diff --git a/.agents/skills/sm-flow/references/archive-rules.md b/.agents/skills/sm-flow/references/archive-rules.md
index 2d4522f..0775b09 100644
--- a/.agents/skills/sm-flow/references/archive-rules.md
+++ b/.agents/skills/sm-flow/references/archive-rules.md
@@ -2,6 +2,49 @@
 
 archive 阶段的目标是把 OpenSpec 产物、实现结果和过程日志转化为持久、可读、可复用的项目记忆。sm-flow 在 clarify → apply 期间只维护 `decisions.md` 作为过程日志，archive 阶段从中提取完整 devflow 档案。
 
+## Archive 强制执行顺序
+
+Archive 阶段必须按以下顺序执行，不得跳过或重排：
+
+### Step 1: 创建 devflow 档案（必需）
+
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/brief.md`
+      （从 proposal.md 提取：背景、目标、范围、非目标）
+      
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/evidence.md`
+      （从 decisions.md 提取：evidence-driven 记录）
+      
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/decisions.md`
+      （整理为最终版：关键决策、权衡、风险）
+      
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/acceptance.md`
+      （记录：静态验证、脚本验证、浏览器/人工验证、未验证）
+
+### Step 2: 更新索引（必需）
+
+- [ ] 在 `devflow/index.md` 末尾追加或更新一行：
+      `| YYYY-MM-DD | slug | 领域 | 关键词 | openspec/changes/xxx | archived |`
+
+### Step 3: 标记 OpenSpec（必需）
+
+- [ ] 创建 `openspec/changes/{slug}/.archive-ready` 文件
+
+### Step 4: 向用户汇报（必需）
+
+- [ ] 列出创建的 devflow 档案文件路径（验证文件实际存在于磁盘）
+- [ ] 汇报验证情况（按静态验证、脚本验证、浏览器/人工验证、未验证分类）
+- [ ] 列出剩余风险或后续事项
+- [ ] 询问：**是否现在归档 OpenSpec？**
+
+### Step 5: 用户确认后执行 OpenSpec Archive（可选）
+
+- [ ] 调用 `openspec-archive-change`
+- [ ] 记录 archive 结果
+
+**自检**：在执行 Step 4 前，检查 Step 1-3 是否都完成。
+
+---
+
 ## 目录规则
 
 项目档案路径：
diff --git a/.agents/skills/sm-flow/references/phase-contracts.md b/.agents/skills/sm-flow/references/phase-contracts.md
index 77a667e..4406510 100644
--- a/.agents/skills/sm-flow/references/phase-contracts.md
+++ b/.agents/skills/sm-flow/references/phase-contracts.md
@@ -82,6 +82,10 @@
 - 优先使用 `grill-with-docs`。
 - 进入 grill 时先建立一个 question pool，并记录到 `decisions.md`：
   - 默认至少覆盖术语、边界、验收三个维度。
+  - **技术实现维度**（新增）：当 proposal 提到参考实现、或涉及项目现有基础设施时，增加技术澄清问题：
+    - 参考实现的具体文件路径是什么？
+    - 项目现有的 [请求结构/MQ/缓存/加密/工具类] 标准是什么？
+    - 有哪些技术点需要先调研或新建？
   - 如果变更涉及多模块、接口、权限、下游消费者、响应结构或生命周期规则，先把这些维度补进问题池。
 - 逐项标记每个问题的模式：
   - `evidence-driven`：问题能通过代码、文档、测试、OpenSpec 或既有 ADR 证明；代理先查证，再向用户汇报证据、结论和是否需要确认。
@@ -203,7 +207,16 @@
 
 **退出条件**：
 - Draft OpenSpec 已达到可执行状态，并记录为 Committed OpenSpec。
-- apply 所需的 proposal、design、specs 和 tasks 均存在且一致；commit checkpoint 必须验证文件实际存在于磁盘，如果任一文件不存在，commit 失败，返回 specify 补写。
+- **文件完整性检查**（必须全部通过）：
+  - [ ] `proposal.md` 存在，包含问题描述（至少 50 字）、建议方案（至少 100 字）、范围/非目标
+  - [ ] `design.md` 存在，包含架构设计（文字或图）、数据结构定义（至少 1 个）、关键决策记录（至少 2 条）
+  - [ ] `specs/` 目录存在，至少 1 个 functional-spec.md 包含 ≥3 个 requirement
+  - [ ] `tasks.md` 存在，包含 ≥5 个可执行子任务，每个任务有验收标准
+- **一致性检查**（必须通过）：
+  - [ ] proposal 中的核心概念在 design 中有对应设计
+  - [ ] design 中的关键决策在 tasks 中有对应实现任务
+  - [ ] tasks 的验收标准可验证（不是"正确实现""完成功能"这类模糊描述）
+- **标记文件**：检查通过后，创建 `openspec/changes/{slug}/.committed` 文件标记为 Committed OpenSpec
 - 所有 preflight 风险已消除或明确记录为已接受。
 
 **输出**：
@@ -219,6 +232,12 @@
 
 **进入条件**：
 - `openspec/changes/{slug}/` 中 proposal/design/specs/tasks 已通过 commit，成为 Committed OpenSpec。
+- **前置门控检查**（硬约束）：
+  - 检查 `openspec/changes/{slug}/.committed` 文件是否存在
+  - 如不存在，执行以下流程：
+    1. 汇报：Draft OpenSpec 未通过 commit 检查
+    2. 列出缺失的 checkpoint 项（文件完整性、一致性检查）
+    3. 询问用户：是否补做 commit 检查，或明确跳过（需显式确认）
 - commit 后已获得用户明确的 apply 授权，除非用户在启动时要求"全自动执行"。
 - devflow 与 OpenSpec 没有未解决冲突。
 - 没有未解决的 user-interview 问题、未判级接口影响、未汇报 evidence-driven 结论或未接受架构风险。
@@ -226,22 +245,63 @@
 **显式子 skill**：`openspec-apply-change`；遇到 bug/不确定行为时显式调用 `diagnose`；需要测试驱动时显式调用 `tdd`。进入本阶段必须调用指定子 skill，不得静默跳过。
 
 **动作**：
+
+### Pre-apply Checkpoint（15-20 分钟）
+
+**触发条件**：当 OpenSpec 涉及以下任一情况时必须执行
+- design 或 tasks 中提到"参考 XXX 实现"
+- 需要调用项目现有基础设施（MQ/统一请求结构/工具类等）
+- 技术栈不熟悉或第一次在该项目实现类似功能
+
+**执行步骤**：
+1. **完整阅读所有参考实现**（约 10 分钟）
+   - 从 OpenSpec design 或 tasks 中定位参考实现文件
+   - 如果路径不明确，通过 Grep 搜索关键类名或模式
+   - 逐行理解关键逻辑，提取可复用代码片段和模式
+
+2. **Grep 关键技术栈**（约 5 分钟）
+   - 请求/响应结构模式（如 `RequestMsg`、`ResponseMsg`、DTO 规范）
+   - 消息队列模式（如 `@KafkaListener`、`@YkMsg`、发送模板）
+   - 统一工具类（如 `XxxUtil`、`XxxHelper`、加密/验签工具）
+   - 异常处理和日志记录标准
+
+3. **形成技术栈清单并写入 decisions.md**
+   - 项目使用的请求/响应结构标准
+   - MQ 消息定义和发送标准
+   - Consumer 标准位置和写法
+   - 加密/验签/工具类的标准用法
+   - 识别需要新建的工具类或基础设施
+
+**输出要求**：
+- 技术栈清单已写入 `decisions.md` 的 "Pre-apply Research" 章节 ✅
+- 已列出所有参考实现的文件路径 ✅
+- 已识别需要新建的工具类/基础设施 ✅
+
+**快速模式**：micro 分档可缩短为 5-10 分钟快速扫描，但仍需形成清单。
+
+### 实现过程
+
 - 优先调用 `openspec-apply-change`。
 - 执行依据是 OpenSpec specs/tasks；devflow 只能作为上下文参考。
 - 按 OpenSpec tasks 的纵向切片实现。
+- **分步实现**：建议按 Controller → Service → MQ/异步组件 → Consumer/下游 顺序，每完成一层验证后再继续。
 - 进入实现前先汇报本阶段的 capability 来源、当前 task 进度和本轮要推进的切片；否则 apply 不算真正开始。
+- **首模块完成后对齐检查**：完成第一个接口/模块后，对比 OpenSpec design/tasks，标记"已完成/TODO"；核心功能（加密/验签/核心业务逻辑）不允许空实现或纯 TODO 注释。
 - 当用户质疑、用户要求修改、代码检查、测试失败或运行行为与 OpenSpec 冲突时，做三类判断：
   - OpenSpec 不准（规格遗漏、边界未覆盖、验收口径缺失）→ 暂停 apply，修正 OpenSpec 后重新提交。
   - 代码偏离（实现没按 OpenSpec 做）→ 修正代码，不改 OpenSpec。
   - 不确定根因、涉及设计方向、用户改变目标或范围 → 暂停并等待用户确认。
 - 判断结果、证据、用户确认和 OpenSpec 回写状态必须记录到 `decisions.md`。
