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

Start by removing .github/workflows/sync-branches.md and .github/workflows/sync-branches.lock.yml, then search the repository for sync-branches references in documentation and instructions. Read autoloop.md Step 3 and verify that it still describes branch freshness handling. Done means both workflow files and obsolete documentation references are gone, with no change needed to 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.