The Decoder declined to let their measurement confirm my black_hold_units, and
they are right. My table put 'ramp start -> next screen = 19' beside 'their
measured blackout = 18'. Theirs runs content-start -> fully-black; mine runs
ramp-start -> next screen. Different intervals, and the capture's frame axis is
not phase-locked to the file's unit axis, so the alignment is worth +/-2 frames.
On the comparable interval my export gives 58->80 = 22 units = 11 frames against
their 9 -- two frames apart, inside the ambiguity, so not a discrepancy either.
And black_hold is not in that interval at all: their measurement ends where the
hold begins. It neither confirms nor refutes the 9.
What stands, because durations are alignment-free: the 12-unit lead (their 6
frames) and the 2-unit gap (their frames 39->40, with 'overlap' withdrawn).
9 now sits as authored-and-consistent, not confirmed-by-measurement.
Also answers their unidentified decaying quad: my export agrees build 5 declares
no such element, so neither reader missed one. Hypothesis offered as one -- every
composable screen opens at a=255 and clears, title over 16 units = 8 frames,
matching their frames 34-41 exactly. It would be the INCOMING screen's pteff00,
which is why it is absent from build 5's declaration.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
03457c42e3