build(deps-dev): bump @types/node from 22.20.2 to 26.5.1

[dependabot]

Bumps @types/node from 22.20.2 to 26.5.1.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[clawsweeper]

Codex review: blocked before merge. Reviewed September 14, 2026, 12:12 PM ET / 16:12 UTC.

ClawSweeper review

What this changes

Updates development-time Node.js definitions from 22.20.2 to 26.5.1 and refreshes their transitive types and lockfile references.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open for an explicit compatibility decision: recent merged work deliberately aligned typings with Node 22. No current runtime failure is established, and this upgrade is absent from main and v0.8.1.

Priority: P3
Reviewed head: b2992ffafc38036d1fad4763d76ed1b8a92138a4
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The manifest and lockfile update is consistent and checks pass; accepting its compatibility strategy remains a human decision.
Proof confidence	🌊 off-meta tidepool	Not applicable: This Dependabot-authored development-types update is exempt from contributor runtime proof; the supplied compatibility checks provide supplemental validation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This Dependabot-authored development-types update is exempt from contributor runtime proof; the supplied compatibility checks provide supplemental validation.
Evidence reviewed	5 items	Verified introduced scope: The complete pinned diff changes only the development dependency and corresponding lockfile entries, including undici-types. It changes no runtime dependency, lifecycle script, permission, or application source. Explicit prior compatibility choice: Merged #209 explicitly aligns typings with Node 22 while preserving the runtime floor. Its verified commit patch changes @types/node from ^26.4.1 to ^22.20.2 and adds Node 22/24 runtime jobs. Current-main and release comparison: Both fetched main and the v0.8.1 package manifest retain @types/node ^22.20.2 and engines.node >=22; the proposed upgrade has not already landed.
Findings	None	None.
Security	None	None.

How this fits together

Clawpatch uses Node.js type definitions when compiling its TypeScript CLI and tests. These definitions determine which Node APIs the compiler accepts, while the published CLI supports Node 22 and newer.

flowchart LR
  A[CLI and test source] --> C[TypeScript compiler]
  B[Node type definitions] --> C
  C --> D[Compiled CLI]
  D --> E[Node 22 and 24 compatibility checks]
  D --> F[Node 26 checks]

Loading

Decision needed

Question	Recommendation
Should Node 26 typings replace the Node 22 baseline deliberately established by the recent compatibility refresh?	Preserve Node 22 alignment: Keep the existing typings baseline and decline this major-version bump.

Why: The upgrade reverses an explicit merged compatibility choice without explaining why; current passing checks cannot decide that policy.

Before merge

• Resolve merge risk (P1) - Node 26 typings permit future source changes to compile against APIs unavailable on supported Node 22 installations; passing current runtime checks does not preserve the previous compile-time guard.
• Complete next step (P2) - Obtain an explicit decision on replacing the deliberately selected Node 22 typings baseline before merging.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

None.

Merge-risk options

Maintainer options:

1. Keep the supported-runtime typings baseline (recommended)
   Decline this major upgrade to preserve the existing Node 22 compile-time compatibility guard.
2. Explicitly accept newer API definitions
   Approve Node 26 typings with the understanding that runtime CI becomes more important for detecting unsupported API use.

Technical review

Best possible solution:

Retain Node 22 typings while Node 22 remains the runtime floor, unless maintainers explicitly approve a different compatibility strategy.

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

Not applicable: this dependency update reports no existing bug, and the supplied Node 22/24 checks pass.

Is this the best way to solve the issue?

No, absent explicit approval: keeping typings aligned with the minimum runtime preserves the compatibility strategy documented in the recent merged refresh.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add P3: This is development dependency maintenance with no established current user-facing failure.
• add merge-risk: 🚨 compatibility: The bump removes the intentional alignment between compile-time Node definitions and the supported Node 22 runtime floor.
• 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 Dependabot-authored development-types update is exempt from contributor runtime proof; the supplied compatibility checks provide supplemental validation.

Label justifications:

• P3: This is development dependency maintenance with no established current user-facing failure.
• merge-risk: 🚨 compatibility: The bump removes the intentional alignment between compile-time Node definitions and the supported Node 22 runtime floor.
• 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 Dependabot-authored development-types update is exempt from contributor runtime proof; the supplied compatibility checks provide supplemental validation.

Evidence

What I checked:

• Verified introduced scope: The complete pinned diff changes only the development dependency and corresponding lockfile entries, including undici-types. It changes no runtime dependency, lifecycle script, permission, or application source. (package.json:44, b2992ffafc38)
• Explicit prior compatibility choice: Merged chore: update dependencies and verify supported Node runtimes in CI #209 explicitly aligns typings with Node 22 while preserving the runtime floor. Its verified commit patch changes @types/node from ^26.4.1 to ^22.20.2 and adds Node 22/24 runtime jobs. (package.json:44, b979f94701be)
• Current-main and release comparison: Both fetched main and the v0.8.1 package manifest retain @types/node ^22.20.2 and engines.node >=22; the proposed upgrade has not already landed. (package.json:44, aa0565d82caf)
• Compatibility validation: CI builds, tests, and runs installed-package smoke checks on Node 22 and 24, alongside Node 26 validation. Supplied checks report success for these jobs. The smoke harness installs the packed CLI and exercises init and map. No tests or builds were executed during this read-only review. (.github/workflows/ci.yml:48, b2992ffafc38)
• Routing history: Recent package and CI history repeatedly identifies Peter Steinberger; GitHub identifies steipete as the author of the merged compatibility refresh. Some historical blobs were unavailable, preventing local blame and deeper patch inspection; the relevant merged patch was independently read through GitHub. (package.json, b979f94701be)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

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

• Resolve whether to preserve the recent Node 22 typings baseline or explicitly approve replacing it.

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.