redesign sm-flow v4.0 as protocol-layer harness

- Reposition sm-flow as orchestration harness over OpenSpec lifecycle
- Adopt 4 user commands (Actions, Not Phases) instead of phase numbers
- Rename all stages to English verbs (clarify through archive)
- Reorder execution: grill before specify to eliminate rework loops
- Simplify core rules from 19 to 6 hard constraints in SKILL.md
- Simplify conflict classification from 4 categories to 2+1
- Switch devflow strategy to decisions.md-only process log during execution
- Upgrade micro mode from artifact compression to gate merging
- Add observable outputs for quality constraints
- Add design review doc and user guide
- Append v4.0 changelog to workflow.md

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

@@ -1,6 +1,6 @@
-# 归档规则
+# 归档规则
 
-Phase 4 的目标是把 OpenSpec 产物、实现结果和验证结果转化为持久、可读、可复用的项目记忆。v3 中，OpenSpec 是执行真理源，devflow 是辅助 OpenSpec 和人类阅读的档案层。
+archive 阶段的目标是把 OpenSpec 产物、实现结果和过程日志转化为持久、可读、可复用的项目记忆。sm-flow 在 clarify → apply 期间只维护 `decisions.md` 作为过程日志，archive 阶段从中提取完整 devflow 档案。
 
 ## 目录规则
 
