build(node): coordinate Node 22.22.2 floor with jsdom 30

[seonghobae]

Canonical Node/jsdom/npm compatibility owner

This Draft advances the Node 22/jsdom 30 compatibility slice on protected develop. Predecessor checks or reviews do not transfer to the current head.

Exact current identity

• Head: 1a27cc3a3ce09bf9c0605ca1b039eae13f040f49.
• Protected base: develop@314ddeae7b775a4957594b599358c8255617eb2e.
• Comparison: 101 commits ahead / 0 behind, 11 changed files.
• The remote tree 1e71183fbf0740d98ec2bcd9f862f1b742de38e9 is byte-for-byte the locally verified tree.
• The head is a non-force descendant of the prior build(node): coordinate Node 22.22.2 floor with jsdom 30 #896 head, protected develop, the valid ESLint intent from build(deps-dev): bump eslint from 10.8.1 to 10.9.1 #1136, and the canonical Ruff repair from repair(ci): format consolidated supply-chain policy test #1176.

Repair

The former real RED state paired Node >=22.22.2 <23 and jsdom ^30.0.1 manifests with the protected pre-migration lock. Separately, #1136 carried valid ESLint ^10.9.1 manifest intent but its generated lock removed all 26 platform-specific root @esbuild/* peer: true records.

The canonical owner now:

• preserves jsdom ^30.0.1 and ESLint ^10.9.1 in both owning workspaces;
• generates the complete root lock with exact Node 22.22.2 and npm 10.9.9 using npm install --package-lock-only --ignore-scripts --no-audit --no-fund;
• preserves lockfile v3, public-registry SRI, PDF.js/Undici security baselines, and every root esbuild peer marker;
• records package-lock SHA-256 641e83f8abc85345661ce531908df6fd94e1771e46cfbaff857aec40cc276174;
• adds an executable ESLint manifest/lock regression;
• corrects stale runtime assertions that inspected a workflow-global environment value inside a job body and rejected valid transitive package engine ranges;
• integrates protected workflow consolidation and repair(ci): format consolidated supply-chain policy test #1176's exact Ruff repair through ordinary merge ancestry; and
• adds docs/product-technical-gap-baseline.md with PRD/TRD/Context Map/UML/ERD/gap/action/status and rollback boundaries.

No product database, persistence, API, event, or user data contract changes.

Exact-tree local verification

Executed with Node 22.22.2 and npm 10.9.9:

• complete lock generation and frozen npm ci --ignore-scripts --no-audit --no-fund;
• npm runtime check: npm 10.9.9, bundled tar 7.5.22;
• lint, docs, security-pattern, supply-chain, GitHub-bootstrap, Ruff, format, Bandit, TypeScript and mypy gates;
• full tests: desktop 216, shared-types 20, Python 686 passed / 24 skipped, with 100% statement/branch/function/line coverage;
• production workspace build and Storybook build; and
• git diff --check.

The Vite/Storybook build retains the existing >500 kB chunk warnings; this dependency-owner slice does not misstate those warnings as resolved performance evidence.

Merge gate

Keep Draft and unmerged until this unchanged exact head has terminal-success for every applicable repository and central CI/security/SAST/SBOM/supply-chain/build/release gate, zero valid unresolved findings, a qualifying independent current-head approval, and ordinary branch-protection acceptance. Never reuse predecessor evidence or weaken a gate.

[opencode-agent]

Already queued @opencode-agent on this exact request for PR #896 at head c07e51639dbb7b44f57ff0aabc26ad793e691add. Central exact-name Actions artifacts are the durable dispatch ledger; existing review workflows remain authoritative for the final verdict and failure evidence.

[opencode-agent]

Already queued @opencode-agent on this exact request for PR #896 at head c07e51639dbb7b44f57ff0aabc26ad793e691add. Central exact-name Actions artifacts are the durable dispatch ledger; existing review workflows remain authoritative for the final verdict and failure evidence.

[opencode-agent]

Already queued @opencode-agent on this exact request for PR #896 at head c07e51639dbb7b44f57ff0aabc26ad793e691add. Central exact-name Actions artifacts are the durable dispatch ledger; existing review workflows remain authoritative for the final verdict and failure evidence.

[seonghobae]

@opencode-agent Continue the canonical fix/node-22-22-2-jsdom-30-779 lane only, now bound to exact head 8e6a73879dac8aebd70f77aa80d55fc9c670a8f5 and protected develop@749511c3ad4000090048718f685c6bee6b3d2c25. Do not create a competing branch/PR and do not modify #783 ownership.

Fresh exact-head failure evidence: node-minimum-compatibility run 33280770990, job 99175446820, checked out merge commit bfb9309b1062e2a2ed62ccd875e167702412faf1 (head 8e6a738… + base 749511c…). Node setup was exact 22.22.2; corepack enable npm selected exact npm 10.9.9; check:npm-runtime verified bundled tar 7.5.22. The first causal boundary is then frozen npm ci, which fails EUSAGE because the protected lock does not contain the manifest-required jsdom 30 graph: jsdom@30.0.1, @asamuzakjp/css-color@6.0.7, @asamuzakjp/dom-selector@8.3.2, undici@8.10.0, whatwg-url@17.1.0.

