Least code, still safe

woostack's skills, and the code they generate, write as little code as necessary. Less code is less to read, test, and break. "Least code" is a discipline, not a golf score. Correctness and safety set its lower bound.

Understand first, then take the first rung that holds

Laziness applies to the solution, never to reading. The author reads the touched code and traces the real flow end to end before writing anything. The smallest change in the wrong place is a second bug. The first rung that solves the problem wins:

1. YAGNI: decide whether the code is needed at all.
2. In-tree reuse: use a helper, utility, or pattern that already exists in the repository.
3. The standard library: use what the language already provides.
4. A native platform feature: use the platform before adding another layer.
5. An already-installed dependency: reuse a dependency the project already carries.
6. One line: prefer a direct expression when it remains clear and safe.
7. New code: only then, write the minimum new code that works.

Never shrink code by cutting safety

Deletion beats addition, and boring beats clever. Code is small because it is necessary, not golfed. What never gets cut to shrink a diff: validation, error handling, security, accessibility, and data-loss handling. Deliberate multi-layer safety redundancy stays (it is not DRY-removable). At equal size, pick the edge-case-correct option, and a behavior-changing simplification keeps its regression test. A knowingly-cut corner leaves a why comment naming its ceiling and upgrade path.

Comments explain why, not what

Comments are minimal and explain why: a hidden constraint, a workaround, or a surprising invariant. The code already says what.

Where it lives

The tenet is enforced across the loop, not just stated:

• The full generated-code standard is patterns.md §7.
• At the specification and planning boundaries, woostack-build, woostack-fix, woostack-ideate, woostack-harden, and delegated woostack-plan require removal or simplification analysis before additive work. woostack-execute remains the implementation enforcer, while woostack-change applies the authoring discipline to bounded changes.
• The always-on simplify review angle enforces the ladder; the source-triggered comments angle catches comment drift when source changes.