repo-fleet-hygiene: branch and worktree analysis is silently skipped on a moved-identity checkout, dropping a genuine HIGH finding

[kyle-sexton]

Context: #2597

Problem

When a checkout's GitHub identity has moved, the audit emits github-remote-moved and performs no branch or worktree analysis for that repository at all — and says nothing about having skipped it. A reader cannot distinguish "this repository is clean" from "this repository was never examined."

Local branch and worktree facts do not depend on the remote identity being current, so there is no evidence reason to drop them.

Evidence

In a 19-repository run, knowledge-artifacts produced exactly one finding: github-remote-moved (melodic-software/knowledge-artifacts resolving to melodic-software/knowledge-corpus). No branch findings, no worktree findings.

Independent verification found a genuine HIGH candidate the report never emits: branch add/pat-pattison-epub-sources at 438437e has merged PR #1 on knowledge-corpus with an exact headRefOid match — a textbook merged-local-branch.

Severity here is coverage rather than safety: that branch is the checkout's current branch and its sole worktree HEAD, so it was never a deletion candidate. The same mechanism could hide a real candidate elsewhere.

Searching the 6204-line report for any note that analysis was skipped returns only the finding blocks themselves. The omission is undocumented.

Proposed change

Either:

1. Continue local analysis anyway. Branch and worktree classification needs the local inventory and, for merge evidence, a GitHub identity — which the API has just resolved. Use the resolved canonical full_name for the PR queries and report normally, noting that the remote is stale.

2. Or, if that is judged unsafe, emit an explicit analysis-skipped finding naming the repository and stating exactly which analyses were dropped and why.

Option 1 is preferable: the API response already contains the correct identity, so the evidence is present rather than missing.

Acceptance criteria

• A repository whose remote resolves to a different full_name still receives branch and worktree analysis, or receives an explicit finding stating that it did not.
• The report never contains a repository with silently zero coverage.
• Re-running against a checkout in this state surfaces add/pat-pattison-epub-sources-class findings (exact-OID merged PRs on the resolved identity), subject to the usual protection rules.

[kyle-sexton]

Correction — the mechanism in this issue is wrong; the defect is real but sits elsewhere

A fresh-context audit of the installed 0.13.0 source, run after this issue was filed, supersedes the mechanism described above. Recording it here rather than opening a duplicate, because the observable symptom and the acceptance criteria still hold.

What this issue claimed: analysis is skipped for a repository whose GitHub identity has moved.

What the source actually does: there is no moved-identity stop. github-remote-moved falls through and does not gate anything.

The defect is at scripts/audit-fleet.sh:1371–1382. Exact-OID merged evidence is computed for the checked-out branch — and then discarded, with zero emit_finding calls on that path.

The tell that this is a bug rather than a deliberate protection rule: the weaker merged-pr-tip-drift finding at :1383 has no protection guard and is emitted. A protection rule that suppressed the strong finding while letting the weak one through would be backwards.

The reported symptom is unchanged and still reproduces. knowledge-artifacts emits only github-remote-moved; its branch add/pat-pattison-epub-sources has merged PR #1 on knowledge-corpus with head 438437e7b0e7… equal to the local tip exactly, and no merged-local-branch is emitted.

Consequence for the fix: the remediation is narrower than this issue implies. It is not "continue analysis past an identity mismatch" — nothing stops it. It is "emit the finding that is already computed at :1371–1382". The acceptance criteria above still bind.

Since that branch is the checkout's current branch and its sole worktree HEAD, it was never a deletion candidate, so severity remains coverage rather than safety — but the same discarded-finding path applies to any repository, not only one with a moved identity, which widens the blast radius versus what this issue described.