refactor: code-drive 提示词与模板的工作流对齐优化

- schema: design/plan/tasks/apply 改写为 7 段骨架（目标/输入/工具/协议/工作流/完成标准/规则速查）
- schema: 每个下游阶段定义 3 条触发条件 + AI 自决范围，统一回退上游与 blocker 机制
- schema: 阶段职责改为正常流程/异常流程分工，避免与 blocker-revise 决策入口冲突
- schema: 压缩重复的工具前置说明与阶段职责解释，保留引导强度
- blocker-revise: 重写为 7 段骨架，加入用户决策流程与归档规则
- templates: plan/tasks 改为可重复阶段结构，blocker 改为语义化方案命名
- prompts/blocker-revise: 修正 question/choice 触发条件措辞

code-drive/prompts/blocker-revise.md

@@ -2,6 +2,12 @@
 
 当 OpenSpec `code-drive` 的 apply 阶段生成 `blocker.md` 并暂停时，按照本提示词修订规划 artifacts。目标是修正不成立的部分，而不是强行继续实现。
 
+## 目标
+
+读取 `blocker.md` 及上下游 artifacts，识别阻塞本质，定位最上游的修订入口，通过用户决策流程选定修订方向，按 code-drive 各 artifact 的 instruction 逐层修订受影响的部分，最终让 apply 可以从修订后的待办任务继续。
+
+本提示词是 code-drive 中除 requirements 之外**唯一允许向用户发起决策型提问**的入口，决策能力受"用户决策流程（强制协议）"约束。
+
 ## 输入
 
 - 当前 OpenSpec change 目录
@@ -11,89 +17,179 @@
 - `plan.md`
 - `tasks.md`
 - `openspec/schemas/code-drive/schema.yaml`（用于读取各 artifact 的 instruction）
+- `openspec/schemas/code-drive/templates/*.md`（用于读取各 artifact 的模板结构）
+
+## 工具使用（先决说明）
+
+- **todo 工具**：用于跟踪步骤 5/6/7 内的子步骤进度；子步骤颗粒度（如 5.1 / 5.2 / 5.3）直接对应 todo 条目；todo 只是过程跟踪，最终事实必须写回对应 artifact 文件
+- **question / choice 工具**：触发用户决策流程时必须优先使用（如工具支持），按"用户决策格式（强制）"组织候选与说明
+- **读写工具**：本提示词需要写入多个 artifact，但写入前必须先读取对应 artifact 的当前内容；禁止凭印象重写
+- **只读探索工具**：用于步骤 2 的代码库调查（仅在阻塞点涉及未被探索过的代码时使用）
+
+## 用户决策流程（强制协议）
+
+本协议是 blocker-revise 阶段的**唯一决策出口**。任何超出"修订执行细节"层级的方向选择必须走本协议，不得 AI 自决。
+
+### 触发条件（命中即必须启动）
+
+1. **核心修订方向存在多种可行路径**：blocker.md 列出的可选方案 ≥ 2 个，或 AI 补充的方案与原方案构成真正的取舍（不是同一思路的两种写法）
+2. **blocker.md 建议的修订方向会扩展本次业务范围或引入核心新依赖**：与原 requirements / design 不一致，必须显式征得用户同意
+3. **修订入口在不同 artifact 之间犹豫**：例如 blocker 表面指向 plan，但根因可能在 design 或 requirements，需要用户判断修订起点
+4. **blocker.md 未列出可选方案，仅描述了阻塞现象**：AI 必须主动补充 2-3 个候选方向并请用户选择
+
+未命中以上任何条件时，**不得**主动发起决策型提问；AI 自决范围参见下文。
+
+### AI 自决范围（无需启动用户决策流程）
+
+以下类型的修订属于执行细节，AI 自决后直接执行，无需启动用户决策流程：
+
+1. **执行步骤的局部调整**：plan.md 阶段内步骤的拆分、合并、重排
+2. **任务粒度细化或合并**：tasks.md checkbox 的拆分/合并，但不删除整个分组
+3. **描述措辞修正**：澄清歧义、补充缺失细节、修正笔误
+4. **已完成任务的保留决策**：阻塞未证明无效时，已完成 checkbox 必须保留
+5. **修订记录的措辞与格式**：blocker.md 末尾的修订记录按本提示词模板填写
+6. **工具使用顺序**：todo / 读写工具的使用顺序与时机
+
+### 用户决策格式（强制）
+
+每次启动用户决策流程时，输出必须包含：
+
+1. **2-3 个候选选项**：每个选项含义明确，避免"方案 A / 方案 B"这类无信息标签
+2. **推荐方案**：AI 必须明确推荐其中一项，不得回避或"中立呈现"
+3. **取舍说明**：
+   - 每个非推荐方案：说明未选它的核心理由（一句话即可）
+   - 推荐方案：说明选择它的核心理由 + 主要代价
+4. **影响范围预测**（blocker-revise 特有）：每个选项预测将影响哪些 artifact 需要修订，并粗估修订量（小改 / 中改 / 重写章节）
+5. **使用工具**：优先使用 question/choice 工具；工具不可用时以 markdown 形式直接呈现
+
+### 强制语义（不得跳过）
+
+- 触发条件命中时**必须**启动用户决策流程，即使你倾向"自己决定"或"按 blocker.md 建议执行"
+- 即使用户回复"你看着办"，也必须回复"推荐方案 + 主要代价"，请用户**显式确认**推荐方案，不得默认接受"你看着办"作为决策
+- 决策方向涉及扩展本次业务范围或引入核心新依赖时（触发条件 2），必须**额外显式提示**"本选项将扩展本次范围 / 引入新依赖"，并征得用户的明确同意（不接受默认）
+- 用户未决策前**不得**进入步骤 5 的实际修订
+
+### 决策归档规则
+
+用户给出决策后：
+
+1. **决策结论融入对应 artifact 的相关章节**——不设独立的"决策记录"章节
+2. **在 `blocker.md` 末尾追加"修订记录"段**：记录选择方案、选择理由、修改的 artifacts 列表、被取消勾选的 tasks——这是审计线索，不是二次决策入口
+3. **决策引发的修订如果触及 requirements / design 的关键决策**，按各 artifact instruction 中"决策归档规则"融入对应章节
+4. **决策结论应可在 apply 恢复后直接使用**——明确到 apply 阶段无需重新发起决策
 
 ## 工作流
 
