re: RETRACT the splash settle windows -- --build takes an ORDINAL, not an entry

The port recomputed the publisher splash's widest keyframe-free gap as 190 units
against my 8 and said one reading must be wrong. Mine was, and the library was
never wrong -- only my invocation.

From the file: entry 10's union of times is [0,15,30,45,235,239,251,255], widest
gap 190, and settle_window() returns Some((45,235)). Entry 11 gives 145. Both
match the port exactly.

The cause is that screen render --build N takes a BUILD ORDINAL. screen list says
[10] entry 12 and [11] entry 15; the splashes are entries 10 and 11 and are not
screen builds at all, so my --build 10/11 rendered the LOADING screens. This is
the foot-gun HANDOFF already documents, which the port caught months ago in the
mirror direction.

Three retractions:

1. 'Width does not predict quality' -- withdrawn. It rested entirely on the
   splashes being width 8 while winning 75x. They are the widest of the five, so
   width and mid-ramp are perfectly confounded across every screen either of us
   has measured and the width hypothesis is NOT refuted.

2. 'My filter excluded the splashes' -- withdrawn; at 190 and 145 they were never
   near the 10-unit cutoff. The other half stands: it admitted the 10-19 bucket,
   the worst at 45.1 %.

3. The splash rows of settle-vs-rest-against-captures -- void. They scored
   loading-screen renders against splash captures. I discarded them for a railed
   gamma fit; the real reason is that they were the wrong screens, and the railing
   was that mismatch surfacing where my instrument could report it.

Surviving: the title row (ordinal 4 = entry 4) and the disc-wide censuses, which
iterate pak entries directly and never touch the ordinal path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

crates/sylpheed-formats/examples/settle_window_check.rs

@@ -0,0 +1,27 @@
+//! Where does `settle_window()`'s answer come from? The port agent recomputes the
+//! publisher splash's widest keyframe-free gap as 190 units; `--settle` reports 8.
+//! One of the two readings is wrong and the file settles it.
+//!     cargo run -p sylpheed-formats --example settle_window_check -- <build>
+use sylpheed_formats::{pak::PakArchive, ui_layout};
+use std::path::PathBuf;
+fn main() {
+    let b: usize = std::env::args().nth(1).unwrap_or("10".into()).parse().unwrap();
+    let root = PathBuf::from(std::env::var("SYLPHEED_DISC").expect("SYLPHEED_DISC"));
+    let ar = PakArchive::open(root.join("dat/GP_TITLE.pak")).expect("GP_TITLE");
+    let by = ar.read(&ar.entries()[b]).expect("entry");
+    let build = ui_layout::parse_build(&by).expect("parse");
+    println!("entry {b}: {} elements", build.elements.len());
+    for el in &build.elements {
+        let ts: Vec<String> = el.keyframes.iter()
+            .map(|k| k.time.map(|v| v.to_string()).unwrap_or("-".into())).collect();
+        println!("   {:26} [{}]", el.name, ts.join(" "));
+    }
+    let mut ts: Vec<u32> = build.elements.iter()
+        .flat_map(|e| e.keyframes.iter().filter_map(|k| k.time)).collect();
+    ts.sort_unstable(); ts.dedup();
+    println!("\nunion of all element keyframe times: {ts:?}");
+    let gaps: Vec<(u32,u32,u32)> = ts.windows(2).map(|w| (w[1]-w[0], w[0], w[1])).collect();
+    let mut g = gaps.clone(); g.sort_by(|a,b| b.0.cmp(&a.0));
+    println!("widest gaps: {:?}", &g[..g.len().min(4)]);
+    println!("settle_window() reports {:?}", build.settle_window());
+}

docs/re/data/splash-settle-window-retraction.txt

