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>
76 lines
4.5 KiB
JSON
76 lines
4.5 KiB
JSON
{
|
|
"milestone": "execution-loop",
|
|
"round": 1,
|
|
"status": "fail",
|
|
"validatorsRun": {
|
|
"test": {
|
|
"passed": false,
|
|
"command": "pnpm test",
|
|
"exitCode": 1,
|
|
"note": "Test suite failed due to missing MissionExecutionLoop mock in serve.test.ts. Fix applied to add the mock, which resolves the immediate test failure. However, the broader test suite has pre-existing failures in merger.test.ts (buffer handling tests) that are unrelated to execution-loop feature."
|
|
},
|
|
"typecheck": {
|
|
"passed": true,
|
|
"command": "pnpm build",
|
|
"exitCode": 0
|
|
},
|
|
"lint": {
|
|
"passed": false,
|
|
"command": "pnpm lint",
|
|
"exitCode": 1,
|
|
"note": "Lint has 4217 pre-existing errors (mostly @typescript-eslint/no-explicit-any in test files and no-undef in .mjs scripts). These errors predate the execution-loop work and are not introduced by FEAT-004. Only 16 auto-fixable errors were fixed."
|
|
}
|
|
},
|
|
"reviewsSummary": {
|
|
"total": 1,
|
|
"passed": 0,
|
|
"failed": 1,
|
|
"failedFeatures": ["FEAT-004"]
|
|
},
|
|
"blockingIssues": [
|
|
{
|
|
"featureId": "FEAT-004",
|
|
"severity": "blocking",
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 317,
|
|
"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. Violates VAL-EL-006 (validation failure creates fix feature) and VAL-EL-007 (validation blocked)."
|
|
},
|
|
{
|
|
"featureId": "FEAT-004",
|
|
"severity": "blocking",
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 480,
|
|
"description": "notifyValidationComplete callback passes featureId to missionAutopilot.handleTaskCompletion(featureId), but handleTaskCompletion expects a taskId parameter. Inside MissionAutopilot.handleTaskCompletion, it calls getFeatureByTaskId(taskId) which receives a featureId and returns null, causing early-return without action. This breaks autopilot coordination for loop states (VAL-EL-012)."
|
|
},
|
|
{
|
|
"featureId": "FEAT-004",
|
|
"severity": "blocking",
|
|
"file": "packages/engine/src/mission-execution-loop.ts",
|
|
"line": 134,
|
|
"description": "recoverActiveMissions() only logs features in validating/needs_fix states but performs no state transitions or re-triggers. Features in 'validating' state remain stuck with no recovery path unless a new task completion event fires. Violates VAL-EL-009 which requires recovery to 're-enqueue pending validations'."
|
|
}
|
|
],
|
|
"appliedUpdates": [],
|
|
"suggestedGuidanceUpdates": [
|
|
{
|
|
"target": "AGENTS.md",
|
|
"suggestion": "Clarify TDD enforcement: AGENTS.md specifies 'write tests BEFORE implementation (TDD)' but no test file was created for MissionExecutionLoop despite the requirement. Consider requiring workers to show test file creation in the same commit as implementation, or adding a validation step that checks for test files.",
|
|
"evidence": "FEAT-004 handoff shows tests.added: [] despite AGENTS.md requiring TDD; mission-execution-loop.test.ts referenced in feature spec but never created",
|
|
"isSystemic": true
|
|
},
|
|
{
|
|
"target": "skills/backend-worker",
|
|
"suggestion": "Add guidance on AI response parsing: The worker skill procedure was followed correctly but the backend-worker skill does not document how to extract structured JSON from AI agent sessions. The parseValidationResult stub was left unimplemented due to this knowledge gap. Consider adding a library entry or skill section on 'Extracting structured data from AI sessions'.",
|
|
"evidence": "parseValidationResult at mission-execution-loop.ts:317 returns hardcoded pass; comment acknowledges 'don't have actual parsing logic'; parseValidatorResponse methods in fn-1587 worktree not committed",
|
|
"isSystemic": false
|
|
}
|
|
],
|
|
"rejectedObservations": [
|
|
{
|
|
"observation": "runId='unknown' fallback in createGeneratedFixFeature call would throw (line 492)",
|
|
"reason": "Non-blocking: This code path is unreachable because parseValidationResult always returns 'pass', so the catch block with createGeneratedFixFeature is never executed. The issue would only manifest if parseValidationResult were fixed, but it would also require fix in the runId fallback logic."
|
|
}
|
|
],
|
|
"previousRound": null
|
|
}
|