Dead code audit

What this audit answers

The dead code audit asks which repository surfaces are disconnected from current behavior and can be treated as credible cleanup candidates. It deliberately separates confirmed dead code from code that only looks unused through one static signal. Dynamic registration, public APIs, migrations, feature flags, compatibility paths, generated code, and dormant product capabilities can all have protected uses.

The score measures current cleanliness, not whether the team has a recurring cleanup process.

What Guard inspects

Guard maps entry points, imports, references, registrations, exports, routes, services, CLI and worker wiring, configuration, localization, scripts, dependency anchors, and major product capabilities. Safe reachability tools can support the analysis, but their output remains candidate evidence until protected-use cases are reviewed.

Repository history is supporting evidence only. It can help confirm current residue, but old age or low change frequency is not proof that a live path is removable.

Confidence and criteria

Candidates are classified before priority or penalty: confirmed at 85–100% confidence, likely unused at 65–84%, ambiguous at 35–64%, and weak signal below 35%. Intentional dormancy and false positives are not scored as dead code. The percentage communicates calibrated evidence strength, not a mathematical probability.

Eight 0–5 criteria summarize unwired code, unused declarations, detached config/flags/parameters/metadata, commented or copied implementation, obsolete feature residue, functionally irrelevant code, dead dependency anchors, and ambiguous candidates. A wired-but-underused capability is normally report-only context unless a specific removable path is confirmed.

How the score works

The final score starts at 100 and subtracts evidence-backed ranges: 15–25 for a broad confirmed finding, 5–12 for a local confirmed finding, 3–8 for likely unused code with one protected-use question, 5–15 for detached configuration or metadata, 2–8 per commented or copied cluster, 5–15 for a dead dependency anchor, and 3–10 for material ambiguity. A wired but underused capability subtracts nothing when intentionally dormant and only 3–8 when unclear ownership materially slows understanding.

Broad ambiguity that prevents separating live from inactive behavior can cap the score at 69. Confirmed dead code across multiple repository surfaces can cap it at 59. Systemic confirmed residue, or ambiguity so strong that current behavior cannot be understood, can cap it at 39.

Limitations and boundaries

The audit is read-only and does not delete code. Tool gaps, dynamic dispatch, external consumers, generated contracts, shallow history, and unavailable product ownership can leave candidates ambiguous. Those cases stay out of an automatic cleanup queue.

Per-option defects inside otherwise live configuration belong to configuration hygiene. Broad codebase smells belong to codebase hygiene. Dead code requires reachability and protected-use reasoning, not just a linter warning.

Improvements and reruns

Only confirmed or likely-unused candidates should enter a cleanup proposal, and every candidate needs fresh current-state validation before a write. Ambiguous, weak, intentionally dormant, false-positive, and underused-capability entries remain owner decisions or report context.

Prefer one coherent cleanup with tests or build verification over a sweeping deletion. After merge, rerun to ensure the residue is gone and no registration, consumer, compatibility path, or product behavior was broken.