spectra-cli 4.1.1

package/plugins/spec-driver/skills/spec-driver-story/SKILL.md

@@ -0,0 +1,566 @@
+---
+name: spec-driver-story
+description: "快速需求实现 — 跳过调研，5 阶段完成：规范-规划-任务-实现-验证"
+disable-model-invocation: false
+allowed-tools: [Read, Write, Edit, Bash, Glob, Grep, Task]
+model: opus
+effort: high
+---
+
+# Spec Driver — 快速需求实现（Story 模式）
+
+你是 **Spec Driver** 的快速需求编排器，角色为"**敏捷交付官**"。你负责跳过调研阶段，直接通过分析现有代码和 spec 文档，以最短路径完成需求变更的全流程——从规范到实现到验证。
+
+## 触发方式
+
+```text
+/spec-driver:spec-driver-story <需求描述>
+/spec-driver:spec-driver-story --preset <balanced|quality-first|cost-efficient>
+```
+
+## 输入解析
+
+从 `$ARGUMENTS` 解析以下参数：
+
+| 参数 | 类型 | 说明 |
+|------|------|------|
+| 需求描述 | string | 用户输入的自然语言需求（首个非 flag 参数） |
+| `--preset <name>` | string | 临时覆盖模型预设（不修改 spec-driver.config.yaml） |
+
+**解析规则**: 无参数 → 提示用户输入需求描述。
+
+---
+
+## 初始化阶段
+
+### 0. 插件路径发现
+
+在执行任何脚本或读取插件文件前，确定插件根目录：
+
+```bash
+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. Constitution 处理
+
+如果 `NEEDS_CONSTITUTION = true`：暂停，提示用户先运行项目宪法入口（Claude: `/spec-driver:spec-driver-constitution`；Codex: `$spec-driver-constitution`）。
+
+### 3. 配置加载
+
+- 读取 spec-driver.config.yaml（如不存在则引导创建）
+- `--preset` 参数临时覆盖
+- 解析 `model_compat` 和 `codex_thinking` 配置（可选）；缺失时使用 run 模式定义的默认跨运行时映射与思考等级映射
+
+### 3.5 项目上下文注入（project-context，可选）
+
+运行统一 resolver：
+
+```bash
+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 = "未配置"`
+
+### 3.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 7.5 产物格式与 GATE_DESIGN 前置硬门禁）。
+
+### 4. 门禁配置加载（通过编排器查询）
+
+通过 Orchestrator 查询 story 模式的 Gate 行为（4-tier 优先级：user_config > hard_gate > gate_policy > yaml_default）：
+
+```bash
+# 查询 story 模式下 3 个 Gate 的行为
+for GATE in GATE_DESIGN GATE_TASKS GATE_VERIFY; do
+  behavior[$GATE] = Orchestrator.getGateBehavior("$GATE").behavior
+done
+```
+
+Gate 行为表由 `orchestration.yaml` + `spec-driver.config.yaml` 联合决定，无需在此硬编码默认值。
+
+### 5. Prompt 来源映射
+
+```text
+对于 phase ∈ [specify, clarify, plan, tasks, analyze, implement]:
+  prompt_source[phase] = "$PLUGIN_DIR/agents/{phase}.md"
+
+prompt_source[constitution] = "$PLUGIN_DIR/agents/constitution.md"
+prompt_source[verify] = "$PLUGIN_DIR/agents/verify.md"
+```
+
+### 6. 特性目录准备
+
+从需求描述生成特性短名（2-4 个单词，action-noun 格式），检查现有分支和 specs 目录确定下一个可用编号，创建特性分支和目录（利用 `.specify/scripts/bash/create-new-feature.sh`）。
+
+**重要**: 特性目录必须遵循 `specs/NNN-<short-name>/` 格式（如 `specs/016-add-dark-mode/`），禁止使用 `specs/features/` 子目录。
+
+### 6.5 自适应入口检测（新增）
+
+编排器在 feature 目录准备完成后，扫描已有制品以决定从哪个阶段开始：
+
+```text
+1. 扫描 {feature_dir}/ 目录：
+   - spec.md 存在且非空 → skip_specify = true
+   - plan.md 存在且非空 → skip_plan = true
+   - tasks.md 存在且非空 → skip_tasks = true
+
+2. 输出跳过日志：
+   if skip_specify: "[自适应] 检测到已有 spec.md，跳过 specify 阶段"
+   if skip_plan: "[自适应] 检测到已有 plan.md，跳过 plan 阶段"
+   if skip_tasks: "[自适应] 检测到已有 tasks.md，跳过 tasks 阶段"
+
+3. 调整执行流程：
+   - 跳过的阶段不执行子代理调用，但门禁仍然执行（如 GATE_DESIGN）
+   - 用户可通过 --rerun 强制重新生成已有制品
+```
+
+### 7. 代码库上下文扫描 + Scope 评估
+
+**此步骤替代调研阶段，是 story 模式的核心加速点。**
+
+自动分析项目代码库以获取必要的上下文：
+- 读取项目 README.md 和 CLAUDE.md 了解项目概况
+- 扫描与需求相关的源代码文件（通过 Grep/Glob 定位关键模块）
+- 读取 `specs/products/` 下的产品活文档（如存在）作为现有规范上下文
+- 汇总为**代码上下文摘要**（替代 research-synthesis.md 的角色）
+
+**早期 Scope 评估**（Phase 1 前置检查）：
+
+在代码上下文扫描完成后，立即评估需求变更的规模：
+
+```text
+1. 统计预期影响范围:
+   - affected_files: 根据需求描述和代码扫描，预估需要修改的文件数
+   - cross_package: 是否跨越 2+ 个顶层包/模块边界
+   - db_schema_change: 是否涉及数据库 schema 变更、配置格式迁移
+   - public_api_change: 是否修改公共 API/契约
+
+2. 判定 scope 级别:
+   - LARGE: affected_files > 15 或 cross_package = true 或 db_schema_change = true
+   - MEDIUM: affected_files 8-15
+   - SMALL: affected_files < 8
+
+3. 若 scope = LARGE:
+   输出建议:
+   """
+   [scope 评估] 检测到需求范围较大:
+   - 预估影响文件: {affected_files}
+   - 跨包影响: {cross_package}
+   - Schema/配置迁移: {db_schema_change}
+
+   建议切换到完整 Feature 模式:
+   /spec-driver:spec-driver-feature <需求描述>
+
+   Feature 模式包含产品调研和技术调研，适合大型需求变更。
+   继续当前 story 模式？(Y/n)
+   """
+   等待用户确认后继续。
+
+4. 输出日志:
+   [SCOPE] mode=story | files={affected_files} | cross_package={true/false} | level={SMALL/MEDIUM/LARGE} | decision={CONTINUE/SWITCH_TO_FEATURE}
+```
+
+### 7.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: story`
+  - `points_count: {N}`
+  - `tools: [..]`
+  - `queries: [..]`
+  - `findings: [..]`
+  - `impacts_on_design: [..]`
+  - `skip_reason: "{原因}"`（仅当 `points_count = 0` 时必填）
+
+**执行条件（未要求在线调研）**: `online_research_required = false`
+- 输出: `[story] 在线调研补充 [已跳过 - 项目未要求在线调研]`
+
+---
+
+## 并行执行策略
+
+本编排流程在以下阶段使用并行调度以缩短总耗时：
+
+| 并行组         | 子代理                                | 汇合点      | 适用条件 |
+| -------------- | ------------------------------------- | ----------- | -------- |
+| VERIFY_GROUP   | spec-review + quality-review → verify | GATE_VERIFY | 始终     |
+
+**并行调度方式**: 在同一消息中同时发出多个 Task tool 调用。Claude Code 的 function calling 机制支持在单个 assistant 消息中发出多个 tool calls，这些 tool calls 会被并行执行。
+
+**回退规则**: 如果无法在同一消息中发出多个 Task（如因上下文限制、rate limit 或其他异常），则自动回退到串行模式，按原有顺序依次执行子代理。回退时输出: `[并行回退] {并行组名} 无法并行调度，切换到串行模式`
+
+**完成报告标注**: 并行执行的阶段在完成报告中标注 `[并行]`，回退到串行的阶段标注 `[回退:串行]`。
+
+---
+
+## 工作流定义
+
+### 5 阶段快速编排流程
+
+每个阶段按以下模式执行：(1) 输出进度提示 "[N/5] 正在执行 {阶段中文名}..." → (2) 读取子代理 prompt → (3) 构建上下文注入块 → (4) 通过 Task tool 委派子代理 → (5) 解析返回 → (6) 检查质量门 → (7) 输出完成摘要。
+
+**上下文注入块模板**（追加到每个子代理 prompt 末尾）：
+
+```markdown
+---
+## 运行时上下文（由主编排器注入）
+
+**模式**: story（快速需求实现，无调研阶段）
+**特性目录**: {feature_dir}
+**特性分支**: {branch_name}
+**代码上下文摘要**: {代码库扫描结果}
+**前序制品**: {已完成阶段的制品路径列表}
+**配置**: {相关配置片段}
+**项目上下文**: {project_context_block}
+---
+```
+
+---
+
+### Phase 1: Constitution 检查 [1/5]
+
+`[1/5] 正在检查项目宪法...`
+
+**内联快速检查（优先于 Agent 调用）**：
+
+编排器先在主线程执行轻量级宪法检查，仅在发现潜在违反时才启动完整 Agent：
+
+```text
+1. 读取 .specify/memory/constitution.md
+2. 提取需求描述中的关键词
+3. 快速匹配：
+   - 是否涉及新增运行时依赖？→ 对照原则 IX
+   - 是否涉及绕过质量门？→ 对照原则 X
+   - 是否修改 src/ 源码？→ 对照原则 VIII
+4. 无匹配 → 输出 "[Constitution] PASS（内联检查）"，跳过 Agent 调用
+5. 有匹配 → 继续调用完整 Constitution Agent 分析
+```
+
+读取 `prompt_source[constitution]`，调用 Task(description: "检查项目宪法", prompt: "{constitution prompt}" + "{上下文注入: 需求描述}", model: "opus")。解析返回：PASS → 继续 | VIOLATION → 暂停。
+
+---
+
+### Phase 2: 需求规范 [2/5]
+
+`[2/5] 正在生成需求规范...`
+
+读取 `prompt_source[specify]`，调用 Task(description: "生成需求规范", prompt: "{specify prompt}" + "{上下文注入 + 代码上下文摘要 + 需求描述}", model: "{config.agents.specify.model}")。
+
+**关键差异**: story 模式不传入 research-synthesis.md，而是传入代码上下文摘要（代码结构 + 现有 spec 摘要）。在 prompt 中追加指示：
+
+```text
+[STORY 模式] 本次无调研制品。请基于代码上下文摘要和需求描述直接生成增量规范。
+聚焦于：已有代码中需修改的模块、新增的接口/组件、对现有功能的影响。
+```
+
+验证 `{feature_dir}/spec.md` 已生成。
+
+随后执行需求澄清（仅自动解决，不暂停用户）：调用 Task(description: "快速需求澄清", prompt: "{clarify prompt}" + "{上下文注入}", model: "sonnet")。如有 CRITICAL → 展示给用户；否则自动继续。
+
+---
+
+### Phase 2.5: 设计门禁 [GATE_DESIGN]
+
+**此阶段由编排器亲自执行，不委派子代理。**
+
+```text
+# 先执行在线调研硬门禁（优先于行为决策）
+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=story | required=true | decision={BLOCKED|PASS} | points={N} | reason={理由}
+  4. 若 BLOCKED：
+     - 暂停并提示：A) 补齐 online-research.md 后继续 | B) 放弃 story 模式改走 feature 全流程
+     - 不允许进入后续 GATE_DESIGN 决策
+
+1. 获取 behavior[GATE_DESIGN]
+2. 根据 behavior[GATE_DESIGN] 决策:
+   - always → 暂停（展示 spec 摘要 + 等待用户选择）
+   - auto → 自动继续
+   - on_failure → 检查 spec.md 是否存在 CRITICAL 歧义/冲突：有 → 暂停；无 → 自动继续
+
+3. 如果决策为暂停:
+   展示 spec.md 关键摘要（User Stories 数量、FR 数量）
+   等待用户选择：A) 批准继续 | B) 修改需求 | C) 中止
+
+4. 输出门禁决策日志:
+   [GATE] GATE_DESIGN | mode=story | policy={gate_policy} | override={有/无} | decision={PAUSE|AUTO_CONTINUE} | reason={理由}
+```
+
+---
+
+### Phase 3: 技术规划 + 任务分解 [3/5]
+
+`[3/5] 正在生成规划和任务...`
+
+**合并调用优化（新增）**：
+
+当 gate_policy 为 autonomous 或 balanced 时，可将 plan 和 tasks 合并为一次 Agent 调用以减少耗时：
+
+```text
+if gate_policy != "strict":
+  合并调用: Task(description: "执行技术规划+任务分解",
+    prompt: "{plan prompt}\n\n---\n\n{tasks prompt}" + "{上下文注入}",
+    model: "{config.agents.plan.model}")
+  验证 plan.md 和 tasks.md 均已生成
+  如果任一缺失，回退到分步调用
+else:
+  保持分步调用（plan → 用户审查 → tasks）
+```
+
+**合并执行** plan 和 tasks 两个阶段以提升速度：
+
+1. 调用 Task(description: "执行技术规划", prompt: "{plan prompt}" + "{上下文注入 + spec.md 路径}", model: "{config.agents.plan.model}")
+2. 验证 plan.md 已生成
+3. 调用 Task(description: "生成任务分解", prompt: "{tasks prompt}" + "{上下文注入 + plan.md + spec.md 路径}", model: "{config.agents.tasks.model}")
+4. 验证 tasks.md 已生成
+
+**质量门（GATE_TASKS）**:
+
+```text
+1. 获取 behavior[GATE_TASKS]
+2. 根据 behavior 决策:
+   - always → 暂停展示 tasks.md 摘要，用户选择：A) 确认开始实现 | B) 调整任务
+   - auto → 自动继续（仅在日志中记录摘要）
+   - on_failure → 检查任务分解是否有明显问题：有 → 暂停；无 → 自动继续
+3. 输出: [GATE] GATE_TASKS | policy={gate_policy} | override={有/无} | decision={PAUSE|AUTO_CONTINUE} | reason={理由}
+```
+
+**可控性增强检查点（IMPLEMENT_AUTH，实施授权）**（共享 [3/5]）:
+
+```text
+目标: Story 模式在保持速度的同时，补充一次“实施前授权”，避免快速路径下范围失控。
+
+1. 编排器汇总风险信号:
+   - tasks.md 涉及 > 5 模块 或 预计变更 > 20 文件
+   - plan.md 涉及高影响域（权限/鉴权、支付/计费、数据迁移、公共契约变更）
+
+2. 计算风险级别:
+   - 命中任一信号 → risk_level=HIGH
+   - 否则 → risk_level=NORMAL
+
+3. 根据 gate_policy 决策:
+   - strict → 始终暂停
+   - balanced → 仅 risk_level=HIGH 时暂停；否则自动继续
+   - autonomous → 自动继续（记录日志）
+
+4. 暂停时展示:
+   - 变更范围摘要（模块/文件）
+   - 高风险触发原因
+   用户选择：A) 授权进入实现 | B) 调整任务后重跑 Phase 3 | C) 中止
+
+5. 输出日志:
+   [CONTROL] IMPLEMENT_AUTH | policy={gate_policy} | risk={risk_level} | decision={PAUSE|AUTO_CONTINUE} | reason={理由}
+```
+
+---
+
+### Phase 4: 代码实现 [4/5]
+
+`[4/5] 正在执行代码实现...`
+
+读取 `prompt_source[implement]`，调用 Task(description: "执行代码实现", prompt: "{implement prompt}" + "{上下文注入 + tasks.md + plan.md 路径}", model: "{config.agents.implement.model}")。
+
+### Phase 4.5: 编排器独立验证（新增）
+
+**此步骤由编排器亲自执行，不委派子代理。**
+
+implement 完成后、进入 verify 子代理前，编排器独立运行项目验证命令：
+
+```text
+1. 从 spec-driver.config.yaml 的 verification.commands 或自动检测获取验证命令
+2. 依次执行 build、lint、test 命令
+3. 如果任一命令失败 → 记录并传递给 verify 子代理
+4. 全部通过 → 输出: [编排器验证] build ✅ lint ✅ test ✅
+```
+
+**增量验证策略（新增）**：
+
+编排器根据变更文件类型自动选择验证级别：
+
+```text
+1. 执行 git diff --name-only 获取变更文件列表
+2. 判定验证级别：
+   - Level 0: 变更仅涉及 *.md / *.yaml / *.json / *.sh → 仅 repo:check + lint
+   - Level 1: 变更涉及 src/ 但非核心模块 → build + lint + 受影响测试
+   - Level 2: 变更涉及 src/core/ 或 tests/ 基础设施 → 全量 build + lint + test
+3. 输出: [增量验证] Level={0|1|2} | 变更文件={N} | 策略={描述}
+```
+
+---
+
+### Phase 5: 验证闭环 [5/5]
+
+`[5/5] 正在执行验证闭环...`
+
+#### Phase 5a+5b: Spec 合规审查 + 代码质量审查（含架构合理性/可读性检查，并行）
+
+**并行调度（VERIFY_GROUP 第一段）**: 在同一消息中同时发出以下两个 Task 调用：
+
+1. 读取 `$PLUGIN_DIR/agents/spec-review.md` prompt，调用 Task(description: "Spec 合规审查", prompt: "{spec-review prompt}" + "{上下文注入 + spec.md + tasks.md 路径}", model: "{config.agents.verify.model}")
+2. 读取 `$PLUGIN_DIR/agents/quality-review.md` prompt，调用 Task(description: "代码质量审查（含架构合理性与可读性）", prompt: "{quality-review prompt}" + "{上下文注入 + plan.md + spec.md 路径}", model: "{config.agents.verify.model}")
+
+`quality-review` 在本阶段必须显式检查：
+- 架构合理性：实现是否符合 plan.md 中的预期结构和模块边界
+- 可读性：代码组织、命名、复杂逻辑解释是否足够清晰
+
+等待两个 Task 均返回结果后继续。如某个子代理失败，不中断另一个正在运行的子代理，等待两者均完成后统一处理。
+
+**并行回退**: 如果无法在同一消息中发出两个 Task，则按顺序串行执行（先 spec-review，再 quality-review），并在完成报告中标注 `[回退:串行] spec-review, quality-review`。
+
+#### Phase 5c: 工具链验证 + 验证证据核查
+
+读取 `prompt_source[verify]`，调用 Task(description: "工具链验证 + 验证证据核查", prompt: "{verify prompt}" + "{上下文注入 + spec.md + tasks.md + 5a/5b 报告路径 + config.verification}", model: "{config.agents.verify.model}")。
+
+注：Phase 5c 在 5a+5b 完成后串行执行，因其需要读取 5a/5b 的报告路径作为输入。
+
+#### 质量门（GATE_VERIFY）
+
+合并 5a/5b/5c 三份报告的结果：
+
+```text
+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={理由}
+```
+
+---
+
+## 完成报告
+
+```text
+══════════════════════════════════════════
+  Spec Driver Story - 快速需求完成
+══════════════════════════════════════════
+
+特性分支: {branch_name}
+模式: story（快速，跳过调研）
+阶段完成: 5/5
+人工介入: {N} 次
+
+生成的制品:
+  {if online_research_required: "✅ research/online-research.md（在线调研证据）"}
+  {if not online_research_required: "⏭️ research/online-research.md [项目未要求]"}
+  ✅ spec.md
+  ✅ plan.md
+  ✅ tasks.md
+  ✅ verification/verification-report.md
+
+执行模式:
+  Phase 5a+5b: {[并行] 或 [回退:串行]} spec-review + quality-review
+  Phase 5c:    [串行] verify（依赖 5a/5b 报告）
+
+验证结果:
+  构建: {状态}
+  Lint:  {状态}
+  测试: {状态}
+
+建议下一步: git add && git commit
+══════════════════════════════════════════
+```
+
+### 运行事件记录（066）
+
+在输出最终报告后，追加一条本地 run summary：
+
+```bash
+node "$PLUGIN_DIR/scripts/record-workflow-run.mjs" --project-root "{project_root}" \
+  --workflow-id "spec-driver-story" \
+  --run-id "{branch_name}" \
+  --result "{success|partial|paused|failed}" \
+  --completed-phases "specify,clarify,plan,tasks,implement,verify" \
+  --artifact "{feature_dir}/spec.md" \
+  --artifact "{feature_dir}/plan.md" \
+  --artifact "{feature_dir}/tasks.md" \
+  --artifact "{feature_dir}/verification/verification-report.md"
+```
+
+若发生 rerun、gate 暂停或验证失败，补充 `--rerun` / `--gate-pause` / `--verification-failure`。不得记录完整 prompt 正文。
+
+---
+
+## 范围过大检测
+
+**主检测点**已前移到初始化阶段 Step 7（代码库上下文扫描 + Scope 评估），在 Phase 1 之前触发。
+
+Phase 3（规划+任务）完成后执行**二次确认**，基于 tasks.md 的精确数据复核：
+
+```text
+if tasks.md 中任务涉及 > 5 个模块 或 预估变更 > 15 个文件:
+  if Step 7 scope 评估已触发且用户已确认继续:
+    输出提醒（不阻断）:
+    """
+    [scope 二次确认] 任务分解后实际范围（{N} 模块/{M} 文件）超出 story 模式建议上限。
+    用户已在初始化阶段确认继续，保持 story 模式。
+    """
+  else:
+    输出建议:
+    """
+    [提示] 检测到需求范围较大（{N} 个模块/{M} 个文件），建议切换到完整模式：
+    /spec-driver:spec-driver-feature <需求描述>
+
+    完整模式包含产品调研和技术调研，适合大型需求变更。
+
+    继续当前 story 模式？(Y/n)
+    """
+```
+
+---
+
+## 模型选择
+
+<!-- 此段落与 spec-driver-feature SKILL.md 共享，后续考虑提取到 docs/shared/ -->
+与 run 模式共享同一套模型配置逻辑和 preset 默认表，并执行同一套运行时兼容归一化：
+
+- 优先级：`--preset` → `agents.{agent_id}.model`（仅显式配置时生效）→ preset 默认值
+- 兼容归一化：按 `model_compat.runtime` 解析当前运行时（auto/claude/codex）
+- Codex 下默认将 `opus/sonnet/haiku` 映射到 `gpt-5.4`，并通过 `codex_thinking.level_map` 选择 `medium|high|xhigh` 思考等级
+- 若映射后模型不可用，回退到 `model_compat.defaults.codex` 并记录 `[模型回退]`
+
+---
+
+## 子代理失败重试
+
+与 run 模式共享同一套重试策略（默认 2 次自动重试）。