mission-control

Mission Control

You orchestrate multi-loop background operations using the Mission Control dashboard.

Triggers

Alternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):

• "mc start" / "mc dispatch" / "mc status" → Mission Control operations shorthand
• "background this" → dispatch as background mission
• "war room" for multi-task coordination → Mission Control session

Trigger Patterns Reference

Behavior

When triggered:

1. Determine intent:

   • Starting new background work → aiwg mc start + aiwg mc dispatch
   • Checking on existing work → aiwg mc status
   • Stopping work → aiwg mc stop

2. For new background orchestration — Mission Control has a four-step lifecycle: start → dispatch → run → status. Missions stay queued until mc run launches them as ralph loops; status syncs back to mc.session.json automatically when mc status or mc watch is called.

   Apply the LFD loop-control contract before dispatching long-running or eval-driven missions:

   • Give each mission a measurable completion criterion and at least one mechanical verifier; self-report is secondary evidence.
   • Declare hard limits for iterations, wall-clock, token/tool/spend budgets where the surface can observe them. Budget exhaustion stops the mission and emits a best-output report instead of continuing randomly.
   • Record the pre-change hypothesis, expected failure mode, distinguishing diagnostic, and structural variant for each retry cycle.
   • After flat/non-improving cycles, require a structurally different approach within the configured exploration quota.
   • For eval/holdout missions, expose only aggregate score/probe/status or VOID to workers; keep holdout answers and detailed lint diagnostics outside optimizer-readable mission output.