-### 1. 阅读并理解阻塞
+### 步骤 1: 阅读并理解阻塞
 
 阅读 `blocker.md`，识别：
 
-- 阻塞点的本质（不是症状）
+- 阻塞点的**本质**（不是症状）
 - 当前位置：任务编号、`plan.md` 阶段、相关文件
 - 已尝试的方案及失败原因（避免重复）
-- `blocker.md` 建议的修订目标
+- `blocker.md` 建议的修订目标（如有）
 
-### 2. 影响分析
+完成本步骤后进入步骤 2。
+
+### 步骤 2: 影响分析
 
 根据 `blocker.md` 的影响范围，系统分析上下游影响链：
 
-- 如果 `requirements.md` 需要修订：检查 `design.md` 的哪些决策依赖它，再检查 `plan.md` 的哪些阶段受影响，最后检查 `tasks.md` 的哪些 checkbox 需要取消
-- 如果 `design.md` 需要修订：检查 `plan.md` 的哪些阶段依赖它，再检查 `tasks.md` 的哪些 checkbox 需要取消
-- 如果 `plan.md` 需要修订：检查 `tasks.md` 的哪些 checkbox 依赖它，以及是否有下游阶段依赖被阻塞阶段的输出
-- 如果 `tasks.md` 需要修订：只影响当前任务及其直接依赖
+- 如果 `requirements.md` 需要修订 → 检查 `design.md` 的哪些决策依赖它，再检查 `plan.md` 的哪些阶段受影响，最后检查 `tasks.md` 的哪些 checkbox 需要取消
+- 如果 `design.md` 需要修订 → 检查 `plan.md` 的哪些阶段依赖它，再检查 `tasks.md` 的哪些 checkbox 需要取消
+- 如果 `plan.md` 需要修订 → 检查 `tasks.md` 的哪些 checkbox 依赖它，以及是否有下游阶段依赖被阻塞阶段的输出
+- 如果 `tasks.md` 需要修订 → 只影响当前任务及其直接依赖
 
