Design brief for the interactive real-time dashboard. Built for Claude design tools (Claude Artifacts, v0, etc.) to flesh out visually. All data sources documented. Architecture proven on calendar card.
Mark's #1 trust signal is seeing the neural stack grow. Right now he gets Notify alerts (numbers, not visual) and a static HTML page that only updates when a deploy runs. He can't tell at a glance whether the system is alive, whether OMI is feeding data, or whether ingestion actually happened today. The live dashboard solves all of this.
TP2 had a dashboard concept that never shipped. TP3 has the data. The Cloudflare KV + Worker pattern (already proven with the calendar card) makes a live dashboard fast to build and free to run.
↓ This is a design mockup — shows shape and data, not final visual style
Steps · Sleep · Energy burned · O₂ sat · Source: Google Drive Health Connect exports
Live from Cloudflare KV — refreshed daily at 6:30 AM by Apps Script
| Panel | Data Source | How to get it | Freshness |
|---|---|---|---|
| TP3 row count | Postgres tp3_metadata |
SSH → SELECT COUNT(*), MAX(ingest_time) FROM tp3_metadata via scheduled Apex script → push to KV |
Every 15 min |
| Daily delta | Same table, date filter | WHERE ingest_time > now()-'1 day' |
Every 15 min |
| Last ingest time | MAX(ingest_time) |
Same query, derived field | Every 15 min |
| Ingest stream (live feed) | Postgres recent rows | SELECT source, snippet, row_count FROM tp3_metadata ORDER BY ingest_time DESC LIMIT 10 → KV |
Every 5 min |
| Stack health | Docker API / health endpoints | Apex PowerShell: docker ps --format json + curl each /health → KV JSON |
Every 2 min |
| OMI memories count | OMI API | GET api.omi.me/v2/memories?limit=1 → total count in header → KV |
Every 30 min |
| OMI today's conversations | OMI API | GET api.omi.me/v1/conversations?date=today → KV |
Every 30 min |
| Health stats | Google Drive Health Connect CSVs | Drive MCP → read latest CSV → parse → KV | Daily (when Drive syncs) |
| Calendar | Google Calendar API | Apps Script → CalendarApp → KV (already built) | Daily at 6:30 AM |
| Ollama status | Ollama API | curl.exe http://localhost:11434/api/ps → KV |
Every 5 min |
| Phase | What ships | Est. time | Status |
|---|---|---|---|
| 0 (done) | Calendar card via KV Worker | — | LIVE |
| 1 | TP3 row count + last ingest + stack health — 4 KPI cards + health table | 3–4h | NEXT |
| 2 | Ingestion stream feed (last 10 rows with source + snippet) | 2h | QUEUED |
| 3 | OMI activity card (daily conversation count + top tags) | 2h | QUEUED |
| 4 | Health stats graphs from Drive CSVs | 3h | QUEUED |
| 5 | Interactive query — text box → TP3 semantic search → results | 4–6h | FUTURE |
Hand this document to a design tool with: "Build a dark-mode real-time personal AI dashboard based on this spec. Use the panel layout in Section 2. Data values are fake but the labels and structure are final. Make it visually impressive — gradients, animated status indicators, smooth sparklines."
TP2's dashboard concept never shipped because TP2's Chroma backend couldn't serve fast queries at scale. TP3 runs Postgres — COUNT(*) on 641K rows takes under 10ms. The KV layer means the Worker never hits Postgres directly; it just reads a pre-computed blob. This is how it ships this time.