精简变更
由变更作者自行进行的编辑清理：在打开 PR 之前，以及推送大型修复之前，在你的分支上运行此流程。它先于 Code Review，且绝不替代 Review。继承任务的范围和修复权限；仅审查请求会返回发现项而非编辑。由选定的维护者工作流负责发布、审查和合并。
代码差异（diff）是一个提案。 通过测试表明它运行正常，但并不能证明其架构或每个新增测试都是必要的。
规则： 根目录下的 AGENTS.md 文件中的“设计优先级”、“单一负责人，完整切换”、“运行时和代码安全保障”以及“产品与验证”部分，以及最近作用域内的 AGENTS.md。步骤 2 和步骤 3 将每条规则应用于每个已变更的文件。
1. 重新推导最小的完整修复
阅读用户期望的结果和最新范围、针对目标合并基础的完整差异以及保留的验证。复用已收集的会话上下文。然后询问：
从基础出发，利用已有的代码负责人，什么是最小的完整修复？我还会引入这种架构吗？
首先检查最大的新增模块、状态、适配器和测试脚手架。阅读它们的直接调用者和相关历史：看似冗余的行为可能保护了已发布的配置或早前的回归问题。范围是已变更的系统及其替换的路径。
将每个变更的代码块（hunk）追溯到声明的结果。服务于其他目标的代码块应移出本次变更：将其删除或移至独立的 PR。
计算非机械性变更的行数。超过约 800 行，或复杂逻辑超过约 500 行时，确定可以首先交付的最小且一致的处理阶段，并将变更裁剪至该阶段。
完成时，你应该能够用一句话分别描述缺陷、必要的不变量以及最小的完整修复，并且每个剩余的代码块都服务于该修复。
2. 移除不必要的架构
对代码差异应用每项支持的简化：
- 单一决策负责人。 将重复的调用方策略迁移到拥有决策权的操作中。迁移受影响的调用方，并移除旧的实现、导出和修复分支。不同的传输方式可以共享同一个决策，同时保留各自的交付合约。
- 优先使用现有状态。 挑战新增的 schema、管理器、缓存和组合表示。当现有负责人的生命周期、权限、原子性和清理机制适用时，就复用它。仅当迁移确实不必要时才移除提议的迁移；保留能使现有配置和状态在更新后继续正常工作的迁移。新状态应属于一个具有明确含义的字段。
- 删除冗余路径。 移除并行的渲染器、重复的解析器、仅用于获取结果的伪生命周期操作、调用方已经可以获取的派生状态以及仅用于转发或重命名的包装器。偏好一种更简单的表示方式，而不是围绕旧表示方式提供回退模式。
- 最后做精炼。 在每个变更的代码块中，只保留维护者在该文件中通常会编写的内容：
- 解释负责人、生命周期、排序或约束的注释；
- 与周围模块匹配并防御真实状态的检查语句和
try/catch块； - 真实的类型而非类型擦除的转型（如
as any、as unknown as T、先放宽再断言）； - 增加领域含义、消除重复或简化控制流的变量和辅助函数；
- 有明确已发布合约和移除计划支持的 shim、别名、重试和回退机制；
- 与周围文件匹配的命名、控制流、导入和格式。
保留请求的修复和受支持的行为，而不是提案中的偶然设计。保留真实的领域差异和合理的公开兼容性。当历史记录（git log -p -S <符号>）无法明确某条路径的用途时，保留它并报告。将新的产品决策、破坏性合约、无关清理和破坏性分支替换作为发现项报告给负责人。
3. 保留用于验证失败的测试
对于每个新增或更改的测试组及其设置辅助函数，命名它们能捕获的不同可观察失败。
保留针对实际缺陷和不同边界的回归测试：排序、取消、过期的权限、重启、拒绝、真实错误以及受影响的消费者差异。保留独立保护真实边界的静态合约守卫。移除重复的相同路径用例、模拟回声、无关的字段复制或措辞断言、对静态定义值的断言、仅证明已删除逻辑已不存在的测试、过时实现的测试以及脚手架或仅为测试而设的生产钩子。将有用的测试用例整合到现有的负责人测试套件中。
删除测试绝不削弱剩余的断言、真实边界的覆盖范围或基线。
完成时，每个剩余的测试组都必须有一个命名的失败场景。
4. 验证更小的变更并交付
批处理编辑，然后重新运行针对变更合约和受影响的消费者的重现检查和针对性检查。复用其输入未变的现有验证。保留的重启、升级或传输声明需要适用的验证。现有的工作流会选择更广泛的检查。
完成条件：完整的差异已检查，每条规则对每个已变更文件都有判定结果，已应用支持的简化，被取代的路径已不可达，受影响的行为仍有验证。当现有形状合理时，“无变更”也是一个有效结果。目标是净减少代码量，而非达到删除指标。
在 PR 正文或现有任务证据中报告：已消失的责任或机制、仍受保护的行为、以及相对于合并基础的生产/测试差异。将针对早期版本的缩减与整体变更差异分开标记。说明任何必要的剩余增长或未解决的决策。
然后打开或更新 PR。在后期修复之后，在推送之前只简化新的变更及其所涉及的负责人。