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

devflow/index.md

@@ -9,3 +9,4 @@
 | 2026-05-19 | add-year-filter | knowledge-index | year-filter, index-panel, frontmatter | `openspec/changes/add-year-filter/` | active |
 | 2026-05-19 | dev-flow-skill-evaluation | sm-flow | dev-flow, sm-flow, skill-evaluation, fallback, phase-contracts | 未关联 | accepted-unarchived |
 | 2026-05-21 | sm-flow-v3-1-upgrade | sm-flow | interface-impact, commit-gate, devflow-index, apply-conflict, skill-compatibility | `openspec/changes/archive/2026-05-21-sm-flow-v3-1-upgrade/` | archived |
+| 2026-05-22 | sm-flow-execution-hardening | sm-flow | execution-hardening, checklist, phase-gate, cross-artifact, question-pool | 未关联 | active |

devflow/projects/2026-05-22-sm-flow-execution-hardening/acceptance.md

@@ -0,0 +1,40 @@
+# SM Flow Execution Hardening Acceptance
+
+## Result
+
+Implemented `sm-flow-execution-hardening` as protocol/document changes only.
+
+Updated artifacts:
+
+- `.agents/skills/sm-flow/SKILL.md`
+- `.agents/skills/sm-flow/references/phase-contracts.md`
+- `.agents/skills/sm-flow/references/fallbacks.md`
+- `skill-workbench/docs/sm-flow/workflow.md`
+- `openspec/changes/sm-flow-execution-hardening/tasks.md`
+
+## Verification
+
+- Static verification:
+  - Confirmed explicit phase checkpoint and stage-completion rules exist in `SKILL.md`.
+  - Confirmed Phase 2 question-pool behavior and Phase 1.5 / 2.9 cross-artifact checks exist in `phase-contracts.md`.
+  - Confirmed fallback declaration and recording requirements exist in `fallbacks.md`.
+  - Confirmed `workflow.md` explains the same execution-hardening model without introducing mandatory output templates.
+- OpenSpec verification:
+  - Implementation/documentation tasks `1.1` to `3.2` are complete.
+  - Validation tasks `4.1` to `4.4` are complete.
+
+## Acceptance Scope Check
+
+- Satisfied by protocol/document changes alone: yes
+- Requires standardized phase-report output format: no
+- Requires fixed checkpoint/alignment templates: no
+
+## Unverified
+
+- OpenSpec CLI validation passed: `openspec validate sm-flow-execution-hardening`.
+- No automated tests were needed because this change only modifies protocol and documentation artifacts.
+
+## Archive Status
+
+- OpenSpec change is not archived.
+- User still needs to be asked whether to archive after validation is complete.

devflow/projects/2026-05-22-sm-flow-execution-hardening/brief.md

@@ -0,0 +1,31 @@
+# SM Flow Execution Hardening Brief
+
+## 背景
+
+- 用户目标：把 `sm-flow` 在真实项目执行中暴露出的流程失真问题，提炼为下一轮协议硬化需求。
+- 当前问题：`sm-flow` 已经具备完整阶段规则，但实际执行时仍会出现跳过检查点、弱化显式声明、问题池不足、Cross-artifact 一致性检查不充分等情况。
+- 关联 OpenSpec：`openspec/changes/sm-flow-execution-hardening/`
+- devflow 分档：complex
+
+## 范围
+
+- 本次要做：把复盘中的执行问题整理为结构化需求，明确目标、非目标、用户故事、验收口径和建议改进方向。
+- 本次不做：立即修改 `sm-flow` 协议、直接创建 OpenSpec change、重写 `sm-flow` 主设计。
+- 影响区域：
+  - `.agents/skills/sm-flow/SKILL.md`
+  - `.agents/skills/sm-flow/references/phase-contracts.md`
+  - `.agents/skills/sm-flow/references/fallbacks.md`
+  - `.agents/skills/sm-flow/references/templates.md`
+  - `skill-workbench/docs/sm-flow/workflow.md`
+  - `skill-workbench/docs/sm-flow/retrospective.md`
+
+## OpenSpec 对齐
+
+- proposal 覆盖状态：已覆盖
+- specs 覆盖状态：已覆盖
+- tasks 覆盖状态：已覆盖
+
+## 入口摘要
+
+- 这次需求关注的不是 `sm-flow` 的理念是否成立，而是它在真实执行中为什么仍然会“按代码习惯行动”，而不是“按 phase gate 行动”。
+- 目标是把这些问题固化为更强的执行约束，让后续代理在 `micro` 或 `standard` 模式下也不再轻易跳过关键阶段。

devflow/projects/2026-05-22-sm-flow-execution-hardening/decisions.md

