tsconfig.vitest.json is deleted; its job (a paths map applying to all
test files) is inherent in tsconfig.base.json having no include —
vite-tsconfig-paths treats that as match-all. All four vitest configs
now pin the same facade: the unit config gains a shared pathsPlugin()
helper, the web lane drops its handwritten webserver alias (apps/web
tests are covered by match-all), and the snapshot lane leaves the root
solution (which no longer carries paths) and stops resolving client
imports through package exports. tsconfig.base.json documents the
facade role and bans include/files; the CI eslint cache key hashes the
four graph tsconfigs; the eslint tests-block comment states resolution
via the solution to tsconfig.host.json.
Per missions/tsconfig-single-graph-migration.md §3.
Skipped matrix jobs never expand matrix display values, so let GitHub use stable job identifiers. Bind optimized jobs to pull requests and the three serial references to master pushes.
The ::warning:: wrapper kept the lane job green on failure — honest
about not gating merges, but a Windows regression was visible only as
an annotation buried in the run summary. GitHub has no yellow job
state, so the choice is green+annotation (too hidden) or a red X on a
non-required job (visible, still non-blocking). Take the red X:
job-level continue-on-error, plain 'Run gates' step, one less wrapper.
The step stays on the runner's native pwsh — never shell: bash — per
the MSYS-parent leak recorded in the windows-support RFC.
Also remove the temporary Windows-only failing demo test that
exercised the wrapper's annotation path (REVERT ME commit a496b9ae).
The lane-split merge moved the Run gates step to `shell: bash`, which
broke it twice over. First, GHA's bash shell runs with -e, so a failing
gate aborted the step before the ::warning::/exit 0 lines — the lane
went red X instead of the intended yellow warning. Second, and worse,
Git Bash as the PARENT of the gate run leaks MSYS environment into the
suite itself, producing 8 real test failures the pwsh-launched runs
(and the DSec VM runs) never saw:
- bash exports PWD; the MSYS runtime rewrites it to Windows form for
native children, dsh-bash-local's adaptEnv passes it through, and the
executor's MSYS bash adopts it — `pwd` prints `D:/a/...` where the
tests (and the executor's MSYS dialect) expect `/d/a/...` (7 tests).
- cygwin enables SeBackupPrivilege on the runner's admin token; children
inherit the enabled state, and libuv's FILE_FLAG_BACKUP_SEMANTICS read
opens then pierce the dwShareMode=0 lock the jsonl EBUSY test holds —
loadLive resolves instead of rejecting (1 test).
Evidence: run 28918325498 (pwsh step, pre-merge) failed only the two
hooks dispose tests since fixed by f8fd8c00; run 28921741006 (bash
step) fixed those and failed exactly the 8 above, with zero relevant
source diff between them.
Fix: run the wrapper in pwsh — a native command's failure doesn't abort
pwsh, so $LASTEXITCODE capture + ::warning:: + exit 0 works without an
errexit dance, and the gates start from a native Windows shell as they
do everywhere else Windows CI has been validated.
Docs: the windows-support RFC drops the stale continue-on-error wording
(replaced by the warning wrapper) and records the launch-environment
limitation — native shell required today; making an MSYS parent a
supported launch environment (PWD scrub in adaptEnv, privilege-explicit
tests) is a future improvement direction.
The Windows CI was a single job running the full ci-windows inventory
(check:ci:windows), while Linux splits into 5 lanes (static/lint/coverage/
snapshot/artifacts) per the parallel-gates RFC. The single-job shape was a
transitional artifact from when Windows CI was added as a non-required
observation lane; its rationale ('keep gate parallelism modest so coverage
is not starved') conflated run-gates intra-job concurrency
(DSH_GATE_CONCURRENCY) with GitHub job fan-out — orthogonal concerns.
Split Windows into 4 lanes mirroring Linux (snapshot absent: its goldens
are Linux-recorded and self-skip on Windows). Each lane is a separate
GitHub job so a Windows regression is attributable to one lane, not
buried in one job's log. Concurrency is NOT throttled versus Linux: the
lane is non-blocking (continue-on-error), and the observational stance
is to actively expose Windows-arm issues rather than hide them behind
reduced parallelism.
- scripts/run-gates.ts: add ci-windows:static/lint/coverage/artifacts
modes; ci-windows (full inventory) is retained as the local one-process
entry, symmetric with Linux's ci-primary.
- .github/workflows/ci.yml: windows job becomes a matrix over the 4 lanes.
- package.json: check:ci:windows:{static,lint,coverage,artifacts} scripts.
- AGENTS.md + windows-support RFC: document the per-lane, non-blocking,
unthrottled stance.
Verified: scripts/caohuanqi-private/run-ci.py --windows (full
check:ci:windows) — all gates green except the known hooks-claude
bridge.spec waitFor timeout (pre-existing Windows subprocess-timing
flake, unrelated).
Add a Windows CI job alongside the existing Linux checks. Runs the full
test suite (without the Linux-only coverage gate) plus typecheck, lint,
doc-sync, build, hygiene, and demo smoke under PowerShell. Developer
Mode is enabled via registry for symlink support (fs-local tests,
verify-node-next-types).
Per the windows-support RFC transition plan: step (2) — non-required
Windows CI job to observe stability.
Runs `pnpm install` + `pnpm run build` (tsc -b + tsdown) on windows-2025,
and is listed in all-checks-passed `needs` so a Windows build regression
cannot land silently. Windows path/shell support is still partial, so this
lane covers the build surface only; tests and gates are not run here yet.
