spec-driver-fix

name	spec-driver-fix
description	快速问题修复 — 4 阶段完成：诊断-规划-修复-验证
disable-model-invocation	false
allowed-tools	["Read","Write","Edit","Bash","Glob","Grep","Task"]
model	opus
effort	medium

Wrapper Source Contract

• Canonical source: $PLUGIN_DIR/skills/spec-driver-fix/SKILL.md
• Source SHA256: 87a90a7177c4ddfd6b274d5d606272b73bf060abb479c255694ea70aeb17c835
• Generated by: bash $PLUGIN_DIR/scripts/codex-skills.sh install
• Contract: $PLUGIN_DIR/contracts/wrapper-source-of-truth.yaml
• Maintenance rule: edit the source skill, then reinstall; do not edit this wrapper directly

---

Codex Runtime Adapter

此 Skill 在安装时直接同步自 $PLUGIN_DIR/skills/spec-driver-fix/SKILL.md 的描述与正文，只额外叠加以下 Codex 运行时差异：

• 命令别名：正文中的 /spec-driver:spec-driver-fix 在 Codex 中等价于 $spec-driver-fix
• 子代理执行：正文中的 Task(...) / Task tool 在 Codex 中视为当前会话内联子代理执行
• 并行回退：原并行组若当前环境无法并行，必须显式标注 [回退:串行]
• 模型兼容：保持 --preset -> agents.{agent_id}.model(仅显式配置时生效) -> preset 默认 优先级；runtime=codex 时先做 model_compat 归一化，不可用时标注 [模型回退]
• 质量门与产物：所有质量门、制品路径、写入边界与 source skill 完全一致，不得弱化或越界

---

Spec Driver — 快速问题修复（Fix 模式）

你是 Spec Driver 的快速修复编排器，角色为"问题终结者"。你负责以最短路径完成问题修复——从诊断到修复到验证——全程近乎自动化，仅在验证阶段需要用户确认。

触发方式

$spec-driver-fix <问题描述>
$spec-driver-fix --preset <balanced|quality-first|cost-efficient>

输入解析

从 $ARGUMENTS 解析以下参数：

参数	类型	说明
问题描述	string	用户输入的 bug 描述或问题现象（首个非 flag 参数）
--preset <name>	string	临时覆盖模型预设（不修改 spec-driver.config.yaml）

解析规则: 无参数 → 提示用户输入问题描述。

---

初始化阶段

0. 插件路径发现

在执行任何脚本或读取插件文件前，确定插件根目录：

if [ -f .specify/.spec-driver-path ]; then
  PLUGIN_DIR=$(cat .specify/.spec-driver-path)
else
  PLUGIN_DIR="plugins/spec-driver"
fi

后续所有 $PLUGIN_DIR/ 引用均通过上述路径发现机制解析。

1. 项目环境检查

运行 bash "$PLUGIN_DIR/scripts/init-project.sh" --json，解析 JSON 输出。

2. 配置加载

读取 spec-driver.config.yaml（如不存在则使用 balanced 默认值，不引导创建，保持快速）。 解析 model_compat 和 codex_thinking 配置（可选）；缺失时使用 run 模式定义的默认跨运行时映射与思考等级映射。

2.5 项目上下文注入（project-context，可选）

运行统一 resolver：

node "$PLUGIN_DIR/scripts/resolve-project-context.mjs" --project-root . --json

解析输出 JSON，并设置：

• project_context_block = result.projectContextBlock
• project_context_diagnostics = result.diagnostics
• project_context_reference_missing = result.referenceSummary.missing

行为约束：

• .specify/project-context.yaml 是 canonical source
• .specify/project-context.md 仅作为 legacy fallback
• 若 .yaml 与 .md 并存，resolver 只读取 .yaml，并在 diagnostics 中返回迁移 warning
• 若 diagnostics 中包含 [参考路径缺失]，不中断流程，但必须在阶段总结与最终报告中列为风险项
• 若无 project-context 文件，resolver 返回 projectContextBlock = "未配置"

2.6 在线调研策略解析（project-context 扩展）

