Missions Workflow

Overview

Missions are the highest-level unit of work in tmux-ide. A mission defines what you are building, milestones gate progress into phases, and the orchestrator dispatches tasks to specialized agents automatically.

This page walks through the full lifecycle: pre-planning, planning, execution, validation, and completion.

Scaffolded Directory Structure

Running tmux-ide init --template missions creates the following project structure:

your-project/
├── ide.yml                          # tmux-ide layout config
├── .tasks/
│   ├── tasks.json                   # Mission, milestones, goals, and tasks
│   └── validation-contract.md       # Assertion definitions (VAL-XXX)
├── .tmux-ide/
│   ├── skills/
│   │   ├── frontend.md              # Skill prompt for frontend agents
│   │   ├── backend.md               # Skill prompt for backend agents
│   │   ├── reviewer.md              # Skill prompt for the validator
│   │   └── researcher.md            # Skill prompt for the researcher
│   └── library/
│       ├── architecture.md          # Repo-wide context injected into every dispatch
│       ├── learnings.md             # Appended automatically as tasks complete
│       └── research-findings.md     # Accumulated research output
└── AGENTS.md                        # Project boundaries and rules for every agent

The ide.yml produced by the missions template gives you this layout:

┌───────────┬───────────┬───────────┐
│           │           │           │
│   Lead    │ Frontend  │  Backend  │  70%
│           │           │           │
├───────────┼───────────┼───────────┤
│ Validator │ Researcher│   Shell   │  30%
└───────────┴───────────┴───────────┘

Phase 1: Pre-Planning

Before creating the mission in tmux-ide, the lead prepares the shared knowledge that agents will rely on.

Define the mission scope

Decide what the mission delivers, what is in scope, and what is explicitly out of scope. Write this down in plain language -- it becomes the mission description.

Write the validation contract

Create .tasks/validation-contract.md with concrete, testable assertions. Each assertion gets a unique ID that tasks will reference later.

# Validation Contract — Auth v2

## Authentication

- **VAL-AUTH-001**: POST /api/auth/login returns a JWT on valid credentials
- **VAL-AUTH-002**: POST /api/auth/login returns 401 on invalid credentials
- **VAL-AUTH-003**: POST /api/auth/refresh returns a new access token given a valid refresh token
- **VAL-AUTH-004**: Protected routes return 403 when the JWT is expired

## Test Coverage

- **VAL-TEST-001**: Unit tests cover all auth service functions with >90% line coverage
- **VAL-TEST-002**: Integration tests exercise the full login-refresh-logout flow

Update architecture.md

Add relevant context to .tmux-ide/library/architecture.md so dispatched agents understand the codebase they are working in.

# Architecture

## Stack

- Next.js 14 (App Router)
- Drizzle ORM + PostgreSQL
- JWT via jose library

## Key Paths

- `src/app/api/auth/` — auth route handlers
- `src/lib/auth/` — token creation, validation, refresh logic
- `src/middleware.ts` — route protection

## Conventions

- All API routes return `{ data }` or `{ error }` JSON envelopes
- Tests live next to source files as `*.test.ts`

Phase 2: Planning

Mission status: planning

Create the mission

tmux-ide mission set "Auth v2" --description "JWT login, token refresh, route protection, and full test coverage"

Create milestones

Milestones are sequential gates. M1 must complete before M2 starts.

tmux-ide milestone create "Foundation" --sequence 1
tmux-ide milestone create "Implementation" --sequence 2
tmux-ide milestone create "Validation & Polish" --sequence 3

Create tasks

Each task belongs to a milestone and can declare which validation assertions it fulfills, what specialty it needs, and what goal it serves.

# M1 — Foundation
tmux-ide task create "Set up auth database schema" \
  --milestone M1 \
  --specialty backend \
  --priority 1 \
  --goal "Establish the data layer for auth"

tmux-ide task create "Create JWT utility functions" \
  --milestone M1 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-AUTH-001,VAL-AUTH-003" \
  --goal "Token creation and validation helpers"

# M2 — Implementation
tmux-ide task create "Build login endpoint" \
  --milestone M2 \
  --specialty backend \
  --priority 1 \
  --fulfills "VAL-AUTH-001,VAL-AUTH-002" \
  --goal "POST /api/auth/login with JWT response" \
  --depends "001,002"

tmux-ide task create "Build refresh endpoint" \
  --milestone M2 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-AUTH-003" \
  --goal "POST /api/auth/refresh with token rotation" \
  --depends "002"

