07 – TUI and web dashboard [SPEC]

TUI as primary frontend, web dashboard as secondary management surface

Reader orientation: This document specifies the web dashboard for Bardo Compute, the managed VM hosting service for Golems (mortal autonomous DeFi agents). It belongs to the Compute layer of Bardo (the Rust runtime for these agents). The key concept before diving in: the TUI (bardo CLI, built on ratatui) is the primary interactive frontend; the web dashboard at bardo.money/compute is a secondary management surface for deployment, monitoring, and fleet overview. Terms like Golem, Styx, Grimoire, and x402 are defined inline on first use; a full glossary lives in 00-overview.md § Terminology.

Two surfaces, different purposes

The Golem has two user-facing surfaces. They serve different purposes and carry different weight.

TUI: the primary interactive frontend

The TUI (bardo CLI) is a full terminal application built on ratatui. It is the primary way owners interact with their Golems. It renders the GolemEvent stream in real-time – heartbeat ticks, emotional state, vitality curves, dream cycles, trading activity, and death approach are all visible as they happen. The TUI connects to the Golem’s event stream through Styx, meaning it works from anywhere, even when the Golem is behind NAT.

The TUI is specified in prd2/18-interfaces/03-tui.md. This document covers only the web dashboard.

Web dashboard: the secondary management surface