@@ -0,0 +1,76 @@
+# SM Flow Execution Hardening Decisions
+
+## User-interview
+
+| 问题 | 用户回答 | 决策 | OpenSpec 回写 |
+| --- | --- | --- | --- |
+| 这次是否将复盘问题提炼为正式需求？ | “[$sm-flow] 提炼成需求” | 创建 `sm-flow-execution-hardening` 需求档案，先收敛需求，再决定是否进入 OpenSpec。 | 不影响 |
+| 是否必须产出固定 checkpoint / alignment 模板？ | “确认 1” | 不强制固定模板；协议只要求必填字段和检查动作。 | 已回写 |
+| 验收是否要求统一阶段汇报格式？ | “确认1” | 验收停在协议明确 gate、问题池和对齐规则，不要求统一阶段汇报格式。 | 已回写 |
+
+## Phase 2 Tracking
+
+| 问题池项 | 模式 | 状态 | 备注 |
+| --- | --- | --- | --- |
+| Q1：是否必须产出固定 checkpoint / alignment 模板 | user-interview | 待确认 | 会影响 templates.md 与 tasks 范围 |
+| Q2：协议主术语采用 checkpoint 还是 checklist | evidence-driven | 待整理 | 优先由现有文档术语一致性决定 |
+| Q3：验收是否要求统一阶段汇报格式 | user-interview | 已确认 | 验收停在规则层，不扩到统一输出格式 |
+| Q4：workflow 是否需要保留复盘案例示例 | evidence-driven | 待整理 | 主要影响 workflow 文档粒度 |
+
+## Phase 2.5 审计结论
+
+- 决策：主术语采用 `checkpoint`，`checklist` 作为内部核对动作描述。
+  - 原因：仓库现有 `phase-contracts.md` 已使用 `Human checkpoint`，继续沿用能减少术语漂移。
+  - 影响：后续协议修改应优先写“phase checkpoint”，避免在规则层混用主术语。
+  - 风险接受：当前接受
+
+- 决策：`workflow.md` 不扩成案例手册，继续保留规则抽象和演进说明；具体复盘案例留在 `retrospective.md`。
+  - 原因：如果把案例并入 workflow，规则与示例会双份维护，后续更容易漂移。
+  - 影响：执行真理源继续留在 `SKILL.md` / `phase-contracts.md` / OpenSpec，而不是 workflow 长文。
+  - 风险接受：当前接受
+
+## Phase 2.9 Commit Result
+
+- 决策：`sm-flow-execution-hardening` 当前 Draft OpenSpec 通过 commit gate，视为 Committed OpenSpec。
+  - 原因：proposal、design、specs、tasks 已完整；user-interview 已确认；evidence-driven 结论已汇报；未发现 devflow/OpenSpec 冲突。
+  - 影响：可以进入 Phase 3 修改协议文件，但仍需单独的 apply 授权。
+  - 风险接受：当前接受
+
+## 关键取舍
+
+- 决策：将本轮定位为 `complex` 分档。
+  - 原因：虽然不涉及业务代码，但它影响 `sm-flow` 的多个核心文件、阶段协议和验收方式，且包含多处跨文档一致性约束。
+  - 影响：使用 `brief.md`、`prd.md`、`evidence.md`、`decisions.md` 四类产物，而不是只写简短 brief。
+  - 风险接受：当前接受
+
+- 决策：不复用 `sm-flow-v3-1-upgrade` 项目，而是新开需求档案。
+  - 原因：`v3.1` 已归档且目标不同；本轮关注的是执行稳定性，不宜混入已完成升级项目。
+  - 影响：后续若进入 OpenSpec，可独立创建新 change。
+  - 风险接受：当前接受
+
+- 决策：将“规则存在但执行不稳”定义为首要问题。
+  - 原因：复盘中的多个现象都能收敛到这一点，能避免后续需求继续发散。
+  - 影响：后续需求改造应优先考虑 checklist、阶段 gate、显式声明和一致性检查。
+  - 风险接受：当前接受
+
+## Phase 3 Implementation Record
+
+- 决策：Phase 3 以本地 `openspec-apply-change` `SKILL.md` 作为 capability 来源继续执行。
+  - 原因：当前环境可读取对应 skill 协议，且用户已通过“apply”明确授权进入 Phase 3。
+  - 影响：本轮实现按 committed OpenSpec 的 task 切片直接修改协议与工作流文档。
+  - 风险接受：当前接受
+
+- 决策：本轮不修改 `templates.md`。
+  - 原因：用户已确认不要求固定 checkpoint / alignment 模板，也不要求统一阶段汇报格式；OpenSpec task 2.4 的目标是保持模板可选。
+  - 影响：实现集中在 `SKILL.md`、`phase-contracts.md`、`fallbacks.md`、`workflow.md`，避免把协议硬化扩大成模板标准化。
+  - 风险接受：当前接受
+
+- 决策：把“checkpoint 缺失则阶段不算完成”写入顶层协议和阶段契约，而不是只放在说明文档。
+  - 原因：这是决定阶段能否前进的硬 gate，必须落在执行真理源。
+  - 影响：Phase 0、0.5、1、2、2.5、2.9 现在都需要显式 checkpoint 和 capability 声明。
+  - 风险接受：当前接受
+
+- 决策：将 Phase 2 question pool、Phase 1.5/2.9 cross-artifact 对齐、`micro` gate 保留和 fallback 记录要求同步落在协议正文与 workflow 说明。
+  - 原因：这些规则既要可执行，又要便于人类理解；单独放在一处容易再次漂移。
+  - 影响：OpenSpec、协议正文和 workflow 解释层的关键术语已收敛到同一套执行规则。
+  - 风险接受：当前接受

devflow/projects/2026-05-22-sm-flow-execution-hardening/evidence.md

