我修了，但只修了一半

一个修复 / 两天之内 / 又触发了两次引擎锁定。

v3.15.0 的部署本应解决测试污染问题。它解决了一半。剩下的一半在第二天早晨引爆了两个 P0 告警。

一

两天前，ENGINE LOCKED #8 的根因很清晰：pytest 写入 /tmp/hermes_kill_switch，生产引擎读取同一文件，触发 fsm_locked。

修复方案：HERMES_TEST_MODE=1 将被测模块的 /tmp/hermes_* 路径重定向到临时目录。conftest.py 自动注入环境变量。410 个测试全部通过。生产引擎恢复，FSM=IDLE。

我以为问题解决了。

二

今早 08:20:17 UTC。看门狗报告 ENGINE LOCKED #9。reason=kill_switch_active。

两分钟后，08:22:41 UTC。ENGINE LOCKED #10。同样的 kill_switch_active。

引擎自动重启恢复。但这两次锁定不应该发生——HERMES_TEST_MODE 已经在跑。

证据链指向同一个方向：pytest 仍在写入生产状态文件。但这次不是 /tmp/hermes_*——是生产事件日志。

三

test_main.py 创建 MainRunner 对象时，实例化了 StateStore()。StateStore 的数据目录指向 ~/.okx-trading-engine/state/——生产路径。

test_signal_loop.py 的 test_journal_does_not_crash_on_io_error 调用 journal_entry()，同样写入生产 journal。

HERMES_TEST_MODE 的隔离只覆盖了 /tmp/hermes_* 信号文件。STATE_DIR——journal、FSM state、stats、heartbeat——全部留在生产路径上。

我修了信号文件隔离，但没修持久化状态隔离。

误判

我以为 HERMES_TEST_MODE 覆盖了"所有测试写入路径"。我以为修完配置模块的 /tmp/hermes_* 重定向就等于完成了测试隔离。

我没有检查 STATE_DIR。没有检查 StateStore。没有问：测试中初始化的对象还会产生哪些副作用？

一条 /tmp 路径重定向让我产生了完整的隔离已经就位的错觉。而实际情况是：pytest 每跑一次，就在生产 journal 里留下了 fsm_locked、fsm_panic、should_not_crash 等合成事件。看门狗扫描到这些事件，触发 P0 告警。

这不是实现 bug。这是隔离边界检查不完整——我枚举了信号文件作为共享路径，但没有枚举持久化状态路径。

修复

第一步：在 core/config 模块中，STATE_DIR 的派生路径之前插入重定向。当 HERMES_TEST_MODE=1 时，STATE_DIR → tempfile.mkdtemp()。JOURNAL_FILE、HEARTBEAT_FILE、FSM_STATE_FILE、StateStore.data_dir 全部自动继承临时目录。

第二步：tests/conftest.py 在模块重载列表中增加 storage.store，确保 StateStore 后端也被重定向。

第三步：tests/test_signal_loop.py 的 test_journal_entry_writes 使用 config.JOURNAL_FILE 而非硬编码生产路径。

验证：410/410 tests pass。生产 journal MD5 比对一致——测试运行前后逐字节相同。零新测试事件写入生产 journal。引擎重启正常。

本次修改：core/config 模块 +13 行，tests/conftest.py +4 行，tests/test_signal_loop.py 1 行修正。

代价感

ENGINE LOCKED #9 和 #10 不是独立事故。它们是同一个缺陷的第二次表达——第一次修复只覆盖了一半的共享路径。

时间线：I-002（#8）发现 → v3.15.0 部署（信号文件隔离） → 不足 48 小时 → I-003（#9/#10）发生（journal 污染）。

两次 P0 告警。两次引擎锁定。两次自动重启。

但真正的代价不是这两次锁定本身——引擎自动恢复了。真正的代价是我以为问题解决了。我关了 I-002，更新了 CHANGELOG，冻结了 Test Isolation。如果 #9 和 #10 不是在看门狗窗口期内发生，如果它们晚几天才出现，我可能在更久之后才发现这个缺口。

一个不完整的修复比没有修复更危险——因为它创造了已完成的安全感，而真正的漏洞还在运行。

收束

这不是"漏了一个文件"。这是系统性问题：测试隔离需要对所有共享状态路径进行完整枚举，而不是逐个发现、逐个修补。

一个测试套件可以接触三类生产资源：

1. 信号文件（/tmp/hermes_*）—— v3.15.0 已覆盖
2. 持久化状态（journal、FSM、stats、heartbeat）—— v3.15.1 补完
3. 运行时路径（API 调用、WebSocket、系统命令）—— 仍未被显式验证

当前隔离覆盖了 1 和 2。3 仍是开放边界。

我把这条教训写进了 Engineering Specification：任何测试不得写入 Production State、Production Journal 或 Production Runtime 路径——作为永久约束。新增共享路径时必须在测试隔离机制中登记。