The adoption queue is a queue, not a ledger

Dropping the stale 2.1.219 parse_failed row from shared/cc-adoption-gaps.json · 2026-08-31

Two files, two jobs, and only one of them is history

shared/cc-adoption-gaps.json          TRANSIENT WORK QUEUE
  what is still waiting for triage. generate-lab-data.mjs:119-134 says so outright.
  A row leaves the queue when it is actioned or when it can never be actioned.

docs/site/lib/generated/cc-adoption-data.ts   THE BOARD, i.e. HISTORY
  merge-adoption-waves.mjs is ADD-ONLY, for exactly this reason: the queue can
  shrink without the published record losing a wave.

Confusing the two is what makes a dead row look load-bearing.

The row, and why nothing could ever action it

{ "version": "2.1.219", "parse_failed": true, "features": [],
  "raw_bullets_count": 24, "failed_at": "2026-07-25T04:02:20.214Z", "below_floor": true }

No features to triage, and the version is below the support floor. Its only effect was to make the queue read as two waves deep when one is real.

Verified before removing, not after

claim	check that decided it
the PUBLISHED 2.1.219 wave survives	`cc-adoption-data.ts` carries it before regeneration and after: 1 hit both times. The merge only ever adds
no test depends on the version	`grep -rln '2\.1\.219' tests` returns nothing
the generated diff is the digest only	the board's only change is `SOURCE_DIGEST`, a sha over the queue's raw bytes

The trap this change would otherwise walk into

Touching the queue without shipping the regenerated board in the SAME commit
trips the CI drift gate (ci.yml:82), which compares generated output against source.
The regenerated file is in this commit. Green by construction, not by retry.