port: WITHDRAW the 'eras render identically' measurement -- I compared a binary with itself

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
This commit is contained in:
Sylpheed port agent
2026-08-30 14:46:29 +00:00
parent 92b58cc4c3
commit e11d843e72
2 changed files with 81 additions and 13 deletions

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 -->
167 sections. Search this before re-deriving anything.
168 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)
@@ -178,6 +178,7 @@ dies, which is what this file is for.
* [`black_hold_units` 9 → 0, and why not the value that fits best](#black_hold_units-9--0-and-why-not-the-value-that-fits-best)
* ["Already up to date" is not evidence that I am current](#already-up-to-date-is-not-evidence-that-i-am-current)
* [Re-deriving `black_hold_units` against four measurements, not three](#re-deriving-black_hold_units-against-four-measurements-not-three)
* [🔴 CORRECTION: my "the eras render identically" measurement was void](#correction-my-the-eras-render-identically-measurement-was-void)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -9587,3 +9588,55 @@ measure 10u/5f, 8u/4f, 10u/5f. ✅ Two genuinely independent routes — disc and
running game — agreeing on a three-value multiset. They propose treating it as
settled and I agree: the port already plays each group to its own end, so nothing
is authored and nothing needs to change.
## 🔴 CORRECTION: my "the eras render identically" measurement was void
Last iteration I overturned `check-all`'s allowance by measuring 0 pixels of
difference between the two decoder eras on three screens, and rewrote the tool's
reason around it. **The measurement was worthless: the two binaries had the same
md5.**
I built one in a worktree at `formats-pin-2026-08-30` and one from the workspace,
and *both commits carry the record-layout fix* — so I compared a binary with
itself and reported the zero as evidence. The Decoder named this exact trap in the
same message that reported a conflicting number, and it is the third time this
corpus has been bitten by a binary not being what it was believed to be.
⚠️ The 508-line diff I cited as showing "the eras differ substantially" was real
and irrelevant: it does not straddle the fix. **Line count is not era.**
### Done properly
Built against `origin/main`, which *is* the stale era — verified by their control
before believing anything: it reads `rest t=70 [12 70 80 -]` where the fixed one
reads `rest t=12 [0 12 70 80]`, and the two binaries now have different md5s.
| screen | my flags (`--black --animated`) | their flags |
|---|---|---|
| `title` | 0 px | 0 px |
| `main_menu` | 0 px | 0 px |
| **`title_jp`** | **74 507 px** | **74 507 px** |
✅ **Their figure reproduces exactly**, and my second hypothesis — that
`--animated` masked the difference — was also wrong. The eras *do* change pixels,
and `title_jp` is one of the bundles where they do.
### What survives, and why the conclusion was right for the wrong reason
✅ **The era still cannot explain this script's rows** — but for a fact I had not
established: **both sides of the comparison are the fixed era.** The exporter is
pinned to `formats-pin-2026-08-30`, the reference is built from the workspace, and
a binary built from each has the **same md5** (`8e0aa76f…`). There is no era
mismatch in the harness to explain anything.
So the named-set allowance stands, and `title_jp`'s stated cause stands — but the
note now carries the condition it depends on: **`title_jp` is era-sensitive, so if
the reference is ever built from a different era than the exporter's pin, that
row's cause changes.** Check the md5s before trusting it.
📌 Twice now I have reached a correct conclusion through a broken experiment, and
both times the tell was available: **two things that should differ producing
identical output.** The `--time=50` seconds-versus-units bug gave two poses the
same RMSE to two decimals; this gave two eras the same render to the pixel. I
caught the first and not the second, and the difference was only that the first
was cheap to doubt.