chore(deps-dev): bump @types/node from 24.2.0 to 26.0.1

[dependabot]

Bumps @types/node from 24.2.0 to 26.0.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)

[alfred-openspec]

OpenSpec still supports Node 20.19, so compiling against Node 26 types can admit APIs unavailable at the runtime floor even though the current suite passes. Please keep @types/node aligned with the supported runtime baseline; the Nix dependency hash is also currently red.

[clay-good]

Code review — verdict: merge once the Nix hash is updated

@types/node 24.2.0 → 26.0.1, a devDependency. Type-only, so it cannot affect shipped runtime behaviour — it can only cause compile errors, and it doesn't.

Verified

• pnpm install --frozen-lockfile + npm run build: clean, no type errors.
• Full suite: 112 files / 2253 tests, all passing, matching the origin/main baseline.
• Lint & Type Check is green in CI.

Assessment

1. Need: routine maintenance.
2. Works: yes.
3. Breaking: none. @types/node ships no runtime code and isn't in dependencies, so nothing reaches users' installs. Skipping two majors (24 → 26) would normally warrant caution about newly-strict or removed type definitions, but the build is clean against the real source tree, which is the check that matters.
4. Scope: package.json + lockfile only.

Worth noting the two majors track Node 25/26 type surfaces while OpenSpec targets node >=20.19.0. That's normal and safe — @types/node remains backward-compatible for older runtimes — but it does mean the types can now describe APIs that don't exist on Node 20. The compiler won't catch a Node-20-absent API used from source. That's an argument for keeping the CI test matrix honest about the minimum supported Node version, not against this bump.

The shared blocker: flake.nix pnpmDeps hash

Nix Flake Validation is red:

error: hash mismatch in fixed-output derivation ...openspec-pnpm-deps.drv
    specified: sha256-82sVXXqj4mfe6n6BRagUiOQS0Gd+jbPOQiYzUhmrZGU=
       got:    sha256-rNUXCeNPuGKYB8TfhEv95dO1iTgyfKdnD5OXtFoMIYE=

Expected, and not the PR's fault: flake.nix pins a content hash of the pnpm dependency set, so any pnpm-lock.yaml change invalidates it and dependabot cannot update Nix files. One-line fix in flake.nix using the hash CI already computed above (or bash scripts/update-flake.sh locally with Nix installed).

One process note for the batch

Four lockfile-touching dependabot PRs are currently in this same state (#1448, #1451, #1452, #1453). Merging any one invalidates the hash on the other three, so serial merges mean four rounds of hash regeneration. Consolidating into a single PR with one lockfile resolution and one hash (as in #1427) would be much less churn. Leave #1450 out — it has a real API break needing a code change.

[clay-good]

Superseded by #1457, which consolidates this with the other three lockfile bumps into a single resolution.

Why consolidate: every one of these PRs changes pnpm-lock.yaml, and flake.nix pins a content hash of the pnpm dependency set — so merging them one at a time would invalidate that hash four times over, needing four regenerations and three rebases. Dependabot can't update Nix files, which is why all four were red on Nix Flake Validation. Same approach as #1427.

This PR's bump is carried over unchanged in #1457, which is green on all 15 checks including Nix Flake Validation and the full linux/macOS/Windows test matrix.

Worth noting for the record: the consolidated lockfile resolves to sha256-x3AFjyWjl2DkQFOnSuv8a90/JrZZpiweueORWaPxAbU=, which is different from the hash any of these PRs would have produced individually — so the per-PR hashes couldn't simply be reused.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.