Parallel Mission Control: ten agents built the read-only cockpit that watches ten agents
How DalkkakAI's Parallel Mission Control subsystem (work units mc01–mc10) was built as a local-first, read-only coordination cockpit for parallel AI-agent worktrees — and which parts are wired versus still scaffolding.
When you run a wave of AI agents in parallel — each in its own git worktree, each on its own branch, each dropping a *-result.md — the bottleneck stops being the agents and becomes you, the human captain trying to track ten dirty trees, ten result docs, and the collisions between them. Parallel Mission Control is the subsystem built to be that cockpit. Fittingly, it was itself built by a parallel wave: ten work packets, mc01 through mc10, each landing on 2026-06-17 (see git log from 34d3d03 add read-only mission control scanner through a88ac9a persist mission control registry).
The founding design (mc01, docs/product/parallel-agent-mission-control-implementation-plan-2026-06-17.md) drew a hard line: local-first, no cloud worker fleets, no provider API calls, and crucially no auto-merge to main. Every later packet inherited that constraint, which is why the running result is a board you read, not a robot that merges for you.
The implementation splits cleanly across two homes. Pure decision logic lives in @ddalkkak/shared as side-effect-free TypeScript: missionControlRegistry.ts (the durable run model), missionControlResultInbox.ts (a deterministic Markdown parser for result docs — no LLM), verificationEvidence.ts + missionControlVerificationRunner.ts (a planning-only runner that classifies commands against a narrow allowlist and converts approved text to argv arrays, but marks even allowlisted commands blocked until explicit confirmation), and missionControlMergeQueue.ts (a review-lane model whose doNotAutoMergePolicy.allowed is permanently false). The git-touching side is a single read-only Rust file, apps/desktop/src-tauri/src/parallel_mission.rs, which shells git in argument-array form (rev-parse, worktree list, status, diff, rev-list) — never mutating the repo.
The central technical decision was conservatism as a safety property: unknown stays unknown. The inbox parser refuses to fabricate a card from an unreadable result doc; the merge queue blocks any worker missing a result doc or passing verification; the runner never passes a shell string. A test-fixture bug in mc02 (apps/web/src/App.tsx not flagged as a shared hub) was fixed by routing the test through the production shared-hub classifier rather than duplicating it — the kind of small correctness call that keeps a coordination tool trustworthy.
On wiring, honesty matters. This is not an orchestration-orphan: all four Tauri commands (parallel_mission_scan, parallel_mission_registry_read, parallel_mission_registry_refresh_from_scan, parallel_mission_registry_update_worker) are registered in lib.rs:2260–2263, and MissionControlPanel.tsx is mounted from StartupView.tsx:516. The panel really renders scanner metrics, a Result Inbox, a Verification Checklist, a Merge Queue lane, and registry-backed worker actions (refresh-from-scan, save captain note, mark reviewing/ready/blocked), persisting to .dalkkak/mission-control/registry.json.
What is still scaffolding, stated plainly: there is no dispatch, no merge, no arbitrary command execution — the panel header literally says so. The Decision Gate is a visible placeholder; GraphStore emission is explicitly not added; mc06's missionControlLearning.ts is exported from @ddalkkak/shared but has zero app-code references — an orphaned helper awaiting an inbox surface. And across nearly every packet, the live Tauri GUI smoke was described but never run — automated panel and Rust tests cover the wiring, but a human still owes it one click-through.