-记录每个 artifact 的影响程度：必须修订 / 可能受影响 / 无影响。
+记录每个 artifact 的影响程度：**必须修订 / 可能受影响 / 无影响**。
 
-### 3. 确定修订入口
+如阻塞点涉及未被探索过的代码模块，使用只读探索工具补充上下文；否则不发起额外探索。
 
-根据影响分析，确定需要修订的最上游 artifact：
+完成本步骤后进入步骤 3。
 
-- 如果需要修订 `requirements.md`：从 requirements 开始，依次修订 design、plan、tasks
-- 如果需要修订 `design.md`：从 design 开始，依次修订 plan、tasks
-- 如果需要修订 `plan.md`：从 plan 开始，修订 tasks
-- 如果只需要修订 `tasks.md`：只修订 tasks
+### 步骤 3: 确定修订入口
 
-### 4. 用户决策
+根据影响分析，确定需要修订的**最上游** artifact：
 
-让用户从 `blocker.md` 中列出的可选方案中选择。如果选项不足，提出 2-3 个方案并说明取舍。工具支持时优先使用 question/choice 工具。
+- 需要修订 `requirements.md` → 从 requirements 开始，依次修订 design、plan、tasks
+- 需要修订 `design.md` → 从 design 开始，依次修订 plan、tasks
+- 需要修订 `plan.md` → 从 plan 开始，修订 tasks
+- 只需要修订 `tasks.md` → 只修订 tasks
 
-### 5. 执行修订
+如果"修订入口在不同 artifact 之间犹豫"（触发条件 3），先暂停并启动用户决策流程；用户决策后回到本步骤。
 
-从修订入口开始，按正常 code-drive 流程逐层修订下游 artifacts。
+完成本步骤后进入步骤 4。
 
-每个 artifact 的修订必须遵循该 artifact 的 instruction 和 template：
+### 步骤 4: 用户决策
+
+检查是否命中"用户决策流程（强制协议）"中任一触发条件：
+
+- **命中** → 按强制格式输出候选 + 推荐 + 取舍 + 影响范围预测，等待用户决策
+- **未命中** → 直接进入步骤 5（属于 AI 自决范围）
+
+用户决策后或确认无需决策后，进入步骤 5。
+
+### 步骤 5: 执行修订
+
+从步骤 3 确定的修订入口开始，按 code-drive 正常流程逐层修订下游 artifacts。
+
+**子步骤 5.1: 读取 instruction 与 template**
+
+对每个待修订的 artifact：
 
 1. 读取 `schema.yaml` 中该 artifact 的 `instruction`
 2. 读取该 artifact 的 `template`
-3. 按 instruction 的工作规则和必需章节进行修订
-4. 确保修订后的 artifact 符合 template 结构
+3. 后续修订必须遵循 instruction 工作流和 template 结构
 
-修订范围原则：
+**子步骤 5.2: 局部修订**
+
+按修订范围原则执行：
 
 - 只改错误的部分，不重写整个章节（除非整个章节的基础假设不成立）
 - 改了 `plan.md` 阶段的实现步骤时，同步更新 `tasks.md` 对应 checkbox 的描述
 - 改了 `design.md` 的关键决策时，检查 `plan.md` 的代码模式是否需要同步，但不自动重写
 - 改了 `requirements.md` 时，逐层向下检查影响，每层只改受影响的部分
-- 如果修订导致 `tasks.md` 分组结构变化，重新对齐 plan -> tasks 映射
+- 如果修订导致 `tasks.md` 分组结构变化，重新对齐 plan → tasks 映射
 
-保留已完成任务：
+**子步骤 5.3: 保留已完成任务**
 
-- 已完成且不受阻塞影响的 tasks：保留 checkbox
-- 已完成但被阻塞证明无效的 tasks：取消 checkbox，并在修订记录中说明原因
-- 未完成的 tasks：根据修订结果更新描述或删除
-- 如果阶段需要拆分：在 `plan.md` 中新增阶段，将已完成部分和待完成部分分开
+按以下规则处理 tasks.md 中已完成任务：
 