tmux-ide task create "Add route protection middleware" \
  --milestone M2 \
  --specialty backend \
  --priority 3 \
  --fulfills "VAL-AUTH-004" \
  --goal "Middleware that rejects expired or missing JWTs"

tmux-ide task create "Build login page" \
  --milestone M2 \
  --specialty frontend \
  --priority 2 \
  --goal "Login form that calls the auth API"

# M3 — Validation & Polish
tmux-ide task create "Write unit tests for auth service" \
  --milestone M3 \
  --specialty backend \
  --priority 1 \
  --fulfills "VAL-TEST-001" \
  --goal "Unit test coverage for all auth functions"

tmux-ide task create "Write integration tests for auth flow" \
  --milestone M3 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-TEST-002" \
  --goal "End-to-end login, refresh, and logout test" \
  --depends "007"

Check coverage

Before leaving planning, verify that every assertion in the validation contract is claimed by at least one task.

tmux-ide validate coverage

Validation Coverage Report
──────────────────────────
VAL-AUTH-001  ✓  Covered by: 002, 003
VAL-AUTH-002  ✓  Covered by: 003
VAL-AUTH-003  ✓  Covered by: 002, 004
VAL-AUTH-004  ✓  Covered by: 005
VAL-TEST-001  ✓  Covered by: 007
VAL-TEST-002  ✓  Covered by: 008

Coverage: 6/6 assertions covered (100%)

If any assertion is uncovered, create additional tasks before proceeding.

Activate the mission

tmux-ide mission plan-complete

This transitions the mission from planning to active, locks all milestones except M1, and the orchestrator begins dispatching.

Phase 3: Execution

Mission status: active

Once the mission is active and you launch the session with tmux-ide, the orchestrator takes over.

How dispatch works

On each tick (default every 5 seconds), the orchestrator:

1. Identifies idle agent panes (any pane that is not the lead and is not currently working)
2. Picks the highest-priority unblocked task in the current active milestone
3. Prefers panes whose specialty matches the task's --specialty
4. Builds a full context prompt from the mission description, milestone context, goal, task details, the agent's skill file, and the knowledge library
5. Sends the prompt to the idle agent via tmux send-keys

What agents receive

Each dispatched agent gets a prompt containing:

• Mission: title, description, and current status
• Milestone: which phase this task belongs to
• Goal: the high-level objective the task serves
• Task: title, description, dependencies, and fulfillment targets
• Skill: the contents of .tmux-ide/skills/<specialty>.md
• Library: architecture.md, learnings.md, AGENTS.md

Task completion

When an agent finishes, it reports back:

tmux-ide task done 003 \
  --proof "Login endpoint implemented. Returns JWT on valid creds, 401 on invalid. Tests in src/app/api/auth/login/route.test.ts" \
  --summary "Implemented POST /api/auth/login using jose for JWT signing. Passwords verified with bcrypt. Response shape: { data: { accessToken, refreshToken, expiresIn } }"

The --proof explains what was done and how to verify it. The --summary is appended to learnings.md so subsequent agents benefit from the knowledge.

Monitoring progress

tmux-ide mission status          # Mission overview with milestone progress
tmux-ide metrics                 # Task counts, completion rate, time estimates
tmux-ide metrics agents          # Per-agent utilization and task history
tmux-ide orch                    # Live orchestrator state (agents, queue, events)

Phase 4: Validation

Milestone status: validating

Validation happens automatically when all tasks in a milestone complete.

Automatic validator dispatch

When the last task in a milestone is marked done, the orchestrator:

1. Transitions the milestone status to validating
2. Dispatches the validator agent with the validation contract and all assertion IDs that belong to this milestone
3. The validator reads the contract, inspects the code, runs tests, and checks each assertion

Reporting assertions

The validator reports the status of each assertion:

tmux-ide validate assert VAL-AUTH-001 --status passing \
  --evidence "POST /api/auth/login returns { accessToken, refreshToken } on valid credentials. Verified via integration test."

tmux-ide validate assert VAL-AUTH-002 --status passing \
  --evidence "POST /api/auth/login returns 401 with { error: 'Invalid credentials' }. Verified via integration test."

tmux-ide validate assert VAL-AUTH-003 --status failing \
  --evidence "Refresh endpoint exists but does not rotate the refresh token. Old token remains valid after refresh."

When all assertions pass

If every assertion for the milestone passes:

1. The milestone status moves to done
2. The next milestone in sequence is unlocked and set to active
3. The orchestrator begins dispatching tasks from the new milestone