@@ -0,0 +1,106 @@
+# SM Flow Execution Hardening Evidence
+
+## 证据
+
+| 来源 | 证据 | 结论 | 是否已汇报 |
+| --- | --- | --- | --- |
+| `skill-workbench/docs/sm-flow/retrospective.md` | 逐 Phase 复盘了一次真实执行，明确记录了 Phase 0、0.5、1.5、2、2.5、2.9、4 的实际偏差。 | 当前主要问题是执行偏差和自检不足，不是流程理念方向错误。 | 是 |
+| `skill-workbench/docs/sm-flow/workflow.md` | v3.1 已经补入 Draft/Committed OpenSpec、接口影响分级、Phase 2.9、Phase 3 冲突分类等规则。 | 新一轮需求不应继续扩展原则，而应硬化执行协议。 | 是 |
+| `.agents/skills/sm-flow/SKILL.md` | 已明确 Phase 0.5、2、2.9 不可跳过，且要求显式 skill/fallback 声明。 | 当前缺口在于代理执行时没有被强制逐项核对这些规则。 | 是 |
+| `.agents/skills/sm-flow/references/phase-contracts.md` | 每个 Phase 已有进入条件、动作、退出条件和 checkpoint。 | 还缺一个更短、更高频的执行时 checklist 机制。 | 是 |
+| `.agents/skills/grill-with-docs/SKILL.md` | 明确要求 one-at-a-time 提问，并在可探索时优先查代码。 | Phase 2 的问题不是缺规则，而是没有把“问题池 + 单题推进”落成稳定动作。 | 是 |
+| `devflow/projects/2026-05-19-dev-flow-skill-evaluation/dev-flow-skill-evaluation.md` | 历史评估已指出 `SKILL.md` 更像设计说明书，缺少执行时检查点。 | 本轮需求与历史评估一致，属于同一产品化方向的继续深化。 | 是 |
+| `openspec/changes/sm-flow-execution-hardening/proposal.md` | Draft proposal 已将变更范围收敛到 phase checkpoint、问题池、cross-artifact alignment、micro gate preservation。 | Phase 1.5 已完成大方向对齐，未决问题主要落在“是否要求固定记录格式”这一类实现边界。 | 是 |
+| `openspec/changes/sm-flow-execution-hardening/design.md` | Draft design 已明确 checkpoint、问题池、cross-artifact 检查链路和 devflow 过程内同步更新。 | Phase 2 需要确认的重点不再是方向，而是边界和验收粒度。 | 是 |
+
+## Evidence-driven 结论
+
+- 结论：`sm-flow` 当前最需要的是“执行硬化”，不是“设计重构”。
+  - 证据：v3.1 已经把主从关系、gate 和冲突分类写清楚，但真实执行仍偏离。
+  - 风险：如果继续增加理念说明，可能让文档更长，但不提升执行稳定性。
+  - 用户确认：不需要
+
+- 结论：Phase 1.5 和 2.9 的 cross-artifact 检查应成为优先增强点。
+  - 证据：复盘里 `proposal` 漏字段未被代理提前发现，直到用户 review 才暴露。
+  - 风险：如果这两层不稳，Phase 2 即使问得更全，问题仍会漏到 apply 前后。
+  - 用户确认：不需要
+
+- 结论：`micro` 模式的误用是本次偏差的重要诱因。
+  - 证据：复盘根因明确指出“高估了小改动判断，误以为 micro 可以跳检查”。
+  - 风险：若不把这点写得更硬，后续类似问题会重复出现。
+  - 用户确认：不需要
+
+## Phase 1.5 对齐检查
+
+- `brief/prd` -> `proposal`：已对齐
+  - 覆盖了执行硬化而非主设计重构、影响文件范围、非目标边界。
+- `proposal` -> `design`：已对齐
+  - 设计已展开 checkpoint、问题池、cross-artifact alignment、micro gate preservation 和 devflow 过程内更新。
+- `design` -> `specs`：已对齐
+  - 已拆出 `sm-flow-phase-checkpoints`、`sm-flow-question-pool`、`sm-flow-cross-artifact-alignment`、`sm-flow-micro-gate-preservation` 四个 capability spec。
+- `specs` -> `tasks`：部分对齐，仍有一个边界待确认
+  - 当前 tasks 写了“如有需要则更新模板”，但是否必须定义固定记录格式，尚未明确。
+- `specs` -> `tasks`：现已对齐
+  - 用户已确认这轮不强制固定模板，也不把统一阶段汇报格式纳入验收，因此 tasks 保持“协议强化优先，模板仅按需微调”。
+
+## Phase 2 Question Pool
+
+- Q1 `user-interview` / 范围：
+  - 这次 change 是否必须产出固定的 checkpoint / alignment 记录模板，还是只要求协议定义必填字段即可。
+  - 状态：已确认为后者。
+- Q2 `evidence-driven` / 术语：
+  - `phase checkpoint`、`phase checklist`、`stage-completion rule` 三个说法里，哪个作为协议中的主术语最稳。
+- Q3 `user-interview` / 验收：
+  - 验收是以“文档明确要求这些门禁”为准，还是要进一步要求代理输出统一格式的阶段汇报。
+  - 状态：已确认采用前者。
+- Q4 `evidence-driven` / 边界：
+  - 这次是否需要把 retrospective 中的具体案例映射到 workflow 文档中的示例，还是只保留规则层抽象。
+
+## Phase 2.5 架构审计
+
+- 输入 -> 处理 -> 输出链路
+  - `retrospective.md` / 现有 `sm-flow` 协议 / 已归档 OpenSpec change
+  - -> `SKILL.md` 核心规则、`phase-contracts.md` 阶段契约、`fallbacks.md` 降级协议、按需 `templates.md`
+  - -> `workflow.md` 设计说明、`devflow` 过程记录、最终可提交的 OpenSpec
+
+- 模块职责
+  - `.agents/skills/sm-flow/SKILL.md`：放短而硬的总规则、gate 和主从关系。
+  - `.agents/skills/sm-flow/references/phase-contracts.md`：放逐阶段的进入/动作/退出条件与 checkpoint。
+  - `.agents/skills/sm-flow/references/fallbacks.md`：放 capability 不可用时的降级协议和记录要求。
+  - `.agents/skills/sm-flow/references/templates.md`：只放稳定模板，不承载这轮的主逻辑。
+  - `skill-workbench/docs/sm-flow/workflow.md`：保留设计说明和演进脉络，不承载执行真理源。
+
+- 架构风险评估
+  - 当前最大风险不是规则缺失，而是把同一条规则分散到 `SKILL.md`、`phase-contracts.md`、`workflow.md` 后出现漂移。
+  - 这轮 change 如果把“checkpoint”同时做成规则、模板和示例，容易再次扩大维护面。
+  - 更稳的做法是让 `SKILL.md` 和 `phase-contracts.md` 成为主落点，`workflow.md` 只解释，不重复列执行细则。
+  - `templates.md` 应保持可选和轻量，否则会把“协议硬化”扩成“输出格式标准化”。
+- 审计结论与当前 Draft OpenSpec 一致，不需要新增 capability，只需要在实现时严格控制规则落点。
+
+## Phase 2.9 Commit Gate
+
+- proposal：通过
+  - 已覆盖变更原因、范围、非目标、关键边界，以及“不强制固定模板 / 不要求统一阶段汇报格式”的范围约束。
+- design：通过
+  - 已覆盖 checkpoint、问题池、cross-artifact alignment、micro gate preservation、devflow 过程内更新和规则落点分层。
+- specs：通过
+  - 已覆盖四个新增 capability，且行为描述集中在可观察的协议要求。
+- tasks：通过
+  - 已覆盖协议修改、workflow 更新、校验和验收边界验证。
+- user-interview：通过
+  - 两个需要用户确认的问题均已确认并回写。
+- evidence-driven：通过
+  - 术语与 workflow 粒度问题已通过现有文档证据收束。
+- devflow / OpenSpec 冲突：未发现
+
+结论：当前 Draft OpenSpec 已达到可执行状态，可视为 Committed OpenSpec，进入 Phase 3 前仅缺明确 apply 授权。
+
+## Phase 3 Apply Evidence
+
+| 来源 | 证据 | 结论 | 是否已汇报 |
+| --- | --- | --- | --- |
+| `.agents/skills/sm-flow/SKILL.md` | 已新增显式 checkpoint 完成规则、question pool 规则、cross-artifact 对齐规则、`micro` gate 保留规则和 devflow 分阶段更新规则。 | 顶层协议已把执行硬化从“建议”提升为阶段完成条件。 | 是 |
+| `.agents/skills/sm-flow/references/phase-contracts.md` | 已新增 Phase 1.5 对齐链检查、Phase 2 问题池建立、Phase 2.9 闭环复核、Phase 3 capability 启动汇报和 Phase 4 consolidation 约束。 | 逐阶段执行契约已经覆盖 committed OpenSpec 的核心要求。 | 是 |
+| `.agents/skills/sm-flow/references/fallbacks.md` | 已新增统一 fallback 记录要求，并在各 fallback 协议中补入记录动作。 | 降级执行现在是可见、可审计的协议事件。 | 是 |
+| `skill-workbench/docs/sm-flow/workflow.md` | 已新增 question pool、Phase Checkpoint、Cross-Artifact Alignment、Micro 不是 Skip、fallback 记录要求等说明。 | retrospective 中的经验已被提升为稳定规则，而不是仅停留在叙述层。 | 是 |
+| `openspec/changes/sm-flow-execution-hardening/tasks.md` | 已完成 1.1-3.2，文档实现范围已落地。 | Phase 3 的协议/文档实现部分已完成，剩余工作转入验证与验收。 | 是 |

devflow/projects/2026-05-22-sm-flow-execution-hardening/prd.md

