build: turn on pnpm's supply-chain policies

pnpm 11 ships a set of guards that are either off or only half on by default.
All of them are now set explicitly in pnpm-workspace.yaml, each with its
reasoning inline:

- minimumReleaseAge quarantines anything published in the last three days, and
  minimumReleaseAgeStrict makes an immature pick abort the install rather than
  quietly excluding itself. Seven days -- the value worth wanting -- is not
  reachable yet: it rejects 65 current lockfile entries, and ranges like
  oxfmt's ^0.61.0 have no version old enough to satisfy it at all.
- trustPolicy rejects a version whose publish trail is weaker than that of a
  version published before it, which is what a package takeover looks like from
  outside. chokidar@4.0.3 and semver@6.3.1 predate their packages adopting
  trusted publishing and are excluded by name.
- trustLockfile stays false, so the two policies above are re-applied to every
  lockfile entry on each install rather than trusted from whoever resolved it.
- blockExoticSubdeps keeps git/http/file specs out of transitive manifests.
- strictDepBuilds turns an unlisted install script into an error.
- verifyStoreIntegrity and strictStorePkgContentCheck are pinned on.
- verifyDepsBeforeRun stops `pnpm run` against a node_modules that has drifted
  from the lockfile.

`pnpm audit` now runs as its own CI job and as the last step of `pnpm run ci`,
failing at audit.level (low). It stays out of both deploy workflows: an
advisory against a transitive dependency should not be what stops the blog from
shipping.

That audit was failing on GHSA-mh99-v99m-4gvg. brace-expansion reaches the tree
only through typed-css-modules > glob > minimatch, which has no release picking
the fix up, so its 2.x branch is pinned through overrides. The fix is itself
younger than the cooldown, hence the one minimumReleaseAgeExclude entry.

Verified on Node 26.5.1 with every policy live: clean install, frozen-lockfile
install (962 entries pass), the full ci run, all three builds, the deploy
workflows' --ignore-scripts path, and the blog's dev server. Both guards were
also made to fire on purpose -- verifyDepsBeforeRun aborts on an uninstalled
dependency, and audit exits 1 against the pre-fix lockfile.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Shinyaigeek

.github/workflows/ci.yml

@@ -58,6 +58,23 @@ jobs:
             - name: Run tests
               run: pnpm run test
 
+    audit:
+        needs:
+            - warmup_dependencies_cache
+        runs-on: ubuntu-latest
+        timeout-minutes: 5
+        env:
+            NODE_ENV: development
+        steps:
+            - uses: actions/checkout@v4
+            - uses: ./.github/actions/setup
+            # Fails on any advisory at or above audit.level in pnpm-workspace.yaml,
+            # currently `low`. This job is deliberately outside the deploy
+            # workflows: an advisory published against a transitive dependency
+            # should page us, not stop the blog from shipping.
+            - name: Audit dependencies
+              run: pnpm run audit
+
     build:
         needs:
             - warmup_dependencies_cache

CLAUDE.md

@@ -87,6 +87,7 @@ pnpm format        # oxfmt, writes in place
 pnpm format:check  # oxfmt --check
 pnpm typecheck     # tsc --noEmit in every package
 pnpm test          # vitest in every package that has tests
+pnpm audit         # advisories against the lockfile, needs network
 pnpm run ci        # all of the above, the way CI runs them
 ```
 
@@ -106,18 +107,57 @@ that is not 11.18.0 fetches that version and hands over to it rather than
 running as itself. The GitHub runner image does still ship corepack, which is
 what `corepack enable pnpm` in the workflows picks up.
 
-Dependencies' install scripts no longer run unless the package is listed under
-`allowBuilds`. The four that ask for one (`@swc/core`, `esbuild`, `msw`,
+### Supply-chain settings
+
+All of these are in `pnpm-workspace.yaml`, each with the reasoning inline. The
+two worth knowing before an install surprises you:
+
+- **`minimumReleaseAge: 4320`** quarantines anything published in the last three
+  days, and every install re-checks the whole lockfile against it, not just new
+  resolutions. So a version that was fine to resolve can still block a
+  `--frozen-lockfile` install for its first three days. `pnpm install` fails with
+  `ERR_PNPM_LOCKFILE_RESOLUTION_VERIFICATION` and names each entry. To take
+  something early anyway — a security fix, typically — add it to
+  `minimumReleaseAgeExclude` as `name@exact.version`, which is also what
+  `pnpm audit --fix` writes.
+- **`trustPolicy: no-downgrade`** rejects a version whose publish trail is weaker
+  than that of a version published before it. Old releases of a package that
+  later adopted trusted publishing trip this without anything being wrong;
+  `chokidar@4.0.3` and `semver@6.3.1` are listed under `trustPolicyExclude` for
+  exactly that reason. Check the publish dates before adding a third.
+
+Both checks cost registry round-trips on the first install after a lockfile
+change, and the verdict is cached afterwards.
+
+Dependencies' install scripts do not run unless the package is listed under
+`allowBuilds`, and `strictDepBuilds` makes an unlisted script an error rather
+than a warning. The four that ask for one (`@swc/core`, `esbuild`, `msw`,
 `workerd`) are all listed as `false`: each ships its platform binary as an
 optional dependency and only uses the script to unpack or shortcut to it, and
 the deploy workflows have always installed with `--ignore-scripts` anyway.
 
+`verifyDepsBeforeRun: error` means `pnpm run` and `pnpm exec` refuse to start
+when `node_modules` has drifted from the lockfile, with
+`ERR_PNPM_VERIFY_DEPS_BEFORE_RUN`. Editing a dependency in a package.json and
+running a script before installing is the usual way to meet it.
+
+`pnpm audit` runs as its own CI job and as the last step of `pnpm run ci`,
+failing on any advisory at or above `audit.level` (`low`). It is deliberately
+not in either deploy workflow: an advisory landing against a transitive
+dependency should not be what stops the blog from shipping.
+
 `overrides` in `pnpm-workspace.yaml` pins **rollup** to 4.62.2. From 4.62.3
 its prebuilt Linux binary needs GLIBC 2.32, which is newer than the dev machine
 (Ubuntu 20.04, GLIBC 2.31) has, so vitest dies with `ERR_DLOPEN_FAILED` on every
 `pnpm test`. CI runs on ubuntu-latest and is unaffected — drop the override once
 the dev machine is on a newer glibc.
 
+The second override pins **brace-expansion**'s 2.x branch to ^2.1.4 for
+GHSA-mh99-v99m-4gvg. It reaches the tree only through
+`typed-css-modules > glob > minimatch`, which has no release picking the fix up,
+so the override is the only way to clear the advisory; drop it once
+typed-css-modules moves off that minimatch.
+
 ### Blog (packages/applications/blog/)
 ```bash
 pnpm dev            # watch everything, 日本語 on :3000 and English on :3001

package.json

@@ -18,7 +18,8 @@
     "lint:fix": "oxlint --fix ./packages",
     "typecheck": "pnpm -r typecheck",
     "test": "pnpm -r test",
-    "ci": "pnpm run lint && pnpm run format:check && pnpm run typecheck && pnpm run test"
+    "audit": "pnpm audit",
+    "ci": "pnpm run lint && pnpm run format:check && pnpm run typecheck && pnpm run test && pnpm run audit"
   },
   "keywords": [],
   "author": "",