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？
-
-