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

port: the capture has NEW GAME focused, and my harness had been rendering no focus

Browse Source 
The Decoder attached an honest caveat to its reproduction of the tone-curve
refutation -- its bins included the focus-state mismatch, so it was "not a clean
second opinion". Removing that caveat found a defect of mine.

IDENTIFYING THE FOCUSED BUTTON, with a known-answer control. Walking focus
through all five buttons and comparing each against a capture:

                    vs -options-focused    vs live-main-menu
  ptbtn01 NEW GAME        6351                   531
  ptbtn02 LOAD GAME       7087                  7094
  ptbtn03 TUTORIAL        6230                  6237
  ptbtn04 OPTIONS         1292                  6364
  ptbtn05 EXTRAS          6073                  6080

The control picks OPTIONS by 4.7x -- the answer its own filename gives -- so the
test is trustworthy, and live-main-menu.png has NEW GAME focused by 11.5x. That
is what the port already focuses. Corroboration, NOT a decode: Q5's instability
stands (four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME) and this
identifies one frame rather than a rule. Recorded in the authored entry.

THE DEFECT: `verify-capture` rendered menus with `--screen=`, which draws no
focus record, so it had been comparing main_menu to the oracle in a state the
oracle was never in.

  main_menu  0.25% differing, RMSE 14.79  ->  0.06%, RMSE 13.21
  extras     0.46%, RMSE 15.29            ->  0.20%, RMSE 13.38

A 4x improvement that was entirely my harness posing the port wrong rather than
the port drawing wrong. The first run of a new correctness harness reported a
discrepancy and three quarters of it was the harness.

AND THE DECODER'S CAVEAT RESOLVES TO NOTHING, measured rather than assumed:
re-deriving the transfer curve on the correctly-posed pair gives 1.20 / 1.26 /
1.18 / 1.10 / 1.03 / 0.94 at render 8..48, unchanged from the mismatched run. Its
reproduction stands as a second opinion after all.

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-29 17:23:27 +00:00
parent ca23a5479a
commit 4e249d9d63
3 changed files with 267 additions and 196 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
docs/port/DECISIONS.md
View File

@@ -3748,3 +3748,59 @@ extrapolating past a reach the measurement's own authors had written down.
**Extrapolating a measurement past its stated reach is how this tool got it wrong
twice**, and the answer was not a better fit but a different instrument: a table
somebody can argue with.
## Identifying the capture's focused button — and my harness was posing the port wrong
The Decoder attached an honest caveat to its reproduction of the tone-curve
refutation: its bins included the focus-state mismatch, so it was *"not a clean
second opinion"*. That is removable, and removing it found a defect of mine.
### The method, with a known-answer control
`--menu=main_menu --script=down,down,down,down` walks focus through all five
buttons and shoots each. Compare every one against a capture; the minimum
identifies the focused button. **The control is the capture whose answer is in
its own filename:**
| render focus | vs `live-main-menu-options-focused` | vs `live-main-menu` |
|---|---|---|
| `ptbtn01` NEW GAME | 6 351 | **531** |
| `ptbtn02` LOAD GAME | 7 087 | 7 094 |
| `ptbtn03` TUTORIAL | 6 230 | 6 237 |
| `ptbtn04` OPTIONS | **1 292** | 6 364 |
| `ptbtn05` EXTRAS | 6 073 | 6 080 |
✅ **The control picks `OPTIONS`, by 4.7×** — the answer the filename gives.
✅ **So the test is trustworthy, and `live-main-menu.png` has NEW GAME focused, by
11.5×.**
**Which is what the port already focuses.** `authored/flow.json`'s
`initial_focus: ptbtn01` was chosen because HANDOFF Q5 measured focus as
*unstable* across boots — four boots gave TUTORIAL, TUTORIAL, NEW GAME, NEW GAME
— and it is one of the two observed states. It is now also the state of the
committed capture. ⚠️ That is corroboration, **not** a decode: Q5's instability
stands, and this identifies one frame rather than a rule.
### The defect: `verify-capture` rendered menus with no focus at all
`--screen=` draws no focus record, so the harness had been comparing `main_menu`
to the oracle **in a state the oracle was never in**. Rendered properly, with
`--menu=`:
| | before | after |
|---|---|---|
| `main_menu` | 0.25 % differing, RMSE 14.79 | **0.06 %**, RMSE 13.21 |
| `extras` | 0.46 %, RMSE 15.29 | **0.20 %**, RMSE 13.38 |
A 4× improvement on `main_menu` that was **entirely my harness posing the port
wrong**, not the port drawing wrong. Worth stating plainly: the first run of a
new correctness harness reported a discrepancy, and three quarters of it was the
harness.
### And the Decoder's caveat resolves to nothing — measured, not assumed
Re-deriving the transfer curve on the correctly-posed pair gives 1.20 / 1.26 /
1.18 / 1.10 / 1.03 / 0.94 at render 8…48 — **unchanged** from the mismatched run.
So the focus-state contamination it flagged really did not move the trend. Its
reproduction stands as a second opinion after all, and that is now a measurement
rather than a hope.