# Handoff — what the menu port needs, and where it stands

The single page the **port agent** reads. Everything here is produced by the
container agent's reverse engineering; nothing here is a design decision about
the port itself.

Keep it current. It is a summary with links into `docs/re/`, not a second copy of
the findings — but an answer that is not reachable from this page has not been
delivered.

## How to read an answer

Every row below is one of exactly three things, and the distinction is the point:

| | meaning | what the port should do |
|---|---|---|
| **decoded** | a field on the disc, with a disc-wide check | read it from the data |
| **measured** | not on the disc in any form we found, but the running game does *this* | hardcode it, and cite this page |
| **undecodable** | we looked in these places, it is not there, here is the reach of the negative | author it by hand, knowingly |

There is no fourth kind. If a row says *measured* or *undecodable*, the port is
**authoring** that value, not transcribing it — and it should be kept somewhere a
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.

## ✅ 2026-08-29 — the disc is back in the decoder container; the red banner that stood here is withdrawn

**This supersedes the "the decoder container has no disc" banner** written at
commit `b9aca6a` (10:42 UTC). That diagnosis was true for the container it was
written in, and a human has since fixed it: this container's PID 1 started at
**11:07:38 UTC**, 25 minutes later, and it has the disc mounted.

Verified, not assumed:

| | |
|---|---|
| `/disc` | a real read-only bind mount on device 2050 (`/` is device 92), **6.2 GB**, 74 entries under `dat/`, `default.xex` present |
| `/iso/game.iso` | present, 7 835 492 352 B |
| end-to-end | `sylpheed-cli screen list $SYLPHEED_DISC/dat/GP_TITLE.pak` returns **12 screen builds**, matching [`ui-title-build-map.md`](../re/ui-title-build-map.md) |

⚠️ **`sylph-doctor` still reports "no ISO" and "no extracted disc", and it is
wrong.** It looks only under `/work` (`find /work -maxdepth 2 -iname '*.iso'`
and `-d /work/sylph_extract/dat`); it never consults `$SYLPHEED_DISC`. Do not
take its two ✖/! lines as evidence about the disc — the disc is at `/disc`
and works. Same trap for `find / -xdev`, which by definition cannot cross into
a bind mount on another device, and which is what the withdrawn banner ran.

**What that means for you:** the decoder can boot the oracle, run
`sylpheed-cli` against a pak, run the disc-gated tests and read the executable
again. New measurements are available; ask for them.

## ✅ 2026-08-29 — three answers from one oracle session (the port's asks 1, 2 and 3)

* **1 — the focus ring SPINS CONTINUOUSLY. Period 2.18 s wall-clock; author it
  as 120 units = 60 frames = 2.00 s at 30 Hz.** It does not ramp once and stop.
  Measured with no angle estimated anywhere — the angular estimator written for
  this **failed its own control** (a synthetic 30° came back as 0°) and was not
  used. What settles it instead: total annulus brightness is conserved to
  **0.4 %** while individual angular bins swing by **24** — brightness moving
  *around* the ring, which excludes a pulse — and the profile's autocorrelation
  has **eight evenly spaced peaks, mean 2.177 s**, over nine revolutions.
  ⚠️ Do not read the committed 20 s mean image as a frame: the spin averages to
  a uniform circle, which is why it looks headless. Five single frames 4 s apart
  show the head at five different angles.
  [`focus-ring-spin-measured.md`](../re/focus-ring-spin-measured.md) ·
  [frames](../re/captures/focus-ring/ring-single-frames-4s-apart.png)

* ✅ **And the ring is the ONLY thing that moves on the settled main menu.**
  Temporal std over 20 s untouched is **exactly 0.000** on every unfocused
  button, on the labels and on the `ptmsg` footer. Static menu + spinning ring
  draws everything that moves.

* **3 — the idle timer that made your Ⓑ rule unprovable is REFUTED on the main
  menu.** Held untouched, the menu stayed put for **≥ 60 s** (49 samples, menu
  correlation never leaving 0.9245–0.9249), against the "~8–10 s idle returns to
  the title" this page carried. ✅ That timer is real but belongs to the
  **title**, not the menu — the corpus had it attached to the wrong screen.
  🟡 Ⓑ itself: delivered (Canary logs `vk=5801`), and in both runs the only input
  in ≥ 100 s, followed by the title. **Ordering measured, timing not** — keep
  Ⓑ→title, now better supported than authored.
  [`menu-idle-and-b-2026-08-29.md`](../re/menu-idle-and-b-2026-08-29.md)

* **Your new #1 — the boot title shows build 4 FIRST, and the plate arrives
  after.** It is your third option, not the first two. Green-Ⓐ glyph count on the
  boot title went **154 → 781**, and 154 is the same reading the committed
  `live-title-build4-no-plate.png` gives (159) while plate titles give
  753/977/1493. 🔴 **The delay is NOT measured** — see the next bullet.

* 🔴 **Four durations I took the same day are WITHDRAWN, including the plate
  delay.** `screen_match.classify_array` costs **1503 ms/frame**; a probe running
  it per frame drained an 8 fps stream at **0.64 fps**, so its frames were stale
  and increasingly so. It manufactured "plate 24.66 s after the title art",
  "Ⓑ→title in 15.58 s", "Ⓑ→title in 25.60 s" and "Ⓐ→menu in 20.26 s". The tell:
  a transition, a press and a fade do not share a duration — a backlog does.
  A backlog **preserves ordering and destroys durations**, which is exactly why
  the sequence results above stand and the timings do not. Fixed (`fast=True`,
  38–75 ms, re-controlled 8/8 on both paths, agreeing to ±0.005); the ring's
  numbers are unaffected and that was checked, not assumed.

## Status

