# Mission Control v1 Spec

## Objective
Build a lightweight Mission Control layer on top of the existing OpenClaw workspace so Adner can quickly see agent status, automation status, and operational risk without digging through chat, config, or cron output.

This should be an operations console, not a generic dashboard.

## Why this matters now
Recent pain points already proved the gap:
- model routing was unclear during OAuth vs API switching
- cron jobs were active but not visible in one place
- Gmail watch maintenance required manual checking
- Triad coordination exists, but agent lane/status visibility is fragmented
- there is no simple way to see "what is running, what is broken, what should I do next"

## Recommendation
Start with a narrow v1 that uses the current workspace structure instead of inventing a new app stack.

Best home for v1:
- extend the existing `/dashboard` surface
- pull in existing board + automation data
- add a Mission Control panel focused on control, health, and routing

## v1 modules

### 1. Agent Status Panel
Show the current state of the three assistants:
- Mr Anderson
- Trinity
- Morpheus

Fields:
- name
- lane / role
- host
- service status
- current/expected model
- auth mode if known (OAuth vs API key)
- last active time
- notes / anomalies

Example useful states:
- `Mr Anderson: openai-codex/gpt-5.4, OAuth, healthy`
- `Trinity: claude-sonnet route, auth path unverified`
- `Morpheus: service active, Gmail OAuth needs reauth`

### 2. Model Routing Panel
Purpose: remove ambiguity around which lane is active.

Show:
- default active model
- current live session model
- auth mode
- fallback route
- manual switch options

Desired outputs:
- `Primary: openai-codex/gpt-5.4 (OAuth)`
- `Fallback: openai/gpt-5.4-mini (API)`
- `Heartbeat: xai/grok-4-1-fast-non-reasoning`
- `Voice/TTS: openai tts-1`

This panel should make it obvious when we are on:
- subscription-backed OAuth
- API billing
- fallback/degraded state

### 3. Automation / Cron Panel
Show only important active jobs first.

Priority jobs:
- Session health monitor
- Gmail watch renewal
- Gmail ToAssistant poll
- lossless-claw version check
- any pending reminders tied to live work

Fields:
- job name
- enabled/disabled
- cadence
- last run
- last status
- next run
- delivery mode
- model used (if any)

This creates one place to inspect automations instead of pulling cron listings manually.

### 4. Inbox / Watch Health Panel
Purpose: catch Gmail intake breakage quickly.

Show:
- Gmail watch expiration
- gog-gmail-watch-serve.service status
- last successful renewal
- last known watch label/topic
- alert if service inactive or watch expired

This should reduce invisible intake failure risk.

### 5. Risk / Attention Panel
A small prioritized block at the top.

Examples:
- `TTS key rotated recently, verify voice path`
- `Morpheus Gmail OAuth unresolved`
- `2 pending Monday reminders`
- `Auth route changed to OAuth, API fallback should remain documented`

This should be opinionated and short.

## Data sources for v1
Use existing sources wherever possible:
- `/home/isthekid/.openclaw/workspace/dashboard/data.json`
- `/home/isthekid/.openclaw/workspace/action/data.json`
- `cron list` output via a refresh script
- `session_status`-style runtime checks captured by a small script
- `systemctl --user` checks for local services
- static config reads from `/home/isthekid/.openclaw/openclaw.json`
- optional remote snapshots later for Trinity/Morpheus

## Implementation approach
Do not build a full React app first.

Use the existing dashboard pattern:
1. create a small data-builder script that produces `mission-control.json`
2. extend existing `dashboard/index.html`
3. render a clean executive console with 4 to 5 focused sections
4. keep refresh manual or lightweight at first

## v1 deliverables
- `workspace/dashboard/build-mission-control.py`
- `workspace/dashboard/mission-control.json`
- updated `workspace/dashboard/index.html` with Mission Control section

## What not to do in v1
Avoid these for now:
- full inter-agent chat relay
- auto-remediation actions
- historical analytics
- multi-user auth model
- heavy frontend rebuild
- remote write/control actions to Trinity/Morpheus

## Best first implementation order
1. Model Routing Panel
2. Cron Panel
3. Inbox / Watch Health Panel
4. Agent Status Panel
5. Risk / Attention Panel

## Success criteria
Mission Control v1 is successful if Adner can answer these in under 30 seconds:
- What model am I on right now?
- Am I on OAuth or API billing?
- What are the key cron jobs doing?
- Is Gmail intake healthy?
- Is anything operationally broken or at risk?
- Which assistant should handle which type of work?

## Recommended next move
Implement v1 inside the current `/dashboard` structure, not as a new project.

That gives the fastest path to value and directly addresses the operational ambiguity exposed this week.