Deletion census: use `git ls-files --deleted`, never `git status` — the 83,441 figure was an empty-index artefact

[hyperpolymath]

The trap

git status --porcelain compares the worktree against HEAD. A clone with an
empty index but a real HEAD therefore reports its entire tree as
staged-deleted. This is not a corruption signal and not a deletion.

This manufactured a false emergency on 2026-09-08: an estate scan reported
83,441 staged deletions. The true figure was two orders of magnitude smaller.

The correct instrument

Use git ls-files --deleted — "in the index, missing from the worktree". That is
the question a deletion audit is actually asking.

Re-measured across 1,043 repos with the correct instrument:

Measure	Value
True deletions	2,642
Repos affected	199
Empty-index clones (the artefact source)	45
Unreadable repos (excluded, not clean)	6

Largest residues: julia-ecosystem 695, polystack 338, meta-repos/stapeln
137, nextgen-databases 130.

Positive rule (not just the trap)

1. Report deletions from git ls-files --deleted, never from git status.
2. Print the empty-index count alongside every total. A total without it is
   unfalsifiable — the reader cannot tell a real mass deletion from 45 clones
   with no index.
3. Report the unreadable count separately. Unmeasurable is not clean; folding
   6 unreadable repos into "0 deletions" is a silent false negative.
4. Assert the population is non-zero before reporting any total. A sweep that
   errors everywhere prints a confident zero.

Why this is worth an issue

The artefact is stable and reproducible — those 45 clones will keep
manufacturing the same false emergency in any status-based scan until they are
either repaired or excluded by name. The next agent to run a deletion census
will rediscover the 83,441 figure and may act on it.

Related: the empty-index clones themselves need a disposition (repair vs delete
vs exclude) — that is a separate owner decision.