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

Closed
opened 2026-07-21 15:32:49 +00:00 by crenshawdev · 1 comment
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).
Owner

Superseded 2026-08-08 by #95, which folds this together with the other two into one requirement.

The three were one idea at three points in the lifecycle - don't build it (#30), catch it if built (#29), record it if deliberately deferred (#31) - and each is nearly worthless alone: a delete-list nobody acts on, a YAGNI default with no pass catching what slips through, a marker convention with no harvest. Filed separately they also read as three unaddressed proposals rather than one unmade decision, which is how the 2026 harness dossier scored them.

Nothing is dropped. The full text stays here; #95 carries the combined scope and the reason it is not v2.6.0.

Superseded 2026-08-08 by #95, which folds this together with the other two into one requirement. The three were one idea at three points in the lifecycle - don't build it (#30), catch it if built (#29), record it if deliberately deferred (#31) - and each is nearly worthless alone: a delete-list nobody acts on, a YAGNI default with no pass catching what slips through, a marker convention with no harvest. Filed separately they also read as three unaddressed proposals rather than one unmade decision, which is how the 2026 harness dossier scored them. Nothing is dropped. The full text stays here; #95 carries the combined scope and the reason it is not v2.6.0.
john closed this issue 2026-08-08 22:51:03 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: crenshawdev/cadence-archived#29
No description provided.