Branch/worktree census — enumerate every ref, classify by anchor and merge state. Inventory only, zero dispositions.

[qmarcelle]

Anchor for the branch census dispatched 2026-07-10. This issue exists because dispatching the census without an anchor would reproduce the exact defect #3 was filed to close.

Why now

#3 produces the rule: no worktree or branch without an explicit issue anchor. That rule is currently asserted against a population nobody has counted. worktree-inherited-shimmying-phoenix was found by accident during a worktree audit. Nothing establishes it was the only one.

Two of today's gates assume phoenix-vs-dev is a two-body problem:

• vreko-dev/vreko#510 scopes the R0 re-audit from git diff dev...phoenix --name-only.
• vreko-dev/vreko#509 Gate 2 resolves conflicts on a two-way staged merge.

If a third ref carries an ancestor of something phoenix touches, or holds unmerged commits against files in vreko-dev/vreko#415's spec-referenced set, both assumptions are wrong. Cheaper to know before staging than during.

Scope discipline — this is an enumeration, not a triage

The census produces a table and zero dispositions. No merge, no rebase, no delete, no cherry-pick, no branch creation. Any ref that turns out to matter becomes a row. Rows are ruled on by a human, later, in their own issues.

This is the same rule as Marcelle-Labs/never-ask-twice#6 Day 1 and vreko-dev/vreko#510: run the enumeration, do not build the harness.

Instrument

Read-only. Touches no working tree that vreko-dev/vreko#509 Gate 0 depends on — all git log / git cherry / for-each-ref against refs.

git fetch --all --prune
git worktree list
git for-each-ref --sort=-committerdate \
  --format='%(refname:short)|%(committerdate:iso8601)|%(authorname)|%(objectname:short)' \
  refs/heads refs/remotes

Per ref, versus dev:

git rev-list --count dev..$REF        # commits ahead (unmerged)
git rev-list --count $REF..dev        # commits behind
git cherry dev $REF | grep -c '^+'    # commits with NO equivalent on dev (the real unmerged count)
git merge-base --is-ancestor $REF dev # fully merged? exit 0 = yes
git diff dev...$REF --name-only | wc -l

git cherry is the load-bearing one. rev-list --count overstates: it counts commits that were cherry-picked onto dev under a different SHA as still-unmerged. The phoenix 153 may itself overstate for exactly this reason — #3 done-condition 2 asks for the novel-vs-duplicated inventory and this instrument answers it.

Report — one row per ref

Ref	Last commit date	Ahead (rev-list)	Novel (git cherry +)	Behind	Files touched vs dev	Fully merged?	Linear anchor	Intersects vreko-dev/vreko#415 spec files?

Plus three explicit outputs:

1. Unanchored refs — every ref with no Linear issue naming it. Count. This is the population worktree-inherited-shimmying-phoenix is STALE, not an integration branch — misread symmetric-diff as "153 commits ahead"; teardown only #3's rule governs.
2. Novel-vs-duplicated for phoenix — git cherry dev worktree-inherited-shimmying-phoenix | grep -c '^+' versus the claimed 153. Satisfies worktree-inherited-shimmying-phoenix is STALE, not an integration branch — misread symmetric-diff as "153 commits ahead"; teardown only #3 done-condition 2 as a side effect.
3. Two-body violation check — any ref other than phoenix with novel commits touching files in vreko-dev/vreko#415's spec-referenced set (list in vreko-dev/vreko#510). If non-empty, vreko-dev/vreko#509 Gate 2 and vreko-dev/vreko#510's scoping are both operating on a false premise and must be told before they run.

Done condition

The table. The three outputs. Counts, not prose. No ref is modified, deleted, or merged by this work. Any ref judged to need action gets its own issue, filed by a human.

Anti-pattern

WRONG	RIGHT
"Cleaned up N stale branches"	N branches enumerated, 0 modified
rev-list --count reported as unmerged work	git cherry novel-commit count reported alongside it
Agent decides a branch is abandoned	Agent reports the row; human rules
Deferring the phoenix novel-count to the merge	It falls out of this census for free