port: black_hold_units tripwire has tripped; escalating rather than choosing

I set the value to 0 with an explicit condition: revisit at the next measurement
that is not 0, or the moment a rule appears. Five measurements now exist -- 0, 4,
6, 6 from the Decoder and ~7.9 from my own verify-dwell shortfall, which arrived
by a different route when the tool stopped absorbing it into slack. Four of five
non-zero, mean 6.0.

Attempted a rule so that any change would be principled rather than fitted: does
the incoming screen's opening black-clear absorb part of a fixed black period? Sums
are 16, 16, 18 on the three menu/title transitions -- suggestive given +/-1 frame --
and 7.9 on the splash pair, whose backdrop is a single keyframe at alpha 255 and
never clears. Three points fitting a constant with one outlier is a fit with an
exception, not a rule. Not adopted.

So my justification for 0 has failed on its own terms -- it now omits a real
quantity on most transitions, which the tripwire called a different invention --
and the alternative is a fit chosen for its residual. Both invent, so this goes to
BLOCKED.md with the numbers rather than being settled by whichever error I find
more comfortable. Value stays 0 pending that, with verify-dwell reporting the
shortfall.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 17:54:28 +00:00
parent 02ab62e28d
commit 03baa7f792
2 changed files with 82 additions and 1 deletions

View File

@@ -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.

View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
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)
<!-- /INDEX -->
## 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.