-### 6. 修订后验证
+- 已完成且**不受**阻塞影响的 tasks → 保留 checkbox
+- 已完成但被阻塞证明**无效**的 tasks → 取消 checkbox，并在修订记录中说明原因
+- 未完成的 tasks → 根据修订结果更新描述或删除
+- 如果阶段需要拆分 → 在 `plan.md` 中新增阶段，将已完成部分和待完成部分分开
 
-每个被修订的 artifact 完成后，执行以下一致性检查：
+完成本步骤后进入步骤 6。
 
-Instruction 合规性：
+### 步骤 6: 修订后验证
 
-- 每个被修订的 artifact 是否符合其 instruction 中的工作规则
-- 每个被修订的 artifact 是否包含其 instruction 中要求的必需章节
+每个被修订的 artifact 完成后，按两层一致性检查。
+
+**子步骤 6.1: Instruction 合规性检查**
+
+- 每个被修订的 artifact 是否符合其 instruction 中的工作流和完成标准
+- 每个被修订的 artifact 是否包含其 instruction / template 要求的章节
 - 每个被修订的 artifact 是否符合其 template 结构
 
-上下游一致性：
+**子步骤 6.2: 上下游一致性检查**
 
-- 需求覆盖：`requirements.md` 的每条需求是否仍有 `design.md` 决策覆盖
-- 决策落地：`design.md` 的每个关键决策是否在 `plan.md` 中有实现路径
-- 阶段覆盖：`plan.md` 的每个阶段是否在 `tasks.md` 中有对应分组
-- 任务可追溯：`tasks.md` 的每个 checkbox 是否能回溯到 `plan.md` 的某个阶段
-- 验证闭环：`design.md` 的“验证方向”是否在 `plan.md` 的“验证策略”中有体现
+- **需求覆盖**：`requirements.md` 的每条需求是否仍有 `design.md` 决策覆盖
+- **决策落地**：`design.md` 的每个关键决策是否在 `plan.md` 中有实现路径
+- **阶段覆盖**：`plan.md` 的每个阶段是否在 `tasks.md` 中有对应分组
+- **任务可追溯**：`tasks.md` 的每个 checkbox 是否能回溯到 `plan.md` 的某个阶段
+- **验证闭环**：`design.md` 的"验证方向"是否在 `plan.md` 的"验证策略"中有体现
 
-### 7. 处理 blocker.md
+任一项失败 → 回到步骤 5 局部修复，修复后从该项重跑。
 
-在 `blocker.md` 末尾追加“修订记录”：
+全部通过后进入步骤 7。
+
+### 步骤 7: 处理 blocker.md
+
+按以下子步骤追加修订记录并归档。
+
+**子步骤 7.1: 追加修订记录**
+
+在 `blocker.md` 末尾追加：
 
 ```markdown
 ## 修订记录
@@ -107,26 +203,32 @@ Instruction 合规性：
   - X.Y：取消原因
 ```
 
+**子步骤 7.2: 保留或归档**
+
 按项目约定保留或归档 `blocker.md`（建议保留作为审计线索）。
 
-### 8. 完成
+完成本步骤后进入步骤 8。
+
+### 步骤 8: 完成
 
 告诉用户重新运行 `/opsx:apply <change-name>`；apply 应跳过已完成 checkbox 并从修订后的待办任务继续。
 
-## 规则
+## 完成标准
 
-- 除非用户明确要求，不要在使用本提示词时实现代码；本提示词只负责修订规划 artifacts。
-- 不要默认重写全部 artifacts，只修订解决阻塞所需的最小上游点及其下游影响。
-- 不要未经用户确认新增需求、依赖、架构方向或范围。
-- 不要取消已完成任务的勾选，除非阻塞证明该已完成工作不正确。
-- 每个被修订的 artifact 必须遵循其 instruction 和 template，即使只是局部修订。
-- 如果工具支持，使用 todo/plan 工具跟踪修订流程，但最终事实必须写回 artifacts。
+- 工作流步骤 1-8 全部走过
+- 步骤 6 的 instruction 合规性 + 上下游一致性全部通过
+- `blocker.md` 已追加修订记录，并被保留或归档
+- 选定的修订方向已记录在受影响 artifact 中
+- 每个被修订的 artifact 符合其 instruction 的工作流和 template 结构
+- 已完成任务的 checkbox 被保留，除非明确失效
+- 所有触发条件命中时都执行了用户决策流程（事后可被审计）
+- 用户知道需要重新运行 apply 继续实现
 
