TWO THINGS, and the first is that nothing needed changing.
The Decoder withdrew one of the two legs under its settle-time run: the plate
pulse period it had offered as proof the run was not slowed rests on one interval
at a 125 ms sample rate, and re-picking the troughs gives 2.628 s rather than
2.369 -- an adjacent local minimum counted as a separate trough. It cannot
resolve a real-time factor below ~7%.
Nothing in the port moves, because the numbers that correction touches were
already unauthored. Checked rather than remembered: grep over authored/ and
port/scripts/ finds no 0.531 and no 0.482. The only build-in reference in the
tree is the plate arithmetic t=118 -> t=238, 120 units, which is the anchored leg
-- it agrees with three prior readings and with the disc's own declaration.
I had declined those two as one-run figures the Decoder itself flagged, with the
port already within ~0.1 s from the disc's keyframes. That reasoning now has a
second, independent justification I did not have at the time: a few per cent of
slowdown sits inside them undetected.
SECOND: `tools/port/verify-dwell`. Last iteration's hand comparison refuted a red
flag I had filed myself -- `rest.t` is the wrong settle landmark, but "everything
the sequencer paces off it is therefore late" was false and I nearly re-paced
screens that already matched the game to 0.05 s. That check existed once, in a
transcript. Now it runs.
Its header carries the trap it exists to prevent, because that is the whole
point: a port's TRANSITION TIMESTAMPS and the oracle's VISIBLE SPANS are not the
same quantity, and differ by the exit ramp plus the black hold -- about 0.6 s,
the entire discrepancy. The same confusion cost this corpus 0.48 s on the plate
delay.
The bar is the oracle's own run-to-run spread plus one film interval. Three cold
boots of the real game differ by 0.3 s, so agreeing more tightly than the oracle
agrees with itself would mean nothing. The developer-logo span reads 3.50 s on
the hand-run and 3.75 s here, one interval apart and both inside the bar -- the
tool reporting its resolution rather than hiding it. The oracle's numbers are in
the script as a labelled test fixture citing their RE document; nothing in the
port derives them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
528043ef88