chore: bump @types/node from 22.19.17 to 22.20.4

[dependabot]

Bumps @types/node from 22.19.17 to 22.20.4.

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)

[claude]

Claude finished @dependabot[bot]'s task in 56s —— View job

---

Dependency review: @types/node 22.19.17 → 22.20.4

• Read PR diff and identify what changed
• Check Node floor (engines.node) vs. the new types version
• Verify Dependabot major-ignore rule is intact
• Build + test on the branch — not run locally (see caveat below)
• Post review

Verdict: safe to merge, pending green CI.

What changed

Lockfile-only, 3 lines — version, resolved, integrity for @types/node. The devDependencies range in package.json is untouched at "^22.0.0", and no transitive dependency moved.

Semver and the major-ignore rule

Minor bump inside the 22 line, so the ignore rule in .github/dependabot.yml:24-25 (version-update:semver-major only) is working as intended — nothing to investigate there.

Node floor

package.json:13 declares "node": ">=22", and the workflows agree: ci.yml:20 matrixes ['22', '24'], update-catalog.yml:27 pins '22', manifest.json declares the same floor. @types/node@22.20.4 stays on the 22 line, so the floor and the types still match — this is exactly the case the CLAUDE.md rule is meant to permit. (release.yml:26 on Node 24 is deliberate; it only builds and publishes.)

One nuance worth naming, not a blocker: >=22 literally admits Node 22.0.0, while 22.20.x type definitions describe APIs up to Node 22.20. tsc would accept something added in, say, 22.12 and not flag it on a 22.0.0 runtime. That gap is inherent to expressing the floor as a major-line range and is unchanged by this PR; it only tightens if the floor becomes a specific minor.

Usage surface

The repo's actual dependence on Node types is small enough to enumerate:

• process.env — src/config.ts:4,11,17
• process.exit — src/index.ts:13
• typeof globalThis.fetch — src/client/kosli-client.ts:23,67, src/tools/execute-action.ts:5,151

No node: module imports in src/. None of these are areas DefinitelyTyped churns within a minor; the fetch/undici typings in the 22 line have been stable. strict: true, ESM/NodeNext, and the .js extension convention are all untouched by this PR.

Caveat on verification

I could not run npm ci / npm run build / npm test in this session — the install step wasn't permitted in my sandbox, and there is no pre-existing node_modules. My analysis is static, so the typecheck claim above is reasoned from the usage surface, not observed. ci.yml running tsc on both Node 22 and 24 is the real gate here — if it's green, the bump is confirmed. To let me verify these locally in future runs, npm ci, npm run build, and npm test would need to be in --allowedTools.
· branch