Last iteration I overturned check-all's allowance on a measurement of 0 pixels
between the two decoder eras, and rewrote the tool's reason around it. The two
binaries had the same md5: one built in a worktree at formats-pin-2026-08-30 and
one from the workspace, and both commits carry the record-layout fix. I compared a
binary with itself and reported the zero as evidence. The 508-line diff I cited
was real and irrelevant -- it does not straddle the fix.
Done properly against origin/main, verified stale by the Decoder's own control
(rest t=70 vs rest t=12) and by differing md5s: title 0 px, main_menu 0 px,
title_jp 74507 px -- reproducing their figure exactly, under their flags and mine.
My second hypothesis, that --animated masked it, was also wrong.
What survives: the era still cannot explain this script's rows, for a fact I had
not established -- both sides of the comparison are the FIXED era, since a binary
built from the pin and one from the workspace have the same md5. Right answer,
wrong evidence. The note now carries its condition: title_jp is era-sensitive, so
if the reference is ever built from a different era than the pin, that row's cause
changes.
Twice now a correct conclusion has come through a broken experiment, and both
times the tell was two things that should differ producing identical output.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
The suite reported '2 DIFFERS, allowed: the pin is not on main, so this compares
two decoder eras', and I had quoted that for several iterations without testing
it. Built sylpheed-cli at formats-pin-2026-08-30 and at workspace HEAD and
rendered through both: title, title_jp and main_menu come out 0 pixels different,
despite 508 lines of difference in ui_layout.rs. The eras are not the cause, and
the allowance was excusing a real signal with a wrong explanation.
A second defect in the same eight lines: the expiry tested formats-pin-2026-08-29d
while Cargo.toml pins formats-pin-2026-08-30, so it would have expired on a tag
this tree does not use.
The real reasons are per-screen and already documented: title is the ptloop sweep
phase residual, title_jp is the --pose=rest sparkle handling -- where the port's
shipped pose scores +0.9994 against the game to the reference's +0.8727, so the
port is closer to the game on the row the script calls a disagreement.
Replaced with a named set: title and title_jp by name, any other DIFFERS fails.
A count cannot notice a different screen drifting while the total stays at two.
Controlled both directions -- passes on the known pair, fails on main_menu or
extras. The pin reminder now reads the tag out of Cargo.toml so it cannot drift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
The Decoder's audit of their own corpus found four refuted claims standing --
including one they had corrected to me, agreed with, and written a METHOD entry
about, without landing it for a full iteration. A hand audit finds what is there
on the day it runs; it does not stop the next one.
check-claims is a register: every occurrence of a refuted claim must carry an
explicit [refuted] sentinel within 400 characters. It found four more unmarked
occurrences than my manual pass had, including one in authored/audio.json.
The marker is a sentinel rather than a keyword because the first version's every
failure was a quotation inside a correction whose wording lacked the keyword. The
temptation was to widen the window until they passed -- tuning a threshold until
the answer comes out right, in the tool built to catch that. 21 quotations marked
by hand; proved it fails by removing one.
Also fixes the Decoder's other finding in my corpus: BLOCKED's voice row had a
struck heading with three sentences below still asserting in the present tense.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
Last iteration I filed title and title_jp's disagreement with sylpheed-cli as
mechanism-unknown, to the Decoder as well as here. Both were already explained in
this file, under headings that name the two screens.
Checked rather than assumed. title: still ties on 0x8083, 0x80a0 and 0x8010, and
the export declares paint_order_ties unresolved; the old entry's 904 px in the
glow band matches my 790 px at the same place, same 4-6/255 magnitude. title_jp:
the 'only non-integer scale' claim finds 26 keyframes export-wide, but exactly
ONE element visible at rest -- ptlogo_eff2 at 125% -- which is the pose
verify-screen uses. It survives narrowly.
The failure is navigability: 6502 lines, 111 sections, no index, so 'has this
been decided?' had no cheap answer and re-deriving it looked like diligence.
index-decisions generates the contents; check-all runs --check. No line numbers
(the first version was a fixpoint that failed its own check, and appends would
invalidate them all), and checked, because a stale index answers 'already
decided?' with a confident no.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
Eleven tools and nothing ran them together -- the ninth instance of correct,
documented and unexercised, one level up. check-all runs the four that assert,
reports the oracle table, and gives verify-screen an allowance that EXPIRES when
the pin lands rather than standing forever. All eleven exercised first; none had
rotted.
verify-screen computed over3 because 'a single max cannot tell 2 pixels from
25 444' and then decided the verdict on max alone: main_menu (max 4, over3 0)
read DIFFERS while extras (max 3, over3 0) read OK. The bar is unchanged; a frame
with no pixel over it now gets its own ROUNDING verdict.
And corrects a claim I have given the Decoder more than once. The real count was
ten, now eight: six forced-backdrop, two rounding, and TWO UNEXPLAINED -- title
at 790 px and title_jp at 20498, neither carrying a forced element. My leaf
hypothesis is refuted: emptying draw_leaf_for changes the numbers not at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
