Phase 1 run-control semantics and run_state events

docs/architecture/AGENT_DIAGRAM.md

@@ -139,6 +139,10 @@ Outbound Reply
   -> ChannelAdapter.send()  (text + optional attachments)
 ```
 
+Gateway streaming UX signals:
+
+- WebSocket `agent.send` emits `run_state` lifecycle events (`start`, `cancel_requested`, `cancelled`, `complete`, `error`) for UI/state rendering.
+
 Key files:
 
 - Routing + per-session agent creation: `src/daemon/routing.ts`

docs/architecture/GATEWAY_SESSIONS_AND_QUEUE.md

@@ -91,6 +91,7 @@ Within a lane:
 
 - Only one request executes at a time.
 - Later requests queue (FIFO) and start after the active request finishes.
+- `interrupt` mode enforces "latest wins": any queued backlog is superseded and the active run is asked to cancel so the newest request becomes the next (or immediate) execution.
 
 Across lanes:
 
@@ -112,6 +113,7 @@ Important:
 
 - Cancellation is best-effort for the currently running work: it stops at the next safe point in the agent loop.
 - Queued work is deterministically rejected.
+- Gateway streams `run_state` events (`start`, `cancel_requested`, `cancelled`, `complete`, `error`) so clients can render lifecycle state without parsing assistant text.
 
 Key files: