harden and streamline sm-flow protocol

.agents/skills/sm-flow/SKILL.md

@@ -24,15 +24,16 @@ SM Flow 是一套 **OpenSpec-first / Devflow-assisted** 的软件交付元工作
 
 - Phase 3 默认必须通过 OpenSpec apply 执行；禁止直接依赖 devflow 文档绕过 OpenSpec 写代码。
 - devflow 产物只能辅助生成和校准 OpenSpec，不能成为 Phase 3 的主要执行依据。
-- devflow 默认采用分层产物：只强制保留人类理解和 OpenSpec 校准所必需的档案，避免重复 OpenSpec 的 proposal/design/tasks。
 - 不得跳过 Phase 0.5：生成或修正 OpenSpec 前，必须读取相关 devflow 上下文。
 - 不得跳过 Phase 2。即使需求看起来很清楚，也至少解决三个高价值澄清或验证问题。
 - 不得跳过 Phase 2.9：进入 Phase 3 前，必须确认 Draft OpenSpec 已提交为 Committed OpenSpec。
+- Phase 0、0.5、1、2、2.5、2.9 只有在显式 checkpoint 后才算完成；checkpoint 至少汇报当前阶段、能力来源、产出物、已满足退出条件和未解决阻塞。
 - `evidence-driven` 不是自动通过：凡是通过证据确认的结论，也必须向用户汇报证据、结论和是否需要确认。
 - `user-interview` 问题必须等待用户确认；涉及范围、偏好、验收口径、风险接受度时不能擅自决定。
+- Phase 1.5 必须显式检查 `brief/prd -> proposal -> design -> specs -> tasks` 的 cross-artifact 对齐；发现缺口时先修 OpenSpec，再继续后续阶段。
+- Phase 2 必须先建立 question pool，再按 one-at-a-time 规则消费 `user-interview` 问题；问题池至少覆盖术语、边界、验收，复杂变更还要补充模块、接口、权限、消费者、响应结构或生命周期维度。
 - grill 过程必须显式 human-in-the-loop：每个 `user-interview` 问题一次只问一个，必须等用户回答并记录确认后才能继续；未确认的问题不能视为已解决。
 - 单个 grill 决策确认不等于 Phase 3 apply 授权；Phase 2/2.5 回写 OpenSpec 后必须停在 Phase 2.9，报告 Committed OpenSpec 检查结果，并等待用户明确要求进入 apply / 开始实现 / 执行修改 / 继续 Phase 3。
-- 接口影响按 L1-L4 分级处理；接口内部判断逻辑如果改变调用方可观察行为，也属于接口影响，不能因签名未变而降级。
 - Phase 3 实现期冲突必须先分类再处理：实现偏差修代码；规格遗漏修 OpenSpec；设计冲突暂停并请用户确认；用户变更更新 proposal/specs/tasks 后再继续。
 - 架构审计、澄清、ADR 或上下文发现如果影响实现，必须先回写 OpenSpec design/specs/tasks，再进入 Phase 3。
 - 不得猜测式修 bug。实现失败或行为不明时，先进入 diagnose 闭环；如果根因是规格不准，先修 OpenSpec，再继续 apply。
@@ -41,87 +42,21 @@ SM Flow 是一套 **OpenSpec-first / Devflow-assisted** 的软件交付元工作
 - 子 skill 必须显式调用或显式降级：进入 Phase 1、1.5、2、2.5、3、4 时，先说明“本阶段调用/加载的 skill 是 X”；如果不能调用，必须说明“降级为 fallback”，并记录降级原因。
 - 子 skill 绑定能力契约，不绑定单一平台路径。显式调用优先级：优先使用平台原生 Skill 调用；如果平台没有 Skill 工具，则读取对应能力的本地 `SKILL.md` 并按其协议执行；只有文件不存在或协议不可执行时，才使用 `references/fallbacks.md`。
 - fallback 产物必须标注为降级执行，不能伪装成真实子 skill 调用。