The web dashboard (bardo.money/compute/*) handles VM lifecycle management: provisioning, extensions, destruction, billing. It does NOT attempt to replicate the TUI’s real-time cognitive visualization. The dashboard is a REST-driven management interface. The TUI is where you watch your Golem think.

Web application structure

Six pages under /compute. Admin auth uses Privy JWT with admin role.

/compute                        Dashboard (SSE-powered)
/compute/deploy                 Deploy new Golem
/compute/g/[name]               Golem detail view (owner)
/compute/g/[name]/term          Full-screen terminal (owner)
/compute/g/[name]/public        Public Golem page (no auth)
/compute/admin                  Operator admin dashboard (admin role)

Page: Compute dashboard (/compute)

SSE dashboard (replaces polling)

Replace 10s polling with EventSource to GET /v1/machines/mine/events. Initial data load from GET /v1/machines/mine, then SSE for real-time updates.

Fallback: If SSE fails, falls back to 30s polling (not 10s – reduce load on error).

GolemCard component

TTL color coding

Vitality indicator

The dashboard shows a vitality bar alongside the TTL bar. This communicates a distinction the TTL bar alone misses: a Golem can have plenty of TTL but low vitality (epistemic decay, stochastic event approaching), or low TTL but high vitality (self-funding Golem about to extend itself).

Clock-drift-proof countdown

useTTLCountdown hook computing offset from server_time. Fly VMs have been observed with up to 33 minutes of clock skew. The offset is computed from each API response’s server_time field.

Page: Deploy new Golem (/compute/deploy)

Three input modes

1. Natural language – Describe strategy in plain English, compiled to STRATEGY.md
2. Templates – Pick from curated strategy templates
3. Editor – Write STRATEGY.md directly in Monaco/CodeMirror

Strategy compilation

Model: Claude Sonnet 4

Validation rules:

• Must contain all 8 required sections (Overview, Objective, Entry Criteria, Exit Criteria, Risk Parameters, Target Protocols, Asset, Rebalance Frequency)
• Risk parameters must be numeric and within bounds (drawdown 1-50%, position size $1-$100K)
• Target protocols must be from supported list
• Asset must be a valid token symbol

Cost tracking: First 3 compilations per user: free. After 3: x402 payment required (phase 2, priced at cost).

Configuration options

Duration slider displays micro-USDC cost live as the slider moves.

Custody mode selection

The deploy form includes a custody mode picker with clear tradeoffs:

Delegation is the recommended default. The form pre-selects it and shows “Recommended” badge.

Deploy loading states

Step-by-step provisioning progress backed by SSE:

Step labels:
1. "Verifying payment..."           (10%)
2. "Starting your Golem..."         (30%)
3. "Loading tools and Grimoire..."  (50%)
4. "Connecting to Styx..."          (65%)
5. "Registering identity..."        (80%)
6. "Settling on Base..."            (90%)
7. "Your Golem is live!"            (100%)

Usually takes 3-8 seconds for warm pool.

Payment flow

1. User configures Golem, selects custody mode, clicks “Deploy”
2. UI calculates cost: duration_hours * price_per_hour_micro_usdc
3. User reviews cost breakdown
4. For Delegation mode: user signs ERC-7715 permission grant in MetaMask
5. UI constructs EIP-3009 receiveWithAuthorization signature request
6. User signs with wallet
7. UI sends POST /v1/machines with X-402-Payment header
8. UI receives 202 Accepted with machine_name
9. UI connects to SSE GET /v1/machines/:name/provision-status
10. On ready: redirect to detail page, show TUI connection command

Empty/error states

0 Golems (first visit): CTA “Deploy Your First Golem” with link to docs.

Failed provision: “Provisioning failed. You were not charged.” with retry and change-region buttons.

Crashed Golem: Shows crash reason, restart count (5/5), and options to redeploy (keeps Grimoire), view logs, or destroy.

Page: Golem detail (/compute/g/[name])

Tabbed layout with 7 tabs: Overview, Strategy, Terminal, Logs, Grimoire, Wallet, Custody.

Overview tab

• Status, TTL countdown, vitality bar, behavioral phase
• Styx connection status
• Sustainability ratio (if self-funding)
• Recent GolemEvents (last 10, from SSE)
• Quick action buttons

Custody tab

Shows delegation details (for Delegation mode), Privy wallet details (for Embedded mode), or local key status (for LocalKey mode):

• Active delegation hash, caveat enforcers, remaining budget
• Session key address, rotation policy, operations signed
• Delegation expiry countdown (maps to MortalityTimeWindow)

Mobile quick actions

Wallet balance clarity

Wallet section shows clear distinction based on custody mode:

• Delegation: “Funds remain in your MetaMask Smart Account. This Golem operates via delegation.”
• Embedded: Full wallet address with copy. USDC and ETH balances. “This is your Golem’s trading wallet. Funds are swept to you when the Golem dies.”
• LocalKey: Local key address with delegation bounds displayed.

Page: Public Golem (/compute/g/[name]/public)

No authentication required. Shows read-only Golem status, strategy summary, vitality, equity curve, and extension buttons.

Extension explainer

Context for non-crypto users:

• “This Golem runs on prepaid compute credits (USDC). When credits run out, it shuts down. Anyone can add more time – no account needed.”
• Step-by-step: click button -> connect wallet -> approve USDC -> timer extends

Permissionless extension buttons

Pre-configured durations: [+4h $0.20], [+24h $1.20], [+7d $8.40]

Flow: connect any EVM wallet -> sign EIP-3009 -> POST /v1/machines/:name/extend -> TTL extends, SSE pushes update.

Page: Terminal (/compute/g/[name]/term)

Full-screen terminal emulator (xterm.js). Connects via WebSocket through SSH CA proxy. Uses short-lived tickets.

Features: full PTY support (resize, colors, cursor positioning), automatic reconnection on disconnect, copy/paste support.

The terminal provides raw SSH access to the VM. For the rich Golem interaction experience (heartbeat visualization, vitality curves, emotional state, creature display), use the TUI via bardo attach <golem-name>.

Page: Admin dashboard (/compute/admin)

Auth: Privy JWT with admin role.

Health indicators

Admin sections

• Fleet overview – All Golems across all users, filterable by status/region/size/custody-mode
• Revenue – Total USDC collected, settled, pending. Self-extension revenue tracked separately.
• Warm pool – Pool sizes by region, claim rates, replenishment queue
• TTL worker – Last run, next run, machines approaching expiry
• User lookup – Search by wallet address, view all Golems for a user
• Vitality overview – Golems by behavioral phase, approaching Terminal count

TUI connection from web

After deploying a Golem or viewing a detail page, the web dashboard displays a TUI connection command:

bardo attach golem-V1StGXR8_Z5j

This connects the TUI to the Golem’s event stream through Styx. The TUI renders the full cognitive visualization: heartbeat pipeline, emotional state, vitality curves, dream cycles, creature display, trading activity.

For remote self-hosted Golems, the TUI connects through Styx:

TUI <-- WSS ---- Styx <-- WSS ---- Golem (behind NAT)

Events flow from Golem to Styx to TUI. Steers flow from TUI to Styx to Golem. The deployment location is invisible. The experience is universal.

Component library

Design system tokens

Colors

Typography

Spacing

4px base unit. Standard increments: 4, 8, 12, 16, 24, 32, 48, 64.

Mobile considerations

Responsive breakpoints

Cross-references