它把历史当成了待办清单

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.