{"id":"50ff7b5a-08b4-4ea3-8570-1fe829014e44","slug":"missioncontrol","kind":"skill","name":"MissionControl","summary":"Control plane for human-directed, agent-executed software delivery—with governed execution, verification, evidence, and human-approved pull requests.","owner":"jaydubya818","repoUrl":"https://github.com/jaydubya818/MissionControl","license":"MIT","licenseTier":"permissive","trust":"community","stars":2,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-02-01T20:53:34.000Z","addedAt":"2026-10-21T08:18:02.177Z","logoUrl":"https://avatars.githubusercontent.com/u/50925625?u=0908f44787b94b9f5ac3d5824f3706796058541c&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools"],"tags":["agent-orchestration","ai-agents","autonomous-agents","developer-platform","evaluation","governance","llm","software-factory"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-25T23:54:17.789Z","sample":false,"url":"https://conduits.dev/tools/missioncontrol","language":"TypeScript","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# Mission Control\n\n**The governed control plane for human-directed, agent-executed software\ndelivery.**\n\nHumans define intent and retain authority. Coding agents perform bounded work.\nDeterministic systems enforce scope, policy, verification, currentness, and\nevidence before a change becomes eligible for human acceptance.\n\n[![CI](https://github.com/jaydubya818/MissionControl/actions/workflows/ci.yml/badge.svg)](https://github.com/jaydubya818/MissionControl/actions/workflows/ci.yml)\n[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)\n[![Status: active V1](https://img.shields.io/badge/status-active%20V1-orange.svg)](#project-status-and-proof)\n[![Built with TypeScript](https://img.shields.io/badge/TypeScript-3178C6?logo=typescript&logoColor=white)](https://www.typescriptlang.org/)\n\n![Mission Control Command Center showing portfolio metrics and ranked exceptions](docs/software-factory/screenshots/readme/mission-control-command-center.png)\n\nMission Control is not another coding agent and it is not a chat wrapper. It is\nthe durable authority and evidence layer above coding agents, execution\nharnesses, repositories, CI systems, and deployment tooling.\n\nIts purpose is simple:\n\n> Turn approved software intent into independently verified, review-ready pull\n> requests without giving agents authority to approve their own work.\n\n## Contents\n\n- [Why Mission Control exists](#why-mission-control-exists)\n- [What Mission Control is](#what-mission-control-is)\n- [Operating principles](#operating-principles)\n- [The governed delivery lifecycle](#the-governed-delivery-lifecycle)\n- [Who owns each decision](#who-owns-each-decision)\n- [Core capabilities](#core-capabilities)\n- [Operator experience](#operator-experience)\n- [System architecture](#system-architecture)\n- [Project status and proof](#project-status-and-proof)\n- [Current limitations](#current-limitations)\n- [Quickstart](#quickstart)\n- [Software Factory demo](#software-factory-demo-local-end-to-end)\n- [Development and verification](#development-and-verification)\n- [Security model](#security-model)\n- [Repository map](#repository-map)\n- [Documentation](#documentation)\n\n## Why Mission Control exists\n\nAI-assisted development starts as a one-to-one interaction: a developer asks an\nagent to make a change, watches it work, and reviews the result. That model stops\nscaling when one operator is responsible for many agents, repositories, branches,\nplans, retries, and release decisions.\n\nAt fleet scale, code generation is not the hardest problem. Coordination and\ntrust are.\n\nWithout a control plane:\n\n- prompts drift away from the approved outcome;\n- agents receive broad, ambient permissions;\n- multiple workers collide on repositories and branches;\n- retries consume time and money without a bounded recovery policy;\n- worker completion is mistaken for verified success;\n- evidence becomes stale while optimistic status labels remain green;\n- operators reconstruct decisions from chat transcripts and raw logs; and\n- a process restart or agent handoff destroys operational context.\n\nMission Control addresses those failures with versioned intent, explicit\nauthority, immutable execution Attempts, independent verification, exact\nrepository lineage, durable state, and exception-first operator workflows.\n\n**A chat interface scales conversations. Mission Control scales governed work.**\n\n## What Mission Control is\n\nMission Control coordinates three distinct layers:\n\n| Layer | Primary responsibility | Must not decide alone |\n| --- | --- | --- |\n| **Coding agent** | Execute one bounded task, use admitted tools, report events, and produce artifacts | Product intent, its own authority, independent verification, acceptance, merge, or release |\n| **Software Factory** | Freeze the repository, workflow, executor, policy, budget, verifier, and recovery contract used to produce a candidate | Whether the business outcome is worth pursuing or whether its own output is acceptable |\n| **Mission Control** | Coordinate Missions and Factories, enforce governance, retain lineage, route attention, and present evidence | Product judgment, risk acceptance, or irreversible decisions reserved for people |\n\nThe Factory is the production system for one repository and one exact\nconfiguration. Mission Control is the portfolio-level operating system that lets\na human direct many governed Factories without supervising every agent action.\n\nMission Control is deliberately **not**:\n\n- an autonomous software executive;\n- a general-purpose multi-agent chat application;\n- a replacement for GitHub, CI, or code review;\n- a model leaderboard that can bypass security eligibility;\n- a test runner whose green result silently authorizes a merge;\n- an agent-activity dashboard optimized for messages, tokens, or generated code;\n- a self-modifying system that can promote its own policies or workflows; or\n- a claim of production operation at hundred-agent or enterprise-fleet scale.\n\n## Operating principles\n\nThe product is built around a small set of non-negotiable rules.\n\n### Intent over activity\n\nThe primary object is the desired outcome, not an agent session, chat message,\ntoken count, or generated task list.\n\n### Exceptions over feeds\n\nDefault operator surfaces prioritize decisions, blockers, failed or stale\nevidence, unsafe conditions, and aging work. Routine activity remains available\nfor inspection without competing for attention.\n\n### Evidence over assertions\n\nA worker report or `COMPLETED` status is not proof. Completion requires\nsource-linked artifacts and independently produced evidence against the approved\nacceptance criteria.\n\n### Durable state over conversation\n\nIntent, plans, decisions, execution state, events, artifacts, receipts, and\napprovals survive context limits, process restarts, retries, model changes, and\nagent handoffs.\n\n### Policy before autonomy\n\nRepository scope, identity, tools, secrets, capabilities, risk, budgets, and\nrecovery limits are resolved before execution begins. Unknown or stale authority\nfails closed.\n\n### Independent validation\n\nThe actor that produced a material change cannot be the sole authority that\ncertifies it.\n\n### One authoritative lifecycle\n\nMission, Plan, WorkOrder, Task, Attempt, evidence, pull request, acceptance,\nmerge, deployment, and production verification remain separate states. No lower\nstate silently completes its parent.\n\n## The governed delivery lifecycle\n\nThe authoritative hierarchy is:\n\n```text\nCompany\n└── Workspace\n    └── Repository\n        ├── Project Constitution revision\n        ├── Active Factory version\n        └── Mission\n            └── Mission Spec revision\n                └── Approved Plan + Quality Contract\n                    └── WorkOrder\n                        └── Task\n                            └── Attempt / WorkflowRun\n                                ├── frozen execution manifest\n                                ├── Attempt-bound Context Package\n                                ├── ordered events and artifacts\n                                └── immutable candidate\n\nCandidate → Verification Subject → frozen Verification Plan\n          → independent verifier Attempt → evidence and receipt\n          → Quality Gate Decision → exact-current pull request\n          → authorized human acceptance\n\nPull Request → Merge → Deployment → Activation → Production Verification\n```\n\nThe same system can be summarized at two levels:\n\n- **Builder loop:** `Intent → Plan → Configure agents, harnesses, skills, and tools → Execute → Verify and evaluate → Deliver → Observe → Improve`\n- **Governed delivery lifecycle:** `Mission → approved Plan → WorkOrder → Task → Attempt → candidate → independent evidence → pull request → human decision → release → observed outcome → governed learning`\n\nEach arrow is a gate, not an optimistic handoff.\n\n| Stage | What happens | What it does not authorize |\n| --- | --- | --- |\n| **Define** | A human records the desired outcome, business reason, constraints, scope, risks, stop condition, and acceptance criteria | Planning or execution |\n| **Specify** | Immutable Mission Spec and Project Constitution revisions make requirements attributable and testable | Plan approval |\n| **Plan** | An agent or operator proposes a versioned implementation plan, dependencies, WorkOrder blueprints, validation assertions, budget, and rollback approach | WorkOrder release or dispatch |\n| **Approve** | An authorized human approves one exact Plan revision and its compiled Quality Contract | Agent execution |\n| **Release** | Mission Control materializes governed WorkOrders idempotently from the approved Plan | Dispatch or acceptance |\n| **Preflight** | Repository identity, code scope, Factory version, executor capability, host health, policy, credentials, capacity, and budget are checked | Bypassing a failed or unknown readiness check |\n| **Execute** | An admitted harness performs a bounded Attempt under a fenced lease in a local worktree or approved remote sandbox | Self-verification, publication, or acceptance |\n| **Recover** | Failures are classified; immutable retries use a new Attempt; recovery is bounded by policy and budget | Repeating failed work indefinitely |\n| **Verify** | A separate verifier evaluates the exact immutable candidate against a frozen Verification Plan and records criterion-level evidence | WorkOrder acceptance or merge |\n| **Publish** | A candidate-bound permit and short-lived GitHub App credential create or reconcile an exact-current pull request | Merge or release |\n| **Accept** | An authorized human reviews the evidence package and accepts, rejects, or requests revision | Automatic merge or deployment |\n| **Learn** | Accepted evidence may become advisory signals, experiments, and improvement proposals | Automatic policy, workflow, or repository mutation |\n\nThe distinction is intentional:\n\n```text\nexecution completed ≠ verification passed\nverification passed ≠ exact-current gate eligible\ngate eligible ≠ WorkOrder accepted\nWorkOrder accepted ≠ pull request merged\npull request merged ≠ production verified\n```\n\n## Who owns each decision\n\nMission Control separates judgment, execution, and enforcement.\n\n| Actor | Owns | Cannot independently do |\n| --- | --- | --- |\n| **Human operator** | Intent, Plan approval, risk decisions, acceptance, merge, release, and waivers within assigned authority | Bypass server-side policy or invent missing evidence |\n| **Planning agent** | Repository research, implementation options, risk identification, and proposed Plans | Approve its Plan or dispatch consequential work |\n| **Execution harness** | Bounded code changes and structured result production inside one frozen Attempt | Expand scope, verify itself, publish, accept, merge, or deploy |\n| **Worker runtime** | Admission, leasing, heartbeats, execution coordination, candidate collection, and recovery | Grant itself broader authority or accept output |\n| **Independent verifier** | Execute the frozen Verification Plan against the exact candidate and produce evidence | Change the candidate, publish it, or accept the WorkOrder |\n| **GitHub App publisher** | Publish an exact permitted candidate with a short-lived installation token | Verify, accept, merge, or deploy |\n| **Deterministic control plane** | Identity, policy, budgets, digests, currentness, isolation, state transitions, and authority gates | Replace product judgment or silently waive a failed gate |\n| **Memory, observability, and learning systems** | Advisory context, diagnostics, traces, scores, signals, and proposals | Gain execution, verification, acceptance, or promotion authority |\n\nHuman approval is not a decorative UI state. It is a server-enforced authority\nboundary. Passing execution and verification only make a WorkOrder eligible for\nacceptance; they do not accept it.\n\n## Core capabilities\n\n### Governed Mission intake and planning\n\n- Versioned Missions, Mission Specs, Project Constitutions, and Plans.\n- Structured outcomes, constraints, non-goals, repository scope, risks, budgets,\n  stop conditions, and measurable acceptance criteria.\n- Deterministic Spec Quality checks for ambiguity, placeholders, contradictions,\n  testability, scope, and evidence coverage.\n- Human-readable Plan submission, rejection, revision, approval, and immutable\n  lineage.\n- Idempotent compilation of an approved Plan into Quality Contracts and\n  WorkOrders.\n\n### Repository and Factory control\n\n- Explicit `Company → Workspace → Repository → Code Scope` ownership.\n- Portable repository identity separate from a developer's local checkout.\n- Versioned Factory definitions binding repository, harness, workflow, policy,\n  model route, budgets, sandbox profile, and verifier configuration.\n- Evidence-based readiness checks before activation and dispatch.\n- Repository classification as `PUBLIC`, `INTERNAL`, `CONFIDENTIAL`, or\n  `RESTRICTED`, with fail-closed remote-execution policy.\n\n### Context and Skills admission\n\nMission Control includes 70 repository-local skills: nine native control-plane\nintegration skills and 61 vendored from\n[`jaydubya818/skillz`](https://github.com/jaydubya818/skillz) at a pinned source\nrevision. For non-trivial work, agents start with `mission-control-delivery`;\n`poteto-mode` then selects the smallest applicable workflow and specialist set.\nSee the [skill catalog](docs/skills/skillz-catalog.md) for provenance, licensing,\nupdate policy, and verification commands.\n\n- Versioned Factory configurations bind the exact capability manifest, runtime\n  artifact, sandbox profile, execution backend, and producer and verifier\n  Execution Profiles used by an Attempt.\n- Readiness is derived from current repository, worker, runtime, policy, and\n  qualification evidence; it is not an operator-set status.\n- Producer completion yields an immutable candidate without granting\n  verification, acceptance, publication, merge, or deployment authority.\n- A separate verifier Attempt evaluates a frozen Verification Subject and Plan,\n  with stale authority, changed candidates, and self-verification failing closed.\n\n### Durable execution and recovery\n\n- Attempt-scoped immutable execution manifests.\n- Atomic worker claims, fenced leases, heartbeats, capacity admission, and stale\n  owner recovery.\n- Repository and worktree ownership with collision prevention.\n- Local persistent-worker and bounded Remote Sandbox backends.\n- Immutable retry, cancellation, failure, and recovery history.\n- Structured run events, tool calls, artifacts, changed-file records, and cost\n  observations.\n\n### Verification-first delivery\n\n- Machine-readable Quality Contracts compiled from exact approved Plan intent.\n- Immutable candidate identity and Verification Subject digests.\n- Separate verifier Attempts with frozen Verification Plans.\n- Criterion-level evidence with verifier identity, environment, subject,\n  freshness, and currentness.\n- Fail-closed handling for missing, failed, stale, conflicting, or unknown\n  evidence.\n- Quality Gate Decisions that cannot be manufactured by the producing worker.\n\n### Exact pull-request lineage\n\n- GitHub App installation readiness and least-privilege publication identity.\n- Candidate-bound publication permits.\n- Just-in-time installation tokens that are not persisted in delivery records.\n- Exact repository, branch, commit, candidate, pull-request head, check, and\n  evidence correlation.\n- Signed webhook ingestion, replay protection, and visible uncorrelated evidence\n  rather than guessed lineage.\n- Human merge remains separate from Mission Control's V1 acceptance boundary.\n\n### Advisory intelligence\n\n- Factory Memory retrieves attributable context and freezes a minimal Context\n  Package onto an exact Attempt.\n- Observability and Evals retain traces, observations, datasets, experiments,\n  and diagnostic scores without gaining acceptance authority.\n- Factory Learning converts evidence into signals, clusters, controlled\n  experiments, and proposed improvements.\n- Improvement promotion returns through a new Mission and human-approved Plan.\n\n### Operator control\n\n- Exception-first Command Center for blocked work, pending decisions, failed\n  evidence, risk, and aging.\n- Mission and WorkOrder workspaces with explicit next actions.\n- Approval packets that show authority, scope, policy, evidence, and the effect\n  of the decision.\n- Task and Attempt inspection, verification traces, immutable retry history, and\n  recovery controls.\n- Audit history for lifecycle changes, decisions, denials, policy evaluations,\n  and release activity.\n\n## Operator experience\n\nMission Control is designed for a developer becoming an operator of multiple\nconcurrent delivery streams. The default experience answers:\n\n- What outcome matters most right now?\n- Which work is blocked and what exact decision will unblock it?\n- Which worker may change which repository and code scope?\n- What changed relative to the approved Plan?\n- Which acceptance criteria passed, failed, became stale, or were waived?\n- How much execution, retry, time, and cost budget remains?\n- Can the work be paused, cancelled, retried, or recovered safely?\n- What is actually ready for review, acceptance, merge, or release?\n\n### Command Center\n\nThe Command Center ranks operator attention by risk, urgency, age, and evidence\nstate instead of presenting a wall of agent activity.\n\n![Mission Control Command Center showing portfolio metrics and ranked exceptions](docs/software-factory/screenshots/readme/mission-control-command-center.png)\n\n### WorkOrders\n\nWorkOrders turn approved intent into governed delivery contracts. Operators can\ninspect scope, risk, assignment, approval, execution, verification, and the next\nvalid action without reconstructing state from logs.\n\n![Mission Control Work Orders showing approval, verification, and dispatch state](docs/software-factory/screenshots/readme/mission-control-work-orders.png)\n\n### Audit and evidence\n\nThe audit surface retains approvals, denials, lifecycle changes, deployment\nevents, and policy decisions so agent-executed work remains explainable after the\nfact.\n\n![Mission Control audit surface showing change and approval records](docs/software-factory/screenshots/readme/mission-control-audit.png)\n\nPrimary V1 operator routes include:\n\n| Route | Operator job |\n| --- | --- |\n| `/v2/command-center` | Triage decisions, blockers, risk, and delivery attention |\n| `/v2/missions` | Define outcomes and manage Mission planning |\n| `/v2/mission-detail` | Inspect Plan, WorkOrders, execution, evidence, and acceptance |\n| `/v2/factory` | Select a governed recipe and inspect recent Factory execution |\n| `/v2/control-work-orders` | Govern, dispatch, verify, and accept WorkOrders |\n| `/v2/tasks` | Inspect operational Tasks and Attempts |\n| `/v2/projects` | Configure workspaces, repositories, code scopes, GitHub App readiness, and Factory versions |\n| `/v2/trace-inspector` | Inspect execution trees, timelines, observations, evals, and datasets |\n| `/v2/memory` | Inspect provenance-backed Memory, graph data, and Context Packages |\n| `/v2/audit` | Review decisions, denials, policy outcomes, and lifecycle history |\n\nPreview and Demo routes are explicitly labeled and can be hidden. A component\ndoes not become a production feature merely because it exists in the codebase.\n\n## Eval integrity\n\nMission Control includes a receipt-first Eval Control Plane for measuring the\ngoverned software-factory path without granting evals authority to approve,\nmerge, release, or accept work.\n\n- **Sealed cases.** Candidate adapters receive public probes, never assertions\n  or negative controls.\n- **Fail-closed accounting.** Missing, duplicate, skipped, malformed, or\n  harness-invalid cases cannot be reported as passing.\n- **Reproducible receipts.** Every run binds its suite, baseline, revision,\n  adapter, dataset, configuration, seed, timestamps, costs, and artifact hashes.\n- **Tamper resistance.** Every golden case has a deliberately degraded negative\n  control that CI must detect.\n- **Honest status.** Blocking regressions fail the receipt; advisory evidence\n  gaps remain visible instead of being averaged away.\n\nThe V1 Mission Control golden suite currently reports **6/6 blocking cases**,\n**7/7 negative controls**, and **zero baseline regressions**. Cost and token\nattribution remains an explicit advisory gap, so the receipt is truthfully\n`WARN` and publication-eligible rather than a misleading perfect score.\n\n```bash\npnpm run eval:mission-control\n```\n\nOperators can inspect receipts under **Intelligence → Observability & Evals →\nEval library**. See the [architecture](docs/architecture/eval-control-plane-v1.md)\nand [browser evidence](docs/testing/evidence/eval-control-plane-v1/README.md).\n\n## System architecture\n\n```mermaid\nflowchart TB\n    UI[\"React operator UI\"] -->|\"typed queries and mutations\"| CX[\"Convex control plane\"]\n    CLI[\"mc CLI\"] --> CX\n\n    GH[\"GitHub App and webhooks\"] -->|\"signed ingress\"| HTTP[\"Convex HTTP actions\"]\n    HTTP --> CX\n\n    ORCH[\"Hono orchestration service\"] -->|\"signed service commands\"| CX\n    ORCH --> WORKER[\"Canonical worker runtime\"]\n    WORKER --> REG[\"Generic Harness registry\"]\n    REG --> CODEX[\"codex/v1\"]\n    REG --> DEEP[\"DeepSeek experimental\"]\n    WORKER --> LOCAL[\"Local worktree\"]\n    WORKER --> REMOTE[\"Remote Sandbox Preview\"]\n    WORKER --> VERIFY[\"Independent verifier Attempt\"]\n    WORKER --> PUBLISH[\"Permit-gated GitHub publisher\"]\n    PUBLISH --> GH\n\n    CX --> DB[(\"Convex durable state\")]\n    DB --> UI\n\n    CX --- AUTH[\"Identity, policy, scope, budgets, and audit\"]\n    CX --- DELIVERY[\"Missions, Plans, WorkOrders, Tasks, and Attempts\"]\n    CX --- EVIDENCE[\"Candidates, evidence, Quality Gates, and PR lineage\"]\n    CX --- ADVISORY[\"Memory, observability, evals, and learning\"]\n```\n\n### Architectural responsibilities\n\n- **Convex is the source of truth.** Product state, lifecycle commands, policy,\n  audit, evidence, projections, schedules, and signed ingress live in Convex.\n- **The React UI is an operator client.** It never decides authority from local\n  state or client-provided role labels.\n- **The Hono service is an orchestration boundary.** It hosts long-running worker\n  behavior, harness adapters, sandbox integration, verification commands, and\n  GitHub publication. It does not own a competing delivery lifecycle.\n- **The harness owns execution reliability, not business authority.** Every\n  admitted harness/model/backend tuple has an exact capability contract.\n- **GitHub remains the V1 review system.** Mission Control produces governed,\n  evidence-backed pull requests; it does not replace human code review or merge.\n\nThere is no separate Express REST product backend. UI and CLI product access\nuses Convex queries, mutations, actions, internal functions, and HTTP actions.\n\n## Project status and proof\n\nMission Control is in **active V1 development**.\n\nThe honest current claim is:\n\n> Mission Control is a strong, human-governed production-pilot architecture with\n> a qualified delivery kernel. It is not yet a fleet-scale autonomous software\n> factory or a generally certified Remote Sandbox platform.\n\n### What has been proven\n\n- A browser-operated path from Mission and approved Plan through WorkOrder,\n  Task, Attempt, evidence, pull request, and human acceptance.\n- Real Mission Control GitHub App pull requests with exact repository, branch,\n  commit, changed-file, check, Attempt, and Mission lineage.\n- Immutable cancellation, failure, retry, and successful recovery history.\n- Process restart and browser refresh without losing terminal state or creating\n  duplicate pull requests.\n- Independent verification and exact-current evidence before acceptance.\n- A deterministic V3 qualification of 15 accepted controlled workloads across\n  bug fixes, features, refactors, security/policy changes, and migrations.\n- Seventeen deliberate failure injections that failed closed.\n- A bounded 3/3 live Remote Sandbox cohort with Attempt-scoped credentials and\n  verified cleanup.\n- A deterministic Factory Incident Command control plane with append-only\n  lifecycle, scoped command authority, independent observed-effect evidence,\n  and separately authorized restoration.\n- A canonical Context & Skills Factory admission path from versioned Factory\n  configuration through derived readiness, WorkOrder admission, producer\n  Attempt, unpublished candidate, separate verifier Attempt, and durable browser\n  evidence. This proof is deterministic and synthetic: model routing was denied,\n  transmission was absent, and it granted no acceptance, publication, or\n  production authority.\n\nThe complete evidence is retained in:\n\n- [Real Codex-to-GitHub browser golden path](docs/testing/evidence/real-codex-github-pr-golden-path/README.md)\n- [System Factory E2E V2 qualification](docs/testing/evidence/system-factory-e2e-v2/README.md)\n- [Production Factory Pilot V3](docs/testing/evidence/production-factory-pilot-v3/README.md)\n- [Context & Skills canonical Factory admission](docs/testing/evidence/context-skills-factory-admission-v1/README.md)\n- [Capability Maturity Ledger](docs/product/software-factory-capability-maturity.md)\n\n![Validated Mission with complete assertion coverage](docs/testing/evidence/real-codex-github-pr-golden-path/mission-validated-pr-61.png)\n\nThe public client/backend runtime contract is versioned in\n[`convex/lib/runtimeContract.ts`](convex/lib/runtimeContract.ts). Update it only\nwhen deployed clients and backend functions cannot safely interoperate.\n\nCurrent public client/backend runtime contract: **v63**. Version 63 adds receiver recovery quarantine and signed capability lifecycle acknowledgments. Version 61 on main adds\nobserved-cost reconciliation for terminal Fab Attempts. Version 62 combines that\ncontract with authenticated capability challenges and ordered policy proofs for\nMission and WorkOrder admission. Clients and the backend must advance together.\nSDK-qualified MCP snapshots bind to version 1.31.0 and require fresh qualification\nbefore activation.\n\n### Local Research Lab retry qualification\n\nOctober 8 follow-up reconciled the failed Attempt's observed cost to $0.0102412\nwithout releasing its reservation. The pinned Fab runtime cannot snapshot this\nrepository, so it now rejects that setup before credential minting. A compatible\nexecutor must be qualified before another run. See the\n[follow-up evidence](docs/testing/evidence/retry-followup-2026-10-08/README.md).\n\nZero allowed retries permits one initial execution with no retry Attempts.\nCommit `33e3612` fixes that Mission dispatch boundary while preserving positive\nretry-limit behavior. It is applied only to local Research Lab.\n\nPost-commit qualification passed 1,491 Convex tests and 766 orchestration tests.\nA real zero-retry dispatch created and executed exactly one Attempt. Duplicate\ndispatch and worker restart created no additional Attempt. The producer failed\nat its turn limit without a candidate, so end-to-end qualification remains\nincomplete. No broader deployment is approved. See the\n[retry qualification status and limitations](docs/operations/live-retry-dispatch-review.md)\nand [retained evidence](docs/testing/evidence/live-retry-2026-10-04/README.md).\n\nReplacement executor checks passed 153 focused tests, including eight local\nDocker cases with synthetic provider responses. The governed Codex Bedrock\ncandidate passed the small fixture; the full repository was subsequently\nrejected by its input-size limit. Full-repository execution and live qualification\nremain incomplete. See [full-tree failure and next decision](docs/testing/evidence/full-repository-docker-2026-10-08/README.md). No paid inference or image promotion\noccurred. See [candidate evidence and next gates](docs/testing/evidence/executor-selection-2026-10-08/README.md).\n\nThe approved October 9 local capacity experiment passed the full-tree synthetic\nedit and patch capture with 256 MiB input, 1 GiB workspace and 2 GiB RAM. It also\npassed 67 boundary checks. Runtime defaults remain unchanged. The terminal-status discrepancy was fixed\nand the full-tree test now reports SUCCESS. Canonical local admission and live\napproval gates remain. See [larger-profile\nevidence](docs/testing/evidence/large-repository-docker-2026-10-09/README.md).\n\nThe latest October 9 follow-up passed 1,501 Convex tests, 813 orchestration tests,\nboth typechecks and four full-repository Docker lifecycle cases with synthetic\nresponses. Canonical local admission validation is implemented and applied only\nto Research Lab; no profile is registered or activated. Exact AWS route checks\nawait SSO refresh, and live qualification remains incomplete. See the\n[local application and qualification evidence](docs/testing/evidence/local-admission-2026-10-09/README.md).\nSee [configuration, current price review and draft budget](docs/operations/research-lab-large-profile.md).\n\n### Factory Deployed Engineer qualification environment\n\nThe bounded FDLC Deploy / Factory Deployed Engineer qualification environment is **ready but not activated**. Its safe identifiers are:\n\n- AWS qualification account `083665737366` in `us-east-1`;\n- qualification hostname `qual.factory-engineer.fdlc.ai`;\n- dedicated Convex qualification deployment `calm-buffalo-854`;\n- workspace `mission-control://qualification/fdlc-phase-3`; and\n- Mission Control project `j17ve66cdc005ntgr6qj31b0fs8dwc62`.\n\nThe environment has pinned immutable runtime images and bounded qualification identities. Runtime services remain dormant, Phase 3 live activation has not started, and no Bedrock model invocation or Factory Engineer workload has occurred. This is environment-readiness evidence, not live-qualification or production-operations evidence. See the public [FDE status page](https://fdlc.ai/deploy) for the current release and rollback summary.\n\n### Factory Incident Command (Production-qualified; one exact repository operation)\n\nRuntime contract v51 adds a browser-operable incident control plane for the\ngoverned lifecycle:\n\n`Clarify → Contain → Observe → Isolate → Restore → Correct → Prevent → Measure`\n\nIncident Command deliberately separates a command being issued, the executor\nacknowledging it, and evidence that the intended effect was actually observed.\nAn acknowledgment is diagnostic evidence; it cannot certify containment.\nRestoration is a new consequential action and requires its own current,\nincident-scoped authority. Stale, revoked, replayed, forged, or cross-workspace\nauthority and evidence fail closed. Incident transitions depend on durable,\nappend-only receipts whose authority, provenance, scope, and currentness can be\nindependently verified.\n\nRuntime contract v53 adds one real bounded actuator for repository dispatch.\nAn authorized commander records a durable request; the executor changes the\nexact repository admission projection and records a separate command receipt\nand acknowledgment; a separately invoked observer records the actual effect.\nResume requires a durable, current restoration authorization created before\nexecution. The same admission gate protects WorkOrder dispatch and automatic\nVerification Attempt scheduling.\n\nRuntime contract v55 adds a bounded, authenticated production admission\nattempt for an already-paused exact repository. It invokes that same canonical\ngate, persists a distinct `DISPATCH_DENIED` receipt linked to the active\nindependently observed PAUSE chain, and creates no Attempt, workflow run,\nworker launch, or external call. Incident Command displays the receipt after\nrefresh and reuses its validated lineage as canonical Measure evidence.\n\nThis capability is **Production-qualified for one exact repository operation**.\nOn implementation main `03240af93c442a3f747507a21924b44ff379f80d`, retained\nProduction incident `INC-MTQR363Y-DA535A` completed pause, live dispatch denial,\nseparately authorized resume, independent restoration observation, measurement,\nresolution, and refresh recovery for `jaydubya818/MissionControl`. The exact\nGit-source UI deployment is `dpl_5b9qEHYxZkw1NCUEUzQJFsKpb5vM`; the canonical\nexecutor and admission gate are deployed in Convex Production at runtime\ncontract v55. This narrow qualification does not establish broad control\ncoverage or autonomous emergency authority.\n\n## Current limitations\n\nQualification evidence proves contracts at exact revisions. It does not prove\ngeneral production safety, sustained organizational adoption, provider economics,\nor operation at arbitrary scale.\n\nCurrent boundaries include:\n\n- **Real product pilot pending.** The broad V3 population used controlled,\n  disposable workload repositories. The real GitHub golden path was deliberately\n  narrow. Sustained consequential work on a named product repository remains the\n  next promotion gate.\n- **Remote Sandbox — Production-pilot eligible; Preview.** The qualification\n  status is **Production-pilot eligible; Preview** and includes a **3/3 live exe.dev cohort**,\n  but outbound egress is not yet provider-enforced and the Codex installation is\n  ephemeral. This is bounded live pilot evidence, not general production\n  certification.\n- **Guarded Auto is disabled.** Model/harness/backend routing remains advisory or\n  pinned until sample size, quality margin, cost coverage, and hard eligibility\n  meet policy.\n- **Merge and deployment remain human decisions.** Mission Control V1 stops at\n  evidence-backed acceptance and review-ready pull requests.\n- **Cost attribution is incomplete.** Token and latency data exist, but complete\n  model, provider, sandbox, and cost-per-accepted-outcome coverage does not.\n- **Tool and MCP authority remains narrow.** Mission Control retains the local\n  Phase 3 fixture and qualifies one real Context7 `query-docs` operation for a\n  fixed public React documentation query. No write operation, dynamic discovery\n  authority, connector breadth, or general harness MCP runtime is admitted.\n- **Incident Command — Production-qualified for one exact repository\n  operation.** The retained Production drill proves canonical pause, live\n  dispatch denial, separate restoration authority, independent observation,\n  resolution, and refresh recovery for `jaydubya818/MissionControl`. Other\n  controls, arbitrary repositories, broad provider integration, customer\n  incidents, and autonomous emergency authority remain outside the admitted\n  scope.\n- **Context & Skills admission — Synthetic qualification only.** The canonical\n  local path is qualified for deterministic no-provider execution with separate\n  producer and verifier identities. It does not establish behavioral performance\n  with a model, trusted production-result ingestion, publication eligibility,\n  acceptance authority, production activation, organizational adoption, or\n  equivalent behavior across other agent runtimes.\n- **Enterprise tenancy is not fully qualified.** Company, workspace, repository,\n  and server-side authorization boundaries exist; sustained cross-company and\n  service-identity evidence is still required before public multi-tenant claims.\n- **Adoption is not production-proven.** There is no sustained design-partner\n  cohort, onboarding baseline, satisfaction series, or fleet-scale reliability\n  record.\n\nThe [Capability Maturity Ledger](docs/product/software-factory-capability-maturity.md)\nis the canonical source for each capability's status, evidence, limitation, and\nnext promotion gate.\n\n## Quickstart\n\n### Prerequisites\n\n- Node.js 20+\n- pnpm 9+\n- A Convex development deployment\n\n### First-time setup\nFor the standard local run, the only values you need are the Convex development\ndeployment values. Run `pnpm exec convex dev --once` to create or link the\ndeployment, then copy `CONVEX_URL` into `VITE_CONVEX_URL`. The `.env.example`\nfile is a reference for optional settings and development-safe defaults; it does\nnot need to be copied before Convex setup.\n\n| Variable | Purpose | Where it comes from |\n| --- | --- | --- |\n| `CONVEX_DEPLOYMENT` | Identifies the Convex development deployment | Created by `pnpm exec convex dev --once` |\n| `CONVEX_URL` | Connects the application to the Convex backend | Written by `convex dev` |\n| `VITE_CONVEX_URL` | Connects the browser UI to Convex | Copy `CONVEX_URL` into `.env.local` |\n\n```bash\ngit clone https://github.com/jaydubya818/MissionControl.git\ncd MissionControl\ncorepack enable\npnpm install\npnpm exec convex dev --once\n```\n\nConvex creates or links a development deployment and writes `CONVEX_URL`. If\nonly `CONVEX_URL` is generated, copy that value to `VITE_CONVEX_URL` in\n`.env.local`:\n\n```bash\nCONVEX_URL=https://your-deployment.convex.cloud\nVITE_CONVEX_URL=https://your-deployment.convex.cloud\n```\n\nStart Convex and the UI:\n\n```bash\npnpm run dev\n```\n\nOpen <http://localhost:5173>. If Vite selects another port, use the URL printed\nin the terminal.\n\nAuthentication defaults to the repository's legacy development provider.\nClerk-backed human identity requires the corresponding browser and Convex\nconfiguration described in `.env.example`; demo identity is local-only.\n\n## Software Factory demo (local end to end)\n\nThe deterministic demo is the fastest way to understand the complete product\nmodel without external coding, sandbox, or GitHub providers.\n\nStart the demo runtime in one terminal:\n\n```bash\npnpm run dev:demo\n```\n\nAfter Convex reports that functions are ready, seed the demo from a second\nterminal:\n\n```bash\npnpm run convex:seed:demo:force\n```\n\nOpen <http://localhost:5199/v2/command-center> and select **Software Factory\nDemo** (`sf-demo`).\n\nThe demo starts:\n\n- the Convex development backend;\n- the versioned workflow graph executor; and\n- the EOS V2 operator UI on port `5199`.\n\nUse it to inspect:\n\n1. Command Center attention and decision queues.\n2. Mission intent and approved Plan state.\n3. WorkOrder approval, dispatch, and verification gates.\n4. Task and Attempt lifecycle evidence.\n5. Factory configuration and repository readiness.\n6. Trace Inspector observations and evals.\n7. Factory Memory, graph data, and frozen Context Packages.\n8. Audit, decision, and evidence history.\n\nThe seeded names, counts, timestamps, and outcomes are fixture data. The demo is\nnot proof of production throughput, hundred-agent capacity, external provider\noperation, or autonomous delivery.\n\nFor the preserved Software Factory Research Lab, use\n`pnpm run dev:research-lab`. The Research Lab and deterministic demo are\nintentionally separate runtime profiles and both use port `5199`; stop one before\nstarting the other.\n\nSee [Run the demo](docs/site/get-started/run-the-demo.md) for the complete smoke\ntest and troubleshooting guide.\n\n## Development and verification\n\n### Common commands\n\n| Command | Purpose |\n| --- | --- |\n| `pnpm run dev` | Start Convex and the standard UI |\n| `pnpm run dev:ui` | Start only the Vite UI |\n| `pnpm run dev:demo` | Start the deterministic demo backend, workflow executor, and V2 UI |\n| `pnpm run dev:research-lab` | Start the preserved Research Lab profile |\n| `pnpm run dev:orchestration` | Start the Hono orchestration service |\n| `pnpm run build` | Build every workspace package and app that declares a build |\n| `pnpm run typecheck` | Type-check the workspace after preparing internal packages |\n| `pnpm run test` | Run package, application, and Convex tests |\n| `pnpm run test:e2e:critical` | Run critical accessibility, dashboard, and V2 route browser tests |\n| `pnpm run lint` | Run type checking and skill validation |\n| `pnpm run release:security` | Run dependency, authorization, secret, and Factory documentation gates |\n| `pnpm run qualify:factory` | Run deterministic full-system Factory qualification |\n\nThe repository uses Vitest for unit and contract tests, Playwright for browser\nevidence, and a runtime-contract guard for intentional public Convex API changes.\n\n### Built-in workflows\n\nVersioned YAML workflows live in `workflows/`:\n\n- `bug-fix`\n- `code-review`\n- `continuous-research`\n- `feature-dev`\n- `loop-engineering`\n- `quality-audit`\n- `security-audit`\n\nWorkflow definitions can be snapshotted onto runs so later edits do not rewrite\nthe execution contract of historical Attempts.\n\n### Production worker warning\n\nThe canonical `codex/v1` Factory worker is disabled by default. Do not enable it\nby setting `CODEX_FACTORY_WORKER_ENABLED=true` until the target repository,\nGitHub App installation, Factory version, worker identity, code scope, policy,\nhost, and verification readiness are current and verified.\n\nThe orchestration process requires server-only credentials. Never expose\n`CONVEX_SERVICE_AUTH_TOKEN`, service-command secrets, GitHub App private keys,\ninstallation tokens, provider-management credentials, or sandbox credentials in\n`VITE_*` variables.\n\nSee [Run Commands](docs/guides/RUN.md) and the\n[full technical overview](docs/OVERVIEW.md#production-bound-configuration) before\nstarting a live worker.\n\n## Security model\n\nMission Control assumes that repository content, external text, memory, tool\noutput, model output, and worker result payloads are untrusted data.\n\nCore security boundaries include:\n\n- server-side human and service identity resolution;\n- company, workspace, repository, environment, and code-scope authorization;\n- named capabilities and default-deny admission;\n- separate human and service command surfaces;\n- HMAC-verified webhook and service-command ingress;\n- idempotency, replay protection, and durable audit records;\n- short-lived GitHub and inference credentials;\n- secrets excluded from browser configuration, events, artifacts, and logs;\n- repository classification and risk-proportional execution policy;\n- immutable candidates and exact-subject independent verification;\n- candidate-bound publication permits;\n- bounded retries, budgets, cancellation, pause, and kill controls; and\n- human acceptance, merge, release, and risk authority.\n\nRemote execution is not considered generally certified. Sensitive remote work\nmust fail closed unless the exact Factory and sandbox profile satisfy repository\nclassification, isolation, credential, egress, runtime, cleanup, and evidence\nrequirements.\n\nSecurity documentation:\n\n- [Security Policy](SECURITY.md)\n- [Human and service authorization matrix](docs/security/human-service-authorization-matrix.md)\n- [Verification plane threat model](docs/security/verification-plane-threat-model.md)\n- [Remote Sandbox threat model](docs/security/remote-sandbox-threat-model.md)\n- [GitHub App connection model](docs/security/github-app-connection.md)\n- [Evidence retention policy](docs/security/evidence-retention-policy.md)\n\nReport suspected vulnerabilities privately to the repository owner. Do not put\nlive credentials, exploitable production details, or customer data in a public\nissue.\n\n## Repository map\n\n| Path | Responsibility |\n| --- | --- |\n| `apps/mission-control-ui/` | React operator application and EOS V2 shell |\n| `apps/orchestration-server/` | Hono ingress, signed service commands, canonical Factory worker, harness adapters, sandbox runtime, verifier, and GitHub publisher |\n| `apps/workflow-executor/` | Standalone executor for versioned workflow graphs |\n| `convex/` | Authoritative schema, lifecycle commands, policy, GitHub ingress, evidence, schedules, and projections |\n| `packages/workflow-engine/` | Workflow graph, Generic Harness, Verification Subject and Plan, independence, and currentness contracts |\n| `packages/policy-engine/` | Risk and policy evaluation primitives |\n| `packages/agent-runtime/` | Agent lifecycle and heartbeat behavior |\n| `packages/memory/` | Provider-neutral Memory ingestion, retrieval, graph, Context Package, and eval algorithms |\n| `packages/context-router/` | Context selection and routing |\n| `packages/context-tools/` | Context manifest and activation tooling |\n| `packages/model-router/` | Model and executable Factory tuple routing |\n| `workflows/` | Versioned YAML workflow definitions |\n| `skills/` | Mission Control agent integration skills |\n| `scripts/mc` | Mission Control CLI |\n| `tests/e2e/` | Browser-operated critical paths and accessibility checks |\n| `docs/testing/evidence/` | Revision-specific qualification and browser evidence |\n| `docs/` | Product doctrine, architecture, security, operations, plans, and evidence |\n\n### Technology\n\n- React 18, TypeScript, Vite, Tailwind CSS 4, and shadcn/ui\n- Convex for durable state, typed server functions, scheduled work, and HTTP\n  ingress\n- Hono for long-running orchestration and external executor integration\n- pnpm workspaces and Turborepo\n- Vitest and Playwright\n- GitHub App installation tokens and signed webhooks\n- Local worktrees and an optional exe.dev Remote Sandbox backend\n\n## Documentation\n\nStart with the document that matches the question you are trying to answer.\n\n| Document | Use it for |\n| --- | --- |\n| [Full technical overview](docs/OVERVIEW.md) | Complete rationale, lifecycle, implementation, architecture, security, local operation, and evidence |\n| [Mission Control North Star](docs/product/mission-control-north-star.md) | Product promise, operating doctrine, V1 boundary, and decision filter |\n| [V1 Product Strategy](docs/product/mission-control-v1-product-strategy.md) | Primary users, golden path, priorities, and ship gates |\n| [Capability Maturity Ledger](docs/product/software-factory-capability-maturity.md) | Canonical capability status, evidence, limitation, owner, and next promotion gate |\n| [Run Commands](docs/guides/RUN.md) | Supported local runtime profiles and troubleshooting |\n| [Run the demo](docs/site/get-started/run-the-demo.md) | Deterministic demo walkthrough and smoke tests |\n| [Golden-path proof](docs/testing/evidence/real-codex-github-pr-golden-path/README.md) | Browser-operated Codex-to-GitHub evidence, persisted identifiers, retries, and screenshots |\n| [Generic Harness Contract](docs/architecture/generic-harness-contract-v1.md) | Provider-neutral execution lifecycle and admission contract |\n| [Execution Routing](docs/architecture/execution-routing-v1.md) | Model, harness, backend eligibility and routing policy |\n| [Remote Sandbox execution](docs/architecture/remote-sandbox-execution.md) | Remote execution boundary and security posture |\n| [Factory Memory](docs/architecture/factory-memory-context-intelligence.md) | Advisory retrieval, graph, Context Packages, and phase gates |\n| [Factory Learning](docs/architecture/factory-learning-continuous-improvement.md) | Signals, experiments, proposal-only improvement, and promotion governance |\n| [Skill catalog](docs/skills/skillz-catalog.md) | Bundled skill inventory, upstream provenance, licensing, routing, and update procedure |\n| [Context & Skills canonical Factory admission](docs/testing/evidence/context-skills-factory-admission-v1/README.md) | Exact synthetic runtime, Factory, WorkOrder, Attempt, candidate, verifier, browser, and authority-boundary evidence |\n| [Contributing](CONTRIBUTING.md) | Issue and pull-request expectations |\n\nArchitecture documents define intended contracts. Plans describe proposed or\nhistorical work. Evidence packages prove behavior at an exact revision. When a\nstatus claim differs, current source and retained evidence take precedence, and\nthe Capability Maturity Ledger should be corrected.\n\n## Contributing\n\nIssues and focused pull requests are welcome. Small fixes can go directly to a\npull request; discuss larger capabilities or behavioral changes in an issue\nfirst. See [CONTRIBUTING.md](CONTRIBUTING.md).\n\nPlease keep changes aligned with the V1 product promise: clearer intent, safer\nautonomy, stronger verification, better evidence and traceability, faster\napproved-Plan-to-PR flow, reliable recovery, or greater developer trust.\n\n## License\n\nMission Control is licensed under the [MIT License](LICENSE).\n"}