Current behavior
Evergreen checks for two issue types independently:
merge_conflict — merges main into the PR branch
failing_checks — fixes the code without merging main first
This causes push_to_pull_request_branch failures when the agent merges main locally (to understand the current state) but the incremental patch includes the merge commit, which conflicts with the remote PR branch that hasn't been merged yet.
Desired behavior
Every Evergreen run should follow this sequence:
- Check out the PR branch
- If main is ahead, merge main into the PR branch first — resolve any conflicts, get the branch up to date, push the merge
- Then check if CI passes — if not, fix the failing checks and push the fix
This is two separate pushes when both are needed:
- First push: the merge commit (gets the branch current with main)
- Second push: the CI fix (on top of the merged branch)
This avoids the patch conflict problem because each push is clean — the merge commit goes on top of the remote branch state, and the fix commit goes on top of the merged state.
Why this matters
Autoloop PRs accumulate iterations while main moves forward. The PR branch falls behind, and CI often fails because of drift (not because the iteration itself is broken). Merging main first often fixes CI on its own. When it doesn't, the agent has the full current codebase to work with when diagnosing the failure.
Changes needed
- Evergreen selector (
pr_needs_attention): also flag PRs that are behind main (add a behind_main issue type)
- Evergreen prompt (Workflow section): restructure the fix flow:
- Step 1: Always merge main if behind
- Step 2: Push the merge via
push_to_pull_request_branch
- Step 3: Check if CI is still failing after the merge
- Step 4: If still failing, diagnose and fix, push again
- Evergreen prompt (Rules section): explicitly state "do NOT merge main inside a CI-fix patch — that's a separate push"
Current behavior
Evergreen checks for two issue types independently:
merge_conflict— merges main into the PR branchfailing_checks— fixes the code without merging main firstThis causes
push_to_pull_request_branchfailures when the agent merges main locally (to understand the current state) but the incremental patch includes the merge commit, which conflicts with the remote PR branch that hasn't been merged yet.Desired behavior
Every Evergreen run should follow this sequence:
This is two separate pushes when both are needed:
This avoids the patch conflict problem because each push is clean — the merge commit goes on top of the remote branch state, and the fix commit goes on top of the merged state.
Why this matters
Autoloop PRs accumulate iterations while main moves forward. The PR branch falls behind, and CI often fails because of drift (not because the iteration itself is broken). Merging main first often fixes CI on its own. When it doesn't, the agent has the full current codebase to work with when diagnosing the failure.
Changes needed
pr_needs_attention): also flag PRs that are behind main (add abehind_mainissue type)push_to_pull_request_branch