principle-laziness-protocol

懒惰协议

Aim for the most result with the least code and complexity.

用最少代码和复杂度，换最多结果。

• Prefer deletion. When asked to refactor or improve, look for removals before additions.

• Maintain a flat call hierarchy. Avoid deep call chains. A rich interface that hides substantial work is not a deep call chain. If answering a question requires tracing through more than 3 files or layers, flatten it.

• Consolidate decisions. Do not repeat the same choice in several places. Put it behind one source of truth and pass the result as a simple flag.

• Minimize the diff. Make the smallest change that solves the problem. Fewer lines beat “elegant” boilerplate.

• Question the threading. If a task asks you to pass a new signal through types, schemas, pipelines, or similar layers, stop and look for a more direct path.

• Sweat the small leaks. Remove tiny pass-throughs, representation leaks, and duplicated choices before they spread. Small leaks compound into permanent coordination costs.

• 优先删除。 被要求重构或改进时，先找能删的，再找能加的。

• 保持扁平调用层次。 避免深调用链。藏住大量工作的丰富接口不是深调用链。回答一个问题要跨超过 3 个文件或层，就压平。

• 合并决策。 别在多处重复同一选择。放在唯一真相源后面，用简单 flag 传结果。

• 最小化 diff。 做能解决问题的最小改动。更少行胜过「优雅」样板。

• 质疑穿线。 任务要你把新信号穿过类型、schema、管道或类似层，停下来找更直的路。

• 盯紧小泄漏。 在小透传、表示泄漏、重复选择扩散前删掉它们。小泄漏会复合成永久协调成本。

The test: If a human developer would find the code exhausting to maintain, it is a bad solution.

自检： 若人类开发者会觉得维护这代码累人，就是坏方案。