| | Question | State | Answer / link |
|---|---|---|---|
| Q1 | keyframe time unit + ramp shape | ✅ answered, 🟡 one gap | ramp is **linear**; **2 units per rendered frame**; **`1 unit = 1/60 s` — settled**, the idle title presents at 28.5 fps so the game is 30 Hz. 🟡 **The interpolation law is settled; the group TIMELINE for multi-keyframe elements is not** — `palogo_gamearts` is still at full alpha 9 frames after its declared `a=32`, and its declared 80-frame fade-in never draws — [`ui-keyframe-time-unit.md`](../re/ui-keyframe-time-unit.md). ✅ **REPLICATED 2026-08-29 — for ANIMATION, read `+36` as the time the NEXT pose is reached.** Three elements across two screens: `palogo_gamearts` and `palogo_seta` hold full alpha for **83 frames** and `palogo_sqex` for **≥77**, where the current reading predicts **6–8** and the shifted one **80–102**. The elements that cannot discriminate (the `_eff` glows, on which the linear law was measured) fit both. ⚠️ Our decoder still defaults to the other reading (`SYLPHEED_KF_TIME_SHIFT=1` to flip) because it changes `rest()` on one element — but that is an unsound fallback guessing either way, so **static rendering is unaffected and animation timing should use the shift** |
| 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, ❔ tie-break | **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). ⚠️ **The key does not fully order a screen**: elements sharing a key are tied, and the tie-break is ❔ **undecodable from the bundle** — declaration table, `T8aD` header (exhaustive: every offset 0x00–0x7f at u8/u16/u32, both directions, **0** fields match the measured order against **64** for the control) and the RATC child order all give the same order the game does *not* use. Your exposure is **2 overlapping tied pairs on `EXTRAS`** — [`structures/ui-paint-order-derived-check.md`](../re/structures/ui-paint-order-derived-check.md) |
| Q4 | button → GamePart | ✅ answered | **measured** which screen all **5** buttons open — `NEW GAME` → `DIFFICULTY` → `SELECT DATA`, not a hang. The **GamePart id is still a name match**, not a measurement — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md) |
| Q5 | navigation semantics | ✅ answered | **measured**: initial focus varies boot to boot (2× `TUTORIAL`, 2× `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 | ✅ answered | sequence **measured** end to end; the driver is **code, not data** — four search spaces closed, so the port **authors** the sequence — [`boot-config-and-gamepart-registry.md`](../re/boot-config-and-gamepart-registry.md) |
| 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 | ✅ answered | cue vocabulary + bank **decoded**; event binding is a **name match** (the authors' own event names). ✅ **You CAN have the SE audio** — ⚠️ an earlier version of this row said it was "undecodable from the disc"; that was **retracted** and the row was stale. Three cues are located in `Static.slb` and **decode to PCM**: d-pad move `0x1ec0` (4 packets), Ⓑ back `0x0ec0` (2), Ⓐ confirm `0x5d6c0` (6), all mono 48 kHz. The bank is a packed run of XMA waves with no delimiter, so a wave is only (offset, packet count) — and ⚠️ the file order is **not** cue-id order, so the index cannot be counted out — [`menu-audio-cues.md`](../re/menu-audio-cues.md) |
| Q9 | video binding + playback rules | ✅ answered | **decoded** from the movie manifest: `ADVERTISE_MOVIE`→`ADV.wmv` (boot intro *and* attract are one asset), `MS00A`→`S00A.wmv` is the new-game intro, `STAFF_ROLL`→the credits reel. ✅ **one Ⓐ skips a movie** (title at 57 s vs a 193 s baseline) — [`movie-binding.md`](../re/movie-binding.md) |
| Q10 | music-bank sub-wave roles (intro+loop?) | ✅ answered | **two stems of one performance, played together** — sample-synchronous, equal duration, 32/32 banks. **Concatenating is wrong.** Not a seamless loop either — [`structures/bgm-two-stems.md`](../re/structures/bgm-two-stems.md) |
| S1 | Ready Room go/no-go | ✅ **no-go** | it is 2D and enumerates fine (60 builds), but `GP_READY_ROOM.pak` holds **briefing/tactical-map** content, not the six-button Ready Room menu — [`ready-room-probe.md`](../re/ready-room-probe.md) |

## Already settled — the port can rely on these today

### ⬅ Answers to the port's five asks (2026-08-29)

* **1 — how to recognise the splash.** ❔ **No content rule exists; you are
  authoring this.** Design size fails (every extra composable bundle sampled is
  1280×720, same as every screen) and element count fails (the fragments run
  2…15 elements, the splash halves have 3 and 7 — the ranges overlap).
  ✅ **But `GP_TITLE` needs no rule.** There, `--all` adds exactly **four**
  bundles and all four are real screens — no fragments at all — and the `--all`
  index equals the pak **entry** index 1:1 across all 16, so addressing by entry
  index does not mean something different from elsewhere.
  🔴 **And there are TWO splash screens; you have one.** Entries **11/14** are the
  developer logos (GAME ARTS / SETA / studio anima). Entries **10/13** are the
  **SQUARE ENIX publisher** wordmark — the *first* thing the boot shows — and you
  do not have them. The pairs are region twins (`™` on 10, `®` on 13). All four
  draw every element they declare.
  [`ui-splash-addressing.md`](../re/ui-splash-addressing.md) ·
  [render grid](../re/captures/title-builds/splash-both-halves-rendered.png)

* **2 — the ~0.4 s fade-out is (a)**, and it is bigger than the fade quad.
  Every element of a screen ends on **exactly one** untimed keyframe — so there
  is one unknown duration per screen, which rules out (b). That final block is
  where the screen plays out: the quad goes `a=255` (black) while the buttons,
  `ptmsg` and the glows go `a=0` and the two frames hold. (c) is refuted by a
  null test on the capture: a black quad alone keeps the button÷background
  brightness **ratio constant**, and measured through the fade it falls
  **6.50 → 1.94, a 3.4× monotonic drop**. So: write one authored constant
  (~0.4 s / ~24 units) and **play the group to its end on every element** — do
  not fade a black rectangle over a frozen screen.
  [`screen-transitions.md`](../re/screen-transitions.md)

* **3 — focus: your choice is fine, and it is not your bug.** ✅ The focused
  sprite **completely covers** the base — `f` alpha ≥ base alpha at **100.0 %** of
  base-visible pixels on three pairs across both languages, once aligned properly
  (the true offset is **(7,7)**, and at the centre alignment it reads a
  misleading 78–84 %). Compositing both ways differs by **RMSE 1.1 inside the
  button rectangle**, max 12/255 on ~25 px — unmeasurable at frame level.
  🔴 **What you are actually missing is the focus record's SECOND element.**
  `ptbtn0Nf.rat` declares **two** sprites — `ptbtneff01.t32` (a 42×46 **glowing
  ring**, focus only) then `ptbtn0Nf.t32` (the bright label) — where the base
  record declares one. That ring is the marker you say you draw nowhere. ⚠️ Note
  the small dot-in-circle at each underline's left end is *not* it: that is on
  every button all the time, part of the base art.
  [`structures/ui-button-focus-record.md`](../re/structures/ui-button-focus-record.md)

* **4 — rotation: not mine to decide alone.** Raised with the human; see
  MISSION. What I can say without a decision: the two sub-questions are not
  equally open. Rotation is about the **declared pivot** — that anchor is
  *measured*, not assumed: the title's two `ptloop` sweeps scale 600 %/800 %
  vertically, where the pivot term is worth 450 and 630 px, and the GPU capture
  puts both quad centres at y **359.1**/**360.0** against the pivot formula's
  **360.0**; top-left anchoring predicts 810/990 and centre-as-position 270. So
  if you draw rotation, rotate about the declared pivot.
  ⚠️ It changes nothing on your five screens **at rest** — they have zero
  top-level rotations, and the title's two nested ones sit entirely off-screen at
  rest. [`structures/ui-keyframe-rotation.md`](../re/structures/ui-keyframe-rotation.md)

* **5 — the capture is not gamma-neutral, and RMSE against it has a floor.**
  Measured on flat patches (16×16, both images `std < 8`):
  `capture ≈ 255·(render/255)^γ` with **γ ≈ 1.49** (main menu), **1.49**
  (`EXTRAS`), **1.34** (title). The chain says this is a ramp **the game
  installed**, not a capture-path artefact: canary's swap-path gamma stage is a
  pure 256-entry LUT that defaults to identity, and the game is measured calling
  `VdGetCurrentDisplayGamma` once at video init. ⚠️ **Reach: the flat patches are
  almost all dark (render ~0–60), so nothing here constrains midtones or
  highlights** — which is where γ 1.4 does its visible work. So: yes, there is a
  floor; a γ ≈ 1.4 darkening gets closer and is **authored**, best applied where
  it was measured rather than extrapolated. Do not chase RMSE below it.
  [`structures/ui-render-tone-curve.md`](../re/structures/ui-render-tone-curve.md)


* **`GP_TITLE.pak` is eight screens, each shipped twice — English and Japanese.**
  Build 4 is the English title art and 7 its Japanese twin; **2/3 are the
  `PRESS Ⓐ BUTTON` plate, a build of their own** composited over the title and
  faded in a beat later; 5/8 are the five-button main menu; 6/9 are the `EXTRAS`
  submenu — the **only** submenu inside this archive. Builds 0/1 and 10/11 are a
  `DELTASABER / SYLPHEED A.I.` plate that was **never seen running**, in the boot
  path, any title-side screen, or the attract loop. ✅ measured against live
  captures for the four English screens the boot path shows;
  [`ui-title-build-map.md`](../re/ui-title-build-map.md).
  **Withdrawn:** the earlier "builds 6/8/9 are submenus" — 8 is the Japanese main
  menu. The other four main-menu buttons leave the archive, and where each one
  goes is **measured** — see the button-destination bullet below.
* **Buttons are identifiable as data.** Element kind `0x3002` = button, `0x0` =
  decoration, `0x10` = primitive. ✅ decoded **for the title-side screens**.
  ⚠️ `0x3002` is one member of a `0x3000` family with sub-bits, and it is not the
  only button kind on the disc: `GP_READY_ROOM`'s 902 bundles contain **zero**
  `0x3002` and use `0x3000` / `0x3004` / `0x300c` / `0x3008` instead. Nothing in
  this milestone changes — every screen in scope is `GP_TITLE` — but do not ship
  `kind == 0x3002` as a general button test.
  (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.)
* **The title's settled pose is `rest` — and always pass `--primitives`.**
  Against a plate-free capture of the real screen, `screen render --build 4
  --black` edge-correlates **0.9163 at (0,0)**, so the geometry of `rest` is the
  arrived pose; the timeline is not needed for the title.
  ⚠️ **But without `--primitives` the whole frame is +13.14 too bright** (R +12.35,
  G +13.58, B +13.48); with them, **+0.55**. The missing element is
  **`pteff02.prm`**, the 25 % dim, and `--primitives` is off by default. **That is
  the "washed-out cyan slab"** — a dim that should be there and isn't, not a glow
  that shouldn't. Because the art is blue-dominant, the shortfall reads cyan.
  🔴 **A second, separate defect — and it is the "slab".** With the dim in place
  the residual is localised to one band (y ≈ 112–225): the game draws the logo's
  `Z` **swoosh thin with a pink/magenta edge**, our render draws it **thick and
  solid white**. Crop:
  [`title-swoosh-capture-vs-render.png`](../re/captures/title-builds/title-swoosh-capture-vs-render.png).
  The elements are `ptlogo_back2.t32`, `ptlogo_back2eff.t32` and
  `ptlogo_back2eff1…5`. 🟡 Those five are also the group with the **known
  unsolved paint-order tie-break** (key `0x8083`) — same screen, same elements —
  but a blend-order swap explains white-instead-of-pink poorly.
  🔴 **The pivot mismatch is NOT the cause — checked and refuted.** These elements'
  declared pivots really do belong to the *other language's* sprite
  (`ptlogo_back2`'s `(500,117)` is exactly half the Japanese 1000×234, not its own
  English 1118×262; 24 of 109 title elements are off by > 8 px). **But it cannot
  affect this render**: `blit` sizes a sprite from its **texture**, and applies the
  pivot only as `kf.x − pivot·(scale−100)/100` — and **all seven swoosh elements
  are scale `(100,100)` at every keyframe**, so the term is zero.
  ✅ **That formula is now MEASURED, not just implemented (2026-08-28).** The
  title's two `ptloop` sweeps scale **600 %** and **800 %** vertically, where the
  pivot term is worth 450 and 630 px, and the GPU capture puts both quad centres
  at y **359.1** and **360.0** — against the formula's **360.0** for both.
  Top-left anchoring predicts 810 and 990; treating the position as the centre
  predicts 270. Horizontally the same term makes the group's `t` solved from
  **position** agree with `t` solved from **vertex alpha** to **0.33 / 0.65
  units**, versus ~8 units without it. So: **anchor scaling on the pivot, not on
  the top-left corner.**
  🟡 It does *not* prove interpolation is linear — both fields were inverted
  through the same linear map, so a shared easing curve would cancel. It does
  show position and alpha ride **one shared parameter**.
  ⚠️ It *would* bite `ptlogo1`/`ptlogo2`, which scale 100 → 150 during the
  build-in. Not at rest, and not on the swoosh.
  🔴 **Ruled out for the COLOUR**: every swoosh keyframe's fade is `0x??ffffff`
  (white RGB, alpha only), no tint is non-white, and the texture decodes
  *blue*-leaning (175,174,198).
  🟡 **What is left is the BLEND.** Size and position are the texture's own and
  match; fade, tint and texture colour are all ruled out. Seven overlapping
  mostly-transparent sprites (`ptlogo_back2` 5.4 % opaque, its glow 10.3 %, the
  five `eff` segments 10–23 %, all white or warm) stacked with plain alpha-over
  saturate to opaque white — which is exactly what we draw, and would read as
  "thicker" against the game's thin coloured stroke.
  🟡 **And there is a candidate field for it.** The `T8aD` header word at
  **`+0x04`** splits the title's sprites exactly along effect-vs-normal:
  `pteff01`, `pteff03a`, `ptlogo_back2eff1…5`, `ptlogoall_eff`/`_eff2` are
  **`0x8832`**; `ptlogo1`/`2`, `ptlogo_tm`, `ptbase2`, `ptlogo_back2`,
  `ptcopyright` and `ptlogo_back2eff` are **`0x8830`**. One bit — **`0x02`**.
  Disc-wide it is a real independent flag: 19 216 sprites, 18 distinct values,
  bit `0x02` set in **27.1 %**, and it toggles against otherwise-identical words
  (`0x8830`/`0x8832`, `0x0830`/`0x0832`, `0x0810`/`0x0812`, `0x0030`/`0x0032`).
  ⚠️ **Correlation only — untested.** Nothing yet shows it *means* additive; the
  test is to blend bit-`0x02` sprites additively and re-correlate the title
  against the capture. Note `ptlogo_back2eff` is `0x8830` despite its name, so
  this is a field and not a naming pattern. ❔ Not diagnosed — but two candidate meanings are now dead: **not** "the name contains `eff`" — and not even the one-way "bit ⇒ `eff` name", which held 10/10 on the title but fails on **2 657 of 4 995** bit-set sprites disc-wide (`P(eff|set) = 0.468`). What survives is a 3.3× association, and the counterexamples are rings, glows and lights — effect-like art without the naming convention and **not** "the element is transient" (`pteff03`/`pteff03a` carry the bit and persist to `t=250`). 🛑 **Parked** — four candidate meanings are now dead (additive blend; `eff` name, both directions; transient element; **premultiplied alpha**, refuted because flagged sprites violate `RGB ≤ A` *more* than unflagged, 55.5 % vs 33.7 %) and none produced a positive account. It blocks nothing — your screens composite at 0.947 correlation against a capture without it. ⚠️ Practical note for an asset pipeline: `T8aD` headers appear in **RATC child order** (18/18 verified on build 4 against decoded dimensions), which is the only sound way to attribute a header to a name when two sprites share a size — and two here do.
  ⚠️ **The rotated draw is NOT the swoosh.** It was identified as the swoosh by
  elimination; that is **refuted** — its quads span y −209…925 in screen space,
  the swoosh is a band at y 126…360. ✅ **It is the two `ptloop` sweeps**
  (`ptloop01.rat` → `pteff03.t32`, `ptloop02.rat` → `pteff03a.t32`), confirmed by
  edge length: 400 × 1076 and 400 × 1444 against 399×180 at the two elements'
  **different** declared scales, 600 % (= 1080) and 800 % (= 1440). What stands
  from the old bullet: the game *does* submit rotated quads this compositor
  cannot draw, and vertex colours are white.
  ✅ **SOLVED 2026-08-28 by draw capture — it is the GEOMETRY.** The game submits
  the swoosh as **two rotated parallelograms** (edges `(0.54,−0.56)` and
  `(0.44,0.79)`, ~45° and ~61°, extending to `y=±1.81` NDC).
  `ui_layout::blit` draws **axis-aligned rectangles only**, so it blits the sprite
  upright — right on average, right in position, wrong in shape, which is the
  measured signature exactly. **A port that blits upright rects will have the same
  defect.**
  🔴 Vertex colour is refuted with it: every colour in the capture is
  `<alpha>FFFFFF`, white RGB.
  ✅ **CLOSED 2026-08-28 — the rotation IS on the disc, at keyframe `+12`.**
  It is a signed angle in **degrees**, clockwise-positive in screen space
  (Y down), and `ui_layout::Keyframe` now carries it as `rotation_deg`.
  Confirmed against the framebuffer, not against our own renderer: the two
  `ptloop` records declare `+12` = **30** and **−45**, and the GPU capture
  submits their quads at **+30.26°** and **−45.28°** — magnitude and sign, on two
  different values. Corroborated separately by shape: `GP_BUNK` entry `117ca14f`
  holds a group whose `+12` ramps **0 → 360** with position, scale and alpha all
  constant — a spin in place. Disc-wide `+12` is non-zero in **14.50 %** of
  83 862 keyframe blocks.
  ⚠️ **Two things the port must know about it.**
  (1) **Rotation lives in BOTH the top-level table and nested `.rat` leaf
  records.** ⚠️ I told you one iteration ago that it looked nested-only; that was
  three archives' worth of pattern and **it is refuted** — `GP_DIALOG` and
  `GP_DEBRIEFING_PILOTLOG` rotate top-level elements. The actionable half stands:
  the *title's* rotations are nested, so a composer reading only the declaration
  table gets zero rotation on exactly the elements that move there.
  The clearest examples are top-level and show up in
  `screen info --build 0 --geometry dat/GP_DIALOG.pak`: `pceff03.t32` and
  `pceff04.t32` ramp `r=` **90 → 30 → 10 → 3 → 0** while their alpha ramps
  0 → 255 and they slide into place — a swing-in that settles upright; and build
  6's `pzeff02.t32` ramps **43 → 61 → 75 → 90** while scaling 112 % → 200 % and
  fading to 0 — a spin-out burst.
  (2) **`sylpheed-cli screen render` still does not rotate.** The field is
  decoded, not rendered; `ui_layout::blit` is axis-aligned only. So the reference
  renderer and the port will *both* draw these upright until a rotating blit
  exists — and per your own rule, the two of them agreeing about it means
  nothing.
  ✅ **Checked 2026-08-29: this does NOT affect your five screens at rest.**
  Title, main menu, `EXTRAS` and both splash halves have **zero** top-level
  elements with a non-zero rotation. The only rotations on any of them are the
  title's two nested `ptloop` records (`r = 30` and `−45`), and at rest those sit
  at `x = 1521` and `x = −839` — a 399-wide sprite entirely off both edges of a
  1280 screen. So a static composite is unaffected; the caveat applies only if
  you animate the title's build-in, where the sweeps cross the screen rotated.
  🟡 The neighbouring words `+4` and `+8` are still unexplained: signed, non-zero
  in ~4.8 % / 4.6 % of blocks, almost entirely `±180`/`±90`. That distribution
  looks like a flip flag rather than a free angle, but nothing observed turns on
  them — **do not transcribe them as X/Y rotation.**
  [`ui-keyframe-rotation.md`](../re/structures/ui-keyframe-rotation.md)
  ⚠️ The earlier "pink versus white" reading compared two differently-shaped
  renderings and should be re-checked after geometry, not carried as a separate
  defect.
  ❔ **Classified: undecodable from the disc, with reach.** Seven candidates
  eliminated — pivot (inert at scale 100 *and* no measured displacement), `fade`,
  `tint`, texture colour, additive blend via `+0x04` bit `0x02`, and
  capture-not-settled (the band is identical from t = 4.0 s to t = 21.5 s). The
  residual is stable and modest: band mean **+1.83**, edge-corr **0.70** vs ≈ 0.92
  frame-wide. A next attempt should use a **per-draw GPU capture** of the running
  guest — not another field — but ⚠️ that capture records prim/indices/shader
  hashes/**texture bindings**/**vertex attributes** and **no blend state**, so it
  can test a per-draw *vertex colour* today and would need a Canary change to dump
  `RB_BLENDCONTROL`. ✅ And the plate-free capture is sound; use it.
  🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
  sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
  the paint order is being honoured.

* **The title's motion, decoded and attributed.** After building in, the *title
  art* is essentially static — a 22 s capture measures the wordmark region at
  sd 0.06 and the bottom-right corner at sd 0.003. Two things do move:
  * ✅ **Two slow light sweeps in build 4.** `ptloop01.rat` (an `opt `-linked
    `RATC` at `0xbb5966`) sweeps `pteff03.t32` left→right over **450 units =
    7.5 s**; `ptloop02.rat` sweeps `pteff03a.t32` right→left over **570 units =
    9.5 s**. Ordinary 40-byte keyframe blocks from `+0x68`, three keyframes each.
  * ✅ **The `PRESS Ⓐ BUTTON` plate pulses**, and it is the loudest thing on
    screen — a capture's per-tile amplitude map puts **sd 7.65** in the band
    x ≈ 318–954, y ≈ 560–672 against **0.06** on the wordmark. It is
    `ptbtn00f.rat`, the plate's highlight variant (build **2**, not build 4),
    whose alpha ramps **`0x00 → 0x06 → 0x4a → 0x50` (hold) `→ 0x4a → 0x06 → 0x00`**
    over **eight** keyframes at `t = 6, 29, 35, 50, 58, 97, 105, ?` — a glow that
    fades in and back out, **closing on fully transparent**, so it is a complete
    cycle rather than a one-shot ramp.
  🟡 Its cycle **length** is not readable, and this is now observed rather than
  assumed: the eighth block's time slot literally contains the ASCII terminator
  `end `, so the record ends there and the value does not exist. Declared span is
  therefore **≥ 105 units = 1.75 s** against a measured **≈ 2.3 s** — which would
  need a final step of ≈ 33 units. That number is **fitted to the measurement, not
  read**; the port should take ≈ 2.3 s as measured.
  ⚠️ An earlier version of this bullet said "the title screen loops at ≈ 2.2 s"
  and attributed it to `ptloop01/02`. Both halves were wrong: it is the **plate**,
  and it is a different build.
* 🟡 **Our composite is brighter than the emulator's frame — measured, and you
  would be *authoring* if you apply it.** Alignment is exact (best offset
  dy=0 dx=0, correlation **0.9466**), so only the tone differs. Fitting on 16×16
  patches that are flat in **both** images: `capture ≈ 255·(render/255)^γ` with
  γ = **1.491** (main menu), **1.493** (`EXTRAS`), **1.338** (title).
  ⚠️ **Narrow reach.** Those flat patches span only render values ~0–60, where a
  gamma and a plain scale are nearly indistinguishable — on both menus the errors
  are 0.28 vs 0.34 and 0.22 vs 0.28. Only the title separates them (1.08 vs
  9.02). Nothing here constrains midtones or highlights.
  🔴 The held-out control **failed to discriminate**: the splash's 2 918 flat
  patches are pure black (render 0–4), so every model scores ≈ 0.
  🔴 **My "it may be the emulator" caveat is withdrawn.** I said canary applies
  `kernel_display_gamma_type = 2` (BT.709) on output. It does not — that cvar is
  a value a **kStub getter reports to the guest** (`VdGetCurrentDisplayGamma`),
  which the game uses to build its own ramp; canary then applies **the guest's**
  ramp from the `DC_LUT` registers in the swap path (`apply_gamma_table.ps` /
  `apply_gamma_pwl.ps`). So there is no emulator post-process to subtract, and
  any gamma in a capture is one the game installed.
  ✅ **Measured 2026-08-29: the game DOES query the display gamma.** Booted with
  Kernel logging on (`--log_mask=12 --log_level=3`, which changes nothing about
  the output), `VdGetCurrentDisplayGamma` is called once at video init, between
  `VdGetSystemCommandBuffer` and `VdSetDisplayMode` — the moment a ramp-builder
  would ask. Control in the same log: 359 `VdRetrainEDRAM` lines, so an absent
  call would have shown.
  🟡 **That it then writes the ramp is inferred, not observed** — but the chain
  is closed: canary's swap-path gamma stage is a **pure 256-entry LUT** with no
  other transfer (`apply_gamma_table.xesli`), and that LUT **defaults to
  identity** (`CommandProcessor::Initialize`, whose comment says the linear
  default is "what games set when starting with the sRGB return value"). Identity
  cannot produce the measured γ ≈ 1.4, so a non-identity ramp was written.
  ⚠️ The weak joint is that this assumes our composite reproduces the *pre-ramp*
  framebuffer; what carries it is that a systematic ~1.4 across three screens is
  not the shape of a compositor bug. A fixed sRGB stage does not fit either
  direction (encode brightens; decode darkens far more).
  **Practical upshot for you is unchanged:** the darkening is the game's own
  display ramp, so it belongs in a port as a display profile, not baked in.
  ⚠️ Note the ramp depends on the display type the game is *told*; canary
  hard-codes TV/BT.709, which on hardware is a console setting. **So this is a
  display profile, not a fixed property of the game** — reasonable to expose as a
  setting rather than bake in.
  [`structures/ui-render-tone-curve.md`](../re/structures/ui-render-tone-curve.md)

* ✅ **FIXED 2026-08-29 — the dropped background was a name-decoding defect, and
  `screen render` now draws it.** The reference composites for all five screens
  changed; regenerate anything you diffed against before that date. Cause: a
  RATC child's name is stated by an **`opt ` block** immediately before it
  (`"opt " | BE32 len | name | NUL | 3 bytes | magic`), and our parser instead
  guessed it from the last printable run of bytes. For this one child the 3
  trailing bytes are `38 41 58` = `"8AX"`, which beat the real name
  `pteff05.t32`. **`8AX` was never a name** — earlier text on this page treating
  it as one was wrong. Disc-wide: 18 002 children, 17 918 already agreed with the
  `opt ` reading and **24 did not**, every one the same 3-byte-tail failure.
  Effect on your five screens: mean brightness unmoved, high-frequency detail
  **×1.15…×1.30** — the same art at twice the resolution, which is exactly what
  [8AX](../re/structures/ui-8ax-fullres-background.md) said the game draws.
  ⚠️ Both backgrounds are now drawn (`ptbase` upscaled, then the full-res one over
  it): correct, but wasted fill. Draw only the full-res one, taking its *timing*
  from `ptbase`'s element, which carries the keyframes.
  [`structures/ratc-child-names.md`](../re/structures/ratc-child-names.md)
  ✅ **And the fix has no remaining hole.** 60 of the disc's 18 002 RATC children
  still have no `opt ` block; all 60 are now accounted for and **none is on your
  screens**. They are the ten frames of the disc's only `.tan` **frame sequence**
  (`pb_f15_eg_anm.tan`, six language copies of one `GP_READY_ROOM` bundle), where
  a single `opt ` block names the whole run — so a name-resolution miss is not
  hiding anything else the way `8AX` was. ⚠️ Two notes if you ever read outside
  `GP_TITLE`: `ratc::parse` **over-reports** there, listing a `.tan`'s frames as
  anonymous children; and a RATC bundle names exactly six kinds of resource —
  `.t32` (14 756), `.rat` (3 311), `.prm` (367), `.tbm` (224), `.sbo` (54),
  `.tan` (6).
  [`structures/ratc-tan-frame-sequence.md`](../re/structures/ratc-tan-frame-sequence.md)
  <details><summary>the original entry, kept because its reasoning still stands</summary>

  🟡 **`screen render` silently drops one full-screen element per screen — and
  you must NOT simply draw it.** Auditing what the composer omits on your five
  screens: everything is accounted for (`kind & 0x4` ghost instances, `.prm`
  primitives, `loop*` animations) except **`pteff04.t32`** on the title and
  **`pteff05.t32`** on both menus. Those are `kind 0x0`, one keyframe, rest
  `a = 255`, pivot `(640,360)` — full-screen and opaque.
  **Cause:** the element declares `pteff05.t32`, but the `T8aD` behind its `opt `
  link is registered under the name **`8AX`**, so the sprite lookup misses and a
  silent `continue` drops it.
  ✅ **It does not currently show,** because `ptbase.t32` (640×360, drawn at
  200 %) is *the same artwork at half resolution* — its 2× upscale differs from
  `8AX` by mean 2.05, and our background is pixel-identical to `8AX` in every
  patch sampled.
  ✅ **SETTLED 2026-08-29 — the game draws the full-res `8AX`, so use it.**
  Previously parked as "needs a per-draw capture"; it did not. The two carry the
  same art at two resolutions, so what separates them is the detail `8AX` has
  that an upscale cannot. Correlating the capture's departure-from-upscale
  against the 8AX-only detail (both first mapped through the measured gamma):
  main menu **+0.0475** vs controls +0.0032 / −0.0075, title **+0.0634** vs
  +0.0095 / +0.0086 — **two screens, both 68 % of the theoretical ceiling, 7–15×
  their matched controls**.
  **So: resolve the name and draw `8AX` at 1:1.** Upscaling the 640×360 `ptbase`
  2× is *wrong*, not merely softer. ⚠️ Do not draw **both** — an opaque
  full-screen layer over an identical one costs fill and hides later changes; and
  note `ptbase`'s element is the one carrying the keyframes, so you need its
  timing with `8AX`'s pixels.
  ⚠️ It does not show whether `ptbase` is *also* drawn underneath — the full-res
  background is
  ~86 % opaque and would hide it either way.
  [`structures/ui-8ax-fullres-background.md`](../re/structures/ui-8ax-fullres-background.md)
  </details>

* ✅ **Paint order: your exposure is two element pairs, on one screen.** We use
  an order *measured from the running game* where one exists and a derived order
  (a sort on each sprite's layer key) elsewhere. Checked, rather than assumed:
  the derived order reproduces the measured one **exactly** on the main menu
  (0 inverted pairs) and the developer splash (0). On the **title** it differs by
  8 pairs — **all same-layer-key ties** — and two of those are total occlusions
  (`back2eff5` is 1133×280 and *fully contains* `back2eff3` and `back2eff4`;
  derived puts it on top, the game puts it underneath). The title is unaffected
  in practice because it has a measured order.
  Per screen: title **measured**, main menu **measured**, developer splash
  **measured**, publisher splash derived but with **0 ties** (fully determined),
  and **`EXTRAS` derived with 15 tied pairs of which only 2 overlap**.
  ✅ **That narrows again to ONE, and the capture is consistent with it.** Of the
  two overlapping pairs, `ptloop01`×`ptloop02` are `loop*` animations that
  `compose` skips by default, so their tie is unreachable. The remaining pair is
  `ptframe3`×`ptframe4`, overlapping 102×132 px — and against `live-extras.png`
  that contested region correlates **+0.9622**, *better* than the whole frame
  (+0.9440) and inside the range of regions where order cannot matter (+0.8502 /
  +0.9903). 🟡 Consistent with, not proof — correlation cannot see a swap between
  locally similar art. **15 → 2 → 1 → consistent** is the whole paint-order risk
  on your five screens.
  [`structures/ui-paint-order-derived-check.md`](../re/structures/ui-paint-order-derived-check.md)

* ✅ **How good are the five screens, actually?** One page with the numbers:
  [`five-screens-acceptance.md`](../re/five-screens-acceptance.md). Rendered and
  correlated against the live captures — title **0.9500**, main menu **0.9460**,
  `EXTRAS` **0.9440**, publisher splash **0.9600**, developer splash **0.9643**,
  and every one aligns at **exactly dy=0 dx=0** over a ±2 px search, so placement
  and scale are right and the residual is tone and detail rather than geometry.
  Every undrawn element is accounted for (ghost instances, `.prm` primitives,
  `loop*` animations, and the `8AX` name mismatch whose art is on screen anyway) —
  the counts add up exactly, with nothing unexplained. The residual, ranked: tone
  (γ≈1.4, the game's own ramp), `8AX` resolution, one `EXTRAS` paint-order tie,
  and rotation-not-rendered which does not affect these five at rest.
  ⚠️ Reach: static composites at rest against single frames — this says nothing
  about animation.

* ✅ **A static composite is only meaningful for a screen that SETTLES — the two
  splashes are animations.** Measured with its control: suppressing the `_eff`
  glows takes the **publisher splash 0.9604 → 0.9982** and the **developer splash
  0.9659 → 0.9980**, while the same edit makes the title −0.002, the main menu
  **−0.092** and `EXTRAS` **−0.107** worse. The draw log says why — on the
  developer splash the glows draw on frames 94–115 and the logos on 116–211, so
  at the captured moment every glow is already finished, including the two with
  plateaus that `rest_plateau` renders visible.
  So `rest_plateau` is right where a screen settles and over-draws where it does
  not. **There is no "resting pose" for the splashes** — they play through and
  leave, and a static composite of them is a picture of one arbitrary frame
  (≈0.998 for the frame these captures hold). **Play the timeline for the two
  splashes; composite statically for title / main menu / `EXTRAS`.**
  [`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md)

