Summary
Post-merge follow-up from PR #194.
sw-sync intentionally keeps [gone] branches in the force-delete-candidate class, even when git branch -d would also succeed, because the operator surface is optimizing for deterministic cleanup in squash-merge repositories.
That intent is not stated explicitly enough in the docs/protocol text today.
Problem
The current wording leaves two plausible interpretations for AI agents and human readers:
- treat
[gone] + merged as safe-delete
- keep all
[gone] branches under the second-confirmation -D path for determinism
The implementation/review decision was to keep the deterministic [gone] behavior, but the skill/protocol text should say that directly.
Suggested scope
- update
core/skills/sw-sync/SKILL.md
- update
core/protocols/git.md if needed
- add or extend a deterministic wording/behavior proof so this intent does not drift later
Source
Summary
Post-merge follow-up from PR #194.
sw-syncintentionally keeps[gone]branches in theforce-delete-candidateclass, even whengit branch -dwould also succeed, because the operator surface is optimizing for deterministic cleanup in squash-merge repositories.That intent is not stated explicitly enough in the docs/protocol text today.
Problem
The current wording leaves two plausible interpretations for AI agents and human readers:
[gone] + mergedassafe-delete[gone]branches under the second-confirmation-Dpath for determinismThe implementation/review decision was to keep the deterministic
[gone]behavior, but the skill/protocol text should say that directly.Suggested scope
core/skills/sw-sync/SKILL.mdcore/protocols/git.mdif neededSource
core/skills/sw-sync/SKILL.md