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

port: the counter-example I kept asking for was in a file I wrote

Browse Source 
For several iterations I said the MISSION-SELECT-versus-top-item ambiguity needed
a screen whose opening item is not its first, and that none was known. The Decoder
found one and reported it had been sitting unconnected in their corpus.

It is in mine too, and I authored it. authored/flow.json under
main_menu/buttons/ptbtn01 has read since eef45ec on 2026-08-29: 'MEASURED
destination (EASY/NORMAL/HARD/BACK, opening on NORMAL, then SELECT DATA)'.
DIFFICULTY opens on the second of four. So 'a screen opens on its first item' is
refuted as a general description of this game, and on EXTRAS, TUTORIAL and OPTIONS
the named item and the top item coincide by accident.

Worse than an index failing to amplify: my extras/initial_focus_why framed the
ambiguity as conditional -- 'it matters IF another screen is ever authored' -- in
the same file that already recorded such a screen. Future tense over a fact twelve
keys away. Corrected to name DIFFICULTY concretely.

MenuFlow.initial_focus's buttons[0] fallback is now documented as a repair for
broken data rather than a default, and that is measured rather than fastidious: if
a screen reaches that line silently the port shows a top-item default for a game
that does not always have one. No authored value moves -- DIFFICULTY is not a
GP_TITLE build and EXTRAS keeps ptbtn11, correct under either reading. Walk re-run
unchanged.

It does not settle the question, which is about reset rather than opening. That
needs the cursor moved inside DIFFICULTY, left and re-entered, and its forward
path crashes the guest at SELECT DATA so the run must go back rather than on.

No checker either of us has built would have caught this. Every instrument here
verifies that a claim matches a value; nothing detects that an answer already
written down is not being connected to the question it answers -- and mine had
both halves in one file.

It also makes the previous iteration's restraint look better: declining to promote
'4/4 submenus reset' to a rule was argued from the principle that a generalisation
should not pre-decide the next screen, and the next screen turns out to be one the
generalisation would have got wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-31 01:37:30 +00:00
parent d1a1633619
commit ca7dd583d5
4 changed files with 78 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
port/scripts/menu_flow.gd
View File

@@ -65,6 +65,17 @@ func focus() -> String:
## the first button rather than to nothing, and SAY SO: a menu that opens with
## no focus looks like a rendering bug, and this is the one place that mistake
## would hide.
##
## 🔴 THE FALLBACK IS A REPAIR, NOT A DEFAULT, and since 2026-08-31 that is
## measured rather than fastidious. `DIFFICULTY` -- EASY/NORMAL/HARD/BACK --
## opens on **NORMAL, the second of four**, so "a screen opens on its first item"
## is refuted as a description of this game. On `EXTRAS`, `TUTORIAL` and
## `OPTIONS` the named item and the top item coincide by accident.
##
## So `buttons[0]` here is what to draw when the DATA IS BROKEN, and it warns
## precisely because it is not a claim about the game. If a screen ever reaches
## this line silently, the port will be showing a top-item default for a game
## that does not always have one.
func initial_focus(name: String, buttons: Array) -> String:
if buttons.is_empty():
return ""