@@ -0,0 +1,67 @@
+# SM Flow Execution Hardening PRD
+
+## 问题陈述
+
+`sm-flow` 已经定义了较完整的阶段、规则和 reference 文件，但在真实项目执行中，代理仍然会把它当成“有帮助的流程建议”，而不是“必须逐阶段满足的执行协议”。结果是：
+
+- Phase 0 没有形成入口摘要和已知影响区域。
+- Phase 0.5 没有及时初始化和维护 `devflow/` 项目档案。
+- Phase 1 没有显式声明 skill 或 fallback，Draft / Committed OpenSpec 的边界不稳定。
+- Phase 1.5 被跳过，导致 proposal / design / research / specs / tasks 之间的一致性缺口直到用户 review 才暴露。
+- Phase 2 虽然收集了证据，但没有以结构化问题池和 one-at-a-time 的方式稳定执行。
+- Phase 2.5 被跳过，架构链路和接口影响没有提前暴露。
+- Phase 2.9 缺少强制自检，无法可靠发现 cross-artifact 遗漏。
+
+这说明当前痛点不是缺少理念，而是缺少“执行时自检”和“阶段切换门禁”的产品化机制。
+
+## 解决方案
+
+为 `sm-flow` 增加一轮“执行硬化”需求，目标是让代理在实际使用中更难偏离阶段协议。重点不是新增更多解释，而是把现有规则压缩成更可执行、更可检查、更可暴露偏差的约束，例如：
+
+- 每个阶段结束必须有简短 checklist / checkpoint。
+- 未显式声明 skill 或 fallback 视为该阶段未完成。
+- Phase 2 先生成问题池，再按 one-at-a-time 消费。
+- Phase 1.5 / 2.9 引入更明确的 cross-artifact diff 检查。
+- `micro` 明确只能压缩产物，不得跳过关键 gate。
+- devflow 产物默认在过程内同步更新，而不是拖到 Phase 4 补写。
+
+## 用户故事
+
+1. 作为使用 `sm-flow` 的开发者，我希望代理在进入下一阶段前自动暴露“已满足/未满足”的条件，这样我能尽早发现流程偏差。
+2. 作为使用 `sm-flow` 的开发者，我希望 `micro` 模式仍然保留关键 gate，这样小改动不会因为“看起来简单”而漏掉重要检查。
+3. 作为使用 `sm-flow` 的开发者，我希望 Phase 2 先形成问题池，再逐个提问，这样既符合 human-in-the-loop 约束，也能避免只问了少数问题就错误收尾。
+4. 作为使用 `sm-flow` 的开发者，我希望 Phase 1.5 和 2.9 能可靠检查 proposal / design / specs / tasks / evidence / decisions 的一致性，这样问题能在 apply 前暴露，而不是等我 review。
+
+## 实现决策
+
+- 决策：本轮先把“执行硬化”提炼成需求，而不是直接进入文档改造。
+  - 原因：当前已掌握足够多的真实使用反馈，需要先明确问题边界和验收标准，再决定是否开新 OpenSpec change。
+  - 影响：下一步可以更顺畅地进入 `sm-flow` 的正式改造，而不是边讨论边补规则。
+
+- 决策：把重点放在 phase gate、自检、问题池和一致性检查，而不是继续扩展 `sm-flow` 的理念层说明。
+  - 原因：复盘显示失真主要来自执行习惯和缺少检查，而不是原则方向错误。
+  - 影响：后续改动应优先落在 `SKILL.md`、`phase-contracts.md` 和模板/检查清单，而不是重写 workflow 长文。
+
+## 测试决策
+
+- 好测试应该通过审查 `sm-flow` 协议文本和执行产物，验证代理是否被强制带到正确的阶段检查点。
+- 必须覆盖：
+  - `micro` 模式下 gate 不可跳过
+  - Phase 2 问题池与 one-at-a-time 提问
+  - skill/fallback 显式声明要求
+  - Phase 1.5 / 2.9 cross-artifact 检查
+  - devflow 过程内同步更新
+- 不测试：
+  - 业务代码实现结果
+  - OpenSpec CLI 本身的功能正确性
+
+## 非目标
+
+- 不在本轮定义新的业务流程。
+- 不在本轮替换 OpenSpec-first / Devflow-assisted 主设计。
+- 不要求为所有小改动增加更重的文档负担。
+
+## 补充说明
+
+- 这轮需求直接来源于一次真实项目执行复盘，因此它比理念讨论更贴近代理实际失真模式。
+- 如果后续进入 OpenSpec，建议 change 名可沿用 `sm-flow-execution-hardening`。

openspec/changes/sm-flow-execution-hardening/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-05-22

openspec/changes/sm-flow-execution-hardening/design.md

@@ -0,0 +1,115 @@
+## Context
+
+这次 change 处理的是 `sm-flow` 的执行稳定性，而不是流程理念重构。已有文档已经定义了阶段顺序、Phase 2.9、接口影响、实现期冲突分类和 devflow 索引，但真实使用表明，规则如果没有变成“阶段切换前必须显式满足的条件”，就会在执行中被代理惯性绕开。
+
+受影响的主要文件位于：
+
+- `.agents/skills/sm-flow/SKILL.md`
+- `.agents/skills/sm-flow/references/phase-contracts.md`
+- `.agents/skills/sm-flow/references/fallbacks.md`
+- `.agents/skills/sm-flow/references/templates.md`
+- `skill-workbench/docs/sm-flow/workflow.md`
+
+这次改造的规则落点也需要明确分层：
+
+- `SKILL.md` 承载短而硬的总规则和 gate。
+- `phase-contracts.md` 承载逐阶段进入、动作、退出和 checkpoint。
+- `fallbacks.md` 承载 capability 不可用时的降级协议与记录要求。
+- `templates.md` 只在确有必要时提供轻量字段提示，不承载主逻辑。
+- `workflow.md` 只解释设计与演进背景，不重复执行细则或承担执行真理源职责。
+
+## Design
+
+### 1. Phase checkpoints as executable gates
+
+为每个关键阶段引入最小 checkpoint，要求代理在阶段结束时显式汇报：
+
+1. 当前阶段名称。
+2. 本阶段调用的 skill / 本地 `SKILL.md` / fallback。
+3. 本阶段产物。
+4. 已满足的退出条件。
+5. 未满足但仍阻塞下一阶段的问题。
+
+这个 checkpoint 不是替代现有 `phase-contracts.md`，而是把长契约压缩成执行中更容易遵守的门禁动作。
+本次设计只要求这些 checkpoint 具备明确字段和动作，不要求新增统一模板或统一展示格式。
+
+### 2. Skill/fallback declaration becomes a completion condition
+
+现有规则要求进入某些阶段时说明 skill 或 fallback，但执行中容易被忽略。硬化后：
+
+- 若本阶段未显式声明使用的能力来源，则阶段不得视为完成。
+- 若发生 fallback，必须同时记录：目标 skill、不可用原因、采用的 fallback 协议、降级风险。
+
+### 3. Phase 2 uses a question pool
+
+现有规则强调 one-at-a-time，但没有约束问题覆盖面。硬化后，Phase 2 先生成问题池，再逐个消费：
+
+- 问题池至少覆盖术语、边界、验收。
+- 对复杂任务，可继续覆盖权限、上下游触发、前端返回结构、兼容性、生命周期等。
+- `user-interview` 问题仍然一次只问一个，但问题池必须先暴露计划覆盖面。
+
+这样既保留 human-in-the-loop 约束，也降低“只问了几个问题就误以为够了”的风险。
+
+### 4. Cross-artifact alignment becomes explicit
+
+Phase 1.5 和 2.9 需要明确检查的对齐关系：
+
+- `brief/prd` -> `proposal`
+- `proposal` -> `design`
+- `design` -> `specs`
+- `specs` -> `tasks`
+- `evidence/decisions` -> OpenSpec 回写状态
+
+如果任何链路出现信息缺失、术语不一致、能力未落到 spec、spec 未落到 task，都必须在进入下一阶段前暴露。
+
+### 5. Micro mode preserves gates
+
+`micro` 继续允许合并产物，但明确禁止跳过：
+
+- Phase 0.5 最小上下文检查
+- Phase 2 最小澄清
+- Phase 2.9 commit gate
+- Phase 4 轻量归档
+
+这次 change 不增加 `micro` 的文档负担，而是把“不能跳哪些 gate”写得更硬。
+
+### 6. Devflow updates happen during the flow
+
+`devflow` 不再被视为“最后补文档”。设计上要求：
+
+- Phase 0 写入口摘要到 `brief.md`
+- Phase 2 写 evidence / decisions
+- Phase 2.5 写架构审计摘要
+- Phase 2.9 写 commit gate 结果
+- Phase 4 只做汇总和归档收尾
+
+这样 Phase 4 变成收敛，而不是返工。
+
+### 7. Rule placement avoids duplication drift
+
+本次 change 的一个隐含架构约束是避免同一规则在多个层面双份维护：
+
+- 如果某条规则属于执行门禁，应优先落在 `SKILL.md` 或 `phase-contracts.md`。
+- 如果某条规则属于 capability 降级，应优先落在 `fallbacks.md`。
+- `workflow.md` 可以解释为什么这样设计，但不应再逐条复制执行细则。
+- `templates.md` 保持可选和轻量，否则会把“协议硬化”扩大成“格式标准化”。
+
+这能降低 v3.1 之后再次出现“规则已经写了，但代理仍然执行漂移”的维护风险。
+
+## Risks / Trade-offs
+
+- 更强的 checkpoint 会增加少量流程显式成本，但可以换来更低的遗漏率。
+- 问题池可能让 Phase 2 看起来更正式，但如果不先暴露覆盖面，one-at-a-time 容易退化成随机追问。
+- 更硬的 cross-artifact 检查会让 change 前期更慢，但比在 apply 前后由用户兜底更可靠。
+- 如果把同一规则同时写进协议、模板和案例说明，后续维护面会再次变大，因此这轮需要严格控制规则落点。
+
+## Validation
+
+需要通过文档与 OpenSpec 产物验证以下结果：
+
+- `sm-flow` 明确要求阶段 checkpoint。
+- `micro` 明确禁止跳过关键 gate。
+- Phase 2 明确先形成问题池，再一次一问推进。
+- Phase 1.5 / 2.9 明确 cross-artifact 检查链路。
+- devflow 的过程内同步更新要求被写入协议。
+- 不要求代理额外输出统一格式的阶段汇报示例。

