Estate: 13 repos have a DAMAGED GIT OBJECT DATABASE (not the corrupt-index problem) — 1 with 9 unpushed commits at risk

[hyperpolymath]

Summary

13 repos in hyper-repos/ have a damaged git object database. This is a different
and more serious defect than the known corrupt-index problem, and the established cure
does not touch it.

One of them — reasonably-good-token-vault — has 9 local commits not on origin/main
sitting on top of a damaged pack. That is the only genuine data-loss exposure in the set
and it should be handled before anything else.

This is not the corrupt-index problem

	corrupt index (known, 40 repos)	corrupt pack objects (this issue, 13 repos)
what it is	a cache of the worktree	the object database — the actual data
symptom	fatal: unknown index entry format 0x…	inflate: data stream error / unknown object type 0 / failed to validate delta base reference
cure	rm .git/index && git reset — safe, reversible	not repairable locally; re-fetch from remote
data loss	none, ever	anything not on a remote is gone

rm .git/index && git reset does nothing for these. They need a second, different remediation.

Reach — measured before reporting

Instrument: git ls-tree -r HEAD --name-only over every .git directory in hyper-repos/.

• 227 .git directories; 1 is not a repository at all (bulk_update_oikos-private-farm
  — has a .git dir, git answers fatal: not a git repository). Real population 226.
• 213 TREES_OK · 13 TREE_ERR

⚠ 13 is a FLOOR, not a total. ls-tree -r HEAD reads tree objects only. Blob-level
damage and damage in non-HEAD history are UNMEASURED. Please do not quote 13 as complete.

The 13

repo	index	branch	ahead of remote	remote
aerie	ok	chore/bump-standards-pins	no upstream	hyperpolymath/aerie
candy-crash	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/candy-crash
developer-ecosystem	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/developer-ecosystem
dotmatrix-fileprinter	ok	chore/bump-standards-pins	no upstream	hyperpolymath/dotmatrix-fileprinter
echidna-recovery-20260824	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/echidna
gitbot-fleet	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/gitbot-fleet
grim-repo	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/grim-repo
laniakea	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/laniakea
panll	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/panll
reasonably-good-token-vault	ok	main	+9 / -7 vs origin/main	hyperpolymath/reasonably-good-token-vault
reposystem	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/reposystem
supernorma	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/supernorma
volumod	BLIND	chore/bump-standards-pins	no upstream	hyperpolymath/volumod

Every one has a GitHub remote, so 12 of 13 are recoverable by re-clone.
reasonably-good-token-vault is not — re-cloning it discards 9 commits. Handle first,
and do not re-clone over it.

Note echidna-recovery-20260824 and developer-ecosystem are themselves recovery snapshots.

Error signatures — 4 classes

6 x error: inflate: data stream error (incorrect header check)
3 x error: unknown object type 0 at offset N in .git/objects/pack/pack-....pack
3 x error: failed to validate delta base reference at offset N
1 x error: inflate: data stream error (unknown compression method)

unknown object type 0 and incorrect header check are the classic signatures of a
zeroed or truncated region inside a packfile — bytes replaced by NULs, or a write that
stopped short. Consistent with an interrupted write or a filesystem-level event (this host
is WSL2). Not something git produces in normal operation.

The correlation — a mechanism, not an actor

12 of the 13 sit on branch chore/bump-standards-pins, with no upstream configured.

	on chore/bump-standards-pins	elsewhere
repos	50	176
pack-damaged	12 (24 %)	1 (0.6 %)

Base-rate test: P(branch) = 50/226 = 0.221. Under independence, expected 2.9 of the 13 on
that branch. Observed 12. ≈42x enrichment.

What this licenses, and what it does not.

• It DOES establish the damage is not uniform over the estate, and is therefore
  mechanistic rather than environmental — site-specific and concentrated, not memoryless.
• It does NOT establish that the pin-bump sweep wrote the bad bytes. Equally consistent
  with: the sweep ran fetch/gc/repack concurrently and was interrupted; or it selected
  repos on some other property. The branch is a marker that the sweep ran here, not proof
  of authorship.
• Next probe, not yet run: packfile mtimes against the branch commit dates.

Why nothing caught this

git log, git show, git fetch and git status all keep working until they happen to
walk into the damaged region. A repo with a shredded pack looks alive to every bot, sweep
and census in the estate. Nothing in the estate checks object-database integrity.

Suggested actions

1. reasonably-good-token-vault first — recover the 9 unpushed commits before any
   destructive step (git bundle create what is readable; push what survives).
2. For the other 12: verify the remote is current, then re-clone. Do not gc/repack
   a damaged pack — it can propagate the damage into the rewritten pack.
3. Add git fsck --connectivity-only (or the cheap git ls-tree -r HEAD >/dev/null) to
   whatever health sweep the estate runs. It is one command and it has never been run.
4. Fix [ -d .git ] as a repo test estate-wide — bulk_update_oikos-private-farm passes it
   and is not a repository, so every census using that guard carries a +1 error.

Corpus units for proven-tests-and-benches

• U5 — object-database integrity is unmeasured by every existing check. Canonical
  wrongness: a packfile with a zeroed 4 KB region; the check MUST go red. Silent fixture: an
  intact clone. Fires on 13 live repos today.
• U6 — a repo can be ahead of a remote it can no longer serialise. The detector must
  report ahead-count and object health together; either alone reads as healthy.
• U7 — [ -d .git ] is not a repo test.

Full forensics, with raw data:
developer/.claude/forensics/estate-pack-corruption-2026-08-27.md