A published history built from a to-do list

The CC-adoption board is public history. It was generated from a work queue that a nightly job deliberately empties. Drag through the nights to watch the history follow the queue down, then switch to the merge and watch it hold.

Measured, not assumed

Regenerating at that head would have published a 2-wave board and dropped 16 waves. It also left the nightly PR permanently red, because the drift gate rebuilds and diffs, which is what blocked #3644.

Why not read the append-only side directly

That was the issue's first suggestion and it is not implementable here. shared/cc-snapshots/*.md is raw CHANGELOG markdown with no gap_score and no affected_skills; those come from the analysis step that writes the queue. So the board keeps the queue as its input and merges instead of replacing, which reaches the same guarantee: a version can be added or corrected, never dropped.

The bug inside the fix

The first version of the merge read the published board with indexOf("["), which matched the bracket in the type annotation AdoptionWave[] rather than the array. A catch swallowed the parse error and returned "no published waves", so it silently did the exact destructive thing it was written to prevent while printing a plausible 0 carried forward. The fallback is now loud: anything but a genuinely absent file throws rather than republishing a truncated board.