re: the transition between screens is a fade through black, and most of

its timing is on the disc

Q7. Every title-side screen carries a full-screen black .prm quad that
paints last, and its keyframe group IS the transition: black at T0, clear
by T1, clear until T2, then back to black on exit. Read with the corpus's
start-of-a-ramp rule and Q1's time unit that gives 0.87s for EXTRAS,
0.97s for the main menu, 4.08s for the title -- from the file, not from a
stopwatch.

The disc-wide check is per-pak all-or-nothing rather than the 41% the
headline count suggests, and GP_TITLE's 6 of 12 is the useful row: the
six builds carrying a fade quad are exactly the six SCREENS, and the six
without are exactly the six overlays. GP_DIALOG is 0 of 133. That is
independent corroboration of the overlay finding from two iterations ago.

One piece is NOT on the disc and says so: the fade-OUT length. The fourth
keyframe has no time slot, because a group's last block stops four bytes
short. Measured instead, at 30fps, ~0.4s and the same both directions.

And a warning I earned: the luminance rise after a transition is NOT the
quad's ramp. The incoming screen's own elements animate in after the quad
has cleared -- 1.47s observed against a declared 0.97s. Time the fade
from where the frame is pure black.

Rig: screenshot samples at 0.5 Hz and cannot see a 0.4s fade at all,
which is why an earlier burst called this an instant cut. ffmpeg x11grab
at 30fps instead; both go in METHOD.

docs/re/METHOD.md

@@ -140,3 +140,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   Detect the **focus ring** in the gutter left of the labels instead
   (`tools/re-capture/menu_focus.py`, 254 vs <82 — no threshold tuning needed),
   and look at the PNG before believing either.
+* **`screenshot` samples at 0.5 Hz — it cannot time an animation.** Measured:
+  ~2 s per grab (an `import` of the root plus an ImageMagick crop). A 0.4 s fade
+  falls entirely between two samples, which is why a 40-frame burst across a
+  screen change looked like an instant cut. For anything timed, record the
+  display instead: `ffmpeg -f x11grab -framerate 30 -video_size <W>x<H> -i
+  :98+<X>,<Y> -t <secs>`, then read per-frame statistics off the file. Take the
+  geometry from `xwininfo -root -tree`, the same way `bin/screenshot` does.
+* **A screen's brightness curve is not its fade quad.** The incoming screen's own
+  elements animate in *after* the transition quad has cleared, so mean luminance
+  keeps rising long after the fade is over — 1.47 s against a declared 0.97 s on
+  one screen. Time the fade from where the frame is *pure black*, and take the
+  ramp itself from the keyframes.