Orphan pin class: a reusable pin can be a real commit GitHub still refuses to run — 61 startup-dead rows, 0 alive; check-action-pins-resolve.sh tests the wrong predicate

[hyperpolymath]

Summary

A reusable-workflow pin can be a real commit object that GitHub still refuses to run. Four such SHAs in this estate account for 61 startup-dead workflow rows with zero alive rows, and the estate's own phantom-pin detector (scripts/check-action-pins-resolve.sh) passes every one of them — because it tests the wrong predicate.

reachable != consumable. The missing half is ancestry, not object existence.

Mechanism

GitHub's reusable-workflow fetch resolves only commits reachable from a ref. A pinned commit that is an ancestor of nothing fails at graph-resolution time with:

error parsing called workflow ... secret-scanner-reusable.yml@7fdc2705...: workflow was not found

Two consequences that make this hard to see:

• The run reports jobs.total_count == 0 and, in 130 of 224 measured dead rows, conclusion: "failure" rather than startup_failure. Where the context is required, the gate never reports at all.
• No liveness probe can detect it. commits/<sha> returns 200, and the file is present at that ref, so a contents/<path>?ref=<sha> probe also passes. GitHub never reaches the reusable's contents, so nothing about the file matters.

Measured population

Joined across all 31 distinct pin SHAs in an estate-wide census of 435 repos x 4 workflows (1,740 rows):

ancestor of main?	SHAs	ALIVE rows	DEAD rows
NO	5b1d0022 (not an object at all), 7fdc2705, 892497fe, 46960521	0	61
YES	the other 27	1,100	124

Zero alive rows on the non-ancestor side. Within the 33 repos holding at least one such row, those rows are 61/61 dead while the other rows in the same repos are 8/56 (14.3%) — a within-repo rate contrast, so this is not a per-repo effect.

Sufficient, not necessary: it explains 61 of 185 dead standards-pin rows (33%) and says nothing about the other 124.

Two provenances, one fatal property

The repair differs, so these should not be told as one story:

SHA	How it became a non-ancestor
7fdc2705	Squash-merge orphan. PR #596 (feat/gitleaks-estate-baseline-sharing), merged 2026-08-07, merge commit 86bad549. The pin captured the PR head, which the squash discarded.
892497fe	Deleted unmerged branch. commits/<sha>/pulls returns 0 PRs; its parent fa1453db is also a non-ancestor. Never merged by any route.
46960521	Reachable from a live remote branch (origin/audit/language-safety-20260907) but not an ancestor of main. 3/3 dead.
5b1d0022	Not an object at all — prefix corruption sharing a 26-char suffix with real commit d135b05b.

Defect 1 — the detector's predicate

scripts/check-action-pins-resolve.sh:100:

api "repos/$repo/commits/$sha"
case "$HTTP" in
  200)
    : # resolves — good

A non-ancestor orphan returns 200 here, so it is classified good with a comment asserting it. Both 7fdc2705 and 892497fe pass.

Fix — test ancestry, which is one API call and needs no clone:

api "repos/$repo/compare/main...$sha"      # or the repo's default branch
case "$(jq -r .status <<<"$BODY")" in
  behind|identical) : ;;                    # ancestor => consumable
  ahead|diverged)   bad=$((bad+1)) ;;       # NOT an ancestor => fatal pin
esac

Measured on this repo: compare/main...7fdc2705 = diverged, compare/main...892497fe = diverged, compare/main...81dbf2dd (healthy) = behind. All three return 200 from commits/<sha>.

Two alternatives that do not work, both measured:

• git for-each-ref --contains <sha> — passes 46960521, which is on a remote branch and still 3/3 dead.
• git merge-base --is-ancestor <sha> origin/main — correct in a full clone, but in a shallow clone every SHA reads as absent and the check reports the entire estate broken. Do not use the local form in CI.

Defect 2 — placement (already known, restated for completeness)

This script runs inside governance-reusable.yml (.github/workflows/governance-reusable.yml:1244-1246), whose callers are pinned at the very SHAs it would catch. When the pin is fatal, the workflow never starts, so the check cannot run. The fuse blows before it can trip — adding a pin assertion to a reusable workflow is inert by construction. The predicate fix above is necessary but not sufficient while the detector lives there.

Defect 3 — the generator

Fixing 61 rows does not stop the 62nd. A pin-bump tool must assert ancestry of the default branch before writing a SHA. Pinning a PR head is correct at the moment of writing and becomes fatal the instant that PR squash-merges — which is the normal merge method here (allowed_merge_methods: ["squash"]).

Concretely, a bumper should resolve to the merge commit on the default branch, never the PR head, and refuse to write a SHA whose compare/<default>...<sha> is not behind/identical.

Suggested disposition

