Windows: the test suite passes, but the binary build has no Node 18.20.8 target #35

First result from the Windows job, which had never run before #29/#31 turned it on. The result is better than the red tick suggests, and the failure is specific.

Post-merge run 30840176411 on main:

What actually failed

Not the tests. The Windows Jest run passes — the log shows the suites executing and passing before the failure:

PASS @stoplight/spectral-rulesets packages/rulesets/src/arazzo/functions/__tests__/arazzoStepFailureActionsValidation.test.ts
PASS @stoplight/spectral-core packages/core/src/__tests__/errorMessages.test.ts

It dies in build-binary, which the harness calls before running harness tests:

> Error! No available node version satisfies 'v18.20.8'
##[error]Process completed with exit code 1

That is @yao-pkg/pkg at 5.11.0 (packages/cli/package.json), reporting it has no prebuilt Node 18.20.8 base binary for the node18-windows target. pkg ships a fixed set of prebuilt Node binaries per version, and 18.20.8 is not among the ones this version can satisfy for Windows.

So the correct reading is: spectral passes its tests on Windows. What cannot be produced on Windows is the packaged binary at this pinned Node patch version. That is a packaging-toolchain gap, not a code defect, and it should be described that way anywhere it gets summarised — including #3, which now needs updating.

Note this was previously invisible in both directions: the job never ran here, and upstream it only ever ran on direct develop pushes, with its harness step gated on a matrix.node-version that did not exist. Nobody was going to notice.

Options

1. Move the Windows harness to a Node version pkg has a Windows binary for. Smallest change, and the harness stops being pinned to a patch release nothing can build.
2. Upgrade @yao-pkg/pkg. 5.11.0 is pinned exactly. A newer release may cover 18.20.8 or later. Upstream has a yao-pkg-update branch cached in the refs discussed in Preserve the upstream branches that now exist only in one local clone, and map them to open PRs #7, which suggests they hit something adjacent.
3. Decouple the harness from the binary build on Windows — run the harness against the built CLI rather than a packaged binary, and treat binary production as a release-time concern rather than a per-commit one.
4. Accept it and document it — state that Windows binaries are unsupported for now, rather than leaving a red job.

Option 3 is the most honest structurally: a per-commit test job should not be gated on producing a distributable artifact. But it is also the largest change, and option 1 gets Windows green soonest.

Acceptance criteria

• Decision recorded on which option, with reasoning
• test-windows green, or explicitly documented as unsupported with the job adjusted so it does not report a misleading failure
• Verify the fork builds and tests green #3 updated to state Windows accurately: tests pass, binary packaging does not
• Whether Windows binaries are a supported release artifact settled — this reaches Dockerfile builds on node:16-alpine — end of life since September 2023 #11 and the release path in Supply chain: audit what was inherited, harden the release path #15

Related: #3, #29, #11, #15, #7.