overbuild-review-lens

overbuild-review-lens

A deletion-hunting lens. It asks one question the other judges never ask: should this code exist at all? Sibling of architecture-review-lens and the judge-* family — never overlaps with them.

When to use

• A diff adds a helper, a wrapper, a config layer, an abstraction, or a dependency.
• A rewrite, v2, or large refactor landed — the peak over-build context (see minimal-safe-diff-mechanics § The sanctioned-rewrite trap).
• A reviewer asks "is all of this needed?", "could the platform do this?", or "why is this so clever?".

Do NOT use when:

• The concern is whether the code is correct — route to judge-bug-hunter.
• The concern is security — route to judge-security-auditor.
• The concern is naming, single-responsibility, or convention fit of code whose existence is not in question — route to judge-code-quality. That judge asks is this code malformed; this lens asks should it exist.
• The concern is performance — route to performance. Speed is out of scope here.
• The diff is documentation-only or formatting-only.

The scope fence — read this before the first finding

CORRECTNESS, SECURITY AND PERFORMANCE ARE OUT OF SCOPE FOR THIS LENS.
THE MINIMUM RUNNABLE CHECK IS NEVER FLAGGED FOR DELETION.
A SIZE REDUCTION THAT DROPS A GUARD IS A LOSS, NOT A FINDING.

The measured failure mode this fence exists for: a bare "make it simpler" critic was the only arm in a controlled comparison that dropped a safety guard — the three lines it saved were a path-traversal check. Tests, validation, authorization checks, tenant scoping, and error paths that can actually occur are not over-build. If removing something would reduce coverage of a real case, it is not a finding here.