Remove sync-branches workflow — broken on this repo and redundant with per-iteration branch hygiene (#179)

Bắt đầu bằng cách xóa .github/workflows/sync-branches.md và .github/workflows/sync-branches.lock.yml, sau đó tìm trong repository các tham chiếu đến sync-branches trong tài liệu và hướng dẫn. Đọc autoloop.md Step 3 và xác minh rằng phần này vẫn mô tả việc xử lý độ mới của branch. Hoàn tất khi cả hai tệp workflow và các tham chiếu tài liệu đã lỗi thời đều được xóa, không cần thay đổi Step 3.

Summary

Delete .github/workflows/sync-branches.md and .github/workflows/sync-branches.lock.yml. The workflow is currently broken and doing no useful work.

Current state — it doesn't work

Every recent run of sync-branches is failing. Two overlapping problems:

1. Lock-file drift. sync-branches.md has been edited without running gh aw compile sync-branches, so the activation step bails out with:

   ##[error]ERR_CONFIG: Lock file '.github/workflows/sync-branches.lock.yml' is outdated!
   The workflow file '.github/workflows/sync-branches.md' frontmatter has changed.
   Run 'gh aw compile' to regenerate the lock file.
   

2. Even if we re-compiled it, it wouldn't push. The workflow declares permissions: read-all (to pass gh-aw's strict-mode compile check); that compiles to an empty permissions: {} in the lock file; which means the default GITHUB_TOKEN has no write access. No GH_AW_GITHUB_TOKEN PAT is configured in this repo (gh secret list returns empty). Any git push attempt would be rejected with 403.

The Python script uses capture_output=True and appends to a failed list — it does not fail the workflow on push errors. So before the lock-file drift, the workflow was silently reporting green while syncing zero branches.

Why we don't need it anyway

The per-iteration Step 3 logic in autoloop.md (landed in #179) already does the fast-forward-when-ahead=0 or merge-when-diverged on the program's branch at the start of every iteration. That's the same work sync-branches was meant to do between iterations — except it happens on the branch that's actually about to be iterated, at the moment it's needed, with the agent on hand to resolve any merge conflicts.

Roles that sync-branches was theoretically still doing:

None of these justify a broken workflow that's also fighting strict-mode compile and token permissions.

Concrete removal

1. git rm .github/workflows/sync-branches.md .github/workflows/sync-branches.lock.yml.
2. Audit for any references. Likely candidates: docs, READMEs, install.md-style instructions. Remove or rewrite to point at the per-iteration Step 3 as the branch-freshness mechanism.
3. Commit, open a PR.

That's the entire change. No agent prompt updates needed — autoloop.md already owns branch freshness via Step 3.

Follow-on

File the same removal upstream (already tracked — see cross-reference below). Once upstream drops it too, future installs won't re-introduce the broken workflow.

Acceptance

• .github/workflows/sync-branches.md and .lock.yml are gone from this repo.
• No references to sync-branches remain in docs.
• The autoloop program iteration still brings its branch current at Step 3 (no regression — verify with the next scheduled run on any active program).

Related

• Per-iteration branch hygiene: #179 (fast-forward when ahead=0).
• Upstream removal tracking: proposed on githubnext/autoloop — will be linked once filed.
• Historical: sync-branches's lock-file drift symptom has been showing up in recent workflow runs for days; removal rather than re-compile is the right resolution.