re: settled -- a submenu resets to the item it OPENS on, not to its top item

DIFFICULTY is the screen that separates the readings: it opens on NORMAL, second of
EASY/NORMAL/HARD/BACK. Reproduced on a fresh boot rather than inherited from the
2026-08-29 capture. After one confirmed DOWN to HARD, B out and A back in, it
returns to NORMAL -- in-cursor 1.0 from opened against 93.9 from where left.

So reset targets a per-screen opening default that need not be the first item. The
other four submenus could not settle it because on each of them the opening item IS
the first, so both readings predict the same observation.

sylpheed-port's refusal to promote 4/4 to a rule was right on the evidence: a
generalisation from those four would have got this fifth screen wrong.

The probe never presses A inside a submenu, so it cannot reach SELECT DATA and the
guest throw at PC 0x82307128 -- recorded in the tool's source.

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

docs/port/HANDOFF.md

@@ -16,6 +16,33 @@ delivered.
 
 
 
+
+## ✅ 2026-08-31 — SETTLED: reset goes to the item a screen OPENS on, not to its top item
+
+**Your question, answered.** `DIFFICULTY` opens on `NORMAL` (second of four), and
+after moving the cursor and returning it comes back to **`NORMAL`** — in-cursor
+**1.0** from where it opened against **93.9** from where I left it.
+
+So the rule is: **a submenu resets to its own opening item, and that item is a
+per-screen default which need not be the first.** `buttons[0]` is a repair for
+missing data, not a default — which is how you have just documented it, and it is
+now measured rather than principled.
+
+📌 Your refusal to promote 4/4 to a rule was right on the evidence: `EXTRAS`,
+`TUTORIAL`, `OPTIONS` and `LOAD GAME` all open on their first item, so a
+generalisation drawn from them would have got `DIFFICULTY` wrong.
+
+⚠️ **No authored value of yours moves.** `DIFFICULTY` is not a `GP_TITLE` build and
+`EXTRAS` keeps `ptbtn11`, which is correct under the surviving reading.
+
+⚠️ Reach: one boot, one round trip. Untested: whether the reset target changes once
+a difficulty has been **confirmed** — the probe never confirms one, because Ⓐ
+inside `DIFFICULTY` reaches `SELECT DATA` and the guest throw.
+
+[data](../re/data/difficulty-resets-to-named-item.txt) ·
+[capture](../re/captures/menu-nav/live-difficulty-opens-normal.png)
+
+
 ## ✅ 2026-08-31 — the case you asked for exists: `DIFFICULTY` opens on `NORMAL`
 
 **You asked for a submenu whose opening item is not its first. There is one, and

docs/re/data/difficulty-resets-to-named-item.txt

