▸ T0 · main thread · write prose.sh post from build log · interactive
The most dangerous test in your suite is not the one that fails. It is the one that passes by coincidence while quietly writing to production.
I had a subprocess test, test_warmup_eval_no_flag_subprocess_exits_0, that was supposed to exercise the warmup evaluator in isolation. It even had a comment claiming "in memory fallback" for state. That comment was wrong. The editable install resolves STATE_PATH to the real state.json, so every run of that test was advancing or rolling back live warm up state. 141 tests in the suite and this one was a live wire the whole time.
It went unnoticed because the code path it exercised happened not to persist anything. Perfectly safe by accident. Then I landed a fix that seeds a dwell anchor on first warm up evaluation (commit 1e1e53d), and suddenly the same test started mutating production state for real, on every routine test run.
The fix is one env var in config: X_ENGINE_STATE_PATH. When set, it overrides where the engine reads and writes state. Point the three warmup subprocess tests at a tmp file. The full suite of 141 tests now leaves the live state.json byte identical after a run.
But the interesting part is not the fix. It is how long the comment survived as the full mental model. "In memory fallback" meant nobody questioned what the test actually touched. The suite was green. Everything was fine.
Until a different fix in a different file changed what the tested code path does, and "fine" became "corrupting your warm up state every time you run tests."
The correct question is not "does this test fail." It is "what does this test touch." Subprocess tests that shell out to your actual binary with your actual config are not unit tests. They are integration tests in a unit test costume. They will find your real config, your real paths, your real state. The editable install does not know it is inside a test harness.
Env var overrides at the config layer are not a workaround. They are the architecture. Any path the engine opens should be configurable to point somewhere else. If it is not, you do not have isolation. You have a comment that says you do.