re: the decaying quad is the INCOMING screen -- and (A) and (B) are different shapes

Last iteration left an unidentified full-screen untextured quad decaying
255->15 during a menu->title transition, which build 5's declaration does not
account for. Hypothesis: it is the INCOMING screen's own pteff00, which opens at
a255 and clears. 8 frames matching build 4's declared 16 units is a FIT, so the
test was a transition whose incoming screen declares something else: title->menu
brings in build 5, 0->12 = 12 units = 6 frames. Prediction recorded before the
run.

Measured: menu->title decay 8 frames (incoming build 4, declared 8), title->menu
decay 5 frames (incoming build 5, declared 6). Different incoming screen,
different decay, in the predicted direction. The second is one frame short of
prediction, inside the documented +-1.

The tell that clinches it: a screen contributes TWO primitives, pteff00 at 255
and pteff02 at 64. The settled menu's untextured set is [64]; at frame 34 it
becomes [64, 255, 64] -- build 4's opening pair, which no single element
explains.

Bonus, and it closes the alpha puzzle: in capture 2 the outgoing quad ramps with
no other untextured quad present -- 63, 127, 191, 255, steps of exactly 64, four
frames, against build 4's declared 261->269 = 8 units = 4 frames. Exact and
exactly linear. Capture 1's 102/127/255 was a composite of two overlapping
quads, as sylpheed-port proposed.

The thing neither of us predicted: the two directions are not the same shape.
(A) title->menu is SEQUENTIAL with a real black interval of 5 frames (~10 units,
against the port's authored 9). (B) menu->title is a CROSS-FADE with no black
interval at all -- the incoming title starts drawing at frame 34, before the
outgoing menu's quad begins ramping at 40. Authoring one hold for both directions
inserts black that (B) does not have.

Also fixed: fade_pair.py's automatic rising/decaying classifier worked on capture
1 and produced nonsense on capture 2, where the title has no full-screen
primitive at rest and the heuristic latched onto a transient. It now prints and
does not decide.

Refutation attempted: sylpheed-port's structural prediction of a 6-frame decay
for an incoming menu. Measured 5. Survives as direction, one frame short as
duration; recorded as both.

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

docs/re/screen-transitions.md

@@ -245,6 +245,85 @@ 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 decaying quad IS the incoming screen — and the two directions are NOT the same shape
+
+**Status: ✅ measured**, two captures, with the prediction written down before the
+second run. Data: [`data/fade-two-transitions.txt`](data/fade-two-transitions.txt).
+
+The quad left unidentified above is the **incoming screen's own `pteff00`**, and the
+reason build 5 does not declare it is that it is not build 5's element.
+
+**The tell is that TWO quads arrive together.** A screen contributes both a
+`pteff00` (255 at `t=0`, decaying) *and* a `pteff02` (64). On the settled menu the
+untextured set is `[64]`; at frame 34 it becomes `[64, 255, 64]` — a 255 **and** a
+second 64, which is exactly build 4's opening pair and cannot be explained by any
+single element.
+
+**The discriminator, predicted in advance.** A fit is not a measurement, and 8
+frames matching build 4's declared 16 units is a fit. So: a transition whose
+incoming screen declares something *else*. `title → menu` brings in build 5, whose
+opening is `0→12` = 12 units = **6 frames** against build 4's 8.
+
+| transition | incoming build | declared open | measured decay |
+|---|---|---|---|
+| menu → title (Ⓑ) | 4 | 16 units = 8 frames | **8** (frames 34–41) |
+| title → menu (Ⓐ) | 5 | 12 units = 6 frames | **5** (frames 73–77) |
+
+Different incoming screen, different decay length, in the predicted direction. That
+kills "a fixed transition effect". ⚠️ The second came out **5 where 6 was
+predicted** — one frame short, inside this capture's documented ±1 — so the
+*direction* is measured and the *duration* agrees to a frame, which is as far as
+one run reaches.
+
+### ✅ And the fade-out ramp is exactly LINEAR — the alpha puzzle was a composite
+
+The rise in the first capture (102, 127, 255) did not sit on a line, and this page
+flagged that as unexplained. In the second capture the outgoing title's quad ramps
+with **no other untextured quad present**:
+
+```
+frame  67    68    69    70
+alpha  63   127   191   255      steps of exactly 64
+```
+
+Four frames, against build 4's declared fade-out `261→269` = 8 units = **4 frames**.
+Exact, and exactly linear. The first capture's curve was the **composite of two
+overlapping quads**, not a non-linear ramp — which is what `sylpheed-port` proposed
+when they saw the numbers, and it is right.
+
+### 🔴 The two directions have different structures, and this is the part to author
+
+* **`title → menu` (Ⓐ) is SEQUENTIAL.** Outgoing content fades (58–67); the
+  outgoing quad ramps to black (67–70); frames 70–72 draw almost nothing (6 draws,
+  2 textured); the incoming screen's elements appear at **73**. There is a real
+  black interval — **fully black from frame 70 until the incoming quad first drops
+  below 255 at frame 75, i.e. 5 frames ≈ 10 units.**
+* **`menu → title` (Ⓑ) is a CROSS-FADE.** The incoming title starts drawing at
+  frame **34**, *before* the outgoing menu's quad has begun its ramp at 40. Both
+  screens draw together for ~6 frames. There is no black interval at all: the
+  near-empty frame is a single one (46).
+
+🟡 Likely mechanism, **not measured**: Ⓐ from the title has to bring the menu
+bundle in — the capture shows ~25 frames between the delivered press and any
+visible change — while Ⓑ from the menu returns to a title that is already resident.
+That would make the black interval a *load*, not a designed hold. Untested.
+
+### ⚠️ What this does to "sequence, not overlap"
+
+Last iteration I withdrew an overlap claim and wrote "the shape is sequence, not
+overlap". **Both halves of that were partly wrong, in opposite directions.** What
+is true:
+
+* the **outgoing** screen's content finishes one frame before its own quad starts —
+  the port's 2-unit gap, confirmed;
+* the **incoming** screen genuinely overlaps all of it, on Ⓑ — so "cross-fade" was
+  right about the screens and wrong about which elements;
+* and on Ⓐ neither overlap happens.
+
+The lesson is not about either reading: it is that **one transition was being
+generalised to "a transition"**, and the two directions in this archive do not
+behave alike.
+
 ⚠️ **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