tdd-repair

ruflo スキルとして、テスト駆動修復のループを提供します。失敗しているテストがあり、検証ゲートとしてテストの合否を使いながら（LLM による判定なしで）、テスト対象のソースを自動修正したい場合に使用します。

使用する場合

• 最近のコミットで CI テストが失敗した場合 — テストファイルを指定すれば、検証済みの修正（または「予算内で修復できませんでした」という明確な結果）を得られます。
• ローカルの TDD ワークフロー — まず失敗するテストを作成し（tdd-workflow スキル）、次に tdd-repair を実行してテストを成功させます。
• リグレッションのトリアージ — 以前は成功していたテストが失敗した場合、問題を報告する前に約 1 ドルをかけて、修正が簡単かどうかを確認します。

使用しない場合

• 失敗するテストがない場合。 適合モード（--no-test-oracle）は後続の ADR で扱う予定であり、再現ケースの生成に MCTS が必要です。現時点では、まず失敗するテストを作成してください。
• アーキテクチャの変更。 このスキルは、戦術的な「失敗を成功にする」修正を対象としています。テストを偶発的に壊すモジュール横断リファクタリングは、人間またはスウォームが行うべきです。
• 信頼できないコード。 ヘッドレスの 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 回あたりの一般的な費用	使用するタイミング
1	Haiku	$0.02 – $0.20	まず試す場合 — 「テストを失敗から成功にする」バグの多くは、戦術的な対応で解決できます
2	Sonnet	$0.30 – $2.00	Haiku で解決できなかった場合、またはバグが複数のファイルにまたがる場合
3	Opus	$1.50 – $8.00	Sonnet で解決できなかった場合 — アーキテクチャ上の推論が必要な場合（失敗するテストが 1 つだけなら、割に合うことはほとんどありません）