d768c3ef75
verify-capture's main_menu row said 'rendered with authored initial focus', stale in two ways: the value became measured on 2026-08-31, and nothing had ever established which item THE CAPTURE shows -- an assumption sitting under the port's most-quoted residual. Rendered all five candidates against live-main-menu.png: ptbtn01 13.06, and every alternative 15.96 to 16.59, about 22% worse. The capture shows NEW GAME and the port renders the same state. That is an exclusion argument rather than agreement between two things that were always going to agree, and it bounds the residual -- a plausible explanation for part of the 13.06 is now eliminated rather than untested. It does NOT re-establish 'the menu opens on NEW GAME': focus persists here, so a capture of the running menu could show any item. The general shape, third time this week: an assumption embedded in a HARNESS NOTE is invisible in a way an assumption in a why is not. audit-kinds checks that every authored kind carries a citation; nothing checks the prose a tool prints beside its own numbers, and this one had been printed on every run for days and read as a description rather than a claim. Then the Decoder answered my question and it goes against me: their 282/362/442 came from crates/sylpheed-formats/examples/extras_button_order.rs, calling the same ui_layout::parse_build this port's export uses. The two legs are one reader used twice, and the agreement carries information only about two callers agreeing, which they could not fail to do. Settled by fact rather than by my inference. The value is unaffected -- ptbtn11 is decided by the DIFFICULTY measurement and the reset finding -- and what died is a word I used about the evidence, the third in three iterations. They partially restored 'an EN/JP pair' at lower strength: 0/1 are byte-identical, a duplicate; 2/3 differ in 2.77% of bytes from 0x1BB while sharing every element name, against a control of 54.90% for known-different dialogs. A pair by structure, a language pair by inference, with no ja capture. I am NOT putting it back. Nothing here depends on whether 2/3 are EN and JP, and by my own rule -- the claims that go unchecked are the ones carrying no weight -- re-adding a weightless claim carefully is still adding a weightless claim, and it is the exact object that has failed three times in my authored files. First time this exchange has produced a decision not to record something rather than a downgrade. Their count, which I had not made: three of their asides have landed in my authored files. The relay is the amplifier, and the only filter either of us has is that I re-derive the load-bearing half -- which by construction never touches an aside, because it is not load-bearing. The filter and the failure select for the same property. Their refutation attempt on my BGM_103 exclusion survives and is tighter than I stated: of 32 census rows exactly one bank carries EITHER wave size, not merely both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
Authored decisions
Everything here is a decision we made, not something the disc said. It is
hand-written, committed, and survives a re-export — unlike export/, which is
regenerated wholesale and must never be hand-edited.
Every entry carries a why. When the RE agent decodes the real answer, delete
the entry and let the exporter emit it; that deletion is the measure of
progress.
See docs/FORMAT.md for the schemas and docs/BLOCKED.md for which HANDOFF
question each placeholder is standing in for.