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

port: an authored value becomes measured, and a difference-only check gets an origin

Browse Source 
The Decoder corrected their own focus delivery: the persistence run's item names
were two positions out, from a reader using design-space rows against captures
carrying Xenia's chrome and a 1.060 scale. Two things follow.

initial_focus_kind moves from authored to measured. NEW GAME on a fresh boot, 2/2
fresh boots, both the first menu entry. The value did not change; its standing
did, and the upgrade is not because the measurement agrees with me -- they had
said my agreeing with their records was no evidence, which was correct, and this
is a direct reading independent of the reasoning that chose NEW GAME here. "First
entry" is load-bearing: since the menu remembers its cursor, a reading taken
later measures history, which is the objection that voided the earlier
TUTORIAL-versus-NEW-GAME disagreement. The superseded reasoning is kept under
(was) lines -- the field existing and being labelled honestly is what made
arriving at a measurement a label change rather than an archaeology problem, the
third time that has paid off after loop_start_s and the +0x08 read.

My check_focus_persists anchor survived a correction it should not have been able
to detect. It anchors on the heading, the conclusion, not on the item names. That
is lucky rather than designed: the conclusion is geometry-free -- ring at y 384.0
before the round trip and 385.5 after, an equality immune to a constant offset --
while the names were not. The check would not have caught the label error, and
nothing in it distinguishes anchored-on-a-robust-claim from anchored-above-the-
part-that-was-wrong.

Their generalisation: a control that only checks differences is blind to the
origin. check_splash_dwell is that shape -- it compares the widest gap between
keyframe times, and a reader with every time shifted by a constant passes. Added
check_splash_times, asserting the absolute list the contract prints. Origin and
difference now fail independently.

Writing that control reproduced the error one level down: its perturbation
literal was written from memory of the prose, with a space where the document has
a newline, so it reported its own anchor gone. A control written from a memory of
the source rather than from the source is the class of error these checks exist
to catch. Thirteen controls, all firing.

Q2 closed: fixed same day, and the row was worse than I reported -- the splashes
were also mis-paired as 10/11, one half each of two different pairs.

EXTRAS remains unmeasured; the run meant to settle it navigated to OPTIONS
believing it was EXTRAS. Every asserting check passes.

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-30 22:03:58 +00:00
parent 90025a3e44
commit 5ff278a5ca
4 changed files with 141 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
authored/flow.json
View File

