修复范围膨胀或缩水时，按触发原因控制规模并显式拆分任务

当决定修复多大、范围中途漂移、计划被悄悄裁剪或出现『顺便做』时，用触发原因约束范围，裁剪时显式拆分并驱动至完成。

适用场景

解决思路

1. 核心原则：按触发原因确定修复规模；当现实迫使裁剪时，显式拆分而不是悄悄削减。
2. 触发原因是缺陷或需求本身，不是工单里对它的描述。同一缺陷在第二条路径上也出现时，它在范围内（若只报告“已修复”而它仍在别处存在，就是半真报告）；因为打开文件才发现的邻近改进不在范围内。
3. 修复范围与触发它的事物一样大。不要镀金，不要为不可达边界加围栏，不要因为文件已打开就顺带重构。
4. 你注意到的邻近改进是真实的，应放入 tracker，而不是放进这次 diff。
5. 对边界新增项做测试：如果主修复不存在，它是否凭自身价值也应该发布？如果不是，它就是对别人 diff 的装饰；如果是，它应作为独立变更发布：通过测试只授权一次单独变更，绝不授权搭车。
6. 拥有者可以重新划定范围；拥有者不能合并范围。拥有工作的人说“挤进去”会合法地增加第二个任务，但它仍应作为独立变更发布。这些规则约束工作如何成形；拥有者决定存在哪些工作。
7. 未经请求的结构是披着设计模式外衣的范围蔓延：只有一个实现者的接口、只会构建一种东西的工厂、没人会改的值的配置。等第二个用例出现时再加结构，而不是在想象中加。
8. 接受真实限制的有意简化，要在注释中带上该限制：上限以及什么情况下才值得提高它（例如“一个共享队列；当单个消费者再也跟不上时，按租户分片”）。上限是当前约束：注释描述系统今天做什么，而不是决策历史。
9. 在写新代码之前，穷尽代码库、标准库、平台和已安装依赖；在考虑新包之前查看 `adding-dependencies`。
10. 拥有者要把后来发现过大的已批准任务拆成具名部分，并说明切割线，绝不能交付一个看起来完整、实则悄悄压缩的“务实最小版”。
11. 作者要把每个推迟部分登记为有拥有者的跟踪项；若暂无拥有者，明确写「owner pending triage」。在安装了 technical-writer 插件的情况下，跟踪纪律使用其 `writing-issues`。只存在于作者记忆中的推迟工作就是被悄悄削减，而不是被推迟。
12. 报告要直白说明哪些部分已交付、哪些没有。诚实标注的部分交付是计划；把部分交付标成完成则是缺陷。
13. 已批准计划要执行到完成，不设“要我继续吗？”检查点；只在真正阻塞、破坏性操作或需要操作者的硬性门禁处停下。
14. 某一部分被阻塞时：完成未阻塞部分，暴露阻塞并说明它需要什么，绝不让一个卡住的任务悄悄拖住其余部分。
15. 执行中途，已定决策保持已定。真正会重新打开决策的新信息应成为显式重新决策，而不是悄悄转向；在安装了 technical-writer 插件的情况下，通过 `recording-decisions` 记录。
16. 代码审查时：顺带发现的不相关缺陷不是你的审查发现；为 tracker 记录一次，然后继续审查当前 diff。
17. 被审查时：针对 diff 的发现要修复或明确答复；diff 之外的发现要跟踪，不要吸收进本次变更。
18. 不要用“既然我在这里”作为理由。你在这里是为了触发原因。
19. 不要为了赶截止日期而悄悄缩减范围并报告完成。截止日期压力是真实的；诚实做法是拆分并说明交付了哪一半。
20. 不要为系统无法到达的边界情况加围栏，以显得周全。不可达的防御是带着好意的死代码。
21. 不要因为出现一个稍好的想法就在实现中途重新争论已批准设计。把想法写下来；完成计划；再基于已交付现实提出它。
22. 不要让审查者的范围外愿望扩大 diff。跟踪它，感谢他们，交付触发原因对应的修复。

适用边界 · 注意事项

• 不具备 `principal-engineering` 背景时，不适用。
• 本技能不代替拥有者决定存在哪些工作；它只约束工作如何成形。
• 需要新增依赖时，先用 `adding-dependencies`，本技能不替代该流程。