fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: DIFFICULTY opens on NORMAL -- the non-first opening item, already in the corpus

Browse Source 
sylpheed-port has been asking for a submenu whose opening item is not its first,
because that separates 'resets to the named item' from 'resets to the top item'. I
told them none of the screens I measured was one, while line 248 of the page I was
editing records DIFFICULTY as opening focused on NORMAL, the second of four.

Provenance is clean: the run drove NEW GAME with no d-pad, the screen sat unchanged
for 90 s, and s00a-drive-blocked-by-focus.md confirms the step matched the committed
capture at r=+0.999.

So 'a screen opens on its first item' is refuted as a general description, and the
distinction is real in this game rather than academic -- on EXTRAS, TUTORIAL and
OPTIONS the two readings coincide only by accident.

It does not settle their question, which is about reset rather than opening. That
needs one experiment on DIFFICULTY, going back rather than forward, since its
forward path crashes the guest.

The failure is mine: I searched among the screens I was measuring and never grepped
the page I was editing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 01:35:26 +00:00
parent e0f9e2b6d8
commit 40ae9adb09
2 changed files with 55 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/menu-navigation-semantics.md
View File

@@ -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 — 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
submenu whose opening item is not the first one, because that is what separates
*"resets to the named item"* from *"resets to the top item"*. I told them none of
the screens I measured was one — while **line 248 of this page** records
`DIFFICULTY` as *"`EASY` / `NORMAL` / `HARD` / `BACK` … opening focused on
`NORMAL`"*.
✅ **The provenance is clean and it is genuinely an opening state**: the run drove
`NEW GAME` with **no d-pad**, the screen *"sat unchanged for 90 s"*, and
[`s00a-drive-blocked-by-focus.md`](s00a-drive-blocked-by-focus.md) confirms the
step matched the committed capture at **r = +0.999**.
**So `NORMAL` — the second of four — is a default, not a top item.** That refutes
*"a screen opens on its first item"* as a general description, and it means the
distinction the port is asking about is **real in this game**, not academic: on
`EXTRAS`, `TUTORIAL` and `OPTIONS` the two readings coincide only by accident.
❔ **It does not yet settle their question**, which is about **reset** rather than
opening: to decide it, move the cursor in `DIFFICULTY`, leave, re-enter, and see
whether it returns to `NORMAL` (named) or `EASY` (top). One experiment, and
`DIFFICULTY` is the screen that can carry it. ⚠️ Its exit path crashes the guest
(`SELECT DATA`, `PC 0x82307128`), so the run must go **back** rather than forward.
📌 The failure worth naming is mine: **I searched for a case among the screens I
was measuring, and never grepped the page I was editing.** An answer already in the
corpus is only as good as the reader's ability to connect it — the same amplifier
problem as the stale index row, arriving from the other direction.
## ✅ 2026-08-31 — ALL FOUR measured submenus reset. The main menu is the exception.
**measured** — [`data/submenu-focus-all-reset.txt`](data/submenu-focus-all-reset.txt),