LENS_sm64-movement-camera-onboarding_DRAFT.md

assets/LENS_sm64-movement-camera-onboarding_DRAFT.md

Comparator lens audit — SUPER MARIO 64 (+ Sonic Adventure 1/2 as the camera/momentum counter-case)

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).

records 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.

---

FINDINGS (15) — MISSING ×4 · WEAKER ×10 · DESIGNED-UNBUILT ×1

---

SM64-1 — There is no gameplay-camera doctrine, and unlike every other #26 surface it is not on the ranked queue

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).

---

SM64-2 — The QA loop cannot see a bad gameplay camera: the camera teeth are sequence-scoped, and the slice is the most camera-hostile content in the game

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.

---

SM64-3 — The slice's own agility courses name movement CLASSES the kit cannot express, and the built mantle caps at ~1.3 m

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.

---

SM64-4 — The slice's traversal-ability curve is one Neophyte row across fifteen nodes

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.

---

SM64-5 — Move verbs do not chain: there is no cancel/carry grammar, and we already built the chain-read idiom for combat

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*.

---

SM64-6 — Locomotion is a set of speed values, not a momentum curve: no acceleration, braking or friction is ever authored

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.

---

SM64-7 — The no-fail playground exists and is canonical — but it teaches a kit the player will never hold again

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.

---

SM64-8 — There is no onboarding/tutorial spec, it is declared absent, and it is the only #26 surface with a hard gate riding on it

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]).

---

SM64-9 — Retry latency is a feel metric nobody measures, and the ruled defeat model can make it minutes

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].

---

SM64-10 — A failed agility course has no retry affordance at all

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.

---

SM64-11 — The only tooth that judges our spaces is a combat-slope bar, and the sculpt pass it authorizes flattens the terraces a vertical course wants

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.

---

SM64-12 — Pillar 11 measures mode VARIETY; nothing measures whether the traversal mode is any good

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.

---

SM64-13 — The accessibility floor's camera clauses are orphaned in a proposal with no build item

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.

---

SM64-14 — W-MOVE's remaining queue is designed and unbuilt (recorded so it is never re-minted as missing)

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.

---

SM64-15 — The permissive-controller replay dividend is claimed but not earned: the time-attack lane exists, the execution depth it measures does not

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.

---

COVERED — we already match the pattern (so this audit is not read as "everything is missing")

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].

cannot 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.

is 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.

DIVERGENT-BY-DESIGN — we deliberately differ

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.

Refuted and dropped (attacked before writing; recorded so they are not re-minted)

the recommendation) and reconciled in VOL2 L360-368/L650. My lens brief was stale; corrected in

the header.

stale and self-flagged.

CAVE_BEAR / TUTORIAL_FORCED_RUN row exists under escaped markdown. Re-written as SM64-7.

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.

Section counts

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.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root