← Mission 1 · FD Build

Build Sub-Mission

Mission 1F · Mission Test Harness

Automatically verify what can be objectively verified, preserve the evidence, and return only genuine judgment calls to the Pilot.

CALM · Operational Observation

Mission Test Harness · V0

Automate verification, not authority

Bounded test anatomy

Every test must say exactly what is being checked, how it is checked, what counts as a pass, what evidence is preserved, what happens on failure, and whether the Gate is objective enough to pass without Pilot judgment.

1 · Test target

The observable condition the Mission needs to prove.

2 · Test method

The repeatable check used to gather evidence.

3 · Pass criteria

The explicit condition that must be true for the test to pass.

4 · Evidence produced

The durable facts that justify the result and can be inspected later.

5 · Failure action

Retry, return to build, continue observing, or escalate—defined before the test runs.

6 · Authority level

Auto-pass allowed only for objective, pre-authorized criteria; otherwise the Gate returns to the Pilot.

Example · Deployment verification

AUTO-PASS ELIGIBLE
Target:
New Mission UI is available in production.
Method:
Verify deployment state and fetch the production route.
Pass:
Deployment is READY and route responds successfully.
Evidence:
Commit SHA, deployment ID, deployment state, route response.
Failure:
Return to build or retry verification; do not advance the Gate.

Example · Pilot usefulness

PILOT GATE
Target:
The new UI makes the judgment situation understandable.
Method:
Pilot inspects the live page in the context of the Mission.
Pass:
Pilot confirms the distinction is useful and clear enough to proceed.
Evidence:
Pilot judgment and any observed usability gap.
Failure:
Revise the V0; Flightdeck must not manufacture a human judgment.

Authority boundary

The harness may verify and advance only inside an already-authorized envelope. It cannot change the plan, expand scope, clear Pilot-attention Signals, or convert ambiguity into an automatic pass.

Executable test · Canonical Mission route

Mission identity and durable navigation

Passed

Canonical Mission route responded successfully and matched the expected Mission identity plus durable-UUID sub-mission navigation.

HTTP

200

Mission marker

Found

UUID navigation

Canonical

Authority

Auto-pass eligible

Evidence

https://fd.sproutcolabs.ca/desk/missions/607ce483-1365-48c5-9bbb-146df204c6b1

Checked 2026-09-06T04:22:26.540Z

Progress

The first in-product executable Mission test is live and production-verified. Canonical Mission identity, HTTP 200, durable-UUID sub-mission navigation, and bounded durable evidence persistence all passed. Re-running the evidence test correctly reused the existing durable record instead of creating duplicate evidence.

Current Gate

Observe the harness across additional objective checks and confirm that automatic verification remains bounded, repeatable, and separate from Pilot judgment.

Next authorized action

Reuse the verified harness when an objective Mission Gate can be tested automatically; expand test coverage only when a real build step benefits from it.

Pilot authority

No Pilot approval currently required. Work remains inside the authorized envelope.

Authorized scope

What this aircraft is carrying

Per-Mission and per-sub-mission test definitions
Test target, method, pass criteria, and evidence produced
Canonical route identity must come from the durable Mission UUID, not a display label or sequence number
Executable objective checks may run inside the existing server-side Flightdeck path
Failure action: retry, return to build, observe, or escalate
Authority level: auto-pass allowed vs Pilot judgment required
Bounded durable evidence persistence and idempotent reuse
No automatic plan changes or scope expansion
No automatic clearing of Pilot-attention Signals
No uncontrolled writes merely because a page rendered
No new infrastructure in the first pass

Governance

Independent flight, visible dependencies

Evidence Before Expansion applies to this sub-mission independently. A Gate here does not stop another FD Build sub-mission unless a real dependency requires it. Parent Mission 1 remains the cockpit view for the whole build fleet.