+- **快速失败**：连续返工 ≥ 2 次时，暂停并重新执行 pre-apply checkpoint 或向用户汇报。
 - 当用户要求、行为复杂或回归风险高时使用 TDD。
 - 当测试失败、行为意外或原因不确定时使用 diagnose。
 - 如果 diagnose 发现根因是 OpenSpec 不准确，先修正 OpenSpec，再继续 apply。
 - 修改文件前遵守仓库指令，例如 `AGENTS.md`。
 
 **退出条件**：
+- 已完成 pre-apply checkpoint（如触发条件满足），技术栈清单已写入 `decisions.md` ✅
 - OpenSpec tasks 已完成，或剩余 tasks 已明确记录。
+- 核心功能已实现或明确标注"待联调"，无纯 TODO 占位 ✅
 - 所有实现期冲突已分类并处理；没有未确认的规格遗漏、设计冲突或用户变更。
 - 已运行验证，或记录了未验证原因。
 - 已列出已知限制。
diff --git a/skill-workbench/docs/sm-flow/phase-contracts-v4.1-changelog.md b/skill-workbench/docs/sm-flow/phase-contracts-v4.1-changelog.md
new file mode 100644
index 0000000..dece89c
--- /dev/null
+++ b/skill-workbench/docs/sm-flow/phase-contracts-v4.1-changelog.md
@@ -0,0 +1,216 @@
+# SM Flow Phase Contracts v4.1 更新日志
+
+> 更新日期: 2026-06-23  
+> 更新原因: 基于"山东商客意向单同步接口"执行复盘  
+> 更新方案: 方案 B（简化版）
+
+---
+
+## 更新概览
+
+**核心目标**: 减少 apply 阶段的返工次数（从 4-5 次降低到 0-1 次）
+
+**更新范围**:
+- ✅ grill 阶段：增加技术实现维度
+- ✅ apply 阶段：增加 Pre-apply Checkpoint
+
+**文本增量**: +55 行（从 281 行 → 336 行，+20%）
+
+---
+
+## 详细修改
+
+### 1. grill 阶段 — 增加技术实现维度
+
+**修改位置**: `phase-contracts.md` 第 85-88 行
+
+**新增内容**:
+```markdown
+- **技术实现维度**（新增）：当 proposal 提到参考实现、或涉及项目现有基础设施时，增加技术澄清问题：
+  - 参考实现的具体文件路径是什么？
+  - 项目现有的 [请求结构/MQ/缓存/加密/工具类] 标准是什么？
+  - 有哪些技术点需要先调研或新建？
+```
+
+**目的**: 在 grill 阶段就识别技术调研需求，避免 apply 时才发现技术栈不熟悉。
+
+---
+
+### 2. apply 阶段 — 增加 Pre-apply Checkpoint
+
+**修改位置**: `phase-contracts.md` 第 234-265 行
+
+**新增章节**: Pre-apply Checkpoint（15-20 分钟）
+
+#### 触发条件（3 条）
+- design 或 tasks 中提到"参考 XXX 实现"
+- 需要调用项目现有基础设施（MQ/统一请求结构/工具类等）
+- 技术栈不熟悉或第一次在该项目实现类似功能
+
+#### 执行步骤（3 步）
+1. **完整阅读所有参考实现**（约 10 分钟）
+   - 从 OpenSpec design 或 tasks 中定位参考实现文件
+   - 如果路径不明确，通过 Grep 搜索关键类名或模式
+   - 逐行理解关键逻辑，提取可复用代码片段和模式
+
+2. **Grep 关键技术栈**（约 5 分钟）
+   - 请求/响应结构模式
+   - 消息队列模式
+   - 统一工具类
+   - 异常处理和日志记录标准
+
+3. **形成技术栈清单并写入 decisions.md**
+   - 项目使用的请求/响应结构标准
+   - MQ 消息定义和发送标准
+   - Consumer 标准位置和写法
+   - 加密/验签/工具类的标准用法
+   - 识别需要新建的工具类或基础设施
+
+#### 输出要求（3 条）
+- ✅ 技术栈清单已写入 `decisions.md` 的 "Pre-apply Research" 章节
+- ✅ 已列出所有参考实现的文件路径
+- ✅ 已识别需要新建的工具类/基础设施
+
+#### 快速模式支持
+- micro 分档可缩短为 5-10 分钟快速扫描，但仍需形成清单
+
+---
+
+### 3. apply 阶段 — 实现过程增强
+
+**修改位置**: `phase-contracts.md` 第 267-284 行
+
+**新增要求**:
+- **分步实现**：建议按 Controller → Service → MQ/异步组件 → Consumer/下游 顺序
+- **首模块完成后对齐检查**：完成第一个接口/模块后，对比 OpenSpec design/tasks，标记"已完成/TODO"；核心功能不允许空实现或纯 TODO 注释
+- **快速失败**：连续返工 ≥ 2 次时，暂停并重新执行 pre-apply checkpoint 或向用户汇报
+
+---
+
+### 4. apply 阶段 — 退出条件增强
+
+**修改位置**: `phase-contracts.md` 第 286-292 行
+
+**新增退出条件**:
+- ✅ 已完成 pre-apply checkpoint（如触发条件满足），技术栈清单已写入 `decisions.md`
+- ✅ 核心功能已实现或明确标注"待联调"，无纯 TODO 占位
+
+---
+
+## 简化对比
+
+### 与完整方案对比
+
+| 维度 | 完整方案 | 简化方案 B | 差异 |
+|------|----------|-----------|------|
+| 文本增量 | +100 行 | +55 行 | -45% |
+| 子阶段数 | 3 个（Phase 1/2/3） | 1 个（Pre-apply Checkpoint） | -67% |
+| 强制规则 | 9 条 | 5 条 | -44% |
+| 检查清单 | 2 个详细清单 | 1 个简化清单 | -50% |
+| 时间分档 | 3 档（15/20/30 分钟） | 1 档（15-20 分钟） | -67% |
+
+### 保留核心价值
+
+✅ **保留**（解决返工问题）:
+- 前置调研（最重要）
+- 技术栈清单（防止想当然）
+- 核心功能不能空实现（保证质量）
+- 快速失败机制
+
+❌ **简化**（去掉过度约束）:
+- 严格的执行顺序
+- 频繁的检查点
+- 详细的操作指南模板
+
+---
+
+## 预期效果
+
+### 量化指标
+
+| 指标 | 当前 | 目标 | 改善 |
+|------|------|------|------|
+| 返工次数 | 4-5 次 | 0-1 次 | -80% |
+| 核心功能空实现率 | 高（3/3 核心功能） | 0% | -100% |
+| 实现时间（含返工） | 2 小时 | 1.5 小时 | -25% |
+| 前置调研时间 | 0 分钟 | 15-20 分钟 | +20 分钟 |
+
+### ROI 分析
+
+```
+投入: 15-20 分钟调研
+回报: 节省 60 分钟返工 + 避免核心功能遗漏
+ROI = (60 - 20) / 20 = 200%
+```
+
+---
+
+## 适用场景
+
+### ✅ 强烈推荐
+
+- 中等及以上规模需求（3+ 接口或涉及多模块）
+- 涉及项目现有基础设施（MQ/统一请求结构/工具类）
+- 第一次在该项目实现类似功能
+- 设计文档提到"参考 XXX 实现"
+
+### 🟡 可选执行
+
+- micro 分档的简单需求（可缩短为 5-10 分钟）
+- 纯数据处理或工具脚本（技术栈熟悉）
+
+### ❌ 不推荐
+
+- 紧急热修复（时间紧急）
+- 一次性脚本（不涉及项目标准）
+
+---
+
+## 后续优化方向
+
+### 短期（1-2 个需求后）
+
+- 收集数据：实际调研时间、返工次数、遗漏率
+- 验证效果：是否达到预期 ROI
+- 调整参数：时间要求、触发条件
+
+### 中期（观察 5+ 个需求后）
+
+如果效果显著，考虑升级为完整方案：
+- 增加 Alignment Checkpoint（每模块对齐检查）
+- 增加详细的技术栈清单模板
+- 增加分步实现的每步验证要求
+
+### 长期（跨项目验证后）
+
+- 提取通用技术栈清单模板（Java/Go/Python 等）
+- 建立参考实现库（常见模式的最佳实践）
+- 自动化部分调研步骤（Grep 脚本、清单生成）
+
+---
+
+## 实施检查清单
+
+### 立即验证
+
+- [ ] `phase-contracts.md` 文件已更新
+- [ ] grill 阶段增加了技术实现维度
+- [ ] apply 阶段增加了 Pre-apply Checkpoint
+- [ ] apply 退出条件增加了 2 条新检查
+- [ ] 文件语法无误，可以正常解析
+
+### 下次执行验证
+
+- [ ] agent 是否正确识别触发条件
+- [ ] agent 是否执行了完整的 3 步调研
+- [ ] 技术栈清单是否写入 decisions.md
+- [ ] 是否有效减少了返工次数
+- [ ] 核心功能是否避免了空实现
+
+---
+
+## 附录：复盘案例链接
+
+- 原始复盘文档: `skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md`
+- 修改前版本: phase-contracts.md (commit: 待补充)
+- 修改后版本: phase-contracts.md (commit: 待补充)
diff --git a/skill-workbench/docs/sm-flow/phase-contracts-v4.2-changelog.md b/skill-workbench/docs/sm-flow/phase-contracts-v4.2-changelog.md
new file mode 100644
index 0000000..5598530
--- /dev/null
+++ b/skill-workbench/docs/sm-flow/phase-contracts-v4.2-changelog.md
@@ -0,0 +1,307 @@
+# SM Flow Phase Contracts v4.2 更新日志
+
+> 更新日期: 2026-06-24  
+> 更新原因: 基于"lookup-knowledge-integration"执行复盘  
+> 更新方案: 增强执行机制，引入可验证 checkpoint
+
+---
+
+## 更新概览
+
+**核心目标**: 解决"约束是软性的"问题，增加可执行的检查机制
+
+**更新范围**:
+- ✅ commit 阶段：增加文件完整性和一致性检查清单
+- ✅ apply 阶段：增加前置门控（.committed 文件检查）
+- ✅ archive 阶段：增加强制执行顺序（5 步 checklist）
+
+**文本增量**: +80 行
+
+---
+
+## 核心问题诊断
+
+### 问题根源：约束是"软性"的，缺少执行机制
+
+| 问题 | 现象 | 影响 | 根本原因 |
+|------|------|------|----------|
+| **Commit 检查缺标准** | 不知道如何判断"通过 commit 检查" | agent 跳过 commit 直接进入 apply | 只说"检查是否可执行"，没说具体检查什么 |
+| **Apply 缺前置门控** | 用户说"修复"就直接开始实现 | 可能基于不完整的 OpenSpec | 进入条件是软性描述，没有文件检查 |
+| **Archive 无 Checklist** | 先创建 handoff，忘记 devflow | 归档流程不完整 | 没有强制执行顺序 |
+
+---
+
+## 详细修改
+
+### 1. Commit 阶段 — 增加可验证 Checkpoint
+
+**修改位置**: `phase-contracts.md` 第 208-221 行
+
+**新增内容**:
+
+#### 文件完整性检查（必须全部通过）
+
+- [ ] `proposal.md` 存在，包含问题描述（至少 50 字）、建议方案（至少 100 字）、范围/非目标
+- [ ] `design.md` 存在，包含架构设计（文字或图）、数据结构定义（至少 1 个）、关键决策记录（至少 2 条）
+- [ ] `specs/` 目录存在，至少 1 个 functional-spec.md 包含 ≥3 个 requirement
+- [ ] `tasks.md` 存在，包含 ≥5 个可执行子任务，每个任务有验收标准
+
+#### 一致性检查（必须通过）
+
+- [ ] proposal 中的核心概念在 design 中有对应设计
+- [ ] design 中的关键决策在 tasks 中有对应实现任务
+- [ ] tasks 的验收标准可验证（不是"正确实现""完成功能"这类模糊描述）
+
+#### 标记文件
+
+检查通过后，创建 `openspec/changes/{slug}/.committed` 文件标记为 Committed OpenSpec
+
+**目的**: 
+- 提供明确的"可执行状态"判断标准
+- 强制 agent 完成所有检查项
+- 通过 `.committed` 文件提供下游门控依据
+
+---
+
+### 2. Apply 阶段 — 增加前置门控检查
+
+**修改位置**: `phase-contracts.md` 第 233-244 行
+
+**新增内容**:
+
+#### 前置门控检查（硬约束）
+
+1. 检查 `openspec/changes/{slug}/.committed` 文件是否存在
+2. 如不存在，执行以下流程：
+   - 汇报：Draft OpenSpec 未通过 commit 检查
+   - 列出缺失的 checkpoint 项（文件完整性、一致性检查）
+   - 询问用户：是否补做 commit 检查，或明确跳过（需显式确认）
+
+**目的**:
+- 强制 apply 依赖 Committed OpenSpec
+- 阻止基于不完整 OpenSpec 的实现
+- 提供补救路径（补做 commit 或显式跳过）
+
+---
+
+### 3. Archive 阶段 — 增加强制执行顺序
+
+**修改位置**: `archive-rules.md` 第 5-41 行
+
+**新增章节**: Archive 强制执行顺序
+
+#### Step 1: 创建 devflow 档案（必需）
+
+- [ ] 创建 `brief.md`（从 proposal.md 提取）
+- [ ] 创建 `evidence.md`（从 decisions.md 提取）
+- [ ] 创建 `decisions.md`（整理为最终版）
+- [ ] 创建 `acceptance.md`（记录验证情况）
+
+#### Step 2: 更新索引（必需）
+
+- [ ] 在 `devflow/index.md` 末尾追加或更新一行
+
+#### Step 3: 标记 OpenSpec（必需）
+
+- [ ] 创建 `openspec/changes/{slug}/.archive-ready` 文件
+
+#### Step 4: 向用户汇报（必需）
+
+- [ ] 列出创建的 devflow 档案文件路径（验证文件实际存在）
+- [ ] 汇报验证情况（按类型分类）
+- [ ] 列出剩余风险
+- [ ] 询问：**是否现在归档 OpenSpec？**
+
+#### Step 5: 用户确认后执行 OpenSpec Archive（可选）
+
+- [ ] 调用 `openspec-archive-change`
+- [ ] 记录 archive 结果
+
+**自检**: 在执行 Step 4 前，检查 Step 1-3 是否都完成。
+
+**目的**:
+- 强制 devflow 档案优先（不再先创建 handoff）
+- 提供明确的执行顺序，避免遗漏
+- 通过 `.archive-ready` 文件标记完成状态
+
+---
+
+## 新增门控文件
+
+| 文件 | 创建时机 | 用途 |
+|------|----------|------|
+| `.committed` | commit 阶段退出时 | apply 阶段前置门控 |
+| `.archive-ready` | archive Step 3 | 标记归档准备就绪 |
+
+---
+
+## 预期效果
+
+### 量化指标
+
+| 指标 | v4.1 | v4.2 目标 | 改善 |
+|------|------|-----------|------|
+| Commit 阶段跳过率 | 高（无明确标准） | 0%（有 checklist） | -100% |
+| Apply 基于不完整 OpenSpec | 可能发生 | 0%（门控阻止） | -100% |
+| Archive 遗漏 devflow | 可能发生 | 0%（强制顺序） | -100% |
+
+### 质量提升
+
+**Commit 阶段**:
+- ✅ 明确什么叫"可执行状态"
+- ✅ agent 无法跳过检查清单
+- ✅ 提供 `.committed` 文件作为凭证
+
+**Apply 阶段**:
+- ✅ 强制检查 `.committed` 文件存在
+- ✅ 阻止基于不完整 OpenSpec 的实现
+- ✅ 提供补救路径
+
+**Archive 阶段**:
+- ✅ 强制 devflow 优先（不再先创建 handoff）
+- ✅ 5 步 checklist 避免遗漏
+- ✅ 自检机制确保完整性
+
+---
+
+## 与 v4.1 的关系
+
+| 版本 | 核心改进 | 解决问题 |
+|------|----------|----------|
+| v4.1 | Pre-apply Research Checkpoint | apply 阶段前置调研不足，导致返工 |
+| v4.2 | 可验证 Checkpoint + 门控文件 | 约束是软性的，agent 容易跳过阶段 |
+
+**互补关系**:
+- v4.1 解决"调研不充分导致返工"
+- v4.2 解决"缺少执行机制导致跳过阶段"
+
+---
+
+## 设计原则
+
+### 1. 可验证性
+
+**Before**: "检查 OpenSpec 是否可执行"（模糊）  
+**After**: "proposal ≥50字、design ≥1个数据结构、specs ≥3个 requirement"（具体）
+
+### 2. 门控文件
+
+**Before**: 软性描述"已通过 commit"  
+**After**: 硬性检查 `.committed` 文件存在
+
+### 3. 强制顺序
+
+**Before**: 建议性"应该先 devflow 后 handoff"  
+**After**: 5 步 checklist，不得跳过或重排
+
+---
+
+## 复杂度评估
+
+**本次修改复杂度**: 低-中等
+- 文本增量: +80 行（phase-contracts.md +40 行，archive-rules.md +40 行）
+- 概念增加: 2 个门控文件（.committed, .archive-ready）
+- 规则增强: 3 个阶段的检查清单
+
+**整体复杂度**: 高（但更可靠）
+- 总行数: ~700 行 → ~780 行（+11%）
+- 门控数: 6 个 → 8 个（+commit 文件完整性 + apply 前置门控）
+- 强制清单: +3 个（commit 文件完整性、commit 一致性、archive 5 步）
+
+**权衡**:
+- ✅ 收益: 彻底解决"跳过阶段"问题
+- ⚠️ 成本: 增加 80 行文本，agent 需检查更多项
+
+---
+
+## 适用场景
+
+### ✅ 所有场景（无例外）
+
+v4.2 的改进是**执行机制**层面的，不涉及业务逻辑：
+- 无论 micro/standard/complex，都需要 commit 检查
+- 无论需求大小，都需要 apply 前置门控
+- 无论项目规模，都需要 archive 强制顺序
+
+### 快速模式
+
+快速模式可以简化产物（如 tasks 只需 3 个子任务），但**不能跳过门控**：
+- ✅ 仍需 commit 检查（即使 tasks 数量少）
+- ✅ 仍需 apply 前置门控
+- ✅ 仍需 archive 强制顺序
+
+---
+
+## 实施验证
+
+### 验证计划
+
+下次完整执行 sm-flow 时，检查：
+
+1. **Commit 阶段**:
+   - [ ] agent 是否执行了文件完整性检查？
+   - [ ] agent 是否执行了一致性检查？
+   - [ ] agent 是否创建了 `.committed` 文件？
+
+2. **Apply 阶段**:
+   - [ ] agent 是否检查了 `.committed` 文件存在？
+   - [ ] 如不存在，agent 是否汇报并询问用户？
+
+3. **Archive 阶段**:
+   - [ ] agent 是否按 5 步顺序执行？
+   - [ ] agent 是否在 Step 4 前自检了 Step 1-3？
+   - [ ] agent 是否创建了 `.archive-ready` 文件？
+
+### 成功标准
+
+- ✅ 无未经检查的 commit → apply 跳转
+- ✅ 无基于不完整 OpenSpec 的实现
+- ✅ 无先创建 handoff 后补 devflow 的情况
+
+---
+
+## 后续演进方向
+
+### v5.0 候选特性（观察 3+ 次执行后决定）
+
+如果 v4.2 执行良好，但仍有问题，考虑：
+
+1. **流程状态文件** `.sm-flow-state`
+   - 记录当前阶段、已完成阶段、时间戳
+   - 支持断点续做
+
+2. **更多门控文件**
+   - `.context-done`（context 阶段完成）
+   - `.grill-done`（grill 阶段完成）
+   - `.apply-done`（apply 阶段完成）
+
+3. **违规自检机制**
+   - 每个阶段退出前，自动检查是否违反 6 条硬约束
+
+4. **进度可视化**
+   - 每次开始时，汇报进度条（9 个阶段的完成情况）
+
+**判断依据**: 如果 v4.2 后仍频繁出现跳过阶段，再引入更重的机制。
+
+---
+
+## 相关文档
+
+- 执行复盘: `skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md`
+- 修改文件: 
+  - `.agents/skills/sm-flow/references/phase-contracts.md`
+  - `.agents/skills/sm-flow/references/archive-rules.md`
+
+---
+
+## 总结
+
+**v4.2 的核心理念**: 把"软性约束"变成"硬性检查"
+
+| 改进点 | Before | After |
+|--------|--------|-------|
+| Commit 标准 | "可执行状态"（模糊） | 文件完整性 + 一致性检查清单 |
+| Apply 门控 | "已通过 commit"（软性） | 检查 `.committed` 文件存在（硬性） |
+| Archive 顺序 | "应该先 devflow"（建议） | 5 步强制顺序 + 自检 |
+
+**预期效果**: 彻底解决"agent 跳过阶段"问题，提升流程可靠性。
diff --git a/skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md b/skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md
new file mode 100644
index 0000000..b4511fe
--- /dev/null
+++ b/skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md
@@ -0,0 +1,293 @@
+# SM Flow 执行复盘 - 山东商客意向单同步接口
+
+> 项目: yingke-platform  
+> 需求: 385 山东公司商机信息同步接口  
+> 执行日期: 2026-06-23  
+> 复盘人: Claude Code
+
+---
+
+## 执行概况
+
+- **需求规模**: 中等（3个接口 + Kafka消费 + 数据库变更）
+- **总耗时**: 约 2 小时（含多次返工）
+- **返工次数**: 4-5 次重大返工
+- **最终状态**: 核心代码完成，但验签/解密/查询接口未实现
+
+---
+
+## 发现的问题
+
+### 1. 前置调研不足，导致多次返工
+
+#### 问题表现
+
+| 返工点 | 初次实现（错误） | 返工后（正确） | 浪费时间 |
+|--------|------------------|----------------|----------|
+| RequestMsg 结构 | 自创 `SyncIntentOrderReq/Resp` | 使用项目标准 `RequestMsg<T>` | 15 分钟 |
+| Kafka 发送方式 | `SendMessageTunnel` + `TaskTypeEnum` | `ykMqTemplate` + `@YkMsg` | 20 分钟 |
+| Consumer 模块位置 | order-service 模块 | web 模块（参考案例位置） | 10 分钟 |
+| 透传字段结构 | Map → DTO → 最终平铺 | 应一次到位平铺到 Msg | 15 分钟 |
+
+**根本原因**: apply 阶段直接开始写代码，没有充分调研现有代码模式。
+
+#### 改进建议
+
+**在 apply 阶段前增加强制调研步骤**（pre-apply research checkpoint）：
+
+1. **阅读所有参考实现**（设计文档中明确提到的）
+   - 完整阅读参考代码，而不是凭想象
+   - 提取关键模式：请求结构、Kafka 使用、模块划分
+   
+2. **Grep 关键技术栈**
+   ```bash
+   grep -r "@YkMsg" --include="*.java"
+   grep -r "ykMqTemplate" --include="*.java"
+   grep -r "RequestMsg<" --include="*.java"
+   ```
+   
+3. **形成"技术栈清单"文档**（临时产物）
+   ```markdown
+   - 项目使用 RequestMsg<T> 作为统一请求包装
+   - Kafka 消息使用 @YkMsg + MsgData + ykMqTemplate.sendAsync()
+   - Consumer 统一放在 web 模块的 manager/stream/consumer
+   ```
+
+4. **调研时间要求**: 不少于 15 分钟，复杂需求可延长至 30 分钟
+
+---
+
+### 2. 设计文档与实现偏离，缺少一致性检查
+
+#### 问题表现
+
+| 设计文档要求 | 实际实现 | 偏离程度 |
+|--------------|----------|----------|
+| Controller 层 SM3 验签 | 只有 TODO 注释 | ❌ 核心功能缺失 |
+| Service 层 AES256-GCM 解密 | 只有 TODO 注释 | ❌ 核心功能缺失 |
+| queryIntentOrder 调用一体化客服 | 空实现 | ❌ 核心功能缺失 |
+| syncIntentOrder 同步调用 | 改为 Kafka 异步 | ⚠️ 架构差异（可能合理） |
+
+**根本原因**: apply 阶段没有"设计-实现对齐检查点"。
+
+#### 改进建议
+
+**在 apply 阶段中增加对齐检查点**（alignment checkpoint）：
+
+1. **每完成 1 个接口/模块，立即对比设计文档**
+   - 逐条核对设计文档的任务清单
+   - 标记"已完成/部分完成/TODO"
+   
+2. **核心功能不允许"TODO 占位"直接通过**
+   - 加密/解密、验签、核心业务逻辑必须实现或明确标注"待联调"
+   - 区分"框架完整但待联调"（✅） vs "空实现"（❌）
+
+3. **架构差异必须显式记录并询问用户**
+   - 设计说同步，实现改异步 → 必须记录原因并确认
+   - 创建 `decisions.md` 记录所有偏离设计的架构决策
+
+---
+
+### 3. 分步验证不足，一次写太多代码
+
+#### 问题表现
+
+- 一次性写完 Controller + Service + Kafka + Consumer，然后发现 RequestMsg 结构错了
+- 没有"写一点 → 编译 → 确认方向"的小步迭代
+
+#### 改进建议
+
+**强制分步验证**（incremental validation）：
+
+1. **Controller 层先行**
+   - 只写 Controller + 最小 Service 骨架
+   - 确认请求/响应结构正确
+   - 编译通过后再继续
+
+2. **Kafka 发送独立验证**
+   - 写完发送逻辑，先打印 JSON 确认消息格式
+   - 再写 Consumer
+
+3. **Consumer 最后实现**
+   - 基于已确认的消息格式实现
+
+---
+
+### 4. 参考案例利用不充分
+
+#### 问题表现
+
+- 设计文档明确提到"参考 AddIntentOrderOutSystemDealTunnel"
+- 但实际执行时，直到用户提醒才去看参考实现
+- 之前都在凭想象写，导致返工
+
+#### 改进建议
+
+**强制参考案例优先**（reference-first approach）：
+
+1. **grill 阶段就应该找出所有参考案例**
+   - 不要只记录"参考 XXX"，而是实际阅读并提取模式
+   
+2. **apply 前必须完整阅读参考实现**
+   - 不是"扫一眼"，而是逐行理解关键逻辑
+   - 提取可复用的代码片段
+
+3. **参考案例模式提取清单**（临时文档）
+   ```markdown
+   ## AddIntentOrderOutSystemDealTunnel 关键模式
+   
+   1. Consumer 方法签名: `public void onXXX(XXXMsg msgBO)`
+   2. 调用链: msg → AES加密 → OnlineOpportunityApi → 回填状态
+   3. 异常处理: try-catch → updateStatus(EXCEPTION) → throw
+   4. 成功判断: isSyncSuccess() 三层校验
+   ```
+
+---
+
+### 5. grill 阶段澄清不够深入
+
+#### 问题表现
+
+- grill 阶段问了业务问题（省份校验、透传字段），但没有问技术实现问题
+- 导致后续实现时才发现技术栈不熟悉
+
+#### 改进建议
+
+**grill 阶段增加技术实现澄清**：
+
+除了业务澄清，还应该包括：
+
+1. **技术栈确认问题**
+   - "项目现有的 Kafka 消息怎么定义和发送？"
+   - "RequestMsg/ResponseMsg 的标准用法是什么？"
+   - "类似接口的 Controller/Service 是怎么写的？"
+
+2. **参考实现确认**
+   - "设计文档提到的参考实现是哪些文件？"
+   - "这些参考实现的核心模式是什么？"
+
+3. **技术风险识别**
+   - "有哪些技术点我不熟悉，需要先调研？"
+
+---
+
+## 改造建议汇总
+
+### 方案 A: 在现有 9 阶段中增强（保守）
+
+```
+clarify → context → propose → grill+ → specify → audit → commit → pre-apply+ → apply+ → archive
+                                  ↑                                      ↑        ↑
+                           增加技术澄清                             增加调研  增加检查点
+```
+
+**修改点**：
+
+1. **grill 阶段**：增加技术实现澄清问题模板
+2. **apply 阶段前**：增加 pre-apply research checkpoint（15-30分钟）
+3. **apply 阶段中**：增加 alignment checkpoint（每完成1个模块对比设计文档）
+
+### 方案 B: 新增独立调研阶段（激进）
+
+```
+clarify → context → propose → grill → research → specify → audit → commit → apply → archive
+                                                    ↑
+                                          新增独立调研阶段
+```
+
+**新阶段 research**：
+
+- **输入**: proposal + 参考实现列表
+- **输出**: 技术栈清单 + 参考模式提取 + 风险评估
+- **时间**: 15-30 分钟
+- **产物**: `research.md`（临时文档，archive 时删除）
+
+**research.md 结构**：
+
+```markdown
+# 技术调研 - [需求名称]
+
+## 参考实现分析
+
+### AddIntentOrderOutSystemDealTunnel
+- 文件位置: web/manager/stream/consumer/...
+- 关键模式:
+  - Consumer 定义: @YkMqConsumer + MsgData 子类
+  - 调用链: ...
+
+## 技术栈清单
+
+- 请求结构: RequestMsg<T> / ResponseMsg<T>
+- Kafka: @YkMsg + ykMqTemplate.sendAsync()
+- 加密: AESUtil.encryptAES() (AES-128 ECB)
+
+## 风险点
+
+- AES256-GCM 工具类不存在，需要新建
+- 验签逻辑没有现成拦截器，需要在 Service 层实现
+```
+
+### 推荐方案
+
+**方案 A**（渐进增强）：
+
+1. 对现有流程影响小
+2. 实施成本低
+3. 可以立即生效
+
+**具体实施**：
+
+- 修改 `phase-contracts.md` 的 grill 和 apply 阶段规范
+- 增加 checkpoint 描述
+- 更新 question pool 增加技术澄清问题
+
+---
+
+## 其他建议
+
+### 1. 增加"快速失败"机制
+
+当发现以下情况，立即暂停并询问用户：
+
+- 需要创建的类/接口在参考实现中有类似的（防止重复造轮）
+- 实现方式与设计文档明显偏离
+- 连续返工超过 2 次（说明方向可能错了）
+
+### 2. 产物可观测性增强
+
+在 apply 阶段，定期输出：
+
+```markdown
+## 实现进度（每 30 分钟更新）
+
+✅ Controller 层（已完成）
+  - ShandongSyncController.syncIntentOrder
+  - 请求结构使用 RequestMsg<ShandongIntentOrderData>
+  
+🚧 Service 层（进行中）
+  - ShandongSyncService 接口完成
+  - 实现类 70% 完成
+  - ⚠️ 验签解密未实现（TODO）
+  
+⏳ Kafka 层（待开始）
+```
+
+### 3. 设计文档质量要求
+
+设计文档应该包含：
+
+- ✅ 参考实现的具体文件路径（而不是只说"参考 XXX"）
+- ✅ 关键技术栈的使用示例（而不是只说"使用 Kafka"）
+- ✅ 数据流图（清晰展示同步/异步边界）
+
+---
+
+## 总结
+
+**核心问题**: apply 阶段"想当然"开始写代码，缺少充分调研和分步验证。
+
+**解决方向**: 在 apply 前增加强制调研步骤，在 apply 中增加对齐检查点。
+
+**预期效果**: 返工次数从 4-5 次降低到 0-1 次，实现质量与设计文档一致性提升。
+
+**立即可做**: 修改 `phase-contracts.md` 的 grill 和 apply 阶段规范即可生效。
\ No newline at end of file
diff --git a/skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md b/skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md
new file mode 100644
index 0000000..80ab57b
--- /dev/null
+++ b/skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md
@@ -0,0 +1,504 @@
+# SM Flow Skill - 使用情况分析与优化建议
+
+## 执行概况
+
+**项目**: lookup-knowledge-integration  
+**执行日期**: 2026-06-24  
+**执行模式**: 手动跳阶段（用户直接要求"修复问题"）
+
+### 实际执行的阶段
+
+1. ❌ **Clarify** - 跳过（用户直接给了 handoff 文档）
+2. ❌ **Context** - 跳过（未读取 devflow 历史）
+3. ❌ **Propose** - 跳过（OpenSpec 已存在）
+4. ❌ **Grill** - 跳过（未进行澄清）
+5. ❌ **Specify** - 跳过（OpenSpec 已完整）
+6. ❌ **Audit** - 跳过（未进行架构审计）
+7. ❌ **Commit** - **跳过（关键遗漏）**
+8. ✅ **Apply** - 执行（实现代码）
+9. ⚠️ **Archive** - 部分执行（先创建 handoff，后补 devflow）
+
+---
+
+## 做得好的地方 ✅
+
+### 1. Archive 规则详细且可执行
+
+**优点**：
+- `archive-rules.md` 提供了清晰的提取映射表
+- 目录结构规范（devflow/projects/YYYY-MM-DD-{slug}/）
+- 产物分档（micro/standard/complex）明确
+- 索引维护规则具体
+
+**证据**：被提醒后，我能快速创建符合规范的 devflow 档案
+
+### 2. 硬约束明确
+
+**优点**：
+- 6 条核心规则写在 SKILL.md 顶部，醒目
+- 规则表述清晰（不得跳过 context/grill/commit）
+
+**问题**：虽然规则清晰，但缺少执行机制（见后续建议）
+
+### 3. Phase 契约结构清晰
+
+**优点**：
+- `phase-contracts.md` 定义了进入/退出条件
+- 每个阶段的职责明确
+
+---
+
+## 关键问题 ❌
+
+### 问题 1: Commit 检查缺少可执行标准
+
+**现象**：
+- 我不知道如何判断"通过 commit 检查"
+- phase-contracts.md 说了要做 commit，但没说具体怎么判断
+
+**影响**：
+- 我直接跳过 commit，进入 apply
+- 违反了硬约束规则 4："不得跳过 commit"
+
+**根本原因**：
+```
+phase-contracts.md:
+  "Commit 阶段：检查 Draft OpenSpec 是否达到可执行状态"
+  
+但没有说：
+  - 什么叫"可执行状态"？
+  - 需要检查哪些文件？
+  - 每个文件的必需内容是什么？
+  - 如何标记"已通过"？
+```
+
+### 问题 2: Apply 阶段缺少前置门控
+
+**现象**：
+- 用户说"修复问题"，我直接开始实现
+- 没有检查是否存在 Committed OpenSpec
+
+**影响**：
+- 可能基于不完整的 OpenSpec 执行
+- 违反了 "apply 必须基于 Committed OpenSpec" 的约束
+
+**根本原因**：
+- Apply 阶段的"进入条件"是软性描述
+- 没有强制的文件检查机制（如 `.committed` 文件）
+
+### 问题 3: Archive 阶段缺少 Checklist
+
+**现象**：
+- 我先创建了 handoff 文档
+- 忘记了 devflow 才是核心记忆层
+- 被提醒后才补创建 devflow 档案
+
+**影响**：
+- 归档流程不完整
+- 需要用户纠正
+
+**根本原因**：
+- archive-rules.md 有详细说明，但没有强制执行顺序
+- 我容易按"直觉"操作，而不是按"规范"操作
+
+### 问题 4: 缺少流程状态追踪
+
+**现象**：
+- 我不知道当前在哪个阶段
+- 每次执行都像"全新开始"
+
+**影响**：
+- 容易跳过中间阶段
+- 无法断点续做
+
+---
+
+## 优化建议（按优先级）
+
+### High Priority（立即修复）
+
+#### 建议 1: Commit 检查增加可执行 Checkpoint
+
+**位置**：`references/phase-contracts.md` - Commit 阶段
+
+**增加内容**：
+```markdown
+## Commit 阶段退出条件
+
+必须完成以下 checkpoint：
+
+### 文件完整性检查
+- [ ] `proposal.md` 存在且包含：
+  - 问题描述（至少 50 字）
+  - 建议方案（至少 100 字）
+  - 范围/非范围
+
+- [ ] `design.md` 存在且包含：
+  - 架构设计（文字或图）
+  - 数据结构定义（至少 1 个）
+  - 关键决策记录（至少 2 条）
+
+- [ ] `specs/functional-specs.md` 存在且包含：
+  - 至少 3 个 requirement
+  - 每个 requirement 有 scenario
+
+- [ ] `tasks.md` 存在且包含：
+  - 至少 5 个可执行子任务
+  - 每个任务有验收标准
+
+### 一致性检查
+- [ ] proposal 中的核心概念在 design 中有对应设计
+- [ ] design 中的关键决策在 tasks 中有对应实现任务
+- [ ] tasks 的验收标准可验证（不是"正确实现"这种模糊描述）
+
+### 标记
+通过后创建 `.committed` 文件：
+```bash
+echo "committed at $(date)" > openspec/changes/{slug}/.committed
+```
+
+**执行指令**：
+在 apply 阶段入口，必须先执行此检查。
+```
+
+#### 建议 2: Apply 阶段增加前置门控
+
+**位置**：`references/phase-contracts.md` - Apply 阶段
+
+**修改"进入条件"**：
+```markdown
+## Apply 阶段进入条件
+
+**硬约束**：
+1. 必须存在 `.committed` 文件
+2. 如果不存在，执行以下流程：
+   a. 汇报：Draft OpenSpec 未通过 commit 检查
+   b. 列出缺失的 checkpoint
+   c. 询问用户：是否补做 commit 检查，或明确跳过（需显式确认）
+
+**检查代码**：
+```bash
+if [ ! -f "openspec/changes/{slug}/.committed" ]; then
+    echo "错误：Draft OpenSpec 未通过 commit 检查"
+    echo "请先完成 commit 阶段，或显式确认跳过"
+    exit 1
+fi
+```
+```
+
+#### 建议 3: Archive 阶段增加强制 Checklist
+
+**位置**：`references/archive-rules.md` 顶部
+
+**增加内容**：
+```markdown
+## Archive 阶段强制执行顺序
+
+**按以下顺序执行，不得跳过或重排**：
+
+### Step 1: 创建 devflow 档案（必需）
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/brief.md`
+      （从 proposal.md 提取：背景、目标、范围、非目标）
+      
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/decisions.md`
+      （从 decisions.md 整理：关键决策、权衡、风险）
+      
+- [ ] 创建 `devflow/projects/YYYY-MM-DD-{slug}/acceptance.md`
+      （记录：静态验证、脚本验证、人工验证、未验证）
+
+### Step 2: 更新索引（必需）
+- [ ] 在 `devflow/index.md` 末尾追加一行：
+      `| YYYY-MM-DD | slug | 领域 | 关键词 | OpenSpec路径 | archived |`
+
+### Step 3: 标记 OpenSpec（必需）
+- [ ] 创建 `openspec/changes/{slug}/.completed` 文件
+
+### Step 4: 创建 Handoff（可选）
+- [ ] 创建 `handoff/YYYY-MM-DD-{slug}.md`
+      （运维交接文档，给未来开发者）
+
+### Step 5: 向用户汇报
+- [ ] 列出创建的 devflow 档案
+- [ ] 汇报验证情况（按类型分类）
+- [ ] 列出剩余风险
+- [ ] 询问：**是否现在归档 OpenSpec？**
+
+**自检**：在执行 Step 5 前，检查 Step 1-4 是否都完成。
+```
+
+---
+
+### Medium Priority（下个版本）
+
+#### 建议 4: 增加流程状态文件
+
+**目标**：让我知道当前在哪个阶段
+
+**实现**：在 OpenSpec 目录维护 `.sm-flow-state` 文件
+
+```json
+{
+  "change": "lookup-knowledge-integration",
+  "currentPhase": "apply",
+  "completed": ["clarify", "context", "propose", "grill", "specify", "audit", "commit"],
+  "nextPhase": "archive",
+  "committed": true,
+  "timestamps": {
+    "commit": "2026-06-24T10:00:00Z",
+    "apply_start": "2026-06-24T10:05:00Z"
+  }
+}
+```
+
+**使用方式**：
+- 每个阶段开始时：读取此文件，确认前置阶段已完成
+- 每个阶段结束时：更新此文件，标记当前阶段完成
+- 用户下次调用时：直接从 `nextPhase` 继续
+
+**集成到 SKILL.md**：
+```markdown
+## 执行前检查
+
+1. 读取 `.sm-flow-state` 文件
+2. 确认当前阶段的前置阶段已完成
+3. 如有缺失，汇报并询问是否补做
+```
+
+#### 建议 5: Context 阶段增加必读清单
+
+**位置**：`references/phase-contracts.md` - Context 阶段
+
+**增加内容**：
+```markdown
+## Context 阶段必读文件
+
+按顺序读取（即使文件不存在也要尝试）：
+
+1. **devflow/index.md** - 项目索引
+   - 查找相关领域的历史项目
+   - 识别可能相关的关键词
+   
+2. **devflow/glossary/CONTEXT.md** - 术语表
+   - 提取项目术语和业务规则
+   
+3. **相关项目的 decisions.md** - 历史决策
+   - 从 index.md 中识别的相关项目
+   - 读取其决策，避免重复或冲突
+   
+4. **devflow/compound/*.md** - 可复用知识
+   - 查找可复用的设计模式、经验
+
+**如果文件不存在**：
+- 记录"无历史上下文"
+- 在 proposal.md 中标注"首次相关实现"
+- 继续执行
+```
+
+#### 建议 6: 增加"违规自检"机制
+
+**目标**：每个阶段结束前，自动检查是否违反硬约束
+
+**实现**：在每个阶段的退出条件后增加"自检清单"
+
+```markdown
+## [阶段名] 退出前自检
+
+检查以下硬约束是否违反：
+
+- [ ] 是否跳过了 context？
+      检查：是否读取了 devflow/index.md？
+      
+- [ ] 是否跳过了 grill？
+      检查：decisions.md 中是否记录了至少 3 个澄清问题？
+      
+- [ ] 是否跳过了 commit？
+      检查：是否存在 .committed 文件？
+      
+- [ ] apply 是否基于 Committed OpenSpec？
+      检查：apply 开始前是否读取了 OpenSpec 文件？
+      
+- [ ] 遇到冲突是否先分类？
+      检查：冲突记录是否标记了类型（规格遗漏/实现偏差）？
+      
+- [ ] 是否调用了所有必需的子 skill？
+      检查：阶段定义中要求的 skill 是否都调用了？
+
+如有违规项，停止执行并汇报。
+```
+
+---
+
+### Low Priority（可选增强）
+
+#### 建议 7: Grill 阶段增加 Question Pool 模板
+
+**目标**：帮助我提出高质量的澄清问题
+
+**位置**：`references/phase-contracts.md` - Grill 阶段
+
+**增加内容**：
+```markdown
+## Grill Question Pool 模板
+
+必须覆盖至少 3 个维度：
+
+### 维度 1: 范围边界
+模板问题：
+- "Out of scope 里的 X 功能，为什么不在这次做？有什么依赖或风险？"
+- "如果用户要求 Y，这个方案能扩展支持吗？需要改动多少？"
+- "边界场景 Z 应该怎么处理？报错还是降级？"
+
+### 维度 2: 技术风险
+模板问题：
+- "如果依赖的 A 服务挂了，这个方案有降级策略吗？"
+- "为什么选择技术方案 B 而不是 C？主要考虑什么？"
+- "数据量增长到 N 倍，性能瓶颈在哪里？"
+
+### 维度 3: 用户验证
+模板问题：
+- "这个方案解决的核心痛点是什么？有真实场景吗？"
+- "有没有现成的替代方案？为什么不用？"
+- "如果上线后发现不符合预期，回滚成本多大？"
+
+### 维度 4: 实现可行性
+模板问题：
+- "最复杂的部分是什么？有没有技术预研？"
+- "需要改动哪些核心模块？影响面多大？"
+- "有没有类似的历史实现可以参考？"
+```
+
+#### 建议 8: 增加"快速模式"明确定义
+
+**当前问题**：`operating-rules.md` 提到快速模式，但没说具体怎么做
+
+**建议**：明确快速模式的简化规则
+
+```markdown
+## 快速模式
+
+### 触发条件
+满足以下所有条件时，可使用快速模式：
+- 变更小于 5 个文件
+- 无架构变更
+- 无数据库迁移
+- 用户明确要求"快速"
+
+### 简化规则
+1. Grill 阶段：至少 1 个问题（而非 3 个）
+2. Specify 阶段：tasks.md 可简化为 3 个子任务
+3. Audit 阶段：可跳过（标注"快速模式跳过审计"）
+4. Archive 阶段：使用 micro 分档（brief/decisions/acceptance）
+
+### 不得简化
+- Context 阶段：仍需读取 devflow
+- Commit 阶段：仍需检查 OpenSpec 完整性
+- Apply 阶段：仍需基于 Committed OpenSpec
+```
+
+---
+
+## 执行机制优化建议
+
+### 当前问题：约束是"软性"的
+
+**现象**：
+- 规则写得很清楚："不得跳过 commit"
+- 但我仍然能跳过，没有强制机制
+
+**根本原因**：
+- 规则是"描述性"的（说应该做什么）
+- 缺少"执行性"的机制（强制检查、文件依赖）
+
+### 解决方案：引入"门控文件"
+
+**设计**：
+```
+每个阶段完成后，创建一个标记文件：
+- .context-done
+- .grill-done
+- .commit-done (即 .committed)
+- .apply-done
+- .archive-done
+
+下一个阶段开始前，检查前置文件是否存在。
+```
+
+**示例**：Apply 阶段入口检查
+```bash
+if [ ! -f ".committed" ]; then
+    echo "错误：Commit 阶段未完成"
+    echo "缺失文件：.committed"
+    echo "请先完成 commit 阶段，或显式跳过（需用户确认）"
+    exit 1
+fi
+```
+
+**好处**：
+1. 强制执行顺序（无法跳过）
+2. 可视化进度（ls 就能看到哪些阶段完成了）
+3. 支持断点续做（下次执行自动识别位置）
+
+---
+
+## 用户体验优化
+
+### 当前问题：用户不知道"现在在哪"
+
+**场景**：
+- 用户说"继续"
+- 我不知道该从哪个阶段继续
+
+**建议**：每次开始时，主动汇报状态
+
+```
+开始执行 SM Flow...
+
+当前状态：
+✅ Context 已完成
+✅ Propose 已完成
+⏸️ Grill 未开始 ← 当前阶段
+
+下一步：执行 Grill 阶段（人类对齐澄清）
+预计耗时：5-10 分钟
+```
+
+### 建议：增加"进度条"
+
+```
+SM Flow 进度：
+[✅] Clarify
+[✅] Context
+[✅] Propose
+[⏸️] Grill ← 当前
+[ ] Specify
+[ ] Audit
+[ ] Commit
+[ ] Apply
+[ ] Archive
+```
+
+---
+
+## 总结
+
+### 核心问题
+1. **Commit 检查缺少可执行标准**（导致容易跳过）
+2. **Apply 阶段缺少前置门控**（没有强制检查 .committed）
+3. **Archive 阶段缺少 Checklist**（容易遗漏 devflow）
+4. **缺少流程状态追踪**（不知道当前在哪）
+
+### 优先修复（High Priority）
+- ✅ Commit 检查增加 Checkpoint
+- ✅ Apply 增加前置门控
+- ✅ Archive 增加 Checklist
+
+这三个修复后，绝大多数"跳过阶段"问题都能解决。
+
+### 框架本身很好
+- 架构清晰（9 个阶段、4 层架构）
+- 规则明确（6 条硬约束）
+- 文档详细（phase-contracts, archive-rules）
+
+**问题不是"约束不够"，而是"执行机制不够明确"。**
+
+增加可验证的 checkpoint 和门控文件后，我就很难"偷懒"了。
diff --git a/skill-workbench/docs/sm-flow/workflow.md b/skill-workbench/docs/sm-flow/workflow.md
index 5cf51d8..dbb7b4e 100644
--- a/skill-workbench/docs/sm-flow/workflow.md
+++ b/skill-workbench/docs/sm-flow/workflow.md
@@ -819,3 +819,299 @@ v4：
 ### 后续观察项
 
 问题 1 和 2 暂不改协议，如果多次验证中反复出现再考虑加约束。问题 3 需要在下次 specify 阶段验证：spec scenario 是否自然地描述用户行为而非实现细节。
