principle-laziness-protocol

Prefer deletion over addition, make the smallest change that solves the problem, and question any task that threads a new signal through multiple layers. If a human maintainer would find the result exhausting, simplify it.

Look for removals before additions, consolidate repeated decisions behind one source of truth passed as a simple flag, and avoid elegant boilerplate. Fewer lines that solve the problem beat larger structural rewrites.

Flatten when answering a question about the code requires tracing through more than 3 files or layers. A rich interface hiding substantial work is acceptable; long chains of pass-through calls are not.

It is wrong when it only passes data through, duplicates a decision made elsewhere, or leaks a representation across boundaries. Small pass-throughs compound into permanent coordination costs and should be removed early.

Yes, the principles are scale-independent: minimize each diff, remove tiny leaks before they spread, and keep call hierarchies flat. Apply them incrementally per change rather than attempting a wholesale rewrite.