When an assertion fails

If any assertion fails:

1. The orchestrator auto-creates remediation tasks targeting the failing assertions
2. The milestone status resets to active
3. The remediation tasks are dispatched like any other task
4. When they complete, the milestone returns to validating and the validator runs again

# Example: orchestrator auto-creates a remediation task
# Task 009: "Fix refresh token rotation (remediation for VAL-AUTH-003)"
#   --milestone M2 --specialty backend --fulfills "VAL-AUTH-003" --priority 1

Viewing validation state

tmux-ide validate report

Validation Report
─────────────────
Milestone: M2 — Implementation

VAL-AUTH-001  ✓ passing   Login returns JWT on valid creds
VAL-AUTH-002  ✓ passing   Invalid creds return 401
VAL-AUTH-003  ✗ failing   Refresh token not rotated
VAL-AUTH-004  ✓ passing   Expired JWT returns 403

Status: 3/4 passing — remediation in progress

Phase 5: Mission Completion

When the final milestone's validation passes and all milestones are done, the mission is complete.

What happens automatically

1. The mission status transitions to complete
2. The orchestrator stops dispatching
3. The lead is notified of completion
4. Final metrics are recorded

Optional: create a pull request

If your workflow ends with a PR, you can create one from the shell:

gh pr create --title "Auth v2" --body "JWT login, refresh, route protection, and full test coverage"

Review the final state

tmux-ide mission status
tmux-ide validate report
tmux-ide metrics history

Quick Reference

Tips

• Write the validation contract first. It forces clarity about what "done" means before any code is written.
• Use --fulfills on every task. Uncovered assertions are a planning gap that validate coverage will catch.
• Keep milestones small (3-7 tasks). Large milestones delay validation feedback.
• Add --depends between tasks that have real ordering constraints, but avoid over-constraining -- the orchestrator handles priority and specialty matching.
• Check tmux-ide metrics agents to spot agents that are idle or overloaded, and adjust specialties if needed.
• The knowledge library is cumulative. Task summaries in learnings.md help later agents avoid re-discovering the same patterns.

End-to-end walkthrough: ship an auth system

This walkthrough takes you from an empty repo to a merged pull request for a JWT-based auth system, with three Claude agents collaborating autonomously under one tmux session. Every command below is real and runs against the v2.5.0 CLI.

The mission has three milestones:

Once the lead types tmux-ide mission plan-complete, the orchestrator does the rest: dispatch, retry-with-backoff, validation, auto-remediation, milestone advancement, and the final pull request.

Step 1 — Scaffold the project

From the repo root:

tmux-ide init --template missions

