Summary
/epic-sync (node scripts/github-coordination.js sync --repo <owner/repo>) treats every issue in the repository as an epic. On a non-dry run it adds the epic and coordination:synced labels to all of them and writes a coordination block into each body — including plain bugs, features and closed issues.
Where
Verified on 2.2.1 and on main @ c9148d0:
scripts/lib/github-coordination/actions.js — applySync calls listIssues(repo, { state: 'all', limit: 100 }) with no label filter and then, for every returned issue, runs syncIssueLabels(...) and editIssue(repo, issue.number, { body }) when the merged body differs.
scripts/lib/github-coordination/state.js — desiredLabelsForState unconditionally does labels.push(known.epic) and labels.push(known.synced).
scripts/lib/github-coordination/gh-api.js — listIssues passes no --label to gh issue list.
Reproduce
In a repo with two epic-labelled issues and ~85 ordinary issues:
node scripts/github-coordination.js sync --repo <owner/repo> --dry-run --json \
| jq -c '.count, ([.items[] | .labels] | unique)'
Output:
87
[["coordination:available","coordination:synced","epic"],["coordination:claimed","coordination:synced","epic"]]
Every one of the 87 issues is planned to get epic + coordination:synced (the second set is the one epic that was already claimed). Each ordinary issue also gets a dependencies list from any #N in its body.
Expected
Sync only touches issues that already carry the configured epic label (policy.labels.epic) — e.g. listIssues(..., { label: policy.labels.epic }) / gh issue list --label epic — or at least requires an explicit opt-in to adopt unlabeled issues.
Impact
The command docs position /epic-sync as the first step of the epic cycle. Following them in a repo that uses labels for issue type (lane) silently turns the entire backlog into epics and rewrites every issue body; the damage is only visible after the fact.
The other coordination commands look fine: claim, decompose, validate, review and publish only edit the target issue, and unblock only touches issues whose coordination block says blocked.
Workaround
Skip sync and run claim → decompose → validate directly on the epic issue, --dry-run --json first.
Summary
/epic-sync(node scripts/github-coordination.js sync --repo <owner/repo>) treats every issue in the repository as an epic. On a non-dry run it adds theepicandcoordination:syncedlabels to all of them and writes a coordination block into each body — including plain bugs, features and closed issues.Where
Verified on 2.2.1 and on
main@ c9148d0:scripts/lib/github-coordination/actions.js—applySynccallslistIssues(repo, { state: 'all', limit: 100 })with no label filter and then, for every returned issue, runssyncIssueLabels(...)andeditIssue(repo, issue.number, { body })when the merged body differs.scripts/lib/github-coordination/state.js—desiredLabelsForStateunconditionally doeslabels.push(known.epic)andlabels.push(known.synced).scripts/lib/github-coordination/gh-api.js—listIssuespasses no--labeltogh issue list.Reproduce
In a repo with two
epic-labelled issues and ~85 ordinary issues:Output:
Every one of the 87 issues is planned to get
epic+coordination:synced(the second set is the one epic that was already claimed). Each ordinary issue also gets adependencieslist from any#Nin its body.Expected
Sync only touches issues that already carry the configured epic label (
policy.labels.epic) — e.g.listIssues(..., { label: policy.labels.epic })/gh issue list --label epic— or at least requires an explicit opt-in to adopt unlabeled issues.Impact
The command docs position
/epic-syncas the first step of the epic cycle. Following them in a repo that uses labels for issue type (lane) silently turns the entire backlog into epics and rewrites every issue body; the damage is only visible after the fact.The other coordination commands look fine:
claim,decompose,validate,reviewandpublishonly edit the target issue, andunblockonly touches issues whose coordination block saysblocked.Workaround
Skip
syncand runclaim→decompose→validatedirectly on the epic issue,--dry-run --jsonfirst.