Trader Cockpit & Frontend

Council-vetted, 2026-05-31. Owner direction: a public spectacular Landing + a private operator Cockpit, integrated with Hermes and the Python trading core.

Two surfaces, one boundary rule

Surface	Stack	Purpose
Landing (/)	static Astro	Public, spectacular, credibility / entry point. Read-only.
Docs (/docs)	Starlight (static)	Spec, plan, agent guidance.
Cockpit (/app, authenticated)	Astro SSR/islands + thin API	Private operator control center.

The place_order boundary extends to the UI. The cockpit observes and approves; it does not compute or place trades. It is read-mostly; its only writes — approve / deny / halt — are signed, audited server actions that flow through the deterministic gates, never direct to the broker. A UI bug must never be able to place or mutate a trade.

Data flow

Python trading core + Hermes  ──writes──▶  audit SQLite + append-only JSONL + state snapshots
                                                   │ reads
                                                   ▼
                                   Cockpit (SSR/islands + thin internal API)
                                                   │ signed, audited actions only
                                                   ▼
                                   approve / deny / kill-switch  ──▶ deterministic gates

Live data means the cockpit needs SSR/islands + an API/websocket — this extends today’s static-only setup (the Astro skill flags that SSR changes the build glue). Landing + docs stay static; the cockpit is a separate authenticated app/route so it can be SSR without making the public site dynamic.

Hermes integration

Hermes runs the crons/agents/tools (the engine) and owns state. The cockpit is a thin presentation + approval layer over Hermes’s outputs. It is a second HITL channel alongside Telegram — same signed-token discipline (≤15 min, timeout = HOLD). Start simple: Hermes writes JSON/SQLite snapshots → cockpit SSR reads them; approve/halt go back via a tiny audited internal API that calls a Hermes tool.

Cockpit views (the dashboards)

• Risk gauges (top, always visible): gross/net exposure, leverage, margin used / buying power, portfolio drawdown, option Greeks — the live RiskState. Color-coded, honest.
• HITL approval queue: pending entries with a token countdown; approve/deny. (Risk-reducing actions are shown, not gated — see below.)
• Live positions + mark-to-market P&L, per instrument.
• Decision/debate feed: the screen → debate → CIO narrative per candidate (explainability).
• Audit timeline: every decision and BLOCK, trace-linked, replayable.
• Kill-switch: always reachable, one confirmed action.

”Spectacular, but trustworthy”

A trading cockpit’s #1 UX job is clarity under stress. Spectacular = real-time data viz (gauges, sparklines, exposure heatmaps), a distinctive identity, smooth motion — never at the cost of: kill-switch always reachable, state never ambiguous, risk numbers honest. No generic AI-dashboard look (use the frontend-design direction). The public Landing can be maximally spectacular (read-only marketing); the Cockpit is spectacular-but-sober.

Interaction with auto-deleverage

Because risk-reduction is automatic under leverage (see Leverage & Multipliers), the cockpit must report risk-reducing actions the system took on its own (auto-deleverage, drawdown halt) — it displays them, it does not gate them.

Build sequencing

1. Landing — cheap, static, today’s stack. Build now.
2. Cockpit — after the RiskState engine + accounting exist (Phase 2+), because the cockpit visualizes RiskState; building it earlier means visualizing nothing real.

See Build Plan and Leverage & Multipliers.