re: the main menu remembers its cursor across menu -> title -> menu

F1 TUTORIAL, two delivery-confirmed DOWNs to EXTRAS, B to the title, A back:
F3 is EXTRAS. Re-entry restores the item you left.

Reframes the initial-focus disagreement rather than settling it: if focus
persists, any 'initial focus' reading not taken on a fresh boot's first menu entry
measures history. It still says nothing about what the menu opens on -- this run's
F1 was itself carried over from a prior probe's press.

Reached on the plate-pulse gate, not boot_menu.sh, whose stillness test cannot fire
on this title -- TITLE at 422.7 s on a boot skip_intro could not gate at all.

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

docs/port/HANDOFF.md

@@ -10,6 +10,32 @@ delivered.
 
 
 
+
+## ✅ 2026-08-30 — the main menu remembers its cursor; re-entry is not a reset
+
+**measured, and it changes what `on_cancel` should do.** Ⓑ from the menu to the
+title and Ⓐ back returns you to **the item you left**, not to a default.
+
+| step | focus |
+|---|---|
+| on the menu | `TUTORIAL` |
+| after 2× DOWN (both delivery-confirmed) | `EXTRAS` |
+| after Ⓑ → title → Ⓐ → menu | **`EXTRAS`** |
+
+Control passed: two DOWN presses moved the cursor exactly two items, and the run
+is discarded if they do not.
+[`data/focus-persists-across-title.txt`](../re/data/focus-persists-across-title.txt)
+
+📌 **This also reframes the initial-focus warning I sent earlier today.** If focus
+persists, an "initial focus" reading not taken on a fresh boot's *first* menu entry
+is measuring history — so the records that disagree need not disagree about the
+game. **It still does not say what the menu opens on.** Your authored `NEW GAME`
+stands on its own reasoning; nothing here confirms or refutes it.
+
+⚠️ Reach: one boot, one round trip, one direction. Persistence across a **reboot**
+is untested and is the reading that would matter for authoring a default.
+
+
 ## 🔴 2026-08-30 — do not hardcode the menu's initial focus; the sources disagree
 
 **New, and it is a warning rather than an answer.** `menu-navigation-semantics.md`

docs/re/data/focus-persists-across-title.txt

