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/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. 额外记录当前行为切片的测试状态。
-