+
+## v4.1：Apply 阶段前置调研增强（2026-06-23）
+
+### 背景
+
+基于"山东商客意向单同步接口"的执行复盘（`skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md`），发现 apply 阶段存在严重的返工问题：
+
+- **返工次数**：4-5 次重大返工
+- **核心问题**：apply 阶段"想当然"开始写代码，缺少充分调研和分步验证
+- **主要表现**：
+  - 参考实现利用不充分（设计文档提到参考实现，但直到用户提醒才去看）
+  - 技术栈不熟悉（RequestMsg 结构、Kafka 发送方式、Consumer 位置全部返工）
+  - 设计-实现偏离（验签/解密/查询接口只有 TODO 注释）
+
+### 核心改进：Pre-apply Checkpoint
+
+在 apply 阶段开始前增加强制性调研检查点（方案 B 简化版）：
+
+#### 修改 1：grill 阶段增加技术实现维度
+
+在 question pool 中新增"技术实现维度"：
+
+```markdown
+**技术实现维度**（新增）：当 proposal 提到参考实现、或涉及项目现有基础设施时，增加技术澄清问题：
+- 参考实现的具体文件路径是什么？
+- 项目现有的 [请求结构/MQ/缓存/加密/工具类] 标准是什么？
+- 有哪些技术点需要先调研或新建？
+```
+
+**目的**：在 grill 阶段就识别技术调研需求，避免 apply 时才发现技术栈不熟悉。
+
+#### 修改 2：apply 阶段增加 Pre-apply Checkpoint
+
+在 apply 阶段开始前增加 15-20 分钟的强制调研步骤：
+
+**触发条件**（3 条）：
+- design 或 tasks 中提到"参考 XXX 实现"
+- 需要调用项目现有基础设施（MQ/统一请求结构/工具类等）
+- 技术栈不熟悉或第一次在该项目实现类似功能
+
+**执行步骤**（3 步）：
+1. **完整阅读所有参考实现**（约 10 分钟）
+   - 从 OpenSpec design 或 tasks 中定位参考实现文件
+   - 如果路径不明确，通过 Grep 搜索关键类名或模式
+   - 逐行理解关键逻辑，提取可复用代码片段和模式
+
+2. **Grep 关键技术栈**（约 5 分钟）
+   - 请求/响应结构模式
+   - 消息队列模式
+   - 统一工具类
+   - 异常处理和日志记录标准
+
+3. **形成技术栈清单并写入 decisions.md**
+   - 项目使用的请求/响应结构标准
+   - MQ 消息定义和发送标准
+   - Consumer 标准位置和写法
+   - 加密/验签/工具类的标准用法
+   - 识别需要新建的工具类或基础设施
+
+**输出要求**（3 条）：
+- ✅ 技术栈清单已写入 `decisions.md` 的 "Pre-apply Research" 章节
+- ✅ 已列出所有参考实现的文件路径
+- ✅ 已识别需要新建的工具类/基础设施
+
+**快速模式支持**：micro 分档可缩短为 5-10 分钟快速扫描，但仍需形成清单。
+
+#### 修改 3：apply 实现过程增强
+
+**分步实现**：建议按 Controller → Service → MQ/异步组件 → Consumer/下游 顺序，每完成一层验证后再继续。
+
+**首模块完成后对齐检查**：完成第一个接口/模块后，对比 OpenSpec design/tasks，标记"已完成/TODO"；核心功能（加密/验签/核心业务逻辑）不允许空实现或纯 TODO 注释。
+
+**快速失败**：连续返工 ≥ 2 次时，暂停并重新执行 pre-apply checkpoint 或向用户汇报。
+
+#### 修改 4：apply 退出条件增强
+
+新增退出条件：
+- ✅ 已完成 pre-apply checkpoint（如触发条件满足），技术栈清单已写入 `decisions.md`
+- ✅ 核心功能已实现或明确标注"待联调"，无纯 TODO 占位
+
+### 预期效果
+
+| 指标 | 当前 | 目标 | 改善 |
+|------|------|------|------|
+| 返工次数 | 4-5 次 | 0-1 次 | -80% |
+| 核心功能空实现率 | 高（3/3 核心功能） | 0% | -100% |
+| 实现时间（含返工） | 2 小时 | 1.5 小时 | -25% |
+| 前置调研时间 | 0 分钟 | 15-20 分钟 | +20 分钟 |
+
+**ROI 分析**：
+```
+投入：15-20 分钟调研
+回报：节省 60 分钟返工 + 避免核心功能遗漏
+ROI = (60 - 20) / 20 = 200%
+```
+
+### 复杂度评估
+
+**本次修改复杂度**：中等
+- 文本增量：+55 行（从 281 行 → 336 行，+20%）
+- 概念层级：+1 层（apply 内部增加 Pre-apply Checkpoint 子阶段）
+- 强制规则：+5 条（pre-apply 触发条件、执行步骤、输出要求）
+
+**整体复杂度**：高（但合理）
+- 总行数：606 行 → ~700 行（+15%）
+- 阶段数：9 个（不变）
+- 门控数：4 个 → 6 个（+propose checkpoint, +pre-apply checkpoint）
+
+**简化设计**：
+- 采用方案 B（简化版），相比完整方案减少 45% 文本量和 44% 规则数
+- 保留核心价值（前置调研、技术栈清单、核心功能质量保证）
+- 去掉过度约束（严格执行顺序、频繁检查点、详细操作模板）
+
+### 适用场景
+
+✅ **强烈推荐**：
+- 中等及以上规模需求（3+ 接口或涉及多模块）
+- 涉及项目现有基础设施（MQ/统一请求结构/工具类）
+- 第一次在该项目实现类似功能
+- 设计文档提到"参考 XXX 实现"
+
+🟡 **可选执行**：
+- micro 分档的简单需求（可缩短为 5-10 分钟）
+- 纯数据处理或工具脚本（技术栈熟悉）
+
+❌ **不推荐**：
+- 紧急热修复（时间紧急）
+- 一次性脚本（不涉及项目标准）
+
+### 相关文档
+
+- 执行复盘：`skill-workbench/docs/sm-flow/sm-flow-execution-review-shandong-intent-sync.md`
+- 更新日志：`skill-workbench/docs/sm-flow/phase-contracts-v4.1-changelog.md`
+- 修改文件：`.agents/skills/sm-flow/references/phase-contracts.md`
+
+## v4.2：可验证 Checkpoint 与执行机制增强（2026-06-24）
+
+### 背景
+
+基于"lookup-knowledge-integration"的执行复盘（`skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md`），发现一个结构性问题：
+
+**约束是"软性"的，缺少执行机制**
+
+- **规则清楚但可绕过**：6 条硬约束写得很清楚"不得跳过 commit"，但 agent 仍然能跳过
+- **标准模糊无法判断**：commit 阶段说"检查是否可执行"，但不知道具体检查什么
+- **流程无强制顺序**：archive 建议"先 devflow 后 handoff"，但 agent 可能先创建 handoff
+
+**核心认知**：规则是"描述性"的（说应该做什么），缺少"执行性"的机制（强制检查、文件依赖）。
+
+### 核心改进：从软性约束到硬性检查
+
+v4.2 不增加新阶段或新规则，而是**把现有约束变成可验证的 checkpoint**：
+
+| 改进点 | Before（v4.1） | After（v4.2） |
+|--------|---------------|--------------|
+| Commit 标准 | "检查是否可执行"（模糊） | 文件完整性 + 一致性检查清单（具体） |
+| Apply 门控 | "已通过 commit"（软性） | 检查 `.committed` 文件存在（硬性） |
+| Archive 顺序 | "应该先 devflow"（建议） | 5 步强制顺序 + 自检（必须） |
+
+### 详细修改
+
+#### 修改 1：Commit 阶段增加可验证 Checkpoint
+
+**文件完整性检查**（必须全部通过）：
+- [ ] `proposal.md` 存在，包含问题描述（≥50字）、建议方案（≥100字）、范围/非目标
+- [ ] `design.md` 存在，包含架构设计、数据结构（≥1个）、关键决策（≥2条）
+- [ ] `specs/` 目录存在，至少 1 个 functional-spec.md 包含 ≥3 个 requirement
+- [ ] `tasks.md` 存在，包含 ≥5 个可执行子任务，每个任务有验收标准
+
+**一致性检查**（必须通过）：
+- [ ] proposal 核心概念 → design 有对应设计
+- [ ] design 关键决策 → tasks 有对应实现
+- [ ] tasks 验收标准可验证（非"正确实现"这类模糊描述）
+
+**标记文件**：检查通过后，创建 `openspec/changes/{slug}/.committed` 文件
+
+#### 修改 2：Apply 阶段增加前置门控
+
+**前置门控检查**（硬约束）：
+1. 检查 `openspec/changes/{slug}/.committed` 文件是否存在
+2. 如不存在：
+   - 汇报：Draft OpenSpec 未通过 commit 检查
+   - 列出缺失的 checkpoint 项
+   - 询问用户：是否补做 commit，或明确跳过（需显式确认）
+
+#### 修改 3：Archive 阶段增加强制执行顺序
+
+**5 步 Checklist**（不得跳过或重排）：
+1. **创建 devflow 档案**（必需）：brief.md + evidence.md + decisions.md + acceptance.md
+2. **更新索引**（必需）：在 `devflow/index.md` 追加一行
+3. **标记 OpenSpec**（必需）：创建 `.archive-ready` 文件
+4. **向用户汇报**（必需）：列出文件、验证分类、剩余风险，询问是否归档
+5. **执行 OpenSpec Archive**（可选）：用户确认后调用 `openspec-archive-change`
+
+**自检**：Step 4 前检查 Step 1-3 是否都完成
+
+### 新增门控文件
+
+| 文件 | 创建时机 | 用途 |
+|------|----------|------|
+| `.committed` | commit 阶段退出时 | apply 阶段前置门控依据 |
+| `.archive-ready` | archive Step 3 | 标记归档准备就绪 |
+
+### 预期效果
+
+**解决的问题**：
+- ❌ Commit 标准不明确 → ✅ 有具体检查清单，无法模糊通过
+- ❌ Apply 可能基于不完整 OpenSpec → ✅ 门控文件强制阻止
+- ❌ Archive 容易遗漏 devflow → ✅ 强制顺序确保完整
+
+**量化指标**：
+- Commit 阶段跳过率：-100%（有 checklist 无法跳过）
+- Apply 基于不完整 OpenSpec：-100%（门控阻止）
+- Archive 遗漏 devflow：-100%（强制顺序）
+
+### 设计原则
+
+#### 1. 可验证性
+将模糊标准转为可测量的具体要求：
+- Before: "检查 OpenSpec 是否可执行"
+- After: "proposal ≥50字、design ≥1个数据结构、specs ≥3个 requirement"
+
+#### 2. 门控文件
+用文件存在性替代软性判断：
+- Before: 描述"已通过 commit"
+- After: 检查 `.committed` 文件存在
+
+#### 3. 强制顺序
+用 checklist 替代建议性描述：
+- Before: "应该先创建 devflow"
+- After: "Step 1 devflow → Step 2 索引 → Step 3 标记 → Step 4 汇报"
+
+### 复杂度评估
+
+**本次修改复杂度**：低-中等
+- 文本增量：+80 行（phase-contracts.md +40 行，archive-rules.md +40 行）
+- 概念增加：2 个门控文件
+- 规则增强：3 个阶段的检查清单
+
+**整体复杂度**：高（但更可靠）
+- 总行数：~700 行 → ~780 行（+11%）
+- 门控数：6 个 → 8 个
+
+**权衡**：
+- ✅ 收益：彻底解决"跳过阶段"问题
+- ⚠️ 成本：增加 80 行文本，更多检查项
+
+### 与 v4.1 的关系
+
+| 版本 | 核心改进 | 解决问题 |
+|------|----------|----------|
+| v4.1 | Pre-apply Research Checkpoint | apply 前置调研不足，导致返工（4-5次 → 0-1次） |
+| v4.2 | 可验证 Checkpoint + 门控文件 | 约束是软性的，agent 容易跳过阶段 |
+
+**互补关系**：
+- v4.1 解决"调研不充分导致返工"（质量问题）
+- v4.2 解决"缺少执行机制导致跳过阶段"（流程问题）
+
+### 适用场景
+
+**✅ 所有场景（无例外）**
+
+v4.2 的改进是执行机制层面的，不涉及业务逻辑：
+- 无论 micro/standard/complex，都需要 commit 检查
+- 无论需求大小，都需要 apply 前置门控
+- 无论项目规模，都需要 archive 强制顺序
+
+**快速模式**：可以简化产物（如 tasks 只需 3 个），但**不能跳过门控**。
+
+### 后续演进方向（v5.0 候选）
+
+如果 v4.2 执行良好但仍有问题，考虑：
+
+1. **流程状态文件** `.sm-flow-state`
+   - 记录当前阶段、已完成阶段、时间戳
+   - 支持断点续做
+
+2. **更多门控文件**
+   - `.context-done`、`.grill-done`、`.apply-done`
+   - 形成完整的阶段间依赖链
+
+3. **违规自检机制**
+   - 每个阶段退出前，自动检查 6 条硬约束
+
+4. **进度可视化**
+   - 每次开始时，汇报进度条
+
+**判断依据**：如果 v4.2 后仍频繁出现跳过阶段，再引入更重的机制。
+
+### 相关文档
+
+- 执行复盘：`skill-workbench/docs/sm-flow/sm-flow-optimization-suggestions.md`
+- 更新日志：`skill-workbench/docs/sm-flow/phase-contracts-v4.2-changelog.md`
+- 修改文件：
+  - `.agents/skills/sm-flow/references/phase-contracts.md`
+  - `.agents/skills/sm-flow/references/archive-rules.md`