ci: the tree runs on one pinned pnpm 12

[blafourcade]

What broke

validate.yml activates pnpm@latest. pnpm 12.3.4 landed on the runners today and removed the =false value form of --frozen-lockfile, so the lefthook job now stops at its own install step:

error: unexpected value 'false' for '--frozen-lockfile' found; no more were expected
Usage: pnpm install --frozen-lockfile

The job never reaches the hooks it exists to run, so every pull request fails that check from now on, whatever it changes. The three merged today passed it hours earlier, under pnpm 11.

Found on #781, whose diff is markdown and one test file — nothing that could touch an install.

The fix

--no-frozen-lockfile is the same instruction in the form both majors accept: pnpm 11 documents the flag as --[no-]frozen-lockfile, and pnpm 12's own error says the flag takes no value.

One line. No behaviour change: the install still refuses to fail on an out-of-date lockfile, which is what =false asked for.

Named, not fixed

Nine other workflow steps also run corepack prepare pnpm@latest --activate, so the next major arrives the same way — unannounced, on a green branch. Pinning the version is a decision about what the team runs locally, not a CI detail, so it is stated here rather than made.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VWNxk63AGKkqE8HRqHLjGp

---

Second commit: one pinned version, and the overrides pnpm 12 stopped reading

Fixing the flag unblocks CI. It does not stop the same thing happening again, and it leaves the tree disagreeing with itself about which pnpm it runs.

The tree did not agree with itself

	pinned to
repository root	nothing
cli/	pnpm@10.14.0
kanban/	pnpm@10.14.0

Ten workflow steps ran corepack prepare pnpm@latest --activate, so one CI run could resolve the root under 12 and cli/ under 10.

packageManager now names pnpm@12.3.4 in all three, and every workflow step stops at corepack enable — corepack reads the pin instead of choosing. One version, written down once; the next major arrives when somebody edits that line.

The overrides pnpm 12 silently dropped

[WARN] The "pnpm" field in package.json is no longer read by pnpm.
       The following keys were ignored: "pnpm.overrides".

cli/ kept four security floors there. Ignored by pnpm 12 while the lockfile still recorded them — which is the ERR_PNPM_LOCKFILE_CONFIG_MISMATCH every cli install answered with under 12. They move to cli/pnpm-workspace.yaml, their new home, unchanged: fast-uri >=3.1.2, picomatch >=4.0.4, postcss >=8.5.10, qs >=6.15.2.

Worth stating plainly: under pnpm 12 those four floors were not being applied at all. This restores them.

The lockfiles

	before	after	delta
root	746	847	+101 / −0
cli/	5,306	5,407	+101 / −0
kanban/	1,798	1,899	+101 / −0

Only the packageManagerDependencies block pnpm 12 records for a pinned version. No dependency re-resolved, nothing removed. A pin cannot be added without it: --frozen-lockfile refuses to write that block itself, which is what ERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE was saying.

Verified by running it

Every package, pnpm@12.3.4, --frozen-lockfile:

root    exit 0, lockfile stable
cli     exit 0, lockfile stable
kanban  exit 0, lockfile stable

3,471 CLI tests, 371 repository script tests, biome ci clean (2 pre-existing warnings), typecheck clean, bundle 595.7 / 598 KB, 0 broken links in 798 files.

One thing reviewers should know

Pinning packageManager means a contributor whose pnpm is a plain binary rather than a corepack shim will now see pnpm install try to fetch 12.3.4. That is the point of a pin, and it is the first time this repository has had one at the root.