Reported by the maintainer, ruled a bug.
/ca:standup step 3 lists stale/merged worktrees but its hard gate ("MUST confirm each destructive action individually - no batched or implied yes") forces one confirmation per worktree. After a normal multi-lane sprint that is 4-6 consecutive yes prompts for items that were all just proven stale by the same evidence. The per-item ceremony stops adding a decision and starts being the reason the cleanup is skipped.
Fix: worktree removals may be confirmed as an explicitly ENUMERATED group - one confirmation that names every member and its proof, with per-item confirmation still available when the user wants to keep some. Branch deletions keep per-item confirmation. ADR-0022's tier-2 rule (worktree deletion always asks) is preserved: the group confirmation IS the ask.
Related: #586 covers the sibling defect that squash-merged branches are never provably "merged" under the current ancestry instrument, which is the other half of why post-merge cleanup rarely completes.
Reported by the maintainer, ruled a bug.
/ca:standup step 3 lists stale/merged worktrees but its hard gate ("MUST confirm each destructive action individually - no batched or implied yes") forces one confirmation per worktree. After a normal multi-lane sprint that is 4-6 consecutive yes prompts for items that were all just proven stale by the same evidence. The per-item ceremony stops adding a decision and starts being the reason the cleanup is skipped.
Fix: worktree removals may be confirmed as an explicitly ENUMERATED group - one confirmation that names every member and its proof, with per-item confirmation still available when the user wants to keep some. Branch deletions keep per-item confirmation. ADR-0022's tier-2 rule (worktree deletion always asks) is preserved: the group confirmation IS the ask.
Related: #586 covers the sibling defect that squash-merged branches are never provably "merged" under the current ancestry instrument, which is the other half of why post-merge cleanup rarely completes.