⚠️ Corrupt packfile in hyper-repos/gitbot-fleet + 3 commits that exist nowhere on GitHub

[hyperpolymath]

⚠️ Do not delete or re-clone hyper-repos/gitbot-fleet until this is resolved

Found incidentally on 2026-08-25 while making an unrelated one-line fix. No action taken — I moved the work to a fresh clone rather than attempt repair, and restored the one file I had moved aside.

The corruption

/home/hyperpolymath/developer/hyper-repos/gitbot-fleet cannot run git status:

fatal: unknown index entry format 0x636b0000

That is the index, but the damage is deeper — the object database itself:

error: .git/objects/pack/pack-14e1328302c26f23efc3bbaa4b14c39516028ac6.pack pack checksum mismatch
error: index CRC mismatch for object 2eca8eb5... at offset 575111
error: inflate: data stream error (incorrect header check)
error: unknown object type -1 at offset 582956
error: cannot unpack ... (many)

Rebuilding the index does not help: git reset fails with unable to read tree 72c2b2e8.... The pack is damaged, not just the index.

Why this matters — possible unpushed work

git rev-list --all --not --remotes --count reports 13. That number alone would be a false alarm, so I checked whether those commits exist on GitHub. Three do not:

Commit	Message	On GitHub?
e69a536	chore(ci): bump standards reusable pins to 5b1d0022 (#426)	❌ no
ce02567	chore(ci): bump standards reusable pins to fix Bug A and Bug B (#426)	❌ no
632b54a	fix: recover phase-zero CI and governance	❌ no
053ffdc	fix(ci): remove timeout-minutes from jobs using reusable workflows	✅ yes
00ddf89	feat(scripts): fix-actions-policy.sh — repair the estate Actions-policy outage	✅ yes

These are not stale remote refs. I verified the instrument before trusting the reading: the sibling clone's origin/main is 0ea64b2 (2026-08-24), which exactly matches live main on GitHub. The refs are current, so "not on remote" means genuinely not pushed.

632b54a in particular — a CI and governance recovery commit — is the kind of thing that would be painful to lose and hard to notice missing.

Caveat worth stating: e69a536 and ce02567 may have been squash-merged, in which case their content survives under a different SHA. 632b54a lives on fix/phase-zero-recovery in gitbot-fleet-recovery-20260824 and shows as ahead 1, so it looks like genuinely unmerged work rather than a squash artefact.

Relevant clones

Path	Branch	Health
hyper-repos/gitbot-fleet	chore/bump-standards-pins	❌ corrupt pack
hyper-repos/gitbot-fleet-recovery-20260824	fix/phase-zero-recovery	✅ fsck clean, ahead 1 / behind 1

Why I did not fix it

AGENTS.md is explicit:

"Never treat a fresh clone as more canonical than an existing checkout: before any supersede/rename, compare git rev-list --all --not --remotes --count on both sides — the copy with unpushed work is the one to keep."

Both sides report 13. Deciding which to keep, and whether 632b54a should be pushed, is a judgement about work I did not do. Recovery options range from git fsck --lost-found salvage to cherry-picking the three commits onto a fresh clone and discarding the corrupt tree — all of them destructive to something.

Suggested next step

1. Confirm whether 632b54a "fix: recover phase-zero CI and governance" is wanted. If yes, push it from the recovery clone (which is healthy) before touching anything else.
2. Check whether e69a536 / ce02567 were squash-merged; if so they can be discarded.
3. Only then decide the fate of the corrupt tree.

Filed rather than actioned because step 1 is a decision, and steps 2–3 are irreversible.

Horizon: I ran git fsck bounded to 60s and read the first 20 errors — the full extent of pack damage is unmeasured. I did not run fsck --lost-found, did not repack, and did not fetch. The only change I made was moving .git/index aside to test whether a rebuild would work; it did not, and I restored it.