This writes ide.yml, .tasks/validation-contract.md (empty stub), .tmux-ide/skills/*.md, and .tmux-ide/library/architecture.md. Open ide.yml and confirm the layout — the missions template ships with a six-pane grid:

┌───────────┬───────────┬───────────┐
│           │           │           │
│   Lead    │ Frontend  │  Backend  │  70%
│           │           │           │
├───────────┼───────────┼───────────┤
│ Validator │ Researcher│   Shell   │  30%
└───────────┴───────────┴───────────┘

The pane roles are not cosmetic. The orchestrator reads role, specialty, and skill from every pane to decide who gets which task:

panes:
  - title: Lead
    command: claude
    role: lead
    focus: true
  - title: Frontend
    command: claude
    role: teammate
    specialty: frontend
  - title: Backend
    command: claude
    role: teammate
    specialty: backend
  - title: Validator
    command: claude
    role: validator
    skill: reviewer
  - title: Researcher
    command: claude
    role: researcher
    skill: researcher

Note orchestrator.master_pane: Lead in the generated config — the lead pane is excluded from auto-dispatch so it remains a planning surface, never a worker.

Step 2 — Pre-planning artifacts

Before any mission state exists, the lead fills in the two files that every dispatched agent will see.

.tasks/validation-contract.md — the acceptance test plan:

# Validation Contract — JWT Auth

## Authentication

**VAL-AUTH-001**: POST /api/auth/login returns 200 + JWT on valid credentials
**VAL-AUTH-002**: POST /api/auth/login returns 401 on invalid credentials
**VAL-AUTH-003**: POST /api/auth/refresh issues a new access token and rotates the refresh token
**VAL-AUTH-004**: Protected routes return 403 when the access token is expired

## Tests

**VAL-TEST-001**: Unit tests cover all auth service functions with >=90% line coverage
**VAL-TEST-002**: Integration test exercises login → refresh → protected request → logout

.tmux-ide/library/architecture.md — codebase context injected into every dispatch:

# Architecture

## Stack

- Next.js 15 (App Router) on Node 22
- Drizzle ORM + PostgreSQL
- `jose` for JWT signing, `argon2` for password hashing

## Key paths

- `src/app/api/auth/` — route handlers
- `src/lib/auth/` — token + password helpers
- `src/middleware.ts` — bearer-token route protection

## Conventions

- Routes return `{ data }` or `{ error }`; never raw values
- Tests colocate as `*.test.ts` next to source

See validation-contracts for the full assertion-ID convention and per-domain prefixes (VAL-AUTH-, VAL-API-, VAL-DATA-, …).

Step 3 — Launch the session

tmux-ide

All six panes boot. The lead pane sits idle, waiting for you. The other five Claude panes are also idle — but they will not act until a mission is active and tasks exist.

Step 4 — Create the mission

In the lead pane (or any shell with the project cwd):

tmux-ide mission create "Ship JWT auth" \
  --description "Implement JWT login, refresh-with-rotation, and route-protection middleware. Cover with unit + integration tests. No frontend work in this mission."

Verify:

tmux-ide mission show

Mission:      Ship JWT auth
Status:       planning
Description:  Implement JWT login, refresh-with-rotation, ...
Milestones:   0
Tasks:        0

While status: planning, the orchestrator will not dispatch — this is the safe space to lay out milestones and tasks.

Step 5 — Create milestones

Milestones are ordered gates. With dispatch_mode: missions in ide.yml (the missions template default), only the lowest-sequence active milestone is eligible for dispatch.

tmux-ide milestone create "Foundation"     --sequence 1
tmux-ide milestone create "Endpoints"      --sequence 2
tmux-ide milestone create "Tests"          --sequence 3

tmux-ide milestone list

M1  Foundation   sequence=1  status=planning
M2  Endpoints    sequence=2  status=planning
M3  Tests        sequence=3  status=planning

Step 6 — Create tasks against M1, M2, M3

Every task is bound to a milestone, gets a priority, and — most importantly — declares which validation assertions it --fulfills. The validator uses these links to know which assertions to run after the milestone closes.

M1 — Foundation:

tmux-ide task create "Add users + sessions schema" \
  --milestone M1 \
  --specialty backend \
  --priority 1 \
  --goal "Persist user credentials and refresh-token sessions"

tmux-ide task create "JWT sign/verify helpers" \
  --milestone M1 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-AUTH-001,VAL-AUTH-004" \
  --goal "Pure functions for access + refresh token lifecycle"

M2 — Endpoints:

tmux-ide task create "POST /api/auth/login" \
  --milestone M2 \
  --specialty backend \
  --priority 1 \
  --fulfills "VAL-AUTH-001,VAL-AUTH-002" \
  --depends "001,002" \
  --goal "Verify credentials with argon2, return access + refresh tokens"

tmux-ide task create "POST /api/auth/refresh with rotation" \
  --milestone M2 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-AUTH-003" \
  --depends "002" \
  --goal "Rotate refresh token on every use; revoke old session row"

tmux-ide task create "Bearer-token route middleware" \
  --milestone M2 \
  --specialty backend \
  --priority 3 \
  --fulfills "VAL-AUTH-004" \
  --depends "002" \
  --goal "Reject expired/missing tokens with 403"

M3 — Tests:

tmux-ide task create "Unit tests for auth service" \
  --milestone M3 \
  --specialty backend \
  --priority 1 \
  --fulfills "VAL-TEST-001" \
  --goal ">=90% line coverage on src/lib/auth/"

tmux-ide task create "Integration: login→refresh→protected→logout" \
  --milestone M3 \
  --specialty backend \
  --priority 2 \
  --fulfills "VAL-TEST-002" \
  --depends "003,004,005" \
  --goal "End-to-end flow with a real Postgres test container"

Verify coverage before activating:

tmux-ide validate coverage

Validation Coverage Report
──────────────────────────
VAL-AUTH-001  ✓  Covered by: 002, 003
VAL-AUTH-002  ✓  Covered by: 003
VAL-AUTH-003  ✓  Covered by: 004
VAL-AUTH-004  ✓  Covered by: 002, 005
VAL-TEST-001  ✓  Covered by: 006
VAL-TEST-002  ✓  Covered by: 007

Coverage: 6/6 assertions covered (100%)

If anything reads Uncovered, create more tasks before moving on — mission plan-complete will refuse to advance otherwise.

Step 7 — Activate the mission

tmux-ide mission plan-complete

This single command does four things:

1. Transitions mission status: planning → active.
2. Normalizes milestones so only M1 becomes active; M2 and M3 stay planning (locked).
3. Unlocks the orchestrator's dispatch loop on the next tick (default 5s).
4. Emits a mission.activated event onto the SSE stream consumed by the dashboard.

Within seconds you will see the Backend pane wake up. The orchestrator dispatched task 001 (the schema) — the highest-priority unblocked task in M1, matched against specialty: backend.

Step 8 — Watch the orchestrator work

The orchestrator runs in the daemon and ticks every orchestrator.poll_interval ms. On every tick it:

1. Reads pane state from the live tmux session (idle vs working heuristic).
2. Refreshes the task store and filters to the active milestone.
3. Skips tasks that are blocked (unmet --depends) or scheduled for future retry (nextRetryAt > now).
4. Picks the highest-priority remaining task and finds an idle pane, preferring a specialty match.
5. Builds a prompt containing mission, milestone, goal, task, the matching skill file, and the library files (architecture.md, learnings.md, AGENTS.md).
6. Sends the prompt to the pane with tmux send-keys and records a dispatch ID.

Monitor live:

tmux-ide orch

Mission: Ship JWT auth      status=active
Milestone: M1 Foundation    status=active   tasks=2/2 dispatched

Agents
  Lead       idle (master)
  Frontend   idle
  Backend    working  → 002 JWT sign/verify helpers   (4m12s)
  Validator  idle
  Researcher idle
  Shell      n/a

Recent events
  10:02:17  agent.dispatched   002 → Backend
  10:01:55  task.completed     001 (Add users + sessions schema)
  10:01:55  agent.dispatched   001 → Backend

If an agent goes silent past stall_timeout (default 5 minutes), the orchestrator emits an agent.stalled event and nudges the pane. If the agent reports back with --status review instead of done, the orchestrator treats it as a failure, schedules a retry with exponential backoff (10s → 20s → 40s …, capped at 5 min), and increments retryCount. After 5 attempts, the task drops to a hand-off file in .tasks/dispatch/retry-exhausted-<id>.md and the lead is notified.

Step 9 — Tasks complete with proof

When a backend agent finishes task 002, it reports back:

tmux-ide task done 002 \
  --proof '{"tests":{"passed":18,"total":18},"notes":"jose-based signer; helpers exported from src/lib/auth/jwt.ts"}' \
  --summary "Token helpers use HS256 with 15m access / 7d refresh. Refresh tokens are opaque and stored hashed (argon2id) in the sessions table."

The --proof is structured JSON (tests, ci, pr, notes — all optional). The --summary is appended to .tmux-ide/library/learnings.md, so the next agent dispatched against M2 will see "Token helpers use HS256 …" in its prompt and won't re-derive that decision.

Task 001 likewise completes with proof. The orchestrator detects that all M1 tasks are done and flips the milestone:

milestone.status_changed   M1 Foundation: active → validating

Step 10 — Auto-validation

milestone.status_changed → validating triggers an automatic dispatch to the Validator pane. The validator receives:

• The validation-contract file.
• The list of assertion IDs claimed by tasks in M1 (VAL-AUTH-001, VAL-AUTH-004 — others belong to M2/M3).
• The skill prompt from .tmux-ide/skills/reviewer.md.
• The accumulated learnings.md.

It runs tests, inspects code, then writes back one validate assert per assertion:

tmux-ide validate assert VAL-AUTH-001 --status passing \
  --evidence "jwt.test.ts: sign() + verify() round-trip green; 18/18 in src/lib/auth/__tests__/"

tmux-ide validate assert VAL-AUTH-004 --status passing \
  --evidence "expired-token test: verify() throws TokenExpiredError; middleware will translate to 403 in M2"

When the validator finishes:

• Every M1 assertion is passing → M1: validating → done, M2: planning → active, and the orchestrator immediately starts dispatching task 003 (POST /login).
• Any assertion is failing → auto-remediation (next step).

Step 11 — Failed assertion → auto-remediation

Fast forward to M2. The Backend agent ships task 004 (refresh endpoint) and marks it done. The Validator runs and reports:

tmux-ide validate assert VAL-AUTH-003 --status failing \
  --evidence "Refresh endpoint mints a new access token but does NOT rotate the refresh token — old refresh token still valid after use."

The orchestrator's validation handler sees failing and runs the remediation path:

1. Creates a new high-priority task tagged remediation, fulfilling the failing assertion(s):

   Task 008  "Fix VAL-AUTH-003: rotate refresh token on use"
     milestone=M2  specialty=backend  priority=1  fulfills=VAL-AUTH-003  tags=[remediation]

2. Emits a remediation event into the event log.

3. Sets the milestone back to active so the new task is eligible for dispatch on the next tick.

On the next tick, the Backend pane picks up task 008 and works the fix. Once it's done, the milestone flips back to validating; the Validator re-runs only the previously failing assertions (VAL-AUTH-003), confirms passing, and M2 advances to done. M3 unlocks.

You did nothing. The lead pane was idle through the whole loop.

Step 12 — Mission complete + auto PR

When the last assertion in M3 passes:

1. M3: validating → done.
2. All milestones are done → mission.status: active → complete.
3. If gh is available on PATH and the project is a git repo, the orchestrator calls createMissionPr(...). It pushes the current branch (if needed) and runs gh pr create with a body composed from the mission description, every milestone, and a summary of each task's proof.
4. The PR URL is written to .tasks/dispatch/mission-complete.md and the lead pane gets a nudge: Mission complete: "Ship JWT auth". Run: tmux-ide dispatch mission-complete.
5. A mission_complete event lands on the SSE stream, and the dashboard's Mission view renders the completion banner with the PR link.

Inspect the final state:

tmux-ide mission status
tmux-ide validate report
tmux-ide metrics history

Mission:       Ship JWT auth        status=complete
Milestones:    M1 done  M2 done  M3 done
Validation:    6/6 passing
PR:            https://github.com/acme/api/pull/482
Wall time:     1h 47m (auto-dispatch on)
Agent hours:   3h 21m across Backend + Validator

Open the PR, review the diff, merge. The mission's audit trail — every dispatch, every retry, every assertion transition, the remediation event — lives in .tasks/events.jsonl and is queryable via tmux-ide orch --json.

Where to watch from

The dashboard at http://localhost:6061 mirrors the same state the CLI exposes, with three views you'll keep open during a mission:

Mission view

Route: /project/<name> (the default landing) — renders MissionControlView, the same surface used for both Mission and Mission Control tabs.

Use it for:

• The current mission title, description, and planning | active | complete status.
• Per-milestone progress bars with task counts (5/7 done).
• Live validation summary: how many assertions are passing, failing, blocked, pending.
• The agent grid — each pane's role, specialty, and current task title; idle panes are dimmed.
• An event feed of agent.dispatched, task.completed, milestone.status_changed, remediation, and mission_complete events, updated over SSE.

Callout: when a milestone flips to validating, the Validator card lights up and you can watch its prompt land in real time without opening the tmux window.

Tasks view

Mounted via mountTasksView from v2-solid-widgets. Switch to it via the project sidebar (Tasks icon) or by adding a type: tasks widget pane to ide.yml.

Use it for:

• The full task list, filterable by milestone (M1, M2, M3) and status (todo, in-progress, review, done).
• One-click drill-down into each task to see priority, dependencies, --fulfills assertion IDs, proof JSON, and the agent that worked it.
• Spotting blocked tasks — anything with unmet --depends is rendered with a chain icon and lists the blocking task IDs.
• Manual overrides: claim, reassign, or mark done from the UI if you need to intervene.

Callout: remediation tasks created by the orchestrator are tagged remediation and rendered with a red badge so you can audit the validator's history at a glance.

Chat view

Route: /project/<name> then the Chat tab. Each Claude pane has a chat stream backed by the daemon's event bus; the Chat view multiplexes them with a per-pane sidebar.

Use it for:

• The Lead chat — the planning and supervision surface. Add ad-hoc questions ("why did the validator mark VAL-AUTH-003 failing?") and the lead can read events, files, and the .tasks directory to answer without disturbing the workers.
• Per-teammate streams — read what the Backend agent is currently doing, including its full prompt (mission + milestone + skill + library + task) and its responses.
• The Validator stream — see the exact validate assert calls before they hit the CLI and confirm the evidence text is meaningful.

Callout: streams are virtualized (@tanstack/solid-virtual) so long-running missions with thousands of messages stay smooth. Use Cmd+P to quickly jump between panes without leaving the chat surface.

Together, Mission tells you where the mission is, Tasks tells you what each agent is doing and why, and Chat tells you what they are actually saying. The CLI (tmux-ide orch, tmux-ide mission status, tmux-ide validate report) gives you the same data in any shell that has the project cwd, including the Shell pane inside the session itself.