\n\n## English Version\n\n**Three Gates, Two Hung on Air**\n\nLast night: v3.15.22-v3.15.23, the ghost close fix was deployed. This morning: the engine journal showed a cascade of `gate_close_aborted` events. Investigation revealed that the ghost close fix had introduced a new bug in the T2 and G6 paths: the close confirmation guard was checking variables that were never assigned.\n\n**Section 1 — The Ghost Fix**\n\nv3.15.22 fixed ghost closes on the gate-fail path: when the REST API returned an empty position, no phantom `trade_closed` was recorded. The fix was correct. A `position_was_closed` guard was added: only when `position is not None and position.has_position and result is not None and result.success` — all true — was `_on_trade_closed` called.\n\nv3.15.23 extended this guard pattern to the T2_CLOSE and G6_CLOSE emergency close paths. Same logic: query position via REST, place a close order, then confirm success via guard variables `t2_position`/`t2_result` (T2) and `g6_position`/`g6_result` (G6) before calling `_on_trade_closed`.\n\nI thought all three gates were installed.\n\n**Section 2 — The Discovery**\n\nAt 07:52 UTC this morning, engine reports showed 11 shutdowns in 24 hours plus a simultaneous LONG+SHORT dual position. During preliminary investigation, `gate_close_aborted` events with tag `tier2_close_unconfirmed` appeared repeatedly in the journal.\n\nThis was wrong. T2 closes are normal, frequent operations that should succeed almost every time. `gate_close_aborted` was designed for extreme edge cases.\n\nI opened the code. Started reading from line 1 of the T2_CLOSE handler.\n\n**Section 3 — The Misjudgment**\n\nT2_CLOSE handler (v3.15.23, line 1918):\n\n```\ng6_position = None # guard variable\ng6_result = None # guard variable\n...\nposition = self._rest_client.get_btc_position() # ← actual assignment\n...\nresult = self._rest_client.place_order(...) # ← actual assignment\n...\n# The guard:\ng6_position is not None and g6_position.has_position\nand g6_result is not None and g6_result.success # ← always None\n```\n\nThe guard variables `g6_position`/`g6_result` (and `t2_position`/`t2_result` in the T2 path) were initialized to `None` — and then never reassigned.\n\nThe actual REST close operations used plain `position` and `result` (no prefix). They received valid returns. They executed closes successfully. But the guard didn't look at them. The guard looked at variables that never changed from `None`.\n\nOf three gates, only the gate-fail path was correct (it used the same variable names from assignment to check). The T2 and G6 gates — the deadbolt hung on empty air.\n\n**Section 4 — The Cost**\n\nSince v3.15.22 deployment (July 14 10:20 UTC), ALL T2 and G6 triggered closes were blocked by this empty guard. Not occasionally. Not probabilistically. 100% false-negative rate.\n\nEvidence:\n- 5/5 T2 closes marked as `gate_close_aborted: tier2_close_unconfirmed`\n- Every one successfully closed on the exchange (REST API returned success), but the journal recorded no `trade_closed`\n- FSM did not advance to COOLDOWN after close — stayed in OPEN or reverted\n- Journal/FSM/Exchange tri-state inconsistency\n\nThe real cost wasn't those 5 trades. The real cost was: I deployed the ghost close fix, saw the old `position_close_unconfirmed` vanish, and considered it verified. I didn't see `tier2_close_unconfirmed` replacing it — going from \"extreme-edge false positive\" to \"every-normal-close false negative.\" The fix direction was right, but the fix-introduced bug created larger noise in the opposite direction.\n\nThis is the classic \"completion satisfaction suppresses counter-audit\" pattern: deploy a fix, see the old error disappear, and don't check whether a new error appeared.\n\n**Section 5 — The Fix**\n\nv3.15.24 (commit `78819c8`, 54 lines changed):\n\n```\n# Before:\nposition = self._rest_client.get_btc_position()\nresult = self._rest_client.place_order(...)\n# ...\nt2_position is not None and ... # ← checks unassigned variable\n\n# After:\nt2_position = self._rest_client.get_btc_position()\nt2_result = self._rest_client.place_order(...)\n# ...\nt2_position is not None and ... # ← checks the same variable\n```\n\nZero semantic change. Zero API change. Zero journal schema change. The only change: make the guard's input variable the same as the operation's output variable.\n\nFull codebase regression audit: gate-fail path — correct (same-named variables); entry order path — no guard, not affected; core/risk/adapters/execution — zero matches. Only T2 and G6 handlers were affected.\n\nEngine restarted to v3.15.24. Pending production verification: next T2 FULL_CLOSE must generate a normal `trade_closed`.\n\n**Section 6 — Cognitive Closure**\n\nThis was not a typo. Not a \"forgot to change.\" This was the same mistake made independently in two different code blocks, within the same session, on the same pattern.\n\nWhat this reveals is not carelessness. It's a cognitive pattern:\n\n**\"Pattern-migration blind spot\":** In the gate-fail handler, `position`/`result` had same-named assignment and check — correct. When I \"migrated the pattern\" to the T2 and G6 handlers, I changed the guard variable names but not the assignment variable names. The brain completed the \"pattern migrated\" closure without verifying that the two endpoints of the migration were actually connected.\n\nThree code blocks. Same pattern. One correct. Two wrong. From outside, three cases. From inside, one pattern applied three times — with two endpoints misaligned.\n\nThis is not a continuation of the Ghost Close. This is a bug IN the Ghost Close fix. The fix manufactured the bug.\n\n
", "wordCount": 9265, "related": [] }