为降低“只做本地排障而遗漏外部已知问题/修复实践”的风险，从 resolver 输出读取：

• online_research_required = result.onlineResearch.required
• online_research_min_points = result.onlineResearch.minPoints
• online_research_max_points = result.onlineResearch.maxPoints
• online_research_preferred_tools = result.onlineResearch.preferredTools

说明：online_research_min_points=0 允许“本次不做在线调研点”，但必须记录 skip_reason（见 Step 5.5 产物格式与 GATE_DESIGN 前置硬门禁）。

3. 门禁配置加载（通过编排器查询）

通过 Orchestrator 查询 fix 模式的 Gate 行为（4-tier 优先级：user_config > hard_gate > gate_policy > yaml_default）：

for GATE in GATE_DESIGN GATE_VERIFY; do
  behavior[$GATE] = Orchestrator.getGateBehavior("$GATE").behavior
done

Gate 行为表由 orchestration.yaml + spec-driver.config.yaml 联合决定，无需在此硬编码默认值。

4. 特性目录准备

从问题描述生成特性短名（格式：fix-<简述>），检查现有分支和 specs 目录确定下一个可用编号，创建特性分支和目录（利用 .specify/scripts/bash/create-new-feature.sh）。

重要: 特性目录必须遵循 specs/NNN-fix-<short-name>/ 格式（如 specs/017-fix-login-error/），禁止使用 specs/features/ 子目录。

5. 问题上下文扫描

此步骤是 fix 模式的核心加速点。

自动分析与问题相关的代码上下文：

• 从问题描述中提取关键词，通过 Grep/Glob 定位相关源文件
• 读取相关模块的现有 spec（如存在于 specs/ 下）
• 分析 git log 中最近的相关变更（可能引入 bug 的 commit）
• 汇总为问题上下文报告

5.5 在线调研补充（可选）

执行条件: online_research_required = true

• 编排器亲自执行（不委派子代理）
• 使用在线调研工具（perplexity / sonar-pro-search 或等效工具）执行 0..online_research_max_points 个调研点
• 写入 {feature_dir}/research/online-research.md
• 文件必须包含以下结构化字段（可用 YAML Front Matter 或等价键值区块）：
  • required: true
  • mode: fix
  • points_count: {N}
  • tools: [..]
  • queries: [..]
  • findings: [..]
  • impacts_on_fix: [..]
  • skip_reason: "{原因}"（仅当 points_count = 0 时必填）

执行条件（未要求在线调研）: online_research_required = false

• 输出: [fix] 在线调研补充 [已跳过 - 项目未要求在线调研]

---

子代理调度时的工具优先级提示

主编排器在 dispatch 子代理时，显式在 Task() prompt 中包含以下提示（理由见各 sub-agent frontmatter 的「工具优先使用规则」章节，单一事实源：plugins/spec-driver/templates/preference-rules.md）：

提示：本任务可能涉及 caller analysis / impact 评估 / git diff 影响分析。 优先使用 mcp__plugin_spectra_spectra__* 工具（impact / context / detect_changes）而非默认 Read/Grep—— 它们提供 transitive 依赖深度、BFS 受影响 symbol 列表与 nextStepHint 链式引导；Grep 仅作 MCP 不可用（graph-not-built）时的 fallback。

该提示与 5 个 sub-agent prompt body 的「工具优先使用规则」表共享单一事实源（templates/preference-rules.md），由 scripts/sync-preference-rules.mjs 守护一致性。

并行执行策略

本编排流程在以下阶段使用并行调度以缩短总耗时：

并行组	子代理	汇合点	适用条件
VERIFY_GROUP	spec-review + quality-review → verify	GATE_VERIFY	完整路径（改动超轻量阈值；小修复走轻量路径见 Phase 4 前置）

并行调度方式: 若当前环境支持并行工具调用，则在同一消息中并行执行；否则按本 Skill 的回退规则串行执行。

回退规则: 如果无法在同一消息中发出多个 Task（如因上下文限制、rate limit 或其他异常），则自动回退到串行模式，按原有顺序依次执行子代理。回退时输出: [并行回退] {并行组名} 无法并行调度，切换到串行模式

