hrt-change-size-gate

hrt-change-size-gate

将多个独立用户故事捆绑在一个变更中，会同时增加后续每个阶段（规范、设计、任务、应用）的工作量，并降低质量。此门禁会在 proposal 阶段、写入任何制品之前捕获此类情况。

此门禁倾向于一个变更。过度拆分是更常见的问题——一个涵盖多个层或多种能力的宽泛故事很常见，不代表需要拆分。Agent MUST NOT 自行拆分：由它提出建议，用户决定。

何时运行

在 proposal 阶段，起草好「变更内容」和「能力」作为工作内容后、最终确定其中任一项之前。

检查内容

Agent MUST 检查草拟的「变更内容」列表，判断其中是否有两项或更多同时满足以下三个条件：

1. 可独立交付——仅交付该项（而非其他项）仍能为用户提供可用且可验证的成果。
2. 无依赖关系——该项不依赖列表中其他项的代码或数据。
3. 能力不同——没有两项属于正在草拟的「能力」部分中的同一项能力。（此阶段尚不存在 specs/**——检查「能力」列表，而非磁盘。）

示例——相互独立：「添加 CSV 导出」+「添加深色模式开关」（可以单独交付任一项）。不独立：「添加 CSV 导出」+「添加导出的权限检查」（没有导出功能，检查就毫无意义——这是一个切片）。

• 少于两项符合条件 → 门禁 MUST NOT 触发。继续作为一个变更处理，不作提示。
• 两项或更多 → 这会实质性影响范围。Agent MUST 停止，MUST 询问用户「一个变更还是多个变更？」（指出哪些项看起来相互独立，以及原因），并且在用户回答之前 MUST NOT 继续。沉默不算回答。提问 MUST 遵循 plain-language-writing 技能的 COMMS 规则。

在深色模式下（存在 dark.md），门禁仍会升级给用户——MUST NOT 转交给 hrt-dark-mode-decision-gate。答案取决于用户的能力和优先级，而这些信息不会记录在任何依据制品中。

如果用户决定保留为一个变更

保持提案不变，继续推进。不作记录。

如果用户要拆分

按顺序执行。步骤 1–3 立即执行；步骤 4–5 在同一阶段稍后执行，如下所述。

1. 询问现在要构建哪个切片。仅为该切片编写 proposal.md。

2. 在 proposal.md 中添加 ## Out of Scope 部分——每个排除的切片占一行。

3. 在 discovery.md 的 Key Decisions 中添加一条记录（不要放在 Open Questions 中——这是已确定的范围决策，并记录了被拒绝的备选方案）：

   范围：仅构建切片 <X>——切片 <Y, Z> 拆分为单独的变更（在提案规模门槛处决定）。拒绝的备选方案：合并为一项变更（规模过大；下游阶段会膨胀）。

   此条记录 MUST 永久保留——后续拾取切片 Y 的变更 MUST NOT 将其删除。它记录了本次 discovery 会话涵盖的内容。

4. 当阶段的 hrt-adversarial-authoring 步骤运行时：如果其 Destructive Critic 进一步缩小范围，将新排除的切片添加到 ## Out of Scope。

5. ## Out of Scope 最终确定后，同步 openspec/BACKLOG.md：

   • 如果现有条目现已包含在此变更范围内（根据最终版 proposal.md 判断其 “Slice” 行），删除该条目。

   • 为剩余的每个 ## Out of Scope 切片追加一条记录：

     ## <slug-kebab>
     - 提出者：<this change-id>（<YYYY-MM-DD>）
     - 切片：<1–2 句话：此切片完成后，用户可以演示什么>
     - 延后原因：<阻塞依赖项 / 范围 / 容量>
     

   • 如果文件不存在，创建文件，标题为 # Deferred Slices，并添加一行：

     在规划其他变更时提出、但有意延后的切片。不是提案——仅提供足够信息以启动 discovery 会话。当某条目成为一项变更时，将其删除。

   • 如果删除操作使文件中不再有任何条目，保留标题——MUST NOT 删除该文件。

proposal.md 中的 ## Out of Scope 是权威内容（随变更归档）；BACKLOG.md 是由其派生并持续保留的内容（供之后拾取）。这种冗余是有意为之。

回退方案

此门槛需要用户交互。在非交互式运行中，无法通过询问来确定范围——按单项变更继续，并在 proposal.md 中注明无法执行此门槛。这是 OpenSpec 的一般限制，并非此门槛特有。