feat: add merge automation to conductor agent

[geoffjay]

feat: add merge automation to conductor agent

feat(conductor): add detailed merge automation with CI verification and stack ordering

Expand the conductor agent's merge queue management with a complete step-by-step
merge flow and a new merge-worker.yml workflow that drives it.

conductor.yml changes:

• Replace the minimal "Performing a Merge" section with an 8-step merge flow:
  1. Fetch full PR metadata (mergeable, reviews, CI rollup)
  2. Verify CI status using gh pr checks and statusCheckRollup jq filters;
     defer on PENDING, remove merge-ready and comment on FAILURE
  3. Verify ≥1 approval and no unresolved change requests (latest review per
     author via group_by/sort_by jq); add needs-rework if changes requested
  4. Verify no merge conflict via gh pr view --json mergeable; add
     needs-restack on CONFLICTING
  5. Verify stack prerequisites: base PR must be merged before child merges
  6. Squash-merge with gh pr merge --squash --delete-branch
  7. Post-merge restack: git-spice repo sync + git-spice stack submit
  8. Announce result to operations room and store in shared memory
• Update Session Start to sort merge queue by base branch and flag CI failures
• Expand Conflict Escalation with concrete commands: detect branch, find PR,
  add needs-restack label, post structured message to engineering room

merge-worker.yml:

• New workflow triggered by merge-ready label on github_pull_requests source
• Dispatches to the conductor agent with a complete, executable prompt template
• Template mirrors the 10-step merge flow from conductor.yml including all jq
  filters, decision rules, and escalation paths

Closes #644

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

[geoffjay]

This change is part of the following stack:

• feat: add merge automation to conductor agent #704 ◀

_{Change managed by git-spice.}

[geoffjay]

@/private/tmp/claude-501/pr704-review.txt

[geoffjay]

Review: feat(conductor): add detailed merge automation with CI verification and stack ordering

This is a solid, well-structured improvement over the previous minimal merge section. The 8-step flow is operationally complete, the jq filters are correct (the group_by/sort_by/last pattern for latest-review-per-author is right and consistent with GitHub's actual merge eligibility logic), and the three-way CI state split (PENDING/defer, FAILED/remove label, PASSED/continue) is exactly the right model. The explicit handling of UNKNOWN mergeable state is a good catch.

No blocking issues. A few suggestions worth considering before or after merge:

---

🟡 git-spice stack submit scope note was removed without being resolved

The old merge-worker.yml contained this caveat:

git-spice stack submit resubmits from the conductor's current working-directory branch, which may include branches beyond the direct dependents of the just-merged PR. When the conductor's full session context is formalised, this can be scoped to git-spice upstack submit from the merged branch.

That concern is still live. If the conductor happens to be checked out on an unrelated branch when it runs Step 8, git-spice stack submit will resubmit the wrong set of PRs. The note was there as a known-issue marker and removing it without a fix risks the problem being forgotten.

Suggested fix: restore the note as a comment, or switch to:

# Resubmit only the upstack of the just-merged PR, not the full conductor stack
git checkout <base-of-merged-pr>
git-spice upstack submit --fill --no-prompt

---

🟡 Step 1 (merge-worker.yml) runs git-spice repo sync before any gating checks

Running git-spice repo sync as the very first action means a lingering rebase conflict from a previous run can abort the workflow before CI, approval, or mergeability have even been checked. The conductor system prompt correctly places git-spice repo sync as a post-merge step (Step 7) — doing it eagerly at session start adds a pre-gate failure surface.

Suggestion: make Step 1 read-only (git-spice log short only) and keep git-spice repo sync scoped to Step 8 where it belongs.

---

🟡 Step 3 CI FAILED path is prose-only in the workflow template

The template says:

If FAILED — remove merge-ready, comment on the PR, notify operations

...but doesn't include the gh pr comment command inline. The conductor system prompt has the full command under "Handling CI Failures". For an agent executing the workflow template standalone, the missing command could be filled in incorrectly. Consider inlining the comment command to make the template self-contained.

---

🟡 sort_by(.baseRefName) in Session Start is not a reliable stack-order proxy

Sorting by base branch name alphabetically (sort_by(.baseRefName)) is a rough heuristic. It works for the common case (feature/autonomous-pipeline sorts before issue-NNN) but will give incorrect ordering for any branch naming scheme that doesn't sort alphabetically by depth. This is only the session overview query (not the actual merge gate), so it's cosmetic — but calling it "stack order" may mislead. A comment clarifying it's an approximation would help.

---

🟡 Step 6 base-branch check: gh pr list --state merged misses branchless bases

The new check:

gh pr list --repo geoffjay/agentd --head "$BASE" --state merged --json number,title

...only finds base branches that had a PR. A branch pushed directly without a PR (raw push, or an old branch) returns empty and would incorrectly block the merge. The previous git ls-remote --heads origin "$BASE_REF" | wc -l check (0 = gone/merged, 1 = still open) was more robust. Unlikely to matter in practice given this project's PR-first workflow, but worth noting.

---

Stack note: issue-644 stacks directly on feature/autonomous-pipeline — no open parent PRs in the way.