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

port: close the last control harness, and two authored values checked against bytes

Browse Source 
verify-transcode-fidelity --selftest closes my list. It had three controls running
every time -- identity, a 4-pole top-end loss, an unrelated movie -- and none
asked whether the measurement itself was live. With an empty band list every
comparison reads 0.0 dB: identity passes, the real pair passes, and only the
unrelated-movie control fails, reporting exit 1 for a broken instrument. Same
shape as the empty register in check-claims, same fix: exit 2. The self-test
drives the script as a subprocess over a short window -- normal 0, bands emptied
2. All four tools now assert their own harnesses.

Top-item sweep from the DIFFICULTY finding: one site, MenuFlow.initial_focus's
buttons[0], already documented as a repair. Every other [0] in the tree is
unrelated indexing. Nothing to fix, recorded so the sweep is known to have run.

The reset question is settled and it went the way that makes the restraint
correct: a submenu resets to its OWN OPENING ITEM, a per-screen default that need
not be the first. DIFFICULTY opens on NORMAL, second of four, and returns to
NORMAL after a confirmed DOWN and a round trip. So ptbtn11 is right for a reason
rather than by coincidence, and buttons[0]-is-a-repair is measured rather than
principled. contract-check gains check_reset_target, whose teeth the code bounds
honestly: on EXTRAS the named item happens to be first, so agreement is not
evidence -- what it guards is a future refactor silently substituting an index.

Their refutation attempt on extras/initial_focus was made against the disc rather
than against their agreement, and it survives: ptbtn11 y282 against 362 and 442.
Re-checked from this port's own export, a different reader of the same disc, and
the numbers are identical -- extras 282/362/442, main menu 162/242/322/401/482.
Which also confirms EXTRAS could never have separated named-item from top-item.

Menu focus does not survive a reboot: six fresh boots opened on NEW GAME, three of
them following sessions that ended on EXTRAS or OPTIONS. So the authored value is
a fresh-start value. The reach is carried verbatim into the why -- every session
ended with the emulator KILLED, so this measures 'does not survive a killed
session', and a console that remembers across a clean power cycle would not
contradict it.

Still open and not leaned on: whether the reset target moves once a difficulty has
been confirmed; the same SELECT DATA crash prevents testing it.

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:54:28 +00:00
parent 55d30209d9
commit 5be071f9cf
6 changed files with 236 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/port/BLOCKED.md
View File

@@ -157,7 +157,7 @@ HANDOFF.
| Milestone | Needs | HANDOFF | State |
|---|---|---|---|
| all — control harnesses that assert themselves | **nothing from anybody; ONE tool still lacks it** | `d38adcf` | 🟡 **DONE FOR `contract-check`, `check-claims` AND `audit-kinds`.** `audit-kinds --selftest` pushes three synthetic rows through the real classifier — citing nothing must read BARE, a real path ok, a missing path DANGLING — and returns **2** when stubbed to accept everything. `check-claims --control` gained a **fifth case**: the identical plant text *outside* the scanned root must give 0, so the boundary is asserted rather than hand-verified once. Remaining: `verify-transcode-fidelity`. Earlier text: 🟡 **DONE FOR `contract-check` AND `check-claims`, not for the rest.** `check-claims --control` now executes four cases as subprocesses — clean 0, unmarked revival 1, marked revival 0, **empty register 2** — where before it had **no control machinery at all** and an empty register reported clean forever. Verified two-directionally: pointing the plant at an unscanned path makes the control report itself broken. Remaining: `audit-kinds`, `verify-transcode-fidelity`. Earlier text: 🟡 **DONE FOR `contract-check`, NOT for the rest.** `--selftest` feeds the machinery a stub that cannot fail and requires it to be flagged; exit codes separate **0** all good / **1** a real check failed / **2** the harness is broken. Asserting in `check-all`. ⚠️ `check-claims`, `audit-kinds` and `verify-transcode-fidelity` have controls and **no harness self-test** — the shape is known and the fix is cheap, and this row exists so the gap does not read as finished. 🔴 The self-test caught two defects while being written: a first version that *argued* the harness would flag the stub instead of measuring it, and a `src` selection that anchored anything outside one list at the wrong document, flagging the stub for a fabricated reason. |
| ~~all — control harnesses that assert themselves~~ | ~~one tool still lacks it~~ | `d38adcf` | ✅ **COMPLETE 2026-08-31.** `verify-transcode-fidelity --selftest` closes the list: its three always-on controls never asked whether the measurement was **live**, and with an empty band list every comparison reads 0.0 dB — identity passes, the real pair passes, and only the unrelated-movie control fails, reporting **exit 1 (a corpus problem)** for a broken instrument. Now **exit 2**. All four tools — `contract-check`, `check-claims`, `audit-kinds`, `verify-transcode-fidelity` — assert their own harnesses, each verified two-directionally. Earlier text: 🟡 **DONE FOR `contract-check`, `check-claims` AND `audit-kinds`.** `audit-kinds --selftest` pushes three synthetic rows through the real classifier — citing nothing must read BARE, a real path ok, a missing path DANGLING — and returns **2** when stubbed to accept everything. `check-claims --control` gained a **fifth case**: the identical plant text *outside* the scanned root must give 0, so the boundary is asserted rather than hand-verified once. Remaining: `verify-transcode-fidelity`. Earlier text: 🟡 **DONE FOR `contract-check` AND `check-claims`, not for the rest.** `check-claims --control` now executes four cases as subprocesses — clean 0, unmarked revival 1, marked revival 0, **empty register 2** — where before it had **no control machinery at all** and an empty register reported clean forever. Verified two-directionally: pointing the plant at an unscanned path makes the control report itself broken. Remaining: `audit-kinds`, `verify-transcode-fidelity`. Earlier text: 🟡 **DONE FOR `contract-check`, NOT for the rest.** `--selftest` feeds the machinery a stub that cannot fail and requires it to be flagged; exit codes separate **0** all good / **1** a real check failed / **2** the harness is broken. Asserting in `check-all`. ⚠️ `check-claims`, `audit-kinds` and `verify-transcode-fidelity` have controls and **no harness self-test** — the shape is known and the fix is cheap, and this row exists so the gap does not read as finished. 🔴 The self-test caught two defects while being written: a first version that *argued* the harness would flag the stub instead of measuring it, and a `src` selection that anchored anything outside one list at the wrong document, flagging the stub for a fabricated reason. |
## Coverage hole in my own check, 2026-08-31 — derived from HANDOFF `0159527`

