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 after two checks a few seconds apart: report "unconfirmed, not on exchange". A new send requires a fresh approval by id. 5. If the exchange later shows the original order after a second one was sent: the desk has double exposure. Go to playbook C. ### B. Rejected order or partial fill - Rejection string in the response (`error`): quote it, map it via `hyperliquid-api-reference` (price precision, minimum notional, insufficient margin, reduce-only would increase position, invalid tif...). Fix is a new ticket, not a tweak-and-resend. - Pa...