About Mission Control
Mission Control answers three questions, continuously and for every task at once: what is happening, how long has it been happening, and what came out of it.
The failure it exists to catch is a run that is quietly doing nothing while looking alive.
It is a live operational view by Run: executions and attempts, waits and pauses, change revisions, evidence and reviews, findings, gates, decisions, effects, failures, usage, cost and latency.
It is not a log viewer and not a debugger. It shows state and a short story, never an agent's reasoning and never one line per check.
How it works
Mission Control reads the Log, works out each task's state, and follows new events as they arrive.
- 1
Open
The log server keeps no list of current states, and none is added. So the viewer reads the most recent few thousand events and works out each task's state with the ten-minute rule. A task with nothing in that window shows "no recent report".
- 2
Stay live
The viewer holds one live connection per repository to the log server's live route. It catches up from its last position, then receives each event as it is stored, with no gap and no repeat. If more than a thousand events are waiting, it falls back to paging to resync. Several repositories are merged on one screen.
- 3
Show what the record supports
Each square, state and count on the screen comes from a Log event. Where the Log does not carry a fact, the screen shows less rather than guessing.
With no log server, Mission Control reads the log folder behind the same interface.
The screen
One row per task, in three parts, with counts across the top and a Details window.
| Part | Shows |
|---|---|
| Left, fixed | The task title and kind (from the tracker by task number, or "Task 890" when unavailable), where it runs, on which model, and a Details button |
| Middle, scrolling | A strip of squares, one per actor, in order. See The strip |
| Right, fixed | A small live terminal: the true state, the heartbeat age while running, and short timed lines. Where a person is needed, what to do next |
| Top | Counts: running, needs a person, stopped itself, needs a look, dead, queued. Rows needing a person sort first |
| Details | The story step by step with times, tokens per role where known, time waited on a person, and findings per reviewer by count and severity (never their text) |
The strip
- A Developer square (blue), with code review (orange) and security (purple) stacked beside it.
- Confidence sits above the Developer square, and the round's time below it.
- The icon is the state: done, rejected, working, or needs a person.
- A rejected round is followed by a new round.
- The strip ends in a square saying how it stopped: paused, dead, or ready for review.
Task states
A task is in exactly one state.
| State | Meaning | Decided from |
|---|---|---|
| Running | A runner is alive | The newest report is under ten minutes old and no leaving report is newer |
| Paused | The runner stopped on purpose | Pause and stop reports, with the reason and who acts where the Log carries them |
| Ready for review | The change is up and waiting | A leaving report of "finished". Never shown as merged without a source outside the Log |
| Exited | The runner left | A leaving report: finished, paused, restarted itself, error, or killed by a signal, with the last decision |
| Queued | Planned, nothing begun | The tracker |
| Presumed dead | No report for ten minutes and no leaving report | The ten-minute rule. Shown with its silence stated, never like a pause |
Why a task paused
Mission Control says why a task paused using only what the Log carries.
Where each fact comes from
| On screen | Comes from (Log) | When the Log does not carry it |
|---|---|---|
| Header state, round, phase | dev_review_loop · driver_heartbeat (at most every five minutes) or lifecycle events | — |
| Exit reason, last decision | dev_review_loop · driver_exited, stop_ | Shown verbatim |
| Pause reason, who acts | dev_review_loop · paused, handoff · raised | "Paused" plus the last decision |
| Developer and reviewer squares | dev_review_loop · round_started / round_ended; dispatch · dispatched / outcome_received with the role | — |
| Confidence | The round's gate_result_read | A dash when absent; "n/a" when recorded as unavailable |
| Check or cross per reviewer | The round's approved flag and blocking count | A single "changes requested" mark for the pair, if a blocking finding cannot be attributed to one reviewer's scale |
| Model | dispatch events | Heartbeats do not carry it |
| Tokens | usage · observed | Unknown where the vendor gave none |
| Machine | meta.machine (a hash) | The viewer names each machine once; a short hash until then |
| Title, kind, merged | The tracker and code host | "Task 890" only; never "merged" |
See Events for every field.
When the feed is unavailable
The screen says so, shows its last update time on every row, and stops presenting states as live.
The read credential is never in the page, its storage or its traffic.
Configuration
Mission Control has no keys of its own. It reads the destination in logs: a url with readHeaders, or a folder.
The round cap and time budget come from reviewPolicy. (default 3) and reviewPolicy. (default 180). The opening window and the ten-minute rule are fixed tuning values, not configuration.
What gets logged
Nothing. Mission Control reads the Log and adds no events.