[JacobStephens2]

Summary

After the Spec review, the Spec PR now goes through the same Repair loop as a Run's pull request. The Spec is the issue and the Spec branch is the Issue branch. A Spec run asked to merge ends with a Self-merge. To make that possible, the part of implement after the PR is ready moved into run::deliver, which both paths now call:

 run::implement
   implement session, push, mark_pr_ready
-  RepairLoop … Self-merge (inline)
+  run::deliver(issue, worktree, base, pr, goal, run_session)

 spec_run::run(spec, tickets, worktree, base, goal, logs)
   land_tickets → open_spec_pr (draft)
   review_and_deliver
     spec-review session, push, mark_pr_ready
+    run::deliver(spec, worktree, base, pr, goal, run_session)
+      Repair loop: merge Base branch, conflict / CI-fix Repairs, same budgets
+      Goal::Merged → Self-merge, delete Spec branch, close Spec if needed
   Err → failed_run::fail   # back to draft unless a Policy refusal

• merge / --merge, or merge.always without no-merge, now applies to the Spec PR. Tickets still always merge into the Spec branch.
• Repair prompts carry the Spec's URL, because the Spec is the issue passed to them.
• Help and the README's Spec runs section explain how merge applies to a Spec run.

Evidence

• Before: these new tests failed in tests/spec_run.rs: the conflict Repair, the CI-fix Repair, merge on a Spec, merge.always on a Spec, and help naming the Spec PR. The old test a_merge_ask_from_the_user_config_leaves_the_spec_pr_ready_for_review asserted that the Spec PR was left unmerged.
  After: cargo test passes in full. spec_run passes 36/36, including:

  • a_base_branch_that_moved_into_a_conflict_gets_a_conflict_repair_and_the_spec_pr_ends_ready
  • red_ci_on_the_spec_prs_head_gets_a_ci_fix_repair
  • merge_on_a_spec_self_merges_the_spec_pr_into_the_base_branch: a merge commit on main, issue-20 gone from origin, the Spec closed
  • a_merge_ask_from_the_user_config_self_merges_the_spec_pr and no_merge_on_a_spec_leaves_the_spec_pr_ready_while_its_tickets_still_merge
  • a_policy_refusal_on_the_spec_pr_leaves_it_ready_and_exits_1
  • repairs_exhausted_on_the_spec_pr_send_it_back_to_draft_and_exit_1

  Under heavy machine load, one full run hit a single failure in merge_run::ctrl_c_after_the_merge_finishes_the_post_merge_steps_and_exits_as_merged, a test that depends on signal timing. It then passed three times on its own, and a full --no-fail-fast rerun passed completely.

Merge Danger

Door: two-way

Blast Radius: Spec runs

With merge.always = true, a Spec run now merges the Spec PR into the Base branch. Before this change, that setting left the Spec PR for review. Runs on single issues behave the same; the deliver extraction doesn't change their logic.

Unaddressed findings

Standards

• Duplicated test helpers (base_moves_on, checks_on_head, commits_fix, GREEN/RED copied into tests/spec_run.rs): other test files already copy these the same way. Moving them into tests/support touches unrelated test files, so it belongs in its own cleanup.
• Long parameter lists / data clump on deliver and review_and_deliver: bundling issue/worktree/base/goal into a type would reshape RepairLoop as well, which is a larger refactor than this ticket.
• deliver is not a CONTEXT.md term: its doc comment defines it in glossary terms (Repair loop, Self-merge), and the codebase has no single existing word for both together.
• run.rs exposes deliver and mark_pr_ready to spec_run.rs: with two callers, a separate module is premature.

Spec

• No Spec-level tests for a Declined CI fix or the upstream-move budget: the acceptance criteria don't ask for them, and the shared run::deliver path is already covered by tests/ci.rs and tests/merge_run.rs.
• The closing comment says "by a thirdshift Merge run" for a Spec: this is cosmetic. Changing it would mean threading a label through after_merge and updating existing Merge run tests and the README.

Closes #146

🤖 Generated with Claude Code