harden and streamline sm-flow protocol

.agents/skills/sm-flow/references/phase-contracts.md

@@ -11,6 +11,7 @@
 - 如果用户已有 research，先识别它是否已经包含用户价值、技术方案、验收标准和任务拆分。
 - 如果输入过于模糊，最多追加三轮聚焦问题。
 - 当答案会改变 OpenSpec proposal/specs/tasks 时，优先一次只问一个问题。
+- 如果需要判断 `micro / standard / complex` 分档，补读 `references/operating-rules.md`。
 
 **退出条件**：
 - 问题可以用 1-2 句话说清楚。
@@ -53,7 +54,7 @@
 
 **动作**：
 - 优先调用 `openspec-propose`。
-- 如果不可用，执行 `references/fallbacks.md#openspec-propose-fallback`，但仍必须产出 OpenSpec 文件。
+- 如果不可用，执行 `references/fallbacks.md#openspec-提案-fallback`，但仍必须产出 OpenSpec 文件。
 - 用 Phase 0.5 的 devflow 上下文增强 OpenSpec：
   - proposal 写清为什么做、做什么、范围和非目标。
   - design 写入上下文约束、历史 ADR、关键技术决策。
@@ -82,6 +83,11 @@
 **动作**：
 - 如果没有结构化 PRD，则优先按 `to-prd` 协议生成 `brief.md`；复杂需求、对外协作或用户明确要求时再生成 `prd.md`。
 - `micro` 模式默认不创建独立 PRD，除非用户要求或需求复杂度升级；PRD 内容并入 `brief.md`。
+- 显式检查 `brief/prd -> proposal -> design -> specs -> tasks` 的 cross-artifact 对齐关系：
+  - `brief/prd` 中的目标、范围、非目标和验收预期是否进入 `proposal`。
+  - `proposal` 中的范围、约束和关键承诺是否进入 `design`。
+  - `design` 中影响实现的约束、接口影响和架构结论是否进入 `specs` 或 `tasks`。
+  - `specs` 中的可观察行为是否被 `tasks` 覆盖为可执行切片。
 - 检查 PRD、devflow 上下文和 OpenSpec 是否一致：
   - OpenSpec 是否覆盖 PRD 的用户故事和验收预期。
   - OpenSpec 是否使用 glossary 中的正确术语。
@@ -89,14 +95,17 @@
   - specs 是否能表达可观察行为。
   - tasks 是否能驱动实现，而不是泛泛描述。
 - 检查是否涉及接口影响：
+  - 接口影响分级定义见 `references/operating-rules.md#接口影响分级`。
   - 是否改变字段、DTO、service 方法、API、事件、回调、数据库契约、命令契约或跨模块调用语义。
   - 接口内部判断逻辑是否改变调用方可观察行为，例如返回数据、状态、错误码、权限结果、过滤/排序、幂等性、时序或副作用。
   - 按 L1/L2/L3/L4 记录接口影响等级；不确定时标记为 Phase 2 的 `user-interview` 问题。
+- 如果某个行为、术语、字段、约束或实现切片只出现在上游产物，必须显式标记 gap，并在进入下一阶段前修复 OpenSpec。
 - 如果发现不一致，优先修正 OpenSpec，而不是只修改 devflow 文档。
 
 **退出条件**：
 - `brief.md` 已覆盖背景、目标、范围和非目标；复杂需求存在独立 `prd.md` 或用户明确不需要 PRD。
 - OpenSpec 与 PRD/devflow 上下文没有已知冲突。
+- `brief/prd -> proposal -> design -> specs -> tasks` 的下游链路没有未处理 gap。
 - 涉及接口变更时，已记录接口影响等级和产物要求；不确定项已进入 Phase 2。
 - 所有已知冲突已修正或等待用户决策。
 
@@ -113,10 +122,14 @@
 
 **动作**：
 - 优先使用 `grill-with-docs`。
+- 进入 Phase 2 时先建立一个 question pool，并记录到 `decisions.md` 或 `evidence.md`：
+  - 默认至少覆盖术语、边界、验收三个维度。
+  - 如果变更涉及多模块、接口、权限、下游消费者、响应结构或生命周期规则，先把这些维度补进问题池。
 - 先声明本阶段采用的澄清模式，并逐项标记：
   - `evidence-driven`：问题能通过代码、文档、测试、OpenSpec 或既有 ADR 证明；代理先查证，再向用户汇报证据、结论和是否需要确认。
   - `user-interview`：问题涉及产品偏好、范围边界、验收口径、风险接受度或价值取舍；必须问用户并等待确认。
 - 至少覆盖三个维度：术语、边界、验收。