-
-## 接口影响分级
-
-接口影响分级判断的是“记录在哪里、是否需要独立文档”，不是判断“是否需要关注”。凡涉及字段、DTO、service 方法、API、事件、回调、数据库契约、命令契约、跨模块调用语义或接口内部判断逻辑变化，都必须先判断接口影响。
-
-| 级别 | 判断条件 | 产物要求 |
-| --- | --- | --- |
-| L1 内部实现 | 不改变任何调用方可观察的接口、字段、状态、错误码、数据范围、排序、过滤、权限结果、状态流转、副作用或文档承诺 | 不需要接口影响文档，只在 OpenSpec tasks 或 acceptance 记录验证 |
-| L2 内部接口 | 改 DTO、service 方法、内部事件、内部 RPC 或内部判断逻辑，且所有消费者都在同一实现范围内 | 必须记录接口影响范围，可内联到 OpenSpec design/specs/tasks 或 devflow evidence/decisions |
-| L3 协作接口 | 影响其他模块、其他服务、前端、外部系统、跨团队消费者、数据库契约、消息事件、回调或 SDK | 必须产出独立接口文档或等价独立章节 |
-| L4 破坏性接口 | 删除字段、改字段语义、改状态机、改错误码、破坏兼容、旧调用方可能失败，或需要迁移、灰度、回滚 | 独立接口文档 + 迁移/回滚说明；必要时创建 ADR |
-
-判断策略：
-
-- 如果只是修复 bug，让接口回到原 OpenSpec 或原文档承诺，通常是 L1/L2。
-- 如果判断逻辑改变了返回数据、错误码、状态、权限结果、排序/过滤、幂等性、时序或副作用，至少按 L3 检查。
-- 如果旧调用方不改代码会失败、少数据、多数据、状态不同或错误码不同，按 L4 处理。
-- 如果无法确定调用方边界或兼容性，默认提高一级并作为 `user-interview` 问题等待确认。
+- `micro` 只能压缩产物重量，不能跳过关键 gate；Phase 0.5 最小上下文收集、Phase 2 最小澄清、Phase 2.9 commit gate 和 Phase 4 轻量回填必须保留。
+- devflow 记录必须按阶段就近更新；Phase 4 主要做 consolidation，而不是第一次补写 `brief.md`、`evidence.md`、`decisions.md` 或 `acceptance.md`。
 
 ## 首次加载
 
 执行前只读取当前任务需要的 reference 文件：
 
-- 需要逐阶段执行时，读取 `references/phase-contracts.md`。
+- 需要逐阶段执行时，先读取 `references/phase-contracts.md`；如果当前阶段涉及接口影响分级、分档、启动规则、快速模式或完成标准，再补读 `references/operating-rules.md`。
 - 创建或更新 PRD、ADR、验收报告、词汇表、复合知识文档时，读取 `references/templates.md`。
 - Phase 4 或需要从 OpenSpec 提取产物时，读取 `references/archive-rules.md`。
 - 子 skill 或 OpenSpec skill 无法直接调用时，读取 `references/fallbacks.md`。
 
 ## 启动检查
 
-1. 判断启动模式：
-   - 完整模式：用户提供粗略想法或初始 PRD。
-   - Research 模式：用户已有 research，需要转成或修正 OpenSpec。
-   - PRD 文件模式：用户提供已有 PRD 路径。
-   - 指定阶段模式：用户要求从某个 Phase 恢复。
-   - 快速模式：小改动，Phase 2 和 Phase 4 可以轻量化，但不能省略。
-2. 如果缺少 `devflow/`，初始化：
-   - `devflow/projects/`
-   - `devflow/glossary/CONTEXT.md`
-   - `devflow/compound/`
-   - `devflow/reference/`
-3. 如果根目录存在旧 `CONTEXT.md`，且 `devflow/glossary/CONTEXT.md` 不存在或为空，询问用户是迁移还是合并。
-4. 检查 OpenSpec 和子 skill 是否可用：
-   - OpenSpec 能力：`openspec-propose`、`openspec-apply-change`、`openspec-archive-change`。可由平台原生 skill、`.claude/skills/.../SKILL.md` 或 fallback 协议提供。
-   - 辅助能力：`to-prd`、`grill-with-docs`、`diagnose`、`tdd`、`zoom-out`。可由平台原生 skill、`.agents/skills/.../SKILL.md` 或 fallback 协议提供。
-5. 如果 OpenSpec skill 不可用，不要直接绕过执行；先使用 fallback 生成/修正 OpenSpec 产物，并在 Phase 3 前向用户说明执行入口降级风险。
-
-## 项目标识
-
-整个流程使用同一个 slug：
-
-- 优先使用 OpenSpec change name。
-- 如果还没有 change name，则从功能标题生成 kebab-case slug。
-- 项目档案目录格式：`devflow/projects/YYYY-MM-DD-{slug}/`。
-- 如果目录已存在，默认恢复该项目，不要重复创建；除非用户明确要求新开一轮。
-
-## Devflow 产物分层
-
-devflow 是辅助 OpenSpec 和人类阅读的档案层，不复制 OpenSpec 的执行产物。默认只创建必要文件；扩展文件必须有明确理由。
-
-**必须产物**：
-
-- `brief.md`：背景、目标、范围、非目标、变更规模、关联 OpenSpec change。
-- `evidence.md`：代码证据、文档证据、历史决策、evidence-driven 结论和汇报状态。
-- `decisions.md`：user-interview 问题、用户确认、关键取舍、风险接受、OpenSpec 回写记录。
-- `acceptance.md`：实现结果、验证命令、未验证项、归档状态、后续事项。
-
-**按需产物**：
-
-- `prd.md`：需求复杂、用户明确要求 PRD、或需要对外协作时创建；小需求并入 `brief.md`。
-- `research.md`：存在真实调研、代码考古、竞品/API 对比或复杂方案比较时创建。
-- `design.md`：仅记录 OpenSpec design 不适合承载的人类背景、架构审计摘要或长期决策索引；实现设计仍以 OpenSpec design 为准。
-- `tasks.md`：仅记录跨轮次追踪或人类复盘任务；执行任务仍以 OpenSpec tasks 为准。
-- `alignment.md` / `clarifications.md`：问题很多或冲突复杂时单独创建；否则并入 `decisions.md`。
-- `adr/*.md` 和 `compound/*.md`：仅在满足 ADR/复合知识规则时创建。
-
-**规模分档**：
-
-- `micro`：小且低风险，使用 `brief.md`、`decisions.md`、`acceptance.md`；证据少时并入 `brief.md`。
-- `standard`：默认模式，使用 `brief.md`、`evidence.md`、`decisions.md`、`acceptance.md`。
-- `complex`：高风险、跨模块、需求不清或多人协作时，在 standard 基础上按需增加 PRD/research/design/tasks/alignment。
+按 `references/operating-rules.md` 执行启动检查、项目 slug 规则和 devflow 产物分层。
 
 ## 阶段总览
 
