Filed by the PM on a pass-2 seat's finding (#15322 / PR #15369), which was reserved to me rather than filed there. Unassigned, no claim.
The measured defect
content/docs embeds CLI transcripts as teaching material. Several of them quote a number that the CLI derives from a live registry at runtime:
→ Running author-time rules (41)...
AUTHORING_RULES in packages/lint/src/authoring-rules.ts holds 42 entries — 39 declaring ALL and 3 declaring ['validate', 'build'], and authoringRulesFor filters by commands.includes(command), so authoringRulesFor('validate').length is 42. That is also what the CLI printed on a real 17.3.0 run.
Four published pages carried 41:
content/docs/deployment/cli.mdxcontent/docs/deployment/validating-metadata.mdxcontent/docs/ui/react-pages.mdxcontent/docs/getting-started/build-with-claude-code.mdx
PR #15369 corrects the four numbers. It does not fix the mechanism, deliberately — that is this card.
Why nothing caught it
Confirmed by grep: no script under scripts/ mentions author-time rules. The number is derived from a registry at runtime and asserted in the docs as a literal, and nothing connects the two. So it drifts on every rule added, silently, and the only thing that surfaced it was a customer-simulation upgrade run noticing the CLI printed a different number than the page did (hotcrm#1576 / hotcrm#1577, documentation defect 8).
⚠️ The shape, not the number, is the finding. author-time rules (N) is one instance; any transcript quoting a count, a version, a plugin total or a rule name from a live registry has the same exposure. The four pages above are what one grep found for one phrase.
Why it is worth a gate rather than "we fixed it"
The number is derived data asserted as a literal — the same class the repo already treats mechanically elsewhere:
Two stale-literal classes in content/docs in one week, both found by accident rather than by a gate, is a mechanism gap.
Directions worth weighing (⛔ not adjudicated here)
- A transcript-drift gate that pins the numbers CLI transcripts print in
content/docs against the live registries that produce them. Straightforward for a count exported from a module; the design question is how a transcript declares which registry a number came from without turning every code block into an annotated fixture.
- Fold it into
check:corpus-claim-drift, which already does lexical anti-drift over the teaching corpus. ⚠️ Worth evaluating rather than assuming: that gate is a co-occurrence ratchet over claim phrasing, so a numeric assertion pinned to a registry export may or may not fit its model. The seat that found this flagged the same doubt.
Both directions have to answer the same question — how a transcript block says what it is a transcript of — so that is probably where the card starts.
Provenance
Every reading above is from PR #15369 (pass 2 of #15322), which verified the 41 → 42 claim against the registry rather than copying it from the drill that reported it, and measured the four occurrences by grep count (stale text at 0 after the edit, new text at 4). The upstream sighting is hotcrm#1577's documentation-defect list. Related mechanism cards: #15332 (releases/index.mdx stale current-series, third recurrence), #15357 (a rule's "0 findings over the corpus" claim measured against a corpus that is not the app it names).
Filed by the PM on a pass-2 seat's finding (#15322 / PR #15369), which was reserved to me rather than filed there. Unassigned, no claim.
The measured defect
content/docsembeds CLI transcripts as teaching material. Several of them quote a number that the CLI derives from a live registry at runtime:AUTHORING_RULESinpackages/lint/src/authoring-rules.tsholds 42 entries — 39 declaringALLand 3 declaring['validate', 'build'], andauthoringRulesForfilters bycommands.includes(command), soauthoringRulesFor('validate').lengthis 42. That is also what the CLI printed on a real 17.3.0 run.Four published pages carried
41:content/docs/deployment/cli.mdxcontent/docs/deployment/validating-metadata.mdxcontent/docs/ui/react-pages.mdxcontent/docs/getting-started/build-with-claude-code.mdxPR #15369 corrects the four numbers. It does not fix the mechanism, deliberately — that is this card.
Why nothing caught it
Confirmed by grep: no script under
scripts/mentionsauthor-time rules. The number is derived from a registry at runtime and asserted in the docs as a literal, and nothing connects the two. So it drifts on every rule added, silently, and the only thing that surfaced it was a customer-simulation upgrade run noticing the CLI printed a different number than the page did (hotcrm#1576 / hotcrm#1577, documentation defect 8).author-time rules (N)is one instance; any transcript quoting a count, a version, a plugin total or a rule name from a live registry has the same exposure. The four pages above are what one grep found for one phrase.Why it is worth a gate rather than "we fixed it"
The number is derived data asserted as a literal — the same class the repo already treats mechanically elsewhere:
check:docs-image-tagkeeps the docs image tag true, stamped byscripts/at version time (e569cac32).releases/index.mdx, where the sentence names the current series and nothing derives it. That card's ruling was to stamp it, on this precedent.Two stale-literal classes in
content/docsin one week, both found by accident rather than by a gate, is a mechanism gap.Directions worth weighing (⛔ not adjudicated here)
content/docsagainst the live registries that produce them. Straightforward for a count exported from a module; the design question is how a transcript declares which registry a number came from without turning every code block into an annotated fixture.check:corpus-claim-drift, which already does lexical anti-drift over the teaching corpus.Both directions have to answer the same question — how a transcript block says what it is a transcript of — so that is probably where the card starts.
Provenance
Every reading above is from PR #15369 (pass 2 of #15322), which verified the 41 → 42 claim against the registry rather than copying it from the drill that reported it, and measured the four occurrences by grep count (stale text at 0 after the edit, new text at 4). The upstream sighting is hotcrm#1577's documentation-defect list. Related mechanism cards: #15332 (
releases/index.mdxstale current-series, third recurrence), #15357 (a rule's "0 findings over the corpus" claim measured against a corpus that is not the app it names).