upgrade sm-flow v3.1 workflow

devflow/projects/2026-05-21-sm-flow-v3-1-upgrade/evidence.md

@@ -0,0 +1,28 @@
+# SM Flow v3.1 Upgrade Evidence
+
+## 证据
+
+| 来源 | 证据 | 结论 | 是否已汇报 |
+| --- | --- | --- | --- |
+| `skill-workbench/docs/sm-flow/使用问题.md` | 用户列出 6 个实践问题，包含接口文档、propose/grill 顺序、devflow 检索、子 skill 兼容、Phase 3 设计冲突。 | v3.1 应围绕这些使用摩擦改协议，而不是重写整个流程。 | 是 |
+| `.agents/skills/sm-flow/SKILL.md` | 当前核心规则已要求 Phase 0.5、Phase 2、Phase 2.5、Phase 3、Phase 4，但没有 Draft/Committed OpenSpec 和接口影响分级。 | 新规则应补 gate，不应推翻 v3 的 OpenSpec-first 主从关系。 | 是 |
+| `.agents/skills/sm-flow/references/phase-contracts.md` | Phase 1 生成 OpenSpec 后进入 Phase 1.5/2/2.5，Phase 3 以 OpenSpec 执行；缺少 Phase 2.9 提交检查。 | “propose 后 grill 返工”应通过草稿/提交分离解释和治理。 | 是 |
+| `.agents/skills/sm-flow/references/fallbacks.md` | 执行 fallback 已要求失败原因不确定时 diagnose，规格不准先修 OpenSpec。 | 可扩展为 Phase 3 实现期冲突分类，不需要新建完全独立流程。 | 是 |
+| `devflow/projects/2026-05-19-dev-flow-skill-evaluation/dev-flow-skill-evaluation.md` | 历史评估已指出 Claude 工具耦合、子 skill 调用方式不稳、Phase 退出条件不足。 | v3.1 的兼容规则应绑定能力契约，而不是绑定具体平台路径。 | 是 |
+
+## Evidence-driven 结论
+
+- 结论：v3.1 应保留 v3 主轴，只增加 gate 和分级规则。
+  - 证据：当前 skill 文件和 phase contracts 已经清楚表达 OpenSpec-first。
+  - 风险：如果重写阶段顺序，容易引入新的执行歧义。
+  - 用户确认：已通过“开始这次的 v3.1 改造”确认推进。
+
+- 结论：接口文档应分级，不应一刀切。
+  - 证据：用户同时提出“接口影响范围文档”和“接口文档”，说明需要区分影响记录与独立文档。
+  - 风险：分级阈值不清会导致代理低估外部契约风险。
+  - 用户确认：需要在实现时以不确定则确认为规则。
+
+- 结论：Phase 3 应增加实现期沟通规则，而不是让代码建议直接覆盖 OpenSpec。
+  - 证据：用户明确要求“不要全部接收代码建议，而是向我确认是设计冲突，还是没有考虑到”。
+  - 风险：沟通 gate 会暂停执行，但能保护规格真理源。
+  - 用户确认：已确认这是 v3.1 重点。