The older node-minimum-package-lock-candidate was generated with npm 10.9.8 and is no longer acceptable provenance after the protected npm 10.9.9 security boundary. Generate the complete root package-lock.json from the current exact branch using Node 22.22.2 + repository-authoritative npm 10.9.9 and the documented lock-generation command (npm install --package-lock-only --ignore-scripts --no-audit --no-fund). Do not hand-edit or partially transplant lock records. Preserve #783's dependency-security state, registry SRI, root @esbuild/* peer: true sentinel metadata, and current PDF.js/Undici constraints. Commit only the generator-produced lock change unless a regression proves another owning-file repair is required.

Then prove focused GREEN with the current Node/runtime contract tests and frozen npm ci, followed by the exact-minimum lane and full exact-head CI/security/SBOM/release gates. Keep Draft; predecessor, merge-commit-only, skipped, queued, or model-only evidence is non-passing.

[seonghobae]

Fresh downstream evidence for this canonical npm/lock provenance boundary: Dependabot PR #1134 (Vitest 4.1.10→4.1.11), exact head 770db9b73e53e191dc7d3e89e1dcce9fe1e512ce, passed all 236 JS/TS tests and kept frontend coverage at 100%, but ci / build-and-test failed two repository lock-contract regressions because the generated root package-lock.json removed peer: true from root node_modules/@esbuild/*: test_lock_records_match_exact_registry_artifacts_and_preserve_peer_metadata and test_root_lock_preserves_esbuild_peer_metadata. A current-head REQUEST_CHANGES review on #1134 now points here. This is concrete evidence that dependency bumps must not treat arbitrary regenerated lock output as acceptable provenance. Preserve this PR's existing rule: regenerate the complete lock with repository-canonical npm 10.9.9, review the full generated diff, then require frozen npm ci plus the peer/provenance regressions and full quickcheck on the same exact head. Do not hand-edit the lock or weaken the tests.

[seonghobae]

Fresh downstream evidence reinforces this Draft as the canonical repair owner rather than a documentation-only lane. Three current Dependabot heads generated unrelated npm development updates and reproduced the same lock-provenance failure:

• build(deps-dev): bump @types/node from 26.2.0 to 26.4.0 #1133 3f16708767ad8ac11e675e170c622d24d09332d8 (@types/node 26.4.0): CI run 33589595580 / job 100266058867 — exactly two failures, both caused by root node_modules/@esbuild/* records losing peer: true (aix-ppc64 is the first reported record).
• build(deps-dev): bump eslint from 10.8.1 to 10.9.1 #1136 32bbb8ba067ace3365de8ce04a79949457aa7e33 (ESLint 10.9.1): CI run 33589624972 / job 100268985342 — the same two failures and same first missing record.
• build(deps-dev): bump vitest from 4.1.10 to 4.1.11 #1134 770db9b73e53e191dc7d3e89e1dcce9fe1e512ce (Vitest 4.1.11): CI run 33589608944 / job 100267513514 — Vitest 4.1.11 itself executes successfully (216 desktop tests + 20 shared-types tests, 100% measured frontend coverage), then the same two lock-provenance regressions fail on @esbuild/* peer metadata.

All three runs independently verify the repository-pinned npm 10.9.9 runtime before frozen consumption, so the failure is not a reason to relax npm ci, test_high_security_dependency_baseline.py, or test_npm_toolchain_contract.py. I placed exact-head REQUEST_CHANGES reviews on all three PRs and kept their unique package-version deltas open.

For the next complete npm 10.9.9 regeneration in this canonical owner, include the still-valid non-major development intents from those Dependabot PRs where compatible instead of creating a second hand-maintained lock path. Acceptance remains one complete generated root lock preserving @esbuild/* peer metadata, SRI/security baselines, jsdom/Node-floor intent, and exact-head GREEN. Existing downstream PRs can only be closed after their unique semantic deltas are demonstrably present in this or another verified successor.

[seonghobae]

Exact-head RED evidence after the non-force protected-base restack:

• head: fc3d1ec01a1124a4e11375259d720a976a53ec5e
• protected base: develop@889d782e88b4df28dcbb4ae3cfd6d99ef85d9844
• develop...HEAD: behind_by=0; net semantic delta remains the seven Node/jsdom/npm-policy files.
• node-minimum-compatibility run 33828339546, job 100885708608 reached exact Node 22.22.2, activated project npm 10.9.9, and verified its bundled tar 7.5.22 successfully.
• The first frozen dependency-consumption step then failed exactly where expected: npm ci rejected manifest/lock disagreement (EUSAGE) because the committed lock is missing jsdom@30.0.1, @asamuzakjp/css-color@6.0.7, @asamuzakjp/dom-selector@8.3.2, undici@8.10.1, and whatwg-url@17.1.0.

This is the intended realistic RED, not an infrastructure failure and not a reason to weaken frozen consumption. The causal fix remains one complete root package-lock.json regeneration with the approved npm 10.9.9 generator on this current ancestry, followed by review of the complete generated diff, preservation of SRI and @esbuild/* peer:true generator sentinels/security contracts, and exact-head GREEN. Do not hand-edit individual lock records or rerun this failed job as if retry could repair the stale artifact.