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/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