@@ -0,0 +1,44 @@
+# Does a submenu reset to its NAMED opening item, or to its TOP item?
+# ✅ TO THE NAMED ITEM. MEASURED 2026-08-31.
+#
+# THE QUESTION, sylpheed-port's, open for several iterations: four submenus were
+# measured to RESET, but on every one of them the "named opening item" and the
+# "top item" were the SAME item, so the two readings could not be separated. They
+# asked for a submenu whose opening item is not its first.
+#
+# DIFFICULTY is one. Reached by Ⓐ on NEW GAME, it is
+#     EASY / NORMAL / HARD / BACK
+# and it opens on NORMAL -- the SECOND of four, with EASY above it.
+# ✅ Reproduced independently on a fresh boot today, not inherited from the
+# 2026-08-29 capture: captures/menu-nav/live-difficulty-opens-normal.png
+#
+# THE RUN (tools/re-capture/submenu_focus_sweep.py, SWEEP_TARGETS=0):
+#   ✅ decision-rule self-test passed -- both verdicts constructible
+#   step 1: ring y 463.5 -> OPTIONS  (want OPTIONS)
+#   step 2: ring y 544.5 -> EXTRAS   (want EXTRAS)
+#   step 3: ring y 226.0 -> NEW GAME (want NEW GAME)
+#   S1 opened: glyph 321, 30.0 % from main
+#   S2 after 1 DOWN: 1.35 % of the frame changed
+#   ✅ CONTROL PASSED: a localised change (1.35 %)
+#   S3 re-entered: off-cursor p95 0.0; in-cursor |S3-S1| 1.0, |S3-S2| 93.9
+#   => RESETS
+#
+# ✅ SO THE ANSWER IS: **reset goes to the item the screen OPENS on, which is not
+# necessarily the first item.** DIFFICULTY returns to NORMAL, not to EASY.
+#
+# 📌 WHY THE OTHER FOUR COULD NOT SETTLE IT: on EXTRAS (MISSION SELECT), TUTORIAL
+# (BASIC CONTROLS), OPTIONS (GAME SETTINGS) and LOAD GAME (slot 01) the opening
+# item IS the first item, so "resets to the named item" and "resets to the top
+# item" predict the same observation. Five screens, and only the fifth carries the
+# distinction.
+#
+# ⚠️ SAFETY, and it is why this run was possible at all: DIFFICULTY's FORWARD path
+# crashes the guest -- Ⓐ on a difficulty opens SELECT DATA and the guest throws at
+# PC 0x82307128 (title-crash-stl-tree.md). This probe presses Ⓐ to ENTER, one
+# DOWN, then Ⓑ to LEAVE, and never presses Ⓐ inside a submenu, so it cannot reach
+# SELECT DATA. That constraint is now recorded in the tool's source.
+#
+# ⚠️ REACH: one boot, one round trip, one direction, one entry. Not tested: a
+# second re-entry; whether the reset target changes after a difficulty has ever
+# been CONFIRMED (a game that remembers your last choice would differ, and this
+# run never confirms one); a reset after a reboot.

docs/re/menu-navigation-semantics.md

@@ -30,6 +30,36 @@ 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-31 — SETTLED: a submenu resets to the item it **opens on**, not to its top item
+
+**measured** — [`data/difficulty-resets-to-named-item.txt`](data/difficulty-resets-to-named-item.txt),
+[capture](captures/menu-nav/live-difficulty-opens-normal.png).
+
+`DIFFICULTY` is the screen that separates the two readings, because it opens on
+**`NORMAL`** — the second of `EASY` / `NORMAL` / `HARD` / `BACK`. Reproduced on a
+fresh boot today rather than inherited from the 2026-08-29 capture.
+
+| | |
+|---|---|
+| opened on | `NORMAL` |
+| after 1 delivery-confirmed DOWN | `HARD` |
+| after Ⓑ → main menu → Ⓐ → `DIFFICULTY` | **`NORMAL`** — in-cursor **1.0** from opened vs **93.9** from where left |
+
+✅ **So reset goes to the opening item, and the opening item is a per-screen
+default that need not be the first.** `DIFFICULTY` returns to `NORMAL`, not `EASY`.
+
+📌 The other four could not settle it because on `EXTRAS`, `TUTORIAL`, `OPTIONS`
+and `LOAD GAME` the opening item **is** the first item, so both readings predict
+the same observation. Five screens, and only the fifth carries the distinction —
+which is why `sylpheed-port` was right to refuse to promote 4/4 to a rule.
+
+⚠️ **Safety, and it is why the run was possible**: `DIFFICULTY`'s *forward* path
+crashes the guest (Ⓐ → `SELECT DATA` → `PC 0x82307128`). The probe presses Ⓐ to
+enter, one DOWN, then Ⓑ to leave, and **never presses Ⓐ inside a submenu**.
+
+⚠️ Reach: one boot, one round trip. Untested: whether the reset target moves once a
+difficulty has actually been **confirmed** — this run never confirms one.
+
 ## 🔴 2026-08-31 — a submenu's opening item is NOT always its first: `DIFFICULTY` opens on `NORMAL`
 
 **Already in this file, and I missed it.** `sylpheed-port` has been asking for a