Gap
#44 added the YAGNI standard and #46 made over-engineering the sixth review dimension. Both are detection — they catch speculative machinery after it has been designed and written.
Nothing tells the planner or the implementer not to produce it in the first place. §1 ("Plan Mode Default") describes plan format and the review gate but says nothing about plan scope, and §1c's implementer step just says "implements an atomic task per the approved plan".
Why this matters at plan time specifically
A plan is where speculative machinery gets legitimised. Once "add a --strategy flag" is a numbered task in an approved plan, it stops reading as a guess and starts reading as a requirement — the implementer builds it, the reviewer sees it matches the plan, and it ships. The review dimension then has to argue against an approved decision rather than against a stray idea.
It is also the cheapest possible point to catch it: deleting a line from a plan costs nothing, while pruning the same thing later costs an implementation, a review round, a refactor, and a re-verification that the refactor changed no behaviour (per #46's "Verifying a Refactor").
Evidence
In the batch that prompted #44, a Puppet profile shipped at 343 lines and was later pruned to 100 with no behaviour change. The removals were a parameter no caller overrode, a parameter whose one caller always took the default, ~15 lines of idempotence machinery guarding a state the calling system cannot reach, and validation heavier than the risk.
None of that was a coding mistake — each item was correct, reasoned and tested. They were planning decisions, made before a line was written, and every later gate accepted them because they matched the plan.
Proposed
- One bullet in §1: plan the smallest thing that satisfies the request; name the caller for every parameter, option and abstraction the plan introduces, and cut the item if that caller is hypothetical.
- One sentence on §1c step 1: implement the task, not a generalised version of it; if the task appears to need machinery the plan didn't call for, re-plan rather than improvise.
Gap
#44 added the YAGNI standard and #46 made over-engineering the sixth review dimension. Both are detection — they catch speculative machinery after it has been designed and written.
Nothing tells the planner or the implementer not to produce it in the first place. §1 ("Plan Mode Default") describes plan format and the review gate but says nothing about plan scope, and §1c's implementer step just says "implements an atomic task per the approved plan".
Why this matters at plan time specifically
A plan is where speculative machinery gets legitimised. Once "add a
--strategyflag" is a numbered task in an approved plan, it stops reading as a guess and starts reading as a requirement — the implementer builds it, the reviewer sees it matches the plan, and it ships. The review dimension then has to argue against an approved decision rather than against a stray idea.It is also the cheapest possible point to catch it: deleting a line from a plan costs nothing, while pruning the same thing later costs an implementation, a review round, a refactor, and a re-verification that the refactor changed no behaviour (per #46's "Verifying a Refactor").
Evidence
In the batch that prompted #44, a Puppet profile shipped at 343 lines and was later pruned to 100 with no behaviour change. The removals were a parameter no caller overrode, a parameter whose one caller always took the default, ~15 lines of idempotence machinery guarding a state the calling system cannot reach, and validation heavier than the risk.
None of that was a coding mistake — each item was correct, reasoned and tested. They were planning decisions, made before a line was written, and every later gate accepted them because they matched the plan.
Proposed