PR creation fails if there are merge conflicts with intervening updates to target branch

[dsyme]

A proportion of our workflow failures are related to PR creation where there's been intervening updates, causing merge conflicts.

When there are no merge conflicts we just proceed and merge (which seems fine), but if there are merge conflicts we fail:

 :twisted_rightwards_arrows: Patch Apply Failed: The patch could not be applied to the current state of the repository. This is typically caused by a merge conflict between the agent's changes and recent commits on the target branch.
Failed Operations:
create_pull_request: Failed to apply patch

I'm guessing the problem is we're trying to create a PR against the head commit of the target branch - applying the patch direct to head branch - when we should be creating one against an earlier commit and accept the merge conflicts will show as soon as the PR is created.

[dsyme]

/scout please advice on options here

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @dsyme

Executive Summary

The root cause is confirmed: create_pull_request.cjs fetches the latest state of origin/${baseBranch} before creating the PR branch (line 672), so the patch — which was generated against an earlier checkout — is applied to a newer HEAD. When there are intervening commits that touch the same files, git am --3way fails and the whole PR creation aborts. Your intuition in the issue is correct: we should branch from the original base SHA instead of the current HEAD, apply the patch there (which always succeeds), and let GitHub surface the conflicts naturally in the resulting PR.

Click to expand detailed findings

Research Findings

Current implementation (create_pull_request.cjs, lines 667–731)

The failure sequence is:

1. git fetch origin ${baseBranch}          ← fetches newest HEAD
2. git checkout -b ${branchName}           ← new branch at newest HEAD
3. git am --3way ${patchFilePath}          ← patch was made against older SHA → CONFLICT → return { success: false }
```

No fallback to issue creation is triggered here — the function just returns `success: false`, which propagates as the "Patch Apply Failed" error shown in the issue.

---

#### Option 1 — Branch from original base SHA (lowest risk, recommended)

Record the repo's HEAD SHA at workflow start (the checkout SHA) and pass it as input to the create-pull-request action. When `git am --3way` fails:

1. `git am --abort`
2. `git checkout -b ${branchName} ${originalBaseSha}`  ← branch from old SHA
3. `git am ${patchFilePath}`  ← no conflicts, patch was made here
4. Push the branch and create the PR as normal

GitHub will detect the divergence from `${baseBranch}` and show a "This branch has conflicts" banner on the PR — but **the PR is created**, reviewers can see the work, and someone can rebase/resolve manually. This matches how human developers handle the same situation.

**Why this works:** the patch was generated from `${originalBaseSha}`, so applying it there is guaranteed to succeed. GitHub can compare any two arbitrary commits to produce a PR.

**Implementation note:** the workflow already has access to the checkout SHA (e.g. via `actions/checkout` output `sha` or `git rev-parse HEAD` captured before the agent runs). It just needs to be plumbed into the create-PR step and stored alongside the patch artifact.

---

#### Option 2 — Opportunistic rebase before falling back to Option 1

Before giving up, try a rebase:

```
git am --abort
git stash          ← not needed, but for clarity
git rebase origin/${baseBranch} ${branchName}

If the rebase succeeds (no overlapping changes), the PR is created cleanly with no conflicts visible. If it fails, fall back to Option 1.

This is a nice-to-have layered on top of Option 1 — worth doing but not required for the immediate fix.

---

Option 3 — git apply --reject for partial application

Use git apply --reject instead of git am, which applies all non-conflicting hunks and leaves .rej files for the conflicting ones. Commit what applied plus the .rej files. The PR is created with a partial implementation and a clear indicator of what didn't apply.

Downside: partial changes may not compile/test, and .rej files are noisy. Better as a last-resort fallback than a primary strategy.

---

Option 4 — Agent retry with conflict context

When a conflict is detected, re-trigger the agent with the conflict details + current HEAD as context, asking it to reattempt the task accounting for the intervening changes.

Tradeoff: expensive (full agent run), and not guaranteed to work if the intervening changes were significant. Better reserved for cases where Options 1–2 also fail and the conflict is semantically complex.

---

Recommendations

• Primary fix: implement Option 1. Capture the checkout SHA at workflow start, store alongside the patch, and use it as the branch base when git am fails on the current HEAD. This is a small, low-risk change to create_pull_request.cjs that turns failures into conflict-flagged PRs.
• Add Option 2 on top: before falling back to the old SHA, attempt a rebase so clean cases produce a clean PR.
• Adjust the fallback-as-issue path: the current fallback (creating an issue) is appropriate when patch application fails against the old base too (e.g. truly broken patch), but should not trigger for the conflict-with-newer-HEAD case now that Option 1 handles it.

Key Sources

• [git am --3way documentation]((gitscm.com/redacted) — --3way applies a three-way merge when the patch base is not present, but still fails on true content conflicts
• GitHub: A PR can be created with conflicts — "you can check out the pull request locally and merge it using the command line"
• Optio agent framework — similar agent loop that detects prChecksStatus=conflicts and resumes the agent with rebase instructions; useful prior art for Option 4

Suggested Next Steps

1. Add a base-sha input to the create-PR action (or capture it from the patch From <SHA> header) and thread it through to create_pull_request.cjs
2. In the catch (patchError) block (line 710), after git am --abort, retry branching from the original SHA
3. Add a test case in git_patch_integration.test.cjs covering the "newer HEAD, older patch" scenario
4. Update the conflict PR's body to include a banner noting the conflicts, so reviewers know what to expect

References:

• §23597603295 — Scout workflow run

🔭 Intelligence gathered by Scout · ◷

[dsyme]

Yes go ahead and do those steps (Option 2 falling back to Option 1)