name: 测试修复循环工作流 description: 端到端的测试修复工作流：生成包含渐进层（L0-L3）的测试会话，然后执行迭代修复循环，直到通过率 >= 95%。结合测试修复生成和测试循环执行，形成一个统一的工作流管道。在 “workflow:test-fix-cycle” 上触发。 allowed-tools: spawn_agent, wait, send_input, close_agent, AskUserQuestion, Read, Write, Edit, Bash, Glob, Grep
工作流测试修复循环
端到端的测试修复工作流管道：生成包含渐进层（L0-L3）的测试会话、AI代码验证和任务生成（阶段1），然后执行包含自适应策略引擎的迭代修复循环，直到通过率 >= 95%（阶段2）。
架构概述
┌────────────────────────────────────────────────────────────────────────────┐
│ 工作流测试修复循环协调器（SKILL.md） │
│ → 完整管道：测试生成 + 迭代执行 │
│ → 阶段调度：读取阶段文档、执行、传递上下文 │
└───────────────┬────────────────────────────────────────────────────────────┘
│
┌────────────┴────────────────────────┐
↓ ↓
┌─────────────────────────┐ ┌─────────────────────────────┐
│ 阶段1：测试修复生成 │ │ 阶段2：测试循环执行 │
│ phases/01-test-fix-gen │ │ phases/02-test-cycle-execute │
│ 5个子阶段： │ │ 3个阶段： │
│ ① 创建会话 │ │ ① 发现 │
│ ② 收集上下文 │ │ ② 主循环（迭代） │
│ ③ 测试分析（Gemini） │ │ ③ 完成 │
│ ④ 生成任务 │ │ │
│ ⑤ 摘要 │ │ 代理（通过spawn_agent）： │
│ │ │ @cli-planning-agent │
│ 代理（通过spawn_agent） │ │ @test-fix-agent │
│ @test-context-search │ │ │
│ @context-search │ │ 策略：保守 → │
│ @cli-execution │ │ 激进 → 外科式 │
│ @action-planning │ │ │
└────────┬────────────────┘ └────────────┬──────────────────┘
↓ ↓
IMPL-001..002.json 通过率 >= 95%
TEST_ANALYSIS_RESULTS.md 自动完成会话
任务管道：
┌──────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐
│ IMPL-001 │───→│ IMPL-001.3 │───→│ IMPL-001.5 │───→│ IMPL-002 │
│ 测试生成 │ │ 代码验证 │ │ 质量门 │ │ 测试与修复 │
│ L1-L3 │ │ L0 + AI问题 │ │ 覆盖率80%+ │ │ 最多10次迭代 │
│@code-developer│ │ @test-fix-agent │ │ @test-fix-agent │ │@test-fix-agent│
└──────────────┘ └─────────────────┘ └─────────────────┘ └──────────────┘
│
修复循环：│
┌──────────────────┘
↓
┌──────────┐
│ @cli-plan│───→ IMPL-fix-N.json
│ 代理 │
├──────────┤
│@test-fix │───→ 应用和重新测试
│ 代理 │
└──────────┘
关键设计原则
- 两阶段管道：生成（阶段1）创建会话和任务，执行（阶段2）运行迭代修复循环
- 纯协调器：调度到阶段文档，解析输出，在阶段间传递上下文
- 自动继续：触发后全管道自主运行
- 子代理生命周期：明确的生命周期管理，使用spawn_agent → wait → close_agent
- 渐进测试层：L0（静态）→ L1（单元）→ L2（集成）→ L3（端到端）
- AI代码问题检测：验证常见AI生成代码问题
- 智能策略引擎：基于迭代上下文，保守 → 激进 → 外科式
- CLI回退链：Gemini → Qwen → Codex，用于分析弹性
- 渐进测试：迭代期间受影响的测试，最终验证完整套件
- 角色路径加载：子代理角色通过MANDATORY FIRST STEPS中的路径引用加载
自动模式
此工作流完全自主——阶段1生成测试会话和任务，阶段2执行迭代修复循环，所有无需用户干预，直到通过率 >= 95%或达到最大迭代次数。
子代理API参考
spawn_agent
使用任务分配创建新子代理。
const agentId = spawn_agent({
message: `
## 任务分配
### MANDATORY FIRST STEPS（代理执行）
1. **读取角色定义**：~/.codex/agents/{agent-type}.md（必须首先读取）
2. 读取：${projectRoot}/.workflow/project-tech.json
3. 读取：${projectRoot}/.workflow/project-guidelines.json
## 任务上下文
${taskContext}
## 交付物
${deliverables}
`
})
wait
从子代理获取结果（唯一检索结果的方式）。
const result = wait({
ids: [agentId],
timeout_ms: 600000 // 10分钟
})
if (result.timed_out) {
// 处理超时——可以继续等待或使用send_input提示完成
}
send_input
与活动子代理继续交互（用于澄清或后续操作）。
send_input({
id: agentId,
message: `
## 澄清答案
${answers}
## 下一步
继续计划生成。
`
})
close_agent
清理子代理资源（不可逆）。
close_agent({ id: agentId })
用法
workflow-test-fix-cycle <input> [options]
# 输入（阶段1 - 测试生成）
source-session-id WFS-* 会话ID（会话模式 - 用于已完成实现的测试验证）
feature description 要测试的功能描述（提示模式）
/path/to/file.md 需求文件路径（提示模式）
# 选项（阶段2 - 循环执行）
--max-iterations=N 自定义迭代限制（默认：10）
# 示例
workflow-test-fix-cycle WFS-user-auth-v2 # 会话模式
workflow-test-fix-cycle "测试src/auth/api.ts中的用户认证API端点" # 提示模式 - 文本
workflow-test-fix-cycle ./docs/api-requirements.md # 提示模式 - 文件
workflow-test-fix-cycle "测试用户注册" --max-iterations=15 # 使用自定义迭代
# 恢复（仅阶段2 - 会话已创建）
workflow-test-fix-cycle --resume-session="WFS-test-user-auth" # 恢复中断会话
质量门：测试通过率 >= 95%（基于关键性）或 100% 最大迭代次数：10（默认，可调整） CLI工具：Gemini → Qwen → Codex（回退链）
测试策略概述
渐进测试层（L0-L3）：
| 层 | 名称 | 焦点 |
|---|---|---|
| L0 | 静态分析 | 编译、导入、类型、AI代码问题 |
| L1 | 单元测试 | 函数/类行为（正常/负面/边缘情况） |
| L2 | 集成测试 | 组件交互、API合约、失败模式 |
| L3 | 端到端测试 | 用户旅程、关键路径（可选） |
关键特性：
- AI代码问题检测 - 验证常见AI生成代码问题（幻觉导入、占位符代码、模拟泄漏等）
- 项目类型检测 - 应用适当的测试模板（React、Node API、CLI、库等）
- 质量门 - IMPL-001.3（代码验证）和IMPL-001.5（测试质量）确保高标准
详细规格：请参阅test-task-generate工作流工具，了解完整的L0-L3要求和质量阈值。
执行流程
输入 → 检测模式（会话 | 提示 | 恢复）
│
├─ 恢复模式 → 跳转到阶段2
│
└─ 会话/提示模式 → 阶段1
│
阶段1：测试修复生成（phases/01-test-fix-gen.md）
├─ 子阶段1.1：创建测试会话 → testSessionId
├─ 子阶段1.2：收集测试上下文（spawn_agent） → contextPath
├─ 子阶段1.3：测试生成分析（spawn_agent → Gemini） → TEST_ANALYSIS_RESULTS.md
├─ 子阶段1.4：生成测试任务（spawn_agent） → IMPL-*.json, IMPL_PLAN.md, TODO_LIST.md
└─ 子阶段1.5：阶段1摘要
│
阶段2：测试循环执行（phases/02-test-cycle-execute.md）
├─ 发现：加载会话、任务、迭代状态
├─ 主循环（针对每个任务）：
│ ├─ 执行 → 测试 → 计算通过率
│ ├─ 100% → 成功：下一个任务
│ ├─ 95-99% + 低关键性 → 部分成功：批准
│ └─ <95% → 修复循环：
│ ├─ 选择策略：保守/激进/外科式
│ ├─ spawn_agent(@cli-planning-agent) → IMPL-fix-N.json
│ ├─ spawn_agent(@test-fix-agent) → 应用修复和重新测试
│ └─ 重新测试 → 返回决策
└─ 完成：最终验证 → 摘要 → 自动完成会话
核心规则
- 立即开始：第一个动作是进度跟踪初始化
- 无初步分析：在阶段1之前不要读取文件
- 解析每个输出：为下一阶段提取数据
- 自动继续：每个阶段完成后，自动执行下一个待处理阶段
- 阶段加载：按需读取阶段文档（
phases/01-*.md、phases/02-*.md） - 任务附件模型：子任务附加 → 执行 → 折叠
- 关键：不要停止：连续管道直到阶段2完成
- 阶段转换：阶段1摘要后，立即开始阶段2
- 明确生命周期：等待完成后始终使用close_agent释放资源
阶段执行
阶段1：测试修复生成
读取：phases/01-test-fix-gen.md
5个子阶段，创建测试会话并生成任务JSON：
- 创建测试会话 →
testSessionId - 收集测试上下文（spawn_agent → wait → close_agent） →
contextPath - 测试生成分析（spawn_agent → wait → close_agent） →
TEST_ANALYSIS_RESULTS.md - 生成测试任务（spawn_agent → wait → close_agent） →
IMPL-001.json、IMPL-001.3.json、IMPL-001.5.json、IMPL-002.json、IMPL_PLAN.md、TODO_LIST.md - 阶段1摘要（内部 - 转换到阶段2）
使用的代理（通过spawn_agent）：
test-context-search-agent（~/.codex/agents/test-context-search-agent.md） - 上下文收集（会话模式）context-search-agent（~/.codex/agents/context-search-agent.md） - 上下文收集（提示模式）cli-execution-agent（~/.codex/agents/cli-execution-agent.md） - 使用Gemini进行测试分析action-planning-agent（~/.codex/agents/action-planning-agent.md） - 任务JSON生成
阶段2：测试循环执行
读取：phases/02-test-cycle-execute.md
3阶段迭代执行，带有自适应策略：
- 发现 - 加载会话、任务、迭代状态
- 主循环 - 执行任务 → 测试 → 分析失败 → 修复 → 重新测试
- 完成 - 最终验证 → 摘要 → 自动完成会话
使用的代理（通过spawn_agent）：
cli-planning-agent（~/.codex/agents/cli-planning-agent.md） - 失败分析、根因提取、修复任务生成test-fix-agent（~/.codex/agents/test-fix-agent.md） - 测试执行、代码修复、关键性分配
策略引擎：保守（迭代1-2）→ 激进（通过率>80%）→ 外科式（回归）
输出工件
目录结构
{projectRoot}/.workflow/active/WFS-test-[会话]/
├── workflow-session.json # 会话元数据
├── IMPL_PLAN.md # 测试生成和执行策略
├── TODO_LIST.md # 任务清单
├── .task/
│ ├── IMPL-001.json # 测试理解和生成
│ ├── IMPL-001.3-validation.json # 代码验证门
│ ├── IMPL-001.5-review.json # 测试质量门
│ ├── IMPL-002.json # 测试执行和修复循环
│ └── IMPL-fix-{N}.json # 生成的修复任务（阶段2）
├── .process/
│ ├── [test-]context-package.json # 上下文和覆盖率分析
│ ├── TEST_ANALYSIS_RESULTS.md # 测试需求和策略（L0-L3）
│ ├── iteration-state.json # 当前迭代状态、策略、卡住测试
│ ├── test-results.json # 最新结果（通过率、关键性）
│ ├── test-output.log # 完整测试输出
│ ├── fix-history.json # 所有修复尝试
│ ├── iteration-{N}-analysis.md # CLI分析报告
│ └── iteration-{N}-cli-output.txt
└── .summaries/iteration-summaries/
进度跟踪模式
阶段1（生成）：
[
{ content: "阶段1：测试修复生成", status: "in_progress" },
{ content: " 1.1 创建测试会话", status: "completed" },
{ content: " 1.2 收集测试上下文", status: "in_progress" },
{ content: " 1.3 测试生成分析", status: "pending" },
{ content: " 1.4 生成测试任务", status: "pending" },
{ content: " 1.5 阶段摘要", status: "pending" },
{ content: "阶段2：测试循环执行", status: "pending" }
]
阶段2（执行）：
[
{ content: "阶段1：测试修复生成", status: "completed" },
{ content: "阶段2：测试循环执行", status: "in_progress" },
{ content: " 执行IMPL-001：生成测试[code-developer]", status: "completed" },
{ content: " 执行IMPL-002：测试与修复循环[迭代]", status: "in_progress" },
{ content: " → 迭代1：初始测试（通过率：70%，保守）", status: "completed" },
{ content: " → 迭代2：修复验证（通过率：82%，保守）", status: "completed" },
{ content: " → 迭代3：批量修复认证（通过率：89%，激进）", status: "in_progress" }
]
更新规则：
- 阶段1：在阶段1内附加/折叠子阶段任务
- 阶段2：添加迭代项，包括策略和通过率
- 每个阶段/迭代完成后标记为完成
- 所有完成后更新父任务
错误处理
| 阶段 | 场景 | 行动 |
|---|---|---|
| 1.1 | 源会话未找到（会话模式） | 返回错误，包含会话ID |
| 1.1 | 无完成IMPL任务（会话模式） | 返回错误，源不完整 |
| 1.2 | 上下文收集失败 | 返回错误，检查源工件 |
| 1.2 | 代理超时 | 重试延长超时，close_agent，然后返回错误 |
| 1.3 | Gemini分析失败 | 返回错误，检查上下文包 |
| 1.4 | 任务生成失败 | 重试一次，然后返回错误 |
| 2 | 测试执行错误 | 记录日志，使用错误上下文重试 |
| 2 | CLI分析失败 | 回退：Gemini → Qwen → Codex → 手动 |
| 2 | 代理执行错误 | 保存状态，close_agent，使用简化上下文重试 |
| 2 | 达到最大迭代次数 | 生成失败报告，标记为阻塞 |
| 2 | 检测到回归 | 回滚最后修复，切换到外科式策略 |
| 2 | 检测到卡住测试 | 使用替代策略继续，在失败报告中记录 |
生命周期错误处理：
try {
const agentId = spawn_agent({ message: "..." });
const result = wait({ ids: [agentId], timeout_ms: 600000 });
// ... 处理结果 ...
close_agent({ id: agentId });
} catch (error) {
if (agentId) close_agent({ id: agentId });
throw error;
}
协调器清单
阶段1（生成）：
- 检测输入类型（会话ID / 描述 / 文件路径 / 恢复）
- 使用2个顶级阶段初始化进度跟踪
- 读取
phases/01-test-fix-gen.md以获取详细子阶段执行 - 使用spawn_agent → wait → close_agent生命周期执行5个子阶段
- 验证所有阶段1输出（4+个任务JSON、IMPL_PLAN.md、TODO_LIST.md）
- 确保所有代理在每个子阶段完成后关闭
阶段2（执行）：
- 读取
phases/02-test-cycle-execute.md以获取详细执行逻辑 - 加载会话状态和任务队列
- 使用spawn_agent → wait → close_agent执行迭代测试修复循环
- 在进度跟踪中跟踪迭代
- 成功时自动完成会话（通过率 >= 95%）
- 确保所有代理在每个迭代完成后关闭
恢复模式：
- 如果提供
--resume-session，跳过阶段1 - 直接加载现有会话到阶段2
相关技能
先决技能：
workflow:plan或workflow:execute- 完整实现（会话模式）- 无，对于提示模式
阶段1代理（通过phases/01-test-fix-gen.md使用spawn_agent）：
test-context-search-agent（~/.codex/agents/test-context-search-agent.md） - 测试覆盖率分析（会话模式）context-search-agent（~/.codex/agents/context-search-agent.md） - 代码库分析（提示模式）cli-execution-agent（~/.codex/agents/cli-execution-agent.md） - 使用Gemini进行测试需求分析action-planning-agent（~/.codex/agents/action-planning-agent.md） - 任务JSON生成
阶段2代理（通过phases/02-test-cycle-execute.md使用spawn_agent）：
cli-planning-agent（~/.codex/agents/cli-planning-agent.md） - CLI分析、根因提取、任务生成test-fix-agent（~/.codex/agents/test-fix-agent.md） - 测试执行、代码修复、关键性分配
后续：
- 成功时自动完成会话
- 为后续工作创建问题（完成后的扩展）