openspec/changes/sm-flow-execution-hardening/proposal.md

@@ -0,0 +1,47 @@
+## Why
+
+`sm-flow` 已经建立了 `OpenSpec-first / Devflow-assisted` 的主从关系，也补入了 Draft/Committed OpenSpec、接口影响分级、Phase 2.9 和实现期冲突分类等关键规则。但真实项目复盘显示，代理仍然会按“先读代码、先形成方案、尽快推进实现”的习惯行动，而不是稳定经过 phase gate、自检和一致性检查。
+
+当前问题不是主设计方向错误，而是执行协议还不够“硬”：
+
+- `micro` 模式容易被误解为可以跳过关键阶段。
+- skill/fallback 声明存在规则，但没有成为阶段完成条件。
+- Phase 2 有 one-at-a-time 约束，但没有先形成问题池，导致问题覆盖不足。
+- Phase 1.5 和 2.9 的 cross-artifact 检查缺少更明确的执行清单，遗漏只能等用户 review 才暴露。
+- devflow 产物容易被拖到 Phase 4 补写，而不是在过程内同步更新。
+
+因此需要新增一轮“执行硬化”改造，把现有规则收敛成更明确的阶段检查点、问题池机制和一致性检查要求。
+
+## What Changes
+
+- 为 `sm-flow` 增加更短、更高频的 phase checklist / checkpoint 规则。
+- 明确“未显式声明 skill 或 fallback = 本阶段未完成”。
+- 为 Phase 2 增加“先形成问题池，再一次一问推进”的要求。
+- 强化 Phase 1.5 / 2.9 的 cross-artifact diff 检查，覆盖 proposal、design、specs、tasks、brief、evidence、decisions 的一致性。
+- 明确 `micro` 只能压缩产物，不能跳过 Phase 0.5、Phase 2、Phase 2.9 等关键 gate。
+- 明确 devflow 默认在各阶段同步更新，而不是拖到 Phase 4 统一补写。
+- 明确本次改造不强制固定 checkpoint / alignment 模板，也不把统一阶段汇报格式纳入验收范围。
+
+## Capabilities
+
+### New Capabilities
+
+- `sm-flow-phase-checkpoints`: 定义各阶段的最小检查点和阶段完成条件。
+- `sm-flow-question-pool`: 定义 Phase 2 的问题池生成与单题推进规则。
+- `sm-flow-cross-artifact-alignment`: 定义 Phase 1.5 / 2.9 的跨产物一致性检查要求。
+- `sm-flow-micro-gate-preservation`: 定义 `micro` 模式下不可跳过的关键 gate。
+
+### Modified Capabilities
+
+- `sm-flow-commit-gate`: 增强提交前检查，补充 cross-artifact diff 和阶段状态显式确认。
+- `sm-flow-context-indexing`: 补充 devflow 过程内同步更新要求。
+
+## Impact
+
+- 修改 `.agents/skills/sm-flow/SKILL.md`
+- 修改 `.agents/skills/sm-flow/references/phase-contracts.md`
+- 修改 `.agents/skills/sm-flow/references/fallbacks.md`
+- 可能修改 `.agents/skills/sm-flow/references/templates.md`
+- 修改 `skill-workbench/docs/sm-flow/workflow.md`
+- 不修改业务代码
+- 不改变 `OpenSpec-first / Devflow-assisted` 主设计

openspec/changes/sm-flow-execution-hardening/specs/sm-flow-cross-artifact-alignment/spec.md

@@ -0,0 +1,29 @@
+## ADDED Requirements
+
+### Requirement: Phase 1.5 checks cross-artifact alignment explicitly
+
+SM Flow SHALL explicitly check alignment across requirement, design, specification, and execution artifacts during Phase 1.5.
+
+#### Scenario: Alignment check runs
+
+- **WHEN** Phase 1.5 reviews the current Draft OpenSpec
+- **THEN** it checks that `brief/prd` aligns with `proposal`, `proposal` aligns with `design`, `design` aligns with `specs`, and `specs` align with `tasks`
+
+#### Scenario: Alignment gap is found
+
+- **WHEN** an expected behavior, term, field, constraint, or implementation slice appears in one artifact but not its downstream artifact
+- **THEN** the flow marks the gap explicitly and repairs OpenSpec before entering the next phase
+
+### Requirement: Phase 2.9 validates cross-artifact closure
+
+SM Flow SHALL re-check cross-artifact closure during Phase 2.9 before implementation.
+
+#### Scenario: Commit gate runs
+
+- **WHEN** Phase 2.9 evaluates whether Draft OpenSpec can become Committed OpenSpec
+- **THEN** it verifies that `evidence.md` and `decisions.md` findings that affect implementation are reflected in proposal, design, specs, or tasks
+
+#### Scenario: User review would otherwise catch the gap
+
+- **WHEN** a field, scope item, acceptance behavior, or design constraint is missing from the downstream OpenSpec artifacts
+- **THEN** the flow SHALL fail the commit gate and return to the earlier phase that owns the missing update

openspec/changes/sm-flow-execution-hardening/specs/sm-flow-micro-gate-preservation/spec.md