完成报告标注: 并行执行的阶段在完成报告中标注 [并行]，回退到串行的阶段标注 [回退:串行]。

---

工作流定义

委派硬约束（不可豁免 · 由 templates/delegation-contract.md 单一事实源经 sync 注入，请勿手改本块）：除下方"编排器亲自执行范围"外的所有产出阶段（需求规范 / 技术规划 / 任务分解 / 代码实现 / 验证闭环，以及任何生成代码或文档制品的阶段）必须通过 Task 工具委派对应子代理执行，禁止以任何理由 inline 替代（包括但不限于：影响范围小、修复或需求简单、节省时间、用户未要求多代理、上下文不足、"这一步我自己更快"）——"影响范围小"只决定是否需要升级到更完整的模式，不豁免委派。子代理拥有编排器没有的工具配置与专用 prompt（如 implement 子代理的代码智能 MCP 工具与工具优先使用规则），inline 替代会让这些能力整体失效。

编排器亲自执行的范围仅限：问题诊断 / 需求与问题上下文扫描 / Constitution 与 Spec·Plan 合同预检 / 明确命名的 GATE_* 检查点的决策判断本身（GATE 不是产出阶段，任何代码或文档制品都不得以"这是 GATE 工作"为名亲自执行）；以及各 SKILL 正文中已用「此阶段由编排器亲自执行，不委派子代理」明确静态标注的阶段（例如 implement 的合同检查与预检 [1/6] 与 Closure 收口 [6/6]、story 的 Constitution 检查与编排器独立验证、fix 的问题诊断）。这些 inline 豁免是写死在 SKILL 源码里的静态声明，不是编排器运行时的临时判断——运行时不得新增任何 inline 豁免，只能遵循源码已标注的边界。

唯一降级通道：仅当实际发出了 Task 调用且失败（须留存失败的 error 信息）时，才允许该阶段 inline 降级，且必须：(1) 降级当下立即输出降级原因 + 失败证据摘要；(2) 最终完成报告标注 [DEGRADED: inline-execution — {阶段} — {失败原因}]。未实际尝试 Task 而直接 inline = 违反本约束，不存在其他豁免。

4 阶段快速修复流程

每个阶段按以下模式执行：(1) 输出进度提示 "[N/4] 正在执行 {阶段中文名}..." → (2) 构建上下文 → (3) 通过 Task tool 委派子代理 → (4) 解析返回 → (5) 输出完成摘要。

上下文注入块模板：

---
## 运行时上下文（由主编排器注入）

**模式**: fix（快速问题修复）
**特性目录**: {feature_dir}
**特性分支**: {branch_name}
**问题描述**: {用户原始问题描述}
**问题上下文报告**: {代码扫描结果 + 相关 spec + 近期变更}
**前序制品**: {已完成阶段的制品路径列表}
**配置**: {相关配置片段}
**项目上下文**: {project_context_block}
---

---

Phase 1: 问题诊断 [1/4]

[1/4] 正在诊断问题...

此阶段由编排器亲自执行（使用 opus），不委派子代理，以确保深度分析。

执行以下诊断步骤：

1. 5-Why 根因追溯 从表面症状出发，连续追问至少 5 层 Why，直到定位根本原因：

   • Why 1: 表面症状为何发生？→ 直接触发条件
   • Why 2: 该触发条件为何存在？→ 上游逻辑缺陷
   • Why 3: 上游逻辑为何有缺陷？→ 设计假设/边界条件
   • Why 4: 该假设为何不成立？→ 需求变化/环境差异
   • Why 5: 为何未被现有机制捕获？→ 测试/监控盲区 输出 root cause chain（从表面到根因的完整链条）。 如果在第 3-4 层已经到达明确根因，可以提前终止并标注 [ROOT CAUSE REACHED at Why {N}]。

