build(deps): refresh eligible tooling and security scanners

[dependabot]

Refresh Zod, Vitest/V8 coverage, Oxlint, Oxfmt, Node 22 typings, pnpm 11, CodeQL, and TruffleHog while retaining Node 22 compatibility and the 48-hour dependency release-age policy. This incorporates #221 and #224 and updates TruffleHog’s explicit runtime version alongside its action pin.

Restore Crabbox validation by sizing its disk to the image’s 400 GB minimum and explicitly selecting pnpm 11.27.0 in the hydration workflow, matching package.json.

Validation: frozen install, typecheck, lint, formatting, full V8 coverage suite (962 passed, 2 platform skips), build, and installed-package smoke checks all passed on AWS Crabbox. Independent Codex review of the final diff is clean through P2. The GitHub scanner log confirms TruffleHog 3.97.5 executed successfully.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 21, 2026, 12:12 PM ET / 16:12 UTC.

ClawSweeper review

What this changes

Updates Vitest and V8 coverage to 5.0.1, Oxfmt to 0.68.0, and Oxlint to 1.83.0 through the development dependency manifest and lockfile.

Merge readiness

✅ Ready for maintainer review

Keep open: these dependency updates are absent from current main and v0.8.1. The scoped patch has no identified correctness or security defect, and the reported validation checks passed.

Priority: P3
Reviewed head: 495a4692606b203d708dc8b58fd9c13902e04434

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused dependency update with coherent lockfile changes, passing reported checks, and no actionable defect.
Proof confidence	🌊 off-meta tidepool	Not applicable: This bot-authored development-tool update is exempt from contributor runtime proof; reported CI exercises the changed formatter, linter, test runner, and coverage provider.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This bot-authored development-tool update is exempt from contributor runtime proof; reported CI exercises the changed formatter, linter, test runner, and coverage provider.
Evidence reviewed	7 items	Pinned introduced change: The complete introduced diff changes only package.json and pnpm-lock.yaml. Vitest and coverage peers move together; existing native binding packages receive matching version and integrity updates. Runtime dependencies, lifecycle scripts, permissions, and Node engine constraints are unchanged. Still needed on main and release: The live main SHA remains the pinned base. Its manifest retains Oxfmt ^0.67.0, and the inspected v0.8.1 lockfile retains Vitest/coverage 5.0.0, Oxfmt 0.67.0, and Oxlint 1.82.0. Recent PR metadata does not establish a merged replacement for these updates. Validation coverage: The existing Node 26 CI job runs frozen installation, typecheck, lint, formatting checks, V8 coverage, build, and package smoke checks; additional jobs cover Windows execution and Node 22/24. Supplied check results report success for those jobs and dependency review. No builds or tests were executed during this read-only review.
Findings	None	None.
Security	None	None.

How this fits together

Clawpatch’s development tooling formats and checks source code, runs tests, and produces coverage reports. These dependencies support local development and CI without changing the published CLI’s runtime dependencies.

flowchart LR
  A[Dependency manifest] --> B[Locked tool versions]
  B --> C[Formatter and linter]
  B --> D[Tests and coverage]
  E[Repository source] --> C
  E --> D
  C --> F[CI validation results]
  D --> F

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Retain the coordinated development-tool updates with matching Vitest coverage peers and the existing runtime compatibility checks.

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

Not applicable: this is a dependency maintenance PR rather than a reported product bug; no introduced failure was identified.

Is this the best way to solve the issue?

Yes: the manifest and lockfile updates use the existing tooling path, preserve matching coverage peers, and avoid unrelated application changes.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 4d3dad28a600.

Labels

Label changes:

• add P3: Routine development dependency maintenance with unchanged runtime dependencies and no identified user-facing regression.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This bot-authored development-tool update is exempt from contributor runtime proof; reported CI exercises the changed formatter, linter, test runner, and coverage provider.

Label justifications:

• P3: Routine development dependency maintenance with unchanged runtime dependencies and no identified user-facing regression.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This bot-authored development-tool update is exempt from contributor runtime proof; reported CI exercises the changed formatter, linter, test runner, and coverage provider.

Evidence

What I checked:

• Pinned introduced change: The complete introduced diff changes only package.json and pnpm-lock.yaml. Vitest and coverage peers move together; existing native binding packages receive matching version and integrity updates. Runtime dependencies, lifecycle scripts, permissions, and Node engine constraints are unchanged. (package.json:46, 495a4692606b)
• Still needed on main and release: The live main SHA remains the pinned base. Its manifest retains Oxfmt ^0.67.0, and the inspected v0.8.1 lockfile retains Vitest/coverage 5.0.0, Oxfmt 0.67.0, and Oxlint 1.82.0. Recent PR metadata does not establish a merged replacement for these updates. (pnpm-lock.yaml:31, aa0565d82caf)
• Validation coverage: The existing Node 26 CI job runs frozen installation, typecheck, lint, formatting checks, V8 coverage, build, and package smoke checks; additional jobs cover Windows execution and Node 22/24. Supplied check results report success for those jobs and dependency review. No builds or tests were executed during this read-only review. (.github/workflows/ci.yml:26, 495a4692606b)
• Vitest package provenance: Read-only npm registry metadata for vitest@5.0.1 and @vitest/coverage-v8@5.0.1 identifies vitest-dev/vitest and matches the lockfile integrity values. Neither metadata record adds an install lifecycle script. The target directly executes these packages through its test and coverage scripts. Sources: https://registry.npmjs.org/vitest/5.0.1 and https://registry.npmjs.org/@vitest/coverage-v8/5.0.1.
• Formatter and linter provenance: Read-only npm registry metadata for oxfmt@0.68.0 and oxlint@1.83.0 identifies oxc-project/oxc and matches the lockfile integrity values. Both retain the recorded Node requirements and have no scripts field. The target invokes these packages through its formatting and lint scripts. Sources: https://registry.npmjs.org/oxfmt/0.68.0 and https://registry.npmjs.org/oxlint/1.83.0.
• Discussion source identity: The fetched full PR body matches captured SHA-256 fa36b3e425d841b7da80043d927e87fc77bad7a39eb280a1f1f08ab6de7f22bd; the omitted portions were inspected. Its content describes upstream dependency releases and Dependabot operations. The supplied discussion contains no human review or competing implementation. Upstream Vitest references do not establish same-repository related items. (495a4692606b)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)
• openclaw/openclaw-secops: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.