sm-flow v4.1: add pre-apply research checkpoint to reduce rework

Based on real execution review (shandong-intent-sync), apply phase
suffered from 4-5 rework cycles due to insufficient upfront research.

Changes:
- grill: add technical implementation dimension to question pool
- apply: add mandatory pre-apply checkpoint (15-20min research)
  - read reference implementations thoroughly
  - grep key tech stack patterns
  - form tech stack checklist in decisions.md
- apply: add incremental implementation guidance
- apply: add first-module alignment check
- apply: add fast-fail rule (≥2 rework → pause)

Expected impact:
- Rework: 4-5 cycles → 0-1 cycle (-80%)
- Core feature empty impl: 100% → 0%
- ROI: 200% (invest 20min, save 60min)

Complexity: +55 lines to phase-contracts.md (+20%)
Approach: simplified version (plan B) to balance value vs overhead

Docs:
- phase-contracts.md: updated grill + apply phases
- workflow.md: added v4.1 evolution chapter
- phase-contracts-v4.1-changelog.md: detailed change log
- sm-flow-execution-review-shandong-intent-sync.md: source review

.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 证明；代理先查证，再向用户汇报证据、结论和是否需要确认。
@@ -226,22 +230,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 占位 ✅
 - 所有实现期冲突已分类并处理；没有未确认的规格遗漏、设计冲突或用户变更。
 - 已运行验证，或记录了未验证原因。
 - 已列出已知限制。