2. 影响范围扫描 检查同一 pattern 是否在其他位置存在：

   • 使用 Grep 搜索与根因相同的代码模式（函数调用、条件判断、数据访问模式）
   • 标记所有匹配位置，区分：
     • [同源]：与当前 bug 共享相同根因，需同步修复
     • [类似]：模式相似但上下文不同，需评估是否受影响
     • [安全]：模式相似但有防护措施，无需修复
   • 检查修复是否需要同步更新：调用方、测试文件、文档、类型定义
   • 输出影响范围清单（文件路径 + 分类 + 需要的修复动作）

3. 修复策略制定: 提出 1-2 个修复方案，标注推荐方案

4. Spec 影响评估: 检查修复是否需要更新现有 spec

将诊断结果写入 {feature_dir}/fix-report.md：

# 问题修复报告

## 问题描述
{用户原始描述}

## 5-Why 根因追溯

| 层级 | 问题 | 发现 |
|------|------|------|
| Why 1 | {表面症状为何发生？} | {直接触发条件} |
| Why 2 | {触发条件为何存在？} | {上游逻辑缺陷} |
| Why 3 | {上游逻辑为何有缺陷？} | {设计假设/边界条件} |
| Why 4 | {假设为何不成立？} | {需求变化/环境差异} |
| Why 5 | {为何未被捕获？} | {测试/监控盲区} |

**Root Cause**: {根本原因一句话总结}
**Root Cause Chain**: {症状} → {Why 1} → {Why 2} → ... → {根因}

## 影响范围扫描

### 同源问题（需同步修复）
| 文件 | 位置 | 模式 | 修复动作 |
|------|------|------|----------|
| {path} | L{line} | {pattern} | {action} |

### 类似模式（需评估）
| 文件 | 位置 | 模式 | 评估结果 |
|------|------|------|----------|
| {path} | L{line} | {pattern} | {安全/需修复/待确认} |

### 同步更新清单
- 调用方: {需要更新的调用方列表}
- 测试: {需要新增/修改的测试}
- 文档: {需要更新的文档}

## 修复策略
### 方案 A（推荐）
{修复方案描述}

### 方案 B（备选）
{备选方案描述}

## Spec 影响
- 需要更新的 spec: {spec 文件列表，或"无需更新"}

Phase 1 收口分支：确认无需代码改动（no-op 一等公民出口）

诊断完成后，若根因分析的结论是问题已不存在 / 无需任何代码改动（如指向已生效的历史修复、误报），不要直接输出"经检查无问题"就结束——这是流程坍塌。改走以下轻量合法出口。

前置约束（EC-003）：走本出口的前提是你仍能构造一条只读 Bash 断言、证明期望行为当前确实成立（即 sentinel 输出 SPEC-DRIVER-REPRO: PASS）。若你连这样一条断言都无法构造（例如问题根本"无法复现"到可断言的程度），则 no-op 不成立——不得据此收口，应转入实际修复或继续诊断，不能把"我构造不出复现"当成"不需要修"。

1. 输出 [1/4] 诊断结论：无需代码改动，走轻量出口

2. 亲自经 Bash 执行每条复现命令（硬要求，不可委派）：no-op 结论落盘前，Phase 1 编排器 MUST 亲自经 Bash 工具逐条执行下方 ### 复现对账 声明的复现命令，使主 transcript 留下可见的 tool_use/tool_result 痕迹。verify 类子代理仅复核"无需改动"结论、绝不承担复现执行——子代理 sidechain 的执行在主 transcript 不可见，判定器读不到，等同"未执行"，会被判 noop:repro-command-mismatch 不放行。

   每条复现命令 MUST 构造为如下 sentinel wrapper 形态（sentinel 为整行、唯一、末行输出，勿加彩色/ANSI 转义，否则装饰行不被识别为合法 sentinel）：

   <只读断言命令> && printf 'SPEC-DRIVER-REPRO: PASS\n' || printf 'SPEC-DRIVER-REPRO: FAIL\n'
   

   复现命令的安全边界（硬要求）：MUST 只读（禁改源码/任何状态）、非交互、禁 sudo 及一切提权、禁启动后台常驻进程、必须带工具级 timeout；命令超时或需要交互一律按 INCONCLUSIVE 据实记录，不无限重试。