+- 从问题池中选择下一个未解决问题推进；可以并行整理 evidence-driven 证据，但 `user-interview` 仍然必须 one-at-a-time。
 - 一次只问一个 `user-interview` 问题。
 - 每个 `user-interview` 问题必须等待用户显式回答，并把回答、决策和 OpenSpec 回写状态记录到 `decisions.md`；不能由代理代替用户确认。
 - 未获得用户确认的 `user-interview` 问题必须保持未解决状态，不能进入 Phase 2.9 或 Phase 3。
@@ -127,6 +140,7 @@
 - 对难以逆转、依赖上下文、源自真实权衡的决策创建 ADR。
 
 **退出条件**：
+- question pool 已建立并覆盖当前 change 所需维度。
 - 至少解决三个高价值澄清或验证问题，并记录每个问题属于 `evidence-driven` 还是 `user-interview`。
 - 所有 evidence-driven 结论已向用户汇报。
 - 所有 user-interview 决策已获得用户确认。
@@ -169,7 +183,7 @@
 **进入条件**：
 - Phase 2 已解决术语、边界、验收三个维度的高价值问题。
 - 所有 `user-interview` 问题都已获得用户显式确认。
-- Phase 2.5 架构审计已经完成，或快速模式下已记录跳过原因。
+- Phase 2.5 架构审计已经完成，或快速模式下已记录跳过原因；快速模式定义见 `references/operating-rules.md#快速模式`。
 - Draft OpenSpec 已回写所有会影响实现的澄清、接口影响和架构审计结论。
 
 **动作**：
@@ -177,6 +191,9 @@
 - 检查 design 是否记录上下文约束、关键技术决策、架构风险和接口影响。
 - 检查 specs 是否表达外部可观察行为，并覆盖验收口径。
 - 检查 tasks 是否是可执行的纵向切片，而不是泛泛描述。
+- 复核 `brief/prd -> proposal -> design -> specs -> tasks` 是否闭环，没有把字段、范围项、验收行为或实现切片丢在上游产物里。
+- 检查 `evidence.md` 和 `decisions.md` 中所有影响实现的发现，是否已回写到 proposal、design、specs 或 tasks。
+- 接口影响分级定义见 `references/operating-rules.md#接口影响分级`。
 - 检查接口影响是否已按 L1/L2/L3/L4 判级；L3/L4 是否有独立接口文档或等价独立章节。
 - 检查没有未汇报的 evidence-driven 结论，没有未确认的 user-interview 问题，没有 devflow/OpenSpec 冲突。
 - 如果检查失败，返回 Phase 1、Phase 2 或 Phase 2.5 修正 Draft OpenSpec。
@@ -209,6 +226,7 @@
 - 优先调用 `openspec-apply-change`。
 - 执行依据是 OpenSpec specs/tasks；devflow 只能作为上下文参考。
 - 按 OpenSpec tasks 的纵向切片实现。
+- 进入实现前先汇报本阶段的 capability 来源、当前 task 进度和本轮要推进的切片；否则 Phase 3 不算真正开始。
 - 当用户质疑、用户要求修改、代码检查、测试失败或运行行为与 OpenSpec 冲突时，先分类再继续：
   - 实现偏差：Committed OpenSpec 正确，代码没有按规格做；修代码，不改 OpenSpec。
   - 规格遗漏：OpenSpec 没覆盖真实边界、接口影响、验收口径或外部可见行为；暂停 apply，修正 OpenSpec 后重新提交。
@@ -239,6 +257,7 @@
 **动作**：
 - 遵循 `references/archive-rules.md`。
 - 从 OpenSpec、实现结果和验证结果提炼 brief、evidence、decisions 和 acceptance；只在复杂场景按需拆出 PRD/research/design/tasks/alignment。
+- 把 Phase 0 到 Phase 3 已经形成的过程内记录整理为最终档案；不要把 Phase 4 当作第一次补写这些记录。
 - 写入或更新验收记录，并区分静态验证、脚本验证、浏览器/人工验证、未验证。
 - 如果本次流程产生可复用经验，写入 compound knowledge。
 - 更新 `devflow/index.md`，记录日期、slug、领域、关键词、关联 OpenSpec 和状态。