@@ -137,23 +72,13 @@ devflow 是辅助 OpenSpec 和人类阅读的档案层，不复制 OpenSpec 的
 
 每个阶段的进入条件、动作、输出和退出标准见 `references/phase-contracts.md`。
 
+关键阶段的完成判断也以 `references/phase-contracts.md` 为准；如果缺少显式 checkpoint 或能力来源声明，该阶段不得视为已完成。
+
 ## 快速模式
 
-快速模式仅在改动小且低风险时使用。它可以压缩 Phase 1.5 和 Phase 2.5，但必须保留：
-
-- Phase 0.5 最小上下文检查：至少检查 glossary 和相关 ADR。
-- Phase 2 最小澄清：至少一个术语问题、一个边界问题、一个验收问题；evidence-driven 结论也要汇报。
-- Phase 2.9 提交检查：即使快速模式也必须确认没有未解决用户问题、接口影响已记录、OpenSpec tasks/specs 可执行。
-- Phase 3 仍以 OpenSpec tasks/specs 为执行依据。
-- Phase 4 轻量归档：记录验收结果、OpenSpec 产物链接和是否归档。
+快速模式的具体约束见 `references/operating-rules.md`。
 
 ## 完成标准
 
-一次流程只有在满足以下条件时才算完成：
-
-- OpenSpec change 中的 proposal/design/specs/tasks 已生成或更新到可执行状态。
-- 实现或规划任务已经完成，且执行依据来自 OpenSpec。
-- 已运行验证，或明确记录未运行验证的原因。
-- `devflow/projects/YYYY-MM-DD-{slug}/` 中存在符合规模分档的必要 devflow 产物，并能说明背景、证据、决策、验收和归档状态。
-- 用户知道剩余风险和下一步动作，并已被询问是否要归档 OpenSpec change。
+流程完成标准见 `references/operating-rules.md`。
 

.agents/skills/sm-flow/references/fallbacks.md

@@ -2,6 +2,21 @@
 
 当子 skill 无法直接调用时使用这些协议。Fallback 不是绕过 OpenSpec 的许可；v3 中 fallback 的目标仍然是生成、修正或执行 OpenSpec 产物。使用任何 fallback 前必须先向用户说明：目标子 skill、无法调用原因、降级协议名称、降级风险。产物中也必须记录“本阶段为 fallback 降级执行”。
 