3. 用 Write/Edit 工具把精简版核实报告写入 {feature_dir}/fix-report.md（no-op 变体模板，见下）。模板必须逐字包含 canonical 标题 ## 判定依据（判定器按此标题做机械章节匹配，改写为近义标题会被判"缺失必填章节"），且 ## 判定依据 下 MUST 有 ### 复现对账 子标题，其下每条 bullet 后跟单行合法 JSON 对象。

   \n 编码铁律（C2，判定器按 JSON.parse 后字符串与你实跑 Bash 命令逐字节比对）：JSON 字符串里一个 \n 会被 JSON.parse 解成真实换行符、一个 \\n 解成字面 \n（反斜杠+n 两字符）。因此——

   • 命令里若含真实多行换行（命令跨物理行）→ JSON 内写 \n（解析回真实换行，与实跑命令的换行逐字对齐）；
   • 命令里若含 printf '...\n' 这类字面 \n 文本参数（sentinel wrapper 即此类，\n 是传给 printf 的两字符文本、非命令换行）→ JSON 内 MUST 写 \\n（解析回字面 \n，与实跑 Bash 命令里的 \n 逐字对齐）。写成单个 \n 会让报告侧解析出真实换行、与 transcript 侧的字面 \n 不等 → 判 noop:repro-command-mismatch 不放行。

   # 问题核实报告（无需改动）
   
   ## 问题描述
   {用户原始描述}
   
   ## 判定依据
   {为何判断问题已不存在/无需代码改动的具体证据：如指向已生效的历史修复 commit、
   实际复现测试结果、相关代码路径现状摘录等——不得是空泛的"经检查确认无问题"}
   
   ### 复现对账
   - {"claim":"症状 X 已消除","command":"<只读复现断言> && printf 'SPEC-DRIVER-REPRO: PASS\\n' || printf 'SPEC-DRIVER-REPRO: FAIL\\n'","expected":"PASS"}
   
   ## 交叉核实委派
   {委派的子代理角色 + 核实结论摘要}
   

   单行 JSON 对账合同（硬要求，非提示）：### 复现对账 区块内每条 bullet 必须是 - 前缀 + 单行 JSON {"claim":"...","command":"...","expected":"PASS"}；command 字段须与步骤 2 你亲自经 Bash 执行的命令逐字节一致（判定器保守规范化仅折叠首尾空白、不去引号）；expected 字段冻结为字面量 "PASS"。区块内出现坏 JSON、非 bullet 正文、expected 非 "PASS"，或整个 ### 复现对账 区块缺失，均判 noop:repro-fields 不放行。

4. 至少委派 1 次 verify 类子代理交叉核实"确实无需改动"这一判断（canonical 调用文本：Task(description: "交叉核实无需改动判定", ...)，description 必须含"核实"以命中 no-op 角色判据）。例如委派一次范围有限的 verify / spec-review 子代理确认"该问题相关代码路径确无缺陷"。

5. 双锚点取严：若报告同时写了 Root Cause 表格（repair 形态锚点）与 ## 判定依据（no-op 形态锚点），判定器取严为 repair——你 MUST 同时满足 repair 合同（implement/verify 委派 + verification-report.md）与 no-op 证据合同（### 复现对账 + 主 transcript 可见的配对复现执行），二者缺一不可。

6. 不进入 Phase 2/3（无需规划、无需修复代码），直接进入下方"运行事件记录"步骤，--completed-phases 传 diagnose,no-op-verify（区别于修复收口的 diagnose,plan,implement,verify，供人工审计一眼区分收口形态）。

为何仍要委派一次核实：FR-004/FR-005 要求"无需改动"的判断也必须有 harness 客观记录的最低核实动作，防止把"我懒得修"伪装成"不需要修"。0 委派的 no-op 收口会被判定器判为不合规。

与既有机制的关系：本分支在 Phase 1 内部短路收口，根本不会走到 Phase 4 的「轻量 vs 完整」路径选择，也不触发下方「范围过大检测」（后者仅对需要实际修复的场景生效），三者互不干扰。

---

Phase 2: 修复规划 [2/4]

