re(ui): a static composite is only meaningful for a screen that settles

The model's sharpest prediction, tested with its control. The draw log
says that on the developer splash the _eff glows are drawn on frames
94-115 and the logos on 116-211, so at the moment the reference capture
was taken EVERY glow is already finished -- including the two that have
plateaus and which rest_plateau therefore renders visible. Suppressing
them should help on the splashes and hurt where a screen genuinely
settles.

  publisher splash   +0.9604 -> +0.9982   +0.0377
  developer splash   +0.9659 -> +0.9980   +0.0321
  title    (control) +0.9500 -> +0.9480   -0.0020
  main menu(control) +0.9460 -> +0.8544   -0.0916
  EXTRAS   (control) +0.9440 -> +0.8370   -0.1070

Both splashes jump to about 0.998; all three persistent screens get
worse. The control is what makes this a finding rather than a
coincidence: the same edit helps exactly where the model says it should
and hurts exactly where it says it should not.

So rest_plateau is not over-drawing in general -- it over-draws on
TRANSIENT screens. A plateau mid-animation means the element is held at
that point in the timeline, not that it is on screen once the screen has
settled. Where a screen settles, the held pose IS the settled pose and
the rule is measurably right.

And that answers the question left open several iterations ago -- what
"rest" means for a transient element. It does not mean anything: the
splashes never rest. A static composite of them can match a chosen frame,
and about 0.998 is what these captures' frame is worth, but the format
does not answer a question the screen never poses.

For the port: play the timeline for the two splashes, which the settled
keyframe timing now supports, and composite statically for title, main
menu and EXTRAS.

METHOD: an edit that improves one set of cases is only interesting once
you have shown it damages the cases where it should.

crates/sylpheed-formats/examples/plateauless_suppression.rs

@@ -25,7 +25,15 @@ fn main() {
         let bytes = ar.read(&entries[idx]).expect("read");
         let Some(build) = ui_layout::parse_build(&bytes) else { continue };
         // plateau-less = rest() had to guess: no two adjacent keyframes share a pose
+        // Default: suppress plateau-less elements. With SUPPRESS_SUBSTR set,
+        // suppress every element whose NAME contains it instead — used to test
+        // the entry→hold→exit model's prediction that the splash glows are all
+        // finished by the moment the logos are up.
+        let by_name = std::env::var("SUPPRESS_SUBSTR").ok();
         let mask: Vec<bool> = build.elements.iter().map(|e| {
+            if let Some(sub) = &by_name {
+                return !e.name.to_lowercase().contains(sub.as_str());
+            }
             let k = &e.keyframes;
             (0..k.len().saturating_sub(1)).any(|i| {
                 k[i].fade == k[i+1].fade && k[i].scale_x == k[i+1].scale_x

docs/port/HANDOFF.md

@@ -328,6 +328,21 @@ authored version can be deleted.
   ⚠️ 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)
+
 * **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

docs/re/METHOD.md

@@ -787,3 +787,11 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   completion* while the screen is still up. The exit is the dismissal, so a
   displayed screen never reaches its last keyframe. Both claims survive; what was
   wrong was the step between them that I supplied.
+* **The control is what turns a helpful edit into a finding.** Suppressing the
+  `_eff` glows raised both splashes from ≈0.96 to ≈0.998 — on its own that reads
+  as "we over-draw glows". Running the same edit on the three screens that settle
+  made them **worse** (−0.002, −0.092, −0.107), which is what makes the result
+  mean something specific: the over-draw is confined to transient screens, where
+  a plateau mid-animation is not evidence the element is on screen at rest. An
+  edit that improves one set of cases is only interesting once you have shown it
+  damages the cases where it should.

docs/re/REFUTED.md

@@ -555,3 +555,11 @@ neighbourhood, not just the line.
   group is entry → hold → exit and the exit is the screen's *dismissal*: a
   displayed screen sits at the hold, not at its final pose.
   [`ui-resting-pose.md`](structures/ui-resting-pose.md)
+* "`rest_plateau` renders elements the game has already finished with" (as a
+  general claim) → **narrowed by its control.** It holds on **transient** screens
+  only: suppressing the finished glows takes the two splashes from 0.9604/0.9659
+  to **0.9982/0.9980**, while the same edit costs the title 0.002, the main menu
+  **0.092** and `EXTRAS` **0.107**. A plateau mid-animation is evidence the
+  element is held at that point in the timeline, not that it is on screen once the
+  screen has settled — and where a screen does settle, the rule is right.
+  [`ui-resting-pose.md`](structures/ui-resting-pose.md)

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

@@ -603,3 +603,50 @@ for 12.
 plateau-less element's animation has finished by the time the screen is settled.
 The draw log establishes this for the two splash glows (drawn on frames 94–115,
 with the logos on 116–211) and nothing establishes it for the rest.
+
+---
+
+## ✅ A static "rest" composite is only meaningful for a screen that SETTLES
+
+**2026-08-29.** The model's sharpest prediction, tested with its control.
+
+The draw log says that on the developer splash the `_eff` glows are drawn on
+frames **94–115** and the logos on **116–211** — so at the moment the reference
+capture was taken, *every* glow is already finished, including the two that have
+plateaus and which `rest_plateau` therefore renders visible. Suppressing them
+should improve the match. Suppressing them on a screen that genuinely settles
+should make it worse.
+
+| screen | as-is | `eff` elements suppressed | Δ |
+|---|---|---|---|
+| **publisher splash** | +0.9604 | **+0.9982** | **+0.0377** |
+| **developer splash** | +0.9659 | **+0.9980** | **+0.0321** |
+| title *(control)* | +0.9500 | +0.9480 | −0.0020 |
+| main menu *(control)* | +0.9460 | +0.8544 | **−0.0916** |
+| `EXTRAS` *(control)* | +0.9440 | +0.8370 | **−0.1070** |
+
+Both splashes jump to **≈0.998**; all three persistent screens get worse. The
+control is what makes this a finding rather than a coincidence — the same edit
+helps on exactly the screens the model says it should and hurts on exactly the
+ones it says it should not.
+
+### What this settles
+
+**`rest_plateau` is not over-drawing in general — it over-draws on transient
+screens.** A plateau in the middle of an animation is evidence the element is
+held *at that point in the timeline*, not that it is on screen when the screen
+has settled. On a screen that settles, the held pose is the settled pose and the
+rule is right (the controls). On a screen that plays through and leaves, there is
+no settled moment at all, and the reference capture is a picture of one arbitrary
+frame.
+
+⚠️ **So the honest answer to "what is the rest pose of a transient screen" is:
+there isn't one.** The splashes are animations. A static composite of them can
+match a chosen frame — ≈0.998 for the frame these captures hold — but "the
+resting pose" is a question the format does not answer because the screen never
+rests.
+
+✅ For the port: **play the timeline for the splashes**, which the settled
+keyframe timing now supports ([time unit](../ui-keyframe-time-unit.md)). Use a
+static composite for the title, main menu and `EXTRAS`, where the screen does
+settle and `rest_plateau` is measurably right.