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
5be071f9cf