+## Fallback 记录要求
+
+任何 fallback 都必须同时满足以下记录要求：
+
+1. 在对用户的阶段汇报里声明：
+   - 目标 capability
+   - 不可用原因
+   - 使用的 fallback 协议名
+   - 本次降级风险
+2. 在 `decisions.md`、`evidence.md` 或 `acceptance.md` 中留下同样的降级记录。
+3. 如果当前阶段需要 checkpoint，则 fallback 声明是 checkpoint 完成条件的一部分。
+4. 如果没有完成这些声明和记录，该阶段不得视为已完成。
+
+除非某个 fallback 额外说明，否则下面各节默认继承这组通用记录要求，不再重复要求“记录本阶段 fallback 声明”。
+
 ## OpenSpec 提案 fallback
 
 1. 创建或识别 `openspec/changes/{slug}/`。
@@ -27,6 +42,7 @@
 3. 向用户汇报冲突和推荐修正。
 4. 用户确认后，优先修正 OpenSpec proposal/design/specs/tasks。
 5. 再同步更新 devflow 文档；不要只改 devflow。
+6. 额外记录冲突修正状态。
 
 ## OpenSpec 执行 fallback
 
@@ -48,6 +64,7 @@
 10. 只有验证通过或明确记录原因后，才更新 task 状态。
 11. 如果失败原因不确定，停止并进入 diagnose。
 12. 如果 diagnose 证明规格不准，先修正 OpenSpec，再继续执行。
+13. 额外记录任务推进状态和验证状态。
 
 ## PRD fallback
 
@@ -58,6 +75,7 @@
 - 从当前上下文、devflow 记忆和 OpenSpec 产物综合，不要机械复制。
 - `brief.md` 或 PRD 用来表达用户价值、范围和验收口径；不能替代 OpenSpec specs/tasks。
 - 只有当缺失决策会阻塞 OpenSpec 正确性时，才采访用户。
+- 额外记录是否创建了独立 `prd.md`。
 
 ## 文档化追问 fallback
 
@@ -68,6 +86,7 @@
 5. 术语确认后立即更新词汇表。
 6. 影响实现的澄清必须回写 OpenSpec。
 7. 只为难以逆转的真实权衡创建 ADR。
+8. 额外记录 question pool 和已消费问题。
 
 快速模式的最小问题：
 
@@ -85,6 +104,7 @@
 4. 检查是否与词汇表、ADR 和 OpenSpec design 冲突。
 5. 用不超过五句话总结最大风险。
 6. 如果影响实现，回写 OpenSpec design/tasks。
+7. 额外记录审计结论回写状态。
 
 ## Diagnose fallback
 
@@ -96,6 +116,7 @@
 6. 如果是实现问题，修复被证明的最小原因。
 7. 如果是规格问题，先修正 OpenSpec，再继续 apply。
 8. 运行回归验证。
+9. 额外记录根因分类和回归结果。
 
 ## TDD fallback
 
@@ -106,4 +127,5 @@
 3. 实现刚好让测试通过的最小代码。
 4. 只在测试通过时重构。
 5. 对下一个 OpenSpec 行为重复以上步骤。
+6. 额外记录当前行为切片的测试状态。
 

.agents/skills/sm-flow/references/operating-rules.md