@@ -0,0 +1,30 @@
+## ADDED Requirements
+
+### Requirement: Micro mode compresses artifacts but preserves critical gates
+
+SM Flow SHALL allow `micro` mode to reduce artifact weight without skipping critical gates.
+
+#### Scenario: Micro mode starts
+
+- **WHEN** a change is classified as `micro`
+- **THEN** the flow may merge or simplify devflow artifacts
+- **AND** it SHALL still perform Phase 0.5 minimum context harvest, Phase 2 minimum clarification, Phase 2.9 commit gate, and Phase 4 lightweight backfill
+
+#### Scenario: Micro mode is treated as skip permission
+
+- **WHEN** the agent attempts to skip a critical gate because the change is small or low-risk
+- **THEN** the flow SHALL treat that as a protocol deviation rather than a valid micro-mode optimization
+
+### Requirement: Devflow updates happen during the flow
+
+SM Flow SHALL update devflow artifacts during the relevant phases rather than deferring all updates to Phase 4.
+
+#### Scenario: Phase-local information is produced
+
+- **WHEN** a phase produces entry summary, evidence, decisions, architecture findings, or commit-gate conclusions
+- **THEN** the corresponding devflow artifact is updated in or near that phase
+
+#### Scenario: Phase 4 begins
+
+- **WHEN** the flow enters Phase 4
+- **THEN** devflow backfill is primarily a consolidation step rather than the first time those records are written

openspec/changes/sm-flow-execution-hardening/specs/sm-flow-phase-checkpoints/spec.md

@@ -0,0 +1,34 @@
+## ADDED Requirements
+
+### Requirement: Each critical phase has an explicit checkpoint
+
+SM Flow SHALL require an explicit checkpoint before a critical phase can be considered complete.
+
+#### Scenario: Phase completes normally
+
+- **WHEN** the agent finishes a critical phase such as Phase 0, Phase 0.5, Phase 1, Phase 2, Phase 2.5, or Phase 2.9
+- **THEN** it reports the current phase, the capability source used, the produced artifacts, the satisfied exit conditions, and any unresolved blockers
+
+#### Scenario: Checkpoint is missing
+
+- **WHEN** a critical phase has produced artifacts or conclusions but no explicit checkpoint summary
+- **THEN** the phase SHALL NOT be treated as complete for purposes of entering the next phase
+
+### Requirement: Capability declaration is part of phase completion
+
+SM Flow SHALL treat skill or fallback declaration as part of the phase completion condition.
+
+#### Scenario: Native skill or local protocol is used
+
+- **WHEN** a phase depends on a named capability such as `openspec-propose`, `grill-with-docs`, `zoom-out`, or `openspec-apply-change`
+- **THEN** the agent states whether it used a native skill, a local `SKILL.md`, or a fallback protocol
+
+#### Scenario: Fallback is used
+
+- **WHEN** a phase falls back from a named capability
+- **THEN** the agent records the target capability, the reason it was unavailable, the fallback protocol name, and the downgrade risk
+
+#### Scenario: Declaration is omitted
+
+- **WHEN** no capability source is declared for a phase that requires one
+- **THEN** that phase SHALL NOT be considered complete

openspec/changes/sm-flow-execution-hardening/specs/sm-flow-question-pool/spec.md

@@ -0,0 +1,29 @@
+## ADDED Requirements
+
+### Requirement: Phase 2 builds a question pool before interviewing
+
+SM Flow SHALL build a Phase 2 question pool before consuming `user-interview` questions one at a time.
+
+#### Scenario: Phase 2 starts
+
+- **WHEN** the flow enters Phase 2
+- **THEN** it defines a question pool that covers at least terminology, scope boundaries, and acceptance
+
+#### Scenario: Complex change needs deeper coverage
+
+- **WHEN** the change affects multiple modules, interfaces, permissions, downstream consumers, response structures, or lifecycle rules
+- **THEN** the Phase 2 question pool also includes those dimensions before user-interview consumption begins
+
+### Requirement: User-interview questions remain one-at-a-time
+
+SM Flow SHALL preserve the one-question-at-a-time rule while using a question pool.
+
+#### Scenario: User-interview question is asked
+
+- **WHEN** the next unresolved `user-interview` item is selected from the question pool
+- **THEN** the flow asks exactly one question, waits for the explicit user answer, records the result, and only then advances to the next `user-interview` item
+
+#### Scenario: Question pool exists but answer is missing
+
+- **WHEN** there are remaining question-pool items and the current `user-interview` question is unanswered
+- **THEN** the flow SHALL NOT ask another `user-interview` question until the current one is resolved

openspec/changes/sm-flow-execution-hardening/tasks.md

@@ -0,0 +1,24 @@
+## 1. OpenSpec artifacts
+
+- [x] 1.1 Write proposal for `sm-flow-execution-hardening`
+- [x] 1.2 Write design for execution hardening rules
+- [x] 1.3 Add specs for checkpoints, question pool, cross-artifact alignment, and micro gate preservation
+
+## 2. Protocol hardening
+
+- [x] 2.1 Update `.agents/skills/sm-flow/SKILL.md` with explicit phase checkpoint and stage-completion rules
+- [x] 2.2 Update `.agents/skills/sm-flow/references/phase-contracts.md` with question pool, cross-artifact alignment, and micro gate preservation rules
+- [x] 2.3 Update `.agents/skills/sm-flow/references/fallbacks.md` so fallback declaration is mandatory and recorded
+- [x] 2.4 Keep templates optional; only adjust them if existing references need minimal field hints rather than mandatory fixed formats
+
+## 3. Workflow documentation
+
+- [x] 3.1 Update `skill-workbench/docs/sm-flow/workflow.md` with the execution-hardening model
+- [x] 3.2 Ensure retrospective learnings are reflected as protocol rules rather than only narrative notes
+
+## 4. Validation
+
+- [x] 4.1 Validate the OpenSpec change
+- [x] 4.2 Verify key terms are consistently documented across skill, references, and workflow docs
+- [x] 4.3 Backfill devflow records after implementation if the change proceeds beyond Draft
+- [x] 4.4 Verify acceptance is satisfied by protocol/document changes alone, without requiring a standardized phase-report output format

skill-workbench/docs/sm-flow/retrospective.md