* ❔ **A group's DURATION is in the data; its START TIME is not.** Testing whether
  the splash timeline *played* reproduces the capture: each element is on screen
  for its declared span to within 2 % (glows 44 units observed vs 45 declared;
  logos 192 vs 195). But every glow declares the same times `15,30,45` and every
  logo the same `15,30,190,194,206,210`, so on one clock they would overlap almost
  entirely — and they **do not overlap at all**. The glows run frames 94–115, the
  logos 116–211, strictly sequential.
  🔴 The obvious candidate is dead: each group header carries an undecoded
  **lead-in word**, and it is `0x00000000` for all seven elements. Not the
  keyframe times, not that word, not declaration order, not the RATC child order.
  ✅ **Here is the sequence to author, measured** (1 frame = 1/30 s):
  publisher `palogo_sqex` **3.00 s+** (a floor — it is already at full alpha on
  the capture's first frame), a **0.10 s** gap with nothing drawn, then the
  developer **glows for 0.73 s**, then the developer **logos for 3.20 s**, the
  glow→logo switch being a single frame boundary with no overlap. Each phase is
  within 2 % of its element's declared span, so the *durations* come from the
  bundle and only the *ordering* is authored.
  ⚠️ One capture, one run; and `palogo_anima`/`_eff` get 0 draws in all 214
  frames, so a third pair's phase is not in this measurement.
  [`data/splash-phase-timeline.txt`](../re/data/splash-phase-timeline.txt)
  ⚠️ **So you must author the sequencing.** The observed order on the developer
  splash — both glows, then both logos — is *measured for one screen*, not a
  decoded rule.
  ✅ **Verified against its own refutation:** across all 235 captured frames,
  **zero** contain both a glow and a logo; the switch is one clean boundary with
  two sprites either side.
  🔴 **And it goes further than start times — a bundle's declared elements are
  not what gets drawn.** ✅ **And the mechanism is now established, by
  elimination.** The competing story — "two compositions shown in sequence" —
  needs a bundle declaring the glows *without* the logos, and no such bundle
  exists: only four entries in `GP_TITLE` carry `palogo` elements, and each
  developer entry (11, 14) declares **all six** logos and glows. So whichever
  bundle was active, only a subset of its elements was drawn at a time.
  (An earlier texture-base test could not separate the two — it failed its own
  control, since the publisher splash is a different bundle and shares the base
  `0x11C30000`, a reused upload slot rather than an identity.) Entry 11 declares *three* logo/glow pairs; only two are ever drawn.
  `palogo_anima` gets **0 frames** while `palogo_gamearts` gets **95**, from
  byte-identical keyframe times. (Reach: the capture covers frames 1–214, so
  "never in the window".) **Compositing every element of a bundle does not
  reproduce what the game shows over time** — it is right for a static screen
  that settles, and it is not a timeline.
  [`structures/ui-group-start-time.md`](../re/structures/ui-group-start-time.md)

* ✅ **The splash's backdrop is an opaque black `.prm` from the bundle, painted
  first.** Measured: every frame opens with the clear and then an **untextured
  1280×720 quad, vertex colour `FF000000` in all 212 frames** — matching
  `palogo_eff0.prm`'s declaration (`kind 0x10`, pivot 640×360, one keyframe,
  `a=255`). That is why a splash render needs `--black` rather than the default
  backdrop. ⚠️ Not a general rule: the main menu's measured order puts one `.prm`
  at position 4 and the other **last** (the transition fade).
  ✅ **The splash's recorded paint order `[0,2,4,6,1,3,5]` is a real depth
  order** — read off the runtime child array, and independently backed by the
  static layer key (glows `0xa100` sort before logos `0xa110`;
  `paint_order_audit` reports derived == measured, 0 ties). A same-day claim on
  this page that it was "a temporal sequence, not depth" was **withdrawn**; see
  the ❌ section in the linked page for why, if you read it before the fix.
  ⚠️ Separately and still true — and it is an **activation** fact, not a
  paint-order one: the splash's glows and logos are never on screen together
  (glows f94–115, logos f116–211,
  [timeline](../re/data/splash-phase-timeline.txt)). Compositing all seven at
  once reproduces no frame of the real screen. Depth says *what covers what*;
  it does not say *what is up*.
  [`structures/ui-prm-primitives.md`](../re/structures/ui-prm-primitives.md)

