Phase 1 Roadmap — Waves 1–7
The roadmap for Phase 1 (The Hub), organized as waves. Alex paves the backend; Nate wires the frontend. Each wave ships backend work that unblocks frontend work. A wave is a coherent slice — not a time box. Sprints are the time box.
For full architectural context, see the Technical Architecture doc.
Progress
Section titled “Progress”| Wave | Name | Status |
|---|---|---|
| 1 | Foundation & Shared Contract | ✅ Shipped |
| 2 | Brain² (The Memory Spine) | Not started |
| 3 | Conversational Chat Layer | Not started |
| 4 | Agent Runtime & In-App Task Board | Not started |
| 5 | Voice Pipeline | Not started |
| 6 | Meeting Capture | Not started |
| 7 | Migration & Onboarding | Not started |
Wave 1 — Foundation & Shared Contract ✅
Section titled “Wave 1 — Foundation & Shared Contract ✅”Status: Shipped (2026-05-29, 30ffdaa)
Why first: Everything downstream depends on typed contracts and a working API skeleton. Nate can’t build real UI without types and endpoints.
| # | Item | Status | What shipped |
|---|---|---|---|
| 1.1 | Shared types from schema | ✅ | packages/shared/ — constants (all enums from schema), full domain types (Org, Brain2Item, Task, AgentRun, etc.), API contracts (org, profile, keys, credentials, dashboard). |
| 1.2 | API service auth + Supabase client | ✅ | Fastify auth middleware (JWT validation, org membership resolution, AuthContext injection). Admin + per-user Supabase clients in lib/supabase.ts. |
| 1.3 | Org + profile endpoints | ✅ | /v1/org and /v1/profile routes — GET/PATCH org, GET members, GET/PATCH profile. |
| 1.4 | API key management + BYOK | ✅ | /v1/ai-credentials and /v1/api-keys routes. AES-256-GCM encrypted storage. Supports cloud providers (Anthropic, OpenAI, Google) and local models (Ollama, self-hosted) — base_url field + optional api_key added in migration 002_local_model_support.sql. |
| 1.5 | Dashboard data endpoint | ✅ | /v1/dashboard — aggregated org summary, recent activity, member list. |
Unblocks: Settings UI, dashboard shell, org management, user profile. Nate can now build against real typed contracts and live endpoints.
Wave 2 — Brain² (The Memory Spine)
Section titled “Wave 2 — Brain² (The Memory Spine)”Why second: Brain² is the central data layer everything else reads/writes through. Chat feeds it, agents query it, meeting capture populates it.
| # | Item | What ships |
|---|---|---|
| 2.1 | Brain² CRUD API | Create/read/update/delete brain2 items. Filter by tier (hot/warm/cold), project, critical flag. Paginated list + single-item fetch. |
| 2.2 | Brain² search (pgvector) | Semantic search endpoint: text query → embedding → cosine similarity search across warm+cold tiers. Uses vector(1536) with OpenAI text-embedding-3-small. |
| 2.3 | Brain² tier cycling worker | BullMQ background job: evaluates items for demotion (hot→warm→cold) based on project activity, age, access frequency. Critical-flag items skip. Logs every demotion. |
| 2.4 | Brain² re-promote endpoint | One-click re-promote: cold→warm or warm→hot. Reverses auto-demotion. |
| 2.5 | Brain² intake endpoint | Accepts content from other systems (chat auto-route, meeting capture) and classifies into the right tier. |
Unblocks: Brain² UI — the “second brain” view. Search interface. Memory timeline. Hot/warm/cold visualization.
Dependency: Requires Redis + BullMQ for the cycling worker. Set up Redis addon on Railway as part of 2.3.
Wave 3 — Conversational Chat Layer
Section titled “Wave 3 — Conversational Chat Layer”Why third: The chat layer is the primary interaction surface — the main thing users type into. It feeds Brain² (wave 2) and later connects to the agent runtime (wave 4).
| # | Item | What ships |
|---|---|---|
| 3.1 | Conversations + messages API | CRUD for conversations (create, list, get with messages). Message streaming via Supabase Realtime (postgres_changes on messages table). Thread branching (parent_thread_id). |
| 3.2 | Running doc auto-generation | As messages arrive, maintain a concise running doc per conversation. Background job or trigger. |
| 3.3 | Auto-route on close | When conversation is archived/closed/inactive, route the running doc to a destination: Brain² tier, project folder, or task board. Confirmation chip (not a gate). |
| 3.4 | Context-drift detection (v1) | Basic implementation: compute topic embeddings per message window, detect when similarity drops below threshold. Start conservative (explicit cues only). Auto-spawn new thread on drift. |
Unblocks: Chat UI — Claude-style sidebar, conversation history, thread navigation. The “reimagined terminal” is largely this + Brain² rendered in a terminal-like shell.
Wave 4 — Agent Runtime & In-App Task Board
Section titled “Wave 4 — Agent Runtime & In-App Task Board”Why fourth: The agent runtime deploys AI agents against tasks. The in-app task board is where agents and humans collaborate on project work.
| # | Item | What ships |
|---|---|---|
| 4.1 | AgentContract + registry | TypeScript interface for agents (agentType, invoke → AsyncIterable |
| 4.2 | AI gateway (BYOK routing) | Resolve org’s provider credentials, route through Vercel AI SDK, log usage to ai_usage_records. Security boundary — credentials decrypted here only. |
| 4.3 | Single-agent dispatcher | Dispatch an agent against a task. Stream AgentEvents (status_update, task_delta, completion, error) back to the client via SSE. |
| 4.4 | In-app task CRUD | Create/read/update tasks within a project. Three sources: human, auto-extracted, agent-proposed. Assignee, status, project scope. |
| 4.5 | Agent run tracking | Track agent runs: model, tokens, current step, ETA. Attach runs to tasks. Stream progress. |
| 4.6 | Agent completion detection | Agents emit structured task-delta events. On completion, draft one-sentence summary. Flag candidate task completion for human review. |
| 4.7 | Privacy gate | Solo/scratch agent sessions stay private. Only runs explicitly attached to a task surface to the team. |
Unblocks: Agent run UI, task board UI, efficiency lens (per-teammate AI usage), agent output streaming display.
Deferred (add incrementally): Swarm management, swarm-sizing recommendation, board deduplication. Start with single-agent runs.
Wave 5 — Voice Pipeline
Section titled “Wave 5 — Voice Pipeline”Why fifth: Depends on agent runtime (wave 4). Voice is a modality on top of the existing agent + chat infrastructure.
| # | Item | What ships |
|---|---|---|
| 5.1 | TTS engine integration | Select and integrate TTS engine (likely ElevenLabs or OpenAI TTS). Streaming audio output. <500ms first-byte target. |
| 5.2 | Voice turn-taking WebSocket | Persistent WebSocket endpoint for voice sessions. Client sends audio chunks → STT → agent runtime → TTS → client plays audio. Turn-taking protocol. |
| 5.3 | Barge-in handling | Client-side detection of user speaking while agent is outputting. Interrupt agent mid-sentence, restart listening. |
Unblocks: Voice UI — mic button, audio playback, visual turn indicators.
Open question: TTS engine choice. Spike needed before committing.
Wave 6 — Meeting Capture
Section titled “Wave 6 — Meeting Capture”Why sixth: Feeds Brain² and later pitch briefings. Not on the critical path for core hub experience but important for “knows your whole brain.”
| # | Item | What ships |
|---|---|---|
| 6.1 | Meeting capture processor | BullMQ worker: accepts audio/transcript → STT (if audio) → structured summary (action items, decisions, attendees, named-entity tags). |
| 6.2 | Granola integration (if available) | Webhook receiver: Granola sends transcript/summary → store pointer + metadata. Edge Function or API route. |
| 6.3 | Brain² + task board feed | Processed meeting outputs → Brain² warm tier. Action items → task board as proposed tasks. |
Open question: Granola partnership model. Build native fallback first.
Wave 7 — Migration & Onboarding
Section titled “Wave 7 — Migration & Onboarding”Why last in Phase 1: Important for adoption but not for core product experience. Teams can use DREAMTEAM without importing from Notion day one.
| # | Item | What ships |
|---|---|---|
| 7.1 | Notion OAuth flow | OAuth integration for Notion API access. Stored at org level. |
| 7.2 | Structure mapping engine | Map Notion hierarchy → DreamTeam structure. Pages/docs → Brain² (warm/cold). Databases/boards → task board. Teamspaces → workspace structure. |
| 7.3 | Import pipeline worker | BullMQ worker: processes hundreds of pages. Preserves hierarchy, links, properties, assignees. Progress reporting. |
| 7.4 | Re-sync (optional) | Incremental re-sync from Notion until full cutover. Conflict resolution if both sides edited. |
Unblocks: Migration UI — connect Notion, pick what to import, progress display, mapping review.
Cross-cutting (frontend, depends on waves 1–4)
Section titled “Cross-cutting (frontend, depends on waves 1–4)”| Item | Depends on |
|---|---|
| Reimagined Terminal shell | Waves 1–3 (needs chat + brain2 APIs) |
| Dashboard with real data | Wave 1 (dashboard endpoint) |
| Brain² UI (memory view) | Wave 2 (brain2 API) |
| Chat UI (sidebar, threads) | Wave 3 (chat API) |
| Agent run + task board UI | Wave 4 (agent + task API) |
| Voice UI | Wave 5 (voice pipeline) |
| Meeting capture UI | Wave 6 (capture API) |
| Migration/onboarding UI | Wave 7 (migration API) |