sha256sum-or-shasum selection happens in preflight (macOS ships shasum,
not GNU coreutils) with a clear missing-tool hint; provisioning now waits
for every child and reports each named status before exiting, so a fast
failure can neither hand the EXIT trap a scratch tree that a still-running
install is writing into nor bury the root cause behind a downstream
symptom.
AGENTS.md and the Wine Agent Note pair state the run policy: CI owns the
everyday win32 signal; run check:windows-wine only while investigating a
known Windows-related failure, and pre-push selection never includes it.
scripts/wine-windows-gates.sh owns the whole lane — workspace snapshot,
concurrent Node/wineboot/install provisioning, entrypoint resolution, the
vue link, smoke, and the two concurrent blocking gates — so the ci.yml
windows job shrinks to runner provisioning plus one script call, and
pnpm run check:windows-wine runs the identical script locally. The local
path never mutates the working tree, persists the Wine prefix and the
checksum-verified Windows Node zip under .cache/wine-windows/, and falls
back to the cached zip offline. AGENTS.md ceiling 1680 -> 1695 for the
one-line command entry.
- The clone exclusion is now '.runner*' (catches .runner_migrated /
.credentials_migrated, which GitHub writes on migrated runners and
which equally trip the already-configured refusal — hit live during
the 2026-07-27 org-group migration).
- The problem statement now states the verdict runs on ubuntu-latest,
scopes the switch to enterprise Linux-pool outages, and names the
residual dependency: node-compat/python-sdk/windows stay standard-
hosted, so a broader hosted-capacity failure still blocks the
verdict, with Windows the only leg lacking any in-house substitute.
Static gate green locally: 32 passed, 0 failed.
Two sessions resolved the same all-checks-passed conflict differently. The
remote's version is the one kept: the selector with '|| ubuntu-latest'
covers a standard-hosted outage too, which a bare ubuntu-latest pin does
not, and its runbook wording is internally consistent at four failover
jobs. Reverted this side's three-job doc downgrade.
One semantic conflict on the `all-checks-passed` verdict job. Master moved
it to `ubuntu-latest`; this branch had routed it through the failover
selector so a hosted-pool outage could not leave the required verdict
queued. Master's resolution satisfies that requirement more directly:
standard hosted capacity is independent of both custom pools, so the
verdict is reachable whichever pool is degraded, and the selector is no
longer needed. Kept `ubuntu-latest` and folded the failover reasoning
into its comment.
The failover runbook accordingly documents three failover jobs (the three
required Linux workers), not four, and states why the verdict stays on
standard hosted capacity in both states.