@@ -10,12 +10,12 @@ Phase 4 的目标是把 OpenSpec 产物、实现结果和验证结果转化为
 devflow/projects/YYYY-MM-DD-{slug}/
 ```
 
-默认创建以下必要文件：
+archive 阶段创建以下文件：
 
-- `brief.md`
-- `evidence.md`
-- `decisions.md`
-- `acceptance.md`
+- `brief.md`：从 proposal.md 提取背景、目标、范围、非目标。
+- `evidence.md`：从 decisions.md 中的 evidence-driven 记录提取。
+- `decisions.md`：保持为最终版，整理格式。
+- `acceptance.md`：从实现结果和验证结果提取。
 
 同时维护仓库级索引：
 
@@ -44,11 +44,12 @@ devflow/projects/YYYY-MM-DD-{slug}/
 
 | 来源 | 提取内容 | 写入位置 |
 | --- | --- | --- |
+| `decisions.md`（过程日志） | question pool、evidence-driven 汇报状态、user-interview 确认状态、关键取舍 | `decisions.md`（整理格式为最终版） |
+| `decisions.md`（过程日志） | evidence-driven 结论、代码/文档证据 | `evidence.md` |
 | `proposal.md` | 为什么做、做什么、范围、非目标 | `brief.md` |
 | `design.md` | 技术方案、关键决策、风险；只提炼长期有用内容 | `evidence.md` / 按需 `design.md` |
 | `specs/**/*.md` | requirement 标题和 scenario 意图 | `brief.md` 或 `acceptance.md` 的验收追踪 |
 | `tasks.md` | checkbox 状态、剩余工作、执行切片 | `acceptance.md`；复杂项目可拆 `tasks.md` |
-| 澄清记录 | evidence-driven/user-interview、证据、结论、确认状态 | `evidence.md` + `decisions.md` |
 | 测试/构建输出 | 验证命令、结果、验证类型 | `acceptance.md` |
 | diagnose 记录 | 根因、修复、回归验证 | `acceptance.md` |
 | 词汇表更新 | 术语和业务规则 | `devflow/glossary/CONTEXT.md` |
@@ -57,7 +58,7 @@ devflow/projects/YYYY-MM-DD-{slug}/
 
 ## 索引维护规则
 
-`devflow/index.md` 是 Phase 0.5 的默认入口，Phase 4 回填时必须维护。
+`devflow/index.md` 是 context 阶段的默认入口，archive 阶段回填时必须维护。
 
 最小字段：
 
@@ -67,9 +68,9 @@ devflow/projects/YYYY-MM-DD-{slug}/
 规则：
 
 - 每个 `devflow/projects/YYYY-MM-DD-{slug}/` 默认对应一行索引。
-- Phase 4 新建或更新项目档案时，必须新增或更新对应行。
+- archive 阶段新建或更新项目档案时，必须新增或更新对应行。
 - 如果项目仍在进行，状态写 `active`；已验收但未 archive 写 `accepted-unarchived`；已 archive 写 `archived`；暂停写 `paused`。
-- 关键词只放能帮助 Phase 0.5 定位的术语，不复制 brief 内容。
+- 关键词只放能帮助 context 阶段定位的术语，不复制 brief 内容。
 - 如果无法准确判断领域或状态，写 `unknown`，并在 `acceptance.md` 记录待补。
 
 ## 验收记录规则
@@ -85,7 +86,7 @@ devflow/projects/YYYY-MM-DD-{slug}/
 
 - 如果验证通过，记录命令/步骤和覆盖范围。
 - 如果验证失败，记录失败摘要和是否阻塞验收。
-- 如果需要人工验证，列出明确步骤，不要用“手动测试一下”这种模糊描述。
+- 如果需要人工验证，列出明确步骤，不要用"手动测试一下"这种模糊描述。
 
 ## ADR 规则
 
@@ -111,19 +112,17 @@ devflow/compound/YYYY-MM-DD-decision-{slug}.md
 
 OpenSpec archive 是显式 human-in-the-loop 动作。archive 前必须确认 devflow 已经回填 OpenSpec 的关键执行信息：
 
-- Phase 4 可以建议 archive，但必须先询问用户。
+- archive 阶段可以建议 archive，但必须先询问用户。
 - 在用户确认前，不要执行 archive。
 - 如果用户暂不归档，在 acceptance 中记录原因或状态。
 - 如果用户确认归档，执行后记录 archive 结果和剩余档案位置。
 
 ## 归档交接
 
-Phase 4 结束时告诉用户：
+archive 阶段结束时告诉用户：
 
 - 创建或更新了哪些档案文件。
 - `devflow/index.md` 是否已更新。
 - 运行了哪些验证，并按静态验证、脚本验证、浏览器/人工验证、未验证分类。
 - 还剩哪些风险或后续事项。
 - 明确询问：是否现在 archive OpenSpec change？
-
-

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

@@ -1,39 +1,39 @@
-# Fallback 协议
+# 降级协议
 
-当子 skill 无法直接调用时使用这些协议。Fallback 不是绕过 OpenSpec 的许可；v3 中 fallback 的目标仍然是生成、修正或执行 OpenSpec 产物。使用任何 fallback 前必须先向用户说明：目标子 skill、无法调用原因、降级协议名称、降级风险。产物中也必须记录“本阶段为 fallback 降级执行”。
+当子 skill 无法直接调用时，sm-flow 使用内置执行协议接管。这不是能力缺失，而是 harness 的正常能力切换。
 
-## Fallback 记录要求
+使用任何降级前必须先向用户说明：目标子 skill、无法调用原因、降级协议名称。产物中也必须记录"本阶段为降级执行"。
 
-任何 fallback 都必须同时满足以下记录要求：
+## 降级记录要求
+
+任何降级都必须同时满足以下记录要求：
 
 1. 在对用户的阶段汇报里声明：
    - 目标 capability
    - 不可用原因
-   - 使用的 fallback 协议名
-   - 本次降级风险
-2. 在 `decisions.md`、`evidence.md` 或 `acceptance.md` 中留下同样的降级记录。
-3. 如果当前阶段需要 checkpoint，则 fallback 声明是 checkpoint 完成条件的一部分。
+   - 使用的降级协议名
+2. 在 `decisions.md` 中留下同样的降级记录。
+3. 如果当前阶段需要 checkpoint，则降级声明是 checkpoint 完成条件的一部分。
 4. 如果没有完成这些声明和记录，该阶段不得视为已完成。
 
-除非某个 fallback 额外说明，否则下面各节默认继承这组通用记录要求，不再重复要求“记录本阶段 fallback 声明”。
+除非某个降级额外说明，否则下面各节默认继承这组通用记录要求，不再重复。
 
-## OpenSpec 提案 fallback
+## OpenSpec 提案降级
 
-1. 创建或识别 `openspec/changes/{slug}/`。
-2. 先读取 devflow 上下文：`devflow/glossary/CONTEXT.md`、相关项目档案、ADR、acceptance、compound knowledge。
-3. 写入 `proposal.md`，包含：
-   - 问题
-   - 建议方案
-   - 范围
-   - 非目标
+specify 阶段调用 `openspec-propose` 不可用时使用。propose 阶段使用 sm-flow 内置协议（轻量 proposal），不需要降级。
+
+1. 确认 `openspec/changes/{slug}/proposal.md` 已存在（propose 阶段产出）。
+2. 读取 grill 阶段的 decisions.md 记录，获取已确认的需求和决策。
+3. 写入 `design.md`，包含：
+   - 关键技术决策
    - 来自 devflow 的上下文约束
-   - 风险
-4. 当实现需要技术选择时，写入 `design.md`，并引用相关 ADR 或历史验收结论。
-5. 将 `tasks.md` 写成按纵向切片组织的 checkbox 清单。
-6. 只为外部可见行为或发生变化的需求编写 specs。
-7. 如果存在高风险假设，在 Phase 1.5 前向用户 checkpoint。
+   - 架构约束和风险
+4. 将 `tasks.md` 写成按纵向切片组织的 checkbox 清单。
+5. 只为外部可见行为或发生变化的需求编写 specs。
+6. 确保 design/specs/tasks 与 proposal 对齐。
+7. 如果存在高风险假设，在 specify checkpoint 中向用户汇报。
 
-## OpenSpec 修正 fallback
+## OpenSpec 修正降级
 
 当 PRD、devflow、澄清结论、架构审计和 OpenSpec 冲突时：
 
@@ -42,33 +42,32 @@
 3. 向用户汇报冲突和推荐修正。
 4. 用户确认后，优先修正 OpenSpec proposal/design/specs/tasks。
 5. 再同步更新 devflow 文档；不要只改 devflow。
-6. 额外记录冲突修正状态。
+6. 额外记录冲突修正状态到 decisions.md。
 
-## OpenSpec 执行 fallback
+## OpenSpec 执行降级
 
-仅当 `openspec-apply-change` 不可调用时使用。执行依据仍必须是 `openspec/changes/{slug}/`。
+apply 阶段调用 `openspec-apply-change` 不可用时使用。执行依据仍必须是 `openspec/changes/{slug}/`。
 
 1. 阅读 `proposal.md`、`design.md`、`specs/**/*.md` 和 `tasks.md`。
 2. 确认 OpenSpec 与 devflow 上下文没有未解决冲突。
 3. 确认没有未解决的 user-interview 问题、未判级接口影响或未提交的 Draft OpenSpec。
-4. 确认 Phase 2.9 后已经获得用户明确的 Phase 3 apply 授权；单个 grill 决策确认不能替代 apply 授权。
+4. 确认 commit 后已经获得用户明确的 apply 授权；单个 grill 决策确认不能替代 apply 授权。
 5. 修改前先检查现有代码。
 6. 一次实现一个 OpenSpec task 的纵向切片。
-7. 如果用户质疑、代码发现、测试失败或运行行为与 OpenSpec 冲突，先分类：
-   - 实现偏差：OpenSpec 正确，代码偏离；修代码。
-   - 规格遗漏：OpenSpec 未覆盖真实边界、接口影响或验收；暂停执行，修正 OpenSpec 并重新提交后继续。
-   - 设计冲突：OpenSpec 与架构、ADR、历史验收或模块边界冲突；暂停并等待用户确认。
-   - 用户变更：用户改变目标、范围、验收或风险接受度；更新 proposal/specs/tasks 后继续。
-8. 冲突分类、证据、用户确认和 OpenSpec 回写状态必须记录到 `decisions.md` 或 `acceptance.md`。
+7. 如果用户质疑、代码发现、测试失败或运行行为与 OpenSpec 冲突，做三类判断：
+   - OpenSpec 不准（规格遗漏、边界未覆盖、验收口径缺失）→ 暂停执行，修正 OpenSpec 并重新提交后继续。
+   - 代码偏离（实现没按 OpenSpec 做）→ 修代码。
+   - 不确定根因、涉及设计方向、用户改变目标或范围 → 暂停并等待用户确认。
+8. 判断结果、证据、用户确认和 OpenSpec 回写状态必须记录到 `decisions.md`。
 9. 用最窄但有效的命令验证每个切片。
 10. 只有验证通过或明确记录原因后，才更新 task 状态。
 11. 如果失败原因不确定，停止并进入 diagnose。
 12. 如果 diagnose 证明规格不准，先修正 OpenSpec，再继续执行。
 13. 额外记录任务推进状态和验证状态。
 
-## PRD fallback
+## PRD 降级
 
-优先使用 `references/templates.md#brief-模板` 创建 `brief.md`。只有复杂需求、对外协作或用户明确要求 PRD 时，才使用 `references/templates.md#prd-模板` 创建 `prd.md`。
+specify 阶段调用 `to-prd` 不可用时使用。优先使用 `references/templates.md#brief-模板` 创建 `brief.md`。只有复杂需求、对外协作或用户明确要求 PRD 时，才使用 `references/templates.md#prd-模板` 创建 `prd.md`。
 
 规则：
 
