用途：让拉取请求的边界表达可评审的成果，而不是实现上的便利。一个“目标”指一个连贯的产品或工程成果，可能包含多个任务、提交、测试、生成文件或文档改动。
适用时机：当计划把目标或任务分配到工单、工作树、分支或 PR 时；当提议的 PR 包含多个成果时；当有人以共享文件、顺序或中间状态为由合并工作时；或实现过程中出现拆分/合并已批准 PR 分组的压力时。
决策规则：每个可独立评审的目标拥有自己的工单、工作树、分支和 PR；仅当已批准计划记录了为何拆分不安全或无法形成有意义评审边界时，才合并目标，且不得静默更改已批准的分组。
应用方式：用不描述实现步骤的方式陈述每个预期成果；判断每个成果能否被独立评审、验证、接受、回滚和排序；即使触及相同文件或实现上方便，也拆分独立成果；把完成并证明同一成果所必需的支持代码、测试、生成产物和文档保留在同一目标内；若拆分会产生不安全、无效或无意义的中间状态，须在批准前把具体原因记入计划，只合并不可分割的工作；批准后，将实际分组与已批准的任务和 PR 分组对比，任何批准未覆盖的拆分、合并或新增目标都应停止并回到规划。
限制与反例：一个目标不等于一个文件、一次提交或一个任务；行为变更及其必需的测试和文档属于同一目标。触及同一模块不足以合并两个缺陷修复，可用有序或堆叠 PR 保持各自独立意义。“改动很小”“代码已经打开”“评审一个 PR 更快”属于便利理由，不是不安全拆分的理由。当单独评审或落地任一者会使仓库无效时，源与生成输出可留在一起，但计划必须说明。保持行为的前置重构可作为独立目标并排序，而非藏在功能 PR 中。紧急情况不消除批准边界，若需更改已批准分组，应停止并获取更新后的计划。
可观察变化：计划或执行报告为每个目标显示一行，含工单、工作树、分支和 PR；每个合并分组都包含已批准的不安全拆分或无有意义边界的原因；实现中出现不匹配时，应回到规划而非擅自更改分组。