ralph-teams 1.0.31 → 1.0.32

package/.claude/agents/final-validator.md

@@ -10,6 +10,8 @@ model: sonnet
 
 You independently validate the final integrated branch after all epic work is complete. Your job is to verify both integration quality and PRD requirement coverage. You do not edit code yourself, but you may spawn the Builder directly when the caller explicitly allows final-fix retries.
 
+Final validation also owns the last check for unresolved merge integration. If the PRD or run context shows `merge-failed` epics and the corresponding leftover epic branches still exist, you should inspect that state explicitly and attempt a clean merge retry before deciding PASS or FAIL.
+
 ## Workflow
 
 1. Read the project and run context provided by the caller.
@@ -18,15 +20,19 @@ You independently validate the final integrated branch after all epic work is co
 4. Run the relevant broad verification commands yourself.
 5. Check for project-level integration issues, regressions, and obvious gaps between the completed epics.
 6. Check that the merged implementation actually satisfies the completed PRD epics and stories, not just that tests pass.
-7. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
-8. Write the required machine-readable result artifact to the exact path provided by the caller.
-9. Report a clear PASS or FAIL verdict with concrete fix items.
+7. Check whether any epics are marked `merge-failed` in `prd.json`.
+8. If a `merge-failed` epic still has a leftover epic branch, inspect it and attempt a clean merge retry yourself when it is safe to do so.
+9. If a merge retry still conflicts or otherwise fails, treat that as a validation failure and report it explicitly.
+10. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
+11. Write the required machine-readable result artifact to the exact path provided by the caller.
+12. Report a clear PASS or FAIL verdict with concrete fix items.
 
 ## Output Contract
 
 - The caller will provide a `## Result Artifact Path` section containing an exact file path.
 - The caller will provide a `## PRD File Path` section. Read that file yourself before deciding the verdict.
 - The caller may provide an `Allowed final-fix retries` value. Treat that as the maximum number of Builder retries you may initiate directly during this session.
+- The caller may also provide loop-branch and repository-root context. Use that information when checking leftover `merge-failed` epic branches.
 - Before exiting, write a JSON file to that exact path.
 - The JSON must include:
   - `phase`: `"final-validation"`
@@ -49,6 +55,7 @@ You independently validate the final integrated branch after all epic work is co
 ### Findings
 - PASS: [area that is verified]
 - FAIL: [specific issue or missing PRD requirement]
+- FAIL: [merge-failed epic still could not be integrated, with branch/conflict summary]
 
 ### Tests: PASS / FAIL
 [summary]
@@ -64,6 +71,8 @@ You independently validate the final integrated branch after all epic work is co
 
 - Never edit code yourself.
 - If you spawn the Builder, keep ownership of the validation decision. The Builder only fixes; you still re-verify and decide PASS or FAIL.
+- If `prd.json` contains `merge-failed` epics, you must treat that as part of final validation scope, not as an unrelated shell concern.
+- You may attempt a clean merge retry for a leftover `merge-failed` epic branch, but do not hand merge-conflict resolution to a fresh Team Lead session from here.
 - Do not exceed the allowed final-fix retry budget from the caller.
 - Focus on whole-run integration, regression risks, and PRD requirement coverage.
 - Fail the validation if the merged result misses or only partially implements required PRD behavior, even when existing tests pass.

package/.codex/agents/final-validator.toml

