Strategy Lifecycle

Every setting on step 2 is editable from the terminal's Settings tab while the strategy runs. What differs is how the engine applies it:

One special case: increasing grid_levels extends the ladder — only the new rungs are added, and the existing levels, their inventory and their exits are untouched.

1. 1
   Raise max capital

   The terminal has a dedicated widget for adding capital to a running strategy — no restart, no redeploy.
2. 2
   With trail-down on

   The engine trails the grid down: the freed budget is deployed into new levels below the current window, immediately.
3. 3
   With trail-down off

   The ceiling simply rises. Existing levels are unchanged; the extra budget is available for refills and future extension.

• Raising with trail-down extends the ladder downward straight away.
• Raising without trail-down just relaxes the ceiling.
• Lowering never force-closes anything; it stops further deployment.

Commands are scoped to one strategy id, so an action can never affect another strategy or the orchestrator itself. The durable queue means a command issued while a worker is briefly disconnected is still applied on reconnect.

On start the engine looks for a persisted grid for the strategy id. If it finds one with real broker order ids or filled inventory, it adopts it: the live resting orders are kept and no duplicates are placed. Only a genuinely empty or unplaced grid is rebuilt from scratch.

• Idle orders are re-registered on resume. The deferred-order list is in-memory only, so without this a restart would orphan a pending refill.
• Session venues get a full rebuild on the next session open, because the exchange cancelled everything overnight — resting order ids from yesterday are dead.
• Base-position targets are reconciled so the engine does not keep reserving room for targets that have already unwound to their own levels.

• Missed-fill poller — periodically asks the broker whether any resting order filled beyond what the grid booked, and replays the difference. This is the direct recovery path for a silently stalled websocket.
• Position auditor — triggered only when the broker's own position feed disagrees with the grid's expected net, and only after a settle window plus a fresh re-poll, so a transient snapshot cannot cause a false heal.
• Level auditor — catches levels whose committed exposure drifted below capacity because a refill was dropped. Such a gap never shows up as a net position mismatch.
• Order healer — re-places orders that never reached the exchange. These hold no position, so no drift signal can surface them.

Deleting removes the bot record and the active config. It does not retroactively cancel orders that a running engine already placed, so stop the strategy first (with cancel-orders) and confirm the position is flat before deleting.

• 1.Engines — Python vs C++ — Who drains the command channel
• 2.Stop Loss — The halted state
• 3.Capital Allocation — Max capital as a live ceiling
• 4.Trail Modes — Trailing and rebalance