@@ -0,0 +1,94 @@
+# 运行规则
+
+本文件承载稳定但不必放在顶层 `SKILL.md` 的运行规则。
+
+## 接口影响分级
+
+接口影响分级决定“记录在哪里”以及“是否需要独立接口文档”。凡涉及字段、DTO、service 方法、API、事件、回调、数据库契约、命令契约、跨模块调用语义，或内部决策逻辑改变可观察行为的变更，都必须先做分级。
+
+| 级别 | 判断条件 | 产物要求 |
+| --- | --- | --- |
+| L1 内部实现 | 不改变调用方可观察行为 | 在 OpenSpec tasks 或 acceptance 记录验证 |
+| L2 内部接口 | 内部 DTO/service/event/RPC/decision-logic 变化，且所有消费者仍在同一实现边界内 | 在 OpenSpec design/specs/tasks 或 devflow evidence/decisions 中内联记录影响 |
+| L3 协作接口 | 影响其他模块/服务、前端、外部系统、跨团队消费者、数据库契约、事件、回调或 SDK | 产出独立接口文档或等价独立章节 |
+| L4 破坏性接口 | 破坏兼容、改变语义/错误码/状态机、可能让旧调用方失败，或需要迁移/灰度/回滚 | 独立接口文档 + 迁移/回滚说明；必要时创建 ADR |
+
+判断启发：
+
+- 如果变更只是把接口恢复到原 OpenSpec 或既有文档承诺，通常是 L1 或 L2。
+- 如果决策逻辑改变了返回数据、错误码、状态、权限结果、排序/过滤、幂等性、时序或副作用，至少按 L3 检查。
+- 如果旧调用方不改代码就可能失败，或会观察到缺失/额外数据、不同状态或不同错误码，按 L4 处理。
+- 如果消费者边界或兼容性不明确，默认提高一级，并转成 `user-interview` 问题。
+
+## 启动检查
+
+1. 判断启动模式：
+   - 完整模式：用户提供粗略想法或初始 PRD。
+   - Research 模式：用户已有 research，需要生成或修正 OpenSpec。
+   - PRD 文件模式：用户提供已有 PRD 路径。
+   - 指定阶段模式：用户希望从某个 Phase 恢复。
+   - 快速模式：小改动；Phase 2 和 Phase 4 可以轻量化，但不能跳过。
+2. 如果缺少 `devflow/`，初始化：
+   - `devflow/projects/`
+   - `devflow/glossary/CONTEXT.md`
+   - `devflow/compound/`
+   - `devflow/reference/`
+3. 如果根目录旧 `CONTEXT.md` 存在，而 `devflow/glossary/CONTEXT.md` 缺失或为空，询问是迁移还是合并。
+4. 检查 OpenSpec 和辅助能力是否可用：
+   - OpenSpec 能力：`openspec-propose`、`openspec-apply-change`、`openspec-archive-change`
+   - 辅助能力：`to-prd`、`grill-with-docs`、`diagnose`、`tdd`、`zoom-out`
+5. 如果 OpenSpec 能力不可用，不要静默绕过；要走 fallback 协议，并在 Phase 3 前披露降级风险。
+
+## 项目标识规则
+
+- 整个流程使用同一个 slug。
+- 优先使用 OpenSpec change name。
+- 如果还没有，则从功能标题生成 kebab-case slug。
+- 项目档案目录格式：`devflow/projects/YYYY-MM-DD-{slug}/`
+- 如果目录已存在，默认恢复该项目；除非用户明确要求新开一轮。
+
+## Devflow 产物分层
+
+Devflow 是辅助 OpenSpec 的人类可读档案层，不应复制 OpenSpec 的执行产物。
+
+必需产物：
+
+- `brief.md`：背景、目标、范围、非目标、分档、关联 OpenSpec change
+- `evidence.md`：代码/文档证据、历史决策、evidence-driven 结论、汇报状态
+- `decisions.md`：user-interview 条目、确认结果、取舍、风险接受、OpenSpec 回写记录
+- `acceptance.md`：结果、验证、未验证项、归档状态、后续事项
+
+按需产物：
+
+- `prd.md`：复杂需求、用户明确要求，或需要对外协作
+- `research.md`：真实调研、代码考古、竞品/API 对比或复杂方案比较
+- `design.md`：不适合放进 OpenSpec design 的长期背景或架构审计摘要
+- `tasks.md`：跨会话的人类追踪；执行任务仍属于 OpenSpec
+- `alignment.md` / `clarifications.md`：仅在 gap 或澄清很多时使用
+- `adr/*.md` 和 `compound/*.md`：仅在满足 ADR / compound knowledge 规则时使用
+
+分档：
+
+- `micro`：使用 `brief.md`、`decisions.md`、`acceptance.md`；证据很少时并入 `brief.md`
+- `standard`：使用 `brief.md`、`evidence.md`、`decisions.md`、`acceptance.md`
+- `complex`：`standard` 基础上按需增加 PRD/research/design/tasks/alignment
+
+## 快速模式
+
+快速模式只适用于小而低风险的变更。它可以压缩 Phase 1.5 和 Phase 2.5，但必须保留：
+
+- 最小 Phase 0.5 上下文收集：至少检查 glossary 和相关 ADR
+- 最小 Phase 2 澄清：至少一个术语问题、一个边界问题、一个验收问题；evidence-driven 结论仍需汇报
+- Phase 2.9 commit gate：确认没有未解决用户问题、接口影响已记录、OpenSpec tasks/specs 可执行
+- Phase 3 仍由 OpenSpec tasks/specs 驱动执行
+- 轻量 Phase 4 回填：记录验收结果、OpenSpec 链接和归档状态
+
+## 完成标准
+
+只有同时满足以下条件，流程才算完成：
+
+- OpenSpec proposal/design/specs/tasks 已生成或更新到可执行状态
+- 实现或规划工作已完成，且执行依据来自 OpenSpec
+- 已运行验证，或已记录未运行验证的原因
+- `devflow/projects/YYYY-MM-DD-{slug}/` 包含所选分档要求的必要产物
+- 用户知道剩余风险与下一步，并已被询问是否归档 OpenSpec change

.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 和状态。