Design: define integration, repair, and supersession semantics

[devkade]

Design: define integration, repair, and supersession semantics

Parent: #167
Related: #168, #172

Summary

Define how failed or partial task outcomes create repair work, how repair tasks supersede failed tasks, and how verified worker outputs become IntegrationCandidate records.

Scope

Define:

• repair task creation rules;
• repair budget consumption;
• same-worker vs different-worker retry policy;
• failed dependency downstream behavior;
• task supersession semantics;
• IntegrationCandidate model;
• integration dry-run behavior;
• conflict and regression handling;
• final integration gate inputs.

Non-goals

• No automatic merge-to-main behavior.
• No destructive branch/worktree cleanup.
• No GitHub PR merge/tracker semantics in core.

Acceptance criteria

• Repair task generation rules are documented.
• Supersession rules are documented.
• IntegrationCandidate model is defined.
• Dry-run integration gate is defined.
• Conflict handling and rollback expectations are defined.
• Relationship between evaluation verdicts and repair/integration is explicit.

Verification

• Walkthroughs for clean integration, conflict repair, failed dependency, and exhausted repair budget.

[devkade]

Design decision

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

Decisions:

• Design: define integration, repair, and supersession semantics #190 is post-MVP hardening and must not block Sub-roadmap: DAG runtime phase 3 — worker execution, heartbeat, and evidence-gated completion #196.
• Repair tasks are created only from explicit evaluation/integration failures or stale ownership recovery paths.
• Repair consumes a tracked repair budget.
• Supersession is explicit: a repair task can satisfy a failed task's downstream dependency only when completion evidence says it supersedes the failed task.
• Integration candidates are refs to diffs, artifacts, branches, worktrees, or external resources; they are not automatic merges.
• Integration dry-run/conflict/regression checks gate final completion when integration is in scope.
• No automatic merge-to-main/dev or destructive cleanup belongs in this issue.

Implementation can proceed as Step 8 of #167 after worker/evidence MVP is proven.