Sub-roadmap: DAG runtime phase 4 — IntegrationCandidate and repair loop

[devkade]

Sub-roadmap: DAG runtime phase 4 — IntegrationCandidate and repair loop

Parent roadmap: #167
Related: #168, #190, #172, #189
Runtime-first sequence: phase 4 of 4
MVP inclusion: no — post-MVP hardening

Summary

Define and implement post-MVP convergence: failed or partial results generate repair tasks, verified worker outputs become IntegrationCandidate records, and integration dry-runs gate final completion.

Goal

Ilchul should be able to move from parallel task completion to safe convergence: repair what failed, combine what passed, and preserve evidence for final verification.

Scope

• Repair task creation rules.
• Repair budget consumption.
• Same-worker vs different-worker retry policy.
• Failed dependency downstream behavior.
• Task supersession model.
• IntegrationCandidate model.
• Integration dry-run workflow.
• Conflict detection and reporting.
• Regression/evaluation gate before final completion.
• Events for repair-created, task-superseded, integration-candidate-created, integration-started, integration-passed, integration-failed.

Non-goals

• No automatic merge to main/dev.
• No GitHub PR merge/tracker semantics in core.
• No destructive branch/worktree cleanup.
• No automatic objective weight changes.

Acceptance criteria

• Evaluation failures can create repair tasks.
• Repair tasks can supersede failed tasks.
• Repair budget is tracked.
• Passed worker outputs can become IntegrationCandidate records.
• Integration dry-run result is recorded.
• Conflicts block final integration and produce actionable evidence.
• Final completion requires integration evidence when integration is in scope.

Verification

• Unit tests for repair task generation.
• Unit tests for supersession.
• Unit tests for repair budget exhaustion.
• Integration dry-run fixture with clean result.
• Integration dry-run fixture with conflict result.

[devkade]

Design decision

needs-design is resolved by #167's Development Order.

Decisions:

• Sub-roadmap: DAG runtime phase 4 — IntegrationCandidate and repair loop #195 implements the post-MVP convergence loop described by Design: define integration, repair, and supersession semantics #190.
• It starts only after Sub-roadmap: DAG runtime phase 3 — worker execution, heartbeat, and evidence-gated completion #196 establishes evidence-gated worker execution.
• Evaluation failures may create repair tasks.
• Passed worker outputs may become IntegrationCandidate records.
• Dry-run integration records clean, conflict, or regression outcomes.
• Conflicts block final integration and must produce actionable evidence.
• Final completion requires integration evidence only when integration is in scope for the run.

Implementation can proceed as Step 8 of #167. This remains post-MVP hardening.