* **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
  ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
  disc's real navigation structure is unknown, and `opt ` is *not* a focus link
  (measured and refuted, see
  [`ui-focus-and-effect-elements.md`](../re/structures/ui-focus-and-effect-elements.md)).
* **Highlighted states pair by name** — `ptbtn01.rat` ↔ `ptbtn01f.rat`. 🟡 a
  naming convention that holds for all 54 real pairs, not a decoded field.
* **`rest()` was wrong for elements with no exit animation — fixed 2026-08-28.**
  A trailing run of identical keyframes was always treated as the exit and
  excluded; on an element that has no exit it *is* the hold, and `rest()` fell
  back to the element's **first** keyframe — off-position and transparent. Six
  elements on the main menu were affected, including `ptframe1`/`ptframe2`, the
  bright circuit bracket around the menu, which both the port's composite **and**
  `sylpheed-cli screen render` were dropping.
  The rule now: **a trailing run is the hold exactly when it is visible** (alpha
  ≠ 0). ⚠️ Not the pose-equality test the report proposed — `pgptitle.rat`'s
  trailing run also matches its last timed keyframe, and adopting that would erase
  the word PAUSE. Oracle correlation over the bracket region improved
  **0.9596 → 0.9748**; the PAUSE control is unchanged.
  ✅ **Disc-wide**: over 2 859 bundles / 13 991 elements, `rest` moves for **30**
  (0.21 %) — **4 invisible → visible, 0 visible → invisible**. Tests green
  (131 passed).
  ❔ **Back to the port agent:** on the English main menu exactly **two** elements
  satisfy your pose-equality condition (`ptframe1`/`ptframe2`), so your six span
  the whole export. If any of the other four have a **transparent** trailing run,
  this rule leaves them alone on purpose. **Which screens are they on, and does a
  capture show any of them drawn?** If so the alpha rule is incomplete.
  This also closes the old ❔ on `ptframe1`/`ptframe2` "resting at alpha 0 but the
  capture shows the frame plainly".
