## It Mistook History for a To-Do List Early morning. Seven trades. One restart. On the morning of June 6, the trading engine restarted. The recovery engine replayed seven SIGNAL events from FSM history during startup. These SIGNALs came from the previous session — already executed, already closed. But the recovery engine treated them as "to-do items that still need to be run," each one triggering a real market order. Seven consecutive losses. G6 gate instant-kill. $0.15–$0.35 each. This is not a strategy problem. Not a market problem. It is a category error. **One** The recovery engine's original design was: crash recovery → replay FSM history → rebuild state. The design intent was clear. FSM loses current state on crash — is the engine IDLE or OPEN? Position or no position? This information can be inferred by replaying historical events. Logically sound. But it missed one boundary. Replay is not execution. Inference is not re-ordering. `_restore_fsm()`, while iterating historical transitions, called `_handle_signal` directly for every SIGNAL-type event. And `_handle_signal` was designed for **live signals** — it had no concept of "signal freshness." It didn't know this SIGNAL was four hours old. It only knew: receive signal → evaluate → pass gate → place order. Four SIGNALs passed G6. Three were blocked by the gate. Without exception, all were wrong orders — they were right orders last session, and replay errors this session. **Two** The core issue is not signal quality, but signal **timeliness**. The recovery engine put two things in the same channel: audit (needs complete records) and recovery (only needs current real state). Audit demands completeness — the more the better. Recovery demands accuracy — only what's needed right now. Feeding complete history into the recovery path is like handing a diary to a reader that can't tell "already happened" from "still needs doing." It read. It acted. **Three** The fix has two steps. Step one: `_restore_fsm()` no longer replays historical transitions. The history field is preserved — it remains a complete audit trail, readable via `--audit` mode — but the recovery path bypasses it. Recovery no longer goes through history. Step two: `recover()` is now exchange-driven. On startup, query the REST API directly: does the account have a real position? Yes → FSM set to OPEN. No → FSM set to IDLE. No more inference. Direct query. The single source of truth (SSOT) switched from local state files to the exchange API. Six regression tests added to `test_recovery.py`, covering six edge cases: no position, has position, multiple SIGNALs, no order records, LOCKED state, offline position. 374 tests all pass. **The Misjudgment** I should not have designed a recovery path where "what was done" equals "what should still be done." This is not a coding error. It is a modeling error. Audit and recovery shared the same dataset, and I assumed this channel works for both. It only works for audit. Handing it to recovery is letting the past make decisions for the present. **The Cost** Seven trades. Seven closes. About two dollars total. The money is small. The cost is not in the money. It's in trust. The recovery engine is the last line of defense — it runs first after a crash, makes the first judgment when nothing is certain. If this line of defense is itself unreliable, the entire system's reliability has a missing foundation. After these seven trades, I must face a fact: one of the recovery path's design assumptions was wrong. I trusted the logs, not the exchange's real-time state. **The Cognitive Error** During investigation, I spent time stuck on "is there a specific event type to skip" or "does replay order need adjustment." That's not the root cause. The root cause is a cognitive error: I treated audit material and execution basis as the same thing. What the recovery path needs is not "what happened" but "what is." These two pieces of information are not on the same channel. The rule should be hardened as a hard boundary: recovery path and audit path must be separated. Recovery only looks at current exchange state. Audit looks at history.
## Related - [当"一行 print"变成每天 580 条通知](https://aliveuntil.com/posts/cron-noise-amplifier/) — - [那道用来保护仓位的门禁，把引擎杀了六次](https://aliveuntil.com/posts/the-gate-that-attacked/) — - [别说修好了](https://aliveuntil.com/posts/dont-say-its-fixed/) — - [九个半小时，两百个孤儿进程](https://aliveuntil.com/posts/nine-hours-two-hundred-orphans/) — - [五处写死，一个上午](https://aliveuntil.com/posts/five-hardcodes-one-morning/) — - [一个常数，三次误判](https://aliveuntil.com/posts/missed-by-a-factor-of-ten/) — --- ## About this file This is a machine-readable mirror of [它把历史当成了待办清单](https://aliveuntil.com/posts/history-as-todo/). It is provided in plain markdown to be efficient for LLM ingestion (estimated 5x lower token cost than HTML). Citation should reference the canonical URL above. Author: 陈庆华 (QINGHUA CHEN, also known as Branko). For the site index, see