fix(docs): pin typescript to ^6 so npm ci resolves

[worktrunk-bot]

publish-docs is red on main: @astrojs/check@0.9.10 declares peer typescript@"^5.0.0 || ^6.0.0", so the TypeScript 7 lockfile that landed in #3870 makes npm ci fail with ERESOLVE before any docs step runs. This reverts docs/package.json + docs/package-lock.json to their pre-bump state and tells Dependabot to skip TypeScript majors until @astrojs/check accepts ^7. Verified locally with npm ci and npm run check.

Problem

Run 32615600271 failed at the Install docs dependencies step of .github/actions/docs-build:

npm error While resolving: @astrojs/check@0.9.10
npm error Found: typescript@7.0.2
npm error Could not resolve dependency:
npm error peer typescript@"^5.0.0 || ^6.0.0" from @astrojs/check@0.9.10

check-docs had already failed the same way on #3870 itself (run 32558778950), so the breakage merged rather than appearing after it. Every publish-docs run since is red — 64efa5e5d and be2c088a6 (current main) — and every subsequent run will be, because the failure is in dependency installation, not in anything docs content can change.

There is no upstream fix to move to: 0.9.10 is the latest @astrojs/check, and its peer range still excludes ^7.

Solution

Three parts, two durable:

1. Revert the bump. docs/package.json goes back to typescript: "^6.0.3" and docs/package-lock.json is restored byte-for-byte to 8e405bced (chore: bump typescript from 6.0.3 to 7.0.2 in /docs in the docs-site group #3870's merge base) rather than regenerated — chore: bump typescript from 6.0.3 to 7.0.2 in /docs in the docs-site group #3870 is the only commit to touch either file since, and the local npm is 10.9.8 against CI's 11.17.0, which would otherwise strip libc metadata from ~20 optional dependency entries as unrelated churn. The lockfile diff is exactly the inverse of chore: bump typescript from 6.0.3 to 7.0.2 in /docs in the docs-site group #3870's.
2. Stop it recurring. An ignore entry for typescript version-update:semver-major under the /docs npm ecosystem. Without it Dependabot reproposes the identical bump next week, and the fix is a revert each time. Minor and patch TypeScript 6 updates still flow through the docs-site group; the comment names the condition for removing the entry.
3. Give that condition a reader. The ignore entry suppresses the only proposal Dependabot would ever make for it, so nothing surfaces when @astrojs/check widens its peer range — and the rule is version-agnostic, so it would go on blocking a TypeScript major @astrojs/check fully supports. The weekly CI Pin Bumps pass is where versions Dependabot can't see get revisited, and it currently says to skip docs/package.json outright; .claude/skills/running-tend/SKILL.md now names this entry as the exception that pass owns, with the npm view check to run and the condition for deleting it.

Pinning at the manifest is the right level here — the alternative fixes (npm ci --legacy-peer-deps in the composite action, or an overrides block) would silence the peer conflict for every dependency rather than the one that is genuinely incompatible, and would let a real breakage install quietly.

Testing

Ran the CI install and check steps locally against the fixed tree, in docs/:

Verification output

$ rm -rf node_modules && npm ci --ignore-scripts
added 450 packages, and audited 451 packages in 5s
found 0 vulnerabilities
NPM_CI_EXIT=0

$ npm run check
[check] Getting diagnostics for Astro files in /home/runner/work/worktrunk/worktrunk/docs...
Result (7 files):
- 0 errors
- 0 warnings
- 0 hints
CHECK_EXIT=0

npm ci left the lockfile unmodified, confirming manifest and lockfile agree. The remaining docs-build steps (npm test, npm run build, npm run test:site) need the worktrunk-assets clone, so CI covers those — check-docs on this PR exercises the whole action.

Fixes #3879 — the scheduled nightly run auto-filed it for the same ERESOLVE on link-check (run 32621228902).

---

Automated fix for failed run

[worktrunk-bot]

Another occurrence of this failure: run 32615714639 — publish-docs on be2c088a6, same ERESOLVE at the Install docs dependencies step. tend-ci-fix fired on it and derived the same revert independently; this PR already covers it, so nothing new is being opened.

One thing worth adding: the PR body defers npm test, npm run build, and npm run test:site to CI because they need the worktrunk-assets clone. I was able to clone the assets repo from the sandbox, so I ran the full docs-build sequence against the reverted tree — all four steps pass locally.

Local run of the whole docs-build sequence

Against main with docs/package.json and docs/package-lock.json reverted to 8e405bced (identical to this PR's tree for those two files), in docs/:

$ npm ci
added 450 packages, and audited 451 packages in 7s
found 0 vulnerabilities

$ gh repo clone max-sixty/worktrunk-assets /tmp/worktrunk-assets -- --depth 1
$ cp -r /tmp/worktrunk-assets/assets public/

$ npm run check
Result (7 files):
- 0 errors
- 0 warnings
- 0 hints

$ npm test
# tests 9
# pass 9
# fail 0

$ npm run build
[build] 16 page(s) built in 3.90s
[build] Complete!

$ npm run test:site
# tests 13
# pass 13
# fail 0

Local npm is 10.9.8 / node v22.23.2 against CI's 11.17.0 / node 24, so check-docs on this PR remains the authoritative signal — but the docs content itself builds and tests clean under the ^6.0.3 pin, which is the part the revert could plausibly have disturbed.

Separately, the reason this reached main at all: check-docs is not among the required contexts on the "Merge access" ruleset (test (linux|macos|windows), fast-checks), so #3870's red check-docs did not block its merge. Adding it would catch the next docs-only breakage at the PR rather than after it — a maintainer call, and out of scope for this PR.

[worktrunk-bot]

Self-review. The fix itself holds up on the facts: @astrojs/check@0.9.10 is still the latest release and its peer range is {"typescript": "^5.0.0 || ^6.0.0"}, typescript@6.0.3 is the latest 6.x, and both docs/package.json and docs/package-lock.json at this head are byte-identical to their blobs at 8e405bced (#3866) — so the "restored rather than regenerated" claim is exact, not approximate. check-docs passes here, which is the step that failed on #3870.

One thing I'd want a maintainer to decide on, flagged inline: the new ignore entry has no reader for its own removal condition.

[worktrunk-bot]

Self-review of 2109b84. The bullet closes the gap the last review flagged — the weekly pin-bump pass now owns the ignore entry, with a version-agnostic removal condition and a concrete check (npm view @astrojs/check peerDependencies.typescript returns ^5.0.0 || ^6.0.0 today, against @astrojs/check@0.9.10). Resolving that thread.

One thing the commit left behind: the inline comment on the ignore entry in .github/dependabot.yaml still says "Drop this once @astrojs/check accepts ^7", which is the narrow framing the commit message itself argues against. The entry blocks every typescript major, so following that condition literally when @astrojs/check widens to ^7 while TypeScript 8 is current would drop the guard and let the same ERESOLVE back into npm ci — the exact failure this PR reverts. It's the same defect one file over from the one just fixed, so I'm pushing the comment fix rather than leaving the two halves of one instruction disagreeing.

[worktrunk-bot]

A third occurrence, and a new workflow: run 32615601934 — nightly / link-check on 7275a5ad9, failing with the same ERESOLVE at the Install docs dependencies step. link-check started running the shared composite in #3874, so the blast radius of #3870 is three legs, not one: check-docs, publish-docs, and now nightly. Nothing new opened — this PR is the fix.

The reason it's worth a comment rather than a silent tally is timing. That run was push-triggered, so create-issue-on-nightly-failure was skipped — its if: requires github.event_name == 'schedule'. Today's cron (37 5 * * *, so ~05:47 UTC in practice) is not skipped, and the gate job passes non-PR events through unconditionally, so link-check will fail the same way and auto-file a nightly-failure issue against main. Merging this before then is the difference between a red workflow and a red workflow plus a bot-authored issue to close.

Evidence

The failing step in run 32615601934, before lychee is even installed (Fetch docs assets, Check docs source, Build docs, Test built site all report outcome=skipped after it):

npm error While resolving: @astrojs/check@0.9.10
npm error Found: typescript@7.0.2
npm error Could not resolve dependency:
npm error peer typescript@"^5.0.0 || ^6.0.0" from @astrojs/check@0.9.10

link-check gained the composite in e3adde218 (#3874), which is an ancestor of 7275a5ad9 — so the leg was already consuming npm ci when #3870 landed. The last scheduled nightly run, 32555217021 on 5a870224d (2026-08-22, before #3870), was green, which is what dates the breakage to the bump rather than to the composite sharing.

The issue-filing job's gate, at .github/workflows/nightly.yaml:429:

if: always() && contains(needs.*.result, 'failure') && github.repository_owner == 'max-sixty' && github.event_name == 'schedule'

link-check is in its needs, so a red link-check alone satisfies contains(needs.*.result, 'failure').

This PR's own checks are green at 3ecd80eb6, including check-docs (34s) and codecov/patch.