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

re: menu focus does not survive a reboot -- six fresh boots, three following a session that ended elsewhere

Browse Source 
No new boot was spent: six runs had already captured the first menu entry of a
fresh boot, and all six read NEW GAME. Three of them follow a session that ended
with the cursor on EXTRAS or OPTIONS, which is what makes it a test of persistence
rather than a repeated observation.

Reach stated rather than implied: every session ends with the emulator KILLED, so a
game that writes menu state on a clean shutdown would never get the chance. This
measures 'does not survive a killed session'.

Refutation attempt on the port's extras/initial_focus: ptbtn11 -- it SURVIVES.
ptbtn11 is the top button on the EXTRAS build, with the main menu as a control
where ptbtn01 is top and is known to be NEW GAME.

Incidentally corrects ring_row.py's stated calibration. It cited capture_y = 49.5 +
1.060*design_y, fitted against menu_focus.py's row centres, which are NOT the
disc's button rows -- the disc says 162/242/322/401/482, spacing 80, and
menu_focus.py drifts up to 17 px against them. Re-fitted: 64.82 + 0.9919*design_y,
residuals under 0.7 px. No item assignment changes.

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:51:03 +00:00
parent 924f16c2a1
commit 1bf619460a
4 changed files with 131 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/re/REFUTED.md
View File

@@ -818,3 +818,22 @@ here, against the **19–20 dB** an unrelated movie gave them. A 0.66 dB thresho
an 8× margin against that floor rather than a 30× one, so **the safety of the
threshold depends on how different the chosen known-negative is**, not on the method.
[data](data/impossibility-scope-sweep.txt)
### Refutation attempt on `sylpheed-port`'s `extras/initial_focus: ptbtn11` — ✅ SURVIVES (2026-08-31)
**Target:** their statement that `EXTRAS` keeps `ptbtn11` and is "correct under the
surviving reading" — i.e. that a submenu resets to the item it opens on, and that
`ptbtn11` is that item.
**My attempt:** the oracle shows `EXTRAS` opening on `MISSION SELECT`, the first of
three. So their value is right only if `ptbtn11` is the **top** button on that
screen. Checked against the disc, with the main menu as a control
(`examples/extras_button_order.rs`):
| | buttons top to bottom |
|---|---|
| **control** — main menu (entry 5) | `ptbtn01` y162, `ptbtn02` y242, `ptbtn03` y322, `ptbtn04` y401, `ptbtn05` y482 → top is `ptbtn01` = `NEW GAME` ✅ |
| `EXTRAS` (entry 6) | `ptbtn11` y282, `ptbtn12` y362, `ptbtn13` y442 → **top is `ptbtn11`** |
**The claim survives**, and the control confirms the ordering rule reproduces a
screen whose answer is independently known.