chore(deps): refresh dependencies

[steipete]

Summary

• Refresh @stryker-mutator/core 9.6.1 → 10.0.0 after proving the complete 424-mutant CI job still passes.
• Refresh oxfmt 0.63.0 → 0.64.0 and oxlint 1.78.0 → 1.79.0; the lockfile also picks up safe compatible patch updates under the unchanged 48-hour minimumReleaseAge policy.
• Held: none; the Stryker major is included only after real mutation-runner proof.
• Supersedes Dependabot PRs chore(deps-dev): bump @stryker-mutator/core from 9.6.1 to 10.0.0 #506 and chore(deps-dev): bump the development group with 2 updates #512.

Verification

• pnpm install --no-frozen-lockfile — canonical project-pinned pnpm 10.34.5 and the existing two-day release maturity policy.
• pnpm run mutate — 424 mutants, 385 killed, zero errors/timeouts, 90.80% mutation score, exceeding the configured 80% threshold.
• pnpm run check — formatting, typechecking, type-aware lint, production Node 22 CLI/library bundles, replay-viewer typechecking and Vite production build, all 935 primary tests, and the 85%-threshold runtime coverage gate passed.
• Coverage: 94.64% statements/lines, 88.39% branches, 96.67% functions; the focused coverage phase passed all 130 runtime/flow tests.
• pnpm run conformance:run -- --case acp.v1.initialize.handshake — real ACP handshake passed.
• Compiled CLI runtime smokes: node dist/cli.js --help, --version, and config show --format json all exited 0.
• pnpm audit --prod --json — zero production vulnerabilities.
• Structured pre-commit Codex review: clean.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs changes before merge. Reviewed August 23, 2026, 12:38 PM ET / 16:38 UTC.

ClawSweeper review

What this changes

Updates Stryker, Oxfmt, and Oxlint development dependencies and refreshes their pnpm lockfile resolutions.

Merge readiness

⚠️ Needs maintainer review before merge - 3 items remain

Keep this PR open: the Stryker major brings Babel 8 packages whose declared Node floor is higher than acpx’s documented Node 22.13 baseline, so the mutation workflow needs compatibility resolution before merge.

Priority: P2
Reviewed head: 1b2aea4407cc5f7e9bc9ec7f3b780536caf999b7

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The reported validation is strong, but the supported Node baseline remains a merge-blocking compatibility concern.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (live_output): The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (live_output): The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.
Evidence reviewed	6 items	Declared project baseline: The package manifest still declares Node >=22.13.0 as the project engine floor. New transitive Node constraint: The refreshed lockfile resolves Babel 8, which declares Node ^22.18.0 or >=24.11.0. Dependency path: Stryker’s updated instrumenter directly consumes the Babel 8 packages, so their engine contract applies to the changed mutation workflow.
Findings	1 actionable finding	[P1] Preserve the documented Node 22.13 mutation workflow
Security	None	None.

How this fits together

acpx’s development toolchain runs formatting, linting, mutation testing, and release validation before publishing the CLI. The manifest selects those tools and the lockfile supplies their executable transitive dependencies.

flowchart LR
  A[Package manifest] --> B[Lockfile resolution]
  B --> C[Development tools]
  C --> D[Lint and mutation checks]
  D --> E[Release validation]
  E --> F[Published CLI]

Loading

Before merge

• Preserve the documented Node 22.13 mutation workflow (P1) - Stryker 10 resolves @stryker-mutator/instrumenter to Babel 8, whose locked packages declare ^22.18.0 || >=24.11.0, while this repository still supports Node >=22.13.0. The floating CI Node 22 job does not exercise that lower bound, so contributors on supported 22.13–22.17 may no longer be able to run the required mutation check. Verify that range or retain a compatible Stryker resolution before merging.
• Resolve merge risk (P1) - Merging can leave contributors on the documented Node 22.13–22.17 range with a mutation-tool dependency graph that declares their runtime unsupported.
• Complete next step (P2) - A focused repair can preserve the documented Node baseline while retaining the independently compatible tool updates.

Findings

