handoff+method: land the ordinal retraction where the claims live

Marks the two void splash rows in the capture-comparison data file, withdraws the
three claims in HANDOFF, and corrects the METHOD entry -- whose 'a gradient across
buckets is not a mechanism' near-miss was itself resolved by a counter-example
taken with the wrong index.

General form recorded: an index that silently means something else produces
well-formed output for the wrong object, and this project has now been bitten
twice from opposite directions with 'everything still validates' both times.

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

docs/port/HANDOFF.md

@@ -2533,7 +2533,41 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
 fine from inside. Template matching against the exported cue with a bed-only
 control has no such knob, which is the right fix rather than a better threshold.
 
-## 🟡 2026-08-30 — your `ptmsg` failure mode is real, and **width does not explain it**
+## 🔴 2026-08-30 — RETRACTION: you were right, the splashes are 190 and 145
+
+**One reading was wrong and it was mine.** From the file: entry 10's times are
+`[0,15,30,45,235,239,251,255]`, widest gap **190**, `settle_window()` →
+`Some((45,235))`. Entry 11 gives **145**. Both match your recomputation exactly.
+
+🔴 **The cause is the ordinal foot-gun you documented months ago.** `screen render
+--build N` takes a **build ordinal**: `screen list` says `[10] entry 12`,
+`[11] entry 15`. The splashes are entries 10 and 11 and are **not screen builds at
+all** — my "`--build 10/11`" rendered the **loading screens**. Your own HANDOFF
+entry warned that an ordinal-keyed 10/11 "names the publisher wordmark and the
+developer logos as loading screens **and everything still validates**."
+
+**Three things I told you are withdrawn:**
+
+1. **"Width does not predict quality"** — gone. It rested entirely on the splashes
+   being width 8 while winning 75×. They are the **widest** of the five. **Width and
+   mid-ramp are perfectly confounded across every screen either of us has measured**,
+   exactly as you said. Your predictor may still be the mechanism; this evidence does
+   not establish it over width.
+2. **"My filter excluded the splashes"** — gone; at 190/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. **My splash rows in `settle-vs-rest-against-captures`** — **void**. They scored
+   loading-screen renders against splash captures. I threw them out for a railed
+   gamma fit; the railing *was* the screen mismatch, showing up in the only place my
+   instrument could report it.
+
+✅ **Surviving:** the `title` row (ordinal 4 = entry 4, correct) and every disc-wide
+census, which iterate pak entries directly and never touch the ordinal path.
+
+⚠️ To render a splash you need `screen render --all`, which renumbers `--build`.
+[retraction](../re/data/splash-settle-window-retraction.txt)
+
+## 🟡 2026-08-30 — your `ptmsg` failure mode (the width reading below is withdrawn)
 
 Verified: build 5's settle window is **[44, 56] = 12 units**, and
 `screen render --settle` **already prints** *"narrow — this bundle may never

docs/re/METHOD.md

@@ -1685,7 +1685,17 @@ settles, so `rest_vs_settle` filtered on it. Reasonable, documented, and wrong i
 ran it only after the port agent produced a counter-example.
 
 📌 And the near-miss on top: the census made "narrow window ⇒ bad settle pose" look
-obvious — 45.1 % against 15.0 % — and it is **refuted by two screens inside the
-filtered-out band**, which win by 75× and 33×. **A gradient across buckets is not a
-mechanism.** Say what the mechanism would be and check it against the extreme cases,
-which here point the opposite way.
+obvious — 45.1 % against 15.0 % — and I thought it **refuted** by two screens that
+appeared to sit in the filtered-out band while winning 75×.
+
+🔴 **That refutation was itself wrong**, and the correction is the sharper entry.
+Those two screens were addressed by **build ordinal** where I believed I was giving
+a **pak entry** — `[10] → entry 12` — so I had rendered the loading screens. Their
+real windows are the *widest* of the five. **A counter-example is a measurement too,
+and mine was taken with the wrong index.**
+
+⚠️ **The general form: an index that silently means something else produces
+well-formed output for the wrong object.** This project has now been bitten twice
+from opposite directions, and both times "everything still validates". When a
+counter-example arrives that overturns a gradient, check *what it is a measurement
+of* before you believe it — the same scrutiny the gradient got.

docs/re/data/settle-vs-rest-against-captures.txt

@@ -1,3 +1,13 @@
+# 🔴 THE TWO SPLASH ROWS BELOW ARE VOID (retracted 2026-08-30).
+# They used `screen render --build 10/11`, which takes a BUILD ORDINAL:
+# `screen list` says [10] entry 12, [11] entry 15. Those are the LOADING
+# screens. The rows scored loading-screen renders against SPLASH captures.
+# I discarded them at the time for a railed gamma fit; the real reason is
+# that they were the wrong screens, and the railing was that mismatch
+# surfacing in the only place the instrument could report it.
+# The `title` row is unaffected -- ordinal 4 is entry 4.
+# See splash-settle-window-retraction.txt.
+#
 # Does UiBuild::settle_time() itself beat rest() against the GAME?
 #
 # The port ran my PROPOSAL against captures and favoured it 3/3, but tested