re: the transition is overlap, not ramp-then-hold -- and the fade-in was 5x wrong

screen-transitions.md carried a 14-unit "black hold" that the page itself
flagged as arithmetic rather than measurement. Measured it against the running
game; the guess was wrong, and finding the instrument to measure it turned up a
second, larger error in the same page.

1. fade_quads.py was STALE. It read each pose's time from blk+36 -- the next
record's time word -- the association the keyframe record-layout fix retired in
the crate. sylpheed-cli was rebuilt at the time; the Python helper was never
swept with it. Signature: it cannot time a group's last pose, so it printed a
trailing `t=-`. Fixed, controlled against the rebuilt `screen info` ([0 12 70
80] for build 5's pteff00.prm).

2. Through it, the page labelled the quad's CLEAR-hold as its fade-in and
published 0.87 s / 0.97 s / 4.08 s for a ramp that is 0.20 s / 0.20 s / 0.27 s.
A port pacing its menu fade-in off that would run it 5x too slow.

3. The measurement. fade_decompose.sh boots to the main menu, arms the UI draw
capture there, then presses (B), so one 260-frame window holds the whole screen
change. The fade quad is identified rather than guessed: a .prm carries no
tex[base=] and paints last, so it is the last full-screen untextured quad of a
frame. Control first -- the quad's ramp is decoded at 10 units = 5 frames, and
measures 4 submitted-frame steps with one unlogged frame in the span.

Result: content elements begin fading at frame 34; the black quad first appears
at 40 and is opaque by 43; the menu's last frame is 45; frame 46 has 6 draws
against 12. So the ~14 extra units are the content's own fade-outs OVERLAPPING
the quad's ramp, not a hold after it, and the inter-screen black is one frame.

Refutation attempted: sylpheed-port's entries 13/14 twins. Re-derived off the
disc -- 3.06 / 4.33 / 47.91, identical to two decimals. Recorded as confirming
their addressing and arithmetic, NOT as independent support: same renderer,
same disc, which is their own rule.

Reach: one transition, one run; the frame axis has gaps (232 headers over frames
3..260), so every span is +-1 frame.

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

docs/re/METHOD.md

@@ -189,6 +189,20 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   luck in one archive, not a property of the format, and it does not extend to the
   screens the port has left to do.
 
+* **A layout fix has to be swept across every READER of that layout, not just the
+  crate.** The keyframe record-layout fix (a pose's time precedes it) landed in
+  `ui_layout.rs`, and `sylpheed-cli` was found stale and rebuilt. **Two more
+  readers survived it**: `tools/re-capture/fade_quads.py`, which read each pose's
+  time from `blk+36` — the *next* record's time word — and therefore printed a
+  trailing untimed keyframe; and, through it,
+  [`screen-transitions.md`](screen-transitions.md), which labelled the quad's
+  **clear-hold** as its *fade-in* and published 0.87–4.08 s for a ramp that is
+  0.20–0.27 s. Both looked right: a shifted time series is still monotone,
+  plausible, and internally consistent. The tell is structural, not numeric — the
+  stale reader **cannot time the last pose**, so any output with a trailing `t=—`
+  or `-` is that bug's signature. Grep the corpus for readers of a structure
+  before calling its fix done.
+
 ## Runtime / emulator
 
 * **Look at the PNG** — and check its dimensions.