* feat(#4422): block merging into next/main while the base branch's Tests run is red
Adds a next-health job to test.yml that checks the base branch's own last
push-triggered Tests run via the GitHub API and fails the existing "Required
tests" required check when it's red, with a maintainer-applied "fix-next"
label as the explicit escape hatch for the fix-forward PR itself. No
branch-protection config change needed — it rides the already-required
check. The job is deliberately not gated behind preflight, same reasoning
as the changes job: a compute-free API read has nothing to save by waiting.
Documents the fix-next label in CONTRIBUTING.md and adds a property test
locking the CLEAN/RED/INDETERMINATE classification's iff-relationship.
This closes the second half of the 2026-09-06 RCA: three unrelated PRs
merged on top of an already-broken next before anyone noticed it was red.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix: close two zero-margin CI timing gaps found while verifying #4422
Discovered while watching this branch's own CI, root-caused via /diagnose
rather than dismissed as Windows flakiness:
1. tests/gsd-check-update-worker-atomic-cache.test.cjs's outer timeout
(15000ms) exactly matched the inner npm-view timeout the worker wraps
(NPM_VIEW_TIMEOUT_MS, gsd-core/bin/check-latest-version.cjs). A slow
registry response raced two SIGKILLs at the same instant, killing the
worker before it could catch its own timeout and degrade gracefully.
Windows's shell-wrapped npm subprocess made the race lose more often
there, but the zero margin was platform-agnostic. Fixed by giving the
test real headroom (+10s) beyond the named constant it wraps, plus an
invariant test so the two values can't silently collide again.
2. scripts/run-tests.cjs's per-chunk weight budget (MAX_FILES_PER_CHUNK)
let a Windows full-matrix chunk that was well under budget by the
Linux/macOS-calibrated weight table (~32/60 units) still exceed the
600s wall-clock backstop — codex-config.test.cjs's genuinely-measured
weight (17.87) doesn't transfer 1:1 to Windows's slower install/
subprocess overhead. Windows now gets its own lower cap (40 vs 60).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: sim <sim@local>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
1c0acb2359