You are implementing Echodo's automation foundation. Read docs/adr-model-routing.md
before touching model routing code. This repo uses pnpm, Drizzle, tRPC, zod in
packages/shared, and multitenancy via workspace_id on every tenant table.
Dogfooding (required for every task in this plan):
1. At session start: call MCP claim_task with this task's backlogItemId (import
plans/ if the row is missing).
2. At session end: call MCP complete_task with outcome, tokensTotal, and
modelAlias/modelTier when you used a routed model.
3. Stay within the task's acceptance criteria; do not widen scope.
4. Run pnpm lint && pnpm type-check && pnpm test before declaring done.
Stack: Next.js App Router, packages/database for schema, apps/web for UI.
Never store API keys in committed files or DB — only api_key_env_var names.
---
# Plan overview
Echodo is evolving from a multitenant task app with MCP coordination into **mission control** for an agent pipeline: fleet view, human gates, per-role model routing, and (later) a built-in orchestrator and worker. This plan delivers the **first concrete slice** — the model provider registry and role routing system defined in [docs/adr-model-routing.md](../../docs/adr-model-routing.md).
Epics 1–6 and the mission-control UI are **shipped**. Epic 7 (worker) is **in progress** — skeleton exists in `apps/worker`. Epics 8–9 remain draft with decomposed tasks. Follow-on tasks from the [Autensa benchmark](#autensa-benchmark-2026-08) are injected into epics 1, 3, 5, 6, 7, 8, and 9 (concepts only — no OpenClaw dependency).
| `.convoys/model-routing-registry.md` | **Created at kickoff** via `role-conductor` — tracks IA/UX/architecture for the initiative (not stored under `plans/`) |
| `model_policy` in convoy | Dogfoods alias-based routing (Claude planning, Qwen local) once registry exists |
| `scripts/log-convoy-event.sh` | Log each role completion to `.convoys/.metrics.jsonl` when L3 convoy scaffolding is present |
**Kickoff ritual (human + conductor):**
1. Prompt: *"Start a new convoy: Implement workspace-scoped model provider registry and role routing per docs/adr-model-routing.md. Success = operators can configure Anthropic + Ollama aliases and assign them to pipeline roles from Settings."*
3. Architect decomposes into briefs that **map 1:1 to tasks in `Epic-model-provider-registry`** (below).
4. Each implementer session: `claim_task` on the matching `Task-*.md` → implement → `complete_task`.
## Getting started (operator checklist)
Do these **before or in parallel with** Epic 1 implementation. Nothing here blocks writing code; some items unblock dogfooding and `testProvider` against real endpoints.
### A. Repo and backlog (one time)
- [ ]`pnpm install` at repo root
- [ ]`.env` from `.env.example` — `DATABASE_URL`, `REDIS_URL`, `NEXTAUTH_*` at minimum
- [ ]`pnpm db:migrate` if schema is behind
- [ ]`pnpm --filter @tasks/database import:markdown-backlog` — loads `plans/Plan-automation-foundation/**` into DB for `claim_task`
- [ ] Confirm Echodo MCP in `.cursor/mcp.json` works (restart Cursor after MCP changes)
### B. Local inference on Mac (pick one or both)
See ADR § **Local MLX on Apple Silicon** and **Local Ollama**.
| Goal | Action |
|------|--------|
| Simplest local coder | Install [Ollama](https://ollama.com), `ollama pull qwen2.5-coder:32b`, listen on LAN if Coolify must reach Mac |
| Best Apple Silicon perf / MLX models | `pip install mlx-openai-server` (preferred if you expect **parallel implementers**), launch with `--host 0.0.0.0` |
| Quick MLX smoke test | `pip install mlx-lm` → `mlx_lm.server --model mlx-community/...` on port 8080 |
Note your Mac LAN IP and port for registry aliases later (`http://<ip>:8000/v1` or `:11434/v1`).
### C. Cloud / free-tier aliases (optional until Epic 1 UI exists)
Configure env vars on the machine that runs `apps/web` / worker (Coolify or local):
-`ANTHROPIC_API_KEY` — planning roles (or use NIM/Gemini free tier per ADR references)
Sequential order with parallel opportunities noted. **Current focus: Epic 7** (worker end-to-end dogfood), then Epic 8 → 9. Follow-on tasks on done epics can run in parallel when they do not block the critical path.
| [Epic-optional-orchestrator](../Plan-agent-coordination/Epic-optional-orchestrator/Epic-optional-orchestrator.md) | **Superseded in intent** by Epic 6 here — richer spec, Echodo-native, no Symphony dependency |
| Agent-pipeline v0.4 Phase 2a | Epic 4 implements the MCP tools described there |
| Agent-pipeline v0.4 Phase 4 workers | Out of scope until Epic 8+; drift/rollup is a future Plan, not this roadmap |
### End-state (what “done” looks like for the full plan)
Operator opens Echodo fleet view → starts convoy chat → hits **Go** → orchestrator runs pipeline roles with per-role models → worker executes briefs against connected repos → gates surface in inbox with AI co-pilot → approve → repeat until `released`. Live activity feed, spend rollups, and PR recovery are visible without leaving mission control.
### Autensa benchmark (2026-08)
Studied [crshdn/mission-control](https://github.com/crshdn/mission-control) (Autensa) as a UX/reliability benchmark — **not** as a runtime dependency. Ideas mapped to tasks:
