名称: 问题执行描述: 从问题队列执行所有解决方案，每个解决方案后使用 git 提交。支持批处理和执行控制。参数提示: “–queue=<id> [–worktree=<路径|新建>] [–skip-tests] [–skip-build] [–dry-run]”

问题执行（Codex 版本）

核心原则

串行执行：通过 ccw issue next 从问题队列中一个一个地执行解决方案。对于每个解决方案，按顺序完成所有任务（实现 → 测试 → 验证），然后使用格式化摘要进行一次提交。继续自主执行，直到队列为空。

项目上下文（必需的第一步）

在执行之前，加载项目上下文：

读取项目技术栈：.workflow/project-tech.json
读取项目指南：.workflow/project-guidelines.json
读取解决方案模式：~/.ccw/workflows/cli-templates/schemas/solution-schema.json

这确保执行遵循项目约定和模式。

参数

--queue=<id>：要执行的队列 ID（必需）
--worktree=<路径|新建>：工作树路径或“新建”以创建新工作树
--skip-tests：跳过解决方案实现期间的测试执行
--skip-build：跳过构建步骤
--dry-run：预览执行而不进行更改

队列 ID 要求（必需）

--queue <queue-id> 参数是必需的

当未提供队列 ID 时

列出队列 → 输出选项 → 停止并等待用户

操作：

ccw issue queue list --brief --json - 获取队列列表
筛选活动/待处理状态，输出格式化列表
停止执行，提示用户使用 codex -p "@.codex/prompts/issue-execute.md --queue QUE-xxx" 重新运行

无自动选择 - 用户必须明确指定 queue-id

工作树模式（推荐用于并行执行）

当指定 --worktree 时，创建或使用 git 工作树来隔离工作。

用法：

--worktree - 创建一个带有基于时间戳名称的新工作树
--worktree <现有路径> - 在现有工作树中恢复（用于恢复/继续）

注意：ccw issue 命令自动检测工作树并自动重定向到主仓库。

# 步骤 0：在开始前设置工作树（从主仓库运行）

# 使用绝对路径避免在子目录中运行时出现问题
REPO_ROOT=$(git rev-parse --show-toplevel)
WORKTREE_BASE="${REPO_ROOT}/.ccw/worktrees"

# 检查是否提供了现有工作树路径
EXISTING_WORKTREE="${1:-}"  # 作为参数传递或为空

if [[ -n "${EXISTING_WORKTREE}" && -d "${EXISTING_WORKTREE}" ]]; then
  # 恢复模式：使用现有工作树
  WORKTREE_PATH="${EXISTING_WORKTREE}"
  WORKTREE_NAME=$(basename "${WORKTREE_PATH}")

  # 验证是否为有效的 git 工作树
  if ! git -C "${WORKTREE_PATH}" rev-parse --is-inside-work-tree &>/dev/null; then
    echo "错误：${EXISTING_WORKTREE} 不是有效的 git 工作树"
    exit 1
  fi

  echo "在现有工作树中恢复：${WORKTREE_PATH}"
else
  # 创建模式：带有时间戳的新工作树
  WORKTREE_NAME="issue-exec-$(date +%Y%m%d-%H%M%S)"
  WORKTREE_PATH="${WORKTREE_BASE}/${WORKTREE_NAME}"

  # 确保工作树基础目录存在（被 git 忽略）
  mkdir -p "${WORKTREE_BASE}"

  # 清理之前中断执行的陈旧工作树
  git worktree prune

  # 从当前分支创建工作树
  git worktree add "${WORKTREE_PATH}" -b "${WORKTREE_NAME}"

  echo "创建了新工作树：${WORKTREE_PATH}"
fi

# 设置清理陷阱以进行优雅的失败处理
cleanup_worktree() {
  echo "由于中断，正在清理工作树..."
  cd "${REPO_ROOT}" 2>/dev/null || true
  git worktree remove "${WORKTREE_PATH}" --force 2>/dev/null || true
  # 保留分支以调试失败的执行
  echo "工作树已移除。分支 '${WORKTREE_NAME}' 保留以供检查。"
}
trap cleanup_worktree EXIT INT TERM

# 更改为工作树目录
cd "${WORKTREE_PATH}"

# ccw issue 命令自动检测工作树并使用主仓库的 .workflow/
# 因此您可以直接从工作树运行 ccw issue next/done

工作树执行模式：

0. [主仓库] 验证队列 ID（--queue 必需，或提示用户选择）
1. [工作树] ccw issue next --queue <queue-id> → 自动重定向到主仓库的 .workflow/
2. [工作树] 实现所有任务，运行测试，git 提交
3. [工作树] ccw issue done <item_id> → 自动重定向到主仓库
4. 从步骤 1 重复

注意：将 .ccw/worktrees/ 添加到 .gitignore 以防止跟踪工作树内容。

好处：

并行执行器不会相互冲突
主工作目录保持清洁
执行后易于清理
恢复支持：传递现有工作树路径以继续中断的执行

恢复示例：

# 列出现有工作树以查找中断的执行
git worktree list

# 在现有工作树中恢复（将路径作为参数传递）
# 将使用工作树路径而不是创建新的
codex -p "@.codex/prompts/issue-execute.md --worktree /path/to/existing/worktree"

完成 - 用户选择：

当所有解决方案完成时，输出选项并等待用户指定：

所有解决方案在工作树中完成。选择下一步操作：

1. 合并到主分支 - 将工作树分支合并到主分支并清理
2. 创建 PR - 推送分支并创建拉取请求（推荐用于并行执行）
3. 保留分支 - 保留分支以供手动处理，仅清理工作树

请回复：1、2 或 3

根据用户响应：

# 在有意清理之前禁用清理陷阱
trap - EXIT INT TERM

# 首先返回主仓库（使用设置中的 REPO_ROOT）
cd "${REPO_ROOT}"

# 验证主仓库状态在合并前（防止冲突）
validate_main_clean() {
  if [[ -n $(git status --porcelain) ]]; then
    echo "⚠️ 警告：主仓库有未提交的更改。"
    echo "无法自动合并。回退到“创建 PR”选项。"
    return 1
  fi
  return 0
}

# 选项 1：合并到主分支（仅当主分支清洁时）
if validate_main_clean; then
  git merge "${WORKTREE_NAME}" --no-ff -m "合并问题队列执行：${WORKTREE_NAME}"
  git worktree remove "${WORKTREE_PATH}"
  git branch -d "${WORKTREE_NAME}"
else
  # 如果主分支有更改，回退到 PR
  git push -u origin "${WORKTREE_NAME}"
  gh pr create --title "问题队列：${WORKTREE_NAME}" --body "自动化问题队列执行（主分支有未提交的更改）"
  git worktree remove "${WORKTREE_PATH}"
fi

# 选项 2：创建 PR（推荐用于并行执行）
git push -u origin "${WORKTREE_NAME}"
gh pr create --title "问题队列：${WORKTREE_NAME}" --body "自动化问题队列执行"
git worktree remove "${WORKTREE_PATH}"
# 分支保留在远程

# 选项 3：保留分支
git worktree remove "${WORKTREE_PATH}"
# 分支保留在本地以供手动处理
echo "分支 '${WORKTREE_NAME}' 保留。准备就绪时手动合并。"

并行执行安全性：对于并行执行器，“创建 PR”是最安全的选项，因为它避免了合并期间的竞争条件。可以按顺序审查和合并多个 PR。

执行流程

步骤 0：验证队列 ID（--queue 必需，或提示用户选择）

初始化：通过 ccw issue next --queue <queue-id> 获取第一个解决方案

当解决方案存在时：
  1. 通过 ccw issue next --queue <queue-id> 接收解决方案 JSON
  2. 按顺序执行 solution.tasks 中的所有任务：
     对于每个任务：
       - 实现：遵循 task.implementation 步骤
       - 测试：运行 task.test 命令
       - 验证：检查 task.acceptance 标准
  3. 提交：暂存所有文件，使用格式化摘要进行一次提交
  4. 通过 ccw issue done <item_id> 报告完成
  5. 通过 ccw issue next --queue <queue-id> 获取下一个解决方案

当队列为空时：
  输出最终摘要

步骤 1：获取第一个解决方案

