55d30209d9
For several iterations I said the MISSION-SELECT-versus-top-item ambiguity needed
a screen whose opening item is not its first, and that none was known. The Decoder
found one and reported it had been sitting unconnected in their corpus.
It is in mine too, and I authored it. authored/flow.json under
main_menu/buttons/ptbtn01 has read since 1defbe0 on 2026-08-29: 'MEASURED
destination (EASY/NORMAL/HARD/BACK, opening on NORMAL, then SELECT DATA)'.
DIFFICULTY opens on the second of four. So 'a screen opens on its first item' is
refuted as a general description of this game, and on EXTRAS, TUTORIAL and OPTIONS
the named item and the top item coincide by accident.
Worse than an index failing to amplify: my extras/initial_focus_why framed the
ambiguity as conditional -- 'it matters IF another screen is ever authored' -- in
the same file that already recorded such a screen. Future tense over a fact twelve
keys away. Corrected to name DIFFICULTY concretely.
MenuFlow.initial_focus's buttons[0] fallback is now documented as a repair for
broken data rather than a default, and that is measured rather than fastidious: if
a screen reaches that line silently the port shows a top-item default for a game
that does not always have one. No authored value moves -- DIFFICULTY is not a
GP_TITLE build and EXTRAS keeps ptbtn11, correct under either reading. Walk re-run
unchanged.
It does not settle the question, which is about reset rather than opening. That
needs the cursor moved inside DIFFICULTY, left and re-entered, and its forward
path crashes the guest at SELECT DATA so the run must go back rather than on.
No checker either of us has built would have caught this. Every instrument here
verifies that a claim matches a value; nothing detects that an answer already
written down is not being connected to the question it answers -- and mine had
both halves in one file.
It also makes the previous iteration's restraint look better: declining to promote
'4/4 submenus reset' to a rule was argued from the principle that a generalisation
should not pre-decide the next screen, and the next screen turns out to be one the
generalisation would have got wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
Authored decisions
Everything here is a decision we made, not something the disc said. It is
hand-written, committed, and survives a re-export — unlike export/, which is
regenerated wholesale and must never be hand-edited.
Every entry carries a why. When the RE agent decodes the real answer, delete
the entry and let the exporter emit it; that deletion is the measure of
progress.
See docs/FORMAT.md for the schemas and docs/BLOCKED.md for which HANDOFF
question each placeholder is standing in for.