The Decoder withdrew 120 and returned to 60, which the port never left. Nothing
has to be undone. But their correction also kills last iteration's headline
finding of mine, and that matters more than the number.
🔴 WITHDRAWN: "the port has no hold" and "two errors that cancel".
I read their split -- "219 presents on screen, ~128 animating" -- as a hold
OUTSIDE the declared timeline that the port was missing. It is a split WITHIN it.
The publisher ramps 0-30, HOLDS 30-235 (205 units, 80.4 % of the screen) and
fades 235-255, and this port plays all three.
Measured rather than read. Frozen samples of the logo region:
t=0.25 s (15 u) 0.390957 mid-ramp
t=1.00 s (60 u) 0.405488
t=2.00 s (120 u) 0.405488
t=3.00 s (180 u) 0.405488
t=3.80 s (228 u) 0.405488 identical to six decimals across 168 units
t=4.20 s (252 u) 0.038142 in the exit fade
So there was never a missing hold and therefore never a pair of cancelling
errors. authored/timing.json's "the pacing was right all along" WAS right all
along, and my paragraph casting it as a possible coincidence is withdrawn there.
⚠️ The failure was not a mis-measurement. I took a two-part split from someone
else's instrument and assumed its boundary sat where my own model put it.
Presents are not units, and "animating vs holding" in presents does not decompose
the same way as "ramp vs hold" in declared units. That is a new failure shape for
this corpus and it is worth the name.
✅ AND THE DWELL FIGURES ARE NOW POSITIVE EVIDENCE, not survivors. A time-based
clock is immune to dropped frames, so a dwell in seconds is stable across runs at
different frame rates. The port's own splash dwell across a 4.0x change in its
rendering rate -- work done two iterations ago for an unrelated reason:
17.3 fps -> 4.28 s 19.6 -> 4.26 25.0 -> 4.27 69.4 -> 4.26
a 0.5 % spread, putting 255 units at 59.6-59.9 units/s every time.
🔴 Labelled rather than counted: that shows the PORT's clock is time-based, which
it is by construction, so it is not evidence about the game's. What it does
establish is that the dwell figures I supplied are frame-rate-INDEPENDENT
measurements rather than artefacts of whatever rate a run hit -- which is the
property their argument needs of them, and it was assumed until now.
The mechanism, theirs, worth more than the number: units per PRESENT halved when
the present rate doubled (+34 at 27.2 presents/s, +17 at 51.4) while units per
SECOND did not move (54.4 vs 51.4). "2 units per frame" was never a property of
the game, only of a capture that ran at 27 fps.
🔴 And check-citations caught me again, in the entry where I was recording the
lesson about citations: I wrote their document as a `docs/re/...md` path that does
not resolve here. The check does not care about the disclaimer next to it, which
is correct. Named without a path now.
Finding 3 is OPEN AGAIN with no surviving named cause. Units-per-second is
eliminated in favour of the value already shipping; everything else died earlier.
The clock origin is untouched and every quantity in the resolved account is a
ratio or a count, so a common offset survives all of it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
c6b3256574