@@ -0,0 +1,208 @@
+# SM Flow 首次执行回顾
+
+**日期**：2026-05-21
+**变更**：[ops-message-support](projects/2026-05-21-ops-message-support/) — 站内消息新增 OMC 支持
+**目的**：以本次交互为例，逐阶段复盘实际执行与 SM Flow 预期的差距，作为后续执行的改进依据。
+
+---
+
+## Phase 0 — 入口澄清
+
+### 应该做的
+- 收集问题、期望结果、目标用户、涉及代码区域、约束条件
+- 输出入口摘要、slug、规模分档
+
+### 实际做的
+- 用户输入需求后，直接开始读代码和查数据库
+- 输出了 slug（`ops-message-support`）和分档（micro）
+
+### 没做到的
+- 没有输出入口摘要（清晰的 1-2 句话问题 + 1-2 句话期望结果）
+- 没有列已知影响代码或模块清单
+
+### 改进建议
+- Phase 0 结束时花 1 分钟写 3-5 行入口摘要到 `brief.md`，而不是等用户问再补
+
+---
+
+## Phase 0.5 — Devflow 上下文收集
+
+### 应该做的
+- 初始化 devflow 目录结构
+- 读取 glossary、ADR、历史项目
+- 形成上下文摘要写入 brief.md
+
+### 实际做的
+- 等用户质疑 devflow 无产物时才在 Phase 2.9 补创建
+
+### 没做到的
+- ❌ **没有在 Phase 0.5 创建 devflow 项目目录和任何文件**
+- 没检查 glossary（当时为空也正常，但应该初始化和告知）
+
+### 改进建议
+- 进入 Phase 0.5 就执行 `mkdir devflow/projects/{slug}/` 并创建 `brief.md` 骨架
+- Devflow 是"思考记录"不是"文档任务"，哪怕只写 3 行也比事后补强
+
+---
+
+## Phase 1 — OpenSpec propose
+
+### 应该做的
+- 声明"本阶段调用 openspec-propose skill"
+- 如果不可用，降级为 fallback 并说明原因
+- 产出 proposal / design / specs / tasks
+
+### 实际做的
+- 调用了 `openspec new change` 创建了 change 目录
+- openspec CLI 模板不匹配时报错，**没有声明降级**，直接手动创建文件
+- 手动创建了 research、proposal、design、specs、tasks
+
+### 没做到的
+- ❌ **没有声明"openspec CLI 模板不匹配，降级为 manual fallback"**
+- ❌ **没有区分 Draft OpenSpec 和 Committed OpenSpec**（两者在流程中意义不同）
+- 产出顺序按了 research-first schema，但未验证 artifacts 间的依赖一致性
+
+### 改进建议
+- Skill 不可用时必须说清楚：什么 skill + 什么原因不可用 + 降级方式
+- Draft OpenSpec 阶段标记为 draft，和 Committed OpenSpec 区分
+
+---
+
+## Phase 1.5 — PRD / OpenSpec 对齐
+
+### 应该做的
+- 检查 proposal 是否覆盖 research 范围
+- 检查 design 是否满足 proposal 承诺的能力
+- 检查接口影响等级（L1-L4）
+
+### 实际做的
+- **直接跳过**，没有做任何 formal 的对齐检查
+
+### 没做到的
+- ❌ 对齐检查完全缺失
+- 后果：proposal.md 漏了 type 字段，design.md 和 research.md 都已包含但 proposal 没更新，直到用户 review 才发现
+
+### 改进建议
+- 即使 micro 模式，至少做一次快速交叉检查：research 范围 ↔ proposal 变更 ↔ design 决策 ↔ specs 场景
+
+---
+
+## Phase 2 — Human-in-the-loop 澄清
+
+### 应该做的
+- 声明"本阶段调用 grill-with-docs skill"，按结构化方式追问
+- 至少覆盖术语、边界、验收三个维度
+- evidence-driven 的先查证再汇报
+- user-interview 的**一次只问一个问题**，等用户确认后再问下一个
+- 用户确认后回写 OpenSpec
+- 对模糊的术语（如"运管"）通过 grill 确认其准确定义
+
+### 实际做的
+- **没有调用 grill-with-docs** ❌
+- **一次问了 3 个 user-interview 问题**，违反规则 ❌
+- 收集了充分的 evidence（代码和数据库分析到位）✓
+- 用户确认后及时回写了 OpenSpec ✓
+
+### 没做到的
+- ❌ 没有使用 grill 或任何结构化追问工具，自己随意问了几个问题
+- ❌ 一次多问被用户 reject
+- 问题数量太少：只用了 3 个问题（编码、子分类、字段范围），远不足以覆盖所有盲区
+- 以下该问但没有问的问题：
+  - OMC 消息从哪里发送？通过什么 identifier/messageCode 触发投递？
+  - OMC 用户侧的权限体系是怎样的？和 APP 用户在同一张权限表吗？
+  - OMC 前端需要怎样的响应结构？只要总数还是要子分类列表？
+  - 现有 APP 端有 hasUnread/readAll 等功能，OMC 端是否也需要？
+  - OMC 消息的创建时间和保留策略？
+- "运管"这个概念从一开始就模棱两可，没有通过 grilling 追根究底，到用户主动纠正为 OMC 时才明确
+
+### 改进建议
+- 必须调用 grill-with-docs，不调用就是跳过
+- 问题数量下限：至少 5-8 个尝试性提问，覆盖：术语定义、发送来源、权限模型、前端需求、功能对标
+- 一次一问，等回复后再继续
+- 在 Phase 2 开始时创建 Task 跟踪 grill 进度："Q1[术语]...→Q2[边界]...→Q3[验收]..."，每问一个更新一次
+
+---
+
+## Phase 2.5 — 架构审计
+
+### 应该做的
+- 画出输入 → 处理 → 输出的模块链路
+- 识别跨模块依赖、数据所有权、生命周期和耦合风险
+- 用不超过五句话写出架构风险评估
+- 影响实现的结论回写 OpenSpec design/tasks
+
+### 实际做的
+- **直接跳过**
+- 做了代码分析但未输出正式的架构审计记录
+
+### 没做到的
+- ❌ 模块链路图缺失
+- ❌ 接口影响分析表是用户追问后才补的
+- ❌ listMessageCategory 泄漏 OMC 的问题在架构审计中本应发现，但跳过后留到了用户 review 才发现
+
+### 改进建议
+- Phase 2.5 至少画一张文本链路图：`User → Controller → Service → Mapper → DB`
+- 然后问自己：新增的 type 字段会影响哪些链路节点？
+
+---
+
+## Phase 2.9 — Commit OpenSpec
+
+### 应该做的
+- 检查所有 artifacts 的一致性
+- 检查所有 user-interview 都已确认
+- 检查接口影响已记录
+- 向用户汇报并请求 Phase 3 授权
+
+### 实际做的
+- 做了检查，但不够彻底（proposal 漏了 type）
+- 接口影响分析是补的
+- 汇报了，但用户先发现了 type 字段问题
+
+### 没做到的
+- 没能在用户发现问题前自己找出 proposal 遗漏
+- 自检清单没有对照执行
+
+### 改进建议
+- Phase 2.9 不能光靠头脑检查，要逐行对比 research ↔ proposal ↔ design ↔ specs ↔ tasks 的关键断言
+
+---
+
+## Phase 3 — OpenSpec apply
+
+尚未开始
+
+---
+
+## Phase 4 — 回填 Devflow
+
+### 应该做的
+- 验收记录
+- 更新 devflow/index.md
+- 询问是否归档 OpenSpec change
+
+### 实际做的
+- devflow 产物在用户要求下补创建
+- index.md 在用户质疑后创建
+
+### 改进建议
+- Phase 4 的 devflow 产物应该是最轻松的，因为内容已经在各阶段产出过，只需要汇总
+
+---
+
+## 根因总结
+
+### 约束是否到位？
+
+SM Flow 的 rules 在 SKILL.md 和 reference 中写得很清楚。问题**不是约束不到位**，而是：
+
+1. **高估了小改动的判断** — micro 分档让我误以为"可以跳过检查"，实际 micro 只合并产物不跳过阶段
+2. **按代码习惯而非按流程执行** — 作为习惯于输出代码的 agent，对流程节点的重视度天然低于代码
+3. **缺少执行中的自检机制** — rules 只在加载时读一次，被上下文冲走后就没有对照检查
+
+### 核心教训
+
+- **Devflow 是思考过程，不是文档任务** — 写文档的过程就是做架构审计和一致性检查的过程
+- **Micro 不等于跳过** — 产物可以合并，但检查点不能省略
+- **声明即约束** — 把"本阶段调用 X / 降级为 Y"说出来，是对自己的提醒也是对用户的透明
+- **Devflow 和 OpenSpec 同步更新** — 更新 OpenSpec 时同步更新 devflow，不要把 devflow 留到 Phase 4 一次性补。两者是同一件事的两面，不是先后关系

