Control Plane and Execution Plane

4. Tradeoffs and alternatives

Separation adds infrastructure and latency. The factory needs service identity, command signing, event ingestion, idempotency, health checks, and reconciliation. A small prototype may run all components in one process, but it should preserve the logical boundary in interfaces and state ownership so the system can be separated later.

A control-plane-only architecture is operationally simple. It becomes fragile when database functions have short execution limits or when work needs persistent streams, subprocesses, local repositories, and long-lived leases.

A fully distributed execution architecture can scale and isolate workloads. It also increases the number of partial failures and the difficulty of proving exactly-once effects. Durable commands plus idempotent reconciliation are more realistic than assuming reliable delivery.

Centralized orchestration makes policy and sequencing easier to understand. It can become a bottleneck or single failure domain. Distributed orchestrators may improve availability, but only if they share one authoritative control-plane state and cannot create competing ownership.

The control plane may govern an external deployment system rather than replace it. This preserves existing delivery investments but requires precise mapping between factory decisions and provider state.

5. Current Mission Control Implementation

This assessment uses Mission Control commit 8014d5af427b43ff5c5a63cfdf82ec92742c208c, studied on 2026-08-08. The Mission Control working tree contained unrelated in-progress changes, so all claims and links below refer to the pinned commit.

Operator interface

The React application connects to Convex through ConvexReactClient. Clerk may provide authenticated user identity. React renders commands, state, approvals, exceptions, and evidence, but Convex mutations remain the server authority. A disabled or manipulated client control must not bypass those mutations.

Convex control plane

Convex is the durable source of truth for Mission Control. It stores the domain hierarchy, Factory Configuration versions, WorkflowRuns, approvals, evidence, events, artifacts, GitHub integration records, and audit data. Queries expose projections. Mutations and actions enforce lifecycle changes.

Governed WorkOrder dispatch evaluates the active Factory version, readiness assessment, configuration digest, repository and GitHub state, workflow, executor, policy, verifiers, host, budget, recovery controls, worktree, and concurrent mutation. Successful dispatch records the selected versions and boundaries on the WorkflowRun.

Explicit WorkOrder acceptance is separate. Active execution, missing completed runs, failed criteria, stale evidence, and unsatisfied approvals block it.

Hono orchestration boundary

Mission Control runs a standalone Hono service under apps/orchestration-server. It exposes authenticated routes for governed dispatch, already-dispatched execution, approval and receipt handling, Mission handoffs, validation results, acceptance, revisions, run events, and artifacts.

The original orchestration ADR placed the service under packages/server; the implementation later moved to apps/orchestration-server. The architectural decision—Hono coordinates while Convex remains authoritative—survived the path change. This is an example of enduring intent outliving an implementation detail.

Protected routes use bearer-token authentication. Production fails closed when no orchestration token is configured. Development permits tokenless access, which is convenient locally but cannot be treated as production evidence.

High-impact service commands currently use a signed envelope. The orchestration service creates an HMAC signature over service identity, capability, project, repository, command identity, time window, and payload digest. At the studied commit, the narrow signed capabilities are WorkOrder dispatch and receipt ingestion. Other orchestration routes do not yet share one universal service command envelope.

Workflow executor and adapter boundary

apps/workflow-executor is a long-lived process that polls Convex for WorkflowRuns and executes workflow steps through @mission-control/workflow-engine. It has graceful shutdown handling and an optional health endpoint.

The executor adapter interface defines capability discovery, configuration validation, estimates, execution events, cancellation, optional resume, and health. Mission Control selects codex/v1 as the V1 production executor.

CodexV1ExecutorAdapter launches an ephemeral Codex CLI process. It checks that repository and working-directory paths are absolute and contained, allowed paths cannot traverse upward, prompts are present, and timeouts are bounded. It supports read-only and workspace-write isolation, ordered events, cancellation, bounded output, and basic credential redaction. It does not claim resume.

The repository root is expected to be an Attempt-specific worktree. The adapter records allowed paths, but the executor contract explicitly states that exact post-run changed-file enforcement remains part of the dispatch and golden-path responsibility before pull-request creation.

GitHub and external delivery

Mission Control stores repository connections and GitHub App capability state. It records webhook deliveries for replay and idempotency, ingests head-SHA-specific pull-request and CI evidence, and retains merge facts. GitHub remains the source of truth for repository and pull-request state; Mission Control owns the governed interpretation of whether those facts satisfy progression policy.

Capability assessment

Verification boundary

The cited source and test files were inspected at the pinned commit. No fresh browser journey or live executor run was performed for this chapter. The chapter therefore establishes a source-backed architecture assessment, not proof that the complete Mission-to-pull-request path currently works.