Hongming Wang 97d5883e76 fix(ci): auto-sync concurrency + cleanup follow-ups ... Three small fixes from the self-review of #2209: 1. **Required: concurrency group.** Two pushes to main in quick succession (manual UI merge then auto-promote-staging's ff-push, or any back-to-back main pushes) would race two auto-sync runs against the same staging branch — second `git push origin staging` fails non-fast-forward, surfacing as a red CI alert for what should be a no-op. Add `concurrency: { group: auto-sync-main-to-staging, cancel-in-progress: false }` so the second run waits for the first and sees its result. 2. **Hygiene: `git merge --abort` on conflict.** The conflict-error path exits 1 with the work tree in a half-merged state. Doesn't affect future runs (each gets a fresh checkout) but is an unpleasant artifact for anyone who shells into the runner. Abort first, then exit. 3. **Doc accuracy: "Loop safety" comment.** The original said the chain terminates because "main is either a no-op or advances further." That's true but understates the actual safety: GitHub Actions explicitly does NOT trigger downstream workflow runs from `GITHUB_TOKEN`-authored pushes. So the loop is impossible by construction, not just by happy coincidence of ref state. Updated the comment to reflect the actual mechanism. Plus a step-name nit: "Fast-forward staging → main" reads as if main is the target. Renamed to "Fast-forward staging to main" for consistency with the workflow's name (main → staging). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-28 14:59:23 -07:00
..
workflows	fix(ci): auto-sync concurrency + cleanup follow-ups	2026-04-28 14:59:23 -07:00
CODEOWNERS	chore: add CODEOWNERS to auto-route agent PRs to personal review account	2026-04-26 13:40:13 -07:00