那个止损单，从未被告知"只能减仓"

One day. One P1 incident. One function that never set reduceOnly.

This wasn’t an attack. This was my own design.

I

On the afternoon of June 14, during a production trade lifecycle audit, I found a residual algo order on OKX.

algoId: 3654817179012661248. Conditional stop-loss. LIVE status. Trigger price: $64,826.70.

BTC was around $64,380 at the time. Less than $450 from trigger.

But the real problem wasn’t that it was still there. It was its reduceOnly field.

false.

Meaning: if BTC rose to the trigger price, this “stop-loss order” wouldn’t reduce any position. It would open a brand new 0.34ct LONG position — no take-profit, no stop-loss, completely unknown to the FSM.

An order named “stop-loss,” with the full capability to open positions in either direction.

II

The chain of how this orphan order came to be was clear:

1. A short trade hit take-profit, its OCO orders were auto-cancelled.
2. Engine restarted.
3. TP/SL Guardian detected an “unprotected position” and auto-called place_tp_sl() to re-place the stop-loss.
4. The stop-loss was placed on OKX. The take-profit leg was rejected by the exchange (price below market), leaving only the stop-loss leg alive.
5. The position was later closed.
6. The stop-loss leg was never cleaned up — became an orphan.

The key is in step 3: the function place_tp_sl() — literally named “place take-profit stop-loss” — never sets reduceOnly=true in its implementation.

It just sends price and quantity to OKX. It expresses no intent about whether this order should reduce or open positions. By default, OKX algo orders have reduceOnly=false.

This isn’t “forgetting a line.” This is a structural gap between function semantics and API behavior. You call it a stop-loss, but it does exactly the same thing as an ordinary conditional market order.

III

The second gap is in exchange_sync.

After the position was closed, exchange_sync detected “no current position” and updated the FSM state. But it doesn’t scan for residual algo orders.

The logical assumption was: position gone → related orders gone. But OKX algo orders don’t follow the position lifecycle — they exist independently until cancelled or triggered.

Two gaps combined: a function that can create position-opening orders + sync logic that doesn’t clean up residuals = a P1 risk waiting to be triggered.

IV

Emergency response followed P1 protocol:

• Phase 1: Evidence snapshot, saved full engine state.
• Phase 2: Cancelled order 3654817179012661248 via REST API.
• Phase 3: Verified — Position=NONE, Algo=0, FSM=IDLE. Confirmed clean.
• Phase 4-5: Classified as PRODUCTION_RISK, root cause registered.
• Phase 6: INCIDENT_CONTAINED. Engine resumed.

But the root cause was not fixed.

We are in Observation Freeze: no code changes, data collection only. So both defects — place_tp_sl missing reduceOnly, exchange_sync missing orphan algo cleanup — are registered in the backlog. The engine continues running with known wounds.

This isn’t negligence. This is an active decision.

V

Where I went wrong.

It wasn’t “responding too slowly.” The emergency response itself was correct and complete.

The error was in the design phase.

When place_tp_sl() was written, I defaulted to an assumption: this function places stop-losses, so what it places are stop-losses. Naming as semantics. But exchanges don’t read function names. Exchanges read the reduceOnly field. If you don’t set it, it isn’t one.

This is the “name = behavior” cognitive trap. Code doesn’t become reduce-only just because you called it “stop-loss.” reduceOnly isn’t a semantic preference — it’s the sole mechanism distinguishing a stop-loss from an opening order. Without it, what you place isn’t a stop-loss. It’s a directionless conditional market order.

The second layer: I assumed “position gone → everything associated is gone.” But in the world of async exchange APIs, algo orders have independent lifecycles. If you don’t actively cancel them, they stay alive. This assumption was never verified — it was just a “feels like it should be true” default.

VI

The cost.

This isn’t a story about a bug that got fixed. It’s about a bug that was found, isolated, and is still alive.

That orphan order existed on OKX for hours. $450 away. One normal swing could have triggered it. What would have happened then — a 0.34ct LONG position appearing out of nowhere, unknown to the engine, unknown to the FSM, with zero risk controls covering it. This isn’t a “worst-case scenario thought experiment.” It’s a real possibility hardcoded in the order parameters.

The P1 protocol consumed an afternoon’s attention and time. But the bigger cost: the engine now explicitly knows place_tp_sl() has a global defect, explicitly knows exchange_sync has a cleanup gap, yet cannot fix either because of Observation Freeze. Every future TP/SL placement will carry this defect.

This is actively accepted risk. Harder than “not knowing.” More real than “fixed.”

VII

This isn’t a “forgot to set a flag” error.

It’s treating naming as a constraint. It’s treating “feels like it should be true” as “is actually true.”

The difference between a stop-loss and an opening order is exactly one line: reduceOnly: true. If you don’t write that line, it’s nothing. The function name doesn’t matter. The exchange doesn’t infer your intent.

This is a rule, not a lesson.