sylpheed-port asked which of my figures predate the keyframe record-layout fix,
noting the sharper form of the hazard: a fix that changes WHICH ROWS EXIST is
harder to sweep for than one that changes values, because the recomputation looks
like a correction rather than a different question.
Located the fix (a975517, 2026-08-29 14:01) and enumerated docs quoting
keyframe-derived numbers that have not been touched since. One real hit:
structures/ui-group-start-time.md, a page about group START TIMES, written -- in
its own words -- "under the shifted time reading" and referring to the glows'
"untimed first keyframe".
Durations survive. The glow is visible ~0..45 (45 units) and the logo ~15..210
(195 units), exactly what its table already used; the "~0" it hedged with is now
a real timed 0.
The argument did not. It read "every glow declares the same times 15, 30, 45 ...
both families start at 15". Post-fix both start at 0, with times 0,15,30,45 and
0,15,30,190,194,206,210. Corrected in place with the original sentence quoted so
the change is visible.
The conclusion is unchanged and slightly stronger: on one clock the glow is
visible over 0..45 and the logo over 15..210, an overlap of 30 of the glow's 45
units, where the capture shows no overlap at all (glows frames 94-115, logos
116-211). A shared clock origin was contradicted before and is contradicted by a
wider margin now, because both groups demonstrably begin at the same declared
instant.
Of the three figures the port reports having quoted from me, the splash dwell
spans were already corrected today and the black-gap and cold-boot intervals are
capture-derived, so the fix does not reach them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
de993b39e4