[finding] 393 `claude/*` branches on origin, and the obvious way to tell which are safe to delete does not work in this repo

[hotlong]

Filed unassigned while doing R21 seat housekeeping (chasing one known orphan branch). Recording it rather than acting: deleting branches is destructive, and nobody has asked for a cleanup.

The measurement

$ git branch -r --list 'origin/claude/*' | wc -l
393

Measured on main @ f01e6f6f.

⚠️ The trap, which is the more useful half of this card

The obvious predicate for "safe to delete" is "has this branch been merged into main?", and the obvious command is:

git rev-list --count origin/main..<branch>     # 0 ⇒ fully merged

In this repository that command is meaningless. Landing goes through the merge queue with SQUASH, so a feature branch's own commits never become ancestors of main — the squash commit is a new object with a different tree lineage. Every branch here therefore reports a large non-zero count regardless of whether its work landed. A sample of the run:

origin/claude/agent-metadata-positioning-th5hhm      : 1429 commits ahead of main
origin/claude/authorization-gaps-profile-grants-xrcoku : 1436 commits ahead of main
origin/claude/chinese-i18n-issues-lq7hlp             : 1587 commits ahead of main

Those numbers are artifacts of squash-merging, not unmerged work. ⇒ Anyone reading them as "1429 commits would be lost" concludes the branches must be kept; anyone reading them as noise and deleting anyway is right by luck, not by measurement. Both readings are unsafe. The sound predicate is the branch's associated PR state (merged / closed / none), which is a GitHub API question, not a git-ancestry one.

⭐ This trap is worth recording even if the cleanup itself is never done, because the same reasoning breaks any future "is this branch landed?" check written locally in this repo.

A confirmed instance

origin/claude/issue-1231-dependabot-second-lockfile is a genuine orphan: its tip is 966cc23b, a squash commit that is already main's history, so the branch carries no commit of its own — it was cut and abandoned when #1231's work was re-cut as claude/issue-1231-retire-package-lock and landed as PR #1469. Zero-own-commit branches like this one are the unambiguously safe class, and they are detectable without touching the API: the tip is reachable from main.

What this costs today

Speculative, and deliberately not asserted as harm: every git fetch and every git worktree add in this repo pays for these refs, and this repo runs several agents in parallel, each creating worktrees. Whether that is measurable has not been measured. ⛔ Do not treat "393 branches" as a demonstrated performance problem — it is a demonstrated inventory.

Not proposed

⛔ No mass deletion is proposed here, and this seat will not perform one on its own initiative. If it is wanted, the shape is: enumerate claude/*, resolve each to its PR via the API, delete only those whose PR is merged, and leave every branch with no PR or an open PR alone. The zero-own-commit subset above could go first as a safe pilot.

[hotlong]

First-touch grading → closed not_planned. finding retired. R24, repo:hotcrm seat.

Closing per the 2026-08-16 ruling (「有些暂时不准备开发的应该直接关闭」). ⛔ Not a dismissal — the card is the record, it stays searchable, and reopening is free.

Why closed rather than queued: the card proposes no work, and says so itself. Its one actionable half — a mass branch deletion — is something this seat explicitly declined to do on its own initiative, and nobody has asked for it. Queuing it would put a card in the dispatch queue whose own body rules out the only action it describes.

⚠️ The cost was never measured. The card is careful about this and I am keeping it careful: 393 branches is a demonstrated inventory, not a demonstrated problem. Whether they measurably slow git fetch or git worktree add in a repo several agents work in parallel is unmeasured. ⛔ Do not reopen this on the strength of "393 sounds like a lot".

⭐ The half worth keeping is the measurement trap, and closing does not lose it

git rev-list --count origin/main..<branch>     # 0 ⇒ fully merged

⛔ That predicate is meaningless in this repo. Landing goes through the merge queue with SQUASH, so a feature branch's own commits never become ancestors of main — every branch reports a large non-zero count whether or not its work landed. Reading those counts as "unmerged work" says keep everything; reading them as noise and deleting anyway is right only by luck. Both readings are unsafe.

⇒ The sound predicate is the branch's associated PR state, which is a GitHub API question, not a git-ancestry one. ⭐ That generalises past branch cleanup: any future local "has this landed?" check written in this repo hits the same wall.

⚠️ This finding is also an early instance of the failure that ran through this whole session for me — taking a command's output as evidence without checking what it actually measures. It has since recurred three more times in my own reviews (a pathspec that excluded part of its own subject, a zero from an absent node_modules, a string that mentions a file read as an assertion about it). ⇒ Recorded here because this card is where it was first caught.

Reopen when

• someone measures a real cost, or
• the safe pilot is wanted: the zero-own-commit subset (tip reachable from main, e.g. claude/issue-1231-dependabot-second-lockfile) is unambiguously deletable and detectable without the API.

⛔ Until then there is nothing to dispatch.

---

Generated by Claude Code