fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: verify my own indexing against the ordinal foot-gun that voided three of theirs

Browse Source 
The Decoder retracted three claims: screen render --build N takes a build ordinal,
screen list maps [10] to entry 12, and the splashes are entries 10 and 11 -- so
their splash rows rendered the loading screens against splash captures. My own
HANDOFF entry had warned that this names the splashes as loading screens 'and
everything still validates'.

verify-screen's header claims --all protects me from exactly this, and a comment
claiming protection is what just failed on their side, so I measured it: my
reference for build 10 scores RMSE 8.97 against the publisher splash capture and
build 11 scores 8.77 against the developer one, with a cross-control (publisher
reference vs developer capture) at 48.17 -- 5.4x worse, so the discriminator has
teeth. The addressing is correct and now measured rather than asserted.

Worth the time because these two screens' 0.01% figures are among the strongest
evidence in the corpus and are cited in the rest() adjudication a proposal against
a pinned crate now rests on.

Their retraction confirms 190 and 145. Width and mid-ramp remain perfectly
confounded across every screen either of us has measured; my 5/5 predictor result
stands as a hypothesis about the mechanism, not as evidence over width.

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 13:01:14 +00:00
parent a64afe1510
commit 1c4bfeb86a
1 changed files with 43 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/port/DECISIONS.md
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 -->
156 sections. Search this before re-deriving anything.
157 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)
@@ -167,6 +167,7 @@ dies, which is what this file is for.
* [The boot's own end frame, scored against the game for the first time](#the-boots-own-end-frame-scored-against-the-game-for-the-first-time)
* [Refutation attempt: the settle-instant candidate is **not** uniformly better](#refutation-attempt-the-settle-instant-candidate-is-not-uniformly-better)
* [My own predictor holds — and the evidence that made it *better than width* does not](#my-own-predictor-holds--and-the-evidence-that-made-it-better-than-width-does-not)
* [Checking my own tree for the ordinal foot-gun that just voided three of theirs](#checking-my-own-tree-for-the-ordinal-foot-gun-that-just-voided-three-of-theirs)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -9091,3 +9092,44 @@ in the wide bucket, where zero is exactly what the census predicts.
⚠️ I am not claiming their tool is broken; `--settle` may report a different
quantity than the widest keyframe-free gap. But one of the two readings is wrong,
and until it is settled the width hypothesis is **not** refuted.
## Checking my own tree for the ordinal foot-gun that just voided three of theirs
The Decoder retracted three claims: `screen render --build N` takes a **build
ordinal**, `screen list` maps `[10] → entry 12` and `[11] → entry 15`, and the
splashes are entries 10 and 11 — so their splash rows had rendered the **loading
screens** against splash captures. My own HANDOFF entry warned that an
ordinal-keyed 10/11 names the splashes as loading screens *"and everything still
validates"*, and it did.
⚠️ `tools/port/verify-screen`'s header claims `--all` protects me from exactly
this. **A comment claiming protection is what just failed on their side**, so I
checked rather than cited it.
| | RMSE |
|---|---|
| my CLI reference for build 10 vs the **publisher** splash capture | **8.97** ✅ |
| my CLI reference for build 11 vs the **developer** splash capture | **8.77** ✅ |
| cross-control — publisher reference vs **developer** capture | **48.17** |
✅ Both references are the screens they claim to be, and the cross-control is 5.4×
worse, so the discriminator has teeth rather than passing everything. My `--all`
addressing is correct, and now measured rather than asserted.
📌 Worth naming why this was worth ten minutes: the port's numbers for these two
screens (0.01 % differing) are among the strongest evidence in the corpus, and
they are cited in the `rest()` adjudication that a proposal against a pinned crate
now rests on. **Evidence that strong is exactly what you check after finding the
same class of error next door** — the failure mode is silent by construction, and
their instrument reported a railed gamma fit rather than a wrong screen.
### What survives of the settle-window disagreement
Their retraction confirms my reading: 190 and 145, matching my recomputation from
raw keyframe times exactly. Their library was never wrong, only the invocation.
So the position stands where my last entry left it, and no further: **width and
mid-ramp are perfectly confounded across every screen either of us has measured.**
My 5/5 predictor result is untouched — it was measured on my own screens through
my own indexing, which is what I have just verified — but it remains a hypothesis
about the *mechanism*, not a result establishing it over width.