1. Fix the predicate in check-action-pins-resolve.sh (self-contained, no behaviour change for healthy pins).
2. Add the ancestry assertion to whatever writes pins, so the class cannot recur.
3. Re-point the 61 rows — owner-ordered, not proposed here. This population overlaps the R-2-EXTENDED pin-repair campaign, and the 2026-09-09 ruling is that the owner says which session acts. No repin, ruleset change or PR is proposed in this issue.

Provenance note

The mechanism was already recorded in this estate on 2026-09-02, naming 7fdc2705 and quoting the banner above; the census that measured the 61 rows on 2026-09-09 nonetheless filed the cause as "measured but not diagnosed" for twelve days. A finding filed under a symptom is invisible to a search framed by an identifier. The durable rule adopted: before writing "undiagnosed" about anything carrying an identifier, grep for that identifier first.

One correction to a previously recorded lead, so it is not chased again: the job-level permissions: block in scorecard-reusable.yml at 7fdc2705 was recorded as a candidate cause. It cannot be — GitHub never reaches job parsing when the call graph does not resolve. That lead is withdrawn; the permissions:-replacement class remains real for its own separate 14 rows.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD

[hyperpolymath]

Correction to this issue: one row is wrong, and the fix I prescribed has the exact defect it warns about

A peer session auditing scorecard callers ran this issue's predicate over an independent census and
found the two populations were near-disjoint. Reconciling them exposed an error in my table
above and a hole in my suggested fix. Both are corrected here; the mechanism and the 61/0
measurement are unaffected.

1. 5b1d0022 is NOT "not an object at all" — it is a real commit, and an orphan

Measured just now, with HTTP status captured explicitly:

|===
| SHA | HTTP | compare/main...<sha> | Class

| 5b1d0022 | 200 | diverged (ahead_by: 3) | orphaned commit — same class as 7fdc2705
| 8750b94a | 404 | (no body) | not a commit at all
| 7fdc2705 | 200 | diverged (ahead_by: 4) | orphaned commit
| 892497fe | 200 | diverged (ahead_by: 6) | orphaned commit
| 46960521 | 200 | diverged (ahead_by: 6) | orphaned commit, reachable from a live remote branch
| 81dbf2dd | 200 | behind | healthy ancestor
| cd2ab490 | 200 | behind | healthy ancestor (the frozen campaign target — valid and consumable)
|===

repos/hyperpolymath/standards/commits/5b1d0022 returns 5b1d0022e16acd2eac326983fc95dd6b32b5f1a9.
So the row above claiming "not an object at all — prefix corruption sharing a 26-char suffix with
real commit d135b05b" is withdrawn. The suffix coincidence is real but incidental; it is not
why those 14 rows are dead. They are dead for the same reason as the other three SHAs: non-ancestry.

The d135b05b prefix-corruption story and a peer's competing blob-hash story (that a generator
wrote git rev-parse HEAD:<path>, the pinned file's blob hash, instead of git rev-parse HEAD)
are both unsupported for this SHA. The blob-hash defect is real and worth fixing at source, but
its evidence is 8750b94a, which genuinely 404s — not 5b1d0022.

How both of us got it wrong is worth more than the correction. Each of us ran
git cat-file -t <sha> in a --depth 1 clone and read Not a valid object name as "this SHA does
not exist". A shallow clone contains almost no history, so it answers that way for every SHA,
healthy pins included — this issue already warns about exactly that under the shallow-clone trap,
and I walked into it anyway while checking someone else's claim. cat-file is not an existence
test unless the clone is complete. The API is.

2. The fix I suggested above swallows a 404 — do not copy it as written

The snippet in the Defect 1 section is:

[source,sh]

case "$(jq -r .status <<<"$BODY")" in
behind|identical) : ;;
ahead|diverged) bad=$((bad+1)) ;;
esac

On a non-commit (8750b94a) the API returns 404 with no .status field, jq -r .status yields
null, and that matches neither arm — so the case falls through and the pin is counted as
neither good nor bad, i.e. silently passed. That is the same fail-open shape this issue was filed
to report, reproduced inside its own remedy. Correct form, with the default arm and the status check:

[source,sh]

code=$(gh api "repos/$repo/compare/$default...$sha" -i 2>/dev/null | head -1 | awk '{print $2}')
[ "$code" = "200" ] || { bad=$((bad+1)); continue; } # 404 / 403 / quota => FAIL, never skip
case "$(gh api "repos/$repo/compare/$default...$sha" --jq .status)" in
behind|identical) : ;; # ancestor => consumable
*) bad=$((bad+1)) ;; # ahead|diverged|anything else => fatal pin
esac

Two rules the *) default encodes, both learned the hard way in this estate: a 403 from a hidden
quota must not read as a pass, and --jq over an error body parses the error as data. Treat any
non-200 as FAIL.

3. compare alone is sufficient for all three classes — which simplifies the prescription

The three-class split (non-commit / orphaned / healthy) is the peer's, and it improves this issue:
a two-probe design is unnecessary, because a non-commit 404s on compare too. One call, three
outcomes, with non-200 folded into FAIL. That is the whole detector.

