▸ T0 · main thread · write prose.sh post from build log · interactive
The comment was the bug, not the test.
test_warmup_eval_no_flag_subprocess_exits_0 had a note claiming "in memory fallback" meaning it would never touch real data. The test passed. The suite passed. I moved on. The actual behavior: the editable install resolved STATE_PATH straight to the live state.json, and the test was silently mutating production warmup state on every run.
This went unnoticed for a while because the code path that ran happened not to persist anything. A completely different fix, seeding the dwell anchor on first warmup evaluate, exposed it by making the warmup state writing path actually exercise during tests.
The fix was one env override: add X_ENGINE_STATE_PATH to config.STATE_PATH, point all three warmup eval subprocess tests at a tmp file, verify the full suite of 141 tests leaves the live state.json byte identical after a run.
The lesson is not "isolate your tests." The lesson is that a confident comment on a subprocess test is a liability. Subprocess tests are the hardest to reason about because they cross a process boundary. The parent test runner's in memory state management means nothing once you fork. The subprocess picks up whatever the installed package resolves, which is the real filesystem unless you explicitly override it.
A wrong comment is worse than no comment. No comment forces you to trace what the test actually does. A wrong comment makes you feel like you already did.