---
name: bystander-test-reads-process-global
description: "A test that never touches process-global state can still be its victim — comparing two independent live reads is unsound, and writer-side locking cannot fix it."
metadata: 
  node_type: memory
  type: project
  originSessionId: b3b26b54-35ff-40cf-b335-7b5945a070cd
  modified: 2026-07-29T23:18:28.163Z
---

A test can be the **victim** of process-global state it never touches. spt-core `spt-daemon::servicehost::tests::the_spawn_environment_carries_the_cli_capability` (servicehost.rs:2370) sets no env, makes no TempDir, takes no lock — it just compares **two independent reads** of the process home: `service_env()` pins it at call time, then the assertion re-reads `spt_store::perch::spt_home()` live. A concurrent test re-pointed `SPT_HOME` between them. Red on main @af65ac0, run 30498436981: left `/home/reavus/.spt-core` (real home), right `/tmp/.tmpwZP3IT` (another test's TempDir).

**Why:** `perch.rs` `ENV_LOCK` serializes *writers against each other*. A bystander that never takes the lock gains nothing from it, so **no amount of writer-side discipline closes this class** — including converting every writer to a lock-guarded `with_home`. Product code was clean: pinning the home the daemon resolved is the documented behavior the test's own comment defends. The unsound step was the test's *second read*.

**How to apply:**
- Suspect this whenever a red's two sides are *both plausibly correct values* of one global.
- Fix by removing the global read, not by adding a lock: give production an explicit-home seam (`service_env_at(home, …)`) so the test asserts against a home it supplied. Fallback: capture the global once under the same lock.
- Latency between introduction and first red is normal here — the test dated to `2e20e0a`, long before the batch that exposed it.
- Measure the load *direction* rather than asserting it: `with_home` sites in `crates/spt-daemon/src` went **167 → 188** (+21, +13%) across `ffc7e9e..af65ac0`, while `servicehost.rs` itself had an **empty diff**. That makes it a pre-existing latent defect whose *exposure* the batch increased — seam-adjacent, not seam-caused. Same-sha contradiction corroborates: golden's full-suite Linux job and the local battery both passed this test at the sha that redded.
- Third instance of one class in spt-core (perch.rs env tests, `daemon_inhibit`, this bystander) — route to the lane owner with the fix shape; never flake-register a mechanism you can name.

⭐⭐ **The repair is judged STRUCTURALLY, not by a run** (doyle-ratified 2026-07-29, todlando-found): this red is **Linux-only** — the test PASSES on Windows at the red sha UNREPAIRED — and hertz was fixing it on Windows hfenduleam, a box that cannot observe it. A Windows green after the fix is the same green the *broken* code already gives. So the binding acceptance criterion is source-level (the assertion reads no live `spt_home()` at all; home supplied by the test), with a Linux run as corroboration only — never a substitute, since an ordering-dependent pass only means you didn't lose the race that time. **Fourth surface of the probe-competence class.**

See [[verdict-from-probe-competence]], [[window-assertion-load-direction]], [[load-claim-needs-measured-axes]], [[milestone-a-golden-landed]], [[seedmap-test-collides-live-daemon]].