tdd-repair

将 测试驱动修复循环作为 ruflo 技能提供。当你有一个失败的测试，并希望自动修复被测源代码，同时以测试通过或失败作为验证门槛（不使用 LLM 作为评审）时使用。

使用场景

• 最近一次提交导致 CI 测试失败——将此技能指向测试文件，即可获得经过验证的修复（或一份明确说明“在预算内无法修复”的回执）。
• 本地 TDD 工作流——先编写失败的测试（使用 tdd-workflow 技能），然后运行 tdd-repair 推动测试通过。
• 回归问题排查——之前通过的测试现在失败了；在创建问题单之前，花费约 $1，看看修复是否简单。

不适用场景

• 不存在失败的测试。 一致性模式（--no-test-oracle）计划留待后续 ADR 实现——它需要使用 MCTS 生成复现用例。目前请先编写一个失败的测试。
• 架构变更。 此技能用于战术性地“让红灯变绿”。如果跨模块重构意外导致测试失败，应由人工或 swarm 处理。
• 不可信代码。 无头模式下的 claude -p 使用 --allowedTools Read,Edit,Bash 运行——没有 MCP、没有网络，也不能任意写入文件——但 Bash 仍可访问文件系统。不要将此技能用于你不愿执行 git checkout . 的代码。

算法

实现：scripts/tdd-repair/tdd-repair.mjs。

1. 预检验证——运行测试命令。如果测试已通过，则以状态码 2（test-already-passes）退出。修复已通过的测试要么无事可做，要么说明 --test-command 写错了。
2. 启动 claude -p，并提供有针对性的提示词：
   • 失败测试文件的路径（只读意图）
   • 测试命令（仅运行）
   • 严格约束：不得修改测试
   • 严格约束：不得添加新依赖
3. --allowedTools Read,Edit,Bash 限制可执行操作。--max-budget-usd 限制每次尝试的成本。--permission-mode acceptEdits 会自动接受允许范围内的文件编辑。
4. 重新运行测试进行验证。测试的退出码就是适应度函数——无需单独的沙箱或 LLM 评审。
5. **如果通过：**输出 success: true 和每次尝试的用量。**如果达到 --max-attempts 后仍失败：**输出 success: false 和回执。无论结果如何，工作区都会保留 claude -p 所做的修改（调用方可以使用 git diff 进行检查）。

输出格式

{
  "success": true,
  "data": {
    "repaired": true,
    "attemptsTaken": 1,
    "mode": "test-driven",
    "before": { "passed": false, "exitCode": 1 },
    "after":  { "passed": true,  "exitCode": 0, "durationMs": 4321 },
    "attempts": [
      { "attempt": 1, "claude": { "ok": true, "durationMs": 38421, "usage": { "cost_usd": 0.0234 } }, "verify": { "passed": true } }
    ],
    "totalCostUsd": 0.0234,
    "budgetUsd": 5.0,
    "budgetExhausted": false,
    "shape": { "repo": "...", "test": "...", "testCommand": "...", "maxAttempts": 1, "model": "haiku" }
  }
}

退出码

代码	含义
0	修复后测试通过（成功）
1	达到 --max-attempts 后测试仍未通过
2	配置错误（测试文件缺失、测试已通过、不支持 --no-test-oracle 等）
3	Claude CLI 以非零状态码退出（基础设施故障）
99	保留用于安全熔断（依据 ADR-153）

安全措施

层	机制
成本上限	--max-budget-usd 默认值为 $5，并由 --max-attempts 次尝试分摊。硬性上限——达到上限时 claude 将退出。
操作能力上限	--allowedTools Read,Edit,Bash——没有 MCP、没有网络，也不能任意写入。
范围限制	提示词禁止修改测试或添加依赖。
确认门槛	必须指定 --confirm——否则返回试运行计划（遵循 harness-evolve / harness-mint 惯例）。
硬超时	总墙钟时间为 15 分钟；每次尝试的预算为 timeoutMs / maxAttempts。
预检	如果测试已通过，则拒绝运行（可捕获 --test-command 写错的情况）。

灵感来源

该技能以 agent-harness-generator/packages/darwin-mode ADR-175 中的 测试驱动修复模式为蓝本。关键设计差异：我们不封装 metaharness-darwin evolve（基于种群的搜索），而是驱动一次 claude -p 调用。原因如下：

• 测试命令本身就是适应度函数——无需为变体评分
• claude -p 已在我们的技术栈中——无需添加新的可选依赖
• 成本和操作能力上限均通过一等标志进行控制
• 如果需要迭代，可通过 --session-id 恢复

一致性模式（没有测试，通过 MCTS 编写自己的复现用例）将推迟到未来的 ADR。

示例

# Smoke / dry-run (no --confirm yet)
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo /path/to/myrepo \
  --test tests/auth.test.ts \
  --test-command "npx vitest run tests/auth.test.ts"

# Actually repair (Haiku tier, $5 budget, 1 attempt)
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo /path/to/myrepo \
  --test tests/auth.test.ts \
  --test-command "npx vitest run tests/auth.test.ts" \
  --confirm

# Bigger model + more attempts for harder bugs
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo . --test tests/regression-2456.test.ts \
  --test-command "npm test -- tests/regression-2456.test.ts" \
  --model sonnet --max-attempts 3 --budget 15.00 \
  --confirm

成本阶梯

层级	模型	每次尝试的典型成本	适用场景
1	Haiku	$0.02 – $0.20	首次尝试——大多数“让红变绿”的错误都是战术性的
2	Sonnet	$0.30 – $2.00	Haiku 失败，或错误涉及多个文件
3	Opus	$1.50 – $8.00	Sonnet 失败——需要架构层面的推理（对于单个失败的测试来说，很少值得使用）