@@ -77,16 +76,19 @@
 - 只有当缺失决策会阻塞 OpenSpec 正确性时，才采访用户。
 - 额外记录是否创建了独立 `prd.md`。
 
-## 文档化追问 fallback
+## 文档化追问降级
+
+grill 阶段调用 `grill-with-docs` 不可用时使用。
 
 1. 阅读已有词汇表、ADR、相关 OpenSpec 产物和 devflow 项目档案。
 2. 先声明每个问题的模式：`evidence-driven` 或 `user-interview`。
 3. 对 evidence-driven 问题，先查代码库、文档、OpenSpec 或 ADR，再向用户汇报证据和结论。
 4. 对 user-interview 问题，一次只问一个并等待用户确认。
-5. 术语确认后立即更新词汇表。
-6. 影响实现的澄清必须回写 OpenSpec。
-7. 只为难以逆转的真实权衡创建 ADR。
-8. 额外记录 question pool 和已消费问题。
+5. evidence-driven 和 user-interview 交替推进，避免攒到一起汇报。
+6. 术语确认后立即更新词汇表。
+7. 影响实现的澄清必须回写 proposal.md。
+8. 只为难以逆转的真实权衡创建 ADR。
+9. 额外记录 question pool 和已消费问题。
 
 快速模式的最小问题：
 
@@ -94,9 +96,9 @@
 - 边界：哪些内容明确不在范围内？是否需要用户确认？
 - 验收：什么可观察行为能证明它完成？是否已写入 OpenSpec specs？
 
-## 架构审计 fallback
+## 架构审计降级
 
-产出一份短架构审计：
+audit 阶段调用 `zoom-out` 不可用时使用。产出一份短架构审计：
 
 1. 画出输入 → 处理 → 输出。
 2. 列出相关模块和调用方。
@@ -106,7 +108,9 @@
 6. 如果影响实现，回写 OpenSpec design/tasks。
 7. 额外记录审计结论回写状态。
 
-## Diagnose fallback
+## Diagnose 降级
+
+apply 阶段调用 `diagnose` 不可用时使用。
 
 1. 复现问题，或捕获准确失败信息。
 2. 最小化失败案例。
@@ -118,9 +122,9 @@
 8. 运行回归验证。
 9. 额外记录根因分类和回归结果。
 
-## TDD fallback
+## TDD 降级
 
-使用纵向切片，不要水平批量写测试：
+apply 阶段调用 `tdd` 不可用时使用。使用纵向切片，不要水平批量写测试：
 
 1. 从 OpenSpec specs 中选择一个外部可见行为。
 2. 写一个失败测试。
@@ -128,4 +132,3 @@
 4. 只在测试通过时重构。
 5. 对下一个 OpenSpec 行为重复以上步骤。
 6. 额外记录当前行为切片的测试状态。
-

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

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

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

@@ -1,8 +1,10 @@
-# 阶段契约
+# 阶段契约
 