@@ -0,0 +1,62 @@
+# Does the main menu REMEMBER its cursor across menu -> title -> menu?
+# MEASURED 2026-08-30. Answer: YES.
+#
+# WHY IT MATTERS: menu-navigation-semantics.md records initial focus as TUTORIAL
+# (2/2 boots) while boot_menu.sh's closing line says NEW GAME and
+# menu-state-in-memory.md reaches EXTRAS in four downs, which only counts from
+# NEW GAME. If focus PERSISTS, then any "initial focus" reading not taken on a
+# fresh boot's FIRST menu entry is measuring history, not initial focus -- which
+# would explain the disagreement without any of the records being wrong.
+#
+# HARNESS: tools/re-capture/focus_persistence.py, on the path b_from_menu.py
+# validated -- plate-pulse title detector, glyph-327 menu detector, and every
+# press confirmed from the guest's own [RE-INPUT] log rather than from the pad.
+# NOT boot_menu.sh: its title gate tests for stillness and this title never
+# stills (harness-title-gate-assumes-a-static-title.md). The plate-pulse gate
+# reached TITLE at 422.7 s on the boot skip_intro could not gate at all.
+#
+# ✅ CONTROL, and it is the reason run 1 is discarded rather than reported:
+#    two DOWN presses must move the cursor exactly two items. If they do not,
+#    the reader is not tracking and F3 may not be read.
+#
+#   [   1.0s] MENU (glyph 327)  F1 = TUTORIAL   ring   130    76   254    69    64
+#   [   7.3s] DOWN delivered (attempt 1)
+#   [   8.2s] DOWN delivered (attempt 1)
+#   [   1.0s] after 2x DOWN  F2 = EXTRAS   ring   130    76    66    69   254
+#   ✅ CONTROL PASSED: 2x DOWN moved TUTORIAL -> EXTRAS
+#   [  13.3s] B delivered (attempt 1)
+#   [  24.0s] BACK AT TITLE (glyph 1403)
+#   [  25.8s] A delivered (attempt 1)
+#   [  33.6s] MENU AGAIN  F3 = EXTRAS   ring   130    76    66    69   254
+#
+#   F1=TUTORIAL  F2=EXTRAS  F3=EXTRAS   => FOCUS PERSISTS
+#
+# The ring vector is menu_focus.py's geometry byte for byte: the peak moves from
+# index 2 to index 4 and STAYS at 4 across the round trip.
+#
+################################################################################
+# 🔴 RUN 1 IS DISCARDED, AND ITS FAILURE IS THE USEFUL PART.
+#
+# The first attempt read F1 = LOAD GAME and F2 = LOAD GAME -- the cursor had not
+# moved -- and the control refused to report F3. The cause was NOT the reader:
+# the two frames genuinely differ by 911 px, so they are different frames. It is
+# that run 1 sent the DOWN presses through pad.py with NO delivery confirmation,
+# while A and B were confirmed. The guest's own log settles it:
+#
+#   vk=5811 (dpad down) flags=0001 ... delivered ONCE for TWO presses
+#   vk=5800 (A)         flags=0001 ... delivered once
+#
+# So a press that leaves the harness is not a press the guest received, and the
+# corpus already knew that for A and B and had not applied it to the d-pad.
+# Fixed: every press in this probe is now confirmed the same way, and the run
+# above shows 2/2 DOWN delivered.
+#
+# ⚠️ REACH. One boot, one round trip, one direction. NOT tested:
+#   * persistence across a full REBOOT -- this is within one boot;
+#   * whether F1 = TUTORIAL here is an initial focus. IT IS NOT: run 1 had
+#     already moved the cursor LOAD GAME -> TUTORIAL with its one delivered
+#     press, and run 2 found it still on TUTORIAL. That is a second, incidental
+#     confirmation of persistence -- across two separate probe processes -- but
+#     it means this run says NOTHING about what the menu opens on.
+#   * whether a longer absence, or a submenu round trip, behaves the same.
+#     (Ⓑ from a submenu restoring the entered-from item is already 4/4.)

docs/re/menu-navigation-semantics.md

@@ -30,6 +30,30 @@ 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 — the menu REMEMBERS its cursor across menu → title → menu
+
+**measured** — [`data/focus-persists-across-title.txt`](data/focus-persists-across-title.txt),
+`tools/re-capture/focus_persistence.py`. One run, control passed:
+
+| step | focus | ring vector |
+|---|---|---|
+| F1, on the menu | `TUTORIAL` | 130 76 **254** 69 64 |
+| F2, after 2× DOWN (**both delivery-confirmed**) | `EXTRAS` | 130 76 66 69 **254** |
+| F3, after Ⓑ → title → Ⓐ → menu | **`EXTRAS`** | 130 76 66 69 **254** |
+
+**F3 == F2, so focus persists** — the menu is re-entered on the item you left,
+not on a fixed one.
+
+📌 **And this reframes the disagreement below rather than settling it.** If focus
+persists, then *any* "initial focus" reading not taken on a fresh boot's **first**
+menu entry is measuring history. The records need not disagree about the game at
+all — they may differ in what the cursor had already been moved to. **Nothing here
+says what the menu opens on**; this run's F1 was itself carried over from a prior
+probe's press.
+
+⚠️ Reach: one boot, one round trip, one direction. Persistence across a **reboot**
+is untested, and is the reading that would matter for authoring a default.
+
 ⚠️ **2026-08-30 — and the sources DISAGREE, which nothing here had noticed.**
 `boot_menu.sh`'s own closing line says *"AT MAIN MENU (cursor on NEW GAME)"*, and
 [`menu-state-in-memory.md`](menu-state-in-memory.md)'s run reaches `EXTRAS` in