前提条件：必须确定队列 ID（从 --queue 参数或步骤 0 中的用户选择）。

运行此命令以获取第一个解决方案：

// ccw 自动检测工作树并使用主仓库的 .workflow/
// QUEUE_ID 是必需的 - 从 --queue 参数或用户选择获取
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })

这返回带有完整解决方案定义的 JSON：

item_id：队列中的解决方案标识符（例如，“S-1”）
issue_id：父问题 ID（例如，“ISS-20251227-001”）
solution_id：解决方案 ID（例如，“SOL-ISS-20251227-001-1”）
solution：带有所有任务的完整解决方案
execution_hints：时间和执行器提示

如果响应包含 { "status": "empty" }，则所有解决方案完成 - 跳到最终摘要。

步骤 2：解析解决方案响应

预期解决方案结构：

{
  "item_id": "S-1",
  "issue_id": "ISS-20251227-001",
  "solution_id": "SOL-ISS-20251227-001-1",
  "status": "pending",
  "solution": {
    "id": "SOL-ISS-20251227-001-1",
    "description": "解决方案方法的描述",
    "tasks": [
      {
        "id": "T1",
        "title": "任务标题",
        "scope": "src/module/",
        "action": "Create|Modify|Fix|Refactor|Add",
        "description": "要做什么",
        "modification_points": [
          { "file": "path/to/file.ts", "target": "function name", "change": "description" }
        ],
        "implementation": [
          "步骤 1：做这个",
          "步骤 2：做那个"
        ],
        "test": {
          "commands": ["npm test -- --filter=xxx"],
          "unit": ["单元测试要求 1", "单元测试要求 2"]
        },
        "regression": ["验证现有测试仍然通过"],
        "acceptance": {
          "criteria": ["标准 1：必须通过", "标准 2：必须验证"],
          "verification": ["运行测试命令", "手动验证步骤"]
        },
        "commit": {
          "type": "feat|fix|test|refactor",
          "scope": "module",
          "message_template": "feat(scope): description"
        },
        "depends_on": [],
        "estimated_minutes": 30,
        "priority": 1
      }
    ],
    "exploration_context": {
      "relevant_files": ["path/to/reference.ts"],
      "patterns": "遵循 xxx 中的现有模式",
      "integration_points": "被其他模块使用"
    },
    "analysis": {
      "risk": "low|medium|high",
      "impact": "low|medium|high",
      "complexity": "low|medium|high"
    },
    "score": 0.95,
    "is_bound": true
  },
  "execution_hints": {
    "executor": "codex",
    "estimated_minutes": 180
  }
}

步骤 2.1：确定执行策略

解析解决方案后，分析问题类型和任务操作以确定适当的执行策略。策略定义了超出基本实现-测试-验证周期的额外验证步骤和质量门。

策略自动匹配

匹配优先级：

显式 solution.strategy_type 如果提供
从 task.action 关键词推断（Debug、Fix、Feature、Refactor、Test 等）
从 solution.description 和 task.title 内容推断
如果没有明确匹配，则默认为“standard”

策略类型和匹配关键词：

策略类型	匹配关键词	描述
`debug`	Debug、Diagnose、Trace、Investigate	带有日志和调试的缺陷诊断
`bugfix`	Fix、Patch、Resolve、Correct	带有根本原因分析的缺陷修复
`feature`	Feature、Add、Implement、Create、Build	具有完整测试的新功能开发
`refactor`	Refactor、Restructure、Optimize、Cleanup	保留行为的代码重构
`test`	Test、Coverage、E2E、Integration	具有覆盖率检查的测试实现
`performance`	Performance、Optimize、Speed、Memory	具有基准测试的性能优化
`security`	Security、Vulnerability、CVE、Audit	具有漏洞检查的安全修复
`hotfix`	Hotfix、Urgent、Critical、Emergency	具有最小更改的紧急修复
`documentation`	Documentation、Docs、Comment、README	具有示例验证的文档更新
`chore`	Chore、Dependency、Config、Maintenance	具有兼容性检查的维护任务
`standard`	（默认）	无额外步骤的标准实现

策略特定的执行阶段

每个策略通过额外的质量门扩展基本周期：

1. 调试 → 重现 → 仪器 → 诊断 → 实现 → 测试 → 验证 → 清理

重现 → 仪器 → 诊断 → 实现 → 测试 → 验证 → 清理

2. 缺陷修复 → 根本原因 → 实现 → 测试 → 边缘案例 → 回归 → 验证

根本原因 → 实现 → 测试 → 边缘案例 → 回归 → 验证

3. 功能 → 设计审查 → 单元测试 → 实现 → 集成测试 → 代码审查 → 文档 → 验证

设计审查 → 单元测试 → 实现 → 集成测试 → 测试 → 代码审查 → 文档 → 验证

4. 重构 → 基线测试 → 实现 → 测试 → 行为检查 → 性能比较 → 验证

基线测试 → 实现 → 测试 → 行为保留 → 性能比较 → 验证

5. 测试 → 覆盖率基线 → 测试设计 → 实现 → 覆盖率检查 → 验证

覆盖率基线 → 测试设计 → 实现 → 覆盖率检查 → 验证

6. 性能 → 性能分析 → 瓶颈 → 实现 → 基准测试 → 测试 → 验证

性能分析 → 瓶颈 → 实现 → 基准测试 → 测试 → 验证

7. 安全 → 漏洞扫描 → 实现 → 安全测试 → 渗透测试 → 验证

漏洞扫描 → 实现 → 安全测试 → 渗透测试 → 验证

8. 热修复 → 影响评估 → 实现 → 测试 → 快速验证 → 验证

影响评估 → 实现 → 测试 → 快速验证 → 验证

9. 文档 → 实现 → 示例验证 → 格式检查 → 链接验证 → 验证

实现 → 示例验证 → 格式检查 → 链接验证 → 验证

10. 杂项 → 实现 → 兼容性检查 → 测试 → 变更日志 → 验证

实现 → 兼容性检查 → 测试 → 变更日志 → 验证

11. 标准 → 实现 → 测试 → 验证

实现 → 测试 → 验证

策略选择实现

用于策略匹配的伪代码：

function determineStrategy(solution) {
  // 优先级 1：显式策略类型
  if (solution.strategy_type) {
    return solution.strategy_type
  }

  // 优先级 2：从任务操作推断
  const actions = solution.tasks.map(t => t.action.toLowerCase())
  const titles = solution.tasks.map(t => t.title.toLowerCase())
  const description = solution.description.toLowerCase()
  const allText = [...actions, ...titles, description].join(' ')

  // 匹配关键词（顺序重要 - 先更具体）
  if (/hotfix|urgent|critical|emergency/.test(allText)) return 'hotfix'
  if (/debug|diagnose|trace|investigate/.test(allText)) return 'debug'
  if (/security|vulnerability|cve|audit/.test(allText)) return 'security'
  if (/performance|optimize|speed|memory|benchmark/.test(allText)) return 'performance'
  if (/refactor|restructure|cleanup/.test(allText)) return 'refactor'
  if (/test|coverage|e2e|integration/.test(allText)) return 'test'
  if (/documentation|docs|comment|readme/.test(allText)) return 'documentation'
  if (/chore|dependency|config|maintenance/.test(allText)) return 'chore'
  if (/fix|patch|resolve|correct/.test(allText)) return 'bugfix'
  if (/feature|add|implement|create|build/.test(allText)) return 'feature'

  // 默认
  return 'standard'
}

在执行流中的用法：

// 解析解决方案后（步骤 2）
const strategy = determineStrategy(solution)
console.log(`选择的策略：${strategy}`)

// 在任务执行期间（步骤 3），遵循策略特定的阶段
for (const task of solution.tasks) {
  executeTaskWithStrategy(task, strategy)
}

步骤 2.5：初始化任务跟踪

解析解决方案并确定策略后，使用 update_plan 跟踪每个任务：

// 使用解决方案中的所有任务初始化计划
update_plan({
  explanation: `开始解决方案 ${item_id}`,
  plan: solution.tasks.map(task => ({
    step: `${task.id}: ${task.title}`,
    status: "pending"
  }))
})

注意：Codex 使用 update_plan 工具进行任务跟踪（而不是 TodoWrite）。

步骤 3：按顺序执行任务

遍历 solution.tasks 数组并执行每个任务。

在开始每个任务之前，将其标记为进行中：

// 更新当前任务状态
update_plan({
  explanation: `正在处理 ${task.id}: ${task.title}`,
  plan: tasks.map(t => ({
    step: `${t.id}: ${t.title}`,
    status: t.id === task.id ? "in_progress" : (t.completed ? "completed" : "pending")
  }))
})

完成每个任务后（验证通过），将其标记为已完成：

// 标记任务为已完成（提交发生在解决方案级别）
update_plan({
  explanation: `已完成 ${task.id}: ${task.title}`,
  plan: tasks.map(t => ({
    step: `${t.id}: ${t.title}`,
    status: t.id === task.id ? "completed" : t.status
  }))
})

阶段 A：实现

并行读取上下文文件 使用 multi_tool_use.parallel：

// 并行读取所有相关文件以供上下文
multi_tool_use.parallel({
  tool_uses: solution.exploration_context.relevant_files.map(file => ({
    recipient_name: "functions.read_file",
    parameters: { path: file }
  }))
})

按顺序遵循 task.implementation 步骤
将更改应用到 task.modification_points 文件
遵循 solution.exploration_context.patterns 以保持代码样式一致性
如果指定，运行 task.regression 检查以确保无损坏

输出格式：

## 正在实现：[task.title]（任务 [N]/[总数]）

**范围**：[task.scope]
**操作**：[task.action]

**步骤**：
1. ✓ [实现步骤 1]
2. ✓ [实现步骤 2]
...

**已修改的文件**：
- path/to/file1.ts
- path/to/file2.ts

阶段 B：测试

运行 task.test.commands 中的所有命令
验证单元测试通过（task.test.unit）
如果指定，运行集成测试（task.test.integration）

如果测试失败：修复代码并重新运行。在测试通过之前不要继续。

输出格式：

## 正在测试：[task.title]

**测试结果**：
- [x] 单元测试：通过
- [x] 集成测试：通过（或不适用）

阶段 C：验证

使用 task.acceptance.verification 步骤检查所有 task.acceptance.criteria 是否满足：

## 正在验证：[task.title]

**验收标准**：
- [x] 标准 1：已验证
- [x] 标准 2：已验证
...

**验证步骤**：
- [x] 运行测试命令
- [x] 手动验证步骤

所有标准满足：是

如果任何标准失败：返回实现阶段并进行修复。

重复下一个任务

继续到 solution.tasks 数组中的下一个任务，直到所有任务完成。

注意：不要在每个任务后提交。提交发生在所有任务通过后的解决方案级别。

步骤 3.5：提交解决方案

解决方案中的所有任务通过实现、测试和验证后，对整个解决方案进行一次提交：

# 暂存来自所有任务的已修改文件
git add path/to/file1.ts path/to/file2.ts ...

# 使用干净、标准格式提交（无解决方案元数据）
git commit -m "[commit_type](scope): [更改的简要描述]"

# 示例提交：
# feat(auth): 添加令牌刷新机制
# fix(payment): 解决结账流程中的超时处理
# refactor(api): 简化错误处理逻辑

提交类型选择：

feat：新功能或能力
fix：缺陷修复
refactor：无行为更改的代码重构
test：添加或更新测试
docs：文档更改
chore：维护任务

提交语言：

如果项目的 CLAUDE.md 指定中文响应指南或用户明确请求中文，则使用中文提交摘要
默认或当项目针对国际协作时，使用英文提交摘要
检查项目的现有提交历史以保持语言惯例一致性

输出格式：

## 解决方案已提交：[solution_id]

**提交**：[提交哈希]
**类型**：[commit_type]([scope])

**更改**：
- [功能/修复/改进]：[添加/修复/改进了什么功能]
- [具体更改 1]
- [具体更改 2]

**已修改的文件**：
- path/to/file1.ts - [更改的简要描述]
- path/to/file2.ts - [更改的简要描述]
- path/to/file3.ts - [更改的简要描述]

**解决方案**：[solution_id]（[N] 个任务已完成）

步骤 4：报告完成

解决方案中的所有任务完成并提交后，向队列系统报告完整的解决方案元数据：

// ccw 自动检测工作树并使用主仓库的 .workflow/
// 在此记录所有解决方案上下文（不在 git 提交中）
shell_command({
  command: `ccw issue done ${item_id} --result '${JSON.stringify({
    solution_id: solution.id,
    issue_id: issue_id,
    commit: {
      hash: commit_hash,
      type: commit_type,
      scope: commit_scope,
      message: commit_message
    },
    analysis: {
      risk: solution.analysis.risk,
      impact: solution.analysis.impact,
      complexity: solution.analysis.complexity
    },
    tasks_completed: solution.tasks.map(t => ({
      id: t.id,
      title: t.title,
      action: t.action,
      scope: t.scope
    })),
    files_modified: ["path1", "path2", ...],
    tests_passed: true,
    verification: {
      all_tests_passed: true,
      acceptance_criteria_met: true,
      regression_checked: true
    },
    summary: "[实现了什么 - 简要描述]"
  })}'`
})

完整示例：

shell_command({
  command: `ccw issue done S-1 --result '${JSON.stringify({
    solution_id: "SOL-ISS-20251227-001-1",
    issue_id: "ISS-20251227-001",
    commit: {
      hash: "a1b2c3d4",
      type: "feat",
      scope: "auth",
      message: "feat(auth): add token refresh mechanism"
    },
    analysis: {
      risk: "low",
      impact: "medium",
      complexity: "medium"
    },
    tasks_completed: [
      { id: "T1", title: "Implement refresh token endpoint", action: "Add", scope: "src/auth/" },
      { id: "T2", title: "Add token rotation logic", action: "Create", scope: "src/auth/services/" }
    ],
    files_modified: [
      "src/auth/routes/token.ts",
      "src/auth/services/refresh.ts",
      "src/auth/middleware/validate.ts"
    ],
    tests_passed: true,
    verification: {
      all_tests_passed: true,
      acceptance_criteria_met: true,
      regression_checked: true
    },
    summary: "Implemented token refresh mechanism with automatic rotation"
  })}'`
})

如果解决方案失败：

shell_command({
  command: `ccw issue done ${item_id} --fail --reason '${JSON.stringify({
    task_id: "TX",
    error_type: "test_failure",
    message: "Integration tests failed: timeout in token validation",
    files_attempted: ["path1", "path2"],
    commit: null
  })}'`
})

步骤 5：继续到下一个解决方案

获取下一个解决方案（使用步骤 0/1 中的相同 QUEUE_ID）：

// ccw 自动检测工作树
// 在整个执行过程中继续使用相同的 QUEUE_ID
const result = shell_command({ command: `ccw issue next --queue ${QUEUE_ID}` })

输出进度：

✓ [N/M] 已完成：[item_id] - [solution.description]
  提交：[commit_hash] ([commit_type])
  任务：[task_count] 已完成
→ 获取下一个解决方案...

不要停止。 返回步骤 2 并继续直到队列为空。

最终摘要

当 ccw issue next 返回 { "status": "empty" } 时：

如果在工作树模式下运行：在输出摘要之前，提示用户选择合并/PR/保留（见上文“完成 - 用户选择”）。

## 问题队列执行完成

**执行的解决方案总数**：N
**执行的任务总数**：M
**提交总数**：N（每个解决方案一次）

**解决方案提交**：
| # | 解决方案 | 任务 | 提交 | 类型 |
|---|----------|-------|--------|------|
| 1 | SOL-xxx-1 | T1, T2 | abc123 | feat |
| 2 | SOL-xxx-2 | T1 | def456 | fix |
| 3 | SOL-yyy-1 | T1, T2, T3 | ghi789 | refactor |

**已修改的文件**：
- path/to/file1.ts
- path/to/file2.ts

**摘要**：
[整体实现了什么]

执行规则

