diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index fe03990c..6a02c617 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -862,3 +862,26 @@ the game, not about my renderer. units/frame simply not apply to them? And note the two-strip agreement constrains the strips to each other, not the absolute rate -- both ratios come from one capture under one fps assumption, and 1 unit per 1/30 s at 28.5 fps gives 1.053. + +### `black_hold_units`: 0 is now wrong on 4 of 5 transitions, and every alternative is a fit + +**Derived from Decoder `auto/build-ordinal-audit` plus my own `verify-dwell`.** + +Measured gaps: 0, 4, 6, 6 units (theirs) and ~7.9 (mine, from the port running +0.131 s short on publisher->developer). Four of five non-zero, mean 6.0. + +My authored 0 was justified as "adds no black the game does not have". That +justification has failed: it now omits a real quantity on most transitions. A +uniform 4 or 6 halves the total error but is a fit on five samples with no +mechanism. I attempted a rule -- gap plus the incoming screen's opening +black-clear summing to a constant -- and it holds at 16/16/18 on the three +menu/title transitions and fails outright on the splash pair, whose backdrop never +clears. + +**The ask, and it is a decision rather than a measurement:** is a uniform +non-zero hold preferable to omitting the gap, given neither is derivable? If a +fifth transition of a *different* shape (screen-to-screen rather than menu) is +ever measured, that would test the constant-black-period idea properly. + +Value stays 0 meanwhile; `verify-dwell` reports the shortfall rather than +absorbing it. diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index f2f9f91d..98848aba 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -195 sections. Search this before re-deriving anything. +196 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) @@ -206,6 +206,7 @@ dies, which is what this file is for. * [Auditing `--black`, and a rule that falls out of it](#auditing---black-and-a-rule-that-falls-out-of-it) * [🔴 CORRECTION: my backdrop predicate is exact in `GP_TITLE` and its reading was wrong](#correction-my-backdrop-predicate-is-exact-in-gp_title-and-its-reading-was-wrong) * [Sweeping my own `--help` and headers, after theirs](#sweeping-my-own---help-and-headers-after-theirs) +* [`black_hold_units`: my own tripwire has tripped, and I am not resolving it alone](#black_hold_units-my-own-tripwire-has-tripped-and-i-am-not-resolving-it-alone) ## P0 — the exporter, 2026-08-28 @@ -10997,3 +10998,60 @@ record-layout fix may have a population that moved, not just a value.* My export is post-fix (verified: `[0,12,70,80]`, `rest t=12`) and my censuses were run on it, so my own counts are sound. **Figures of theirs that I have quoted are not something I can audit from here.** + +## `black_hold_units`: my own tripwire has tripped, and I am not resolving it alone + +I set the value to 0 with an explicit condition: *"if the gap is non-zero in most +transitions and no rule emerges, systematically omitting a real quantity is no +longer the cautious choice — it is a different invention. Revisit at the next +measurement that is not 0, or the moment a rule appears."* + +**Both halves of the first clause now hold.** Five measurements: + +| transition | gap | +|---|---| +| menu → title | **0** | +| title → menu | 4 | +| EXTRAS → menu | 6 | +| their fourth | 6 | +| publisher → developer *(from my own `verify-dwell` shortfall)* | **~7.9** | + +**Four of five non-zero, mean 6.0 units.** The fifth is mine and arrived by a +different route — the port running 0.131 s short of the oracle's span on a real +boot transition, which `verify-dwell`'s slack had been absorbing. + +### The rule attempt, which failed + +If a rule existed, changing the value would be principled rather than fitted. The +candidate: does the incoming screen's **opening black-clear** absorb part of a +fixed black period? + +| transition | gap | incoming clear | sum | +|---|---|---|---| +| main_menu → title | 0 | 16 | **16** | +| title → main_menu | 4 | 12 | **16** | +| extras → main_menu | 6 | 12 | **18** | +| publisher → developer | 7.9 | **0** (never clears) | **7.9** | + +🟡 Suggestive on the three menu/title transitions — 16, 16, 18, consistent with a +constant given ±1 frame of measurement. 🔴 **It fails on the splash pair**, whose +backdrop is a single keyframe at alpha 255 and never clears at all. Three points +fitting a constant with one outlier is not a rule; it is a fit with an exception, +which is the error this corpus has spent the week cataloguing. **Not adopted.** + +### Why I am escalating rather than choosing + +⚠️ **My justification for 0 has failed on its own terms.** "It adds no black the +game does not have" was true when 1 of 3 measurements was zero. With 4 of 5 +non-zero, 0 **omits** a real quantity on most transitions — which my own tripwire +called *a different invention*. + +⚠️ **And the alternative is a fit.** A uniform 4 or 6 halves the total error +(8 against 16) and is chosen for its residual on five samples with no mechanism. + +Both options now invent something, and the mission's rule is that I **do not adopt +on my own authority** — so this goes to `BLOCKED.md` with the numbers rather than +being settled by whichever error I find more comfortable. ✅ The value stays at 0 +**pending that**, and `verify-dwell` now reports the resulting shortfall explicitly +instead of hiding it in slack, so the cost of leaving it is visible in the tool +rather than only here.