-## 完成检查
+## 规则速查
 
-- `blocker.md` 已追加修订记录，并被保留或归档。
-- 选定的修订方向已记录在受影响 artifact 中。
-- 每个被修订的 artifact 符合其 instruction 的工作规则和必需章节。
-- 下游 artifacts 与修订后的上游内容一致。
-- 已完成任务的 checkbox 被保留，除非明确失效。
-- 用户知道需要重新运行 apply 继续实现。
+- 本提示词只负责**修订规划 artifacts**，除非用户明确要求，不要在本提示词中实现代码
+- **最小修订**：只修订解决阻塞所需的最小上游点及其下游影响，不要默认重写全部 artifacts
+- **不得擅自扩展**：未经用户确认不得新增需求、依赖、架构方向或范围
+- **已完成任务保护**：不要取消已完成任务的勾选，除非阻塞证明该已完成工作不正确
+- **遵循各 artifact 自身的 instruction**：每个被修订的 artifact 必须遵循其 instruction 和 template，即使只是局部修订
+- **todo 跟踪修订流程**：如果工具支持，使用 todo/plan 工具跟踪修订流程，但最终事实必须写回 artifacts

code-drive/templates/blocker.md

@@ -26,21 +26,21 @@
 
 ## 可选方案
 
-### 方案 A：<!-- 方案名称 -->
+### 方案 1：<!-- 语义化方案名称，例如“回退 design 调整接入方式” -->
 
 - 描述：
 - 需修订：
 - 优势：
 - 风险 / 代价：
 
-### 方案 B：<!-- 方案名称 -->
+### 方案 2：<!-- 语义化方案名称 -->
 
 - 描述：
 - 需修订：
 - 优势：
 - 风险 / 代价：
 
-### 方案 C：<!-- 方案名称 -->（可选）
+### 方案 3：<!-- 语义化方案名称，可选 -->
 
 - 描述：
 - 需修订：

code-drive/templates/design.md

@@ -68,9 +68,3 @@
 ## 验证方向
 
 <!-- 概要说明本次变更应从哪些角度验证，作为 plan.md “验证策略”的输入 -->
-
-## 待确认事项
-
-| 状态 | 问题 | 所需决策 |
-| ---- | ---- | -------- |
-| 无 | 无待确认事项。 | 无需决策 |

code-drive/templates/plan.md

@@ -10,49 +10,7 @@
 | -------- | -------- | -------- |
 | <!-- 文件路径 --> | <!-- 新增 / 修改 / 删除 --> | <!-- 阶段编号 --> |
 
-## 阶段 1: <!-- 阶段名称 -->
-
-### 目标
-
-<!-- 本阶段要完成什么 -->
-
-### 前置条件
-
-<!-- 本阶段开始前必须满足什么；没有则写“无” -->
-
-### 详细实现步骤
-
-<!-- 写清楚关键文件、函数、数据结构、流程或配置变化。不要使用 checkbox。 -->
-
-### 关键代码模式
-
-<!-- 记录本阶段的关键实现细节，apply 据此编写代码。至少覆盖以下内容中适用的部分： -->
-
-**新增 / 修改的函数或方法：**
-<!-- 函数签名、参数、返回值、核心逻辑；无则写“无” -->
-
-**新增 / 修改的数据结构：**
-<!-- 类型定义、字段、约束；无则写“无” -->
-
-**调用顺序 / 流程：**
-<!-- 关键调用链、异步流程、状态转换；无则写“无” -->
-
-**约定 / 模式：**
-<!-- 命名规范、错误处理模式、日志规范等；无则写“无” -->
-
-### 验证方式
-
-<!-- 本阶段如何独立验证 -->
-
-### 验收标准
-
-<!-- 本阶段完成的可验证标准；与 requirements.md 验收标准对齐 -->
-
-### 关联需求
-
-<!-- 例如：F1、F2 -->
-
-## 阶段 2: <!-- 阶段名称 -->
+## 阶段 N: <!-- 阶段名称；按实际阶段重复本块，N 从 1 递增 -->
 
 ### 目标
 
