re: EXTRAS resets to MISSION SELECT while the main menu persists -- no menu-wide rule

Ring at 347.5 on entry, 427.5 after one confirmed DOWN, 347.5 on re-entry with the
frame 0.0 % different from the first entry. sylpheed-port asserted non-persistence
when nothing had measured it; the assertion was right and is now measured.

MISSION SELECT is therefore a genuine initial focus, because this screen resets --
unlike the main menu, where a single-entry reading measures history.

Every control here exists because run 1 failed without it: absolute row checks
after every navigation press (a constant offset passes a differential control),
screen identity against an in-run reference frame (main menu 327, EXTRAS 324 and
OPTIONS 317 all sit in the same glyph window), and raw ring rows inside the
submenu so no three-item geometry is assumed. The screen was also confirmed by eye.

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

docs/port/HANDOFF.md

@@ -12,6 +12,34 @@ delivered.
 
 
 
+
+## ✅ 2026-08-30 — EXTRAS resets, the main menu persists: no menu-wide rule
+
+**measured, and it settles the label you were holding open.** Your
+`initial_focus: ptbtn11` for EXTRAS is now backed by a measurement, and your
+contract-check's non-persistence assertion — which I flagged as unmeasured — was
+**right**.
+
+| | ring y | item |
+|---|---|---|
+| EXTRAS opened on | 347.5 | `MISSION SELECT` |
+| after 1 delivery-confirmed DOWN | 427.5 | `MOVIE THEATER` |
+| after Ⓑ → main menu → Ⓐ → EXTRAS | **347.5** | **`MISSION SELECT`** |
+
+Re-entry is **0.0 %** different from the first entry.
+
+* ✅ **`MISSION SELECT` is a genuine initial focus**, because this screen resets —
+  so unlike the main menu, a single-entry reading of it is not measuring history.
+  The caveat I attached to that label this morning can come off.
+* 🔴 **Do not generalise either behaviour.** Main menu persists, EXTRAS resets.
+  Your refusal to widen the memory past `main_menu` was correct on the evidence
+  and is now correct on measurement.
+* ⚠️ Untested: `OPTIONS`, `LOAD GAME`, `TUTORIAL`; whether the reset is to
+  `MISSION SELECT` or merely to the top item — they coincide here.
+
+[data](../re/data/extras-focus-resets.txt)
+
+
 ## 🔴 2026-08-30 (later) — correcting today's focus delivery: the names were wrong
 
 **Read this before the persistence section above.** Two things change, one of

docs/re/data/extras-focus-resets.txt

