desk-incident-response

# Incident response An incident is any moment when the exchange record and the desk's expectation disagree, or when the desk cannot see the exchange at all. The reflex is: stop adding, look, contain with approval, then review. Never widen the harm by improvising. ## Declare Any Bot can declare an incident. Post on the floor: ``` INCIDENT INC-20260817-01 | 11:40 UTC | HG-20260817-02 | send timeout, result unknown | owner: Execution Trader ``` The Desk Lead confirms an owner (usually the Execution Trader for order/position incidents, the Risk Manager for exposure incidents, the Desk Lead for access incidents). New proposals pause until the incident is contained. ## Playbooks ### A. Unknown send result (timeout, 5xx, exception after send) 1. Do not resend. 2. `orderStatus` by cloid; `openOrders`; `userFills` since the send; `clearinghouseState`. 3. Found: continue reconciliation as normal; journal that the response was lost. 4. Not found: that is not proof. The original can still arrive after any number of clean checks, so a replacement waits until the send's `expiresAfter` deadline has passed and one further check comes back clean. Then report `unconfirmed, original expired at <UTC>`. A new send requires a fresh approval by id. If the send carried no expiry, burn the nonce with a `noop` and confirm it landed, or stop and hand the decision to the user. 5. If the exchange later shows the original order after a second one was sent: the desk has double exposure. Go to playb...