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

New issue

Open

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

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).