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

@@ -31,9 +31,9 @@ authored version can be deleted.
 | Q2 | which build is which screen state | ✅ answered | `GP_TITLE` is **8 screens shipped twice, EN/JP**: 4/7 title art, 2/3 the `PRESS Ⓐ` plate, 5/8 main menu, 6/9 `EXTRAS`, 0/1 and 10/11 two unidentified `DELTASABER` plates — [`ui-title-build-map.md`](../re/ui-title-build-map.md) |
 | Q3 | paint order for the six screens | ✅ answered | **decoded**: a `u16` layer key at `+0x0A` of each `T8aD` sprite header, stable-sorted with declaration index; unkeyed elements get an implied key. Confirmed on 5 measured orders + `EXTRAS` vs a capture. One residual: the **tie-break** is unknown and bites on one element of the title — [`structures/ui-paint-order-key.md`](../re/structures/ui-paint-order-key.md) |
 | Q4 | button → GamePart | 🟡 mostly answered | **measured** which screen each button opens (4 of 5; `NEW GAME` untested — it hangs). The **GamePart id is a name match** onto the decoded id table, not a measurement — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
-| Q5 | navigation semantics | ✅ answered | **measured**: opens on `TUTORIAL` (not the top); ⬆⬇ one step, **wraps both ends**; ⬅➡ do nothing; Ⓑ returns to the parent **with focus restored**; Ⓑ on the main menu → title; Ⓑ on the title → nothing — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
+| Q5 | navigation semantics | ✅ answered | **measured**: initial focus varies boot to boot (2× `TUTORIAL`, 1× `NEW GAME`); ⬆⬇ one step, **wraps both ends**; ⬅➡ do nothing; Ⓑ returns to the parent **with focus restored**; Ⓑ on the main menu → title; Ⓑ on the title → nothing — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
 | Q6 | boot sequence + what drives it | 🟡 partial | order observed, and the **attract cycle is timed**: ~8–10 s idle on the title → fade to black → ~85 s of video → title again, plate and all. The driver is still not decoded |
-| Q7 | transitions | ❔ open | |
+| Q7 | transitions | ✅ answered | a **fade through black**, drawn by the screen's own last-painting `.prm` quad. Fade-in ramp is **decoded** from its keyframes; the ~0.4 s fade-out is **measured** (not in the file) — [`screen-transitions.md`](../re/screen-transitions.md) |
 | Q8 | menu audio bindings | ❔ open | cue table complete, event binding is not |
 | Q9 | video binding + playback rules | 🟡 partial | `ADV.wmv` is the boot intro; new-game intro unidentified |
 | Q10 | music-bank sub-wave roles (intro+loop?) | ❔ open | we concatenate blindly today |
@@ -97,10 +97,9 @@ authored version can be deleted.
 * **Menu movement, measured off the running game.** ⬆⬇ move one item per press
   and **wrap at both ends** (5-item main menu and 3-item `EXTRAS` both). ⬅➡ do
   nothing. Ⓑ goes up one level **and restores focus to the item you came from**;
-  Ⓑ on the main menu returns to the title; Ⓑ on the title does nothing. The main
-  menu opens focused on **`TUTORIAL`**, the middle item — 🟡 reproducible in this
-  harness (2/2) but a third recorded run implies `NEW GAME`, so re-test before
-  hardcoding it. All **measured**, none of it on the disc.
+  Ⓑ on the main menu returns to the title; Ⓑ on the title does nothing. **Initial
+  focus is not stable**: three boots of the same script gave `TUTORIAL`,
+  `TUTORIAL`, `NEW GAME`. Do not hardcode it; pick one and say you picked it. All **measured**, none of it on the disc.
 * **Each button's destination is measured; its GamePart id is not.**
   `LOAD GAME` → the save-slot list, `TUTORIAL` → the lesson list, `OPTIONS` →
   the settings menu, `EXTRAS` → `GP_TITLE` build 6, `EXTRAS ▸ MISSION SELECT` →
@@ -108,6 +107,18 @@ authored version can be deleted.
   GamePart ids (`3`, `25`, `8`, `5`, `7`) are the entries of the decoded id table
   whose **names match the screens seen**; that binding is authored, not measured.
 
+* **A screen change is a fade through black.** Each screen carries a full-screen
+  black `.prm` quad that paints last (`pteff00.prm` / `pfeff00.prm`) whose
+  keyframe group *is* the transition: black at `T0`, clear by `T1`, clear until
+  `T2`, then back to black on exit. ✅ decoded, with a disc-wide check — and in
+  `GP_TITLE` exactly the six **screen** builds carry it while the six overlays do
+  not. The fade-in length is `T1 − T0` and is read from the file (0.87 s for
+  `EXTRAS`, 0.97 s main menu, 4.08 s title). ❔ **The fade-OUT length is not on
+  the disc** — the last keyframe has no time slot; **measured ~0.4 s**, twice.
+  The black hold measures 0.17–0.23 s. ⚠️ Do not time the fade-in off a capture's
+  brightness: the incoming screen's own element animations dominate it and run
+  much longer than the quad.
+
 * **The GamePart id table** — 29 entries at `.rdata 0x820A1630`, confirmed by the
   executable's own registration strings. ✅ This is the screen vocabulary; which
   button reaches which entry is Q4 and is *not* part of it.