* **The resting pose is the hold**, not the first, last or longest-dwell keyframe;
  a keyframe is the **start of a ramp**.
  [`ui-resting-pose.md`](../re/structures/ui-resting-pose.md). ✅
* **That ramp is linear, and it runs at 2 keyframe time units per rendered
  frame.** Measured frame-by-frame off the running game's own draw stream: a
  declared 15-unit fade lands on `round(255·k/15)` for all seven of its samples,
  with `k` stepping 2, 4, 6, 8, 10, 12, 14 on seven consecutive submitted frames.
  **measured**, not decoded — the disc says `t=30`, it does not say what a `t` is.
  🟡 **But a multi-keyframe element's TIMELINE does not reproduce (2026-08-28).**
  The linear law and the 2-units-per-frame rate rest on the splash's `_eff`
  glows, and those are exact. Applying *their* calibration — with no free
  parameter left — to `palogo_gamearts` in the same bundle and the same frames:
  the logo is still at `a=255` nine frames after its declared `a=32`, its
  fade-out runs ~17 frames late, and its declared 80-frame fade-in is never
  drawn at all (and that is not culling — the same element is submitted down to
  `a=7` on the way out). Its declared fade-out also spends 12 of 16 units
  dropping only 23/255 of the alpha; the capture shows no such plateau.
  🔵 **Followed up, and the candidate is now strongly favoured — but not
  adopted.** That `+36` holds the *next* pose's time is supported by a
  calibration-free measurement: the observed full-alpha **hold : fade-out** ratio
  is 83 : 13 frames = **6.38**, the shifted reading predicts **8.00**, and the
  current reading predicts **0.25** — off by **26×**. With the glow's 2
  units/frame fixed and nothing else free, the current reading says the logo
  holds full alpha for **2.0 frames**; the game holds it for **83**. The shift
  also makes `rest()`'s plain dwell rule pick the visible hold instead of a
  fully transparent pose, and removes the decoder's "last block's time is
  unreadable" special case.
  ~~🔴 **What stops it:** … `GP_TITLE` build 7 … twins should match in
  brightness …~~ **Withdrawn 2026-08-28.** That render difference is **not**
  evidence about the time association. It is one element — `ptlogo_eff3.t32`, a
  transient bloom that grows `0 % → 200 %` at full alpha while rotating, then
  collapses — and it has **no resting pose at all**. `rest()` falls through to
  its dwell fallback and returns whichever end of that movement the indexing
  lands on: the invisible frame as decoded, the 200 % peak shifted. An 896×389
  sprite at 200 % is larger than the screen, which is the whole 13.1 % and the
  whole luminance gap. I was comparing a heuristic, not a decode.
  🔴 **And that is a real defect you should know about:** `rest()`'s dwell rule
  is unsound *whenever it runs*. A dwell gap is time spent interpolating **from**
  pose k **to** pose k+1; neither is held unless they are equal — which is a
  plateau, and the plateau path has already returned by then. **So any element
  with no two adjacent identical poses has a guessed rest pose**, in our renderer
  and in anything built from it. Measured disc-wide: **2 305 of 15 493 elements
  (14.88 %)** — ⚠️ **corrected 2026-08-29 down from a published 3 807 (24.57 %)**,
  which counted 1 502 *single-keyframe* elements as guesses; those have one pose
  and it is unambiguously their rest. Of the real 2 305, **195 get a degenerate
  `scale = 0 %` pose**, and the two
  candidate rules agree only **50.2 %** of the time.
  ✅ **This does not block you — your exposure is TWO elements, both on the
  splashes.** The fallback is reached only by an element that is plateau-less
  *and* multi-keyframe; a single-keyframe element short-circuits. Title, main
  menu and `EXTRAS` reach it **zero** times, which is why three different
  fallback rules render them to identical correlations. The publisher and
  developer splashes reach it once each — and there, `SYLPHEED_REST_RULE=last`
  (the final keyframe) scores **+0.9982** and **+0.9758** against the current
  rule's +0.9600 and +0.9643. ⚠️ Measured against single frames of a transient
  animation, so it fixes which pose matches *those* captures, not which is
  canonically at rest. Default unchanged — it is better on both screens where it
  fires and identical on the other three, but it would move 2 305 elements
  disc-wide on two measurements.
  ✅ **And the picture is now coherent.** Applying the last keyframe to *every*
  element (not just the plateau-less ones) collapses all five screens — title
  0.9500→0.6819, main menu 0.9460→0.6416, `EXTRAS` 0.9440→0.5745, and both
  splashes render **blank**. The reason is the model: a group is **entry → hold →
  exit**, and the exit is the screen's *dismissal*. A displayed screen is sitting
  at the **hold**, not at its final pose — so `rest_plateau` is right, and the
  last keyframe is the *post-exit* state. It is right for a **transient** element
  precisely because a transient's settled state is "gone". The draw capture agrees
  independently: on the developer splash the `_eff` glows draw on frames 94–115
  and the logos on 116–211, so the glows are already over when the logos are up.
  **Three independent observables — animation timing, static composites and the
  per-frame draw log — all support: plateau where there is one, last keyframe
  where there is not.**
  📊 **Structurally, `last` is defensible for 2 293 of the 2 305 (99.5 %)**: 1 618
  end invisible (a transient, gone at rest), 675 end at maximum alpha (faded in
  and stopped — the final pose *is* settled), and only **12** end visible below
  full alpha, which are genuinely unclear. The dwell rule returns a mid-movement
  frame by construction. ⚠️ The 1 618 rest on an assumption worth seeing: that
  such an element's animation has finished by the time the screen settles — shown
  by the draw log for the two splash glows, unshown for the rest.
  📊 The disc-wide blast radius, for whoever decides: the rules **differ on 82.3 %**
  of those 2 305, so "either is fine" is not available — and the current rule
  returns a **zero-scale** (collapsed, pre-roll) pose for **195** of them against
  **43** under `last`, a 4.5× reduction in provably-degenerate results. That
  argues the same way as the captures, from the data's own structure. The single disagreement
  is `palogo_anima_eff.t32` on the developer splash, and the current answer is
  the defensible one there — see below. Still worth flagging plateau-less
  elements in an export rather than silently inheriting our guess; it is one pass
  over the keyframes.
  ✅ **One concrete part of it is fixed (2026-08-28): `scale = 0` no longer
  renders at full size.** `blit`/`fill_quad` coerced `scale == 0` to 100 %, so an
  element collapsed to nothing was drawn full-size. The disc settles the reading:
  2 166 elements have a zero-scale keyframe, **not one is zero throughout**, and
  1 762 grow back out of zero — so 0 means collapsed, not "unset". **Renders are
  24/24 byte-identical** on `GP_TITLE` (all 16 builds), `GP_PAUSE_MENU` and
  `GP_OPTIONS`, so nothing you rely on moves; the 126 elements the old
  code actually painted are **all in `GP_READY_ROOM.pak`**, already a no-go.
  [`structures/ui-rat-layout.md`](../re/structures/ui-rat-layout.md)
  🔴 **"rest = last keyframe" is refuted** as the fix. The splash has three
  sibling glows with identical structure and times, differing in one byte
  (`a=212` vs `a=255` at `t=45`); that rule would make `anima_eff` alone
  invisible while its two siblings stay lit. The capture agrees weakly — box-mean
  ratios capture/render are gamearts 0.717, seta 0.723, **anima 0.772**, and a
  glow we drew that the game does not would put anima *below* its siblings.
  [`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md)
  🟡 **The shift is still not adopted**, now for a different reason: it flips
  this element to the visibly wrong answer, so it and a decision about
  plateau-less elements have to land together, and neither half has a capture to
  verify against.
  **Default unchanged**, experiment reachable via `SYLPHEED_KF_TIME_SHIFT=1`.
  **What this means for you:** the interpolation *law* is settled (linear, 2
  units/frame); a multi-keyframe group's *timing* is not — do not expect a
  2-frame hold where the game holds 83.
  ✅ **The seconds conversion is settled: `1 unit = 1/60 s`, a 30 Hz title.** The
  re-test this page used to name has been run — 300 submitted frames timed on the
  **idle** title (nothing loading) came out at **28.8 and 28.3 fps**, the same
  rate as the 27.6 fps measured during the loading splash. The competing 60 Hz
  reading is excluded: it needs the emulator at 47 % of real time while idling on
  a screen that costs ~5 draws per frame.
  A second, independent line agrees — the transition quad is declared black for
  12 units (0.20 s under this conversion) and a capture measured the pure-black
  plateau at 0.17–0.23 s
  ([`screen-transitions.md`](../re/screen-transitions.md)).
  ⚠️ Still **measured, not decoded**: no field on the disc says "sixtieths of a
  second".
* **The paint order is derivable from the file.** Each `T8aD` sprite header
  carries a **`u16` layer key at `+0x0A`** (the upper half of the 32-bit word at
  `+0x08` is zero in all 21 184 sprites on the disc). Paint order is that key,
  **stable-sorted** so equal keys keep declaration order; elements with no sprite
  (`.prm` primitives, `.tbm`) have no key and take an implied one — the backdrop
  and dim quads sort early, the screen-transition fade (`pteff00.prm`,
  `pfeff00.prm`) sorts **last**. ✅ decoded. Checked against five paint orders read
  off the running game, one of them (`GP_SAVE_LOAD`'s slot-list header, 6
  instances) **exact and independent of the screens the rule was fitted to**, and
  against a fresh `EXTRAS` capture. It reorders 341 of the disc's 965 builds, so
  it is not a no-op dressed as a rule.
  🟡 **The one residual: ties.** Where two elements share a key the game
  sometimes paints them in an order nothing predicts — eight candidates refuted,
  including declaration order, RATC child order, keyframe times, resting X/Y and
  `kind`. Measured cost: on the three screens with ground truth it changes the
  blend of **one element on one screen** (a title glow). Take the stable sort and
  accept that.

* **Ⓑ returns to the title, and that title still works.** Ⓐ on the Ⓑ-returned
  title opens the main menu — measured, with Ⓐ on the boot title as the control in
  the same run. (Only the *attract*-returned title is inert, which is an emulator-
  harness curiosity, not a port concern.)
* **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. **Initial
  focus is not stable**: four boots of the same script gave `TUTORIAL`,
  `TUTORIAL`, `NEW GAME`, `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.**
  **`NEW GAME` → `DIFFICULTY`** (`EASY`/`NORMAL`/`HARD`/`BACK`, opening on
  `NORMAL`) **→ `SELECT DATA`** — it does *not* hang; the run then hits the
  already-documented `sub_823070B0` cache crash, which is not a menu problem.
  `LOAD GAME` → the save-slot list, `TUTORIAL` → the lesson list, `OPTIONS` →
  the settings menu, `EXTRAS` → `GP_TITLE` build 6, `EXTRAS ▸ MISSION SELECT` →
  the stage list. The
  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 movie manifest names every boot-side video by role.** `dat/tables.pak`
  entry `0x5b983a08`: `LOGO1`–`LOGO4` → `logo1.wmv`–`logo4.wmv` (**not on the
  disc** — this is why the splash is a screen), **`ADVERTISE_MOVIE` → `ADV.wmv`**,
  `STAFF_ROLL` → `SYLPH_HD720p_8M-CBR_2ch.wmv`, **`MS00A` → `S00A.wmv`** (the
  new-game intro, 93.9 s, with subtitle + `VOICE_S00A` + a text overlay),
  `MS01A` → `S01A.wmv`. ✅ decoded — and **`S00A.wmv` is now also measured**: matched off the running game at 0.96–1.000 with a strictly monotone playhead over 25 consecutive 0.5 s samples. It starts ~4.5 s after Ⓐ on the save slot.
  **The boot intro and the attract movie are the SAME asset** — there is no
  separate boot slot, and 15 of 19 captured attract frames match `ADV.wmv` with a
  monotonically advancing playhead ending at its full 137 s. One video, not two.
  ✅ The attract movie **plays to its end**; nothing cuts it short.
  ✅ **A movie is skippable with a single Ⓐ.** Measured: one tap ~45 s into the
  boot brought the title at ~57 s against a ~193 s no-input baseline over three
  boots, with Canary's own keystroke counter proving exactly one press was
  delivered — and the skipped-to title is **fully functional** (`PRESS Ⓐ` plate
  present, Ⓐ opens the main menu). What breaks the boot is *hammering*: 88
  presses left a permanent black screen. One press is fine.

* **The menu's sound events are named on the disc.** `tables.pak`'s `SOUNDS`
  record carries 322 `SE_*` cues, and the low block is the UI vocabulary — named
  after the *event*: `SE_UI_CURSOR` (2), `SE_UI_DECIDE` (3), `SE_UI_CANSEL` (4),
  `SE_UI_IMPOSI` (5, the error), `SE_UI_SUB_WIN_OPN`/`_CLS` (8/9),
  `SE_UI_SPLASH_IN`/`_OUT` (12/13). ✅ decoded, full list in
  [`data/se-ui-cues.txt`](../re/data/se-ui-cues.txt). They all live in **one**
  bank — `BANK_SE` is a single field naming `Static.slb`, and 0 of the 322 has
  its own `FILES` entry.
  🟡 **Which event fires which cue is a name match**, not a measurement — strong,
  because these are the authors' own event names, but nobody has watched the game
  emit cue 2 on a d-pad press. The port is authoring it.
  ✅ **The SE audio IS extractable — by playing it.** (This corrects an earlier
  "cannot be extracted" on this page.) The disc carries no index: `Static.slb` has
  **0 `RIFF`/`seek`/`WAVE`** and there is **no XACT container anywhere** (0 ×
  `XGSF`/`SDBK`/`WBND` in 1.08 GB of `sound.pak`; no `XACT` string in the
  executable — those extensions are the authoring tool's). But Canary's
  `--xma_param_probe=true` logs every stream's head bytes, and searching them in
  `Static.slb` locates the wave exactly:
  **d-pad move → `0x1ec0` (4 pkts / 8 192 B, 0.533 s); Ⓐ confirm → `0x5d6c0`
  (6 pkts / 12 288 B, 1.016 s); Ⓑ back → `0x0ec0` (2 pkts / 4 096 B, 0.344 s)** —
  every cue the five screens need. Move and back reproduce with identical head
  bytes across **two independent boots**. Each matched at one offset only, and
  the first two are contiguous
  (`0x0ec0 + 4096 = 0x1ec0`) — the bank is a packed run of whole 2 048-byte
  packets with no delimiters, which is why nothing could be scanned for.
  ❔ **⬅ and ➡ play nothing distinct** — no new stream on either, so leave them
  silent (the probe dedups, so this excludes a *distinct* invalid cue, not a
  quiet replay of an already-heard one).
  🟡 The Ⓐ press both confirms and opens a screen, so whether its wave is the cue
  named `SE_UI_DECIDE` or `SE_UI_SUB_WIN_OPN` is not separated.
  ⚠️ The order is **not** cue-id order, so the index must be observed per cue, not
  counted. ✅ **The slices decode**: 0.533 s, 0.344 s and 1.016 s of mono 48 kHz
  audio with the attack-and-decay shape of UI blips, via
  `tools/re-capture/slb_extract_wave.py` — whose wrapper reproduces a known-good
  `BGM_001` decode to the same 173.808875 s, so it is verified, not assumed.

* **The boot sequence is not data-driven — the port authors it.** ❔ Four places
  were checked and the order is in none: `config.ini`'s `[SYSTEM]` is empty, the
  movie manifest carries assets not transitions, the requested GamePart id lives
  **only as a stack argument in flight** (no persistent field, no literal store),
  and the string `GP_ADVERTISE_DEMO` has **zero xrefs**. A transition is a call
  with an id argument, chosen by code.
  🟡 **But the states have names, and the transition uses them.** `sub_821C6458`,
  the title part's state function, calls **`sub_821CC860(…, "<NAME>", 0)`** with
  `TITLE_SCREEN`, `TITLE_MENU` and `LOADING` — the three states measured off the
  game, in the game's own words — and installs the result. So a transition is a
  call with a **name** argument, which is also why `GP_ADVERTISE_DEMO` has no
  xrefs: at this level the screen graph is name-keyed, not id-keyed.
  ✅ The argument is now **decoded** at 46 of that function's 48 call sites (28
  distinct names). ⚠️ It is a **generic name-keyed lookup**, not a screen factory —
  its arguments include `BG`, `BLACK`, `FADE`, `FILE`, `KEY`, `PAD`, `SOUND`,
  `GAMMA_RGB`. An earlier version of this page claimed `DIFFICULTY` and
  `EXTRA_MENU` as corroborated screen names; **neither is ever the argument**, and
  only `TUTORIAL_MENU` survives.
  ✅ **And the state machine itself is decoded**: `state = this+136`, ten states
  dispatched through a jump table at `0x821C6498`, with **18 transitions** each a
  literal `li`/`stw`. States **0, 2, 8** install `TITLE_SCREEN`, `TITLE_MENU`,
  `LOADING`. `4 → 0` is the only edge back to the title, reached from `2 → 4` —
  which matches Ⓑ-returns-to-title as measured. Full graph in
  [`data/title-state-machine.txt`](../re/data/title-state-machine.txt).
  ⚠️ **All of that is ONE PHASE.** `GamePart_Title` dispatches on an outer phase
  field at `this+132` (five values) before reaching any of it: phase 0 is the
  **developer splash** (`sub_821C5690`, the same function the corpus fingered
  independently), phase 4 is the title/menu machine. The ten states and
  eighteen edges above live inside phase 4 alone.
  ✅ **State 4's edge conditions are an event code** — `sub_821C6458`'s third
  argument. State 4 is the input-waiting state (reached straight after the menu
  is installed) and handles 6 of 26 events: **`0` → title**, **`3`, `5`, `8`,
  `25` → `LOADING`**, `10` → state 5.
  🟡 What the event *numbers* mean is not decoded — button id, menu row, or
  message id — so the port still takes the button→destination map from
  measurement. The one-to-title / four-to-loading shape matches the five-item
  menu with Ⓑ, but that is a **count-match, not a mapping**. The sequence itself is fully measured:
  splash → `ADV.wmv` → title + `PRESS Ⓐ` → (idle ~8–10 s → `ADV.wmv` in full →
  title) → Ⓐ → main menu, with Ⓑ from the main menu returning to the title.

* **`config.ini` picks the language, and that is what picks the EN/JP build.**
  The disc's **only** config file (400 bytes, at the root; one `find` over the
  whole extract). Its `[LANGUAGE]` section maps the console's `XC_LANGUAGE_*`
  value to `eng`/`jpn`/`deu`/`fra`/`esp`/`ita`, defaulting to `eng` — that code
  selects `GP_TITLE`'s English or Japanese build and the `<lang>.pak` families.
  ✅ decoded.
  ❔ Its `[SYSTEM]` section — which the file's own comment says holds what the
  game and every game part share — is **empty**, so the boot *order* is not in
  disc-side configuration at all.
