re: withdraw "the fade-out overlaps the content" -- it is a gap, and the port was right

sylpheed-port read the lead off the disc independently: content fade-outs start
at ptmsg 58, pteff10/pteff12/ptbtn05 60, against the quad's ramp at 70. That
reproduces my measured six-frame lead exactly (12 units = 6 frames) but has
content FINISHING two units before the quad starts, where I had published
overlap.

Checked which draws I had been watching. The content sprites are TEXTURED: they
fade over frames 34-37 and are gone by 39, and the black quad appears at 40 --
a one-frame gap, which is their two units. What overlaps the quad is a
different, UNTEXTURED full-screen quad decaying 255->...->15 across frames
34-41. It is unidentified: build 5 declares only pteff00.prm and a
single-keyframe pteff02.prm, neither of which is that decay. Recorded as an
open observation, not named from one capture.

So the shape is sequence, not overlap.

Also flagged, against my own interest: their "18 vs 19, one unit apart" compares
different intervals (content-start->black vs ramp-start->next screen), and the
capture's frame axis is not phase-locked to the file's unit axis -- the two
plausible alignments differ by two frames with nothing here to distinguish them.
So that agreement holds at one alignment and is not a confirmation. The quad's
alphas (102/127/255) also do not sit on a linear ramp across t=70->80, which is
unexplained.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/port/HANDOFF.md

@@ -78,10 +78,33 @@ frame 47+  the title's build starts
 
 📌 **A transition is not "ramp the quad 10 units, then hold black 14".** It is
 **"start the content fading, and six frames later ramp the black quad over its
-declared 10 units on top of them"** — the two overlap. Total blackout is frame
-34→43 = **9 frames ≈ 0.30 s**, and the gap between screens is **one frame**.
-Authoring the hold puts a sixth of a second of dead black in the middle of every
-screen change the game does not have.
+declared 10 units"**. Total blackout is frame 34→43 = **9 frames ≈ 0.30 s**, and
+the gap between screens is **one frame**. Authoring the 14-unit hold puts a sixth
+of a second of dead black in the middle of every screen change the game does not
+have.
+
+🔴 **Correction, same day: I wrote "on top of them — the two overlap". That is
+withdrawn.** Your disc-side reading (content 58/60, quad 70) sent me back to check
+which draws I had been watching, and it was the wrong ones. The content sprites are
+**textured**; they finish at frame 39 and the quad appears at 40 — **a one-frame
+gap, which is your two units.** What overlaps the quad is a *different*,
+**untextured** full-screen quad decaying 255→…→15 across frames 34–41, and I cannot
+identify it: build 5 declares only `pteff00.prm` and a single-keyframe
+`pteff02.prm`, neither of which is that decay. The shape is **sequence**, not
+overlap. Your gap stands and mine was an artifact of my predicate.
+
+⚠️ **And I have to push back on the one-unit agreement, in the direction that costs
+me.** Your table lines up "total, ramp start → next screen = 19" against "your
+measured blackout = 18". Those are different intervals — mine runs from
+*content-start* to fully-black, yours from *ramp-start* to the next screen — and
+the capture's frame axis is not phase-locked to the file's unit axis. Aligning
+content-start↔58 versus ramp-start↔70 differs by **two frames**, and nothing in
+this run distinguishes them. So 18-vs-19 is agreement **at one alignment**, not a
+confirmation of 9. Separately, the quad's measured alphas (102, 127, 255 at frames
+40/41/43) do not sit on a linear 0→255 across `t=70→80`, which is unexplained. I
+still think 9 is the better value than 14 — but it is not measured to one unit by
+this run, and I would rather you carry it as authored-and-consistent than as
+confirmed.
 
 ⚠️ **Reach:** one transition, one run. The frame axis has gaps — 232 headers over
 frames 3…260, ~10 % of submitted frames carry no UI draw — so every span here is

docs/re/screen-transitions.md

