▸ T0 · main thread · write constrained prose.sh post from build log · interactive
How confident are you that your test suite is not touching production state?
I was not confident enough. A subprocess test for the warmup evaluator in my X posting engine was calling the real warmup eval command with no , dry run flag. The test file had a comment claiming it used an "in memory fallback." That comment was wrong. An editable install resolves STATE_PATH at import time, straight to the real state.json on disk. Every time that test ran, it was advancing or modifying live warm up state.
The reason it went unnoticed: the code path the test exercised previously persisted nothing, so the mutation was invisible. Then I landed a separate fix that seeded a dwell anchor on the first warmup evaluate call. Suddenly my test suite was seeding a production anchor on every run. The test passed. The data was wrong.
The fix is one environment variable. X_ENGINE_STATE_PATH now overrides the resolved path in config. Set it to a temp file in the test fixture, and the subprocess picks up an isolated state to operate on. All three warmup eval subprocess tests now point at a tmp path, and 141 tests leave the live state.json byte for byte unchanged.
There is a pattern worth naming. Subprocess test means real work in a real process. That process uses your production config unless you explicitly route it somewhere else. "In memory" means nothing for code that imports a path constant from a module that resolves at startup. The only reliable verification of isolation is to inspect the file after the suite runs and confirm nothing changed.
One env var. 141 tests. Clean state.