voro-dash
The Mission Control dashboard. A Next.js application for agent fleet monitoring, event telemetry visualization, cost tracking, knowledge ops management, and operator workflows.
Purpose
voro-dash is the UI layer for Mission Control. It reads from the shared SQLite database (contract with voro-core), provides real-time event streaming via SSE, and exposes operator workflows for fleet management. It is strictly a presentation layer — the operational backbone lives in voro-core.
Architecture
Tech Stack
- Next.js 15 App Router, React 19, TypeScript 5
- SQLite via better-sqlite3 (WAL mode)
- Zod v4 runtime validation
- vitest for testing
- Port 3900
UI Design
Dark-mode-first interface inspired by Vercel, Linear, and Palantir Gotham:
- Deep space backgrounds (
slate-950), subtle glassmorphism (backdrop-blur-md) - Neon telemetry accents (cyan/emerald/rose) for status indicators
- Clean typography (Inter for UI, JetBrains Mono for data)
- Grid-based layout with KPI cards, telemetry feed, and fleet status panels
Dashboard Zones
| Zone | Components | Purpose |
|---|---|---|
| KPI Row | GlassCard components | Active agents, 24h cost, open remediations, system health |
| Telemetry Feed | Terminal-style event stream | Real-time SSE events with severity badges and JSON detail |
| Fleet Status | Agent cards, cohort lifecycle | Individual agent status and active cohort management |
| Ops Status | Health indicators, alerts | Registry/wiring health, refresh status, alert list |
Shipped Frameworks (F1-F12)
| Framework | Capability |
|---|---|
| F1 | Schema governance + migration runner |
| F2 | Source governance UX (lifecycle controls, telemetry, add/edit sources) |
| F3 | SSE workspace isolation (client/session isolation) |
| F4 | DB workspace isolation (workspace_id on events + agent_status) |
| F5 | OpenClaw skill bridge (deny-list, concurrency cap, trigger parity) |
| F6 | Framework GO gate evaluation |
| F7-F12 | Additional ops automation and operator workflow frameworks |
Operator Workflows (Phase 12)
Full CRUD operator actions for fleet management:
| Route | Purpose |
|---|---|
GET /api/operator/cohorts | Cohort lifecycle snapshot |
POST /api/operator/cohorts/:id/pause | Pause cohort (approval required) |
POST /api/operator/cohorts/:id/resume | Resume cohort (approval required) |
GET /api/operator/recommendations | Recommendation timeline |
GET /api/operator/remediations | Remediation queue |
POST /api/operator/remediations/:id/resolve | Resolve remediation (approval required) |
POST /api/operator/gates/run | Trigger gate check |
GET /api/operator/audit | Audit timeline |
All mutation endpoints require approval metadata (changed_by, reason, approval_ticket).
Knowledge Ops Tooling (Phase 2)
Source governance tools for managing knowledge collections:
| Tool | Purpose |
|---|---|
validate_source_registry.py | Registry schema validation |
route_youtube_video.py | Deterministic YouTube routing |
run_refresh.py | Registry-driven refresh with JSONL telemetry |
schedule_refresh.py | Cadence-based refresh scheduling (daily/weekly/monthly) |
verify_workspace_wiring.py | Dual-layer wiring health check |
source_lifecycle.py | Source state machine (pending → active → paused → archived) |
ops_health.py | Aggregated health check |
refresh_alerts.py | Per-source alert rules |
Ops Status Panel
Wave 1 capabilities (C-01 through C-06):
| Capability | Panel |
|---|---|
| C-01 | Runtime profile presets |
| C-02 | Spawn depth configuration |
| C-03 | Cascade-stop state machine |
| C-04 | Weekly ops checklist (stub) |
| C-05 | Per-source refresh timeline |
| C-06 | Weekly ops summary (4-signal aggregate) |
Key Capabilities
- Real-time telemetry: SSE event stream with workspace isolation
- Fleet monitoring: Agent status, cost tracking, event queries
- Operator workflows: Cohort management, remediation queue, gate checks — all with approval requirements
- Source governance: Full lifecycle management for knowledge collections
- Health monitoring: Aggregated ops health with alert rules and refresh tracking
- Workspace isolation: Both client-side (SSE) and server-side (DB queries) workspace filtering
Database Contract
Source of truth: voro-core/docs/mission-control-contract-v2-schema.sql
Tables: events, cost_rollups, agent_status, ingest_errors, workspaces, pilot_cohorts, recommendation_ledger, pilot_phases, pilot_audit_log
The contract is frozen — no schema changes without updating voro-core first. SQLite is the shared boundary between voro-core (Python writer) and voro-dash (TypeScript reader).
Build & Run
npm install
npm test -- --run # 1,045 vitest tests
PYTHONPATH=. python3 -m pytest tools/ -q # 243 pytest tests
npm run build # Next.js production build
npm run dev # Dev server at port 3900
Current State
- Tests: 1,288 total (1,045 vitest + 243 pytest)
- Frameworks: F1-F12 all COMPLETE (48/48 gate checks passed)
- Shipped: C-01 through C-19, C-31 through C-36
- Status: Stable. Phase 3 data gates not yet met (requires 50 scored predictions + Brier score + profitable paper-trade days).