Observation filed while landing the #11069 gate fix (PR #11549). Not a claim; unassigned. Not repaired there — editing .github/workflows/lint.yml would add a hot conflict-magnet file and new gate families to a scripts/**-only PR, which is scope this card should own instead.
.github/workflows/lint.yml's "Optional-error sink contract" step (around line 1315) carries a comment stating measured counts:
# Runs its own --self-test FIRST (13 cases, both directions, both# narrowings pinned as counts), then the scan — 36 sink types, 15# baselined shrink-only. AST over packages/**, no spawns; ~3.5 s.
Every number in it is now wrong, and each drifted for a different reason:
| the comment says | reality on cd932772 | reality after PR #11549 | what moved it |
|---|
13 cases | 13 | 19 | #11549 added six self-test cases |
36 sink types | 38 | 41 | ordinary tree growth, then #11549's population widening |
15 baselined | 2 | 5 | #10556's paydown (15 → 3 → 2), then #11549's three ledger rows |
The 15 baselined figure is the sharpest: it has been wrong since #10556 paid the ledger down, long before #11069 existed. A reader who trusts it believes there are fifteen outstanding sink repairs when there are five, and the ledger's whole point is to be the count of remaining debt.
Why this is worth a card rather than a one-line fix on the next PR that passes by
The numbers are a census of a moving tree pinned in prose in a file nothing re-measures. That is a strictly worse home for them than the gate's own header, which at least sits next to the code that produces them — and #11069 was filed about exactly this species one level down (a gate's own printed counts bounded by a filter nobody re-checked).
So the fix is probably not "correct the three numbers" — that just resets a clock that will drift again on the next PR that touches any sink in packages/**. Options worth weighing:
- Drop the counts from the workflow comment entirely, keeping only the invariant facts (runs its own
--self-test first, AST over packages/**, no spawns, no paths: filter and why). The gate prints its live census on every run; the comment does not need a stale copy. - Keep a count but make it re-measurable — e.g. state it as "see the gate's own census line" rather than a literal.
- Leave it and accept the drift, explicitly, with a note saying the numbers are illustrative.
I lean to the first: the timing (~3.5 s) and the "no paths: filter, because a filter on packages/** would go dormant on the PR that edits the baseline" rationale are the parts that earn their place, and neither drifts.
Same family, already open
All four are the same shape: a workflow comment asserting a fact about the world, with nothing that re-checks it. Worth someone deciding whether that shape wants a gate rather than four separate repairs.
Refs
#9754 (the gate) · #10556 (the ledger paydown that stranded 15 baselined) · #11069 / PR #11549 (where this was measured)
Observation filed while landing the #11069 gate fix (PR #11549). Not a claim; unassigned. Not repaired there — editing
.github/workflows/lint.ymlwould add a hot conflict-magnet file and new gate families to ascripts/**-only PR, which is scope this card should own instead..github/workflows/lint.yml's "Optional-errorsink contract" step (around line 1315) carries a comment stating measured counts:Every number in it is now wrong, and each drifted for a different reason:
cd93277213 cases36 sink types15 baselinedThe
15 baselinedfigure is the sharpest: it has been wrong since #10556 paid the ledger down, long before #11069 existed. A reader who trusts it believes there are fifteen outstanding sink repairs when there are five, and the ledger's whole point is to be the count of remaining debt.Why this is worth a card rather than a one-line fix on the next PR that passes by
The numbers are a census of a moving tree pinned in prose in a file nothing re-measures. That is a strictly worse home for them than the gate's own header, which at least sits next to the code that produces them — and #11069 was filed about exactly this species one level down (a gate's own printed counts bounded by a filter nobody re-checked).
So the fix is probably not "correct the three numbers" — that just resets a clock that will drift again on the next PR that touches any sink in
packages/**. Options worth weighing:--self-testfirst, AST overpackages/**, no spawns, nopaths:filter and why). The gate prints its live census on every run; the comment does not need a stale copy.I lean to the first: the timing (
~3.5 s) and the "nopaths:filter, because a filter onpackages/**would go dormant on the PR that edits the baseline" rationale are the parts that earn their place, and neither drifts.Same family, already open
changeset pre exitre-arms that gate — release.yml records the keying was changed away from pre-exit #9828 — cut-rc.yml's hotcrm smoke warning describes a keying that release.yml changed away frompackage.json— fifteen times, and the over-broad reading is acquirable by copying #10894 — lint.yml states the Migrate the release toolchain to @changesets/cli v3 — one atomic PR carrying the bump, the pre-mode restructure, and the gates that model v2's semantics #9465 fence as covering rootpackage.json, fifteen timesAll four are the same shape: a workflow comment asserting a fact about the world, with nothing that re-checks it. Worth someone deciding whether that shape wants a gate rather than four separate repairs.
Refs
#9754 (the gate) · #10556 (the ledger paydown that stranded
15 baselined) · #11069 / PR #11549 (where this was measured)