review: over-engineering / minimalism lens (delete-list pass, separate from correctness) #29

New issue

Open

opened 2026-07-21 15:32:49 +00:00 by crenshawdev · 0 comments

crenshawdev commented

2026-07-21 15:32:49 +00:00

(Migrated from github.com)

Summary

Add an over-engineering lens to the review subsystem: a pass that hunts complexity to delete (reinvented stdlib, unneeded deps, single-implementation abstractions, dead flexibility, config nobody sets) and hands back a ranked delete-list. Distinct from correctness review. Candidate surfaces: a dimension inside cad-plan-review, a cad-reviewer mode, or an on-demand /cad-review-style variant scoped to complexity only.

Motivation

cad-reviewer refutes for correctness. Adversarial correctness review structurally misses over-abstraction, because over-building is not a bug: it is code that works and should not exist. Over-delivery is a known failure mode of agentic executors, and nothing in the current spine names or catches it. This is the one real gap the ponytail survey exposed.

Prior art

Surfaced while surveying the ponytail plugin (https://github.com/DietrichGebert/ponytail). Its ponytail-review (diff) and ponytail-audit (repo-wide) skills are exactly this pass: one line per finding, tagged delete / stdlib / native / yagni / shrink, ranked biggest-cut-first, ending in net: -N lines possible, applies nothing. Worth lifting the lens, not the code.

Notes and boundaries

Scope strictly to complexity. Keep correctness, security, and performance out (route those to the normal review pass). The two must not blur.
Cadence's discipline is process rigor. This lens is about minimal output, never minimal verification. Keep that line bright.
Guardrail: a single smoke test or assert-based self-check is the minimum, not bloat. Do not let the lens flag it for deletion.

Acceptance (rough)

A review mode or trigger that returns a ranked delete-list on a diff, optionally repo-wide.
Findings use a fixed tag vocabulary plus a net-lines total. Lists, does not apply.
Wired through the existing review subsystem and reviewer config. On-demand, not a default phase step.

Part of a three-issue set seeded from the ponytail survey (executor minimalism posture, and the in-code shortcut-marker ledger).

## Summary Add an over-engineering lens to the review subsystem: a pass that hunts complexity to *delete* (reinvented stdlib, unneeded deps, single-implementation abstractions, dead flexibility, config nobody sets) and hands back a ranked delete-list. Distinct from correctness review. Candidate surfaces: a dimension inside `cad-plan-review`, a `cad-reviewer` mode, or an on-demand `/cad-review`-style variant scoped to complexity only. ## Motivation `cad-reviewer` refutes for correctness. Adversarial correctness review structurally misses over-abstraction, because over-building is not a bug: it is code that works and should not exist. Over-delivery is a known failure mode of agentic executors, and nothing in the current spine names or catches it. This is the one real gap the ponytail survey exposed. ## Prior art Surfaced while surveying the ponytail plugin (https://github.com/DietrichGebert/ponytail). Its `ponytail-review` (diff) and `ponytail-audit` (repo-wide) skills are exactly this pass: one line per finding, tagged `delete / stdlib / native / yagni / shrink`, ranked biggest-cut-first, ending in `net: -N lines possible`, applies nothing. Worth lifting the lens, not the code. ## Notes and boundaries - Scope strictly to complexity. Keep correctness, security, and performance out (route those to the normal review pass). The two must not blur. - Cadence's discipline is process rigor. This lens is about minimal *output*, never minimal *verification*. Keep that line bright. - Guardrail: a single smoke test or assert-based self-check is the minimum, not bloat. Do not let the lens flag it for deletion. ## Acceptance (rough) - [ ] A review mode or trigger that returns a ranked delete-list on a diff, optionally repo-wide. - [ ] Findings use a fixed tag vocabulary plus a net-lines total. Lists, does not apply. - [ ] Wired through the existing review subsystem and reviewer config. On-demand, not a default phase step. Part of a three-issue set seeded from the ponytail survey (executor minimalism posture, and the in-code shortcut-marker ledger).