cc18206bc5
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
95 lines
4.2 KiB
Markdown
95 lines
4.2 KiB
Markdown
# 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**:
|
|
|
|
1. `MissionFeature.acceptanceCriteria` is the canonical authored feature criteria text.
|
|
2. 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}`
|
|
3. 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.
|
|
4. `milestone.acceptanceCriteria` is also part of the enforced gate by being threaded into the validator prompt for every feature in that milestone.
|
|
5. 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
|
|
|
|
1. **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.
|
|
|
|
2. **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.
|
|
|
|
3. **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.
|