feat: Mission system — long-running autonomous work with ZeroID mission_id, budgets, and milestones

[saucam]

Summary

Coding agents need a first-class primitive for long-running autonomous work. A Mission wraps one or more sessions with a goal, multi-dimensional budgets, milestone tracking, and periodic reporting. Without this, running an agent autonomously is "fingers crossed" — there are no guardrails, no accountability, and no way to know where it stopped or why.

Background

Inspired by SwarmClaw's mission system and designed around codeoid's identity-first architecture. Crucially, ZeroID plans to add mission_id as a first-class claim in tokens — so a mission's budget enforcement and audit trail can be anchored cryptographically, not just in SQLite.

Proposed Design

Mission lifecycle

```
draft → running → paused → completed | failed | cancelled | budget_exhausted
```

Budget dimensions

```typescript
interface MissionBudget {
maxUsd?: number // USD cost ceiling (from model usage)
maxTokens?: number // total input+output tokens
maxTurns?: number // number of agent turns
maxWallclockSec?: number // wall-clock time limit
maxToolCalls?: number // tool calls across all turns
warnAtFractions?: number[] // e.g. [0.5, 0.8] to emit warnings at 50%, 80%
}
```

Milestone events

`started | budget_warn | budget_hit | check_in | subgoal_done | paused | resumed | completed | failed`

Each milestone has a timestamp, a summary string, and optional evidence (file paths, URLs, tool outputs).

ZeroID integration

When ZeroID adds mission_id to its token schema:

• The session token issued at mission start will carry the mission_id claim
• Sub-agent tokens will inherit mission_id via delegation, making all work attributable to the mission
• Budget enforcement can be done at the ZeroID layer (reject token if budget exhausted) rather than only in daemon-side SQLite checks

Periodic reporting

Missions can be configured to emit a report every N minutes/turns. The report is delivered via whatever frontends are active (Telegram message, web push, future Slack/Discord).

Budget enforcement in session loop

In session.ts, before each query() call, check the mission's current usage against its budgets. On exhaustion: interrupt the session, set mission status to budget_exhausted, emit a final milestone, and notify frontends.

Storage

New SQLite tables in store.ts:

• missions — mission metadata + status + budget config
• mission_events — append-only milestone log
• Session rows gain a nullable mission_id FK

CLI additions

```
codeoid mission create --goal "..." --max-usd 2.00 --max-turns 50
codeoid mission ls
codeoid mission status
codeoid mission pause
codeoid mission resume
codeoid mission destroy
```

Acceptance criteria

• Mission CRUD in SQLite with lifecycle transitions
• Budget checked before every query() turn; session interrupted on exhaustion
• Milestone events written on start/warn/hit/complete/fail
• mission_id carried on session tokens (pending ZeroID schema update)
• Sub-agent tokens inherit mission_id via existing delegation chain
• CLI commands for create/ls/status/pause/resume
• Web UI: mission panel showing status, budget burn, milestone timeline
• Telegram: budget warn and completion notifications delivered to active session subscribers

Related

• ZeroID mission_id claim support (upstream dependency for full cryptographic anchoring)
• Task Board (can feed tasks into missions)
• Schedules (missions can be triggered on a schedule)

[saucam]

Budgets are now a prerequisite of unattended autonomy, not a later phase

Reframed by #275, which amends the conductor design's R5 cost-guard decision.

R5 originally said metrics only for v1 — no hard token budget, no loop cap — on the grounds that the event-driven idle model keeps cost low and the metrics UI gives visibility. That reasoning holds only while every turn is owner-initiated.

The reframe makes the conductor an always-on assistant with scheduled routines (#54) and dispatch authority. A cron-fired job that spawns ship workers can spend real money with nobody watching, and the failure-limit auto-block in dispatch.ts bounds retries per task, not spend per day.

So the budget half of this issue is the gating dependency for #54, and it needs three decisions this issue should record:

1. Scope of the ceiling — per-routine, per-conductor-per-day, or per-tenant?
2. Breach behaviour — pause the routine, alert the owner, or degrade to a cheaper backend? (Degrade is attractive given fleet_spawn already takes provider + model.)
3. The cheap loop guard — a per-instruction bounce cap, which R5 already called a low-cost toggle. Distinct from the spend cap and cheaper to land.

The mission_id and milestone parts of this issue are not blocking anything; the budget part is. Worth splitting if that helps sequencing.