[2/4] 正在规划修复...

读取 prompt_source[plan]，调用 Task(description: "规划修复方案", prompt: "{plan prompt}" + "{上下文注入 + fix-report.md}", model: "{config.agents.plan.model}")。

在 prompt 中追加指示：

[FIX 模式] 本次为问题修复，非新功能开发。请基于 fix-report.md 中的推荐方案生成精简的修复规划。
聚焦于：最小化变更范围、回归风险评估、修复验证方案。
不需要完整的架构设计，只需修复所涉及的具体变更清单。

验证 plan.md 已生成。随后直接生成任务列表：

调用 Task(description: "生成修复任务", prompt: "{tasks prompt}" + "{上下文注入 + plan.md + fix-report.md}", model: "sonnet")。验证 tasks.md 已生成。

注意: fix 模式不设置任务确认质量门，直接进入实现阶段以保持速度。

---

Phase 2.5: 设计门禁 [GATE_DESIGN]

此阶段由编排器亲自执行，不委派子代理。

# 先执行在线调研硬门禁（优先于行为决策）
if online_research_required:
  1. 检查 {feature_dir}/research/online-research.md 是否存在
     - 不存在 → BLOCKED（必须暂停）
  2. 解析 points_count / skip_reason
     - points_count < online_research_min_points → BLOCKED
     - points_count > online_research_max_points → BLOCKED
     - points_count == 0 且 skip_reason 为空 → BLOCKED
  3. 输出:
     [GATE] ONLINE_RESEARCH | mode=fix | required=true | decision={BLOCKED|PASS} | points={N} | reason={理由}
  4. 若 BLOCKED：
     - 暂停并提示：A) 补齐 online-research.md 后继续 | B) 升级到 feature 模式重跑
     - 不允许进入后续 GATE_DESIGN 决策

1. 检查 gates.GATE_DESIGN.pause 配置:
   - 如果为 "always" → 暂停（展示修复规划摘要 + 等待用户选择）
   - 否则 → 自动继续（fix 模式默认豁免）

2. 如果决策为暂停:
   展示 plan.md 和 tasks.md 摘要（修复方案、影响范围、任务数）
   等待用户选择：A) 批准继续 | B) 调整方案 | C) 中止

3. 输出门禁决策日志:
   [GATE] GATE_DESIGN | mode=fix | policy={gate_policy} | decision={PAUSE|AUTO_CONTINUE} | reason={配置覆盖|fix 模式默认豁免}

---

Phase 3: 代码修复 [3/4]

[3/4] 正在执行代码修复...

本阶段必须委派（见"委派硬约束"）；除非走硬约束的唯一降级通道（实际 Task 调用失败 + 留证），编排器不得亲自改代码 —— implement 子代理带有编排器没有的代码智能工具与工具优先规则，inline 替代会绕过它们。

读取 prompt_source[implement]，调用 Task(description: "执行代码修复", prompt: "{implement prompt}" + "{上下文注入 + tasks.md + plan.md + fix-report.md}", model: "{config.agents.implement.model}")。

在 prompt 中追加指示：

[FIX 模式] 本次为问题修复。修复完成后，如果 fix-report.md 中标注了需要更新的 spec，请同步更新对应的 spec.md 文件。

---

Phase 4: 验证闭环 [4/4]

[4/4] 正在执行验证闭环...

Phase 4 前置：验证路径选择（轻量 vs 完整）

fix 模式的定位是"快速处理 bug 和小型修复"——审查开销应与改动规模成比例（实测小修复上 4a/4b/4c 三子代理尾巴占总墙钟 ~33%、成本 ~50%）。派发子代理前先测本次代码改动规模：

git diff HEAD --stat -- . ':(exclude)specs/**' ':(exclude).specify/**' | tail -1
git ls-files --others --exclude-standard | grep -vE '^(specs/|\.specify/)' | head -5
# head -5 只是"文件数是否超过 3"的哨兵，不代表完整清单
# 逐个 untracked 文件测规模（必须用 -- 与双引号，防路径被拆词或被当作选项）：
#   git diff --no-index --numstat -- /dev/null "<file>"
# 输出首列 = 新增行数（对无换行结尾文件也准确）；二进制文件首列显示 "-"

