Same mission, same data, three shapes. Buttons are mock controls; nothing is sent anywhere.

Ratified 2026-07-31

The execution prototype is the UI intent

An interactive execution prototype (archived in this repo at docs/ui-prototype/) supersedes the three concepts below as the canonical direction. It is followed in spirit, not to the letter. It keeps Variation A's thread-first shell and extends it with an explicit strategy lifecycle and a state language for every mission moment.

Home: the bound thread

The mission UI lives in the fork's existing chat surface — essentials in the chat header, cards in the message timeline, deterministic controls beside the composer. No separate trading shell and no second screen (Architecture §6.3: do not build a second T3 inside T3). The Phase 1 workspace relocates from /settings/trading into the thread the mission is bound to.

The lifecycle rail

Research → Plan → Armed → Entered → Managing → Closed, rendered as phase pills over the thread, with Failed and Paused as overlays. The rail is a projection of mission status (Runtime §11.1) — analysing, waiting (armed), executing, position_open, completed, blocked, paused — never a second state machine.

The state language

Ten surfaces, each a card in the timeline: a market-snapshot card while researching; a versioned draft-plan card with a condition checklist; an armed card listing live watch values and the next evaluation; an order-intent card while an execution is in flight; fill and scale receipts with order ids and timestamps; a live position card (entry, mark, size, unrealized P&L, stop, liquidation); a completion summary with planned-versus-actual; order-rejected and stale-data cards; a paused card that states protection stays live on-exchange.

Risk-first chrome

A persistent mission strip (state, exposure, maximum loss, one primary action) whenever the mission is armed or exposed. Close & stop is always one click. Maximum loss is visible in every state. Every number carries a freshness stamp, and stale data suspends order placement — visibly.

Delivery map

Phase 2 ships the research surface (header essentials, market-snapshot card). Phase 3 ships the lifecycle rail, plan card, armed card, composer, and timeline. Phase 4 ships order intent, receipts, and the live position card. Phase 5 ships the mission strip, the paused / rejected / stale surfaces, and the completion summary. Phase 7 ships the interpretation echo. Each phase renders only the states its backend makes true.

POC constraints hold

One active mission, ETH perpetual only, testnet only — unchanged through Phase 8. The prototype's multi-strategy sidebar, BTC copy, and mainnet toggle are post-POC aspiration; the sidebar shows the one active mission plus history. Its "Ask before orders" per-order approval mode is deferred post-POC: the POC ships the auto-within-limits authority model only.

Shared principles

What all three variations refuse to do

No second screen

Everything lives on one screen, like a T3 Code thread. Depth is folded into the surface — receipts, tool cards, answers — never routed to another page.

Essentials only

Price, position, protection, equity, and the loss budget. Four numbers and two small charts answer "is my money safe" without a dashboard.

Limited deterministic controls

Pause, Reduce, Close, Revoke — the §14.7 user controls. They never wait for the harness, and there is deliberately nothing else to press.