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

🔴 S00A is unreachable here — the new-game path crashes on an on-disc cache it cannot finish building

Four drives. The first three failed on tooling and are recorded below because each defect is live in shared scripts. The fourth drove perfectly and hit a guest crash, which is the real answer.

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

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

---

✅ Drive 4 — the drive worked; the GAME crashes at SELECT DATA

With focus detected and the detector validated live against a known transition (NEW GAME → ⬇ → LOAD GAME, expected LOAD GAME, CONTROL PASSED), the drive navigated to NEW GAME and pressed through. Every step is confirmed against a committed capture:

step	correlates with	r
after navigation	main-menu-items.png	+0.999
after Ⓐ	newgame-difficulty.png	+0.999
after Ⓐ (NORMAL)	newgame-selectdata-crash.png	+0.997

Then the guest throws: PC: 0x82307128 ×349, one Guest attempted to throw a C++ exception!. No S00A voice stream ever decodes.

✅ It is on the new-game path, not the boot. Ordering in the log is ADV (attract) → BGM_103 (menu music, i.e. the menu was reached) → throw → crash dumps. So this is not the ~100 s boot throw that title-crash-stl-tree.md documents.

🟡 Refining that page — the mechanism holds, the container does not

That page attributes the throw to an incomplete on-disc cache, and Q4's note says the SELECT DATA crash "is already in the corpus", citing it. Checked, and the attribution survives — but not via the container the page names.

cache container	state here
aab216c3 — the one the page names	7 files, complete	not the trigger
1b556564 — resolved immediately before the throw	1 file + 1b556564900c8dcd.tmp	⚠️ exactly the page's run C, "partially rebuilt (1 file + a .tmp) → 1 GUEST-THROW"

The log line before the exception is HostPathDevice::ResolvePath(\1b556564\9\00c8dcd). So the new-game path builds a different cache container from the title path, and it is that one which is incomplete.

🔴 And the page's remedy does not transfer. Its fix is to restore a previously complete cache (run D). No complete 1b556564 has ever existed in this container — the game crashes while building it, leaving the .tmp, so the cache cannot complete and the crash cannot be escaped by re-running. The page's own run B shows a fully cold cache throws too, so deleting it does not help either.

The answer

❔ S00A is not obtainable in this container, and the reach is:

• the drive is not the obstacle — four screens confirmed against committed captures at r ≥ 0.997, and the focus detector passed a live transition control;
• the obstacle is a guest crash with a known site and a known class of trigger;
• the documented remedy needs an artefact — a complete 1b556564 — that has never existed here and that the game cannot produce because it crashes mid-build.

⚠️ Consequence for the voice finding: the centre-channel result stays resting on ADV alone. S00A was wanted because its second stream is digital silence where ADV's is a 0.60 × copy; that corroboration is not available from this container without first solving a crash that is outside the menu-port scope.