The cap that did not announce itself

#2950 · 48 changelog bullets in, 12 issues out, and nothing in the feed said so.

The broken chain

Three numbers exist. Only the first and last were ever recorded, and the first was never read.

Why raw_bullets_count never helped

It has been written since forever. Grep says its only occurrence in the repo is the line that writes it.

$ grep -rn "raw_bullets_count" scripts/ .github/workflows/
scripts/cc-release-watch.mjs:310:  raw_bullets_count: v.body.split('\n').filter(...).length,

one hit. written, never read.

So the ledger knew how many bullets went in and how many features came out, but never the number in between. Without it, 48 -> 12 is unreadable: it could be 36 bug-fix bullets that were correctly not features, or 13 features the cap threw away. Those need opposite responses.

Two tiers of warning, worded apart on purpose

Ledger entryWhat the filer now saysConfidence
features_extracted: 25
features: 20		TRUNCATED, 5 droppedexact
features: 20
(legacy, no field)		possible but UNCONFIRMEDinferred
features_extracted: 3
features: 3		nothingnot saturated
The old warning fired on length == 20 alone. That guess cannot separate a release that genuinely produced exactly 20 from one cut down from 21+. Keeping the two tiers verbally distinct is the point of the fix: a warning that cannot tell truncation from coincidence must not sound like one that can.

What this does NOT fix

The cap still drops the lowest-scoring features. Raising it, or paging through large releases, is suggestion 2 in the issue and a scoping decision, not a correctness one. This change only makes hitting the cap impossible to do quietly.

Also honest: there is no test for cc-file-adoption-issues.sh anywhere in the repo. The filer half of this change rests on manual jq verification, not on CI. The extractor half is covered by Test 15.

Test 15 vs the pre-fix script   69 passed, 3 failed
Test 15 vs the fixed script     72 passed, 0 failed