Files

gsxdsm cc18206bc5 FN-5902: make mission validation AI-run all criteria

Route every mission feature through validator-backed completion checks.

- lazily restore a managed feature assertion before validation instead of auto-passing zero-assertion features
- thread milestone acceptance criteria into validator prompts and system instructions as enforced requirements
- update MissionManager copy/tests to present criteria as AI-validated runtime gates and remove informational-only/zero-assertion warnings
- document the all-criteria AI-run contract and add a changeset for @runfusion/fusion

Files changed:
 .changeset/fn-5902-mission-validation-ai-run.md    |   5 +
 AGENTS.md                                          |   2 +-
 docs/architecture.md                               |   2 +-
 docs/missions-completion-contract.md               | 198 ++++++---------------
 docs/missions.md                                   |   5 +-
 packages/core/src/__tests__/mission-store.test.ts  |  23 ++-
 packages/core/src/mission-store.ts                 |  10 ++
 packages/dashboard/app/components/MissionManager.css    |  31 ----
 packages/dashboard/app/components/MissionManager.tsx    |  86 +++------
 packages/dashboard/app/components/__tests__/MissionManager.test.tsx   |  60 +++++--
 packages/engine/src/__tests__/mission-execution-loop.test.ts   | 111 +++++++++---
 packages/engine/src/__tests__/reliability-interactions/mission-validation-trigger-gap.test.ts         |  57 +++---
 packages/engine/src/mission-execution-loop.ts      |  78 ++++----
 13 files changed, 318 insertions(+), 350 deletions(-)

Fusion-Task-Id: FN-5902

Fusion-Task-Lineage: 5f25caad-33c9-42ff-822b-1ea092afc29f

2026-06-02 18:11:26 -07:00

4.2 KiB

Raw Blame History

Mission Completion Gate Contract

Status

Decision date: 2026-06-02
Current contract task: FN-5902
Supersedes: FN-5718 baseline contract
Depends on runtime trigger/recovery behavior from: FN-5715
Implementation status: Realized by FN-5902

Decision

Mission completion now uses an all-criteria AI-run contract:

MissionFeature.acceptanceCriteria is the canonical authored feature criteria text.
MissionStore must maintain or lazily restore one store-managed per-feature MissionContractAssertion derived from feature content with text priority:
- feature.acceptanceCriteria
- feature.description
- Verify implementation of: {feature.title}
The mission validator must run for every feature completion trigger. Runtime validation may lazily call ensureFeatureAssertionLinked(feature.id) before starting the validator so legacy missing-link rows still become validator-backed.
milestone.acceptanceCriteria is also part of the enforced gate by being threaded into the validator prompt for every feature in that milestone.
Feature, slice, milestone, and mission advancement are gated by the validator result — not by an informational-only path.

Enforcement Model

Feature-level enforcement

A feature is autopilot-complete only when the validator passes after evaluating:

the feature's linked contract assertions, including its store-managed assertion, and
the parent milestone's acceptanceCriteria text when present.

Milestone-level enforcement

milestone.acceptanceCriteria is no longer informational-only. FN-5902 enforces it by threading the milestone pass-bar text into the validator prompt for each feature under that milestone.

This is intentionally prompt-threading, not per-feature milestone assertion row synthesis:

store-managed per-feature assertions remain the canonical feature assertion rows,
milestone acceptance text remains milestone-authored prose,
the validator sees both and must satisfy both.

Legacy data and lazy repair

Legacy missions can still contain features with missing assertion links. Runtime enforcement no longer depends on pre-running backfill:

mission execution lazily restores the store-managed feature assertion just before validation, and
fn_mission_backfill_assertions / backfillFeatureAssertions() remain available as operator repair tooling for data hygiene and visibility.

Removed behavior (FN-5902 inversion)

FN-5718's zero-assertion auto-pass behavior is superseded.

Removed contract:

no validation_auto_passed_no_assertions completion path,
no silent or explicit rubber-stamp pass because assertions were missing,
no informational-only feature criteria bucket in MissionManager.

Instead, features are routed through validator execution after lazy assertion ensure.

Worked examples

Feature has acceptance criteria; no linked assertion row is present yet
- Runtime calls ensureFeatureAssertionLinked(feature.id).
- Validator runs against the restored managed assertion.
- Result gates completion normally.
Feature has acceptance criteria and milestone acceptance criteria
- Validator evaluates the linked feature assertion(s).
- Validator also evaluates the milestone acceptance text in the prompt.
- Feature passes only when both are satisfied.
Operator runs backfill on legacy data
- Backfill pre-restores missing managed assertions for visibility/reporting.
- Runtime behavior is unchanged because lazy ensure already guarantees validator-backed enforcement.

UI contract

MissionManager must present mission criteria as AI-validated rather than informational:

assertion heading text reflects AI validation,
informational / not-enforced labels are removed,
zero-assertion warning guard is removed,
fallback feature-criteria rollups, when shown for missing loaded assertions, describe runtime AI validation rather than non-enforced prose.

Success invariant

For any mission feature that reaches validation trigger points:

a validator run must occur,
the feature must not auto-pass due to missing assertion links,
milestone acceptance text must be visible to the validator when present,
advancement decisions must derive from validator outcomes only.

4.2 KiB Raw Blame History