From b7930e66163021412f3ee96bd18ad96cb49ede76 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 17:27:22 +0000 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/s00a-drive-blocked-by-focus.md | 92 ++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 docs/re/s00a-drive-blocked-by-focus.md diff --git a/docs/re/s00a-drive-blocked-by-focus.md b/docs/re/s00a-drive-blocked-by-focus.md new file mode 100644 index 00000000..77c926f8 --- /dev/null +++ b/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.