root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FN-5755: harden mission validation recovery flow

Browse Source 
Ensure mission feature assertions recover and validate consistently across startup and periodic maintenance.

- add FN-5755 changeset and AGENTS reliability backstop note
- document canonical zero-assertion auto-pass and assertion validation lifecycle updates in missions docs
- expand mission execution loop and reliability interaction tests for startup recovery, periodic replay, and idempotency
- wire self-healing maintenance to replay active mission validation recovery via runtime callback

Files changed:
 .../fn-5755-mission-validation-end-to-end.md       |  5 ++
 AGENTS.md                                          |  1 +
 docs/missions-completion-contract.md               | 15 ++--
 docs/missions.md                                   |  4 +-
 .../src/__tests__/mission-execution-loop.test.ts   | 88 +++++++++++++++++++++-
 .../mission-validation-trigger-gap.test.ts         | 42 ++++++++++-
 packages/engine/src/runtimes/in-process-runtime.ts |  6 ++
 packages/engine/src/self-healing.ts                | 11 +++
 8 files changed, 159 insertions(+), 13 deletions(-)

Fusion-Task-Id: FN-5755

Fusion-Task-Lineage: e54ac4dc-7b8c-4fc9-8cd6-18702708546f
This commit is contained in:
gsxdsm
2026-05-30 17:45:11 -07:00
parent eba6a72594
commit 5396730033
8 changed files with 159 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/missions-completion-contract.md
View File

@@ -57,17 +57,17 @@ Canonical authored source and enforcement path:
## Zero-Assertion Behavior and FN-5696 Failure Shape
### Zero-assertions runtime behavior (must align with FN-5715)
### Zero-assertions runtime behavior (canonical FN-5738 path)
When a feature reaches completion trigger points and has **zero linked assertions**, mission execution must take an explicit auto-pass path (not a silent stall):
When a feature reaches completion trigger points and has **zero linked assertions**, mission execution must take exactly one canonical auto-pass path (not a silent stall and not a competing behavior):
- mark feature as passed/done through the no-assertions path,
- emit explicit observability/audit evidence for the auto-pass reason,
- continue normal slice/mission advancement checks.
- mark feature terminal as `status="done"`, `loopState="passed"`, `lastValidatorStatus="passed"`,
- emit explicit observability/audit evidence with mission event code `validation_auto_passed_no_assertions`,
- continue normal slice/mission advancement checks idempotently (no duplicate re-fire on repeated recovery).
### FN-5696 legacy shape clarification
A feature can show acceptance text while links are missing (legacy pre-repair data). This must be treated as a **linkage/data integrity problem**, not as proof that milestone text alone is enforced. The contract prevents ambiguity by separating:
A feature can show acceptance text while links are missing (legacy pre-repair data). This must be treated as a **linkage/data integrity problem**, not as proof that milestone text alone is enforced. Assertion authoring/backfill (FN-5696) is outside the execution loop; the loop must not synthesize `mission_feature_assertions` rows. The contract prevents ambiguity by separating:
- authored/informational text surfaces, from
- linked assertion enforcement surfaces.
@@ -141,7 +141,8 @@ Target surface: `packages/dashboard/app/components/MissionManager.tsx`
- done mission-linked tasks with linked assertions trigger validation,
- completion-trigger starts loop if needed,
- startup recovery replays done-implementing features with unpassed assertions,
- zero-linked-assertions path remains explicit auto-pass.
- periodic self-heal maintenance replays the same `recoverActiveMissions` path so historically stranded `implementing` features recover without restart,
- zero-linked-assertions path remains explicit canonical auto-pass.
3. **UI behavior**
- Implement the Step-2 label reconciliation and per-row indicator requirements.

4
docs/missions.md
View File

@@ -395,9 +395,9 @@ A feature transitions to `blocked` when:
- `MilestoneValidationRollup.state` reflects `blocked` assertions
- The feature remains in `blocked` state until operator intervention
On engine restart, `recoverActiveMissions()` re-enqueues features in `validating` or `needs_fix` states from the `activeValidations` set, ensuring no validation work is lost. It also re-triggers `implementing` features whose linked task is already `done`/`archived` and whose assertion validation has not passed yet.
On engine restart, `recoverActiveMissions()` re-enqueues features in `validating` or `needs_fix` states from the `activeValidations` set, ensuring no validation work is lost. It also re-triggers `implementing` features whose linked task is already `done`/`archived` and whose assertion validation has not passed yet. The same recovery path is replayed during periodic self-heal maintenance, so historically stranded `implementing` features can self-heal without requiring an engine restart.
For features with zero linked assertions, the completion path is explicit: the loop marks the feature `done`, advances `loopState` to `passed`, emits `validation:passed` with summary `"No assertions linked"`, and records mission event code `validation_auto_passed_no_assertions`.
For features with zero linked assertions, the completion path is explicit: the loop marks the feature `done`, advances `loopState` to `passed`, emits `validation:passed` with summary `"No assertions linked"`, and records mission event code `validation_auto_passed_no_assertions`. Contract details (including canonical no-assertions behavior and FN-5696 assertion-authoring separation) are defined in [Mission Completion Gate Contract](./missions-completion-contract.md).
### Autopilot / Scheduler Interplay