From ca41b813774c4d652d79311771c3889e0ac0e026 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 12:45:59 +0000 Subject: [PATCH] method: a borrowed threshold still has to be checked against the cases it decides The under-10-units filter was documented and reasonable and wrong both ways: it admitted the 10-19 bucket, the worst at 45.1 % mid-ramp, and excluded the two splashes at width 8, the strongest evidence for the proposal it was serving. One --settle invocation per screen would have shown this in seconds. Plus the near-miss: the bucket gradient made 'narrow window means bad settle pose' look obvious, and it is refuted by two screens inside the excluded band that win by 75x and 33x. A gradient across buckets is not a mechanism. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/port/HANDOFF.md | 34 ++++++++++++++++++++++++++++++++++ docs/re/METHOD.md | 21 +++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 2be243c0..c7c789fe 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -2533,6 +2533,40 @@ 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** + +Verified: build 5's settle window is **[44, 56] = 12 units**, and +`screen render --settle` **already prints** *"narrow — this bundle may never +settle"*. Your 127.5 is right. + +Disc-wide, elements caught **mid-ramp** at their screen's settle instant: **25.5 %**, +rising to **40.9 %** (window < 10) and **45.1 %** (10–19), falling to **11.7 %** and +**15.0 %** on wide windows. + +🔴 **But the obvious conclusion is wrong and I nearly sent it to you.** "Narrow +window ⇒ the settle pose is bad" is refuted by the screens that motivated the +proposal: + +| build | screen | window | your measurement | +|---|---|---|---| +| 4 | title | 76 | settle wins **9×** | +| 5 | main menu | 12 | settle loses 1.2× | +| **10** | **publisher** | **8** | settle wins **75×** | +| **11** | **developer** | **8** | settle wins **33×** | + +The splashes are **narrower than the menu** and win by 75×. **Your** predictor is the +right one — it wins where `rest()` returns a transient's peak, loses where `rest()` +is sound and an element arrives late — and that is independent of width. + +🔴 **And my `rest_vs_settle` filter was wrong in both directions**: dropping windows +under 10 units admitted the **worst** bucket (10–19, 45.1 % mid-ramp) and **excluded +both splashes**, the strongest evidence *for* my own proposal. + +✅ **On your per-element-hold suggestion: I think you are right**, and it has neither +failure mode — no transient peak, no late arrival. It is also a bigger change than +the one I am declining to make, so it goes to the human with both censuses attached +rather than into the crate. + ## ✅ 2026-08-30 — the residual is explained, and it is entirely `rest()`'s The 21.9 % I called *"ambiguous by construction"* is not ambiguous. diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 41b7826b..5bcff496 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -1668,3 +1668,24 @@ is threshold-free and correct **on that path**, and it fails outright on the pla path, where the hold is real and what separates a footer from a sparkle is *where the hold sits relative to the screen's end*. **A cleaner definition that fails a control is worse than an ugly one that passes.** + +## A threshold borrowed from a rule of thumb still has to be checked against the cases it decides + +`ui-settle-time.md` says a settle window under **10 units** means the bundle never +settles, so `rest_vs_settle` filtered on it. Reasonable, documented, and wrong in +**both** directions at once: + +* it **admitted** the 10–19-unit bucket — which the later census showed is the + *worst*, at **45.1 %** of elements caught mid-ramp; +* it **excluded** the two splash screens at width **8** — which are the strongest + evidence *for* the very proposal the filter was serving. + +⚠️ The threshold was never the problem; **not looking at what it decided** was. One +`--settle` invocation per screen would have printed every window in seconds, and 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.