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
e2b5e54fb7