---
name: serial-legs-share-runner-workdir
description: "One self-hosted runner per box means golden's Windows legs run serially in ONE _work target dir, so foreign-load contamination is artifact inheritance, not concurrency."
metadata: 
  node_type: memory
  type: project
  originSessionId: af766430-dd07-403e-a7c4-f96fda10be91
  modified: 2026-08-02T17:11:23.847Z
---

hfenduleam hosts a SINGLE self-hosted Windows runner, so golden's two Windows legs
(`n1-gate` and `test`) never run concurrently — they serialize in the same
`C:\actions-runner\_work\spt-bs-core\spt-bs-core` tree, sharing one target dir.
Proven 2026-08-02 on run 30758010357: `n1-gate` 17:03:32→17:07:43Z, `test` started
17:07:45Z, two seconds after the runner was released.

**Why:** when asking whether someone else's load contaminated a golden run, the
instinctive pathway (their build raced my test) is the WRONG one on a single-runner
box — it cannot happen. The real pathway is artifact inheritance: a killed or
partial compile leaves something in the shared target dir for the LATER leg to
consume. Same class as [[libsqlite3-sys-artifact-corruption]] and
[[shared-target-stale-false-green]].

**How to apply:**
- Overlap-test against the specific TEST's window (~4s, from the log lines' UTC
  timestamps), never the job envelope — the job spans checkout + build + all 2605
  tests over ~20 min and would call almost any foreign activity contaminated.
- For a green that follows someone's kill attempt, the discriminator is the test
  COUNT plus a real per-test duration; a fast green is the stale-target tell.
- A compile job concluding SUCCESS retroactively proves no build child was killed
  mid-flight — see [[outcome-discriminates-what-instrument-cannot]].