Remove sync-branches workflow — made redundant by per-iteration Step 3 ahead/behind logic #52

Summary

Remove workflows/sync-branches.md (and its lock file on consumers) from autoloop. The workflow was designed when the per-iteration branch-management logic was minimal; now that each iteration runs a full ahead/behind fast-forward-or-merge at Step 3 (#36), sync-branches is scaffolding without a load-bearing purpose.

Leaving it in is actively harmful: it can't compile under strict mode (see #33), it requires a PAT to actually push (most consumer repos don't configure one), and when it silently fails pushes the workflow still looks green — so users see "sync-branches: success" on their runs while nothing is actually syncing.

Why it's redundant

Before #36, Step 3 of the iteration loop was a simple "merge main if it exists, else create from main." If main advanced between iterations, the branch drifted, and sync-branches was the between-iterations correction.

After #36, Step 3 does:

ahead=$(git rev-list --count origin/main..origin/autoloop/{program-name})
behind=$(git rev-list --count origin/autoloop/{program-name}..origin/main)

if [ "$ahead" = "0" ] && [ "$behind" != "0" ]; then
  # Lossless fast-forward
  git checkout -B autoloop/{program-name} origin/main
  git push --force-with-lease origin autoloop/{program-name}
elif [ "$ahead" != "0" ] && [ "$behind" != "0" ]; then
  # True divergence
  git merge origin/main --no-edit
else
  # Up to date
fi

Each iteration now self-heals the branch. sync-branches's original job is covered.

What sync-branches still technically does, and why we don't need it

Concrete removal

In this repo:

1. git rm workflows/sync-branches.md
2. Remove the gh aw compile sync-branches line from install.md (Step 4).
3. Update README.md if sync-branches is mentioned.
4. Search docs for mentions of "sync-branches" or "sync workflow" and remove/update.
5. If there's a section in workflows/autoloop.md that cross-references sync-branches ("a sync workflow automatically merges the default branch into all active autoloop/* branches") — rewrite it to say that the per-iteration Step 3 handles branch freshness, and point to that section.

Migration for existing installs

Consumers who installed sync-branches previously need to remove it on upgrade:

1. Delete .github/workflows/sync-branches.md and .github/workflows/sync-branches.lock.yml in the consuming repo.
2. That's it. No state to clean up; no references to update.

This belongs in the release notes for whichever version lands this change. The versioning proposal in #46 would make the release-notes path natural.

Resolution of existing issues

• Step 4: gh aw compile sync-branches fails #33 (strict-mode compile error on sync-branches) — closed by removal. No more sync-branches, no more compile error.
• Any future issue asking "why does sync-branches silently no-op" — same resolution.

Acceptance

• workflows/sync-branches.md no longer exists in this repo.
• install.md no longer asks consumers to compile it.
• No doc references to sync-branches remain.
• Release notes (or the PR description, if versioning isn't ready) instruct existing installs how to remove their local copies.
• Step 4: gh aw compile sync-branches fails #33 is closed.

Related

• Step 4: gh aw compile sync-branches fails #33 — the compile-time failure that this removal resolves.
• Fast-forward the long-running branch to main when ahead=0, instead of always merging #36 — the per-iteration ahead/behind logic that makes sync-branches redundant.
• Basic versioning: VERSION file + self-check that opens an update-available issue on drift #46 — versioning proposal; release notes path for migration.