Code Bloat Triage
Objective
Reduce unjustified complexity without sacrificing correctness, necessary fault handling, accessibility, security, evidence, or maintainability.
Triage workflow
- Identify the actual user-facing or research requirement and its supported tests. Treat functionality and safety as constraints.
- Inventory candidate bloat: duplicate logic, dead branches, unused dependencies, unnecessary layers, speculative configuration, redundant wrappers, and oversized generated files.
- Measure only what is meaningful: cognitive complexity, dependencies introduced, code churn, duplicate coverage, review burden, and stability. Lines of code alone are not a quality metric.
- For each candidate, ask: What requirement or failure does this support? Trace to evidence; retain it if necessary, even if verbose.
- Order changes delete unused, consolidate duplicate, simplify abstractions, then optimize hot paths. Avoid a sweeping rewrite when one local fix suffices.
- Make the smallest reversible change under tests; perform positive and regression checks. Preserve behavior and externally observed contracts.
- Report benefits and tradeoffs. If removal weakens coverage or obscures behavior, do not merge the simplification.
Guardrails
No deleting research provenance, validations, approval boundaries, security checks, or known failure examples merely to reduce file count. No unjustified new libraries for small features. Do not alter frozen benchmark semantics under a refactoring label.
Output
Decision register with candidates, reason, proof, change risk, and retained safeguards.
Success criteria
A reviewer can justify each removal and confirm that supported behavior and trust boundaries are unchanged.