re: the S00A drive failed -- initial menu focus was TUTORIAL, not NEW GAME

Reported as a route finding rather than retried silently, because the cause is a
defect in shared harness tooling that will bite the next drive.

Drive 1 sat 396 s reporting other with two spurious menu hits while the guest was
healthy and decoding audio throughout. screen_id.py thresholds on green and only
returns title once the PRESS A plate has faded in, so it cannot see the
plate-less build-4 title this corpus documents. It also calls difficulty-screen a
menu. Both reproduce on committed frames, and newgame_path.sh, nav_probe.sh and
boot_menu.sh all gate on it.

Drive 2, with a classifier controlled 6/6, reached title_plate at t=398 s and
drove on -- into a TUTORIAL MISSION. The screen 60 s after the last A correlates
+0.960 with the committed tutorial-mission-reached-then-crash.png, and no S00A
voice stream ever decoded. newgame_path.sh s header assumes NEW GAME is the first
item so no d-pad movement is needed; that contradicts this corpus s own Q5
result, where four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME.

Incidental corroboration: BGM_103 s two waves decoded on reaching the menu, an
independent runtime confirmation of the menu-music claim that HANDOFF rests on
static code and a disc census.

What is needed is a focus DETECTOR, and wrap-around means counting presses cannot
substitute -- up from the first item goes to the last. I do not have one: a
per-row brightness statistic failed its control, picking NEW GAME on the capture
whose filename says OPTIONS.

Also records a refutation attempt on the port s focus identification that FAILED.
Differencing the two captures and binning by row appeared to show NEW GAME and
EXTRAS changing, contradicting them. That was my error -- I placed row bands as
rest_y plus or minus 24, treating the resting position as a band centre. The
offset-independent check settles it: the changed bands are 254.9 design-y apart
against a button pitch of 80, so the two focused buttons are 3 apart and not 4 --
NEW GAME to OPTIONS. Their identification stands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/re/s00a-drive-blocked-by-focus.md

@@ -0,0 +1,92 @@
+# 🔴 The `S00A` capture failed — the menu's initial focus was TUTORIAL, not NEW GAME
+
+**Classification: measured.** Two drives, 2026-08-29. Reported as a **route
+finding** rather than retried silently, because the cause is a defect in shared
+harness tooling that will bite the next drive too.
+
+## What was wanted
+
+`S00A` is the new-game intro and the second asset for the centre-channel voice
+result ([`voice-three-streams-are-concurrent.md`](structures/voice-three-streams-are-concurrent.md)):
+its second full-length stream is **digital silence** where `ADV`'s is a 0.60 ×
+copy, so agreement there would stop the finding resting on one movie. It starts
+~4.5 s after Ⓐ on the save slot, so it needs a **driven, rendered** run.
+
+## 🔴 Drive 1 — `screen_id.py` cannot see the title it was waiting for
+
+396 s of `other`, two spurious `menu` hits, abort. The guest was healthy
+throughout — its audio was decoding the whole time.
+
+`screen_id.py` thresholds on **green** and only returns `title` once the
+`PRESS Ⓐ` plate has faded in. This corpus's own finding is that the boot title
+shows **build 4 first, plate-less**. Both defects reproduce on committed frames
+(see [`METHOD.md`](METHOD.md)):
+
+| frame | `screen_id.py` | should be |
+|---|---|---|
+| `live-title-build4-no-plate.png` | **`other`** | title |
+| `difficulty-screen.png` | **`menu`** | not the main menu |
+
+⚠️ `newgame_path.sh`, `nav_probe.sh` and `boot_menu.sh` all gate on it.
+
+## 🔴 Drive 2 — reached the title, then pressed Ⓐ on the wrong button
+
+With a replacement classifier controlled **6/6** (three oracle frames at 1.000;
+`difficulty-screen` and both movie frames correctly `other`, at a 0.85 threshold —
+at 0.60 it repeated `screen_id.py`'s own difficulty/menu confusion), the drive
+reached `title_plate` at **t = 398 s**, took Ⓐ to the menu, and drove on.
+
+**It ended up in a tutorial mission.** The screen 60 s after the last Ⓐ
+correlates **+0.960** with the committed
+`tutorial-mission-reached-then-crash.png`. No `S00A` voice stream ever decoded —
+the probe logged `ADV`'s three, `BGM_102`'s two, `BGM_103`'s two and two SE cues,
+and **none of S00A's** (1 810 432 / 1 263 616 / 98 304).
+
+**Why:** `newgame_path.sh`'s header says *"NEW GAME is the menu's FIRST item, so
+this presses (A) with no d-pad movement"*. 🔴 **That assumption contradicts this
+corpus's own Q5 result** — initial focus varies boot to boot, four boots giving
+`TUTORIAL, TUTORIAL, NEW GAME, NEW GAME`
+([`menu-navigation-semantics.md`](menu-navigation-semantics.md)). This boot
+started on TUTORIAL, so the first Ⓐ opened the lesson list.
+
+✅ **Incidental corroboration:** `BGM_103`'s two waves (3 876 864 / 3 930 112)
+decoded on reaching the menu — an independent confirmation of HANDOFF's
+"the menu's music is `BGM_103`", from the runtime rather than from the cue table.
+
+## ❔ What is needed, and why it is not just "press up four times"
+
+Focus must be **detected**, not assumed — and wrap-around makes it
+unreachable by counting: ⬆ from the first item goes to the *last*, so no fixed
+number of presses lands on a known item from an unknown start.
+
+🔴 **And I do not currently have a focus detector.** A per-row brightness
+statistic **failed its control**: on `live-main-menu-options-focused.png` — whose
+answer is in its own filename — it picked NEW GAME. Brightness across a button
+row is dominated by something other than the focus highlight. Until a controlled
+detector exists, a driven run cannot reliably choose a menu item on this boot
+path.
+
+## 🟢 A refutation attempt on the port's focus identification — it FAILED
+
+The port identified `live-main-menu.png` as **NEW GAME focused**, by minimum
+render difference, with the `-options-focused` capture as a control it picked
+correctly by 4.7×.
+
+Differencing the two captures directly and binning by button row, I got NEW GAME
+and **EXTRAS** changing while OPTIONS stayed still — an apparent refutation.
+**It was my error.** I placed the row bands as `rest_y ± 24`, treating the
+resting position as a band *centre*; the changed bands then mis-assigned.
+
+The offset-independent check settles it without needing that geometry at all:
+
+| | |
+|---|---|
+| changed band centres (design y) | 195.2 and 450.1 |
+| separation | **254.9** |
+| 3 button pitches (3 × 80) | 240 — off by **14.9** |
+| 4 button pitches | 320 — off by 65.1 |
+
+**The two focused buttons are 3 apart, not 4** — NEW GAME → OPTIONS, not
+NEW GAME → EXTRAS. ✅ **The port's identification stands.** ⚠️ And as they
+themselves noted, it identifies *one frame*, not a rule: Q5's instability is
+untouched.