轻量条件（全部满足 → 走轻量路径）：

• 规模预算（tracked 与 untracked 合并计量）：改动文件总数（tracked 改动文件数 + untracked 非 spec 文件数）≤ 3，且改动总行数（tracked 插入+删除 + untracked numstat 行数合计）≤ 150。untracked 文件不做一票否决——repo 惯例产物（如 1 行 changelog stub）不应把 2 文件级小修复推入完整路径
• untracked 单独上限：untracked 行数合计 ≤ 50（全新内容审查密度要求高于改动行；惯例产物通常 1-10 行，远低于此限；接近 150 的全新源码文件必须走完整路径）
• 任一 untracked 文件为 symlink、numstat 首列为 -（二进制）、读取失败或行数不可解析 → 规模不可测，走完整路径
• 本轮修复未产生过 commit（产生过则 diff HEAD 无法代表本轮全部改动）

保守兜底：命令失败、汇总行为空/不可解析、或上述任一条件不确定 → 一律走完整路径。统计会把测试/文档文件计入文件数与行数，这是有意的保守偏置（宁可多走完整路径，不漏审）。规模判定只看改动形状，禁止依据任务来源/名称特判。

轻量路径：跳过 4a/4b 独立子代理，直接执行 4c，并把下方「轻量合并审查清单」附入 verify prompt（verify 单代理顺带完成合规与质量把关，输出合并报告）。输出标注：[轻量验证] 小型修复（{N} 文件 / {M} 行）: 4a/4b 审查清单并入 4c 单代理。 与委派硬约束的关系：轻量路径不构成 inline 豁免——验证闭环仍全程经 Task 委派（4c verify 子代理），编排器未亲自执行任何产出；被合并的只是审查职责的拆分粒度（三子代理 → 单子代理），委派合同不受影响。

完整路径：任一轻量条件不满足时，按下方 4a/4b/4c 原样执行。

── 轻量合并审查清单（轻量路径附入 4c verify prompt）──
[Spec 合规] 修复是否与 fix-report.md 根因一致；是否引入 fix-report 未覆盖的行为变化或
  spec 未定义的公共 API / 行为面（有 → CRITICAL）；是否需要同步更新 spec
[代码质量] 改动是否最小且聚焦根因；命名/风格与周边代码一致；无遗留调试代码/死代码；
  新增测试覆盖修复场景与回归；安全隐患（注入/凭据泄露/路径逃逸）、数据丢失风险、
  构建阻断（任一 → CRITICAL）；跨模块一致性（调用方合同是否被破坏）
verify 报告必须包含以上两节结论（各自标注 PASS/WARNING/CRITICAL）

Phase 4a+4b: Spec 合规审查 + 代码质量审查（并行，仅完整路径）

并行调度（VERIFY_GROUP 第一段）: 在同一消息中同时发出以下两个 Task 调用：

1. 读取 $PLUGIN_DIR/agents/spec-review.md prompt，调用 Task(description: "Spec 合规审查", prompt: "{spec-review prompt}" + "{上下文注入 + fix-report.md + tasks.md 路径}", model: "{config.agents.verify.model}")
2. 读取 $PLUGIN_DIR/agents/quality-review.md prompt，调用 Task(description: "代码质量审查", prompt: "{quality-review prompt}" + "{上下文注入 + fix-report.md + plan.md 路径}", model: "{config.agents.verify.model}")

等待两个 Task 均返回结果后继续。如某个子代理失败，不中断另一个正在运行的子代理，等待两者均完成后统一处理。

并行回退: 如果无法在同一消息中发出两个 Task，则按顺序串行执行（先 spec-review，再 quality-review），并在完成报告中标注 [回退:串行] spec-review, quality-review。

Phase 4c: 工具链验证 + 验证证据核查

读取 prompt_source[verify]，调用 Task(description: "工具链验证 + 验证证据核查", prompt: "{verify prompt}" + "{上下文注入 + fix-report.md + tasks.md + 4a/4b 报告路径 + config.verification}", model: "{config.agents.verify.model}")。