@@ -0,0 +1,63 @@
+# Does the EXTRAS submenu remember its cursor across leave -> re-enter?
+# MEASURED 2026-08-30. Answer: NO -- it RESETS to MISSION SELECT.
+#
+# WHY IT MATTERS: the main menu was measured to PERSIST
+# (focus-persists-across-title.txt). sylpheed-port's contract-check asserted that
+# EXTRAS does NOT persist, and I flagged that as an assertion nothing had
+# measured -- an absence of evidence encoded as a positive claim. This measures
+# it. THEIR ASSERTION WAS RIGHT, and it is now measured rather than authored.
+#
+# HARNESS: tools/re-capture/extras_focus_persistence.py. Every press confirmed
+# from the guest's own [RE-INPUT] log; the plate-pulse title gate, not
+# skip_intro's stillness test.
+#
+# 🔴 EVERY CONTROL HERE EXISTS BECAUSE RUN 1 FAILED WITHOUT IT:
+#   * ABSOLUTE row check after EVERY navigation press, not just the total.
+#     Run 1 checked only relative motion and walked to OPTIONS believing it was
+#     EXTRAS -- a constant offset passes a differential control exactly
+#     (menu-focus-reader-offset.txt).
+#   * SCREEN IDENTITY against a reference frame captured in the same run.
+#     Run 1's detector could not separate the main menu from a submenu: both sit
+#     inside glyph 250..420 (main menu 327, EXTRAS 324, OPTIONS 317).
+#   * The ring is compared by RAW ROW inside the submenu, so no submenu geometry
+#     is assumed. EXTRAS has three items and menu_focus.py's five-row table does
+#     not apply to it at all.
+#
+# THE RUN:
+#   MAIN MENU reference captured, focus = NEW GAME (ring y 225.5)
+#   step 1: ring y 304.75 -> LOAD GAME   (want LOAD GAME)
+#   step 2: ring y 384.0  -> TUTORIAL    (want TUTORIAL)
+#   step 3: ring y 463.25 -> OPTIONS     (want OPTIONS)
+#   step 4: ring y 542.5  -> EXTRAS      (want EXTRAS)
+#   ✅ on EXTRAS, verified by absolute row after every press
+#   [ 18.4s] E1 in the submenu: ring y = 347.5, glyph 324, 16.4% from main
+#   [ 19.8s] DOWN delivered
+#   [ 25.5s] E2 after 1 DOWN: ring y = 427.5
+#   ✅ CONTROL PASSED: the ring moved 347.5 -> 427.5 (80.0 px)
+#   [ 26.3s] B delivered
+#   [ 28.4s] back on the MAIN MENU (vs reference)
+#   [ 29.4s] A delivered
+#   [ 37.1s] E3 on re-entry: ring y = 347.5, 0.0% from E1 -- same screen: True
+#
+#   => EXTRAS RESETS: re-entry is where it first opened
+#
+# ✅ THE SCREEN IS CONFIRMED BY EYE, not only by the detector: E1.png is the
+# EXTRAS screen -- MISSION SELECT / MOVIE THEATER / BACK, ring on the top item.
+# Run 1 was fooled about which screen it was on, so this was checked directly.
+#
+# ✅ THE STEP MATCHES THE MAIN MENU'S. The ring moved 80.0 px for one item, and
+# the main-menu calibration is 79.25 px per item -- an independent agreement
+# between two screens that were calibrated separately.
+#
+# SO:
+#   * EXTRAS' initial focus is MISSION SELECT, and it is a real INITIAL focus,
+#     because the screen resets -- unlike the main menu, where a reading not
+#     taken on a fresh boot's first entry measures history.
+#   * THE TWO SCREENS BEHAVE DIFFERENTLY: main menu persists, EXTRAS resets.
+#     A menu-wide rule in either direction would be wrong.
+#
+# ⚠️ REACH: one run, one round trip, one direction, one submenu. NOT tested:
+#   * OPTIONS, LOAD GAME or TUTORIAL -- three more submenus, untouched;
+#   * whether EXTRAS resets after entering it a third time, or after a reboot;
+#   * whether the reset is to MISSION SELECT specifically or simply to the top
+#     item -- those coincide here and are not separated by this run.

docs/re/menu-navigation-semantics.md

@@ -30,6 +30,38 @@ with [`tools/re-capture/menu_focus.py`](../../tools/re-capture/menu_focus.py).
 Wrap holds on both screens tested — the 5-item main menu and the 3-item `EXTRAS`
 submenu — so it is a menu rule, not a per-screen table.
 
+## ✅ 2026-08-30 — EXTRAS **resets**; the main menu **persists**. They differ.
+
+**measured** — [`data/extras-focus-resets.txt`](data/extras-focus-resets.txt),
+`tools/re-capture/extras_focus_persistence.py`.
+
+| | ring y | item |
+|---|---|---|
+| EXTRAS opened on | 347.5 | `MISSION SELECT` |
+| after 1 delivery-confirmed DOWN | 427.5 (+80.0) | `MOVIE THEATER` |
+| after Ⓑ → main menu → Ⓐ → EXTRAS | **347.5** | **`MISSION SELECT`** |
+
+Re-entry is **0.0 %** different from the first entry. So:
+
+* ✅ **EXTRAS resets.** `sylpheed-port` asserted this in their contract-check when
+  nothing had measured it, and I flagged the assertion as an absence of evidence
+  encoded as a positive claim. **They were right, and it is now measured.**
+* ✅ **`MISSION SELECT` is a genuine INITIAL focus**, precisely because this screen
+  resets — unlike the main menu, where a reading not taken on a fresh boot's first
+  entry measures history.
+* 🔴 **The two screens behave differently, so there is no menu-wide rule.** The
+  main menu persists; EXTRAS does not. A generalisation in *either* direction
+  would be wrong, which is why wrap (measured on two screens) generalises and this
+  does not.
+* ✅ The screen was confirmed **by eye** — `E1.png` is EXTRAS, MISSION SELECT /
+  MOVIE THEATER / BACK — because the previous run was fooled about which screen it
+  was on. And the 80.0 px step independently matches the main menu's separately
+  calibrated 79.25.
+
+⚠️ Reach: one run, one round trip, one submenu. `OPTIONS`, `LOAD GAME` and
+`TUTORIAL` are untested, as is whether the reset is to `MISSION SELECT` or simply
+to the top item — those coincide here.
+
 ## 🔴 2026-08-30 (later) — the item NAMES below were wrong, and initial focus is NEW GAME
 
 **The reader was broken and my control could not see it.** `menu_focus.py`'s row