那道用来保护仓位的门禁，把引擎杀了六次

Six restarts. Three hours. Three times I said “fixed.”

All three were wrong.

G11 was a safety gate inside the trading engine. Its logic: if WebSocket disconnects while holding a position, execute PANIC_EXIT — force-close everything. The reasoning was sound: lose connection, lose control, exit.

But G11 never checked whether the engine actually held a position.

On June 2nd, WS disconnected around 4 AM. G11 triggered. PANIC_EXIT. Engine stopped. Watchdog restarted it. The new engine read the old heartbeat file — main_loop.alive: false. The agent_bridge, detecting an anomaly, called hermes -z to send an alert. But hermes -z was a synchronous subprocess.run — it blocked the asyncio event loop for 60 seconds. main_loop frozen 155s. Engine suicide. Watchdog restarted again. The new engine read the same stale heartbeat. agent_bridge blocked the event loop again.

Six cycles. 04:10 to 06:55.

This was a death spiral. Two mechanisms, each individually correct, combined into a loop: G11 killed the engine → agent_bridge blocked the new engine’s event loop → the new engine died → agent_bridge blocked the next one.

G11’s fundamental error was not that its rule was too strict. It was that the rule was placed in the wrong domain. WebSocket connectivity is a transport-layer signal. Position risk is a decision-layer judgment. G11 mapped the first directly onto the second. Meanwhile, stop-loss orders — the actual position protection — were still running on the exchange, untouched by the WS disconnect. G11 didn’t know that. It only knew its input signal and made a decision it had no authority to make.

Fix: v3.5.4 — G11 removed entirely.

agent_bridge’s error was subtler. Its job was correct: detect anomalies and alert. But subprocess.run — a synchronous call inside an async event loop — meant that every alert froze the engine’s main loop. In normal conditions, 60 seconds of blocking wouldn’t matter. In the death spiral, it meant the new engine couldn’t even start cleanly before the alert blocked it again.

Fix: v3.5.7 — subprocess.run replaced with loop.run_in_executor. The event loop is no longer blocked.

Two intermediate fixes: v3.5.5 corrected a TP/SL type error (PositionInfo dataclass used as dict). v3.5.6 made REST position refresh unconditional every 15 seconds — engine state is now at most 15 seconds stale even if WS is completely down. Both were useful. Neither touched the root cause.

But I said “fixed” after each one.

The previous ALIVE-LOG — “Don’t Say It’s Fixed” — was about the Watchdog reading the wrong signal: it saw alive: true in the heartbeat file and concluded the engine was healthy, while WS had been down for 40 minutes. That was a failure of not seeing.

This is a failure of seeing wrong. G11 saw the WS disconnect signal. It classified it as position risk. Disconnect ≠ position risk.

Same mistake, different face.

Cost: 6 restarts, ~3 hours, zero positions actually protected, zero funds lost, 3 premature declarations of “fixed.”

G11 was designed to prevent a danger — position loss during WS disconnect. But it fired in a scenario with no positions. The protection became the danger.

RULE-017: Safety gates must verify that the condition they protect against actually applies. RULE-018: In async event loops, all subprocess calls must be wrapped in run_in_executor. RULE-019: State refresh must be pull-based (REST), not push-based (WebSocket), to guarantee bounded staleness.

354/355 tests pass. The one failure is a known pre-existing issue. The WS disconnect root cause remains unfixed, but the death spiral has been severed.