assets/LENS_sm64-movement-camera-onboarding_DRAFT.md
Lens id: sm64-movement-camera-onboarding · Wave P1-B · Read-only audit of C:\dev\humanity-forgotten
(canon) and C:\dev\Humanity\Humanity (built state).
Lens aspects audited: movement/traversal-feel · camera doctrine (NEW aspect) · onboarding /
difficulty / accessibility · retry + failure latency (NEW aspect) · presentation/identity (input
feedback) · combat (movement-combat coupling) · world-structure grammar (verb-shaped space) ·
endgame/replay (player-authored routing).
What the title-set teaches, in one line: the controller is the content. A chained move-verb
vocabulary (triple-jump / long-jump / wall-kick / dive / slide) on a tuned momentum + air-control
curve is fun with zero content around it; the 3D camera is a named first-class system with its own
rules; the first space is a no-fail playground that teaches the whole kit before any objective; and
restart is sub-second, which is what makes hard content generous. SA1/2 is the inverse proof: great
momentum wrecked by a camera that could not hold it.
Method law held (standing wave rule). Every candidate was checked against both repos before judging.
Every zero below is positive-controlled — and one zero in this audit **failed its positive control
and was corrected**: rg TUTORIAL_FORCED_RUN returned 0 across _source/ because the source doc
escapes markdown underscores; rg -F 'TUTORIAL\_FORCED\_RUN' returns the row. That is the
a-search-that-cannot-match-reports-zero class, caught in-flight; the finding built on it was
re-written, not deleted. DESIGNED-UNBUILT is never reported as MISSING.
Dedupe baseline read before writing: docs/DESIGN_GAP_REGISTER.md (entries 1-45 incl. the recovered
rows 10-19 and the v1.1 rows 20-45), docs/PRE_5090_BUILD_PLAN.md ▶ THE PRE-5090 WINDOW PLAN (the
ranked 30) + §12 decisions (#26 the UX/systems spec bundle), docs/PRE_5090_BUILD_PLAN_VOL2.md
(W-MOVE MV-1..MV-11, the 11c input cluster U11.7-U11.13, D-DEFEAT-AXIS), `docs/proposals/
PRESENTATION_DOCTRINE.md, docs/proposals/QA_WATCHING_PROGRAM.md, docs/proposals/
COMPARATOR_LENS_PROGRAM.md` (the 24 uncovered cells — cell 13 retry-latency is registered to a
future Hades/Returnal lens and the overlap is declared per-finding below), and
docs/pipeline_review/FORKB_RESURRECTION_BRIEF_2026-07-27.md.
Two spec-premise corrections, stated up front (my own lens brief was stale on both).
PRE_5090_BUILD_PLAN_VOL2.md L360-368records Josh's ruling overruling Option B ("Rated M game. Things will die. Health 0 is death…"),
and L650 records the reconcile: "CF-10's boss-defeat STATE is **UNBLOCKED — D-DEFEAT-AXIS RESOLVED
2026-07-24**". The player-side defeat shape was ruled separately on 2026-07-27
(docs/spine/DECISIONS_PENDING_JOSH.md L467-486, FORK B J-1..J-5). What is *unmeasured* is
latency, not the axis — the findings below are scoped to that.
---
---
Class: MISSING (spec) · Priority: HIGH · Owner: spec-doc (fold into rank 19) ·
Workable tag: SPEC-SMALL (a clause set inside a doc that already exists and is already ruled)
What SM64 proves. The 3D camera is not a component you attach; it is a *named system with a
doctrine* — how it resolves occlusion, how tight a space it will accept, who owns the yaw (player,
system, or a blend), and what it does at the moment control is taken away and given back. SA1/2 is
the counter-proof: identical-quality momentum, ruined by a camera with no such doctrine.
Current state (cited). The camera is a stock spring-arm with illustrative constants and no
policy: `CameraBoom->TargetArmLength = 400.0f; SocketOffset = (0,0,60); bUsePawnControlRotation =
true; and FollowCamera->bUsePawnControlRotation = false`
[C:/dev/Humanity/Humanity/Source/Humanity/Private/Core/HumanityCharacter.cpp L103-111, each line
tagged // ILLUSTRATIVE]. Nothing in Source/ sets bDoCollisionTest, ProbeSize,
CameraLagSpeed, or any occlusion/fade behaviour — the engine defaults are the design. The plan
declares the absence itself: item #26 bundles "camera rules" with locomotion, HUD IA, tutorial/
onboarding and the rest, closing "None exist as specs today"
[docs/PRE_5090_BUILD_PLAN.md L1925], and P2.2 carries the inline note "*(Camera SPEC is a Josh
gap — §12.)*" [ibid. L1729]. The queue does not cover it. Of the ranked 30, rank 19 is the
*presentation* doctrine (camera continuity / cut / transition covers) and rank 20 is
T1_UI_UX_Spec + T1_Audio_Spec [ibid. L97-98]. docs/proposals/PRESENTATION_DOCTRINE.md (945
lines, three ruled forks) is a cinematic doctrine and explicitly treats the gameplay camera as an
external given: "CC-3 EXIT RETURNS TO THE LIVE POSE. On exit the camera blends back to **the gameplay
camera's** live pose" [ibid. L456]. The thing it blends back to has no rules.
Positive control. rg -i "camera occlusion|camera collision|probe size|camera probe" over
docs/ + _source/ returns hits only in false-friend contexts — ENGINE_OPTIMIZATION_DOCTRINE.md
L307/L1374 (rendering occlusion culling, HZB, Nanite) and three asset-pipeline research notes.
Control that the corpus is reachable with the same tool: rg -c -i "camera" over docs/ matches
51 files, and the string "gameplay camera" itself matches (PRESENTATION_DOCTRINE L456).
Self-refutation attempted. (a) *"Register #29 / rank 19 already own the camera."* — #29's own
text scopes it to "camera continuity, cut policy, diegetic transition covers" and its deadline is
"precedes CN5.2 template bake", i.e. the eleven LS_TPL_* scene templates. Not the same surface.
(b) *"#26 lists it, so it is queued."* — #26 sits in §12 *Decisions needed from Josh*; two of its
eleven bundled surfaces (HUD/UI, loc) were promoted to rank 20, camera and locomotion were not. A
declaration of absence is not a design and does not earn DESIGNED-UNBUILT. (c) *"It is a tuning-
firewall matter."* — No: occlusion policy, enclosed-space behaviour and yaw authority are SHAPES, and
the firewall explicitly reserves only NUMBERS [PRE_5090_BUILD_PLAN.md L1946]. Survives.
Reuse-first recommendation. Do not mint a camera doc. **Add a §GAMEPLAY CAMERA clause set to
docs/proposals/PRESENTATION_DOCTRINE.md** — it already exists, is already ruled, is already rank 19,
and is already the doc CN5.2 reads, so the cinematic camera and the gameplay camera end up governed by
one authority instead of two that must later be reconciled. Minimum clause set, all ordinal, no
numbers: occlusion resolution (pull-in vs fade vs both, and which one on a protected-site mesh);
enclosed/vertical-space behaviour (the slice is full of caves, cone-house interiors and cliff faces —
SM64-2); yaw authority and the recenter contract; the lock-on blend/break settle (the one piece
already built — SM64-C2); and the accessibility clauses currently orphaned in a proposal (SM64-20).
---
Class: WEAKER · Priority: HIGH · Owner: QA loop (graduate an existing diagnostic) ·
Workable tag: TOOTH-SMALL (one field graduation + one rubric band)
What SM64/SA proves. A camera failure is not a crash and not a still — it is a *class* of moment
(a wall between you and yourself, a corner that swallows the pawn, a pitch you cannot recover). It is
only ever caught by instrumenting the camera during ordinary traversal, not during cutscenes.
Current state (cited). The instrument half exists and is scheduled: the per-frame record carries
camera (cam_loc, cam_rot, cam_fov, cam_target_dist, lock_target_in_frustum)
[docs/proposals/QA_WATCHING_PROGRAM.md L47-49], RecordCameraSample is a named 10 Hz feel hook
[ibid. L114, QS-18 at L362], and a camera tooth exists — QS-11 "Camera continuity + frustum
containment; composition read advisory", tooth T-SEQ-CAM-CONTINUITY [ibid. L360, L162]. **But the
tooth is T-SEQ-*** — its failure modes are "a camera teleport; a target leaving frustum" [ibid.
L162], i.e. cut/sequence continuity. Nothing tests penetration, near-clip, self-occlusion or
recovery during free traversal, and the one rubric that would carry it — RB-8 "World rubrics —
traversal BUILD-NOW" [ibid. L386] — is permitted hand-seeded bands as a P2-gating surface [ibid.
L316] with no doctrine to seed from (SM64-19). Meanwhile the slice content is exactly the hostile
set: liang_bua_cave "limestone karst, cool cave air, low-light navigation"
[docs/spine/CH_02.md L84], the Wae Rebo "mbaru-niang five-story ascent, architecture-vertical
movement" [docs/spine/CH_03.md L240], the "Uluwatu sea-cliff temple traverse"
[docs/spine/CH_04.md L250], "an Ituri three-dimensional canopy traverse"
[docs/spine/CH_11.md L245] and "a Bandiagara escarpment cliff-face traverse"
[docs/spine/CH_12.md L263].
Positive control. The T-SEQ-CAM-CONTINUITY and RecordCameraSample strings both return hits
in QA_WATCHING_PROGRAM.md, so the doc is reachable; the zero is specifically for a traversal-scoped
camera tooth (searched traversal camera, camera penetration, near clip, camera recovery —
all zero in docs/ while traversal alone matches the same file at L210/L225/L386).
Self-refutation attempted. (a) *"Josh is the backstop; he'll feel it."* — He plays nothing until
the polished slice (THE JOSH GATE). The QA loop is the only player, and by construction it cannot
report what it does not measure. (b) *"Pixel strips catch composition."* — Pixel strips are ruled
visual reads only and timing-disarmed [ibid. L62-66]; a camera that fails for 0.3 s during a
climb is a timing event on a state strip, which is where the existing cam_* fields already live.
Survives.
Reuse-first recommendation. Graduate RecordCameraSample from diagnostic to tooth on the
existing QS-13..18 family, with three deterministic predicates computed from fields the record
already carries: pawn-to-camera distance collapsing below a floor (penetration), cam_target_dist
discontinuity above a ceiling outside a declared cut, and time-to-recover after either. Land the
band on RB-8 traversal, which is BUILD-NOW and already gates P2.1 exit. No new capture lane, no
new schema, no model spend.
---
Class: WEAKER · Priority: HIGH (the headline of this lens) · Owner: spec-doc + W-MOVE ·
Workable tag: SPEC (a verb roster + reach constants) then BUILD (MV-2's unbuilt half)
What SM64 proves. Every ledge is one *known* jump-arc away. The geometry is authored from the
moveset, so a space that reads as climbable is climbable with the verbs you were given. The failure
mode when this inverts is not "too hard" — it is a player standing at a wall the fiction says to
climb, holding a controller that cannot.
Current state (cited). The course canon is rich and explicit about movement *class*: "77 agility
courses canonical: one course minimum per chapter… Each course uses a documented cultural or
architectural site appropriate to its chapter as physical layout"
[_source/01_Tier_1_Foundation/T1_Combat_System_Spec [ACTIVE v1.0].md §Agility Course System], with
the biome-rotation roster naming "Ch 03 Manggarai mbaru niang: architecture vertical", "Ch 11
Ituri Forest canopy: arboreal three-dimensional canopy (first three-dimensional-movement
course)", "Ch 12 Dogon Bandiagara cliff: vertical cliff-face (first vertical-cliff course)"
[ibid.]. Every live slice entry restates it — Ch 4 "cliff-vertical movement", Ch 13 "alpine-basalt
vertical ascent, high-exposure mountain movement" [docs/spine/CH_13.md L255]. The Ch-2 canopy
course is a hard line: HL_0079, "canopy-horizontal movement, with a forest-pod Puzzle variant"
[docs/spine/CH_02.md L216].
The kit that must service that. Built: walk / sprint / walk-toggle / crouch / jump / dodge-roll /
parry / swim / mantle-vault. The mantle is a forward+down trace with a hard ceiling —
MantleReach = 90.0f, MantleMaxHeight = 130.0f, MantleMinHeight = 25.0f, a 0.28 s position
lerp [Source/Humanity/Public/Core/HumanityCharacter.h L371-374]. JumpZVelocity = 450.0f,
AirControl = 0.35f [Private/Core/HumanityCharacter.cpp L91-92]. There is no climb. The plan
scoped one — MV-2 "Custom CMC modes: climb/mantle/vault" [docs/PRE_5090_BUILD_PLAN_VOL2.md
L553] — and W5 landed mantle + swim only; the header says so in its own words: "MV-3 note: the FULL
HL_0079 canopy course (12 timed pods + the FLORES letter-fragment + the Puzzle variant) is the
remaining slice of MV-3" [HumanityCharacter.h L368-370]. So a 130 uu vault is the tallest thing the
protagonist can surmount, against five slice courses whose named class is vertical or 3-D.
Positive control. rg -i "\bclimb" over _source/01_Tier_1_Foundation/*.md returns 7 files but
T1_Combat_System_Spec returns 1 hit and it is not a verb definition; control that the same tool
finds movement verbs in that doc: rg -c -i "dodge" on the same file returns 10. In Source/,
grep -rn -i "agility|canopy course|HL_0079" returns only comment strings and one HUD id-list, with
mantle as the positive control returning real symbols.
Self-refutation attempted. (a) *"DESIGNED-UNBUILT — MV-2 scopes climb."* — Partly, and that half
is graded so (SM64-8). But MV-2 is a *build* item with no design behind it: nothing anywhere names
the traversal verb ROSTER, its reach constants, or which course class needs which verb. A one-word
build-row noun is not a spec, and the design question ("what does 'arboreal three-dimensional' mean
in verbs?") has no home. That half is genuinely absent, which is why the finding is WEAKER and not
DESIGNED-UNBUILT. (b) *"Mobility abilities cover verticality."* — Refuted at SM64-4: exactly one
mobility ability is Neophyte-tier. (c) *"Courses are L2 opt-in, so this is post-slice."* — HL_0079
is a hard line on Ch 2, and the courses are the arc's declared per-chapter traversal content;
Ch 3, 4, 11, 12 and 13 all sit inside the Prologue→Ch 13 slice. Survives.
Reuse-first recommendation. Author the traversal verb roster as a clause set in the same
spec pass as SM64-1 (rank 19/20), scoped to what the slice's five course classes actually require —
realistically: a ledge-grab/hang, a wall-supported climb with a stamina draw, and a controlled
descent/slide — each declared with an ordinal reach relation to the *already-shipped* constants
(MantleMaxHeight < ledge-grab reach < climb reach), never new numbers. Then MV-2's climb half
builds against a spec instead of a guess, and SM64-15's reachability tooth has something to assert.
Sequence it before any course geometry is staged, or the courses get authored twice.
---
Class: WEAKER · Priority: MEDIUM · Owner: schema-data (rank 13) ·
Workable tag: DATA (a scoped slice-first subset of an already-ranked pass)
What SM64 proves. Progression that arrives as new *verbs* is the reason a fixed kit stays alive
for 120 stars. If the verbs arrive late, the early hours run on the thinnest kit the game will ever
have — which is exactly the window a first-play judgement is formed in.
Current state (cited). T1_Ability_Tree §5D Mobility is genuinely excellent canon: four cast
patterns, "Mini Cyclone Lift carries charge-hold pattern at a brief one-second timing window —
release at the apex… produces vertical lift; release early produces a muted hop; release late
dissipates the cast", element-coupled risk, and the explicit execution-joy clause "**high-mastery
players outperform low-mastery players at the same ability tier through input precision rather than
ability tier alone**" [_source/01_Tier_1_Foundation/T1_Ability_Tree [ACTIVE v1.4].md §5D.1-§5D.2,
L245-271]. The registry carries 12 ability_class=mobility rows. Enumerated directly from
registries/T0_Ability_Tree_Registry [ACTIVE v0.1]/Sheet1.csv: exactly one is Tier 1 Neophyte —
A_A_001 Wind Step, unlock_chapter_ref=Ch_04, cost low, cast instant. The rest are Tier 3
(Ember Trail), Tier 4 ×6 (Earth Surf, Fire Jet, Wind Walker, Mini Cyclone Lift, Soaring Glide, Astral
Projection @ Ch_15), Tier 5 ×2, Tier 6 ×1, Tier 7 ×1 — and **ten of the twelve carry an empty
unlock_chapter_ref**. Corpus-wide only 32 of 185 ability rows carry an unlock chapter.
Positive control. Counts are read straight out of the CSV with csv.DictReader, not grepped; the
same read returns populated values for ability_class, tier_numerical, cast_pattern and
vril_cost_class on every row, so the empty unlock_chapter_ref cells are real emptiness, not a
parse artefact.
Self-refutation attempted. (a) *"Already register #32 / rank 13."* — Correct and declared: #32
is "153/185 abilities lack an unlock chapter" and rank 13 is the ability data pass. This finding is
not a re-mint; it is the slice-scoped consequence and it carries one instruction #32 does not:
when rank 13 runs, the mobility class is sequenced first and anchored inside Ch 2-13, because it
is the only ability class whose absence changes what the player can physically do in the Josh-gate
slice. (b) *"Vril scarcity is the Ch-2 fiction; abilities are supposed to be absent."* — True and
canon-correct, which is precisely why the BASE kit carries the whole slice, and why SM64-3 is the
higher-priority half. Survives as scoped.
Reuse-first recommendation. Inside rank 13, run mobility first: anchor Wind Step's Ch_04 row as
the pattern, and assign unlock_chapter_ref for the mobility class across Ch 2-13 before the wider
185-row pass. No schema change — the column exists and 32 rows already use it.
---
Class: MISSING (spec) · Priority: MEDIUM · Owner: spec-doc (with SM64-3) ·
Workable tag: SPEC-SMALL (3-4 declared legal chains, ordinal only)
What SM64 proves. Traversal is replayable because each move *sets up the next* — long-jump out of
a run, wall-kick out of a jump, dive-slide out of a dive. Depth comes from the transition rules, not
from the count of verbs. A capability list with no transition rules produces a moveset that is used
one verb at a time forever.
Current state (cited). Every built verb is an independent, self-terminating action with its own
timer and no carry rule: StartDodgeRoll launches and opens i-frames [HumanityCharacter.h
L253-256], StartParry opens a window and hard-blocks re-entry via bParryOnCooldown
[ibid. L258-266], TryMantleVault runs a position lerp with bMantling as an exclusion flag
[ibid. L166-171, L375-379]. The single interaction rule in the whole kit is contextual substitution,
not chaining: "Jump (Space) -> try a mantle/vault first; only if none is available do a normal
ACharacter jump" [ibid. L245-247]. UpdateGroundSpeed() recomputes MaxWalkSpeed from the
sprint/walk flags [ibid. L243-244] — there is no momentum carried through any state transition. And
MV-2's own plan row is a capability list: "Custom CMC modes: climb/mantle/vault"
[PRE_5090_BUILD_PLAN_VOL2.md L553]. We already own the idiom this needs: the ruled chain-meter
— N correct answers in a row on a visible pip meter that wipes on a mistake — is built as
HumanityChainMeter [Source/Humanity/Private/Combat/HumanityChainMeter.cpp] and wired to the parry
band resolution [HumanityCharacter.h L111-129]. It has simply never been pointed at traversal.
Positive control. rg -i "coyote|input buffer|buffered input|jump forgiveness" over docs/ +
_source/ returns 10 files, and every hit is a false friend — "Coyote" the Mesoamerican trickster
[T1_Threads_22_Master_References L544/546/553] and one unrelated "input buffer" mention in
QA_WATCHING_PROGRAM.md L209. Control: the same tool on the same corpus finds dodge, mantle and
parry in their real design contexts. So the movement-forgiveness vocabulary is a genuine zero.
Self-refutation attempted. (a) *"Chaining is a platformer idiom; we are an action RPG."* — The
agility-course system is a RuneScape-derived timed-traversal system with a Hardcore time-attack
variant and completion titles; a time attack with no chain grammar measures route memorisation, not
execution. (b) *"Tuning firewall."* — Which transitions are legal is a shape; the windows are
numbers. Only the numbers wait. Survives.
Reuse-first recommendation. In the SM64-3 clause set, declare **three to four legal chains and
their carry rule** (ordinal, e.g. "a dodge that ends within the sprint state preserves sprint speed";
"a mantle exit permits an immediate jump at reduced height"), plus one forgiveness clause (late-jump
grace at a ledge edge) — no milliseconds. Then point the existing chain meter at the agility
course as its second consumer: pips on chained traversal, wipe on a stop. That is Josh's own ruled
mechanic serving a second surface at near-zero cost, and it gives the Hardcore variant something to
be hard *at*.
---
Class: WEAKER · Priority: MEDIUM · Owner: spec-doc (rank 19/20 pass) + Phase-5M ·
Workable tag: SPEC-SMALL (shape clauses; numbers stay firewalled)
What SM64/SA proves. Feel lives in the *curve* — how fast you reach top speed, how long you carry
it, how much of it survives a turn, how much authority you keep in the air. SA1/2 had a superb
momentum model and shipped a bad-feeling game anyway; the curve alone is not sufficient, but no game
has ever felt good without one.
Current state (cited). The pawn sets five scalars and stops: BaseWalkSpeed = 600.0f,
MaxWalkSpeedCrouched = 300.0f, RotationRate = (0, 500, 0), JumpZVelocity = 450.0f,
AirControl = 0.35f, plus SprintSpeedMultiplier = 1.6f / WalkSpeedMultiplier = 0.45f — each
commented // ILLUSTRATIVE under a block that reads "greybox feel only, NOT tuned. The Phase-5M
movement audit (and the P2.3 control-scheme spec) own the real values"
[Private/Core/HumanityCharacter.cpp L85-92; Public/…/HumanityCharacter.h L313-315]. A repo-wide
grep -rn "AirControl|MaxAcceleration|BrakingDeceleration|JumpZVelocity|GravityScale|GroundFriction"
over Source/Humanity/Private/ returns **seven lines, all of them the ones above plus two enemy
rotation-rate lines** — MaxAcceleration, BrakingDeceleration* and GroundFriction are never
touched, so UE's defaults are the shipped acceleration model by omission rather than by choice. The
spec that would own the shape is #26's "locomotion/traversal verbs (Pillar 10 regional movement)"
— declared absent and, like camera, not promoted to the ranked 30
[docs/PRE_5090_BUILD_PLAN.md L1925 vs L60-108].
Positive control. The grep pattern is confirmed live by its own hits (AirControl at L92); the
zero is specifically for the three untouched CMC fields, and the same sweep returns
bOrientRotationToMovement at two sites, proving the file and the field family are reachable.
Self-refutation attempted. (a) *"Tuning firewall — this is Phase-5M's."* — The firewall reserves
"damage/dial coefficients, Sigma magnitudes, tell/window/cooldown ms, resource maxes…" — i.e. NUMBERS
[PRE_5090_BUILD_PLAN.md L1946]. Whether acceleration is even a *parameter* of our feel model is a
shape, and Phase-5M cannot audit a curve nobody declared exists. (b) *"Pillar 10 regional modifiers
cover it."* — Pillar 10 is per-biome *differentiation* ("movement modifiers (jungle vs desert vs
steppe vs ice)", CVD §12.5 L704-706) and its build item MV-7 is a `footfall_surface →
movement-modifier reader [VOL2` L556]. It modulates a base curve; it does not define one.
Survives.
Reuse-first recommendation. Three ordinal clauses in the same spec pass, no numbers: (1) does the
protagonist accelerate to top speed or arrive at it (declare which, and whether sprint is a
multiplier or a separate curve — today it is a multiplier by accident); (2) air control is a *curve*
against airborne time, not a constant, with its endpoint relation stated; (3) turn authority at speed
relates to RotationRate rather than replacing it. Then Phase-5M has three declared knobs to audit
and RB-8 has something to band. The existing RecordInputLatency hook (QS-15) is the instrument.
---
Class: WEAKER · Priority: HIGH · Owner: canon-author (Ch-2 side only) ·
Workable tag: AUTHORING (a teach-order clause on beats that already exist; the Prologue is not touched)
What SM64 proves. The castle grounds teach the *whole* moveset with no objective, no timer and no
failure — and it is the same moveset for the next thirty hours. The transfer is the entire point.
Current state (cited). The playground is real and ruled. The Prologue is "a single
sovereign-ceiling tutorial (no phase-swap, no fail-wall)" whose registry stages are "move through
the realm · learn the four faculties · the birth · the first rift · seal it", living as beats
CHPRO_B01→CHPRO_B09 [docs/spine/CH_PROLOGUE.md L91, L99; `T0_Boss_Encounter_Registry @
BE_PROLOGUE`], with "the resonant-pitch rift-sealing — matching the tear's frequency, **the
apex-faculty tutorial" as its set-piece [ibid. L65, L86]. But the playable character is the
ELVEN KING** — "the only place in the arc he is playable, at full sovereign vril capability…
Sovereign Vril Projection, Rift Sealing, Temporal Sight, and Familiar Communion, all rendered as
effortless birthright" [ibid. L19]. Not one of those four verbs is ever in the protagonist's hands.
The protagonist's own first hour is Ch 2, and the ruled build order puts the Prologue last ("Ch
2-13 first… THEN Prologue + Ch 1" [docs/PRE_5090_BUILD_PLAN.md L130]). Ch 2's first four beats are
B01 hook/character → B11 discovery → B02 puzzle (fire-making, foraging, shelter) → **B03
combat**, the Kelimutu Guardian dual-serpent sub-boss [docs/spine/CH_02.md L106-125]. The player
fights a Komodo dragon and a reticulated python at beat four, and no beat in the chapter is assigned
to teaching movement.
Positive control. Searched the live Ch-2 entry for the v1.0 baseline's tutorial encounter —
rg -i "\bbear\b" docs/spine/CH_02.md returns 0, positive-controlled by rg -c -i "polo" on the
same file returning 47. The baseline row exists but only under escaped markdown:
rg -F 'CAVE\_BEAR' finds `{boss_id: CAVE_BEAR, type: TUTORIAL_FORCED_RUN, mechanic: "must-run
combat tutorial", canonical_outcome: "no combat resolution; flight is the lesson"}`
[_source/01_Tier_1_Foundation/T1_Story_Spine [ACTIVE v1.0].md L50]. **This is the corrected zero
described in the header** — the unescaped search reported "no tutorial encounter in canon", which was
false. The honest statement: canon's only explicitly *typed* tutorial encounter is a v1.0 Ch-2 row
that the v3 rewrite replaced with the hollowed-hunter stalk, which plausibly inherits its
flight-is-the-lesson function but is nowhere labelled or ordered as teaching.
Self-refutation attempted. (a) *"The Prologue is played first, so the player IS onboarded."* —
Onboarded to a different character's kit at a power ceiling that is then removed by design; the
transfer SM64 depends on is exactly what our fiction deliberately breaks. That is a *narrative
strength* and must not change — which is why the recommendation is entirely Ch-2-side. (b) *"Ch 2 is
a survival-horror opener by canon; a playground would wreck the register."* — The strongest
objection, and it bounds the fix: no bright tutorial space, no prompts, no register change. But Ch 2
already contains a no-fail teaching beat and does not know it (SM64-C6), and the site line places
the agility course at mount_inerie_cone_country [CH_02.md L88] — a non-gating, integrity-open,
bonus-only surface sitting in the exact pre-combat position SM64's castle grounds occupy. (c)
*"Canon-locked — flag it."* — No: nothing here changes a chapter, a beat, a name or a number; teach
ORDER is execution within the locked structure. Survives.
Reuse-first recommendation. Do not touch the Prologue. Declare a **teach-order rider on the Ch-2
beats that already exist**: which verb each of B01/B11/B02 first requires, that each is
introduced before it is required under pressure, and that the Standard-variant course at
mount_inerie_cone_country is the declared consequence-free practice surface (it already is one by
reward design — SM64-C3). The right home is docs/FACTORY_CONTRACT.md, which already carries
per-chapter obligation riders (FR-062 is the precedent) and already emits per-chapter checklists via
harness/emit_chapter_checklist.py. One rider row per slice chapter; zero new systems.
---
Class: MISSING (spec) · Priority: HIGH · Owner: spec-doc (promote into the ranked queue) ·
Workable tag: SPEC-SMALL
What SM64 proves. Teaching is a designed artefact with an order, a failure policy and a completion
condition — not a by-product of level one.
Current state (cited). Plan #26 lists "tutorial/onboarding" among eleven surfaces and closes
"None exist as specs today" [docs/PRE_5090_BUILD_PLAN.md L1925]. The ranked 30 contain no
onboarding item [ibid. L60-108]. The window plan itself calls the Prologue "a ceiling tutorial" while
explaining why it sits *off* the density curve and needs declared sentinels [ibid. L146-147] — i.e.
the one thing labelled a tutorial is explicitly the atypical node. The CVD constrains tutorials
without designing them: the thesis is never declared "Not in tutorial text" [T1_CVD … v1.4 L47,
L1097, L1227] — a prohibition, not a spec.
Positive control. rg -i "tutorial|onboarding|no-fail|FTUE" returns 176 hits across 72 files
in docs/ and 23 across 10 in _source/, so the corpus is thoroughly reachable. Reading the
design-relevant hits: they are §17 prohibitions, the Prologue's own label, UE_BUILD_AUTOMATION.md
(13 hits — Epic's build tutorials), and lens/aspect rows naming onboarding as an uncovered cell. No
hit is a teaching design.
Self-refutation attempted. (a) *"The QA loop is the only player until the gate, so onboarding can
wait."* — Inverts the risk. The gate's verdict is a first-play judgement by a person who has never
touched the game, on a slice whose first ninety minutes are the least designed part of it. (b)
*"#26 covers it."* — #26 is a decision-register bullet in §12; camera, locomotion and onboarding are
the three of its eleven surfaces with no ranked owner. Survives.
Reuse-first recommendation. Fold onboarding into the same rank-19/20 spec pass as SM64-1 and
SM64-6 rather than opening a fourth doc — one UX/systems pass covering camera, locomotion and
teaching, because all three are the same slice-critical first-ninety-minutes surface and each is
otherwise a page. Minimum content: the teach-order contract (SM64-7), the failure policy during
teaching (no-fail, per the existing never-gate discipline), and the completion condition the QA
charter can assert ("every verb bound in the IMC has been required at least once by beat N" — the
input-map QA test at W3 already enumerates the bindings [VOL2 L1526]).
---
Class: WEAKER · Priority: MEDIUM · Owner: QA loop + spec-doc ·
Workable tag: TOOTH-SMALL (one diagnostic field on an existing family)
What SM64 proves. Sub-second restart is what makes hard content generous. Time-to-retry is a
*feel* number in the same family as hitstop and input latency, and it is measured, not vibed.
Current state (cited). The defeat model is ruled and is generous in agency: "HOLD ON is the
DEFAULT state the downed player is already in; LET GO is the option; and holding has a hard ceiling —
'maybe after 2 minutes you can't hold on any longer,' surfaced as a countdown… Timeout = the
withdrawal completes to the checkpoint"; the healer's child is "THE RESCUER: the one who brings you
back to the revival location / checkpoint / recharge (save) zone"
[docs/spine/DECISIONS_PENDING_JOSH.md L468-480, FORK B J-1/J-3]. The shipped shell is the only
measured number in the whole loop: DeathFadeSeconds = 0.55f + RespawnHoldSeconds = 0.9f, then
teleport to the nearest AHumanitySiteMarker [HumanityCharacter.h L394-395, L283-290] — the
resurrection brief cites the same figure as "the 1.45 s auto-respawn timer"
[docs/pipeline_review/FORKB_RESURRECTION_BRIEF_2026-07-27.md L540]. Between those two states there
is no budget: the brief reasons about latency exactly once, as a correctness rule ("**wait impossible
fails FAST** (must NOT run a timer out)" [ibid. L540-543]), and never as a measured band. The QA
program instruments RecordInputLatency and RecordHitStop [QS-15/16] and nothing named for retry.
The anchor it would return to does not exist: "grep Checkpoint over Source → 0 hits; there is
no checkpoint to revive at" [ibid. L472].
Positive control. rg -i "time-to-retry|retry latency|restart latency" over docs/ + _source/
returns hits in exactly two files — COMPARATOR_LENS_PROGRAM.md (cells 3 and 13, this program's own
aspect map) and REALM_ANALYSIS_LENS_GAPS_2026-07-27.md. Reachability control: rg -i "checkpoint"
returns 16 hits in the resurrection brief alone.
Declared overlap. COMPARATOR_LENS_PROGRAM.md L47-49 registers "Defeat axis + retry latency" as
cell 13, assigned to a future Hades + Returnal lens ("we named the teacher, never read it").
This finding is deliberately scoped to the half that lens will *not* cover: not the run economy, but
the per-attempt latency of an authored execution surface (a failed course, a failed guardian
pattern) and the instrument that measures it.
Self-refutation attempted. (a) *"The 2-minute hold is Josh's ruling — re-litigating it is out of
bounds."* — Not proposed. The ruling governs the downed *choice*; nothing in it says how long the
path from let-go to next-attempt-control takes, which is a separate quantity and is currently
unbounded because the checkpoint anchor does not exist. (b) *"Sub-second retry is a platformer value
and clashes with weight/consequence."* — For boss defeat, yes, and that is DIVERGENT (SM64-D3). For a
timed agility course it is not: a Hardcore time attack whose restart costs a fade, a load and a walk
back is a Hardcore variant nobody replays. Survives as scoped.
Reuse-first recommendation. Add RecordRetryLatency as a diagnostic on the existing QS-13..18
telemetry family (t from defeat/fail-state to next player-controlled frame), and band it on RB-7/RB-8
once real data exists — the program's own rule is "a new field enters as a diagnostic and becomes a
tooth only by explicit graduation" [QA_WATCHING_PROGRAM.md L115-116]. The field shape already
exists in the ruled defeat ledger (wait_duration_ref in the WS_044 idiom row
[FORKB_RESURRECTION_BRIEF L518]). No new lane; the A1 checkpoint anchor is already the brief's
"hard prerequisite" [ibid. L472].
---
Class: MISSING (design) · Priority: MEDIUM · Owner: spec-doc / canon-author ·
Workable tag: SPEC-TINY (one clause on an existing canonical system)
What SM64 proves. Restart is a designed affordance of the *course*, not a consequence of the
death system. The course owns its own reset.
Current state (cited). The Agility Course System defines three variants, targets, rewards,
letter-fragments, titles and cultural protections — and says nothing about what happens when you
fail. Standard is "timed traversal within target window for Agility XP bonus"; Hardcore is
"tightened time target plus zero-penalty constraints (no hazard triggers, no faction-disturbance
events, no wildlife disturbance)"; Puzzle is "collecting 12 forest pods in Ch 2 Flores canopy course
without stopping" [T1_Combat_System_Spec §Agility Course System]. Three failure conditions —
a missed window, a triggered hazard, a stop — and no reset rule, no restart input, no re-entry point
for any of them. MV-3 (the Ch-2 course runtime) is the unbuilt remainder of W-MOVE
[VOL2 L552; HumanityCharacter.h L368-370], so nothing has been built that would have forced the
question.
Positive control. rg -i "checkpoint" across docs/ returns 15+ files (the reachability
control); none of the hits attaches a checkpoint or reset to a course. In Source/,
grep -rn -i "agility" returns comments only, with mantle as the positive control returning real
symbols — so the runtime genuinely does not exist and cannot be inspected for an implicit answer.
Self-refutation attempted. (a) *"MV-3 will decide it at build time."* — That is the failure mode
this lens exists to name: a reset rule invented in the build lane is a feel decision made by whoever
types first, on the arc's most-repeated surface (77 courses × 3 variants). (b) *"The Puzzle variant is
non-timed, so failure is soft."* — Puzzle is "non-timed or loosely timed" with ordering/collection
objectives and Ch 2's explicit "without stopping"; that is a fail state. Survives.
Reuse-first recommendation. One clause in the same spec pass: a course carries a **declared
re-entry point and an instant reset input**, and failure returns control at that point without a
death, a load or a walk-back. It costs nothing to specify now and reuses the AHumanitySiteMarker
pattern already used for respawn anchoring [HumanityCharacter.h L288-290]. Pair with SM64-9's
latency diagnostic so the claim "our courses restart fast" is ever checkable.
---
Class: WEAKER · Priority: HIGH · Owner: zero-token-script (extend an existing tool) ·
Workable tag: SCRIPT (one new mode on a shipped, proven tool; no model spend)
What SM64 proves. Space is judged against the moveset. "Is this reachable with the verbs the
player has?" is a *measurable* property of geometry, and it is the property that decides whether a
traversal space is fun or a wall.
Current state (cited). W-SPACE is a real, shipped, generalized tool and its bar is entirely
combat: "Verdicts: OK = mean ≤ 10 deg AND max ≤ 20 deg · NEEDS-PAD = mean ≤ 15 AND max ≤ 30 ·
SEVERE = mean > 15 deg OR max > 30 deg… **The COMBAT bar (Josh, W-SPACE): every combat/boss/guardian
footprint must reach OK**; markers/interact nodes get a pad only if SEVERE"
[C:/dev/Humanity/Humanity/Tools/audit_region_spaces.py docstring L24-27]. Its route check is a
walkability grade sampled at 50 m steps (route_leg(..., step_m=50.0), pct_over20, worst500
[ibid. L197-209]) — an order of magnitude coarser than a jump arc. And the sculpt pass it authorizes
does the opposite of what a vertical course needs: "ONLY Borobudur needed pads — **merapi_slopes
18.4°→0.0°** and the Mahakala plaza 10.9°→0.0°" [docs/PRE_5090_BUILD_PLAN.md L820-821] — where
merapi_slopes is described in the tool's own site table as "ash-and-scree stratovolcano slope
corridor ~2.2 km, agility-pod terrace-proportion variant 120x120"
[audit_region_spaces.py L120]. The one place a course pod lives on that map was flattened to zero
degrees for combat legibility, with no tooth asking whether the course still works.
Positive control. The tool, its verdict thresholds and the sculpt figures are read directly from
source and from the ledger entry, not inferred. Control that a traversal-side bar does not exist
anywhere: grep -rn -i "reach|jump arc|traversal audit|climbable" over Tools/ returns no
reachability check, while slope/route return the lines quoted above.
Self-refutation attempted. (a) *"Terrain-first is the pillar — real geography is the game."* —
Agreed and untouched; see SM64-D2. This asks for a *measurement*, not a re-authoring. (b) *"The
courses are staged by hand later, so an audit is premature."* — Inverted: the audit is what tells the
hand-stager which sites already work and which need a pad, and it is cheapest to build before the
staging, not after. (c) *"Nothing is broken yet."* — merapi_slopes is the existence proof that the
combat-only bar already changed course terrain without anyone being told. Survives.
Reuse-first recommendation. Add a --traversal mode to Tools/audit_region_spaces.py, reusing
region_geo.RegionTransform, the .r16 decode and the same reporting scaffold, sampling at
course-relevant resolution and asserting reach against the shipped constants —
JumpZVelocity=450, AirControl=0.35, MantleMaxHeight=130, MantleReach=90, plus whatever
SM64-3's climb clause adds. Verdict: every authored course node is reachable from its predecessor
with the declared kit. Zero-token, no GPU, no model spend, and it is the tooth that makes SM64-3's
spec enforceable instead of aspirational.
---
Class: WEAKER · Priority: MEDIUM · Owner: QA loop (RB-8 band source) ·
Workable tag: RUBRIC (a band source for a rubric already BUILD-NOW)
What SA1/2 proves. This is the cluster's cautionary case: a game can pass a variety check on every
axis — speed stages, mech stages, treasure-hunting, fishing, a Chao garden — and be remembered for
the modes that were bad. Variety without a per-mode quality floor is a shipping risk, not a feature.
Current state (cited). Variety is genuinely measured: mode_variety_check is 79/79 populated
and dominant_combat_mode 79/79, enumerated directly from `registries/T0_Chapter_Index [ACTIVE
v1.2]/T0_Chapter_Index DRAFT v1.1.csv` (this supersedes CLAUDE.md's "populated 0/79" note, which is
flagged stale in that file's own header). Quality is not: the rubric that would carry it is RB-8
"World rubrics — traversal BUILD-NOW, vista SKELETON-NOW"
[QA_WATCHING_PROGRAM.md L386], and traversal is one of only three surfaces permitted
hand-seeded bands ("Hand-seeded bands are permitted for only the three P2-gating surfaces —
boss feel, HUD, traversal" [ibid. L316]). A hand-seeded band is a number a person writes down; with
no locomotion doctrine (SM64-6), no verb roster (SM64-3) and no chain grammar (SM64-5), there is
nothing to derive it from, so the traversal rubric will be seeded from taste and then gate P2.1 exit.
Positive control. The 79/79 figure is a CSV column count, not a grep. The RB-8 and L316 lines are
quoted verbatim from the program doc, which the same tool searches successfully for camera,
traversal and rubric.
Self-refutation attempted. (a) *"Hand-seeded is explicitly allowed."* — Allowed, and the doc is
honest about it (band_source = hand | extracted with a staleness flip). The finding is not that the
mechanism is wrong; it is that traversal is the one of the three P2-gating surfaces whose doctrine
does not exist, so its hand-seed has no upstream. Boss feel has T1_Combat_System_Spec + the
addendum; HUD has the shipped W10 screen; traversal has five illustrative floats. Survives.
Reuse-first recommendation. Make the SM64-6 locomotion clauses the declared band source for
RB-8 (band_source = hand, provenance = the spec section), so the rubric's seed is traceable to a
doctrine rather than to a person, and the staleness flip has something to flip against when
extraction lands at the handshake.
---
Class: WEAKER · Priority: LOW-MEDIUM · Owner: spec-doc / P1 UI ·
Workable tag: SPEC-TINY (extend one existing build row)
Current state (cited). The floor is authored: "Full input remap, hold/toggle alternates,
one-handed presets, camera shake and motion sliders, photosensitivity mode, TTS menus, subtitle
size and speaker labels" [docs/proposals/ROSTER_PROPOSALS.md L373, §"Accessibility floor (not
assists…)"]. The build row that would carry it is narrower: U11.11 "Accessibility input options:
sprint/crouch hold-vs-toggle, look-sensitivity slider (fixed 0.07 legacy today), **settable
invert-Y**" [VOL2 L711]. Camera shake, motion/FOV and photosensitivity have no row. The shake is
built and unconditional: UHumanityImpulseCameraShakePattern with Duration = 0.32f and per-event
scale, self-describing as "legible but not nauseating"
[Source/Humanity/Public/Combat/HumanityCombatCameraShake.h L1-30] — a design intent with no player
control behind it; a repo-wide grep for a shake scale setting or disable returns nothing.
Positive control. rg -c -i "invert-y|invert y" over docs/ matches VOL2 (the reachability
control); the zero is specific to FOV/shake/photosensitivity build rows, and the proposal-tier
hits above prove the vocabulary exists in the corpus.
Self-refutation attempted. *"Care-inflation / timid."* — Checked against the devil's-advocate
bar and it survives in the opposite direction: this is not softening content, it is a shipping-floor
accessibility control on an R-17 action game, and two independent in-repo analyses already flag a
real photosensitivity risk in our own ruled staging ("a dark hold followed by a bright close-up vril
cast is a flash risk by construction" [FORKB_ANALYSIS_PRESENTATION_2026-07-27.md L445;
FORKB_RESURRECTION_BRIEF L383]). Survives.
Reuse-first recommendation. Extend U11.11's existing row with camera-shake scale (0-100%,
including 0), FOV, and the photosensitivity clause, and cite ROSTER_PROPOSALS §5.3 as its source so
the floor stops being orphaned. One row edit; the options-menu framework (U11.5, UGameUserSettings
with an accessibility tab) is already the home.
---
Class: DESIGNED-UNBUILT · Priority: MEDIUM · Owner: W-MOVE (W5 wave) ·
Workable tag: BUILD
Current state (cited). Scoped, cited and queued in VOL2 §Section 2: MV-3 the HL_0079 Ch-2
canopy-course runtime (12 timed pods + the FLORES letter-fragment + the Puzzle variant) [L552];
MV-4 mobility abilities that alter movement (Fluid Dodge / Wind Step / Stone Skin) [L555];
MV-7 the footfall_surface → movement-modifier reader, the Pillar-10 kinesthetic seam [L556];
MV-8 stamina coupling [L557]; MV-9 a fall-damage / hard-landing model [L558]. All carry
BUILD-NOW tags and a wave (W5).
One correction to my own lens brief. MV-8 is *not* covered: Input_SprintStart raises
MaxWalkSpeed with no resource cost — the only stamina spends in the shipped pawn are the dodge
(DodgeStaminaCost = 20.0f) and the parry (ParryStaminaCost = 12.0f)
[Private/Core/HumanityCharacter.cpp L495-501, L710, L843-853]. The absence is exactly as VOL2
L557 states it. Sprint is free today.
Recommendation. No new work order — this row exists so the audit's MISSING count is honest.
Sequencing note only: MV-3 should not build before SM64-3's verb roster exists, or the Ch-2 course
gets authored against a kit that is about to change.
---
Class: WEAKER · Priority: LOW · Owner: (rides SM64-3/SM64-5; no separate work) ·
Workable tag: NONE — sequencing note
What SM64 proves. A permissive controller yields player-authored challenge — routing, skips,
speedruns — for free. It is an endgame lane that costs zero authored content, but only because the
kit has enough transition depth to route *through*.
Current state (cited). The lane is fully designed: the Hardcore variant carries a "tightened time
target plus zero-penalty constraints" and unlocks integrity-banded cosmetic titles
[T1_Combat_System_Spec §Agility Course System], and "top-score every minigame" is ratified L2
completionist canon [T1_CVD … v1.4 L51, L248, L1148]. What it measures is the open question: with
no chain grammar (SM64-5), no acceleration curve to conserve (SM64-6), and a verb set of jump +
130 uu mantle (SM64-3), a Hardcore run is a memorised path walked faster, not a routed one.
Self-refutation attempted. (a) *"No-scoreboard violation."* — Pre-registered divergence, checked:
no-scoreboard governs progression stats (CVD §12.1) and §17.12 already ratifies top-score completion
on minigames. Not re-litigated. (b) *"Speedrunning is not our audience."* — The point is not
speedrunners; it is that the *same* depth is what makes a course worth replaying once. Survives as
low-priority.
Recommendation. No separate work order — this is the payoff clause for SM64-3 and SM64-5, recorded
so the value of those two is not undercounted. Explicitly do not build a ghost/replay feature now:
if one is ever wanted, the QA program's replay/repro emitter (T2-5) is the reuse target, and it is
free until then.
---
tutorial (no phase-swap, no fail-wall)" with a five-stage teach sequence and a set-piece
[CH_PROLOGUE.md L91, L65, L86]. The structure SM64 teaches exists; only its *transfer* is the
gap (SM64-7).
RInterpTo on control rotation with the comment "this only nudges… Never snaps"
[Private/Combat/HumanityTargetingComponent.cpp L272-279], keyed on the IHumanityTargetable
interface rather than on boss types, with a documented break contract
[Public/Combat/HumanityTargetingComponent.h L1-20]. This is the one camera *system* we have and
it is good; SM64-1's doctrine should extend it, not replace it.
*bonus* for hitting the window, not a penalty for missing it, and is "Open to all integrity bands.
No integrity gating" [T1_Combat_System_Spec §Standard Variant] — a no-fail practice surface by
construction. It just needs to be *declared* as the teaching surface (SM64-7).
(star/coin/cap), our per-course token is a single legible class: "a regional letter-fragment
collectible (chapter-themed letters assembling into regional words: Ch 2 spells FLORES, Ch 13
initial letters D-R-A-K…)" [ibid.]. One token per course, one word per region, one meaning. The
cluster's collection-legibility warning does not land here.
settable invert-Y) with absence-proofs cited to the exact source lines [VOL2 L711], riding the
early W3 input wave, not the late UI wave [ibid. L650].
CH02_B11: "The searchcannot fail and cannot wall: the tells escalate to certainty, so a player who keeps looking
always finds it and no one is ever held at this beat, per the never-gate and
clues-are-never-unsolvable discipline" [docs/spine/CH_02.md L112]. The doctrine exists at beat
scale; SM64-7 asks only that it be declared at chapter scale.
mode_variety_check 79/79 (verified in-registry). SM64-12is about quality, not coverage.
InputLatency / HitStop / Stagger / CameraSample` (QS-13..18, BUILD-NOW) with an explicit
diagnostic→tooth graduation rule [QA_WATCHING_PROGRAM.md L114-116, L362]. Every instrument this
lens asks for is a field on an existing family, which is why every recommendation above is small.
a documented cultural or architectural site appropriate to its chapter as physical layout"
[T1_Combat_System_Spec], with protected-site clauses (Ch 12 Tellem granaries, Ch 29 Sámi). This is
care doctrine and immersive-history canon, and it is correct. Derived obligation, not a gap:
because space cannot be authored to the kit, the kit must be authored to the space — which is
precisely what makes SM64-3's verb roster a slice blocker rather than a polish item, and what
SM64-11's reachability tooth exists to check.
1 m hero / 2 m standard / 5-10 m ambient [PRE_5090_BUILD_PLAN.md W4.2-W4.8]. Not a candidate for
change. Same derived obligation as D1.
model [DECISIONS_PENDING_JOSH.md L468-486] is a deliberate divergence from sub-second restart and
is correct for boss defeat in a rated-M consequence-bearing game. SM64-9/SM64-10 are scoped to the
*execution-surface* retry (courses, pattern fails), which the ruling does not govern.
the recommendation) and reconciled in VOL2 L360-368/L650. My lens brief was stale; corrected in
the header.
mode_variety_check is 0/79."* — DEAD. 79/79 in the live registry; the CLAUDE.md line isstale and self-flagged.
CAVE_BEAR / TUTORIAL_FORCED_RUN row exists under escaped markdown. Re-written as SM64-7.
T-SEQ-CAM-CONTINUITY + the cam_* field set exist;the real finding is that they are sequence-scoped (SM64-2).
register-covered (#28 ally survival/defeat + call-out channel, rank 22).
(DESIGN_GAP_REGISTER.md WoW divergent list: "Markerless navigation (our wayfinding legibility
floor)"), and landmark silhouettes are register #4's ground.
15) · DESIGNED-UNBUILT ×1 (SM64-14).
touch the Prologue, and SM64-9/10 must not reopen the ruled defeat axis.
zero-token-script ×1 · schema-data ×1 · canon-author ×1 · W-MOVE ×1 · P1-UI ×1 · sequencing-only ×1.
grammar, locomotion curve, onboarding) are the same document — the first-ninety-minutes UX pass that
plan item #26 already bundles and the ranked 30 never promoted. Ranks 19 and 20 are already in the
queue and are the natural hosts. That is one spec pass, not five, and it is the single highest-
leverage move this lens surfaces.