4. Population is larger than this issue states

61 dead rows here and 19 in the peer's scorecard census overlap on exactly one repo
(natsci-studio), giving 35 known startup-dead scorecard callers rather than either figure
alone. 8750b94a accounts for 18 of theirs and appears nowhere in mine, because a 404-ing SHA was
invisible to a census keyed on object existence — the mirror image of why their probe missed the
orphans.

Unchanged

The mechanism, the two orphan provenances (7fdc2705 = squash-merge orphan of #596, pin captured
the PR head; 892497fe = deleted unmerged branch), the 61/0 measurement, the three defects, and
the generator-level fix. Add a fourth generator defect: whatever writes a SHA must assert it is
a commit and an ancestor of the default branch — 8750b94a shows the first check is not
redundant.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD

[hyperpolymath]

Retraction: my own correction above was wrong. The original body was right.

I posted a correction earlier today (#issuecomment-5670136441) claiming that 5b1d0022 is a real commit and an orphan, and that the body's "not an object at all — prefix corruption" line was false.

That correction is withdrawn. The original body line was correct. I tested an abbreviation, not the pin.

The instrument error

GitHub resolves abbreviated SHAs. I probed the 8-character prefix:

GET repos/hyperpolymath/standards/commits/5b1d0022
  → 200   5b1d0022e16acd2eac326983fc95dd6b32b5f1a9

That 200 proves only that some commit in the repo starts with those 8 characters. It is a prefix query, not an existence test for the pin. The SHA actually written in the caller workflows is the full 40:

5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236

GET commits/5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236
  → 422  {"message":"No commit found for SHA: 5b1d0022…"}
GET compare/main...5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236
  → 404
GET git/blobs/5b1d0022…   → 404
GET git/trees/5b1d0022…   → 404

Not a commit, not a blob, not a tree. And the corruption is exactly where the body said it was — it shares 26 trailing characters with a real commit:

pin   5b1d0022 9e5e8c0c 0fbfedc7e80f37ea50f49236
real  d135b05b fc647d0c 0fbfedc7e80f37ea50f49236
                        ^^^^^^^^^^^^^^^^^^^^^^^^ 26 chars identical

The corruption lives in the prefix, which is precisely the region an abbreviated probe replaces with a wildcard. That is why the wrong instrument returned a confident 200.

What this changes

5b1d0022…9e5e (14 dead rows)	Class 1 NON-COMMIT — as originally filed
7fdc2705, 892497fe, 46960521 (20 dead rows)	Class 2 ORPHAN — full pins verified 200 + diverged
81dbf2dd, cd2ab490	Class 3 HEALTHY — 200 + behind

Re-measured on the full 40-char pins read out of the consumption table, not on prefixes.

What still stands, unchanged

1. The fail-open defect in my first fix snippet — a case on .status with no *) default silently passes a non-commit. The corrected form, with one addition now that we know a non-commit can answer 422 as well as 404 — which is the whole argument for folding every non-200 into FAIL rather than matching on a status string:

default=$(gh api "repos/$repo" --jq .default_branch)
code=$(gh api "repos/$repo/compare/$default...$sha" -i 2>/dev/null | head -1 | awk '{print $2}')
[ "$code" = "200" ] || { bad=$((bad+1)); continue; }   # 404 / 422 / 403 / quota => FAIL, never skip
case "$(gh api "repos/$repo/compare/$default...$sha" --jq .status)" in
  behind|identical) : ;;                 # ancestor => consumable
  *)                bad=$((bad+1)) ;;    # ahead|diverged|anything else => fatal pin
esac

2. check-action-pins-resolve.sh:100 probes commits/$sha, which is the wrong predicate for "is this consumable" regardless of this retraction — it answers 200 for orphans.
3. The four generator defects, unchanged and still the actual fix: pin the merge commit never the PR head; assert the SHA is a commit; assert ancestry of the default branch, not for-each-ref reach; never let a non-200 read as a pass.
4. The 0 ALIVE / 61 DEAD coverage measurement. The class of 5b1d0022 moved; its 14 rows were always on the dead side.

The generalisable defect, which is worth more than the fix

Two sessions disagreed about this SHA. One reported 404, one reported 200. Both were reporting honestly — we were sending different strings, and neither of us checked that before one of us conceded. When two measurements of the same API disagree, the first hypothesis is different inputs, not different truth; diff the exact request before deferring or insisting.

Related instrument error, same day, same family: git cat-file -t <sha> answers Not a valid object name for every SHA in a --depth 1 clone — 81dbf2dd and cd2ab490 both fail it and are both healthy ancestors of main. Existence and ancestry are both API questions unless git rev-parse --is-shallow-repository is false.

Apologies to the reviewer whose class-1 assignment I contradicted: you had it right.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VG5AnnA12E8GikbXZS7NbD