Found while implementing #6447 (giving the two pnpm 10.x ledger entries a machine-checked anchor). Deliberately not fixed there: #6447's dispatch drew an explicit boundary around #6400's and #6409's landed KNOWN_CLAIMS entries, and this count lives inside one of them. Filing so the number is recorded rather than carried.
The entry
scripts/__tests__/doc-version-claims.test.ts, KNOWN_CLAIMS — the entry keyed content/docs/guide/ci-cd-pipeline.md :: Node 22.x (located by key, not by line: this file moves every few days). Its why ends:
…it credited this page's own pin test with covering the line - ci-cd-pipeline-doc.test.ts contains no node-version and no 22 at all (control, same file: 28 mentions of ci.yml). Nothing re-measured either half, which is the whole reason the count moved into a run.
The identical control also appears once in the file's docblock, in the bullet recording what #6400 found.
Measured on e85231bd4
$ grep -o 'ci\.yml' scripts/__tests__/ci-cd-pipeline-doc.test.ts | wc -l
29
So the reason says 28; the file holds 29.
Controls, same sweep, same file — both directions, because a count is exactly the kind of reading that can be wrong by being empty:
$ grep -o 'DOCUMENTATION_EXEMPT' scripts/__tests__/ci-cd-pipeline-doc.test.ts | wc -l
6 # must be non-zero, and is: the grep and the path are both real
$ grep -o 'node-version' scripts/__tests__/ci-cd-pipeline-doc.test.ts | wc -l
0 # must be zero, and is: the claim the control was attached to still holds
The second control is the important one: the CLAIM the sentence makes — that this page's pin test does not cover the node-version line — is still exactly true. What has drifted is the parenthetical number offered as evidence that the grep was real.
Why this is worth a card and not a shrug
It is the same class as #6400 and #6447 and the third site of it in the same file: a count in a why string is a measurement frozen at the moment someone typed it, and nothing re-takes it. This one is smaller than either — it is a CONTROL for a historical reading, not the anchor of a live claim — but the ledger's whole subject is frozen counts, and a wrong one inside it teaches the next reader that the numbers here are approximate.
Note the asymmetry that makes it worth writing down: this reading drifted upward by one while the sentence around it stayed true. Nothing goes red. A reviewer who re-runs the command to check the reason finds a number that does not match and has no way to tell whether the claim rotted or only the evidence did.
Dispositions
B is the recommendation. #6447 established the policy the file now states in its own header — a count describing the CURRENT tree is removed and replaced by the run that re-takes it, while a count recording what a change MEASURED when it landed is kept and attributed to that change — and this count is squarely of the second kind. Applying the policy the file already documents is a smaller change than deciding a new one.
Suggested triage: tooling / domain:devx, type Task. Left unassigned and unlabelled for the PM to dispose of.
Related: #6447 (the pnpm 10.x entries, same file, same class, manifest anchor), #6400 (the Node 22.x entries, same file, whose entry this count sits in).
Generated by Claude Code
Found while implementing #6447 (giving the two
pnpm 10.xledger entries a machine-checked anchor). Deliberately not fixed there: #6447's dispatch drew an explicit boundary around #6400's and #6409's landedKNOWN_CLAIMSentries, and this count lives inside one of them. Filing so the number is recorded rather than carried.The entry
scripts/__tests__/doc-version-claims.test.ts,KNOWN_CLAIMS— the entry keyedcontent/docs/guide/ci-cd-pipeline.md :: Node 22.x(located by key, not by line: this file moves every few days). Itswhyends:The identical control also appears once in the file's docblock, in the bullet recording what #6400 found.
Measured on
e85231bd4So the reason says 28; the file holds 29.
Controls, same sweep, same file — both directions, because a count is exactly the kind of reading that can be wrong by being empty:
The second control is the important one: the CLAIM the sentence makes — that this page's pin test does not cover the
node-versionline — is still exactly true. What has drifted is the parenthetical number offered as evidence that the grep was real.Why this is worth a card and not a shrug
It is the same class as #6400 and #6447 and the third site of it in the same file: a count in a
whystring is a measurement frozen at the moment someone typed it, and nothing re-takes it. This one is smaller than either — it is a CONTROL for a historical reading, not the anchor of a live claim — but the ledger's whole subject is frozen counts, and a wrong one inside it teaches the next reader that the numbers here are approximate.Note the asymmetry that makes it worth writing down: this reading drifted upward by one while the sentence around it stayed true. Nothing goes red. A reviewer who re-runs the command to check the reason finds a number that does not match and has no way to tell whether the claim rotted or only the evidence did.
Dispositions
pnpm 10.xreasons state 17corepack enablesteps across 12 workflow files; the tree has 20 across 14 #6447 did to the two counts it removed.pnpm 10.xreasons state 17corepack enablesteps across 12 workflow files; the tree has 20 across 14 #6447 attributed the neighbouring docblock bullet: state the number AS OF finding(gate): the version-claim ledger'sci-cd-pipeline.md :: Node 22.xreason states 14node-versiondeclarations; the tree has 27 #6400's cut, so it reads as history rather than as a reading of today. Keeps the evidence that the sweep was real, costs one clause.B is the recommendation. #6447 established the policy the file now states in its own header — a count describing the CURRENT tree is removed and replaced by the run that re-takes it, while a count recording what a change MEASURED when it landed is kept and attributed to that change — and this count is squarely of the second kind. Applying the policy the file already documents is a smaller change than deciding a new one.
Suggested triage:
tooling/domain:devx, type Task. Left unassigned and unlabelled for the PM to dispose of.Related: #6447 (the
pnpm 10.xentries, same file, same class, manifest anchor), #6400 (theNode 22.xentries, same file, whose entry this count sits in).Generated by Claude Code