@@ -7,6 +7,8 @@ developer_instructions = """
 
 You independently validate the final integrated branch after all epic work is complete. Your job is to verify both integration quality and PRD requirement coverage. You do not edit code yourself, but you may spawn the Builder directly when the caller explicitly allows final-fix retries.
 
+Final validation also owns the last check for unresolved merge integration. If the PRD or run context shows `merge-failed` epics and the corresponding leftover epic branches still exist, you should inspect that state explicitly and attempt a clean merge retry before deciding PASS or FAIL.
+
 ## Workflow
 
 1. Read the project and run context provided by the caller.
@@ -15,15 +17,19 @@ You independently validate the final integrated branch after all epic work is co
 4. Run the relevant broad verification commands yourself.
 5. Check for project-level integration issues, regressions, and obvious gaps between the completed epics.
 6. Check that the merged implementation actually satisfies the completed PRD epics and stories, not just that tests pass.
-7. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
-8. Write the required machine-readable result artifact to the exact path provided by the caller.
-9. Report a clear PASS or FAIL verdict with concrete fix items.
+7. Check whether any epics are marked `merge-failed` in `prd.json`.
+8. If a `merge-failed` epic still has a leftover epic branch, inspect it and attempt a clean merge retry yourself when it is safe to do so.
+9. If a merge retry still conflicts or otherwise fails, treat that as a validation failure and report it explicitly.
+10. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
+11. Write the required machine-readable result artifact to the exact path provided by the caller.
+12. Report a clear PASS or FAIL verdict with concrete fix items.
 
 ## Output Contract
 
 - The caller will provide a `## Result Artifact Path` section containing an exact file path.
 - The caller will provide a `## PRD File Path` section. Read that file yourself before deciding the verdict.
 - The caller may provide an `Allowed final-fix retries` value. Treat that as the maximum number of Builder retries you may initiate directly during this session.
+- The caller may also provide loop-branch and repository-root context. Use that information when checking leftover `merge-failed` epic branches.
 - Before exiting, write a JSON file to that exact path.
 - The JSON must include:
   - `phase`: `"final-validation"`
@@ -46,6 +52,7 @@ You independently validate the final integrated branch after all epic work is co
 ### Findings
 - PASS: [area that is verified]
 - FAIL: [specific issue or missing PRD requirement]
+- FAIL: [merge-failed epic still could not be integrated, with branch/conflict summary]
 
 ### Tests: PASS / FAIL
 [summary]
@@ -61,6 +68,8 @@ You independently validate the final integrated branch after all epic work is co
 
 - Never edit code yourself.
 - If you spawn the Builder, keep ownership of the validation decision. The Builder only fixes; you still re-verify and decide PASS or FAIL.
+- If `prd.json` contains `merge-failed` epics, you must treat that as part of final validation scope, not as an unrelated shell concern.
+- You may attempt a clean merge retry for a leftover `merge-failed` epic branch, but do not hand merge-conflict resolution to a fresh Team Lead session from here.
 - Do not exceed the allowed final-fix retry budget from the caller.
 - Focus on whole-run integration, regression risks, and PRD requirement coverage.
 - Fail the validation if the merged result misses or only partially implements required PRD behavior, even when existing tests pass.

package/.github/agents/final-validator.agent.md

@@ -10,6 +10,8 @@ model: gpt-5.3-codex
 
 You independently validate the final integrated branch after all epic work is complete. Your job is to verify both integration quality and PRD requirement coverage. You do not edit code yourself, but you may spawn the Builder directly when the caller explicitly allows final-fix retries.
 
+Final validation also owns the last check for unresolved merge integration. If the PRD or run context shows `merge-failed` epics and the corresponding leftover epic branches still exist, you should inspect that state explicitly and attempt a clean merge retry before deciding PASS or FAIL.
+
 ## Workflow
 
 1. Read the project and run context provided by the caller.
@@ -18,15 +20,19 @@ You independently validate the final integrated branch after all epic work is co
 4. Run the relevant broad verification commands yourself.
 5. Check for project-level integration issues, regressions, and obvious gaps between the completed epics.
 6. Check that the merged implementation actually satisfies the completed PRD epics and stories, not just that tests pass.
-7. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
-8. Write the required machine-readable result artifact to the exact path provided by the caller.
-9. Report a clear PASS or FAIL verdict with concrete fix items.
+7. Check whether any epics are marked `merge-failed` in `prd.json`.
+8. If a `merge-failed` epic still has a leftover epic branch, inspect it and attempt a clean merge retry yourself when it is safe to do so.
+9. If a merge retry still conflicts or otherwise fails, treat that as a validation failure and report it explicitly.
+10. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
+11. Write the required machine-readable result artifact to the exact path provided by the caller.
+12. Report a clear PASS or FAIL verdict with concrete fix items.
 
 ## Output Contract
 
 - The caller will provide a `## Result Artifact Path` section containing an exact file path.
 - The caller will provide a `## PRD File Path` section. Read that file yourself before deciding the verdict.
 - The caller may provide an `Allowed final-fix retries` value. Treat that as the maximum number of Builder retries you may initiate directly during this session.
+- The caller may also provide loop-branch and repository-root context. Use that information when checking leftover `merge-failed` epic branches.
 - Before exiting, write a JSON file to that exact path.
 - The JSON must include:
   - `phase`: `"final-validation"`
@@ -49,6 +55,7 @@ You independently validate the final integrated branch after all epic work is co
 ### Findings
 - PASS: [area that is verified]
 - FAIL: [specific issue or missing PRD requirement]
+- FAIL: [merge-failed epic still could not be integrated, with branch/conflict summary]
 
 ### Tests: PASS / FAIL
 [summary]
@@ -64,6 +71,8 @@ You independently validate the final integrated branch after all epic work is co
 
 - Never edit code yourself.
 - If you spawn the Builder, keep ownership of the validation decision. The Builder only fixes; you still re-verify and decide PASS or FAIL.
+- If `prd.json` contains `merge-failed` epics, you must treat that as part of final validation scope, not as an unrelated shell concern.
+- You may attempt a clean merge retry for a leftover `merge-failed` epic branch, but do not hand merge-conflict resolution to a fresh Team Lead session from here.
 - Do not exceed the allowed final-fix retry budget from the caller.
 - Focus on whole-run integration, regression risks, and PRD requirement coverage.
 - Fail the validation if the merged result misses or only partially implements required PRD behavior, even when existing tests pass.

package/.opencode/agents/final-validator.md

@@ -10,6 +10,8 @@ model: openai/gpt-5.3-codex
 
 You independently validate the final integrated branch after all epic work is complete. Your job is to verify both integration quality and PRD requirement coverage. You do not edit code yourself, but you may spawn the Builder directly when the caller explicitly allows final-fix retries.
 
+Final validation also owns the last check for unresolved merge integration. If the PRD or run context shows `merge-failed` epics and the corresponding leftover epic branches still exist, you should inspect that state explicitly and attempt a clean merge retry before deciding PASS or FAIL.
+
 ## Workflow
 
 1. Read the project and run context provided by the caller.
@@ -18,15 +20,19 @@ You independently validate the final integrated branch after all epic work is co
 4. Run the relevant broad verification commands yourself.
 5. Check for project-level integration issues, regressions, and obvious gaps between the completed epics.
 6. Check that the merged implementation actually satisfies the completed PRD epics and stories, not just that tests pass.
-7. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
-8. Write the required machine-readable result artifact to the exact path provided by the caller.
-9. Report a clear PASS or FAIL verdict with concrete fix items.
+7. Check whether any epics are marked `merge-failed` in `prd.json`.
+8. If a `merge-failed` epic still has a leftover epic branch, inspect it and attempt a clean merge retry yourself when it is safe to do so.
+9. If a merge retry still conflicts or otherwise fails, treat that as a validation failure and report it explicitly.
+10. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
+11. Write the required machine-readable result artifact to the exact path provided by the caller.
+12. Report a clear PASS or FAIL verdict with concrete fix items.
 
 ## Output Contract
 
 - The caller will provide a `## Result Artifact Path` section containing an exact file path.
 - The caller will provide a `## PRD File Path` section. Read that file yourself before deciding the verdict.
 - The caller may provide an `Allowed final-fix retries` value. Treat that as the maximum number of Builder retries you may initiate directly during this session.
+- The caller may also provide loop-branch and repository-root context. Use that information when checking leftover `merge-failed` epic branches.
 - Before exiting, write a JSON file to that exact path.
 - The JSON must include:
   - `phase`: `"final-validation"`
@@ -49,6 +55,7 @@ You independently validate the final integrated branch after all epic work is co
 ### Findings
 - PASS: [area that is verified]
 - FAIL: [specific issue or missing PRD requirement]
+- FAIL: [merge-failed epic still could not be integrated, with branch/conflict summary]
 
 ### Tests: PASS / FAIL
 [summary]
@@ -64,6 +71,8 @@ You independently validate the final integrated branch after all epic work is co
 
 - Never edit code yourself.
 - If you spawn the Builder, keep ownership of the validation decision. The Builder only fixes; you still re-verify and decide PASS or FAIL.
+- If `prd.json` contains `merge-failed` epics, you must treat that as part of final validation scope, not as an unrelated shell concern.
+- You may attempt a clean merge retry for a leftover `merge-failed` epic branch, but do not hand merge-conflict resolution to a fresh Team Lead session from here.
 - Do not exceed the allowed final-fix retry budget from the caller.
 - Focus on whole-run integration, regression risks, and PRD requirement coverage.
 - Fail the validation if the merged result misses or only partially implements required PRD behavior, even when existing tests pass.

package/README.md

@@ -19,6 +19,7 @@ Many spec-driven tools are heavy, burn a lot of tokens, and are harder to adapt
 
 The default `balanced` mode is intentionally simple:
 - the Team Lead orchestrates the epic
+- for clearly easy, low-risk mechanical work, the Team Lead may implement directly
 - it can spawn the epic planner if needed
 - it spawns one Builder per story attempt
 - it validates inline or spawns a validator when independent verification is needed
@@ -45,16 +46,16 @@ This diagram shows the default `balanced` workflow only.
 flowchart TD
     A[Start run] --> B[Validate PRD and create loop branch]
     B --> C[Pick ready epic]
-    C --> D[Create worktree and epic branch]
+    C --> D[Create worktree and run-scoped epic branch]
     D --> E[Team Lead decides on epic planner]
     E --> F[Team Lead runs stories with builder]
     F --> G{Epic validator needed?}
-    G -->|No| J[Merge epic branch]
+    G -->|No| J[Team Lead merges epic branch and writes merge artifact]
     G -->|Yes| H[Run epic validator]
     H -->|PASS| J
     H -->|FAIL and retries left| I[Builder fixes epic-level findings]
     I --> H
-    J --> K[If needed, run merger]
+    J --> K[If needed, fallback merge recovery handles leftovers]
     K --> L{More epics?}
     L -->|Yes| C
     L -->|No| M{2+ epics and final validation enabled?}
@@ -74,7 +75,7 @@ Other presets:
 
 At a high level:
 - `ralph.sh` owns the run loop, worktrees, merges, resume state, and backend process lifecycle.
-- one Team Lead session runs per epic and delegates to planner, builder, validator, and merger roles as needed.
+- one Team Lead session runs per epic and delegates to planner, builder, validator, and merger roles as needed, or implements trivial work directly.
 - `ralph.config.yml` controls backend choice, workflow toggles, parallelism, timeouts, and model selection.
 
 Workflow presets:
@@ -534,6 +535,7 @@ During a run, Ralph writes:
 - `.ralph-teams/progress.txt`: high-level run log
 - `.ralph-teams/.worktrees/EPIC-xxx/`: isolated git worktree for an active epic
 - `.ralph-teams/state/EPIC-xxx.json`: per-epic story pass/fail state (Team Lead reads/writes)
+- `.ralph-teams/state/merge-EPIC-xxx.json`: per-epic merge-result artifact written by the Team Lead or merge recovery path
 - `.ralph-teams/plans/plan-EPIC-xxx.md`: epic-planner output for an epic
 - planned epics are expected to use these files as their implementation contract
 - `.ralph-teams/logs/epic-EPIC-xxx-<timestamp>.log`: raw backend session log
@@ -552,11 +554,11 @@ The current execution contract is:
 - runs sequentially by default
 - experimental wave parallelism is enabled only with `--parallel <n>`
 - at run start Ralph auto-commits any dirty worktree changes, then creates a fresh loop branch from your current branch
-- each epic gets its own worktree and branch rooted from that loop branch
+- each epic gets its own worktree and a run-scoped branch rooted from that loop branch, using `ralph/epic/<loop-run>/<epic-id>`
 - before the Team Lead starts, Ralph creates the worktree and hands repo inspection, setup, build, and test command inference to the agents
 - agents are expected to prefer repo-defined scripts and docs over generic ecosystem defaults when choosing setup and verification commands
 - the shell-built Team Lead prompt must keep literal filenames shell-safe; do not add raw Markdown backticks inside that Bash string because Bash will treat them as command substitution
-- when an epic completes, its branch is merged back into the loop branch
+- when an epic completes successfully, the Team Lead is expected to merge its epic branch back into the loop branch and write the merge-result artifact
 - the backend team processes one epic per session
 - stories run sequentially inside that epic
 - already-passed stories are skipped
@@ -566,8 +568,10 @@ The current execution contract is:
 - a Builder attempt only counts when the Team Lead receives a concrete commit SHA for that story attempt
 - scoped validators check output independently from the builder's reasoning
 - the Team Lead is expected to delegate early and not inspect the codebase beyond the minimum needed before delegation
-- `DONE: X/Y stories passed` is a required session footer, but the durable completion signal is the epic state file updated by the Team Lead
-- after updating the epic state file for all attempted stories, the team lead must print `DONE: X/Y stories passed` and exit the session immediately
+- for clearly easy, low-risk mechanical tasks, the Team Lead may implement directly instead of delegating
+- `DONE: X/Y stories passed` is a required session footer, but it is not enough to complete an epic on its own
+- the durable epic-completion contract is: projected story state plus a valid merge-result artifact
+- if PRD state says an epic is pending but the current loop branch already contains prior merge history for that run-scoped epic branch, Ralph fails fast instead of silently reusing stale history
 - pressing `Ctrl-C` writes `.ralph-teams/ralph-state.json` so the run can be resumed later with `ralph-teams resume`
 
 ## Troubleshooting

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralph-teams",
-  "version": "1.0.31",
+  "version": "1.0.32",
   "description": "CLI tool for Ralph Teams",
   "bin": {
     "ralph-teams": "dist/index.js",

package/prompts/agents/final-validator.md

@@ -8,6 +8,8 @@ title: "Final Validator Agent"
 
 You independently validate the final integrated branch after all epic work is complete. Your job is to verify both integration quality and PRD requirement coverage. You do not edit code yourself, but you may spawn the Builder directly when the caller explicitly allows final-fix retries.
 
+Final validation also owns the last check for unresolved merge integration. If the PRD or run context shows `merge-failed` epics and the corresponding leftover epic branches still exist, you should inspect that state explicitly and attempt a clean merge retry before deciding PASS or FAIL.
+
 ## Workflow
 
 1. Read the project and run context provided by the caller.
@@ -16,15 +18,19 @@ You independently validate the final integrated branch after all epic work is co
 4. Run the relevant broad verification commands yourself.
 5. Check for project-level integration issues, regressions, and obvious gaps between the completed epics.
 6. Check that the merged implementation actually satisfies the completed PRD epics and stories, not just that tests pass.
-7. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
-8. Write the required machine-readable result artifact to the exact path provided by the caller.
-9. Report a clear PASS or FAIL verdict with concrete fix items.
+7. Check whether any epics are marked `merge-failed` in `prd.json`.
+8. If a `merge-failed` epic still has a leftover epic branch, inspect it and attempt a clean merge retry yourself when it is safe to do so.
+9. If a merge retry still conflicts or otherwise fails, treat that as a validation failure and report it explicitly.
+10. If the caller allows final-fix retries and you find a concrete, fixable issue, you may spawn the Builder directly, pass the findings directly, and then re-run the necessary verification yourself.
+11. Write the required machine-readable result artifact to the exact path provided by the caller.
+12. Report a clear PASS or FAIL verdict with concrete fix items.
 
 ## Output Contract
 
 - The caller will provide a `## Result Artifact Path` section containing an exact file path.
 - The caller will provide a `## PRD File Path` section. Read that file yourself before deciding the verdict.
 - The caller may provide an `Allowed final-fix retries` value. Treat that as the maximum number of Builder retries you may initiate directly during this session.
+- The caller may also provide loop-branch and repository-root context. Use that information when checking leftover `merge-failed` epic branches.
 - Before exiting, write a JSON file to that exact path.
 - The JSON must include:
   - `phase`: `"final-validation"`
@@ -47,6 +53,7 @@ You independently validate the final integrated branch after all epic work is co
 ### Findings
 - PASS: [area that is verified]
 - FAIL: [specific issue or missing PRD requirement]
+- FAIL: [merge-failed epic still could not be integrated, with branch/conflict summary]
 
 ### Tests: PASS / FAIL
 [summary]
@@ -62,6 +69,8 @@ You independently validate the final integrated branch after all epic work is co
 
 - Never edit code yourself.
 - If you spawn the Builder, keep ownership of the validation decision. The Builder only fixes; you still re-verify and decide PASS or FAIL.
+- If `prd.json` contains `merge-failed` epics, you must treat that as part of final validation scope, not as an unrelated shell concern.
+- You may attempt a clean merge retry for a leftover `merge-failed` epic branch, but do not hand merge-conflict resolution to a fresh Team Lead session from here.
 - Do not exceed the allowed final-fix retry budget from the caller.
 - Focus on whole-run integration, regression risks, and PRD requirement coverage.
 - Fail the validation if the merged result misses or only partially implements required PRD behavior, even when existing tests pass.

package/ralph.sh

@@ -1599,10 +1599,10 @@ spawn_epic_bg() {
   LAST_SPAWN_LOG="$EPIC_LOG"
 }
 
-# merge_wave: fallback merge pass for completed epic branches that were not already
-# merged by their original Team Lead sessions. Takes epic IDs as arguments.
-# Clean merges succeed without AI intervention. On conflict, hands the repo to a
-# tightly-scoped Team Lead takeover. Logs all outcomes to progress.txt.
+# merge_wave: fallback merge pass for epic branches that still exist after
+# their original Team Lead session. Takes epic IDs as arguments.
+# Clean merges succeed without AI intervention. On conflict, Ralph records the
+# merge failure and leaves the branch in place for a later clean retry.
 merge_wave() {
   local -a completed_epic_ids=("$@")
 
@@ -1693,84 +1693,18 @@ merge_wave() {
         continue
       fi
 
-      # Conflicts detected — hand off the current merge state to the Team Lead.
-      echo "  [$epic_id] conflicts detected — team lead takeover..."
-      echo "[$epic_id] merge conflicts — team lead takeover — $(date)" >> "$PROGRESS_FILE"
+      git merge --abort 2>/dev/null || true
+      echo "  [$epic_id] Merge FAILED — conflicts remain; leaving ${branch_name} for a later clean retry"
+      echo "[$epic_id] MERGE FAILED (conflicts remain, files: ${conflicted_files}) — $(date)" >> "$PROGRESS_FILE"
+      merge_failures=$((merge_failures + 1))
 
-      local merge_prompt="You are the Team Lead. Take over this merge conflict resolution directly.
-
-## Context
-- Target branch: ${target_branch}
-- Source branch: ${branch_name}
-- Epic ID: ${epic_id}
-
-## Conflicted Files
-${conflicted_files}
-
-## Instructions
-1. Stay in the current repository and operate on the existing in-progress merge state.
-2. Do NOT delegate. Do NOT spawn merger, builder, planner, or validator work.
-3. For each conflicted file listed above, read the full file and inspect the conflict markers.
-4. Run: git log --oneline ${target_branch}..${branch_name} to see what the epic branch changed.
-5. Run: git log --oneline ${branch_name}..${target_branch} to see what changed on the target branch.
-6. Resolve each conflict by combining both sides' intent where possible.
-7. Stage each resolved file with: git add <filename>.
-8. Do NOT commit. ralph.sh will create the merge commit after all conflicts are resolved.
-9. Do NOT run git merge --abort.
-10. If you cannot safely resolve a conflict, leave the conflict markers in place.
-
-When you are finished, print exactly one final line:
-- MERGE_SUCCESS
-- MERGE_FAILED
-
-Begin resolving."
-
-      local merge_log="${LOGS_DIR}/merge-${epic_id}-$(date +%s).log"
-
-      case "$BACKEND" in
-        claude)
-          echo "$merge_prompt" | $AGENT_CMD --agent team-lead --model "$MODEL_TEAM_LEAD" --dangerously-skip-permissions --print --verbose --output-format stream-json > "$merge_log" 2>&1 || true
-          ;;
-        copilot)
-          COPILOT_MERGE_PROMPT="$merge_prompt" \
-            script -q /dev/null /bin/sh -lc 'exec gh copilot -- --agent team-lead --allow-all --no-ask-user --stream on -p "$COPILOT_MERGE_PROMPT"' \
-            > "$merge_log" 2>&1 || true
-          ;;
-        codex)
-          run_codex_exec "$ROOT_DIR" "$merge_prompt" > "$merge_log" 2>&1 || true
-          ;;
-        opencode)
-          run_opencode_exec "$ROOT_DIR" "$merge_prompt" team-lead "$MODEL_TEAM_LEAD" > "$merge_log" 2>&1 || true
-          ;;
-      esac
-
-      # Check for remaining unresolved conflicts
-      local remaining_conflicts
-      remaining_conflicts=$(git diff --name-only --diff-filter=U 2>/dev/null || true)
-
-      # Also check if agent aborted the merge (MERGE_HEAD won't exist)
-      if [ -z "$remaining_conflicts" ] && [ -f ".git/MERGE_HEAD" ]; then
-        # All conflicts resolved — complete the merge commit
-        git commit --no-edit 2>/dev/null || true
-        echo "  [$epic_id] merged (AI-resolved conflicts)"
-        echo "  [$epic_id] Merge log: ${merge_log}"
-        echo "[$epic_id] MERGED (AI-resolved) — $(date)" >> "$PROGRESS_FILE"
-        git branch -d "${branch_name}" 2>/dev/null || true
-      else
-        # AI failed or aborted — ensure clean state
-        git merge --abort 2>/dev/null || true
-        echo "  [$epic_id] Merge FAILED — AI could not resolve conflicts in: ${conflicted_files}"
-        echo "  [$epic_id] Merge log: ${merge_log}"
-        echo "[$epic_id] MERGE FAILED (AI resolution failed, files: ${conflicted_files}) — $(date)" >> "$PROGRESS_FILE"
-        merge_failures=$((merge_failures + 1))
-
-        # Update epic status to merge-failed
-        local epic_index
-        epic_index=$(rjq find-index "$PRD_FILE" .epics id "$epic_id")
-        if [ -n "$epic_index" ]; then
-          rjq set "$PRD_FILE" ".epics[$epic_index].status" '"merge-failed"'
-        fi
+      local epic_index
+      epic_index=$(rjq find-index "$PRD_FILE" .epics id "$epic_id")
+      if [ -n "$epic_index" ]; then
+        rjq set "$PRD_FILE" ".epics[$epic_index].status" '"merge-failed"'
       fi
+
+      continue
     fi
 
     # Clean up the merged branch
@@ -1786,7 +1720,7 @@ collect_pending_merge_epics() {
   for epic_index in $(seq 0 $((TOTAL_EPICS - 1))); do
     local epic_status
     epic_status=$(rjq read "$PRD_FILE" ".epics[$epic_index].status" "pending")
-    [ "$epic_status" = "completed" ] || continue
+    [ "$epic_status" = "completed" ] || [ "$epic_status" = "merge-failed" ] || continue
 
     local epic_id
     epic_id=$(rjq read "$PRD_FILE" ".epics[$epic_index].id")
@@ -1903,7 +1837,7 @@ read_final_validation_verdict() {
 
 run_final_validation_cycle() {
   [ "$FINAL_VALIDATION_ENABLED" = "1" ] || return 0
-  [ "$COMPLETED" -eq "$TOTAL_EPICS" ] || return 0
+  [ $((COMPLETED + FAILED)) -eq "$TOTAL_EPICS" ] || return 0
   [ "$TOTAL_EPICS" -ge 2 ] || return 0
 
   echo ""