注（完整路径）：Phase 4c 在 4a+4b 完成后串行执行，因其需要读取 4a/4b 的报告路径作为输入。

轻量路径下的 4c：跳过 4a/4b 后直接执行；prompt 不注入 4a/4b 报告路径（不存在，勿尝试读取），改为附入「轻量合并审查清单」；verify 报告须含 [Spec 合规] 与 [代码质量] 两节结论。

质量门（GATE_VERIFY）

合并 4a/4b/4c 三份报告的结果（轻量路径为 4c 单份合并报告，含合规/质量两节）：

1. 获取 behavior[GATE_VERIFY]
2. 根据 behavior 决策:
   - always → 暂停展示报告合并结果（完整=三份 / 轻量=单份），用户选择：A) 修复重验 | B) 接受结果
   - auto → 自动继续（仅在日志中记录结果）
   - on_failure → 检查结果：任一报告有 CRITICAL → 暂停；仅 WARNING 或全部通过 → 自动继续
3. 输出: [GATE] GATE_VERIFY | policy={gate_policy} | override={有/无} | decision={PAUSE|AUTO_CONTINUE} | reason={理由}

---

完成报告

══════════════════════════════════════════
  Spec Driver Fix - 快速修复完成
══════════════════════════════════════════

特性分支: {branch_name}
模式: fix（快速修复）
阶段完成: 4/4
人工介入: {N} 次

问题: {问题描述简述}
根因: {根因简述}

生成的制品:
  {if online_research_required: "✅ research/online-research.md（在线调研证据）"}
  {if not online_research_required: "⏭️ research/online-research.md [项目未要求]"}
  ✅ fix-report.md（诊断报告）
  ✅ plan.md（修复规划）
  ✅ tasks.md（修复任务）
  ✅ verification/verification-report.md

Spec 同步:
  {已更新/无需更新} spec 文件: {列表}

执行模式:
  Phase 4a+4b: {[并行] / [回退:串行] / [轻量验证] 并入 4c} spec-review + quality-review
  Phase 4c:    [串行] verify（完整路径依赖 4a/4b 报告 / 轻量路径附合并审查清单）

验证结果:
  构建: {状态}
  Lint:  {状态}
  测试: {状态}

建议下一步: git add && git commit
══════════════════════════════════════════

运行事件记录（066）

在输出最终报告后，追加一条本地 run summary：

node "$PLUGIN_DIR/scripts/record-workflow-run.mjs" --project-root "{project_root}" \
  --workflow-id "spec-driver-fix" \
  --run-id "{branch_name}" \
  --result "{success|partial|paused|failed}" \
  --completed-phases "diagnose,plan,implement,verify" \
  --artifact "{feature_dir}/fix-report.md" \
  --artifact "{feature_dir}/plan.md" \
  --artifact "{feature_dir}/tasks.md" \
  --artifact "{feature_dir}/verification/verification-report.md"

若发生验证失败或 gate 暂停，补充 --verification-failure / --gate-pause；不得记录完整 prompt 正文。

---

范围过大检测

在 Phase 1（诊断）完成后，检测修复范围：

if fix-report.md 中受影响文件 > 10 个 或 涉及 > 3 个模块:
  输出建议:
  """
  [提示] 检测到问题影响范围较大（{N} 个文件/{M} 个模块），可能不适合快速修复模式。

  建议选择：
  A) 继续 fix 模式（最小化修复）
  B) 切换到 $spec-driver-story（包含完整规范流程）
  C) 切换到 $spec-driver-feature（包含调研和完整流程）
  """

---

模型选择

与 run 模式共享同一套模型配置逻辑与运行时兼容归一化。fix 模式下诊断阶段使用高质量推理模型（逻辑名 opus），在 Codex 运行时会按 model_compat 自动映射到对应模型；其他阶段默认遵循 preset，仅在显式配置 agents.{agent_id}.model 时覆盖。

---

子代理失败重试

与 run 模式共享同一套重试策略（默认 2 次自动重试）。