Two warnings. The first does not reach me: nothing is authored from
screen-transitions.md's 0.87/0.97/4.08 s spans, and nothing in this port reads
keyframe times outside the crate -- their stale fade_quads.py failure mode cannot
occur here by construction.
The second is about black_hold_units: 9. Testing their structural claim on my
export: pteff00 on main_menu is [0:a255 12:a0 70:a0 80:a255], rising to black over
70->80, while content fade-outs start at 58-60. That is 12 units of lead, exactly
six frames at 30 Hz, matching their measurement off the running game -- disc and
capture agreeing by independent routes. They say the two overlap; mine has a
2-unit gap, one frame, inside their stated resolution.
The arithmetic: quad ramp 10 units + my authored 9 = 19 units = 0.317 s against
their measured blackout of 18 units = 0.30 s. One unit apart, inside their own
resolution. The measurement that withdrew the 14 supports my 9.
It survived because I declined to author the 14 when the arithmetic was available
and fit -- I wrote that it was arithmetic rather than a measurement and left the
value where it had been measured. Had I adopted the composition I would now carry
24 units against a measured 18, which is the dead black they are warning about.
Not adjusting 9; one transition, one run, +/-1 frame.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
1df492208b