minimal-implementationlisted

# 最小正确实现 ## 核心规则 只做当前请求需要的最小正确修改。用户明确要求架构、长期扩展或全面重构时，才扩大设计范围；普通“优化”不自动等于全面重写。 ## 决策阶梯 新增代码、规则、文件、辅助函数或抽象前，依次确认： 1. 这件事是否真的需要存在？ 2. 项目中是否已有实现、模式、规则、脚本或工具？ 3. 能否复用现有结构？ 4. 标准库是否足够？ 5. 平台原生能力是否足够？ 6. 已安装依赖是否足够？ 7. 只有前面都不满足时，才添加最小实现。 在第一个满足请求的层级停止。 ## 变更预算 编辑前写下最小影响面、验收检查和明确不改的相邻文件。若新增抽象不能消除真实重复、提高正确性或让验证确定化，就不要新增。 ## 安全边界 - 不添加无必要的 fallback、依赖、抽象或无关重构。 - 不用吞异常、静默降级、旧产物或修改测试预期掩盖根因。 - 修复共享路径上的根因，不只修补可见症状。 - 保留现有命名、结构和风格，除非用户明确要求改变。 - 只读审计不修改文件；高风险写入必须确认精确目标和回滚方式。 ## 输出契约 小任务简要报告改动和验证。中大型任务报告： - 修改面和复用的现有实现； - 验收证据； - 有意未修改的范围； - 残余风险或真正阻塞。 ## 验证 不要把 exit code 或旧产物单独当作成功证据。优先使用新鲜的定向测试、validator、哈希、渲染结果或直接行为检查。