-本文件是 SM Flow v3 的逐阶段执行准则。v3 的核心原则是：**devflow 辅助 OpenSpec，OpenSpec 指挥执行，执行结果回填 devflow**。
+本文件是 SM Flow 的逐阶段执行准则。核心原则：**sm-flow 编排 OpenSpec，OpenSpec 指挥执行，执行结果回填 devflow**。
 
-## Phase 0 — 入口澄清
+执行顺序：clarify → context → propose → grill → specify → audit → commit → apply → archive。
+
+## clarify — 入口澄清
 
 **进入条件**：用户提供粗略想法、初始 PRD、已有 research、issue，或要求启动 SM Flow。
 
@@ -24,9 +26,9 @@
 - 初步 slug。
 - devflow 规模分档：`micro` / `standard` / `complex`。
 
-## Phase 0.5 — Devflow 上下文收集
+## context — 上下文收集
 
-**进入条件**：Phase 0 已经有足够信息定位领域、项目或变更方向。
+**进入条件**：clarify 已经有足够信息定位领域、项目或变更方向。
 
 **动作**：
 - 优先读取 `devflow/index.md`，按日期、slug、领域、关键词和关联 OpenSpec 定位候选项目。
@@ -38,104 +40,58 @@
 - 如果发现旧根目录 `CONTEXT.md` 与 `devflow/glossary/CONTEXT.md` 冲突，暂停并向用户汇报。
 
 **退出条件**：
-- 已形成“OpenSpec 输入上下文摘要”。
+- 已形成"OpenSpec 输入上下文摘要"。
 - 已记录 `devflow/index.md` 的使用状态：已命中 / 已初始化 / 无相关条目。
 - 已列出相关 ADR 和不能违反的历史决策。
 - 已列出需要写入或修正 OpenSpec 的上下文点。
 
 **输出**：
-- 上下文摘要，默认写入 `brief.md` 或 `evidence.md`；会影响实现的上下文必须写入 OpenSpec design/specs/tasks。
+- 上下文摘要，写入 `decisions.md`（过程日志）。会影响实现的上下文必须标记为"需进入 OpenSpec"。
 
-## Phase 1 — OpenSpec propose
+## propose — 轻量 propose
 
-**进入条件**：Phase 0 + Phase 0.5 已经足够生成或修正 OpenSpec change。
+**进入条件**：clarify + context 已经足够生成轻量 proposal。
 
-**显式子 skill**：`openspec-propose`。进入本阶段必须先声明调用方式：原生 Skill 调用 / 读取本地 `openspec-propose` 的 `SKILL.md` / fallback 降级。
+**执行者**：sm-flow 内置协议。**不调用 openspec-propose**（完整 OpenSpec 产物留待 specify 阶段生成）。
 
 **动作**：
-- 优先调用 `openspec-propose`。
-- 如果不可用，执行 `references/fallbacks.md#openspec-提案-fallback`，但仍必须产出 OpenSpec 文件。
-- 用 Phase 0.5 的 devflow 上下文增强 OpenSpec：
-  - proposal 写清为什么做、做什么、范围和非目标。
-  - design 写入上下文约束、历史 ADR、关键技术决策。
-  - specs 写成可验收的外部行为。
-  - tasks 写成可执行的纵向切片。
-- 在承诺设计细节前，先检查相关仓库代码。
+- 创建或识别 `openspec/changes/{slug}/`。
+- 写入 `proposal.md`，包含：问题、建议方案、范围、非目标、来自 devflow 的上下文约束、风险。
+- **不生成 design.md、specs/、tasks.md**——这些留待 grill 澄清需求后在 specify 阶段补全。
+- 用 context 阶段的 devflow 上下文增强 proposal。
+- 在承诺方案方向前，先检查相关仓库代码。
 
 **退出条件**：
-- `openspec/changes/<slug>/proposal.md` 存在。
-- 对需要正式 OpenSpec 产物的变更，`design.md`、`tasks.md` 和 specs 存在。
-- 关键假设已显式记录在 OpenSpec 或 research 中。
+- `openspec/changes/{slug}/proposal.md` 存在。
+- 关键假设已显式记录。
 
 **输出**：
-- Draft OpenSpec proposal、design、specs 和 task list。
+- Draft OpenSpec proposal.md（轻量版）。
 
 **Human checkpoint**：
-- 向用户简要说明 OpenSpec scope、关键假设、主要风险、devflow 上下文如何影响 OpenSpec。
-- 询问是否继续进入 PRD/OpenSpec 对齐和澄清阶段；用户明确要求“全自动执行”时可跳过等待。
+- 向用户简要说明 proposal 范围、关键假设、主要风险、devflow 上下文如何影响方案。
+- 询问是否继续进入 grill 澄清阶段；用户明确要求"全自动执行"时可跳过等待。
 
-## Phase 1.5 — PRD / OpenSpec 对齐
+## grill — 人类对齐澄清
 
-**进入条件**：Phase 1 已有 OpenSpec 产物。
+**进入条件**：propose 已有轻量 proposal.md。
 
-**显式子 skill**：`to-prd` + `sm-flow`。进入本阶段必须先声明是否读取 `.agents/skills/to-prd/SKILL.md`；如果使用内置模板，标记为 PRD fallback。
-
-**动作**：
-- 如果没有结构化 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 中的正确术语。
-  - OpenSpec 是否遵守相关 ADR。
-  - 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。
-- 所有已知冲突已修正或等待用户决策。
-
-**输出**：
-- `brief.md`，以及按需创建的 `prd.md`。
-- OpenSpec 对齐检查记录。
-- 必要的 OpenSpec 修正。
-
-## Phase 2 — Human-in-the-loop 澄清
-
-**进入条件**：已有 OpenSpec 产物和 PRD/上下文对齐记录。
-
-**显式子 skill**：`grill-with-docs`。进入本阶段必须先声明是否读取 `.agents/skills/grill-with-docs/SKILL.md`；fallback 必须标记为“文档化追问 fallback”。
+**显式子 skill**：`grill-with-docs`。进入本阶段必须先声明是否读取 `.agents/skills/grill-with-docs/SKILL.md`；降级必须标记为"文档化追问降级"。
 
 **动作**：
 - 优先使用 `grill-with-docs`。
-- 进入 Phase 2 时先建立一个 question pool，并记录到 `decisions.md` 或 `evidence.md`：
+- 进入 grill 时先建立一个 question pool，并记录到 `decisions.md`：
   - 默认至少覆盖术语、边界、验收三个维度。
   - 如果变更涉及多模块、接口、权限、下游消费者、响应结构或生命周期规则，先把这些维度补进问题池。
-- 先声明本阶段采用的澄清模式，并逐项标记：
+- 逐项标记每个问题的模式：
   - `evidence-driven`：问题能通过代码、文档、测试、OpenSpec 或既有 ADR 证明；代理先查证，再向用户汇报证据、结论和是否需要确认。
   - `user-interview`：问题涉及产品偏好、范围边界、验收口径、风险接受度或价值取舍；必须问用户并等待确认。
-- 至少覆盖三个维度：术语、边界、验收。
-- 从问题池中选择下一个未解决问题推进；可以并行整理 evidence-driven 证据，但 `user-interview` 仍然必须 one-at-a-time。
+- evidence-driven 和 user-interview 的推进节奏：先批量查证 evidence-driven 并一次性汇报结论，再逐个处理 user-interview 问题。不要把所有问题攒到最后一起问。
 - 一次只问一个 `user-interview` 问题。
-- 每个 `user-interview` 问题必须等待用户显式回答，并把回答、决策和 OpenSpec 回写状态记录到 `decisions.md`；不能由代理代替用户确认。
-- 未获得用户确认的 `user-interview` 问题必须保持未解决状态，不能进入 Phase 2.9 或 Phase 3。
-- 单个 `user-interview` 的确认只能解除该问题本身的阻塞，不能被解释为进入 Phase 3 或修改执行目标文件的授权。
+- 每个 `user-interview` 问题必须等待用户显式回答，并在 decisions.md 中记录：问题原文、用户原话、确认状态（已确认/未确认）。未确认的问题不能从 question pool 移除。
+- 单个 `user-interview` 的确认只能解除该问题本身的阻塞，不能被解释为进入 apply 或修改执行目标文件的授权。
 - 对接口影响等级、消费者边界或兼容性存在不确定时，必须作为 `user-interview` 问题等待用户确认。
-- 如果澄清结果影响实现，必须回写 OpenSpec proposal/design/specs/tasks。
+- 如果澄清结果影响实现，必须回写 proposal.md。
 - 术语一旦确认，更新 `devflow/glossary/CONTEXT.md`。
 - 对难以逆转、依赖上下文、源自真实权衡的决策创建 ADR。
 
@@ -146,18 +102,63 @@
 - 所有 user-interview 决策已获得用户确认。
 - 没有未解决或代理代确认的 user-interview 问题。
 - 没有未判级或未确认的接口影响问题。
-- 影响实现的结论已回写 OpenSpec。
+- 影响实现的结论已回写 proposal.md。
+- 单个 grill 决策确认不等于 apply 授权；grill 完成后必须停在 commit，等待用户明确要求进入 apply。
 
 **输出**：
-- 澄清记录：默认写入 `decisions.md`；问题很多时可拆出 `clarifications.md`。记录术语、边界、验收三个维度、模式、证据、结论、用户确认状态。
-- 更新后的 OpenSpec。
+- 更新后的 proposal.md。
+- 澄清记录：写入 `decisions.md`。包含 question pool、evidence-driven 汇报状态、user-interview 确认状态。
 - 更新后的词汇表和 ADR。
 
-## Phase 2.5 — 架构审计
+**Human checkpoint**：
+- 汇报已解决和未解决的问题、proposal 变更、术语和 ADR 更新。
+- 询问是否继续进入 specify 细化阶段。
 
-**进入条件**：Phase 2 已解决主要产品、领域和验收问题。
+## specify — 细化 + 对齐
 
-**显式子 skill**：`zoom-out`。进入本阶段必须先声明是否读取 `.agents/skills/zoom-out/SKILL.md`；fallback 必须标记为“架构审计 fallback”。
+**进入条件**：grill 已退出，需求已通过澄清稳定下来。
+
+**显式子 skill**：`openspec-propose`（基于已稳定的 proposal 补全完整 OpenSpec）；`to-prd`（按需生成 PRD）。进入本阶段必须先声明调用方式。
+
+**动作**：
+- 基于已稳定的 proposal.md 补全 design.md、specs/、tasks.md：
+  - 优先调用 `openspec-propose`，输入中明确说明"proposal.md 已存在，本次只需补全 design/specs/tasks"。
+  - 如果不可用，执行 `references/fallbacks.md#openspec-提案-降级`。
+- 如果没有结构化 PRD，按需按 `to-prd` 协议生成 `brief.md`；复杂需求、对外协作或用户明确要求时再生成 `prd.md`。
+- `micro` 模式默认不创建独立 PRD，除非用户要求或需求复杂度升级。
+- 用 grill 阶段的 decisions.md 记录增强 OpenSpec 产物：确保 design/specs/tasks 反映所有已确认的决策。
+- **显式 cross-artifact 对齐检查**——在 checkpoint 中输出对齐检查表：
+  - `brief/prd` 中的目标、范围、非目标和验收预期 → `proposal` 是否覆盖。
+  - `proposal` 中的范围、约束和关键承诺 → `design` 是否覆盖。
+  - `design` 中影响实现的约束、接口影响和架构结论 → `specs` 或 `tasks` 是否覆盖。
+  - `specs` 中的可观察行为 → `tasks` 是否覆盖为可执行切片。
+  - 每项标记：已对齐 / 存在 gap。
+- 检查是否涉及接口影响：
+  - 接口影响分级定义见 `references/operating-rules.md#接口影响分级`。
+  - 是否改变字段、DTO、service 方法、API、事件、回调、数据库契约、命令契约或跨模块调用语义。
+  - 接口内部判断逻辑是否改变调用方可观察行为。
+  - 按 L1/L2/L3/L4 记录接口影响等级；不确定时标记为 `user-interview` 问题。
+- 如果存在 gap，在进入下一阶段前修复 OpenSpec。
+- 如果发现不一致，优先修正 OpenSpec，而不是只修改 devflow 文档。
+
+**退出条件**：
+- `design.md`、`specs/`、`tasks.md` 存在且与 proposal 对齐。
+- `brief.md` 已覆盖背景、目标、范围和非目标；复杂需求存在独立 `prd.md` 或用户明确不需要 PRD。
+- cross-artifact 对齐检查表已生成（4 行，每行标记已对齐/存在 gap），没有未处理 gap。
+- 涉及接口变更时，已记录接口影响等级和产物要求；不确定项已标记。
+- 所有已知冲突已修正或等待用户决策。
+
+**输出**：
+- 完整的 Draft OpenSpec：proposal.md + design.md + specs/ + tasks.md。
+- `brief.md`，以及按需创建的 `prd.md`。
+- cross-artifact 对齐检查表（写入 checkpoint 或 decisions.md）。
+- 必要的 OpenSpec 修正。
+
+## audit — 架构审计
+
+**进入条件**：specify 已退出，完整 OpenSpec 产物已存在。
+
+**显式子 skill**：`zoom-out`。进入本阶段必须先声明是否读取 `.agents/skills/zoom-out/SKILL.md`；降级必须标记为"架构审计降级"。
 
 **动作**：
 - 画出输入 → 处理 → 输出的模块链路。
@@ -165,25 +166,26 @@
 - 检查是否与既有架构、ADR、OpenSpec design 冲突。
 - 用不超过五句话写出架构风险评估。
 - 如果审计结果影响实现，必须回写 OpenSpec design/tasks；只写入 devflow design 不够。
+- 审计结论写入 `decisions.md`。
 
 **退出条件**：
-- 架构风险已被接受，或流程返回 Phase 2/Phase 1 修正 OpenSpec。
+- 架构风险已被接受，或流程返回 grill/specify 修正 OpenSpec。
 - OpenSpec design/tasks 已反映会影响实现的架构审计结论。
 
 **输出**：
-- 架构审计记录，默认写入 `decisions.md` 或 `evidence.md`；复杂架构审计可拆出 `design.md`。
+- 架构审计记录，写入 `decisions.md`；复杂架构审计可拆出 `design.md`。
 - 必要的 OpenSpec design/tasks 修正。
 
 **Human checkpoint**：
 - 用不超过五句话向用户说明架构风险、OpenSpec 修正点和实现计划。
-- 询问是否进入 Phase 2.9 Commit OpenSpec；用户明确要求“全自动执行”时可跳过等待。
+- 询问是否进入 commit。
 
-## Phase 2.9 — Commit OpenSpec
+## commit — Commit OpenSpec
 
 **进入条件**：
-- Phase 2 已解决术语、边界、验收三个维度的高价值问题。
+- grill 已解决术语、边界、验收三个维度的高价值问题。
 - 所有 `user-interview` 问题都已获得用户显式确认。
-- Phase 2.5 架构审计已经完成，或快速模式下已记录跳过原因；快速模式定义见 `references/operating-rules.md#快速模式`。
+- audit 已经完成，或快速模式下已记录跳过原因；快速模式定义见 `references/operating-rules.md#快速模式`。
 - Draft OpenSpec 已回写所有会影响实现的澄清、接口影响和架构审计结论。
 
 **动作**：
@@ -191,48 +193,47 @@
 - 检查 design 是否记录上下文约束、关键技术决策、架构风险和接口影响。
 - 检查 specs 是否表达外部可观察行为，并覆盖验收口径。
 - 检查 tasks 是否是可执行的纵向切片，而不是泛泛描述。
-- 复核 `brief/prd -> proposal -> design -> specs -> tasks` 是否闭环，没有把字段、范围项、验收行为或实现切片丢在上游产物里。
-- 检查 `evidence.md` 和 `decisions.md` 中所有影响实现的发现，是否已回写到 proposal、design、specs 或 tasks。
+- 复核 cross-artifact 对齐：`brief/prd → proposal → design → specs → tasks` 是否闭环，没有把字段、范围项、验收行为或实现切片丢在上游产物里。
+- 检查 `decisions.md` 中所有影响实现的发现，是否已回写到 proposal、design、specs 或 tasks。
 - 接口影响分级定义见 `references/operating-rules.md#接口影响分级`。
-- 检查接口影响是否已按 L1/L2/L3/L4 判级；L3/L4 是否有独立接口文档或等价独立章节。
+- 检查接口影响是否已按 L1/L4 判级；L3/L4 是否有独立接口文档或等价独立章节。
 - 检查没有未汇报的 evidence-driven 结论，没有未确认的 user-interview 问题，没有 devflow/OpenSpec 冲突。
-- 如果检查失败，返回 Phase 1、Phase 2 或 Phase 2.5 修正 Draft OpenSpec。
+- 如果检查失败，返回 propose、grill、specify 或 audit 修正 Draft OpenSpec。
 
 **退出条件**：
 - Draft OpenSpec 已达到可执行状态，并记录为 Committed OpenSpec。
-- Phase 3 所需的 proposal、design、specs 和 tasks 均存在且一致。
-- 所有 Phase 3 preflight 风险已消除或明确记录为已接受。
+- apply 所需的 proposal、design、specs 和 tasks 均存在且一致。
+- 所有 preflight 风险已消除或明确记录为已接受。
 
 **输出**：
 - Committed OpenSpec 状态说明。
-- Phase 3 preflight 检查结果，默认写入 `decisions.md` 或 `acceptance.md`。
+- preflight 检查结果，写入 `decisions.md` 或 `acceptance.md`。
 
 **Human checkpoint**：
 - 用不超过五句话说明 Committed OpenSpec 的范围、接口影响、剩余风险和执行计划。
-- 询问是否进入 Phase 3 OpenSpec apply；除非用户在启动时明确要求“全自动执行”，必须等待用户明确说出进入 apply、开始实现、执行修改、继续 Phase 3 或等价授权。
-- 不得把 Phase 2 的单个 grill 决策确认当作本 checkpoint 的授权。
+- 询问是否进入 apply；除非用户在启动时明确要求"全自动执行"，必须等待用户明确说出进入 apply、开始实现、执行修改或等价授权。
+- 不得把 grill 的单个决策确认当作本 checkpoint 的授权。
 
-## Phase 3 — OpenSpec apply
+## apply — OpenSpec 执行
 
 **进入条件**：
-- `openspec/changes/<slug>/` 中 proposal/design/specs/tasks 已通过 Phase 2.9，成为 Committed OpenSpec。
-- Phase 2.9 后已获得用户明确的 Phase 3 apply 授权，除非用户在启动时要求“全自动执行”。
+- `openspec/changes/{slug}/` 中 proposal/design/specs/tasks 已通过 commit，成为 Committed OpenSpec。
+- commit 后已获得用户明确的 apply 授权，除非用户在启动时要求"全自动执行"。
 - devflow 与 OpenSpec 没有未解决冲突。
 - 没有未解决的 user-interview 问题、未判级接口影响、未汇报 evidence-driven 结论或未接受架构风险。
 
-**显式子 skill**：`openspec-apply-change`；遇到 bug/不确定行为时显式调用 `diagnose`；需要测试驱动时显式调用 `tdd`。进入本阶段必须先声明调用方式，不能静默 fallback。
+**显式子 skill**：`openspec-apply-change`；遇到 bug/不确定行为时显式调用 `diagnose`；需要测试驱动时显式调用 `tdd`。进入本阶段必须先声明调用方式，不能静默降级。
 
 **动作**：
 - 优先调用 `openspec-apply-change`。
 - 执行依据是 OpenSpec specs/tasks；devflow 只能作为上下文参考。
 - 按 OpenSpec tasks 的纵向切片实现。
-- 进入实现前先汇报本阶段的 capability 来源、当前 task 进度和本轮要推进的切片；否则 Phase 3 不算真正开始。
-- 当用户质疑、用户要求修改、代码检查、测试失败或运行行为与 OpenSpec 冲突时，先分类再继续：
-  - 实现偏差：Committed OpenSpec 正确，代码没有按规格做；修代码，不改 OpenSpec。
-  - 规格遗漏：OpenSpec 没覆盖真实边界、接口影响、验收口径或外部可见行为；暂停 apply，修正 OpenSpec 后重新提交。
-  - 设计冲突：OpenSpec 与架构、ADR、历史验收、数据所有权或模块边界冲突；暂停并向用户确认设计方向。
-  - 用户变更：用户改变目标、范围、优先级、验收或风险接受度；更新 proposal/specs/tasks 后再继续。
-- 冲突分类、证据、用户确认和 OpenSpec 回写状态必须记录到 `decisions.md` 或 `acceptance.md`。
+- 进入实现前先汇报本阶段的 capability 来源、当前 task 进度和本轮要推进的切片；否则 apply 不算真正开始。
+- 当用户质疑、用户要求修改、代码检查、测试失败或运行行为与 OpenSpec 冲突时，做三类判断：
+  - OpenSpec 不准（规格遗漏、边界未覆盖、验收口径缺失）→ 暂停 apply，修正 OpenSpec 后重新提交。
+  - 代码偏离（实现没按 OpenSpec 做）→ 修正代码，不改 OpenSpec。
+  - 不确定根因、涉及设计方向、用户改变目标或范围 → 暂停并等待用户确认。
+- 判断结果、证据、用户确认和 OpenSpec 回写状态必须记录到 `decisions.md`。
 - 当用户要求、行为复杂或回归风险高时使用 TDD。
 - 当测试失败、行为意外或原因不确定时使用 diagnose。
 - 如果 diagnose 发现根因是 OpenSpec 不准确，先修正 OpenSpec，再继续 apply。