@@ -106,9 +64,3 @@
 - 错误处理：
 - 兼容性：
 - 迁移注意事项：
-
-## 待确认事项
-
-| 状态 | 问题 | 所需决策 |
-| ---- | ---- | -------- |
-| 无 | 无待确认事项。 | 无需决策 |

code-drive/templates/requirements.md

@@ -51,16 +51,7 @@
 
 <!-- 记录相关模块、流程、配置、文档、外部接口或用户路径 -->
 
-### 潜在冲突
-
-<!-- 记录可能与既有行为、约束、依赖、兼容性或用户预期冲突的点 -->
-
 ### 前置条件
 
-<!-- 记录执行前必须满足的条件；没有则写“无” -->
+<!-- 记录执行前必须满足的条件；没有则写"无" -->
 
-## 开放问题
-
-| 状态 | 问题 | 所需决策 |
-| ---- | ---- | -------- |
-| 无 | 无待解决问题。 | 无需决策 |

code-drive/templates/tasks.md

@@ -1,26 +1,16 @@
-## 1. <!-- 对应 plan.md 阶段 1 的名称 -->
+## X. <!-- 对应 plan.md 阶段 X 的名称；按实际阶段重复本块，X 与 plan 阶段编号一致 -->
 
-- [ ] 1.1 阅读 plan.md 阶段 1，确认涉及文件、关键代码模式和验收标准
-- [ ] 1.2 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 1 -->
-- [ ] 1.3 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 1 -->
-- [ ] 1.4 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 1 -->
-- [ ] 1.5 <!-- 运行测试或验证命令，确认阶段 1 的关键行为 -->
-- [ ] 1.6 按 plan.md 阶段 1 的验收标准确认阶段完成
+- [ ] X.1 阅读 plan.md 阶段 X，确认涉及文件、关键代码模式和验收标准
+- [ ] X.2 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 X -->
+- [ ] X.3 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 X -->
+- [ ] X.4 <!-- 运行测试或验证命令，确认阶段 X 的关键行为 -->
+- [ ] X.5 按 plan.md 阶段 X 的验收标准确认阶段完成
 
-## 2. <!-- 对应 plan.md 阶段 2 的名称 -->
+## N. 验证与收尾
 
-- [ ] 2.1 阅读 plan.md 阶段 2，确认涉及文件、关键代码模式和验收标准
-- [ ] 2.2 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 2 -->
-- [ ] 2.3 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 2 -->
-- [ ] 2.4 <!-- 动词 + 文件路径：具体动作描述，详见 plan.md 阶段 2 -->
-- [ ] 2.5 <!-- 运行测试或验证命令，确认阶段 2 的关键行为 -->
-- [ ] 2.6 按 plan.md 阶段 2 的验收标准确认阶段完成
-
-## 3. 验证与收尾
-
-- [ ] 3.1 阅读 plan.md 验证策略，确认所有验证项已执行
-- [ ] 3.2 执行完整测试套件，确认无回归
-- [ ] 3.3 逐项对照 requirements.md 验收标准，确认全部满足
-- [ ] 3.4 检查 design.md 关键决策是否被正确实现
-- [ ] 3.5 如果行为、流程、接口、配置或使用方式发生变化，更新相关文档或交接说明
-- [ ] 3.6 确认所有任务已标记为 `[x]`，未完成或阻塞事项已记录
+- [ ] N.1 阅读 plan.md 验证策略，确认所有验证项已执行
+- [ ] N.2 执行完整测试套件，确认无回归
+- [ ] N.3 逐项对照 requirements.md 验收标准，确认全部满足
+- [ ] N.4 检查 design.md 关键决策是否被正确实现
+- [ ] N.5 如果行为、流程、接口、配置或使用方式发生变化，更新相关文档或交接说明
+- [ ] N.6 确认所有任务已标记为 `[x]`，未完成或阻塞事项已记录