Three things folded in from the Decoder, none of which change the export.
S00A IS NOT OBTAINABLE HERE and it is the game that stops it, not the drive. The
drive works end to end -- main menu +0.999, newgame-difficulty +0.999,
newgame-selectdata-crash +0.997, with the focus detector validated live against a
known transition rather than trusted -- and then the guest throws at
PC: 0x82307128 x349 with no S00A stream ever decoding. Recorded in BLOCKED as a
route finding, with the consequence for me stated: THE CENTRE-CHANNEL RESULT
RESTS ON ADV ALONE. S00A was wanted precisely because its second stream is
digital silence where ADV's is a 0.60x copy.
Q5 GAINED TWO POINTS and the shape is sharper than "it varies": TUTORIAL x3, NEW
GAME x3 over six boots, and no other item ever observed. That does not change the
port's authored initial focus -- NEW GAME is still one of exactly two observed
states and is the state of the committed capture -- but it changes what would
REFUTE it, so the authored `why` now says so: a boot opening on LOAD GAME,
OPTIONS or EXTRAS breaks the two-way shape, and a rule predicting the split
deletes the entry outright.
`which-focus` NEEDS GODOT AND THE EXPORT TREE, so it cannot run in the RE
container. Recorded in its own header rather than left for the next agent to
discover, along with the pointer to the capture-only alternative and that tool's
own caveat: its offline controls are its calibration inputs, which is
self-consistency and not validation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
S00A is blocked on knowing which button a screenshot has focused.
`newgame_path.sh` assumed NEW GAME at boot, drove on it, and landed in a tutorial
mission -- HANDOFF Q5 measured focus as UNSTABLE across boots. Counting presses
cannot substitute: up from the first item wraps to the last, so no fixed number
of presses lands on a known item from an unknown start.
The Decoder's own attempt, a per-row brightness statistic, FAILED the control --
it picked NEW GAME on the capture whose filename says OPTIONS. The
render-difference method passes it, so this packages it as a script.
IT RUNS THE CONTROL ON EVERY INVOCATION, not once when it was written, and
refuses to report anything if the control fails.
live-main-menu-options-focused KNOWN ANSWER OPTIONS 4.7x
live-main-menu the question NEW GAME 11.4x
live-extras KNOWN from corpus MISSION SELECT 4.2x
live-title-press-a no menu at all refuses 1.0x
The extras row is a second known answer I did not plant -- authored/flow.json
already records "MEASURED: EXTRAS opens focused on MISSION SELECT
(live-extras.png)" -- and the tool reaches it independently. The title row is the
negative control.
AND THE REFUSAL NOW CARRIES A NON-ZERO EXIT CODE. The first version printed "do
not act on this" and exited 0, so a caller scripting it -- which is the entire
point -- would have read a refusal as an answer. Same defect as a checker
claiming a check it skipped, and the fifth instance of that shape this session.
What it is not: it identifies focus in ONE FRAME and says nothing about what
selects focus. Q5's instability stands.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
