dead-code-eliminator

Dead Code Eliminator

Delete code only after converging evidence proves it dead, then remove it in reversible slices that include its tests, fixtures, config, and flags.

Workflow

1. Scope one cluster. Pick a single symbol, file, or feature to prove dead. Do not batch unrelated removals - a regression must point to one change.
2. Gather static evidence. Run the language's dead-code detector (ts-prune or knip for TS/JS, vulture for Python, deadcode for Go) and a dependency grapher (madge) or IDE "find usages". Record what each reports unreachable.
3. Gather runtime evidence. Check production coverage or profiling data over a representative window - at least 30 days for user-facing paths, 90+ days for code tied to monthly or quarterly jobs - and telemetry: was this endpoint, job, or branch hit this quarter? A symbol is a deletion candidate only when static analysis AND runtime evidence agree. One signal alone produces false positives that take down prod.
4. Hunt the dynamic callers static tools miss. Grep the symbol name as a string (reflection, string-keyed dispatch, serialization). Check DI containers, registries, ORM hooks, cron/queue workers, and feature-flag config. Search infra repos and other services. Public API surface and library exports are reachable by definition unless you control every consumer.
5. Classify the kind of dead, because each is removed differently. Unreachable (no path calls it) → delete. Unused (callable, never called) → delete. Redundant (duplicates a live path) → repoint callers first. Dormant-behind-a-flag (flag off for a cycle) → retire the flag first, then delete its branch.
6. Soft-delete risky removals first. Replace the suspect path with log-and-throw, or gate it behind a kill flag while keeping the code, for one full business cycle - 30 days minimum, 90 for anything touching monthly or quarterly processes. If nothing fires the log, proceed. For low-risk leaf code, skip to step 7.
7. Delete in a focused PR. Remove the code AND its tests, fixtures, config, flags, and now-orphaned imports. Keep the diff under roughly 400 changed lines so it is reviewable in one sitting; a bigger cluster gets split into multiple PRs. Let CI and the type-checker catch references the search missed. No formatting or refactors in the same diff.