fix(ci): pin Windows release runner to windows-2022

[tnunamak]

Summary

Release builds for Windows stopped producing an installer. GitHub's windows-latest runner image — the label that always points at whatever Windows image GitHub currently considers current — moved to a Visual Studio 2026 install under a bare \18\ path. node-gyp, the tool npm uses to compile native C++ addons, could not parse that path and failed to build better-sqlite3, the SQLite database library this app links natively, with unknown version "undefined" found at ... \18\Enterprise. No Windows artifact was produced at all.

node-gyp 12.1.0 and later understand the new path, so the obvious fix is to make npm use a newer one. That does not work, and this was confirmed on a live run rather than reasoned about: npm_config_node_gyp, the environment variable that normally points npm at a specific node-gyp, is ignored for the automatic native rebuilds npm ci performs, because npm's run-script implementation hardcodes its own bundled copy (npm/cli#2839).

The fix is instead to pin the Windows release job to windows-2022, an image whose Visual Studio install predates the naming change. One line in .github/workflows/release.yml, one matrix entry; the macOS and Linux entries are untouched. A dated TODO records the condition for removing the pin: once actions/setup-node's Node 22 LTS bundles npm 11.6.3 or later, which brings node-gyp 12.1.0, the stock image will work again.

Pinning the runner is a workaround for a toolchain gap, so it is worth being explicit that it cannot hide a genuine build failure. The Windows job still runs scripts/verify-bundled-personal-server.mjs, which checks the produced bundle, and the artifact upload still sets if-no-files-found: error. A broken or missing installer fails the job exactly as before; the pin changes which compiler toolchain is selected, not whether the output is checked.

The failures this uncovered

Getting past node-gyp let the Windows build run further than it ever had, which exposed three latent Windows-only bugs. Each had to be fixed for the build to complete, so they ship together rather than as follow-ups.

@pdpp/polyfill-connectors — a package this repository vendors as a tarball rather than pulling from a registry, which supplies the connectors that fetch a user's data from third-party services — ran spawnSync("patchright", ...) in its postinstall hook without shell: true. Patchright is a drop-in Playwright replacement that drives a real browser while avoiding the fingerprints sites use to detect automation, and the hook installs its bundled Chromium. On Windows, a PATH lookup without a shell does not find the .cmd shim npm writes for package binaries, so this failed with ENOENT. Fixed upstream in PDP-Connect/data-connectors#60, then re-vendored here following reference-implementation/vendor/README.md, with SHA256SUMS and the package-lock.json integrity hash updated to match.

Two more vendored packages under reference-implementation/vendor/ hit the same missing-shim problem in their own build scripts, which call execFile("npx", ...) directly: read-core and mcp-server. Both now pass shell: platform === "win32". A third package in that directory, cli, needs no change because its build is written as an npm script string, and npm always runs those through a shell anyway.

In the Rust code, src-tauri/src/commands/ref_server.rs imported kill_process_group without a #[cfg(unix)] gate. That function is Unix-only at its definition and every call site was already gated, so only the import was wrong — an E0432 unresolved-import error on Windows and nowhere else.

Round 2: review findings addressed

An independent reviewer found the substance sound and raised four items, numbered F1 to F4 in their report. All four are addressed below, most significant first.

F1 — the title described an approach this PR abandoned. The title still read "pin modern node-gyp on Windows release builds" while the body explained that route was confirmed not to work. Because a squash merge takes its subject from the PR title, that misleading line would land on main as the very commit someone greps when deciding whether to unpin. Retitled to "fix(ci): pin Windows release runner to windows-2022".