skill-workbench/docs/sm-flow/workflow.md

@@ -412,8 +412,56 @@ Phase 2 的 `grill-with-docs` 不是代理自问自答。`user-interview` 问题
 
 `evidence-driven` 问题可以由代理先查证，但也必须汇报证据、结论和是否需要用户确认。
 
+Phase 2 在开始追问前，还应该先建立一个 question pool。最小问题池至少覆盖：
+
+- 术语
+- 范围边界
+- 验收口径
+
+如果变更涉及多模块、接口、权限、下游消费者、响应结构或生命周期规则，再把这些维度补进问题池。问题池的作用是先把风险面列全，再继续保持 one-at-a-time 的 `user-interview` 消费节奏，而不是一次把所有问题都抛给用户。
+
 单个 grill 决策确认不等于 Phase 3 apply 授权。用户在 Phase 2 回答“可以”只表示该问题已确认；代理必须先回写 OpenSpec/devflow，停在 Phase 2.9，报告 Committed OpenSpec 检查结果，并等待用户明确要求进入 apply、开始实现、执行修改或继续 Phase 3。
 
+### Phase Checkpoint
+
+v3.1 的另一个收紧点是：关键阶段不再靠“看起来做完了”判断完成，而是靠显式 checkpoint。
+
+关键阶段至少包括：
+
+- Phase 0
+- Phase 0.5
+- Phase 1
+- Phase 2
+- Phase 2.5
+- Phase 2.9
+
+每个 checkpoint 至少说明：
+
+- 当前阶段
+- 调用的 capability 来源
+- 产出的关键 artifact
+- 已满足的退出条件
+- 尚未解决的 blocker
+
+如果没有这些信息，就不应该把阶段视为已完成，更不应该直接进入下一阶段。
+
+### Cross-Artifact Alignment
+
+v3.1 之后，Phase 1.5 和 Phase 2.9 不只是“看看文档差不多”，而是要显式检查一条对齐链：
+
+```text
+brief/prd -> proposal -> design -> specs -> tasks
+```
+
+检查重点不是格式，而是下游产物有没有把上游已经确定的内容接住，例如：
+
+- `brief/prd` 里的范围和非目标有没有进入 `proposal`
+- `proposal` 的关键承诺有没有进入 `design`
+- `design` 里的实现约束和接口影响有没有进入 `specs` 或 `tasks`
+- `specs` 里的可观察行为有没有被 `tasks` 切成可执行工作
+
+如果字段、术语、约束、行为或切片只停留在上游文档里，就应该视为对齐缺口，先修 OpenSpec，再继续流程。
+
 ### 接口影响分级
 
 v3.1 区分“接口影响记录”和“独立接口文档”：
@@ -445,6 +493,21 @@ devflow/compound/
 
 Phase 4 回填项目档案时必须更新 `devflow/index.md`。最小字段为日期、slug、领域、关键词、关联 OpenSpec 和状态。
 
+另外，v3.1 也把一个实践经验写成硬规则：devflow 不是等到 Phase 4 才第一次补写。`brief.md`、`evidence.md`、`decisions.md` 这类过程内档案应该随阶段就近更新，Phase 4 主要负责 consolidation 和归档口径收束。
+
+### Micro 不是 Skip
+
+`micro` 的目标是降低文档重量，不是给代理发放“可以跳 gate”的许可证。
+
+因此即使是 `micro` 变更，也仍然要保留：
+
+- Phase 0.5 最小上下文收集
+- Phase 2 最小澄清
+- Phase 2.9 commit gate
+- Phase 4 轻量回填
+
+如果因为“改动很小”就跳过这些 gate，应该视为协议偏差，而不是合法优化。
+
 ### 实现期冲突处理
 
 Phase 3 中，如果用户质疑、用户修改、代码发现、测试失败或运行行为与 Committed OpenSpec 冲突，必须先分类：
@@ -470,6 +533,58 @@ v3.1 将子 skill 从“路径绑定”改为“能力绑定”。例如 `opensp
 
 这样 `sm-flow` 可以在 Claude、Codex 或其他代理环境中迁移，而不会被某个固定目录锁死。
 
+一旦进入 fallback，代理还必须把这次降级本身记录下来。也就是说，fallback 不只是“内部换个做法”，而是一个需要显式声明 capability 缺失、降级原因和风险的协议事件。
+
+## v3.1 后续收口：协议瘦身与 review 修正
+
+在执行硬化规则落地后，又做了一轮非常实际的收口：不是再增加新规则，而是把已经确认的规则放到更稳定、可维护的位置，并修掉瘦身过程中暴露的引用问题。
+
+### 顶层 skill 瘦身
+
+`SKILL.md` 不再同时承担“入口协议”和“大段运行手册”两种职责，而是收敛为：
+
+- 工作流定位
+- 真理源分层
+- 核心硬规则
+- reference 加载入口
+- 阶段总览
+
+原来放在顶层但更适合按需读取的内容，被下沉到新的：
+
+```text
+references/operating-rules.md
+```
+
+这里集中放：
+
+- 接口影响分级
+- 启动检查
+- 项目标识规则
+- devflow 产物分层
+- 快速模式细则
+- 完成标准
+
+这样做的目标不是减少规则，而是减少“启动时一次读太多”和“顶层协议与 reference 抢职责”的问题。
+
+### Fallback 去重复
+
+`fallbacks.md` 也做了第二轮整理：
+
+- 顶部统一定义 fallback 通用记录要求
+- 各 fallback 小节只保留自己的额外记录义务
+
+这样可以避免每个 fallback 都重复写一遍“要声明 fallback、要记录 fallback”，同时不丢失协议要求。
+
+### Review 驱动的自洽性修正
+
+瘦身后又发现了一类很典型的问题：**规则本身没错，但 cross-reference 可能断掉**。因此又补了一轮 review 驱动修正，重点包括：
+
+- `phase-contracts.md` 在首次使用接口分级、分档、快速模式时，显式指向 `operating-rules.md`
+- 修正 fallback 锚点，避免 skill 指向不存在的章节名
+- 统一 `operating-rules.md` 的语言风格，避免在主协议是中文时夹着一整份英文运行规则
+
+这轮修正说明一件事：协议产品化不只是“把规则写出来”，还要保证**入口、逐阶段契约、fallback 和运行规则之间的导航关系始终自洽**。
+