The Spec PR's Repair loop and Self-merge #146

Parent

#139

What to build

After the Spec review, the Spec PR goes through the same Repair loop a Run's pull request does, and a Spec run asked to merge ends with a Self-merge.

• Merge the Base branch into the Spec branch (never rebase), handing a conflict to a conflict Repair; push; watch CI on the head, handing red CI to a CI-fix Repair; go round again if the Base branch moved. The same Repair and upstream-move budgets, Declined CI fix and Policy refusal apply, with the Spec as the issue and the Spec branch as the Issue branch. Repair prompts name the Spec.
• The goal words apply to the Spec PR only: merge / --merge, or merge.always = true without no-merge, end with thirdshift Self-merging the Spec PR into the Base branch, then deleting the Spec branch and closing the Spec if the merge didn't. Otherwise the Spec run ends with the Spec PR ready for review.
• A Spec PR that fails in this phase follows the Failed run rules for its pull request (back to draft, unless only the Self-merge could not happen), and the Spec run exits 1.

Help and the README say that merge on a Spec merges the Spec PR, and that Tickets always merge into the Spec branch.

Acceptance criteria

• A Base branch that moved into a conflict with the Spec branch gets a conflict Repair, and the Spec run still ends with the Spec PR ready
• Red CI on the Spec PR's head gets a CI-fix Repair
• thirdshift merge <Spec URL> ends with the Spec PR merged into the Base branch with a merge commit, the Spec branch deleted on origin and the Spec closed
• merge.always = true does the same; with no-merge the Spec PR is left ready and unmerged
• A Policy refusal on the Spec PR leaves it ready for review and exits 1
• Repairs exhausted on the Spec PR end the Spec run with exit 1 and the Spec PR back to draft
• Help and README document how merge applies to a Spec run

Blocked by

• Spec review before the Spec PR is ready #142