* **Five GameParts are named but never registered.** Pulling every
  `RegisterToFactory<N, class silph::GamePart_X>` diagnostic string binds **24 of
  the 29 ids to a C++ class**
  ([`data/gamepart-class-ids.txt`](../re/data/gamepart-class-ids.txt)). Ids `1`,
  `2`, `16`, `18`, `28` have no registration site — including
  **`GP_ADVERTISE_DEMO` (1)**, which agrees with the measurement that the attract
  loop is the *title* replaying `ADV.wmv` rather than a separate part. 🟡 an
  argument from a diagnostic string, not from the code.
  Also: **`3` and `4` are both `GamePart_SaveLoad`** — one part, two ids.

* **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.
* **The logo splash is a screen, not a video, and it renders.** `logo1`–`logo4`
  are manifest-bound with no `.wmv` on the disc. ✅ The screen is **two** bundles
  in `GP_TITLE.pak`, each shipped twice: entries **10/13** the white
  `SQUARE ENIX` publisher logo, entries **11/14** `GAME ARTS`/`SETA`/`studio
  anima`. ⚠️ They are **invisible to the default `screen list`/`render`** —
  `is_build` rejects them for having no `.rat` child. Pass **`--all`**, which
  renumbers `--build`. So the first of the five screens does have a reference
  composite. ✅ **And a capture**: both halves edge-correlate to their renders at
  **0.91** and **0.98** at zero shift, each rejected by the other (0.03, −0.03).
  ✅ **Its timing is DECODED, not just measured.** The splash **fades both ways**
  and the bundles carry the keyframes: `SQUARE ENIX` `[15 30 235 239 251 255]`,
  developer logos `[15 30 190 194 206 210]`, each with an `_eff` glow child on
  `[15 30 45]`. Under `1 unit = 1/60 s` that is a 0.25 s ramp in, a **3.42 s**
  / **2.67 s** hold, and a **0.33 s** fade out — and a 10 fps capture measures
  ≈ 3.5 s / ≈ 2.4 s holds and **≈ 0.3 s** fade-outs. The visible brightness
  overshoot on the way in is the `_eff` glow ramping after the logo, not a
  rendering artifact. Wall-clock: logos ≈ 0.4–4.7 s and ≈ 4.9–8.4 s, then
  `ADV.wmv` from ≈ 8.9 s. ⚠️ The cyan `SQUARE ENIX` at ≈ 9.5 s is the
  **movie's** opening, not a third splash screen.
