在实现、收敛和交接前简化代码及周边变更：用最少概念满足行为且…

当需要让代码、测试、文档、配置等变更更紧凑、清晰、高性能且最小化，同时保持行为不变时使用；适用于实现中、行为验证后和交接或合并前。

适用场景

解决思路

1. 产出能完整满足所需行为的最小清晰实现。
2. 最小化概念和活动部件，而不是代码行数。
3. 在构建期间局部应用简化优先级，并在发现行为时允许明显临时的插桩或脚手架来加速学习。
4. 在收敛时，一旦某个逻辑行为切片通过验证，就简化该切片、移除已被取代的尝试，并重跑聚焦验证。
5. 在交接或合并前，将完整分支与其 merge base 比较，并协调代码、测试、注释、文档、配置和相关历史。
6. 识别所需行为、不变量、约束和非目标。
7. 检查相关 diff 并将其拆分为逻辑概念；最终分支审计时，将完整分支与 merge base 比较，并在相关时检查历史中已被取代的尝试。
8. 在新增任何东西之前，检查现有负责人、事实来源、常用路径和决策点。
9. 选择所需概念最少、运行时工作最少的设计。
10. 当要求变更时，直接实现，并在合适处复用现有机制。
11. 用与风险成比例的检查验证行为。
12. 审查最终代码、测试、名称、注释、文档、配置和相关历史，移除任何不再值得其复杂度的事物。
13. 优先删除、复用或直接修改，而不是新增抽象。
14. 保持单一事实来源；避免镜像状态、重叠守卫、重复注册表和补偿机制。
15. 避免推测性回退、兼容路径、配置、参数和通用 API。
16. 当一个一次性 helper 内联后能使策略在决策点更清晰时，内联它。
17. 优先采用直接的正向控制流，而不是 early-return 链或空分支。
18. 在 hot paths 上，最小化内存分配、回调重建、订阅、渲染、遍历、I/O 和原生工作。
19. 对于文字，删除重复，并保留仍然自足的最短措辞或示例。
20. 简化工作代码前建立通过基线。
21. 一次测试一个可疑概念，重跑相关验证；如果行为或有效覆盖削弱，则恢复该概念。
22. 在确定哪些改动因果必要之前，不要重构多个累积的修复尝试。
23. 当怀疑存在重复或无效回归覆盖时，故意破坏所声称的不变量，并确认剩余测试失败。
24. 不要仅凭测试通过就认为每个测试或实现概念都是必要的。
25. 未经授权不要重写分支历史。
26. 性能更改时，命名正在被移除的精确 common-path 工作：内存分配、扫描、挂载、渲染、订阅、I/O 或原生调用。
27. 控制流证据加回归测试可以证明移除结构上未使用的工作是合理的。
28. 当优化改变语义或引入取舍时，要求基准测试、性能剖析或可重复复现。
29. 不要为理论收益增加复杂度。
30. 保留正确性、所需行为、类型安全、不同的回归覆盖和有用的清晰度。
31. 不要仅仅为了减少行数，就用压缩或聪明的代码替换清晰代码。
32. 直接做有范围、行为保持的改进；如果更好的设计需要大规模 API 或架构变更，解释并建议，而不是未经批准扩大任务。
33. 不碰无关和用户编写的更改。
34. 当每个剩余概念都支持需求、不变量、清晰度或经过测量的性能需求时停止。
35. 只报告实质性简化、验证和未解决的机会。

适用边界 · 注意事项

• 当更好的设计需要大规模 API 或架构变更且未获批准时，不适用于在本任务中直接展开简化，应解释并建议。
• 当性能优化会改变语义或引入取舍，且缺少基准测试、性能剖析或可重复复现时，不适用于实施该优化。
• 未经授权不适用于重写分支历史；也不适用于改动无关或用户编写的变更。