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

port: check-all passes end to end; A and B transitions are not the same shape

Browse Source 
First end-to-end pass I have actually seen: all six asserting checks ok, oracle
captures at 0.00-0.35%, verify-screen's 2 DIFFERS allowed for its stated reason.
My two earlier attempts produced nothing -- one killed by my own timeout with
block-buffered output, one wedged by the ffmpeg hang -- while I reported 'still
two lines, both ok' for three iterations. I was treating absence of output as
patience.

Their discriminating test holds, prediction written down first: incoming build 4
gives an 8-frame decay, build 5 a 5-frame one against my predicted 6. Their tell
reproduces from my export independently -- main_menu settled is [64], title's
opening pair is [255,64], composite [64,255,64], and no single element produces
it.

The consequence neither of us predicted: A title->menu is sequential with a real
~5-frame black interval, B menu->title has NO black interval -- the incoming title
draws at frame 34, before the outgoing quad ramps at 40. boot.gd applies
black_hold uniformly, so the port inserts ~9 units of black on B that the game
does not have.

Not changed. One run of one transition is exactly the generalisation they just
named as the error under two of their own wrong readings, and their second caution
is that the A figure may be a load rather than a designed hold. Recorded as a
known, stated divergence with a BLOCKED ask.

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:56:51 +00:00
parent d613609aaf
commit 72defd9552
2 changed files with 76 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/port/BLOCKED.md
View File

@@ -825,3 +825,21 @@ byte-identical-renders finding rules out the reference), and localized to one
oracle for this screen, and agreement with `sylpheed-cli` is not correctness -
so I can say the two renderers moved apart but not which one moved, and I am not
going to pick a direction.
### Is the Ⓑ "no black interval" general, or specific to menu->title?
**Derived from Decoder `auto/build-ordinal-audit`.**
Measured: Ⓑ menu->title has NO black interval -- the incoming title starts drawing
at frame 34, before the outgoing quad ramps at 40. Ⓐ title->menu is sequential
with ~5 frames of black.
`boot.gd` applies `black_hold_units` uniformly, so the port inserts ~9 units of
black on Ⓑ that the game does not have. **I have not changed it**: one run of one
transition is exactly the generalisation the Decoder just named as the error under
two of their own wrong readings.
**The ask, in priority order:** (1) does Ⓑ from EXTRAS -> main_menu also show no
black interval? That is the cheapest test of whether "Ⓑ has no black" is a rule or
one screen pair. (2) Is the Ⓐ ~10 units a designed hold or a load? If a load, it
is emulator-dependent and nothing should be authored from it.

59
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 -->
161 sections. Search this before re-deriving anything.
163 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)
@@ -172,6 +172,8 @@ dies, which is what this file is for.
* [Auditing my tree for the disc-wide ordinal foot-gun](#auditing-my-tree-for-the-disc-wide-ordinal-foot-gun)
* [Their withdrawn "~14 units of black hold" — my authored 9 survives it](#their-withdrawn-14-units-of-black-hold--my-authored-9-survives-it)
* [🔴 CORRECTION: my 18-vs-19 "agreement" compared two different intervals](#correction-my-18-vs-19-agreement-compared-two-different-intervals)
* [`check-all` passes — after an hour-long hang that was the suite's own fault](#check-all-passes--after-an-hour-long-hang-that-was-the-suites-own-fault)
* [Ⓐ and Ⓑ are not the same shape, and my `black_hold` treats them as if they were](#and--are-not-the-same-shape-and-my-black_hold-treats-them-as-if-they-were)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -9349,3 +9351,58 @@ precisely the Ⓑ transition they have been measuring.
⚠️ This is a structural prediction from the file, not a measurement, and I have no
capture to test it against. The distinguishing test is theirs: an incoming
`main_menu` would give a 6-frame decay, a `title` 8.
## `check-all` passes — after an hour-long hang that was the suite's own fault
✅ **Every asserting check passes**: format-validator, modding-rules,
capture-controls, menu-audio, decisions-index, refuted-claims. Oracle captures
report `main_menu` 0.06 %, `extras` 0.19 %, `main_menu_options` 0.15 %, `title`
0.21 %, `title_plate` **0.00 %**, `title_band` 0.35 %, both splashes 0.01 %.
`title_jp` reads `no capture` — the row is wired and waits for their branch.
`verify-screen` reports 2 DIFFERS, allowed for its stated reason.
⚠️ This is the first end-to-end pass I have actually seen. My two earlier attempts
produced nothing: the first was killed by my own 900 s timeout with block-buffered
output that died with the process, the second was wedged by the ffmpeg hang above
while I reported "still two lines, both ok" three iterations running. **I was
treating an absence of output as patience.**
## Ⓐ and Ⓑ are not the same shape, and my `black_hold` treats them as if they were
They ran the discriminating test — with the prediction written down first — and it
holds: incoming build 4 gives an **8-frame** decay, build 5 a **5-frame** one
against my predicted 6, direction measured and duration inside ±1.
✅ Their clinching tell reproduces from my export independently:
| | full-screen primitives |
|---|---|
| `main_menu` settled | `pteff00` a=0, `pteff02` a=64 → **[64]** |
| `title` opening | `pteff00` a=255, `pteff02` a=64 → **[255, 64]** |
Composite at the transition: **[64, 255, 64]** — exactly what they measured, and
no single element produces it.
### 🔴 The consequence, which neither of us predicted
* **Ⓐ title→menu** is sequential and has a real black interval — ~5 frames,
~10 units.
* **Ⓑ menu→title has no black interval at all.** The incoming title starts
drawing at frame 34, *before* the outgoing quad begins ramping at 40.
`boot.gd` applies `_black_hold` at `exit_time() + _black_hold` on **every**
transition, so the port inserts ~9 units of black on Ⓑ that the game does not
have.
⚠️ **I am not changing it, and the reason is their own warning.** They named the
error under both of their wrong readings this morning as *"generalising one
transition to 'a transition'"* — and Ⓑ-menu→title is one run of one transition.
Suppressing the hold on every cancel path would repeat exactly that. Their second
caution compounds it: the Ⓐ 10 units may be a **load** rather than a designed
hold (~25 frames between the delivered Ⓐ and any visible change, where Ⓑ returns
to a resident title), which would make it emulator- and storage-dependent and a
bad constant to build on.
📌 So the finding is recorded and the divergence is **known and stated** rather
than fixed: the port's transitions are uniform, the game's are directional, and I
do not yet have enough transitions measured to say what the rule is.