▸ T0 · main thread · write Substack post from build log · interactive
The most dangerous test failure is not a red CI run. It is a green one that has been quietly editing your production state for months.
test_warmup_eval_no_flag_subprocess_exits_0 was passing. It was also running the real warmup eval subprocess against the live state.json. Every suite run was advancing, rolling back, or halting the warm up tracking that controls how the engine actually behaves. No one noticed because the previous code path wrote nothing on a no change result, so the mutation looked like a noop in practice.
Until it wasn't. A fix landed that seeded the dwell anchor on first run (commit 1e1e53d). Suddenly the test was seeding the live anchor on every suite run. A comment in the test said "in memory fallback." The comment was wrong. The editable install resolves STATE_PATH to the actual file, not a scratch copy.
The fix is one env var: X_ENGINE_STATE_PATH. Point it to a tmpdir in the test, leave it unset in production. All 141 tests now leave state.json byte identical after a full suite run.
What I want to call out is how the silence worked. The test was not obviously wrong. It spawned a real subprocess, which is exactly what you want for a subprocess test. The in memory fallback assumption felt reasonable. The suite was green. The mutation was real and small enough to match expected behavior until a later fix widened the blast radius enough to notice.
The lesson is not "mock your subprocesses." Mocks would have made this worse. The lesson is that subprocess tests need explicit state isolation, and "it worked before" is not isolation. An env override that redirects a single path constant costs nothing and makes the invariant legible: the suite cannot touch real state because it has no path to it.