re: initial focus is TUTORIAL x3 / NEW GAME x3, and never anything else

Two more data points for the Q5 instability, from today s drives. A run that
pressed A with no d-pad movement ended in a tutorial mission, correlating +0.960
with the committed capture, so that boot opened on TUTORIAL. A later boot read
NEW GAME from a focus detector on the first menu frame.

Six boots on the same harness now: TUTORIAL three times, NEW GAME three times,
and no other item ever observed. The distribution is not uniform over the five
buttons -- only these two occur -- which is a real constraint on whatever selects
initial focus and something an explanation will have to account for.

Also records in METHOD a bug that cost a seven-minute driven boot: a value was
clamped for readability BEFORE the comparison that used it. A focus detector
printed a degenerate margin, so it was capped at 999; the cap ran before the
vote-sorting step, two different votes compared equal, the stable sort kept the
wrong one, and a correct NEW GAME became an out-of-range index and a refusal. The
measurement was right throughout -- a cosmetic fix changed a decision. Clamp at
the point of display, never upstream of a comparison.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/re/METHOD.md

@@ -129,6 +129,14 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
 * **Raw grep cannot see inside compressed pak entries.**
 * **Commit messages go in a file** (`git commit -F`); a literal `|` in a table
   cell needs escaping; `git log --all -- <path>` can hang.
+* 🔴 **Never clamp a value before something compares it.** A focus detector
+  printed a degenerate `margin=12359888888.89`, so it was capped at 999 to keep
+  the output readable. That cap ran *before* the vote-sorting step, so two
+  different votes compared **equal**, the stable sort kept the wrong one, and a
+  correct `NEW GAME` became an out-of-range index and a refusal — which aborted a
+  seven-minute driven boot. The measurement was right the whole time; a cosmetic
+  fix changed a decision. **Clamp at the point of display, never upstream of a
+  comparison that depends on the value.**
 * **`pkill -f PATTERN` / `pgrep -f PATTERN` match YOUR OWN command line.** Hit
   twice in one session: `pkill -9 -f adv_audio_cap.sh` killed the shell that ran
   it, and an `until ! pgrep -f "probe.py --run"` loop never exited because the

docs/re/menu-navigation-semantics.md

@@ -130,12 +130,24 @@ So Q4's last row closes as **measured**:
 and `3 GP_LOAD` / `2 GP_SELECT_STORAGE` are name-match candidates and nothing
 more.
 
-### Initial focus — a fourth data point, and it still varies
+### Initial focus — six data points now, and it still varies
 
 This boot opened the main menu on **`NEW GAME`**. Running tally across four
 boots of the same harness: `TUTORIAL`, `TUTORIAL`, `NEW GAME`, `NEW GAME`.
 Unchanged conclusion: **do not hardcode it.**
 
+✅ **Two more, 2026-08-29, and the split is now even.** A drive that pressed Ⓐ
+with no d-pad movement ended in a **tutorial mission** (+0.960 against
+`tutorial-mission-reached-then-crash.png`), so that boot opened on `TUTORIAL`. A
+later boot read **`NEW GAME`** from a focus detector on the first menu frame.
+
+**Tally: `TUTORIAL` ×3, `NEW GAME` ×3.** Six boots, same harness, no other item
+ever seen. ⚠️ It is *not* uniform across the five buttons — only these two occur —
+which is a constraint on whatever selects it, and something a future explanation
+has to account for. Still **do not hardcode it**, and note that
+`newgame_path.sh`'s "NEW GAME is the first item so no d-pad is needed" is wrong
+half the time — see [`s00a-drive-blocked-by-focus.md`](s00a-drive-blocked-by-focus.md).
+
 ### The `NEW GAME` path completes — the `SELECT DATA` crash is state, not path
 
 A second run of the same path, 2026-08-28, **did not crash**: