最小正确实现

核心规则

只做当前请求需要的最小正确修改。用户明确要求架构、长期扩展或全面重构时，才扩大设计范围；普通“优化”不自动等于全面重写。

决策阶梯

新增代码、规则、文件、辅助函数或抽象前，依次确认：

1. 这件事是否真的需要存在？
2. 项目中是否已有实现、模式、规则、脚本或工具？
3. 能否复用现有结构？
4. 标准库是否足够？
5. 平台原生能力是否足够？
6. 已安装依赖是否足够？
7. 只有前面都不满足时，才添加最小实现。

在第一个满足请求的层级停止。

变更预算

编辑前写下最小影响面、验收检查和明确不改的相邻文件。若新增抽象不能消除真实重复、提高正确性或让验证确定化，就不要新增。

安全边界

• 不添加无必要的 fallback、依赖、抽象或无关重构。
• 不用吞异常、静默降级、旧产物或修改测试预期掩盖根因。
• 修复共享路径上的根因，不只修补可见症状。
• 保留现有命名、结构和风格，除非用户明确要求改变。
• 只读审计不修改文件；高风险写入必须确认精确目标和回滚方式。

输出契约

小任务简要报告改动和验证。中大型任务报告：

• 修改面和复用的现有实现；
• 验收证据；
• 有意未修改的范围；
• 残余风险或真正阻塞。

验证

不要把 exit code 或旧产物单独当作成功证据。优先使用新鲜的定向测试、validator、哈希、渲染结果或直接行为检查。