executor: YAGNI-minimal output posture (build the minimum, flag the fuller option) #30

New issue

Closed

opened 2026-07-21 15:32:50 +00:00 by crenshawdev · 1 comment

crenshawdev commented

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

(Migrated from github.com)

Summary

Give cad-executor a minimalism default: build the minimum the task needs, and when a step invites over-building, ship the lean version and flag the fuller option in one line (in the deviation record) instead of building it speculatively.

Motivation

Executors over-deliver by default: speculative abstractions, config nobody sets, scaffolding "for later". Build time is the cheapest place to attack over-engineering, before it ever reaches review. A YAGNI default here is guidance, not a new subsystem.

Prior art

ponytail (https://github.com/DietrichGebert/ponytail) is this idea as a persistent mode. Its ladder, stop at the first rung that holds: does this need to exist (YAGNI), reuse what already lives in the codebase, stdlib, native platform feature, already-installed dep, one line, then only the minimum that works. The load-bearing part is the guardrails, not the "write less":

Never simplify away trust-boundary validation, data-loss handling, security, accessibility, or anything explicitly requested.
"Read fully, then be lazy." The ladder shortens the solution, never the reading. A small diff you do not understand is a second bug.
Bug fix means root cause, not symptom: grep every caller and fix the shared function once.

Boundaries

Minimal output, never minimal verification. This must not weaken cadence's plan and verify rigor.
Do NOT adopt ponytail's persistent global "mode" machinery (hooks, flag file, intensity levels). Cadence does not need it. This is executor guidance only.

Acceptance (rough)

cad-executor guidance carries a YAGNI / minimal-output default with the non-negotiable guardrails spelled out.
When a task invites over-build, the executor ships lean and names the fuller option in its report rather than building it.

Part of a three-issue set seeded from the ponytail survey (over-engineering review lens, and the in-code shortcut-marker ledger).

## Summary Give `cad-executor` a minimalism default: build the minimum the task needs, and when a step invites over-building, ship the lean version and flag the fuller option in one line (in the deviation record) instead of building it speculatively. ## Motivation Executors over-deliver by default: speculative abstractions, config nobody sets, scaffolding "for later". Build time is the cheapest place to attack over-engineering, before it ever reaches review. A YAGNI default here is guidance, not a new subsystem. ## Prior art ponytail (https://github.com/DietrichGebert/ponytail) is this idea as a persistent mode. Its ladder, stop at the first rung that holds: does this need to exist (YAGNI), reuse what already lives in the codebase, stdlib, native platform feature, already-installed dep, one line, then only the minimum that works. The load-bearing part is the guardrails, not the "write less": - Never simplify away trust-boundary validation, data-loss handling, security, accessibility, or anything explicitly requested. - "Read fully, then be lazy." The ladder shortens the solution, never the reading. A small diff you do not understand is a second bug. - Bug fix means root cause, not symptom: grep every caller and fix the shared function once. ## Boundaries - Minimal output, never minimal verification. This must not weaken cadence's plan and verify rigor. - Do NOT adopt ponytail's persistent global "mode" machinery (hooks, flag file, intensity levels). Cadence does not need it. This is executor guidance only. ## Acceptance (rough) - [ ] `cad-executor` guidance carries a YAGNI / minimal-output default with the non-negotiable guardrails spelled out. - [ ] When a task invites over-build, the executor ships lean and names the fuller option in its report rather than building it. Part of a three-issue set seeded from the ponytail survey (over-engineering review lens, and the in-code shortcut-marker ledger).

john referenced this issue

2026-08-08 22:50:55 +00:00

minimalism: one lens at build, review and deferral, replacing #29/#30/#31 #95

john referenced this issue

2026-08-08 22:51:03 +00:00

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

john commented

2026-08-08 22:51:03 +00:00

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:04 +00:00

john referenced this issue

2026-08-08 22:51:04 +00:00

capture: in-code deliberate-shortcut marker harvested into a debt ledger #31

john referenced this issue from a commit

2026-08-09 19:53:37 +00:00

docs: fold the minimalism cluster into one deferred requirement