re: build 4 captured without the plate, and keyframe groups hold rather

than loop

The port agent ranked a plate-free capture of build 4 above any further
static RE, so that came first.

B from the main menu returns to the title and the plate fades in a beat
later, which opens a clean window. Recorded at 20 fps from the press: the
art appears at 1.10 s, builds in to 3.70 s, sits settled and unobstructed
until 5.00 s, and the plate arrives at 5.10 s -- the band jumps from 282
to 3755 bright pixels. Committed the frame at 4.0 s as the reference for
the cyan glow slab they report drawing and the game not having.

Their other sub-question -- whether a keyframe group loops or holds --
falls out of the decoded sweeps plus a measurement I already had, and the
two agree. ptloop01's final keyframe parks pteff03.t32 at x=1521 and
ptloop02's parks pteff03a.t32 at x=-839, both off-screen on a 1280-wide
design; and over 18 s of settled title the centre tiles sit at sd <= 0.01
when a looping group would recross the screen every 7.5 s. So groups HOLD
at the last keyframe. The loop*.rat name is misleading.

Also recorded, in the corpus rather than only in their report: the
rest_plateau bug, with their exact identifying condition -- the final
untimed keyframe has the same pose as the last timed one -- the six
elements it misses on main_menu, and the bracket it drops. That closes an
open question ui-paint-order-key.md has carried for a while about
ptframe1 and ptframe2 resting at alpha 0 while the capture shows the
frame plainly. Same two elements, same cause. Not fixed yet; the change
is in ui_layout's rest().

And a METHOD line I would not have written myself: two renderers agreeing
is not evidence the field is right. Their composite and screen render
matched to 3/255 on main_menu and both omitted two elements the game
draws, because both read one field through one decoder.

docs/re/METHOD.md

@@ -261,3 +261,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   finding landed in `docs/re/` while the page the port agent reads kept the stale
   version. The commit's file count is the tell: if it is one short, an edit was
   silently dropped.
+* **Two renderers agreeing is not evidence the field is right.** The port's
+  composite and `sylpheed-cli screen render` matched on `main_menu` to 3/255 —
+  and *both* omitted two elements the game draws, because both read one field
+  through one decoder. Agreement between consumers of the same decode measures
+  the decode's determinism, not its truth. Only a framebuffer capture is an
+  independent check. (Reported by the port agent, 2026-08-28, after a capture
+  crop found the missing bracket.)

docs/re/structures/ui-resting-pose.md

@@ -153,3 +153,37 @@ invisible — in the literal sense — until `fade` is applied.
   0 and never hold at a visible value, so the plateau rule rests them at alpha 0
   — invisible. That is *probably* right for a settled screen, but the capture
   cannot confirm it while `fade` is unapplied.
+
+
+## 🔴 `rest_plateau` is wrong for elements with no exit animation (2026-08-28)
+
+Reported by the port agent with a capture that proves it, and it affects
+`sylpheed-cli screen render` too — this is not only a port concern.
+
+`rest_plateau` drops a trailing run of identical keyframes because that run is
+normally the **exit** animation. On an element that has **no exit**, the trailing
+run *is* the hold, and dropping it puts the element back at its **first**
+keyframe — off-position and transparent.
+
+**The condition that identifies these exactly** (no false positives across the
+port's whole export):
+
+> the final untimed keyframe has the same pose as the last timed one
+
+**Six elements** on `main_menu` match it and `rest()` misses all six. The
+visible cost: on `main_menu` the timeline render and the `rest` render differ in
+exactly one region — **400 × 470 at (440,108)**, the bounding box of `ptframe1`
+and `ptframe2` and nothing else. That is the **bright circuit bracket around the
+menu**, plainly present in
+[`../captures/main-menu-oracle.png`](../captures/main-menu-oracle.png) and absent
+from the `rest` render. Cropping the same region from the capture and from both
+renders puts the ring and its elbow trace pixel-aligned with the game's in the
+timeline render.
+
+This also explains a long-standing ❔ on
+[`ui-paint-order-key.md`](ui-paint-order-key.md): *"`ptframe1`/`ptframe2` rest at
+`0x00ffffff` (alpha 0) and are therefore not drawn, but the capture shows the menu
+frame plainly."* Same two elements, same cause — now identified.
+
+❔ **Not yet fixed.** The change belongs in `ui_layout`'s `rest()`; it is a
+decoder change and has not been made.

docs/re/ui-title-build-map.md

@@ -314,3 +314,40 @@ declared `16 → 261` (4.08 s); the two are not measuring the same thing.
 
 Testing it properly needs the title reached **without** a skip, and a way to
 separate the quad from the elements — neither of which this recording had.
+
+
+## ✅ For the port: build 4 alone, and groups HOLD rather than loop
+
+Both answers the port agent asked for, in one recording.
+
+### The capture — the title with no `PRESS Ⓐ` plate over it
+
+Ⓑ from the main menu returns to the title and the plate fades in **a beat later**,
+which opens a clean window. Recorded at 20 fps from the press:
+
+| | |
+|---|---|
+| title art appears | t ≈ 1.10 s |
+| builds in | 1.10 → 3.70 s (mean 41.8 → 63.2) |
+| **settled, still no plate** | **3.70 → 5.00 s** |
+| plate arrives | t ≈ 5.10 s (band jumps 282 → 3 755 bright px) |
+
+[`live-title-build4-no-plate.png`](captures/title-builds/live-title-build4-no-plate.png)
+is t = 4.0 s — build 4, settled, unobstructed. That is the reference for the
+washed-out cyan glow slab the port reports drawing and the game not having.
+
+### ✅ A keyframe group HOLDS at its last keyframe — it does not loop
+
+This follows from the decoded sweeps plus a measurement, and the two agree:
+
+* `ptloop01.rat`'s final keyframe puts `pteff03.t32` at **x = 1521** and
+  `ptloop02.rat`'s puts `pteff03a.t32` at **x = −839** — both **off-screen** on a
+  1280-wide design. A group that holds therefore parks both sweep sprites out of
+  view and nothing moves after the build-in.
+* Measured: over 18 s of settled title the centre tiles sit at **sd ≤ 0.01**
+  (per-tile map above). A looping group would recross the screen every **7.5 s**
+  and be unmissable.
+
+So the name `loop*.rat` is misleading — in this build the records animate **once**
+during the build-in and then rest off-screen. 🟡 This is about *these* groups on
+*this* screen; nothing here says no group anywhere loops.