Governed Issue to Validated Pull Request

Current Mission Control Implementation

The controlled target baseline is jaydubya818/mission-control-factory-lab at commit a4c864d743e2304feb2979870f41efbbae5d632b, tagged lab-baseline-v1. The first browser run reached an approved Plan and two released WorkOrders but stopped before dispatch. It therefore remains evidence of partial control-plane operation, not proof of the complete factory promise. See the 2026-08-08 execution assessment.

Governed workflow

1. A human creates the Mission and defines the desired outcome, constraints, acceptance criteria, owner, and risk.
2. An agent investigates the target repository.
3. The factory produces a versioned Plan.
4. A human approves the exact Plan version.
5. Mission Control authorizes a WorkOrder with a bounded acceptance boundary.
6. The factory decomposes and executes Tasks through immutable Attempts.
7. Implementation occurs in an isolated worktree.
8. Independent validators run through separate execution paths and generate their own evidence.
9. Mission Control creates the pull request and review package.
10. A human makes the merge decision.

Required failure exercise

Intentionally submit an empty Business Justification. Show the UI validation, server-side rejection, authoritative record state, and retained evidence. Then correct the input without bypassing the governed path. This is an expected validation failure, not automatically a trust-loss event.

The meaningful runtime failure is independent validation discovering that the first implementation enforces the field only in the browser. The validator must call the authoritative backend path directly with an empty value. If that call succeeds, the criterion fails, acceptance remains blocked, and the factory creates bounded corrective work. The correction adds server-side enforcement and produces a new Attempt. Fresh independent evidence must replace the failed receipt; the original failure remains in history.