Observation-class finding. ⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned.
Reported by the #14744 dev (PR #15301) while registering a legitimate new row in this ledger, and deliberately not fixed there: it is pre-existing, outside that card's scope, and that card's instruction was that nothing else changes. Recorded here so the observation is not lost with the dev's transcript.
What was measured
scripts/pm/dispatch-gates.mjs — the COMPOUND_ANCHOR_LEDGER docblock states its table's size and composition in prose:
…all 22… the fifteen genuine rows… the seven accidental ones…
The table it documents already held 25 rows — 17 genuine / 8 accidental — before PR #15301 added its one row. So the prose was wrong by 3 rows in total and by 2 in each bucket, and the three numbers are mutually consistent with each other (22 = 15 + 7) while being jointly inconsistent with the table, which is the shape that makes a stale count read as deliberate.
Why it is worth a card rather than a comment
⭐ This file is the repo's own instrument for "declared = enforced", and here its declaration disagrees with what it holds. The failure is small in consequence but exactly the class the ledger exists to catch elsewhere: a hand-maintained count beside a table that grows, with nothing comparing the two. Every row added since the prose was written has widened the gap silently, and the next editor to add a row has the same opportunity to leave it wider.
⚠️ The specific risk is not the wrong integer. It is that a reader deciding whether a row belongs — the exact judgment PR #15301's dev had to make, classifying runSelfTest as accidental: false — uses the docblock's bucket counts to calibrate what "genuine" and "accidental" have meant historically. Calibrating against 15 / 7 when the truth is 17 / 8 is a small error in the same direction every time.
Suggested disposition (⛔ not a decision)
Two shapes, and the second is the one the file's own conventions would suggest:
- Correct the three numbers and accept that they will drift again.
- Pin the prose to the table — assert the counts in the file's
--self-test (it already has one, and it already walks this ledger), so a row added without touching the docblock goes red. This is the treatment several sibling ledgers in this file already receive, and it converts a recurring manual chore into a gate.
⚠️ Whoever takes this should re-measure the counts on origin/main at the time rather than trusting the integers above — PR #15301 has since added a row, so the table is at least 26 now, and this card's own numbers are a snapshot that will itself go stale. That is the defect, restated.
Re-check
git show origin/main:scripts/pm/dispatch-gates.mjs | grep -n "COMPOUND_ANCHOR_LEDGER"
# then read the docblock immediately above the table and count the rows in the table itself
Related: PR #15301 (#14744) — the change that surfaced this, and whose own added row is legitimate and separately verified.
Observation-class finding. ⛔ Ungraded and unrouted —
domain:*, priority and type are triage's. Filed unassigned.Reported by the #14744 dev (PR #15301) while registering a legitimate new row in this ledger, and deliberately not fixed there: it is pre-existing, outside that card's scope, and that card's instruction was that nothing else changes. Recorded here so the observation is not lost with the dev's transcript.
What was measured
scripts/pm/dispatch-gates.mjs— theCOMPOUND_ANCHOR_LEDGERdocblock states its table's size and composition in prose:The table it documents already held 25 rows — 17 genuine / 8 accidental — before PR #15301 added its one row. So the prose was wrong by 3 rows in total and by 2 in each bucket, and the three numbers are mutually consistent with each other (22 = 15 + 7) while being jointly inconsistent with the table, which is the shape that makes a stale count read as deliberate.
Why it is worth a card rather than a comment
⭐ This file is the repo's own instrument for "declared = enforced", and here its declaration disagrees with what it holds. The failure is small in consequence but exactly the class the ledger exists to catch elsewhere: a hand-maintained count beside a table that grows, with nothing comparing the two. Every row added since the prose was written has widened the gap silently, and the next editor to add a row has the same opportunity to leave it wider.
runSelfTestasaccidental: false— uses the docblock's bucket counts to calibrate what "genuine" and "accidental" have meant historically. Calibrating against15 / 7when the truth is17 / 8is a small error in the same direction every time.Suggested disposition (⛔ not a decision)
Two shapes, and the second is the one the file's own conventions would suggest:
--self-test(it already has one, and it already walks this ledger), so a row added without touching the docblock goes red. This is the treatment several sibling ledgers in this file already receive, and it converts a recurring manual chore into a gate.origin/mainat the time rather than trusting the integers above — PR #15301 has since added a row, so the table is at least 26 now, and this card's own numbers are a snapshot that will itself go stale. That is the defect, restated.Re-check
Related: PR #15301 (#14744) — the change that surfaced this, and whose own added row is legitimate and separately verified.