@@ -247,27 +248,32 @@
 **输出**：
 - 代码变更、必要测试和实现说明。
 - 更新后的 OpenSpec task 状态。
+- 冲突记录写入 `decisions.md`。
 
-## Phase 4 — 回填 Devflow
+## archive — 回填 + 归档
 
 **进入条件**：实现或规划工作已经达到可交接状态。
 
-**显式子 skill**：`openspec-archive-change` 只在用户确认 archive 后调用；Phase 4 回填由 `sm-flow` 执行。必须记录 archive 是真实调用还是手动 fallback。
+**显式子 skill**：`openspec-archive-change` 只在用户确认 archive 后调用；archive 回填由 `sm-flow` 执行。必须记录 archive 是真实调用还是手动降级。
 
 **动作**：
 - 遵循 `references/archive-rules.md`。
-- 从 OpenSpec、实现结果和验证结果提炼 brief、evidence、decisions 和 acceptance；只在复杂场景按需拆出 PRD/research/design/tasks/alignment。
-- 把 Phase 0 到 Phase 3 已经形成的过程内记录整理为最终档案；不要把 Phase 4 当作第一次补写这些记录。
+- 从 `decisions.md`（过程日志）+ OpenSpec 产物提炼完整 devflow 档案：
+  - `brief.md`：从 proposal.md 提取背景、目标、范围、非目标。
+  - `evidence.md`：从 decisions.md 中的 evidence-driven 记录提取。
+  - `decisions.md`：保持为最终版，整理格式。
+  - `acceptance.md`：从实现结果和验证结果提取。
+- 只在复杂场景按需拆出 PRD/research/design/tasks/alignment。
 - 写入或更新验收记录，并区分静态验证、脚本验证、浏览器/人工验证、未验证。
 - 如果本次流程产生可复用经验，写入 compound knowledge。
 - 更新 `devflow/index.md`，记录日期、slug、领域、关键词、关联 OpenSpec 和状态。
 - 询问用户是否要 archive OpenSpec change；不要默认执行归档。
 
 **退出条件**：
-- `devflow/projects/YYYY-MM-DD-{slug}/` 能说明做了什么、为什么做、OpenSpec 如何指导执行、还剩什么、如何验证。
+- `devflow/projects/YYYY-MM-DD-{slug}/` 包含 brief.md、evidence.md、decisions.md、acceptance.md。
 - `devflow/index.md` 已包含或更新本项目条目。
 - 用户已被询问是否 archive OpenSpec change。
 
 **输出**：
-- 默认输出 `brief.md`、`evidence.md`、`decisions.md`、`acceptance.md`；按需输出 `prd.md`、`research.md`、`design.md`、`tasks.md`、`alignment.md`、ADR 和 compound knowledge。
-
+- 完整 devflow 档案。
+- 归档交接清单：创建或更新了哪些文件、验证分类、剩余风险、是否 archive。

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

@@ -51,11 +51,25 @@
 ```markdown
 # {标题} Decisions
 
+## Question Pool
+
+| # | 维度 | 问题 | 模式 | 状态 |
+|---|---|---|---|---|
+| Q1 | 术语 | {question} | evidence-driven / user-interview | 已解决 / 未解决 |
+| Q2 | 边界 | {question} | evidence-driven / user-interview | 已解决 / 未解决 |
+| Q3 | 验收 | {question} | evidence-driven / user-interview | 已解决 / 未解决 |
+
+## Evidence-driven
+
+| 结论 | 证据来源 | 是否已汇报用户 |
+|---|---|---|
+| {conclusion} | {file/doc/test/ADR} | 已汇报 / 待汇报 |
+
 ## User-interview
 
-| 问题 | 用户回答 | 决策 | OpenSpec 回写 |
-| --- | --- | --- | --- |
-| {question} | {answer} | {decision} | 已回写 / 不影响 / 待回写 |
+| 问题原文 | 用户原话 | 确认状态 | OpenSpec 回写 |
+|---|---|---|---|
+| {question} | {user's exact words} | 已确认 / 未确认 | 已回写 / 不影响 / 待回写 |
 
 ## 关键取舍
 
@@ -329,6 +343,26 @@
 - OpenSpec 归档确认：{已询问/用户确认归档/用户暂不归档/不适用}
 ```
 
+## Cross-Artifact 对齐检查表模板
+
+specify 阶段的 checkpoint 必须包含此检查表。每项标记"已对齐"或"存在 gap"。
+
+```markdown
+## Cross-Artifact 对齐检查
+
+| 上游 → 下游 | 检查内容 | 状态 |
+|---|---|---|
+| brief/prd → proposal | 目标、范围、非目标、验收预期是否进入 proposal | 已对齐 / 存在 gap |
+| proposal → design | 范围、约束、关键承诺是否进入 design | 已对齐 / 存在 gap |
+| design → specs/tasks | 影响实现的约束、接口影响、架构结论是否进入 specs 或 tasks | 已对齐 / 存在 gap |
+| specs → tasks | 可观察行为是否被 tasks 覆盖为可执行切片 | 已对齐 / 存在 gap |
+
+### Gap 详情（如有）
+
+- gap 1：{描述哪个字段/约束/行为/切片只停留在上游，未进入下游}
+  - 修复：{如何修正 OpenSpec}
+```
+
 ## 复合知识模板
 
 ```markdown