F3 — a safety test had gone vacuous in CI. cdp-method-allowlist.test.ts guards the code that streams a live browser session to the user interface. It asserts that this code sends no Chrome DevTools Protocol method — the wire protocol used to control Chromium — outside an explicit allowlist, which protects an anti-detection property: the browser is driven through Patchright specifically so that sites cannot tell it is automated, and a stray Chrome DevTools Protocol call from a forbidden domain is exactly the kind of signal that gives that away. That check is vacuously true if no methods are found at all, so three assertions that specific methods are present exist to prove the extraction still finds something. A commit earlier in this same PR put all three behind a check for @opendatalabs/remote-surface, an optional dependency requiring Node 24 that is never installed on the Node 22.23.1 CI job — so in CI they never ran and the test passed regardless of what the streaming code contained. Two of the three were wrong to gate: Page.startScreencast and Input.dispatchMouseEvent are sent by this repository's own streaming code, in cdp-companion.ts, so they hold with or without the optional package. Only Page.enable lives solely in the optional package. The first two are now asserted unconditionally.

F4 — one test file was running with no type checking at all. run-interaction-stream-remote-surface-session.test.ts needs TypeScript's DOM library for its jsdom-based fake browser, but TypeScript applies that setting per compilation program rather than per file, so including it would have replaced every other file's ambient Headers and ReadableStream types with the browser versions instead of the Node ones. It was therefore excluded from the type-check program entirely — while still executing under the test runner, so a type error in it could fail nothing. A second program, tsconfig.dom.json, now covers exactly that one file with DOM enabled, and the typecheck script runs both. Type-checking the file for the first time surfaced a stale @ts-expect-error on its jsdom import, which is now an error in its own right because the types it claims are missing do resolve; removed.

F2 — scope. The reviewer noted this PR carries several concerns against the repository's "one change per PR" rule and explicitly declined to block on it, since the commits are individually clean and each one unblocked the next. Left as-is deliberately: splitting a proven, green Windows fix at this point costs more than it returns.

Verification

The strongest evidence is a direct contrast in CI on this repository: the windows-2022 build job is green on this head, while the same job on windows-latest is red on a sibling PR against the same base. The macOS and Linux legs stayed green.

Both test repairs were checked by mutation rather than just re-run, since a passing test is not yet evidence it would catch anything:

• Renaming Page.startScreencast and Input.dispatchMouseEvent to non-allowlisted names in the streaming sources, with the optional package absent as in CI, passed before the F3 fix and now fails on the Page.startScreencast assertion.
• A deliberate const x: number = "..." appended to the formerly-excluded test file is invisible to the original type-check program and fails the new one with TS2322. That file's runtime behaviour is unchanged — it still runs and passes.

Both mutations were reverted and the tree verified clean.

Both repairs are also confirmed live in CI on this head, which matters because each one was specifically about CI behaviour. The type-check job's log shows it now runs both programs (tsc --noEmit -p tsconfig.json && tsc --noEmit -p tsconfig.dom.json) and passes, so the formerly-excluded file is genuinely covered rather than merely coverable. The allowlist test reports test:pass on the Node 22 job — the job where the optional package is absent and where its presence assertions previously did not execute at all.

reference-implementation gate, test reference implementation, and typecheck reference implementation are three CI jobs that lint, test, and type-check the reference implementation. The first two fail on main itself, before this branch's changes, because of an unrelated in-progress migration that left the reference implementation with type errors and failing tests — tracked as issue #55, "unblock the Move-B CI seam". They are not affected by this PR. typecheck reference implementation is the exception worth noting: it fails on main and passes here, because the final commit also cleared 34 pre-existing type errors. Those were resolved by fixing type annotations and by excluding the one DOM-dependent test file described in F4 below, not by loosening any compiler option; the tsconfig's strictness settings are untouched.

Fixes #47, which reported that the Windows native build of better-sqlite3 regressed between 2026-08-21 and 2026-09-02 because node-gyp could not parse the windows-latest runner's Visual Studio 18 version string.

Assisted-by: AI

[tnunamak]

Superseded by #61 (merged): same windows-2022 pin plus the macOS bundle fix; the vendored shell:true postinstall arrived via #55's re-vendor and the npx shell + cfg(unix) fixes landed in #61.