Every write travels one spine

Requested is a question, not an answer

The decider never pretends a side effect happened. Press pause in the UI and the event on the wire is trading.mission-control-requested, a request, and its contract says so: "the request itself is not a promise that it will be accepted". The reactor then runs the transition through TradingMissionService, where the status legality table and the one-active-mission invariant are enforced, and only after that write succeeds does it dispatch the internal trading.mission.status-set command whose event the projector folds.

"That ordering is the whole point. The UI never sees a status the domain refused, and mission state still reaches clients over T3's ordered WS push path rather than a side channel." apps/server/src/trading/TradingMissionReactor.ts:10-12

Creation works the same way. The mission-create payload's contract states: "Nothing is persisted yet: TradingMissionReactor performs the write and then raises trading.mission.status-set, so the projection only ever reflects state the domain accepted." And a refusal is not an exception path: "A refused control or execution is a normal outcome, not a crash: the projection keeps the state the domain still holds."

This ordering requires every mission event to join an ordered stream. Each trading command names the thread bound to the mission's agent runtime, called the harness in code. The mission events then use the thread's existing WebSocket stream to reach the UI. Manual orders have no thread, so they use a synthetic per-account mission aggregate, manual:{accountId}, which preserves per-account ordering.

Two classes of command, two answers

Not every operation belongs on the event spine. Use a direct RPC when the operator needs an immediate result or refusal. For example, preview returns its refusal in the RPC response, while placement uses an event-sourced command. The same reasoning appears throughout the client wiring: reviseTradingPlan is an RPC command because "the operator needs the answer, not an acknowledgement", and a plan-document activation needs its refusal (stale_hash) on screen before the operator believes the plan is active.

When the write must be durable, ordered, and replayable, it is a dispatched command. The §14.7 user controls (pause, resume, revoke, risk control) dispatch straight to the server, and that directness is the point: "no harness turn stands between the press and the action." The dispatch is acknowledged with a sequence, the outcome arrives later as an event on the feed, and the UI tracks the press as pending until the result does. These controls keep working when the provider process is unavailable. Safety invariants explains that independence.

The manual order ticket uses both classes at once: preview and manual close are RPCs, "the user needs the refusal on screen; the place itself is an event-sourced dispatch, answered through the feed." The client builders that mint commandIds for these dispatches are covered in Web & desktop.