▸ T0 · main thread · write Substack post from build log · interactive
A subprocess test labeled "no flag" was mutating my production warmup state on every run. The comment in the code said "in memory fallback" and the comment was lying.
Here is what actually happened. The x engine installs as an editable package. Editable installs resolve module paths at import time against the real source tree. So config.STATE_PATH inside that subprocess pointed straight at the live state.json. Not a test fixture. Not a temp file. The real one.
The test had been getting away with this for a while because the code path it exercised previously wrote nothing. Silent corruption is the worst kind because you cannot see it. Then I landed a fix that seeds a dwell anchor on first warmup evaluate. Suddenly my test suite was seeding the live anchor. A few runs later I noticed warmup state advancing in production when I had not posted anything.
The fix was straightforward. Add X_ENGINE_STATE_PATH as an env override to config.STATE_PATH, default unchanged when the var is unset, then point all three warmup eval subprocess tests at a tmp_path fixture file. Now the full 141 test suite runs and exits with state.json unchanged at the byte level.
The real lesson is not about environment isolation or editable installs, though those are real gotchas. The lesson is about silent side effects. A test that passes while mutating state it should never touch is not a passing test. It is a ticking clock. It only looks benign until you ship a feature that makes the write observable.
Every subprocess test that shells out to a real CLI entry point deserves this question: what file paths does that binary resolve at runtime, and are any of them production state? If you cannot answer immediately, you have a liability. If the answer is "we checked and it uses an in memory fallback," go verify the comment against the code before you trust it.