repo-fleet-hygiene:audit remote-tracking gate suppresses 92 of 195 real merged-branch candidates

[kyle-sexton]

Summary

repo-fleet-hygiene:audit gates its merged-PR lookup on the branch being present
in the local remote-tracking inventory. In a fleet that deletes head branches on
merge, that gate suppresses evidence for precisely the branches most likely to be
cleanup candidates. Measured on an 11-repository fleet, the audit reported 103
HIGH candidates where a direct PR join found 195 — the gate hid 92 real,
PR-evidenced candidates.

Observed behavior

Audit run over --root D:/repos, 11 canonical checkouts, 506 local branches,
gh authenticated:

• HIGH = 103, MEDIUM = 60, LOW = 11, UNKNOWN = 5
• The 5 UNKNOWN findings are all merge-evidence-privacy-gated, covering
  300 branches whose merged state was never queried. One repository
  accounted for 291 of them.

The finding text explains the mechanism:

Finding: merge-evidence-privacy-gated
Evidence: exact merged-PR lookup skipped for 291 branch(es) absent from the
  local remote-tracking inventory: ...
Disposition: Merged state unverified; a merged branch whose remote ref was
  auto-deleted and pruned reports no merged finding
Handoff: Push or re-fetch the branch to restore remote evidence, or verify
  manually on GitHub, then rerun

The suggested handoff does not resolve it. git fetch --all --prune cannot
restore a remote ref that was deleted upstream on merge — after fetching all 11
repositories the same branches remain absent from the remote-tracking inventory,
so a rerun reports the same gap. The only escape offered is manual GitHub
verification of 300 branches.

Why the gate is not load-bearing

The audit already has the authoritative evidence source: gh pr list --repo <repo> --state merged --head <branch>, matched on headRefOid against the local
tip. That query does not require a remote-tracking ref to exist. Presence in the
remote-tracking inventory is not a precondition for the lookup — it is only a
proxy for "this branch was once pushed", which a merged PR proves far more
directly.

Cost is not the reason either

I replaced the per-branch query with one bulk call per repository:

gh pr list --repo "melodic-software/$name" --state all --limit 4000 \
   --json number,headRefName,headRefOid,state,url

11 API calls covered all 506 branches in both directions (merged evidence and
open-PR protection). Joining locally on headRefName then comparing
headRefOid to the local tip reproduced every HIGH finding the audit made and
added 92 more. This is strictly cheaper than the current per-branch query path,
not more expensive.

Resulting classification over the same 506 branches:

Disposition	Count
merged PR, headRefOid == local tip	195
local tip is an ancestor of the default branch	27
merged PR present, tip drift	132
no PR, all commits on some remote ref	53
no PR, not an ancestor, commits on no remote ref	99

Secondary finding: the ancestry lane assumes merge commits

Related, and worth stating in the report header: local-ancestry-only and any
ancestry-derived reasoning are near-inert in a squash-merging fleet. Of 506
branches only 27 were ancestors of origin/<default>, because a squash merge
rewrites the commits. Correspondingly, git rev-list --count <tip> --not --remotes reported non-zero for 410 branches — work that is fully merged but
whose exact commit objects exist nowhere on any remote.

Both readings are literally true and both are misleading if used as a deletion
predicate. A consumer following the report's tiering without knowing the fleet's
merge strategy would either preserve almost everything or believe it has 410
branches of unpushed work. The report should state which predicate it used and
that ancestry evidence degrades under squash merge.

Suggested fix

1. Drop the remote-tracking-presence gate before the merged-PR query. Absence of
   a remote ref is expected for merged-and-deleted branches, not a reason to skip
   the lookup.
2. Switch to one bulk gh pr list --state all call per repository and join
   locally. Cheaper than the current path and it yields open-PR protection for
   free.
3. Keep a genuine UNKNOWN tier for real API/auth/network failures only.
4. Name the merge strategy assumption in the report, and note that ancestry
   evidence is weak under squash merge.

Environment

• repo-fleet-hygiene 0.7.0
• Claude Code on Windows 11 Pro 10.0.26200, Git 2.54.0.windows.1
• gh authenticated, 11 repositories, 506 local branches
• Observed 2026-07-29

