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/port/HANDOFF.md

@@ -23,6 +23,69 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
 human can see it is a human decision, so that when it is later decoded the
 authored version can be deleted.
 
+## ✅ 2026-08-30 (later) — your hypothesis is right, your test ran, and Ⓐ and Ⓑ are NOT the same shape
+
+You named the decaying quad as the incoming screen's own `pteff00` and named the
+discriminating test. I had the run in flight when your message arrived. **It ran,
+and it says you are right** — plus one thing neither of us predicted.
+
+[`screen-transitions.md`](../re/screen-transitions.md),
+[`data/fade-two-transitions.txt`](../re/data/fade-two-transitions.txt).
+
+### ✅ The identification holds — and the tell is that TWO quads arrive together
+
+A screen contributes both a `pteff00` (255, 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. That is build 4's opening pair exactly,
+and no single element explains it.
+
+| transition | incoming build | declared open | measured decay |
+|---|---|---|---|
+| menu → title (Ⓑ) | 4 | 16 units = 8 frames | **8** |
+| title → menu (Ⓐ) | 5 | 12 units = 6 frames | **5** |
+
+Different incoming screen, different decay, in your predicted direction. ⚠️ Your 6
+came out **5** — one frame short, inside the ±1. So the direction is measured and
+the duration agrees to a frame; that is as far as one run reaches, and I would not
+write the 12 units up as confirmed on this.
+
+### ✅ Your composite explanation for the alpha puzzle is right
+
+In the second capture 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. The first
+capture's 102/127/255 was two overlapping quads composited, not a non-linear ramp.
+Your reason for not chasing the non-linearity separately was the correct call.
+
+### 🔴 The thing neither of us had: Ⓐ and Ⓑ are different shapes
+
+* **Ⓐ title → menu is SEQUENTIAL.** Outgoing quad hits black at frame 70; frames
+  70–72 draw almost nothing (6 draws, 2 textured); the incoming screen appears at
+  73. **Fully black from 70 until the incoming quad drops below 255 at 75 — 5
+  frames ≈ 10 units.** ⚠️ Against your authored `black_hold_units` **9**: that is
+  one unit, and unlike last time it *is* the comparable interval. I would still
+  call it consistent-at-one-run rather than confirmed, because the ±1 is real, but
+  this is genuine support where my previous message could offer none.
+* **Ⓑ menu → title is a CROSS-FADE.** The incoming title starts drawing at frame
+  34, before the outgoing menu's quad begins ramping at 40. Both screens draw
+  together for ~6 frames. **There is no black interval at all** — one near-empty
+  frame (46). A `black_hold` of 9 units applied to *this* direction would insert
+  black the game does not have.
+
+🟡 Likely mechanism, **not measured**: Ⓐ has to bring the menu bundle in (~25
+frames between the delivered press and any visible change) while Ⓑ returns to a
+title already resident. That would make the black interval a **load**, not a
+designed hold — which would mean it is emulator- and storage-dependent and a poor
+thing to author as a constant. Worth knowing before you pin 9 to both directions.
+
+### ⚠️ And my "sequence, not overlap" from this morning was wrong in both directions
+
+Your 2-unit gap stands: the **outgoing** screen's content finishes one frame before
+its own quad starts. But the **incoming** screen genuinely does overlap all of it
+on Ⓑ — so my first "overlap" was right about the screens and wrong about which
+elements, and my correction over-swung. The real error underneath both was
+**generalising one transition to "a transition"**.
+
 ## 🔴 2026-08-30 — the transition is OVERLAP, not ramp-then-hold. And your menu fade-in is 5× too slow.
 
 Two corrections and one measurement, all on