永远不要在中途停止队列 - 继续直到队列为空
一次一个解决方案 - 完全完成（所有任务 + 提交 + 报告）后再继续
解决方案内顺序 - 在下一个任务之前完成每个任务的实现/测试/验证
测试必须通过 - 如果任何任务的测试失败，不要继续
每个解决方案一次提交 - 所有任务共享一个带格式化摘要的提交
自我验证 - 在解决方案提交之前，所有验收标准必须通过
准确报告 - 每个解决方案后使用 ccw issue done
优雅处理失败 - 如果解决方案失败，通过 ccw issue done --fail 报告并继续下一个
使用 update_plan 跟踪 - 使用 update_plan 工具进行任务进度跟踪
工作树自动检测 - ccw issue 命令从工作树自动重定向到主仓库

错误处理

情况	操作
`ccw issue next` 返回空	全部完成 - 输出最终摘要
测试失败	修复代码，重新运行测试
验证失败	返回实现阶段
解决方案提交失败	检查暂存，重试提交
`ccw issue done` 失败	记录错误，继续到下一个解决方案
任何任务不可恢复	调用 `ccw issue done --fail`，继续到下一个解决方案

CLI 命令参考

命令	目的
`ccw issue queue list --brief --json`	列出所有队列（用于队列选择）
`ccw issue next --queue QUE-xxx`	从指定队列获取下一个解决方案（–queue 必需）
`ccw issue done <id>`	标记解决方案完成并附带结果（自动检测队列）
`ccw issue done <id> --fail --reason "..."`	标记解决方案失败并附带结构化原因
`ccw issue retry --queue QUE-xxx`	重置指定队列中的失败项目

开始执行

步骤 0：验证队列 ID

如果在命令参数中未提供 --queue：

运行 ccw issue queue list --brief --json
筛选并向用户显示活动/待处理队列
停止执行，提示用户使用 --queue QUE-xxx 重新运行

步骤 1：获取第一个解决方案

一旦确认队列 ID，开始运行：

ccw issue next --queue <queue-id>

然后为每个解决方案遵循解决方案生命周期，直到队列为空。

名称: 问题执行 描述: 从问题队列执行所有解决方案，每个解决方案后使用 git 提交。支持批处理和执行控制。 参数提示: “–queue=<id> [–worktree=<路径|新建>] [–skip-tests] [–skip-build] [–dry-run]”

问题执行（Codex 版本）

核心原则

项目上下文（必需的第一步）

参数

队列 ID 要求（必需）

当未提供队列 ID 时

工作树模式（推荐用于并行执行）

执行流程

步骤 1：获取第一个解决方案

步骤 2：解析解决方案响应

步骤 2.1：确定执行策略

策略自动匹配

策略特定的执行阶段

1. 调试 → 重现 → 仪器 → 诊断 → 实现 → 测试 → 验证 → 清理

2. 缺陷修复 → 根本原因 → 实现 → 测试 → 边缘案例 → 回归 → 验证

3. 功能 → 设计审查 → 单元测试 → 实现 → 集成测试 → 代码审查 → 文档 → 验证

4. 重构 → 基线测试 → 实现 → 测试 → 行为检查 → 性能比较 → 验证

5. 测试 → 覆盖率基线 → 测试设计 → 实现 → 覆盖率检查 → 验证

6. 性能 → 性能分析 → 瓶颈 → 实现 → 基准测试 → 测试 → 验证

7. 安全 → 漏洞扫描 → 实现 → 安全测试 → 渗透测试 → 验证

8. 热修复 → 影响评估 → 实现 → 测试 → 快速验证 → 验证

9. 文档 → 实现 → 示例验证 → 格式检查 → 链接验证 → 验证

10. 杂项 → 实现 → 兼容性检查 → 测试 → 变更日志 → 验证

11. 标准 → 实现 → 测试 → 验证

策略选择实现

步骤 2.5：初始化任务跟踪

步骤 3：按顺序执行任务

阶段 A：实现

阶段 B：测试

阶段 C：验证

重复下一个任务

步骤 3.5：提交解决方案

步骤 4：报告完成

步骤 5：继续到下一个解决方案

最终摘要

执行规则

错误处理

CLI 命令参考

开始执行

名称: 问题执行描述: 从问题队列执行所有解决方案，每个解决方案后使用 git 提交。支持批处理和执行控制。参数提示: “–queue=<id> [–worktree=<路径|新建>] [–skip-tests] [–skip-build] [–dry-run]”