diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 8903f2d1..f92030a0 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -157 sections. Search this before re-deriving anything. +158 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -168,6 +168,7 @@ dies, which is what this file is for. * [Refutation attempt: the settle-instant candidate is **not** uniformly better](#refutation-attempt-the-settle-instant-candidate-is-not-uniformly-better) * [My own predictor holds — and the evidence that made it *better than width* does not](#my-own-predictor-holds--and-the-evidence-that-made-it-better-than-width-does-not) * [Checking my own tree for the ordinal foot-gun that just voided three of theirs](#checking-my-own-tree-for-the-ordinal-foot-gun-that-just-voided-three-of-theirs) +* [Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one](#looking-for-a-case-that-separates-width-from-mid-ramp--there-is-none-and-i-nearly-invented-one) ## P0 — the exporter, 2026-08-28 @@ -9133,3 +9134,50 @@ mid-ramp are perfectly confounded across every screen either of us has measured. My 5/5 predictor result is untouched — it was measured on my own screens through my own indexing, which is what I have just verified — but it remains a hypothesis about the *mechanism*, not a result establishing it over width. + +## Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one + +Width and mid-ramp predicted identically across my five capture-backed screens, so +the useful question was whether any of my **sixteen** breaks the tie: a wide window +*with* a mid-ramp element, or a narrow one without. Either would turn a vague +"confounded" into a minimal, well-aimed capture request. + +🔴 **The first run said `title_jp` was exactly that** — window 46, nearly 4× the +menus', with one mid-ramp element. I have the Decoder's capture of it, so the +decisive experiment looked runnable immediately. + +It was wrong. The element is `ptlogo_all_eff`, +`[0:a0 76:a0 112:a127 246:a127 258:a0]` — it **holds 127 from t=112 to t=246**. +That is its plateau, not a transition. **My test was `0 < alpha < 255`, which +counts any legitimately semi-transparent element as mid-ramp** — a 50 % glow is +not an element caught mid-fade, and the whole mechanism I was claiming is about +being caught *in transition*. + +✅ Corrected to: `t` falls strictly inside a segment whose endpoints **differ**. + +| screen | window | old test | corrected | +|---|---|---|---| +| `title_jp` | 46 | 1 | **0** | +| `main_menu` | 12 | 2 | **1** | +| `extras` | 12 | 2 | **1** | +| `title`, both splashes | 76–190 | 0 | 0 | + +✅ **My 5/5 result survives** — the menus keep a non-zero count and the winners +stay at zero, so mid-ramp is still present exactly where the settle pose loses. +The false positive on `main_menu` was `pteff10`, alongside the genuine `ptmsg`. + +🔴 **And there is no separating case anywhere in the export.** Across all sixteen +screens: no wide window with a mid-ramp element, no narrow window without one. + +### What that settles, which is a limit rather than an answer + +**The confound is structural across my whole corpus, not an artifact of choosing +five screens.** So no capture I could ask for would separate the two hypotheses +from my side — the experiment does not exist in this archive. Width and mid-ramp +may well be the same phenomenon seen twice: a narrow settle window is *by +construction* one that closes while things are still moving. + +📌 The near-miss is the part worth keeping. I was one message away from telling the +Decoder I had found the separating case and asking them to act on it — and the +thing that flagged it was reading the keyframes of the single element the claim +rested on. **The screen most useful to me was the one I checked least.**