用途：在决定一个修复应该做多大、任务执行中范围开始漂移、计划被悄悄修剪以凑数，或出现“顺便一起做”时使用。背景要求：需先掌握 principal-engineering 技能。
主要原则：范围和触发问题应匹配。金镀式扩张会让修复超出其触发原因；静默缩减会让已批准任务交付低于约定内容，二者本质都是交付物与原因不再对应。核心做法是按触发问题定尺寸：触发问题是缺陷或需求本身，而非工单里的那句话。同一缺陷在第二条路径上被发现仍属范围内；因为打开了文件而顺手发现的相邻改进则不属范围。修复大小应与触发它的事物相称，不做金镀、不给不可达边界加围栏、不因文件已打开就顺带重构。注意到的相邻改进应记入跟踪器，而非本次改动。边界新增测试：如果主修复不存在，它是否仍能凭自身价值发布？能则单独发布，不能则是他人 diff 上的装饰。负责人可重新定范围，但不能合并范围；“挤进来”的任务仍应作为独立改动交付。未被请求的结构是披着设计模式外衣的范围蔓延，应在第二个用例出现时再加结构。有意简化若接受真实限制，应在注释中写明该限制及提高它的条件。先耗尽代码库、标准库、平台和已安装依赖，再考虑新代码与新增依赖。
拆分而非静默缩减：已批准任务过大时，负责人应拆成具名部分并写明切分线，不得交付看起来完整的“务实最小版”。延后部分应作为跟踪项记录并指定负责人，无负责人时写“待分类”。报告应明确哪些部分已交付、哪些未交付。诚实标注的部分交付是计划，标注完整却是部分交付则是缺陷。
推进完成：已批准计划应无“要我继续吗”检查点地跑完，仅在真实阻塞、破坏性操作或硬性门禁时停下。某部分被阻塞时，完成不受阻塞的部分并暴露阻塞及所需条件。已定决策在执行中保持稳定，新信息若真正重开决策应显式重决策并记录。
评审中的范围：评审时顺带发现的不相关缺陷不是你的发现，记一次给跟踪器，继续看当前 diff。被评审时，针对 diff 的发现应修复或明确回应；diff 之外的发现应跟踪，不得吸收进本次改动。
常见错误：以“我正好在这里”为理由；为赶截止日期缩减范围却报告完成；给系统无法到达的边界加围栏；因出现略好想法而在实现中途重新争论已批准设计；让评审者越界的愿望扩大 diff。