# Atlas — Status Report: Kade Build + Jarvis Bolt-On Scope

**To:** Larry / Jimmie
**From:** Atlas
**Date:** 2026-05-22
**Re:** (1) Kade build status, (2) Jarvis-style interface bolt-on feasibility

---

## Part 1 — Kade build status (priority)

### Where things actually stand (today)

**Built so far: ~0%.** Only artifact in `Team/Kade/` is `profile.md`. Nothing has been merged into the Atlas DB or app.

Specifically, on my side:
- ❌ No migration file for Kade tables (no `tasks`, `reminders`, `meds`, `meds_log`, `lists`, `dnd_windows`, `habit_streaks`)
- ❌ No `/kade` route in the Next.js app (no UI, no list view, no entry form)
- ❌ No API endpoints (`/api/kade/*`)
- ❌ No project-linking glue (the Kade profile says tasks must link to existing `projects` table — that wiring doesn't exist)
- ❌ No Slack bot scaffold inside the Atlas app

On Riv's side (per `C:\PKA\Team\Riv\j2_qbo_mcp\`):
- ❌ No Slack listener / event subscriber
- ❌ No `/remind` integration
- ❌ No custom scheduler for DND-aware delivery, kick-in-the-pants logic, medication-time fires
- ❌ No voice-memo → transcript pipeline

Riv's last 14 days have been the QBO MCP server (queue, worker, Sheet setup, Afton cleanup). My last 14 days were the continuity-system (projects table, events API, day-2 progress, AP/Tally seed) — that work IS the prerequisite Kade depends on for project-linking, so it wasn't wasted, but it means Kade itself hasn't moved.

### What's blocking

Honestly: **nothing technical.** This is calendar capacity. Both Riv and I had higher-priority pre-commits running into the Kade hire date (5/21) and neither of us reshuffled. No spec was written, no kickoff happened.

Secondary issue: **Slack workspace + bot install** isn't confirmed yet. I don't know if Jimmie already has a J2 Slack workspace where Kade should live, or if we're standing one up. That decision blocks Riv's piece.

### Split of work — my piece vs. Riv's

**My (Atlas) piece — backend/DB/UI:**
1. Schema migration: `kade_tasks`, `kade_reminders`, `kade_meds`, `kade_meds_log`, `kade_lists`, `kade_dnd_windows` (+ FKs to `projects` and `clients` where applicable)
2. API: CRUD endpoints + the query verbs Kade actually uses (`top_3`, `today_max_8`, `list_from_hell`, `overdue`, `due_this_week`, `med_adherence_window`)
3. Web UI under `/kade`: today view, list-from-hell view, meds log, DND controls (mostly for Jimmie's audit/override, not Kade's primary surface)
4. Internal HTTP API that Riv's scheduler + Slack bot call

**Riv's piece — Slack + scheduling:**
1. Slack bot install + event subscription (read DMs from Jimmie)
2. LLM call to interpret natural-language inputs ("shut up till 10pm", "X is done", "remind me about Y at Z")
3. Custom scheduler daemon: medication fires, deadline kick-in-the-pants, DND windows, recurring habit reminders
4. Voice-memo transcript → task pipeline (Whisper or similar on the Slack file upload)
5. Slack message composition in Kade's voice (LLM call with profile.md as system prompt)

### Realistic ship date

**Burn-in CANNOT start 5/21 as the memory implies.** The 2-week burn-in clock starts when there's a working v1, and there is no v1.

Phased estimate (assuming Riv and I both have ~50% of our calendar for this):

| Phase | What ships | My days | Riv days | Calendar |
|---|---|---|---|---|
| **v0.1 — Meds only** | Slack bot fires 3 medication reminders/day with non-shaming follow-up; logs to DB | 1.5 | 2.5 | **5 calendar days** → live ~**2026-05-27** |
| **v0.2 — Capture + Top 3** | "Remind me about X at Y" / "X is done" / "Give me my list" work end-to-end | 2 | 3 | +1 week → live ~**2026-06-03** |
| **v0.3 — DND + deadline logic** | "Shut up till 10pm" honored, 7d/1d/day-of kick-in-the-pants, recurring habits | 1.5 | 2.5 | +1 week → live ~**2026-06-10** |
| **v1.0 — Burn-in start** | Voice memo capture, list-from-hell command, pattern detection on missed meds | 2 | 2 | +5 days → **burn-in begins ~2026-06-15** |
| **v1.0 → Qordinate retires** | 2-week burn-in window | — | — | **Qordinate retires ~2026-06-29** |

**Bottom-line ship dates:**
- First reminder fires through Kade: **~5/27**
- Burn-in starts: **~6/15**
- Qordinate retires: **~6/29**

That's ~5 weeks later than the implied 6/4 retirement, and I want to flag that honestly rather than promise something we'll miss. If you want to compress this, the lever is meds-only goes live in 3-4 days and Qordinate stays running for everything else through the burn-in.

### Recommended next moves

1. **Jimmie confirms Slack workspace** (existing J2 workspace or new one) — unblocks Riv day 1
2. **I write the migration file this week** and seed Jimmie's meds, his hard-fenced clients, and known recurring habits from `profile.md`
3. **Riv stands up the bare Slack bot** that can DM Jimmie and read his replies
4. **Phase v0.1 (meds-only) ships in 5 days** as the first real Kade artifact

If that plan is acceptable I can start the migration today.

---

## Part 2 — Jarvis-style interface: bolt-on sketch

Scoping only — not a build plan.

### The honest gap

Pax is giving you the greenfield gold-standard view. I'm telling you what's achievable bolted onto the existing Atlas stack with stuff that already works.

### What we already have that helps

- **Next.js app on port 3000** (PM2-managed, prod stable)
- **Postgres DB** with projects, clients, tags, team, triage, doc
- **Existing chat infra**: `components/chat/*` (ChatArea, AgentSidebar, MessageInput), `lib/chat-runner.ts`, `app/api/chat-send/route.ts`
- **Per-agent routing** already exists at `app/team/[agentId]/page.tsx` — the slash-command roster is already represented in the app
- **Soon: Slack bot infra for Kade** (Riv's piece, above) — reusable as a routing surface

The slash-command roster (Larry → 17 specialists) IS the orchestration layer already. We don't need to rebuild it; we need a voice frontend that emits utterances into it.

### Minimum viable bolt-on (call this "Jarvis Lite")

**New routes:**
- `/hud` — full-screen page with mic button, waveform viz, current-agent badge, response transcript
- `/api/voice/stt` — server-side endpoint that takes an audio blob, returns text (proxies to a cloud STT)
- `/api/voice/route` — takes text, picks an agent (LLM classifier with the 17-agent roster as the prompt), returns `{agentId, prompt}`
- `/api/voice/tts` — takes text, returns audio stream (proxies to a cloud TTS)
- Streaming response via Server-Sent Events to `chat-runner.ts`

**Frontend stack inside the existing Next.js app:**
- Browser `MediaRecorder` API for capture (no extra deps)
- Web Audio API for the waveform
- Push-to-talk first (spacebar held), not wake word — sidesteps the hardest engineering problem
- `<audio>` tag for TTS playback
- Tailwind/shadcn HUD overlay; can be a separate Electron window later but ship it as a browser tab first

**STT/TTS choice for v1:**
- STT: Deepgram or OpenAI Whisper API (cloud, 300-600ms latency, no local model to maintain)
- TTS: ElevenLabs streaming API (best-in-class naturalness, ~400ms first-audio latency)
- Both cloud, both ~$0.01-0.03 per minute. Trade money for not standing up local models.

**Orchestration:**
- Reuse `lib/chat-runner.ts` — it already knows how to invoke an agent by ID
- Add a thin classifier in front: "Given this utterance and the roster of 17 agents, which one handles it? Return JSON `{agentId, refinedPrompt}`." One Sonnet call. ~500ms.
- The orchestration LIVES in the existing slash-command layer. No new router needed for v1.

**Realistic v1 effort:** 4-6 days of focused work for me, alone. No new dependencies on Riv. Latency budget: ~2-3s end-to-end (mic stop → first TTS audio). Not Jarvis-snappy. **Usable, demoable, hands-free.**

### What v1 won't have (and the gap to "full Jarvis")

Pax's report will lay these out properly; this is the bolt-on view of what we'd be skipping:

| Capability | Jarvis Lite (v1 bolt-on) | Full Jarvis | Gap |
|---|---|---|---|
| Wake word | None — push-to-talk | "Hey [name]" always-on | +1-2 weeks (Porcupine/OpenWakeWord + native listener daemon) |
| STT latency | 300-600ms cloud | <150ms local Whisper streaming | +1 week (local Whisper.cpp, audio chunking, partial transcripts) |
| TTS latency | 400ms cloud first-audio | <100ms with streaming + caching | +3-5 days (Kokoro/Piper local, voice cloning if you want a specific timbre) |
| Multi-agent routing | One Sonnet classifier call | Streaming intent classification with confidence + fallback | +1 week (fine-tuned router, fallback chains, "I'm not sure — did you mean X or Y?") |
| HUD | Next.js tab in browser | Always-on-top native Windows overlay | +1-2 weeks (Electron or Tauri wrapper, system tray, global hotkey) |
| Multi-turn / interruption | Single turn, no barge-in | Mid-response interruption, context window across turns | +1 week (VAD, interruption handling, turn-taking state machine) |
| Memory of last N turns | Whatever chat-runner already does | Per-session conversational memory + cross-session continuity | already partially there via Atlas DB |

**Total gap to full Jarvis: ~5-8 weeks of voice/multimodal engineering on top of the 4-6 days for Jarvis Lite.**

### Build-effort gap summary

- **Voice frontend on the existing DB:** 4-6 days, my time only, cloud STT/TTS, push-to-talk. Demoable.
- **Full Jarvis:** add ~5-8 weeks for wake word, local low-latency STT, native overlay, intent classifier upgrade, barge-in. Whether that effort is worth it depends entirely on whether push-to-talk actually annoys you in daily use.

### My recommendation

Ship Jarvis Lite first as a Phase 0 of any voice initiative. It uses parts you already have, takes a week, and gives you a real artifact to react to. You'll know within two days of using it whether the wake-word + native-overlay upgrade is worth the 5-8 week investment, or whether push-to-talk is actually fine.

The thing that kills voice projects is going for the full Jarvis on day 1, hitting an integration wall at week 3, and shelving the whole thing. Bolt-on first, gold-standard second.

---

## Status — both reports

✅ Kade build status — delivered above; realistic ship date 6/15 burn-in start, 6/29 Qordinate retire
✅ Jarvis bolt-on sketch — delivered above; v1 is 4-6 days of my time on existing infra

**Awaiting from Jimmie:**
1. Slack workspace decision (Kade phase 1 unblock)
2. Go/no-go on Kade phased plan above
3. Go/no-go on Jarvis Lite as Phase 0 (separate decision; not coupled to Kade)