fix(automerge): merge ready behind heads directly#679
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Codex review: needs maintainer review before merge. Reviewed July 18, 2026, 5:16 PM ET / 21:16 UTC. Summary Reproducibility: no. independently inspectable live reproduction artifact is included in the supplied context, but the added focused tests provide a clear source-level path for the Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge only after the exact reviewed head remains mergeable with all required checks green, using the accepted policy that GitHub repository rules—not a contributor rebase—decide whether base freshness is required. Do we have a high-confidence way to reproduce the issue? No independently inspectable live reproduction artifact is included in the supplied context, but the added focused tests provide a clear source-level path for the Is this the best way to solve the issue? Yes. Given the recorded maintainer decision, accepting only an exact reviewed, mergeable, green-checked head and leaving base-freshness enforcement to GitHub repository policy is the narrowest solution; the separate conflict gates remain intact. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8f6fb8fcb193. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (2 earlier review cycles) |
|
Maintainer decision: choose option 2 (accept exact-head-only direct merges for ordinary The intended ownership boundary is: ClawSweeper pins the reviewed contributor head with Local proof on |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Summary
BEHINDhead as an automatic repair/rebase requestBEHINDDIRTYandCONFLICTINGstates on the fail-closed repair path, including mixedBEHIND + CONFLICTINGobservationsRoot cause
ClawSweeper treated ordinary base drift as a required contributor-branch rewrite before attempting GitHub squash merge. A real local-container smoke with OpenClaw PR 108974 reproduced the consequence: rebasing the already-green PR onto current main made it inherit four unrelated typecheck failures that also reproduce on the exact main base alone.
GitHub can merge an otherwise-ready behind head with its normal three-way squash merge. The merge call remains pinned with
--match-head-commit; required checks, exact-head ClawSweeper review, review decisions, conflicts, and GitHub repository policy are unchanged.Validation
pnpm run checkFollow-up
The independent real-OpenClaw smoke PR will add a direct-automerge scenario because the current repair-only harness cannot exercise this route.