@@ -137,7 +137,7 @@
},
"main_menu": {
"initial_focus": "ptbtn01",
"initial_focus_kind": "authored",
"initial_focus_kind": "measured",
"focus_persists": true,
"focus_persists_kind": "measured",
"focus_persists_why": [
@@ -180,19 +180,40 @@
"non-persistence half until it returns."
],
"initial_focus_why": [
"AUTHORED, standing in for HANDOFF Q5, which measured that initial focus is NOT STABLE: four boots of the same harness opened on TUTORIAL, TUTORIAL, NEW GAME, NEW GAME. A port has to open on something. ptbtn01 (NEW GAME) is picked because it is one of the two states actually observed and it is the top item, so a reader can predict it. It is a CHOICE. Delete this the day the RE agent finds what selects it. CORROBORATED 2026-08-29, and still not decoded: the committed capture live-main-menu.png has NEW GAME focused. Identified by rendering all five focus states and taking the minimum difference -- 531 differing pixels against 6080-7094 for the others, an 11.5x margin -- with the method controlled on live-main-menu-options-focused.png, whose answer is in its filename and which it picks by 4.7x. That means the port's choice matches the state of one committed frame. It does NOT make focus stable: Q5's four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME, and this identifies one frame rather than a rule. Delete this entry the day something says what SELECTS it. TIGHTENED 2026-08-29: Q5 now has SIX boots, and the shape is sharper than 'unstable' -- TUTORIAL x3, NEW GAME x3, and NO OTHER ITEM EVER OBSERVED. So it is not uniform over five buttons; whatever selects it has to explain a two-way split. That does not change this choice (NEW GAME remains one of exactly two observed states, and it is the state of the committed capture) but it does change what would REFUTE it: a boot opening on LOAD GAME, OPTIONS or EXTRAS would break the two-way shape, and a rule that predicts the split would delete this entry outright.",
"MEASURED 2026-08-30 (later) -- `NEW GAME` on a fresh boot, 2/2 fresh boots,",
"both the FIRST menu entry. Decoder, HANDOFF `bf9e07f`, section \"correcting",
"today's focus delivery\"; ring row y=225.5 against a measured 79.25 px step,",
"data in docs/re/data/menu-focus-reader-offset.txt.",
"",
"✅ CONSISTENT WITH THE ONE CAPTURE, measured 2026-08-30. Rendering each of the",
"five buttons focused against `live-main-menu.png` gives 0.0705 % for ptbtn01",
"and 0.72-0.84 % for the other four -- a 10x discrimination. So that capture",
"shows NEW GAME focused, and the authored choice matches it.",
"🔴 THIS FIELD WAS `authored` UNTIL NOW AND THE UPGRADE IS NOT BECAUSE IT",
"AGREES WITH ME. The value did not change; its standing did. The confirmation",
"is a direct reading of a fresh boot's first menu entry, independent of the",
"reasoning that chose NEW GAME here -- and the Decoder had said explicitly that",
"my agreeing with their records was no evidence, which was correct at the time.",
"",
"⚠️ THIS DOES NOT OVERTURN Q5. Q5 measured initial focus as UNSTABLE across",
"four boots; one capture showing ptbtn01 is consistent with that and does not",
"contradict it. What the measurement establishes is narrower and still worth",
"having: the port's focus rendering is distinctive enough that a capture",
"identifies which button is focused, and this authored value is not at odds",
"with the only frame we can check it against. It stays AUTHORED."
"⚠️ WHY 'FIRST ENTRY' IS LOAD-BEARING: the menu REMEMBERS ITS CURSOR (see",
"`focus_persists`), so any reading not taken on a fresh boot's first entry is",
"measuring HISTORY, not what the screen opens on. That objection is what",
"invalidated the earlier TUTORIAL/NEW GAME disagreement, and this measurement",
"is the one that is immune to it.",
"",
"The superseded reasoning is kept below, because it is what made the wait cheap:",
"the field existed and was labelled honestly, so arriving at a measurement was a",
"label change and not an archaeology problem.",
"",
" (was) AUTHORED, standing in for HANDOFF Q5, which measured that initial focus is NOT STABLE: four boots of the same harness opened on TUTORIAL, TUTORIAL, NEW GAME, NEW GAME. A port has to open on something. ptbtn01 (NEW GAME) is picked because it is one of the two states actually observed and it is the top item, so a reader can predict it. It is a CHOICE. Delete this the day the RE agent finds what selects it. CORROBORATED 2026-08-29, and still not decoded: the committed capture live-main-menu.png has NEW GAME focused. Identified by rendering all five focus states and taking the minimum difference -- 531 differing pixels against 6080-7094 for the others, an 11.5x margin -- with the method controlled on live-main-menu-options-focused.png, whose answer is in its filename and which it picks by 4.7x. That means the port's choice matches the state of one committed frame. It does NOT make focus stable: Q5's four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME, and this identifies one frame rather than a rule. Delete this entry the day something says what SELECTS it. TIGHTENED 2026-08-29: Q5 now has SIX boots, and the shape is sharper than 'unstable' -- TUTORIAL x3, NEW GAME x3, and NO OTHER ITEM EVER OBSERVED. So it is not uniform over five buttons; whatever selects it has to explain a two-way split. That does not change this choice (NEW GAME remains one of exactly two observed states, and it is the state of the committed capture) but it does change what would REFUTE it: a boot opening on LOAD GAME, OPTIONS or EXTRAS would break the two-way shape, and a rule that predicts the split would delete this entry outright.",
" (was) ",
" (was) ✅ CONSISTENT WITH THE ONE CAPTURE, measured 2026-08-30. Rendering each of the",
" (was) five buttons focused against `live-main-menu.png` gives 0.0705 % for ptbtn01",
" (was) and 0.72-0.84 % for the other four -- a 10x discrimination. So that capture",
" (was) shows NEW GAME focused, and the authored choice matches it.",
" (was) ",
" (was) ⚠️ THIS DOES NOT OVERTURN Q5. Q5 measured initial focus as UNSTABLE across",
" (was) four boots; one capture showing ptbtn01 is consistent with that and does not",
" (was) contradict it. What the measurement establishes is narrower and still worth",
" (was) having: the port's focus rendering is distinctive enough that a capture",
" (was) identifies which button is focused, and this authored value is not at odds",
" (was) with the only frame we can check it against. It stays AUTHORED."
],
"on_cancel": {
"goto": "title",