Found while implementing #5306 (correcting root engines to node: ">=22.11" / pnpm: ">=10"). Deliberately not fixed there: #5306's sweep covers prose that restates the workspace's floors, and these two claims address a different audience and have no manifest to check them against. Filing so the two halves stay together — the claims, and the reason nothing caught them.
Half 1 — two claims with no anchor
| Location | Claim |
|---|
content/docs/guide/quick-start.md:12-13 | - **Node.js** 20+ / - **pnpm** 9+ or npm/yarn |
content/docs/guide/building-crud-app.md:12 | - **Node.js** 20+ and **pnpm** 9+ |
Both pages are consumer-facing: the reader runs pnpm create vite my-app and pnpm add @object-ui/react … in their own project, not in this workspace. So root engines never governed them — which is exactly why #5306 left them alone rather than rewriting them to 22.11/10, since that would invent a consumer requirement nobody has measured.
But nothing else governs them either. Measured across all 40 packages: zero declare engines.node or engines.pnpm (packages/vscode-extension declares engines.vscode and that is the only engines block outside the root). So "Node.js 20+" is a number a reader will act on, restating no manifest in this tree, and untested by any CI lane (every workflow runs node-version: '22.x').
Two honest dispositions, and the choice is a decision rather than a cleanup:
- A — measure what the published packages actually need and declare it (per-package
engines, or one statement the guides cite), making these lines a restatement of something real. - B — stop stating a number the project does not test, and say what is true: the packages are exercised on Node 22.x.
Half 2 — why no gate objected
scripts/__tests__/doc-version-claims.test.ts exists precisely to stop unanchored version literals accreting in content/docs, and content/docs is one of its three SCAN_ROOTS. It does not see these lines. Its separator class between a toolchain name and its version is
const SEP = '[' + TICK + '\'"\\s:,|)\\]]{0,6}(?:[-—]\\s*)?[' + TICK + '\'"]?\\s*';
which admits backticks, quotes, whitespace, colons, commas, pipes and brackets — but not *. **Node.js** 20+ therefore never matches TOOLCHAIN + SEP + VERSION, so the literal is neither ledgered in KNOWN_CLAIMS nor checked, and the ratchet's "every literal is either exempt or inventoried" promise silently does not hold for the bold spelling. Markdown emphasis around a toolchain name is a common spelling in this corpus — the two hits above are in bullet lists that use it for every entry.
⚠️ The failure direction is the bad one: the gate reports green over claims it never examined, which is what the gate's own header warns about for other classes.
Cheapest repair if half 2 is taken on its own: add * (and probably _) to SEP's character class, then triage whatever the widened scan surfaces — expect the two lines above plus any others in the same spelling.
Related but distinct: #6086 (no gate judges prose restating a declared surface) is the type-level sibling of half 2; this one is about version literals, where a gate does exist and is blind to a spelling.
Generated by Claude Code
Found while implementing #5306 (correcting root
enginestonode: ">=22.11"/pnpm: ">=10"). Deliberately not fixed there: #5306's sweep covers prose that restates the workspace's floors, and these two claims address a different audience and have no manifest to check them against. Filing so the two halves stay together — the claims, and the reason nothing caught them.Half 1 — two claims with no anchor
content/docs/guide/quick-start.md:12-13- **Node.js** 20+/- **pnpm** 9+ or npm/yarncontent/docs/guide/building-crud-app.md:12- **Node.js** 20+ and **pnpm** 9+Both pages are consumer-facing: the reader runs
pnpm create vite my-appandpnpm add @object-ui/react …in their own project, not in this workspace. So rootenginesnever governed them — which is exactly why #5306 left them alone rather than rewriting them to 22.11/10, since that would invent a consumer requirement nobody has measured.But nothing else governs them either. Measured across all 40 packages: zero declare
engines.nodeorengines.pnpm(packages/vscode-extensiondeclaresengines.vscodeand that is the onlyenginesblock outside the root). So "Node.js 20+" is a number a reader will act on, restating no manifest in this tree, and untested by any CI lane (every workflow runsnode-version: '22.x').Two honest dispositions, and the choice is a decision rather than a cleanup:
engines, or one statement the guides cite), making these lines a restatement of something real.Half 2 — why no gate objected
scripts/__tests__/doc-version-claims.test.tsexists precisely to stop unanchored version literals accreting incontent/docs, andcontent/docsis one of its threeSCAN_ROOTS. It does not see these lines. Its separator class between a toolchain name and its version iswhich admits backticks, quotes, whitespace, colons, commas, pipes and brackets — but not
*.**Node.js** 20+therefore never matchesTOOLCHAIN + SEP + VERSION, so the literal is neither ledgered inKNOWN_CLAIMSnor checked, and the ratchet's "every literal is either exempt or inventoried" promise silently does not hold for the bold spelling. Markdown emphasis around a toolchain name is a common spelling in this corpus — the two hits above are in bullet lists that use it for every entry.Cheapest repair if half 2 is taken on its own: add
*(and probably_) toSEP's character class, then triage whatever the widened scan surfaces — expect the two lines above plus any others in the same spelling.Related but distinct: #6086 (no gate judges prose restating a declared surface) is the type-level sibling of half 2; this one is about version literals, where a gate does exist and is blind to a spelling.
Generated by Claude Code