docs: install the pinned pnpm without Corepack

[Lob26]

Closes #167.

The dead end

Node.js 25 removed the bundled Corepack. The first command of every documented setup path is:

corepack install --global pnpm@11.20.0

On a current Node release that fails outright, and the contributor is left with neither pnpm nor a reason. Nothing in the docs says which Node line to use instead, so the next reasonable move — "my Node is too new, but the badge says 24 LTS and I have 26 installed" — is a guess.

I hit this while setting up the repository: no corepack on the machine, and the documented path had no continuation. I got moving with npx pnpm@11.20.0, which is not what the docs should be teaching.

The change

Two parts, because swapping the command alone would leave the real constraint unsaid.

Install the same pinned pnpm with npm, which ships with every supported release, in the five places that documented the Corepack command:

• README.md (quick start, and the contributing block)
• CONTRIBUTING.md
• apps/docs/docs/self-host/quickstart.md
• apps/docs/docs/self-host/local-development.md
• apps/docs/docs/reference/reference-fixture.md

Say the constraint where the prerequisites are listed. package.json already pins "node": "^22.13.0 || ^24.0.0", so Node 25+ is not a supported runtime here — the docs just never said so, which is why the Corepack failure reads as a broken checkout rather than a wrong Node. Three prose spots now state that Node.js 25 and later are outside the supported range, no longer bundle Corepack, and that .nvmrc selects a supported line.

One consequence worth flagging: local-development.md already told readers "Do not substitute npm or yarn", which the new command would appear to contradict. It now distinguishes using npm to install pnpm from using npm to run the workspace.

Deliberately unchanged

apps/docs/docs/guides/existing-repo.md and reference/project-manifest.md show setup: corepack enable && pnpm install --frozen-lockfile in .facility.yml examples. Those run inside the runner image, which is node:24-trixie-slim and does bundle Corepack, so they are correct today.

They will not stay correct: Dependabot #209 moves the runner to node:26-trixie-slim, and corepack enable in those examples breaks the moment it lands. That is #209's problem to solve, not this PR's, but it is worth knowing before merging it.

Verification

• pnpm guards — ✓ actions-pinned, ✓ markdown-links, 0 failed (no link broken by the edits)
• pnpm --filter @facility/docs test — 10 passed, including the full Docusaurus build and the canonical-URL check
• pnpm lint — clean

Verified on the machine that produced the report: Windows 11, Node 26, no Corepack present. npm install --global pnpm@11.20.0 installs the pinned version and pnpm install --frozen-lockfile then succeeds.

Related

#167's sibling #240 (the engines range) already landed — package.json now pins ^22.13.0 || ^24.0.0 rather than >=22. That tightened the contract without updating the setup instructions it implies, which is the gap this closes. Note that pnpm only warns on an out-of-range Node rather than refusing, so a contributor on 26 gets a working install and an untested toolchain unless the docs say otherwise — now they do.

Claude Code helped

[adrian-lorenzo]

Appreciate the contribution!