* **Sprites carry their own labels.** No font rendering or localisation is needed
  for this milestone. ✅ — and the localisation is *already baked in*: the
  Japanese screens are separate builds in the same pak, not a text swap.

## Facts the port will trip over

* **`ADV.wmv` is WMV3 video + WMA Pro audio**, 1280×720 at 30 fps, 137 s. Godot 4
  plays only Ogg Theora natively. How to handle that is the port's decision, not
  ours — but it is not optional.
* **The disc holds 3.3 GB of video, and exactly two files are in scope:**
  `dat/movie/ADV.wmv` (the boot intro *and* the attract loop — one asset) and
  `dat/movie/S00A.wmv` (the new-game intro, 93.9 s). Named from the movie
  manifest, ✅ decoded.
* **`Static.slb` over-declares its size** by 616 768 bytes — it is the
  highest-offset entry in `sound.pak` and its size field is an allocation size. A
  reader must allow a short read there and only there.
* **Voice downmixes to mono, music does not.** The left-channel downmix is correct
  for spoken lines and discards half a music mix.
* **A music bank is TWO STEMS THAT PLAY TOGETHER — do not concatenate.**
  ✅ The "10 KB + 4.47 MB + 4.67 MB" reading was wrong: the 10 KB is the bank
  header, and a bank is exactly **two waves of identical duration** (32/32 banks
  on the disc). `BGM_001`'s two are **sample-synchronous** — transient
  correlation peaks at lag 0.00 s over ±5 s, and both stop at the same
  millisecond, 167.663 s. Wave 1 is quieter, far more L/R-decorrelated and has
  almost no bass, so it reads as a surround-rear pair or a second intensity
  layer — 🟡 which of those is unsettled, and `ChannelMask` is `0x0002` on both,
  so the file will not say. Today's 347 s concatenation plays the piece twice,
  the second time as a bass-less stem.
  ❔ **And it is not a seamless loop**: `BGM_001` fades out at 167.663 s and is
  followed by 6.15 s of silence, with no loop-point field identified. A menu loop
  is authored.
  ✅ **The menu's music is `BGM_103`.** The cue *table* cannot say — its BGM
  entries are numeric — but `GamePart_Title`'s `sub_821C5580` plays **cue 1103**,
  and `BGM_103.slb`'s two declared waves (3 876 864 / 3 930 112 B) are
  byte-for-byte the two streams the XMA probe saw decoding at the main menu.
  Static code, disc census and runtime all agree. The port does **not** have to
  choose a track.
