port: the counter-example I kept asking for was in a file I wrote

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 eef45ec 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/flow.json

@@ -378,7 +378,19 @@
     "measuring history -- which is precisely what made the caveat necessary while",
     "persistence here was unknown.",
     "",
-    "⚠️ WHAT IS STILL AMBIGUOUS, and it matters if another screen is ever authored:",
+    "⚠️ WHAT IS STILL AMBIGUOUS -- and the condition below is ALREADY MET:",
+    "",
+    "🔴 CORRECTED 2026-08-31. This read \"it matters IF another screen is ever",
+    "authored\" whose opening item is not its first. Such a screen exists and is",
+    "recorded IN THIS FILE: DIFFICULTY, under `main_menu/buttons/ptbtn01`, is",
+    "EASY/NORMAL/HARD/BACK and opens on NORMAL -- the SECOND of four. Measured:",
+    "driven with no d-pad, unchanged for 90 s, matching the committed capture at",
+    "r=+0.999 (Decoder, docs/re/captures/newgame-path/newgame-difficulty.png).",
+    "",
+    "So \"a screen opens on its first item\" is REFUTED as a general description of",
+    "this game. On EXTRAS, TUTORIAL and OPTIONS the named item and the top item",
+    "coincide BY ACCIDENT. A top-item rule would be wrong on DIFFICULTY.",
+    "",
     "nobody can separate \"resets to MISSION SELECT\" from \"resets to the TOP ITEM\".",
     "They coincide here -- ptbtn11 is both. The port's value is correct under either",
     "reading, and the REASON is not established.",