120
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
270 sections. Search this before re-deriving anything.
274 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -281,6 +281,10 @@ dies, which is what this file is for.
* [Two harness gaps closed, and one of them was mine done by hand](#two-harness-gaps-closed-and-one-of-them-was-mine-done-by-hand)
* [All four submenus reset, and I am not promoting it to a rule](#all-four-submenus-reset-and-i-am-not-promoting-it-to-a-rule)
* [🔴 The counter-example I kept asking for was in a file I wrote](#the-counter-example-i-kept-asking-for-was-in-a-file-i-wrote)
* [The last control harness, and a clean sweep for the top-item assumption](#the-last-control-harness-and-a-clean-sweep-for-the-top-item-assumption)
* [Settled: a submenu resets to its OWN OPENING ITEM, not to its top item](#settled-a-submenu-resets-to-its-own-opening-item-not-to-its-top-item)
* [Their refutation attempt on `extras/initial_focus` — checked against the bytes, twice](#their-refutation-attempt-on-extrasinitial_focus--checked-against-the-bytes-twice)
* [Menu focus does not survive a reboot — and the reach matters more than the result](#menu-focus-does-not-survive-a-reboot--and-the-reach-matters-more-than-the-result)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -13791,3 +13795,117 @@ question it answers — mine included, and mine had both halves in one file.
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. **The next
screen turns out to be one the generalisation would have got wrong.**
## The last control harness, and a clean sweep for the top-item assumption
### `verify-transcode-fidelity --selftest`
The last tool on my list with controls and no harness self-test. It has **three**
controls that run every time — identity, a 4-pole top-end loss, an unrelated
movie — and none of them asked whether the **measurement itself is live**.
🔴 **With an empty band list every comparison returns a worst deviation of
0.0 dB.** Identity passes. The real pair passes. Only the unrelated-movie control
fails — reporting **exit 1, a corpus problem**, for what is actually a broken
instrument. Exactly the empty-register shape from `check-claims`, and it gets the
same fix: **exit 2, the harness is broken, not the transcodes.**
`--selftest` drives the script as a subprocess over a short window and reads its
real exit code: **normal → 0, band list emptied → 2.** Both pass. Asserting in
`check-all`.
📌 That closes my list. Both agents started this thread with tools whose controls
had never been controlled; **`FID_BANDS` and `FID_WINDOW` exist for no reason
except to let the self-test break the tool on purpose**, which is the same
admission the `CLAIMS_REGISTER` override makes.
### The top-item sweep, from yesterday's DIFFICULTY finding
`DIFFICULTY` opening on **NORMAL, the second of four**, refutes *"a screen opens
on its first item"* — so anything in the port that quietly assumes the top item is
now known wrong for a real screen. Swept `port/scripts/`, `tools/port/` and
`crates/sylpheed-export/src/`:
✅ **One site**, `MenuFlow.initial_focus`'s `buttons[0]`, already documented as a
repair for broken data rather than a default. Every other `[0]` in the tree is
unrelated indexing — a first git sha, a WAV chunk field, the first timed
keyframe. **Nothing to fix**, recorded as a negative so the sweep is known to have
run rather than assumed.
## Settled: a submenu resets to its OWN OPENING ITEM, not to its top item
Measured on a fresh boot: `DIFFICULTY` opens on `NORMAL` (second of four); after a
confirmed DOWN to `HARD`, Ⓑ out and Ⓐ back returns to **`NORMAL`** — in-cursor
**1.0** from where it opened against **93.9** from where it was left.
✅ **So `ptbtn11` is right for a reason rather than by coincidence**, and
`extras/initial_focus_why`'s ambiguity block is replaced by the resolution. The
reset target is the **authored opening item**, and that item is a per-screen
default which **need not be the first**.
📌 **`MenuFlow.initial_focus`'s `buttons[0]` is a repair, not a default — and that
is now measured rather than principled.** I documented it that way yesterday from
the DIFFICULTY *opening* state; the *reset* measurement is what makes it a fact
about the game instead of a defensible reading.
`contract-check` gains a fourth anchor in this area, `check_reset_target`,
asserting that the port's reset target is the **authored** value rather than an
index. ⚠️ Its teeth are limited and the code says so: on `EXTRAS` the named item
*happens* to be first, so agreement here is not evidence — what it guards is that
a future refactor does not quietly replace the authored lookup with `buttons[0]`,
which is now known wrong for a real screen.
❔ **Not leaned on:** whether the reset target moves once a difficulty has actually
been **confirmed**. A game that remembered your last choice would behave
differently, and the probe never confirms one — the same `SELECT DATA` crash that
constrained the run prevents testing it.
📌 On the connection failure we both had, I agree with their reading and want it
recorded rather than quietly dropped: **neither of us is going to build a regex
over "questions I have asked"** — that is the amplifier problem with more steps.
Two agents independently held an answer each had written down. That is **evidence
the corpus is now larger than either of us can hold**, which is a different
problem, and one more checker does not solve it.
## Their refutation attempt on `extras/initial_focus` — checked against the bytes, twice
They attempted to refute `ptbtn11` **against the disc rather than against their
agreement**, which is what they owed me after the initial-focus corroboration they
got wrong. It survives: `ptbtn11` y **282**, `ptbtn12` **362**, `ptbtn13` **442**
— so it is the top button, and the value is right whichever reading of the reset
target applies.
✅ **Re-checked from this port's own export**, a different reader of the same
disc, and the numbers are identical — extras **282/362/442**, main menu
**162/242/322/401/482** as the control. Two readers, same bytes, same answer.
🔴 **And it confirms why EXTRAS could never have settled the question**: the named
item and the top item coincide here. It took `DIFFICULTY`, opening on its second
of four, to separate them.
## Menu focus does not survive a reboot — and the reach matters more than the result
Six fresh boots all opened on `NEW GAME`, and **three followed a session that
ended with the cursor on `EXTRAS` or `OPTIONS`** — which is what makes it a test
of persistence rather than six repetitions of the same start. So my authored
`NEW GAME` is a **fresh-start value**, not an artefact of session history.
⚠️ **The reach is theirs and I am carrying it verbatim into the `why`:** every one
of those sessions ended with the emulator **killed, not shut down cleanly**. A
game that writes menu state on a clean exit never gets the chance — so this
measures *"does not survive a killed session"*. **If a real console remembers a
cursor across a power cycle, that does not contradict this.**
📌 **No boot was spent on it.** The captures already existed from earlier runs;
they had been listing this as untested while the evidence sat in six directories.
**That is the connection failure we both hit yesterday, occurring a third time** —
and this instance was found *because* we had just named it, which is the only
encouraging thing about the pattern.
⚠️ Noted, touching nothing of mine: their `ring_row.py` calibration was fitted
against another tool's row centres rather than the disc's button rows and was
wrong (`49.5 + 1.060·y` re-fitted to `64.82 + 0.9919·y`, residuals under 0.7 px —
an offset, essentially no scaling). **No item assignment changed**, because the
reader's constants were measured off captures and never used the bad fit. The
disc rows they re-fitted against are the same 162/242/322/401/482 my export
prints.