You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed while implementing #10268 (PR #10802). Recording the half of that gate's design that is deliberately not delivered there.
The gap
scripts/check-release-section-coverage.mjs reports its findings as advisory — ::warning:: + step summary, job green — and ships a --strict flag that promotes them to exit 1. That advisory choice is measured and I stand behind it: hard-failing would have red 2748 PRs across the two real gaps (16.1.0 ran 25d 6h with 2712 PRs landing; 17.1.0 ran 5h44m with 36), for a debt none of them created.
But --strict currently has no caller. Nothing in the repo runs it, so the only thing that ever executes is the advisory pass inside lint.yml, where a finding is one green job's log line among ~86 steps on a PR-heavy day.
Why that is a real gap and not bookkeeping
This is the exact shape both existing patrols were created to close, in their own words:
half-state-patrol.yml: "A healing mechanism with no scheduled caller heals only in the counterfactual, and an alarm added to a script nobody runs is still silence."
required-set-patrol.yml: "It shipped with no standing caller, so the only thing CI ran was its OFFLINE self-test: the mechanism existed and measured nothing."
And it is the shape of the finding #10268 itself was filed about: #8917 recorded "16.1.0 is documented on no page at all" and produced no gate, after which the state persisted 25 days.
What is unlike the two existing patrols
Both of those had to move off lint.yml for a transport reason — they read api.github.com, which PR gates and dispatch containers cannot reach. This check is fully offline: it reads packages/spec/CHANGELOG.md and content/docs/releases/** out of the tree. So the reason for a standing caller here is audience, not reachability, and the design question is genuinely different.
Where the report lands.half-state-patrol.yml rewrites one pinned anchor issue in place and argues against a per-run comment stream; required-set-patrol.yml deliberately lands in the run log and step summary and nowhere else. A finding here is low-frequency (4 in-scope minors exist in total) and has a named owner-shaped remedy, which may argue for the anchor-issue shape.
Whether a red job is right at all. A --strict run stays red for as long as the prose is unwritten — 25 days, in the 16.1.0 case. A chronically red scheduled job is how people learn to skim red, which prerelease-pin-watch.yml's header warns about directly.
Each of the two existing patrols got its own card (#9844, #9678) for exactly these questions, which is why this is filed rather than bundled into #10802.
Not claimed
I have not measured how visible a ::warning:: annotation actually is on a PR in this repo. If it is visible enough in practice, the answer to (3) may be that no standing caller is needed and the advisory is sufficient on its own — that would close this as won't-fix, which is a fine outcome and worth measuring before building anything.
Cross-links: #10268 (the gate), #10802 (the PR), #9844 / #9678 (the two existing patrols and their cards).
Filed while implementing #10268 (PR #10802). Recording the half of that gate's design that is deliberately not delivered there.
The gap
scripts/check-release-section-coverage.mjsreports its findings as advisory —::warning::+ step summary, job green — and ships a--strictflag that promotes them to exit 1. That advisory choice is measured and I stand behind it: hard-failing would have red 2748 PRs across the two real gaps (16.1.0 ran 25d 6h with 2712 PRs landing; 17.1.0 ran 5h44m with 36), for a debt none of them created.But
--strictcurrently has no caller. Nothing in the repo runs it, so the only thing that ever executes is the advisory pass insidelint.yml, where a finding is one green job's log line among ~86 steps on a PR-heavy day.Why that is a real gap and not bookkeeping
This is the exact shape both existing patrols were created to close, in their own words:
half-state-patrol.yml: "A healing mechanism with no scheduled caller heals only in the counterfactual, and an alarm added to a script nobody runs is still silence."required-set-patrol.yml: "It shipped with no standing caller, so the only thing CI ran was its OFFLINE self-test: the mechanism existed and measured nothing."And it is the shape of the finding #10268 itself was filed about: #8917 recorded "16.1.0 is documented on no page at all" and produced no gate, after which the state persisted 25 days.
What is unlike the two existing patrols
Both of those had to move off
lint.ymlfor a transport reason — they readapi.github.com, which PR gates and dispatch containers cannot reach. This check is fully offline: it readspackages/spec/CHANGELOG.mdandcontent/docs/releases/**out of the tree. So the reason for a standing caller here is audience, not reachability, and the design question is genuinely different.What needs deciding (why this was not just built)
check:release-page-statusguards the release-status blockquote but not section coverage — a published minor with no section on its per-major page fails nothing #10268 terms is "visible within a day of a minor publishing", so nightly, not weekly.half-state-patrol.ymlrewrites one pinned anchor issue in place and argues against a per-run comment stream;required-set-patrol.ymldeliberately lands in the run log and step summary and nowhere else. A finding here is low-frequency (4 in-scope minors exist in total) and has a named owner-shaped remedy, which may argue for the anchor-issue shape.--strictrun stays red for as long as the prose is unwritten — 25 days, in the 16.1.0 case. A chronically red scheduled job is how people learn to skim red, whichprerelease-pin-watch.yml's header warns about directly.Each of the two existing patrols got its own card (#9844, #9678) for exactly these questions, which is why this is filed rather than bundled into #10802.
Not claimed
I have not measured how visible a
::warning::annotation actually is on a PR in this repo. If it is visible enough in practice, the answer to (3) may be that no standing caller is needed and the advisory is sufficient on its own — that would close this as won't-fix, which is a fine outcome and worth measuring before building anything.Cross-links: #10268 (the gate), #10802 (the PR), #9844 / #9678 (the two existing patrols and their cards).
Generated by Claude Code