Mission Control / Open-source FDLC reference
Governed autonomous delivery.
Mission Control is the reference implementation of the Factory Development Lifecycle: a bounded, human-governed delivery kernel from intent through verified pull-request publication and acceptance. It turns intent, execution, evidence, approval, and outcomes into durable operating records.
Not another coding agent. The system that decides what agents may do—and what evidence must return before work advances.
Mission Control / Command CenterDemo view
- License
- Open source
- Demo
- Deterministic
- Truth model
- Capability-specific
A concrete control plane that demonstrates FDLC objects, gates, authority, evidence, recovery, and permit-gated pull-request publication.
What it is notThe definition of FDLC, every component of a complete factory, or proof of generalized release, production learning, governed MCP, incident response, enterprise authorization, or fleet-scale autonomous delivery.
Interactive governed path
Follow one mission through the control plane.
Select a stage to see the governing question, the authority allowed to answer it, and the proof required before state can advance.
Governed delivery trace
Deterministic example · 01 mission01 / 06
Planning eligibleMission + Mission Spec
Decision boundary
What outcome is required—and what would prove success?
Intent becomes a versioned contract with scope, non-goals, constraints, and acceptance expectations before an agent receives authority.
- Authority
- Mission owner
- Control
- Specification readiness
- Required proof
- Immutable spec revision
Durable record model
Every claim has an owner, lineage, and boundary.
Mission Control expands the FDLC Artifact Protocol with implementation records needed to dispatch, recover, verify, and audit real work.
- 01Mission
The governed outcome and scope. This is Mission Control’s concrete realization of FDLC Intent.
- 02Mission Spec
An immutable, attributable statement of requirements, non-goals, and acceptance expectations.
- 03Plan
A versioned artifact bound to exact Specification lineage and approved before WorkOrder release.
- 04WorkOrder
The governed delivery and acceptance contract for one bounded unit.
- 05Task
An operational unit inside a WorkOrder; never the acceptance authority.
- 06Attempt
One immutable execution or verification try against frozen inputs and a fenced lease.
- 07Evidence Envelope
Attributable proof bound to the exact candidate, criterion, Attempt, and policy.
- 08Quality Gate Decision
A fail-closed eligibility decision assembled from current verification evidence.
Operator experience
Operate from exceptions, evidence, and decisions.
Explore three real views from the deterministic Software Factory demo. Each surface is designed around the next responsible action—not activity for activity’s sake.
Mission Control / Command CenterSoftware Factory Demo
These screens demonstrate product structure and the documented one-repository V1 path. They are not a claim of fleet-scale autonomous production.
Implementation architecture
Intelligence can vary. Authority remains explicit.
The browser, agents, harnesses, and providers do not create their own permission to act or advance state. The control plane remains the source of identity, policy, state, and decisions.
React + TypeScriptExceptions, decisions, Plans, WorkOrders, traces, and evidence
Human attentionConvexState, policy, identity, admission, decisions, and immutable lineage
Source of authorityHono + worker runtimeSigned service commands, harness admission, leases, checkpoints, and recovery
Bounded coordinationCodex + bounded backendsFrozen manifest, isolated worktree or Preview Remote Sandbox, exact candidate
Replaceable intelligenceIndependent Attempt + GitHub AppEvidence receipts, currentness, Quality Gate, and permit-gated publication
Proof before promotionOperating rule Allow intelligence to change. Never allow authority to become implicit.
Current capability
Inspect what is real—and where it stops.
Status belongs to each capability, not the product slogan. Open any item to see the implemented behavior and its current boundary.
Governed intent, Plans, and WorkOrdersQualified
SupportedVersioned Plans can be reviewed and approved before releasing bounded WorkOrders.
Current boundaryOne-repository V1 golden path; consequential actions remain separately gated.
Agent definitions and Factory bindingQualified
SupportedAgent definitions and factory configuration are bound into the governed delivery path.
Current boundaryBuilder-facing configuration is primarily developer and operator oriented.
Skills, context, and Factory MemoryQualified; advisory
SupportedProvenance-backed context can be frozen to an exact Attempt and inspected.
Current boundaryRetrieval is deliberately non-authoritative and phase-gated.
Durable execution and recoveryQualified
SupportedExecution is admitted against frozen configuration, fenced by a lease, and retained as immutable Attempt lineage.
Current boundaryFleet-scale restart and provider-failure operation are not claimed.
Independent verification and Quality GatesQualified
SupportedExact candidates are checked by logically separate verifier Attempts and bound to evidence receipts.
Current boundaryV1 verifier profiles and repository scope; verification establishes eligibility, not acceptance or release.
Observability, traces, and evalsQualified diagnostic system
SupportedRuns can produce traces, scores, datasets, and experiments for diagnostic comparison.
Current boundaryDiagnostic only; no acceptance authority.
Factory LearningQualified; advisory
SupportedEvidence can produce bounded learning signals and human-reviewed proposals.
Current boundaryFixture and qualification signals dominate; promotion is intentionally manual.
Model/harness/backend routingImplemented, gated
SupportedPolicy-aware routing and recorded routing decisions exist behind gates.
Current boundaryAdvisory by default; the remote tuple has limited samples and incomplete costs.
Remote SandboxProduction-pilot eligible; Preview
SupportedA bounded live cohort is qualified for production-pilot evaluation.
Current boundaryUnrestricted outbound egress, ephemeral Codex installation, and limited live samples remain.
Native tool authorizationPartial
SupportedA canonical Tool Version, Tool Grant, broker, and durable-receipt boundary covers fixtures and one qualified real read.
Current boundaryHarness-native tools do not yet use the same canonical authority.
Tools/MCP runtimePartial
SupportedOne exact Context7 query-docs read was qualified through versioned authority, brokered execution, durable receipts, and independent verification.
Current boundaryOne fixed public React query only; writes, arbitrary servers and operations, broad credentials, and harness-native MCP remain unsupported.
Release and production feedbackPartial
SupportedPull-request publication can be permit-gated and reconciled to exact head and evidence lineage.
Current boundaryHuman merge remains outside V1 authority; full production observation and rollback proof are not established.
Factory incident responseMissing canonical lifecycle
SupportedAlerts, operational events, traces, and run failures provide useful raw signals.
Current boundaryThey are not yet unified into an end-to-end incident lifecycle.
Local quickstart
Run the deterministic factory demo.
Requires Node 20, pnpm 9, Git, and a Convex development deployment. Copy the generated CONVEX_URL to VITE_CONVEX_URL in .env.local. Live providers are not required for the demo.
git clone https://github.com/jaydubya818/MissionControl.git
cd MissionControl
corepack enable
pnpm install
pnpm exec convex dev --once
# Terminal 1
pnpm run dev:demo
# Terminal 2, after Convex reports ready
pnpm run convex:seed:demo:forceThen open http://localhost:5199/v2/command-center and select Software Factory Demo. pnpm run dev starts Convex and the standard UI; dev:demo adds the deterministic workflow executor. Live-provider orchestration requires separate credentials and remains off by default.
Build with the model