* **`JNGL_001.slb` does not decode.** One bank in 9 519; its payload is not a whole
  number of XMA1 packets from any known data offset.

## What is still open

Every question above is answered, so this is the honest residue rather than a
work queue. **None of it blocks the five screens.** (Q1's seconds conversion was
here until 2026-08-28 and is now settled.)

| | what | why it is stuck |
|---|---|---|
| 🟡 | **cue NAME → event binding** (Q8) | event→**wave** is measured for move/confirm/back; that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still read off the authors' identifiers |
| ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
| 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen |
| 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
| 🟡 | **the boot transitions in code** (Q6) | both levels decoded — phase at `this+132` (`entry→2`, `2→0`, `2→3`, `3→4`, `4→2`) and state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS Ⓐ`, phase 4 = menu. Unknown: what the event *numbers* mean |
| 🟡 | **Ⓑ leaving the main menu** (Q5) | **upgraded 2026-08-29 (later).** The idle half of this objection is **refuted**: the main menu does not self-return for **≥ 60 s** untouched, and the ~8–10 s idle belongs to the **title**. Ⓑ is delivered (Canary logs `vk=5801`) and is the only input in ≥ 100 s before the return, so the **ordering is measured**; the latency is not (a backlogged probe void). The footer point stands — the main menu is still the only screen not advertising Ⓑ — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md#-refutation-attempt-2026-08-29--the-main-menus-own-footer-does-not-advertise-ⓑ) |
| ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes |

(An earlier version of this table called the audio items blocked on "an emulator
whose audio path can be observed". That was wrong — this build already has
`--xma_param_probe`, and using it settled both.)

⚠️ **A container caveat that bounds all of the above:** the emulator has twice
been killed mid-run with no crash line in its own log (at ~50 s and ~145 s), on a
box sitting at ~1 GB free with swap exhausted. Dynamic experiments here have to
fit in roughly two minutes of guest time, which is why several of these residuals
are unfinished rather than unattempted.

## The player's-eye map of the menus

[`docs/game/navigation.md`](../game/navigation.md) is the screen-by-screen walk
through the game from the chair — every label, what the cursor does, what each
footer offers. It was filled in on 2026-08-29 from the committed oracle frames,
and it is the page to read if you want to know what a screen *looks like* rather
than how its bundle is laid out. Every ✅ there is a capture, and what is still ❔
is what no capture answers.

## Reference data

Committed alongside the findings, so the port can be built without a disc in the
loop during development:

* `sylpheed-cli screen info --build <n> GP_TITLE.pak` — the element table, per
  build, with pivots, kinds, focus links, keyframes and resting poses.
* `sylpheed-cli screen render` — the reference composite. When the port draws a
  screen, this is what it should be diffed against; where they disagree, one of
  them is wrong and the disagreement is worth reporting back.
* `docs/re/captures/` — framebuffer captures of the real screens, for anything
  that has to be checked against the game rather than against our renderer.