• [P1] Preserve the documented Node 22.13 mutation workflow — package.json:90

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Dependency surface	3 direct development dependencies; 2 files; lockfile +543/-522	The Stryker major transitively replaces the Babel toolchain used by mutation testing.

Merge-risk options

Maintainer options:

1. Retain the documented Node baseline (recommended)
   Verify the mutation command on Node 22.13 and keep a compatible Stryker resolution if Babel 8 cannot support it.
2. Adopt a higher tooling floor
   Explicitly document and test a separate Node floor for contributor validation if maintainers intentionally accept the narrower mutation-tool environment.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Verify `pnpm run mutate` on Node 22.13; if the refreshed Stryker graph is unsupported, retain a compatible Stryker version while preserving the Oxfmt and Oxlint updates.

Technical review

Best possible solution:

Keep mutation testing usable on the documented Node baseline, or deliberately establish a separate, clearly tested development-tooling Node policy without narrowing the published CLI’s support accidentally.

Do we have a high-confidence way to reproduce the issue?

No. The lockfile proves an unsupported Node-range overlap, but neither the PR evidence nor this read-only review runs pnpm run mutate on Node 22.13.

Is this the best way to solve the issue?

No: the update should not merge unchanged until a Node 22.13 mutation run verifies the declared baseline or the dependency resolution is made compatible.

Full review comments:

• [P1] Preserve the documented Node 22.13 mutation workflow — package.json:90
  Stryker 10 resolves @stryker-mutator/instrumenter to Babel 8, whose locked packages declare ^22.18.0 || >=24.11.0, while this repository still supports Node >=22.13.0. The floating CI Node 22 job does not exercise that lower bound, so contributors on supported 22.13–22.17 may no longer be able to run the required mutation check. Verify that range or retain a compatible Stryker resolution before merging.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.91

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 2d735cf18220.

Labels

Label changes:

• add P2: The affected surface is contributor validation rather than the shipped CLI, but supported local workflows can be disrupted.
• add merge-risk: 🚨 compatibility: The new Babel 8 transitive packages require a newer Node 22 minor than the documented project baseline.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.

Label justifications:

• P2: The affected surface is contributor validation rather than the shipped CLI, but supported local workflows can be disrupted.
• merge-risk: 🚨 compatibility: The new Babel 8 transitive packages require a newer Node 22 minor than the documented project baseline.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body records post-update mutation, full-check, ACP-handshake, and compiled CLI smoke results from a real setup.

Evidence

Acceptance criteria:

• [P1] Node 22.13: pnpm install --frozen-lockfile.
• [P1] Node 22.13: pnpm run mutate.
• [P1] pnpm run check.

What I checked:

• Declared project baseline: The package manifest still declares Node >=22.13.0 as the project engine floor. (package.json:126, 1b2aea4407cc)
• New transitive Node constraint: The refreshed lockfile resolves Babel 8, which declares Node ^22.18.0 or >=24.11.0. (pnpm-lock.yaml:125, 1b2aea4407cc)
• Dependency path: Stryker’s updated instrumenter directly consumes the Babel 8 packages, so their engine contract applies to the changed mutation workflow. (pnpm-lock.yaml:3760, 1b2aea4407cc)
• Current CI coverage gap: The mutation job selects floating Node 22 with check-latest, rather than the documented 22.13 lower bound. (.github/workflows/ci.yml:115, 2d735cf18220)
• Area history: Dependency refreshes and the current package engine line are repeatedly attributed to Peter Steinberger, including the prior refresh commit 272d934. (package.json:90, 272d93409a97)
• Reported real validation: The PR body records a full mutation run, check suite, ACP handshake, and compiled CLI smoke results after the update. (1b2aea4407cc)

Likely related people:

• steipete: History shows repeated authored dependency refreshes and releases, and the current Node engine line is attributed to Peter Steinberger. (role: recent dependency and Node-support contributor; confidence: high; commits: 272d93409a97, 2d735cf18220, 1b2aea4407cc; files: package.json, pnpm-lock.yaml, .github/workflows/ci.yml)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Run pnpm run mutate on Node 22.13, or retain a compatible Stryker resolution.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.