[kyle-sexton]

Verified — with one correction to the mechanism, and SKIPPED pending a maintainer decision

The suppression is real and the measurements hold up. But the remote-tracking gate is the fallback
path, not the primary one, and naming it as the cause points the fix at the wrong lever.

What the collector actually does

analyze_repo already issues one repository-scoped bulk query per repo:

gh pr list --repo "github.com/$github_repo" --state merged --limit 200 \
  --json number,headRefName,headRefOid,mergedAt,url

Every branch is joined against that batch locally, with no branch name transmitted. The
remote-tracking gate applies only to the per-branch --head "$branch" fallback for branches the
batch did not match.

So the suppressor is the --limit 200 batch window. Measured on this repository just now:

Quantity	Count
merged PRs (is:pr is:merged search)	865
batch window	200
local branches	271

The window covers roughly the newest quarter of merged history. Every branch whose PR is older than
that falls through to the fallback, where — after GitHub's auto-delete plus a prune fetch — the
remote-tracking ref is gone, the gate engages, and the branch lands in
merge-evidence-privacy-gated. That is a complete explanation for the 291 gated branches in the one
repository that dominated your run, without needing the gate to be wrong.

The collector already anticipates this. The comment above the gate reads:

Deferred (revisit if the gap keeps biting): widening proof-of-prior-push via
branch.<name>.merge/.remote config, and paginating the batch window.

It has now bitten, with numbers.

Suggestion 1 as written would regress a deliberate privacy property

Dropping the gate before a --head "$branch" query would transmit purely local branch names to
github.com. That is the property the gate exists for ("only send a branch name GitHub can already
see"), and it is pinned by a collector test: local-only branch name never sent to GitHub.

Your suggestion 2 makes suggestion 1 unnecessary rather than complementary: a wider bulk fetch joined
locally needs no --head query at all, so the gate stops being load-bearing on its own, with no
privacy regression and no test to weaken. That is the shape any fix here should take.

Secondary finding — confirmed, and stronger than stated

This repository is squash-only with head-branch deletion on merge
(allow_squash_merge: true, allow_merge_commit: false, allow_rebase_merge: false,
delete_branch_on_merge: true). Of 271 local branches, 2 are ancestors of origin/main. So
local-ancestry-only and any ancestry-derived tiering are effectively inert here, and the report
should say which predicate it used and that ancestry degrades under squash merge. Agreed as written.

Why this is SKIPPED rather than fixed

The remaining choice is a cost policy that belongs to the maintainer, not to a defect fix: how much
PR history the audit fetches per repository per run, by default, for every consumer. Going from
one call per repository to a paginated fetch of full merged history is roughly 9 calls for this
repository's 865 PRs, and unbounded on a large monorepo. --limit 4000 --state all is the right
answer for an 11-repository personal fleet; it is not obviously the right default for an
organization auditing a repository with tens of thousands of PRs, and this plugin is meant to be
org-scale safe.

Recommended shape, for whoever takes it

1. Widen and paginate the repository-scoped batch, keep the local join. No branch name leaves the
   machine, so the privacy gate stops mattering for the common case and its test stays green.
2. Make the window a configured cap, not a constant — a fleet.* config key plus a CLI flag,
   defaulting high enough to cover ordinary repositories.
3. Report a truncated window honestly. When the cap is hit, emit a distinct finding naming the
   cap and how to raise it, instead of letting the gap fall through and be reported as
   merge-evidence-privacy-gated — which today misattributes a window problem to a privacy
   decision, and is what sent this investigation at the gate in the first place.
4. Keep UNKNOWN for genuine API/auth/network failures, as suggested.
5. --state all in the same call buys open-PR protection for no extra request; worth taking
   while the query is being changed anyway.
6. Name the merge strategy in the report header and mark ancestry evidence as weak under squash
   merge.

Unassigning so this returns to the queue with the decision stated.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned.

repo-fleet-hygiene remote-tracking gate finding is SKIPPED pending maintainer decision on mechanism; not drain-actionable.