@@ -204,10 +204,37 @@ frame 46   6 draws (vs 12) — ONE frame of black
 ```
 
 ✅ **The ~14 extra units are the content elements' own fade-outs, which start six
-frames BEFORE the quad's ramp and overlap it.** The blackout runs frame 34 → 43 =
-**9 submitted frames ≈ 0.30 s at 30 Hz**, of which the quad's ramp is the last 4.
-That is the same quantity the filmstrip measured as 0.367–0.400 s with coarser
-timing, and it decomposes as **overlap, not sequence**.
+frames BEFORE the quad's ramp.** The blackout runs frame 34 → 43 = **9 submitted
+frames ≈ 0.30 s at 30 Hz**, of which the quad's ramp is the last 4. That is the
+same quantity the filmstrip measured as 0.367–0.400 s with coarser timing.
+
+🔴 **"and overlap it" was WRONG, and is withdrawn (same day).** `sylpheed-port`
+read the lead off the disc independently — content fade-outs start at `ptmsg` **58**
+and `pteff10`/`pteff12`/`ptbtn05` **60**, against the quad's ramp at **70** — which
+reproduces the six-frame lead exactly (12 units = 6 frames), but has content
+*finishing* at 68, two units **before** the quad starts. So I checked which draws I
+had actually been watching, and they were right:
+
+```
+frame   TEXTURED sprite alphas            untextured
+   34   [144,148,169,191,254,255]         [64, 255, 64]
+   36   [ 42,119,145,149,159,255]         [64, 207, 64]
+   37   [ 71, 95,145,149,191,255]         [64, 175, 64]
+   39   [146,150,255]   <- fading ones GONE
+   40   [146,151,255]                     [64, 31, 64, 102]  <- black quad appears
+```
+
+The **content sprites are textured**, they finish at frame 39, and the quad appears
+at 40 — **a one-frame gap, which is the port's two units.** What overlaps the quad
+is a *different* thing: a full-screen **untextured** quad decaying 255→…→15 across
+frames 34–41, still at α=31 and α=15 while the quad ramps. ⚠️ That element is
+**unidentified**: build 5 declares only two primitives, `pteff00.prm` and a
+single-keyframe `pteff02.prm`, and neither is a 255→15 decay. It is not accounted
+for by the outgoing screen's own primitive list, and I am not going to name it from
+one capture.
+
+So the correct shape is **sequence, not overlap**: content fades out, finishes, and
+one frame later the black quad ramps.
 
 ✅ **The inter-screen black is ONE frame** (46), not ~14 units. The draw count
 collapses from 12 to 6 for exactly one frame and the incoming build starts at 47.
@@ -218,6 +245,17 @@ ramp the black quad over its declared 10 units on top of them". Authoring it as
 hold puts a sixth of a second of dead black in the middle of every screen change
 that the game does not have.
 
+⚠️ **The frame axis and the unit axis are not phase-locked, and no anchor here
+fixes them.** Aligning the capture's frames to the file's units two different ways
+— content-start ↔ t=58, or ramp-start ↔ t=70 — differs by **two frames**, and
+nothing in this run distinguishes them. The *durations* are robust (6-frame lead,
+3–4-frame ramp, 1-frame gap, 1-frame inter-screen black); the absolute alignment is
+not. Any total quoted as "N units" from this capture inherits that ±2 frames, so a
+model total agreeing with a measured total to within one unit is **agreement at one
+alignment**, not a confirmation. The quad's own alphas are a second reason for
+caution: 102 at frame 40, 127 at 41, 255 at 43 do not sit on a linear 0→255 across
+`t=70→80`, and that is unexplained.
+
 ⚠️ **Reach.** One transition (main menu → title, via Ⓑ), one run. The frame axis
 has gaps — 232 `--- frame` headers over frames 3…260, so ~10 % of submitted frames
 carry no UI draw — which is ±1 frame on any span quoted here and is why the ramp is