@@ -0,0 +1,54 @@
+# RETRACTION: the splash settle windows are 190 and 145, not 8 -- and the
+# width hypothesis is NOT refuted. 2026-08-30.
+#
+# The port agent recomputed the publisher splash's widest keyframe-free gap
+# as 190 units against my reported 8, and said one reading must be wrong.
+# It was mine, and the library was never wrong -- only my invocation.
+#
+# examples/settle_window_check.rs, straight from the file:
+#
+#   entry 10  palogo_sqex.t32      [0 15 30 235 239 251 255]
+#             palogo_sqex_eff.t32  [0 15 30 45]
+#     union [0,15,30,45,235,239,251,255]  widest gap 45->235 = 190
+#     settle_window() -> Some((45, 235))          <- 190, matches the port
+#
+#   entry 11  union [0,15,30,45,190,194,206,210]  widest gap 45->190 = 145
+#     settle_window() -> Some((45, 190))          <- 145, matches the port
+#
+# 🔴 THE CAUSE: 'screen render --build N' takes a BUILD ORDINAL, not a pak
+# entry. screen list says so directly:
+#     [10] entry 12    [11] entry 15
+# The splashes (entries 10 and 11) are not screen builds at all. My
+# '--build 10' and '--build 11' rendered the LOADING screens.
+#
+# This is the foot-gun HANDOFF already documents -- the port caught it months
+# ago, writing that an ordinal-keyed '10'/'11' names the publisher wordmark
+# and developer logos as loading screens 'and everything still validates'.
+# I walked into the mirror image of it.
+#
+# WHAT THIS RETRACTS:
+#
+# 1. 'Width does not predict quality' -- WITHDRAWN. It rested entirely on the
+#    splashes being width 8 while winning 75x. They are width 190 and 145,
+#    the WIDEST of the five screens. Width and mid-ramp are now perfectly
+#    confounded across every screen either of us has measured, exactly as the
+#    port said. The port's predictor may still be the mechanism; this evidence
+#    does not establish it over width.
+#
+# 2. 'My rest_vs_settle filter excluded the splashes' -- WITHDRAWN. At 190 and
+#    145 they were never near the 10-unit cutoff. The filter's other fault
+#    stands: it admitted the 10-19 bucket, the worst at 45.1 % mid-ramp.
+#
+# 3. The splash rows of settle-vs-rest-against-captures.txt -- VOID. They
+#    scored LOADING-SCREEN renders against SPLASH captures. I discarded them
+#    for a railed gamma fit; the real reason is that they were the wrong
+#    screens, and the railing was that mismatch showing up in the only place
+#    my instrument could report it.
+#
+# ✅ WHAT SURVIVES: the title row (build ordinal 4 = entry 4, correct), where
+#    settle beats rest 4.6x on differing area at an interior gamma. And the
+#    disc-wide censuses, which iterate pak entries directly and never touch
+#    the ordinal path.
+#
+# ⚠️ To render a splash: entries 10/11 need 'screen render --all', which
+#    renumbers --build over every composable bundle.

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

@@ -434,9 +434,19 @@ Disc-wide, elements caught **mid-ramp** at their screen's settle instant
 | ≥ 60 | 3 646 | 548 | 15.0 % |
 | **all** | **13 991** | **3 572** | **25.5 %** |
 
-🔴 **The obvious reading — "a narrow window means the settle pose is bad" — is
-refuted by the very screens that motivated the proposal**, and I nearly published
-it:
+🔴 **WITHDRAWN 2026-08-30 — the table below is wrong and so is the conclusion I
+drew from it.** `screen render --build N` takes a **build ordinal**, not a pak
+entry: `screen list` says `[10] entry 12`, `[11] entry 15`. The splashes are
+entries 10 and 11 and are **not screen builds at all**, so my "`--build 10/11`"
+windows of 8 are the **loading screens**. From the file the splashes are **190** and
+**145** — the *widest* of the five, not the narrowest
+([`../data/splash-settle-window-retraction.txt`](../data/splash-settle-window-retraction.txt)).
+
+**So width and mid-ramp are perfectly confounded across every screen either agent
+has measured, and the width hypothesis is NOT refuted.** The port's predictor may
+still be the mechanism; this evidence does not establish it over width.
+
+The withdrawn reading, kept because the mistake is instructive:
 
 | build | screen | window | port's measurement |
 |---|---|---|---|
@@ -445,16 +455,13 @@ it:
 | **10** | **publisher** | **8** | settle wins **75×** |
 | **11** | **developer** | **8** | settle wins **33×** |
 
-The splashes are **narrower than the menu** and the settle pose wins by 75×. Width
-does not predict quality. The predictor is the port's own: it wins decisively where
-`rest()` lands on a **transient's peak**, and loses slightly where `rest()` is
-already sound and an element **arrives after the window closes**.
+~~The splashes are narrower than the menu and the settle pose wins by 75×.~~ **They
+are wider. The rows read 8 because they are the loading screens.**
 
-🔴 **And my `rest_vs_settle` filter was wrong in both directions.** Dropping bundles
-with a window under 10 units admitted the **10–19** bucket — the *worst*, at 45.1 % —
-and **excluded both splashes at width 8**, the strongest evidence *for* the proposal.
-A threshold taken from a documented rule of thumb and applied without checking which
-screens it admitted and which it threw away.
+⚠️ **One half of the filter criticism survives**: dropping bundles with a window
+under 10 units admitted the **10–19** bucket, the *worst* at 45.1 % mid-ramp. The
+other half — that it excluded the splashes — is withdrawn; at 190 and 145 they were
+never near the cutoff.
 
 ### 🔴 Losing the example did not close the question — it is larger than one element