537d0f3c05
Add MissionExecutionLoop mock to @fusion/engine vi.mock block in serve.test.ts. The mock provides start, stop, processTaskOutcome, and recoverActiveMissions methods to match the actual class interface. Also adds the scrutiny synthesis report for milestone execution-loop which identifies 3 blocking issues in FEAT-004: - parseValidationResult stub always returns pass - notifyValidationComplete passes featureId instead of taskId - recoverActiveMissions doesn't perform state transitions Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
63 lines
6.4 KiB
JSON
63 lines
6.4 KiB
JSON
{
|
|
"featureId": "FEAT-004",
|
|
"reviewedAt": "2026-04-11T18:30:00.000Z",
|
|
"commitId": "46fff0d3",
|
|
"transcriptSkeletonReviewed": true,
|
|
"diffReviewed": true,
|
|
"status": "fail",
|
|
"codeReview": {
|
|
"summary": "MissionExecutionLoop class is wired into dashboard.ts, serve.ts, InProcessRuntime, and scheduler. However, there are three blocking functional issues: (1) parseValidationResult is a stub that always returns status='pass', so validation failure/blocked handling is never exercised; (2) notifyValidationComplete passes featureId to handleTaskCompletion(taskId) which expects a taskId, causing MissionAutopilot to receive wrong input; (3) recoverActiveMissions only logs recovery intent but does not actually transition validating features back to implementing state, leaving them stuck.",
|
|
"issues": [
|
|
{
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 317,
|
|
"severity": "blocking",
|
|
"description": "parseValidationResult() is a stub that always returns { status: 'pass', assertions: all passed }. The comment explicitly says 'For now, return a default pass result since we don't have the actual parsing logic implemented'. This means validation failures are never detected, handleValidationFail is never called, and fix features are never generated. The VAL-EL-006 (validation failure creates fix feature) and VAL-EL-007 (validation blocked) outcomes are never exercised in practice."
|
|
},
|
|
{
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 480,
|
|
"severity": "blocking",
|
|
"description": "notifyValidationComplete callback passes featureId to missionAutopilot.handleTaskCompletion(featureId), but handleTaskCompletion expects a taskId parameter. Inside MissionAutopilot.handleTaskCompletion, it calls getFeatureByTaskId(taskId) which will receive a featureId and return null/undefined, causing the function to early-return without doing anything. This breaks the autopilot coordination for loop states (VAL-EL-012)."
|
|
},
|
|
{
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 134,
|
|
"severity": "blocking",
|
|
"description": "recoverActiveMissions() only logs the features it finds in 'validating' or 'needs_fix' states but never calls any state transition or re-triggers validation. Features in 'validating' state remain stuck in that state with no path to recovery unless a new task completion event fires. This violates VAL-EL-009 which requires recovery to 're-enqueue pending validations'."
|
|
},
|
|
{
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 492,
|
|
"severity": "non_blocking",
|
|
"description": "When parseValidationResult returns 'fail' (which never happens due to the stub), createGeneratedFixFeature is called with runId='unknown' fallback if runId is falsy. The store's createGeneratedFixFeature validates that runId exists and throws if not found. This would cause an unhandled error in the catch block of handleValidationFail, though this path is never reached due to the stub."
|
|
},
|
|
{
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 1,
|
|
"severity": "non_blocking",
|
|
"description": "MissionExecutionLoop extends EventEmitter and emits events (validation:passed, validation:failed, etc.) but there are no test files referencing these events. AGENTS.md specifies 'write tests BEFORE implementation (TDD)' but handoff shows tests.added: []. The referenced test file mission-execution-loop.test.ts does not exist."
|
|
}
|
|
]
|
|
},
|
|
"sharedStateObservations": [
|
|
{
|
|
"area": "conventions",
|
|
"observation": "AGENTS.md specifies TDD with tests written before implementation and references packages/engine/src/mission-execution-loop.test.ts as a key file to create. However, no test file was created and tests.added is empty in the handoff. The validation contract for VAL-EL-005 through VAL-EL-008 requires testing validation pass/fail/blocked flows, but there are no unit tests for any of these outcomes.",
|
|
"evidence": "handoff.tests.added: []; AGENTS.md Testing section says 'write tests BEFORE implementation (TDD)'; validation-contract.md VAL-EL-* items list 'vitest' as the Tool but no test file exists at packages/engine/src/mission-execution-loop.test.ts"
|
|
},
|
|
{
|
|
"area": "skills",
|
|
"observation": "The backend-worker skill procedure was followed according to skillFeedback.followedProcedure: true. However, the worker did not implement the AI response parsing logic (parseValidationResult stub) and did not wire the notifyValidationComplete callback correctly to MissionAutopilot. The backend-worker skill does not document how to extract structured JSON from AI agent sessions, which may have been a knowledge gap.",
|
|
"evidence": "parseValidationResult() always returns pass with a comment 'For now, return a default pass result since we don't have the actual parsing logic implemented'; transcript shows worker created the file but did not iterate on the parsing logic"
|
|
},
|
|
{
|
|
"area": "knowledge",
|
|
"observation": "The worker did not implement actual AI response parsing for the validator output. The extractResponseText() and parseValidatorResponse() methods that appear in the later version of the file (fn-1587 worktree) were not part of the committed implementation. The parsing logic is non-trivial - it requires extracting JSON from potentially multi-part AI responses. This knowledge is not documented in .factory/library/",
|
|
"evidence": "parseValidationResult at line 290-307 returns hardcoded pass result with comment acknowledging it's unimplemented; the worktree version (fusion/fn-1587) shows extractResponseText and parseValidatorResponse methods that handle JSON extraction from session state"
|
|
}
|
|
],
|
|
"addressesFailureFrom": null,
|
|
"summary": "FEAT-004 wiring is structurally complete (dashboard.ts, serve.ts, InProcessRuntime, scheduler integration all present) but has three blocking functional issues: (1) validation result parsing is a stub so failures/blocked never trigger fix feature generation; (2) notifyValidationComplete passes featureId to handleTaskCompletion(taskId) which expects taskId, breaking autopilot coordination; (3) recoverActiveMissions doesn't actually transition validating features. Additionally, no unit tests were written despite AGENTS.md requiring TDD. The implementation would not satisfy VAL-EL-005 through VAL-EL-009, VAL-EL-012 in an actual integration test."
|
|
}
|