/auto-debug

description: テストエラーを解消するための自動デバッグプロセス。全テストケースの確認からエラー原因の調査、修正まで段階的に実行し、テストケースの成功率向上を目指します。
allowed-tools: Read, Glob, Grep, Task, Edit, Write, TodoWrite
argument-hint: "[テストファイルパス（省略可）]"

テストエラーを解消して。

step

step1: 失敗テストの特定

1. **グローバルラウンドカウンタの初期化**

• `global_round: 0` — step3→step2の外側ループ回数
• `max_global_round: 3` — 最大ラウンド数

2. **テストコマンドの決定**

• tasknote（`./docs/implements/**/note.md`）に `test_command` フィールドがあればそこから読み取り
• tasknoteにない場合、以下の順序で情報を収集して決定:
• **a. プロジェクトドキュメントの確認**（存在するもののみ読み取り）:
• `CLAUDE.md` — テスト実行方法、開発ルール、プロジェクト固有の指示
• `README.md` — プロジェクトのセットアップ手順、テスト実行方法
• `AGENTS.md` — エージェント向けの開発ルール、テスト関連の指示
• これらにテスト実行コマンドの記載があればそれを優先採用
• **b. プロジェクト設定ファイルから自動検出**（a で確定しなかった場合）:
• `playwright.config.ts` / `playwright.config.js` が存在 → `npx playwright test`
• `pytest.ini` / `pyproject.toml`（`[tool.pytest]`セクションあり）が存在 → `pytest`
• `package.json` の `scripts.test` が定義されている → `npm test`
• `Makefile` に `test` ターゲットがある → `make test`
• いずれにも該当しない → `npm test`（フォールバック）
• 検出結果を tasknote に記録（tasknoteが存在する場合）
• 以降の全ステップで検出したコマンドを `{{test_command}}` として使用

3. **全テストケースの確認（簡潔モード）**

   timeout 300 {{test_command}} 2>&1

• **--verboseは使用しない**（成功テストの詳細出力はトークンの無駄）
• 失敗しているテストファイル名のみをリスト化
• テストファイルごとにグループ化
• **タイムアウト発生時**: /tsumiki:timeout-fix コマンドを subagent（general-purpose）で実行
• timeout-fix 成功 → テスト再実行
• timeout-fix 失敗（テスト分離成功） → 分離されたテストをレポートに記載し、残りのテストで続行
• timeout-fix 失敗（分離も不能） → タイムアウトとしてレポート（step5）に報告し終了

4. **ビルドエラーの判定**

• テスト出力を解析し、以下のパターンを検知:
• コンパイルエラー（SyntaxError, TypeError at compile time, Cannot find module 等）
• TypeScript型エラー（TS2xxx系エラー）
• 依存パッケージ未解決（Module not found, Cannot resolve 等）
• **ビルドエラーの場合**:
• /tsumiki:build-fix コマンドを subagent（general-purpose）で実行（test_command と error_output を渡す）
• build-fix 成功 → テスト再実行して step1-3 の結果確認に戻る
• build-fix 失敗 → ビルドエラーとして最終レポート（step5）に報告し終了
• **テストエラーの場合**: 通常通りstep2へ進む

5. **失敗テストをTODOに登録**

• TodoWrite ツールで各失敗テストをTODO項目として登録
• 優先度を設定（重要度: 高/中/低）
• メタデータに以下を含める:
• `retry_count: 0` - リトライ回数の初期値
• `max_retry: 3` - 最大リトライ回数
• `status: pending` - 処理状態（pending/in_progress/resolved/on_hold）

step2: テストファイル単位での修正

**各失敗テストファイルに対して以下を実施（最大3回まで）**:

1. **リトライカウンタの初期化**

• 各テストファイルのリトライ回数を0に設定
• 保留テストリストを初期化（空のリスト）
• 修正履歴リストを初期化（空のリスト）

2. **該当テストファイルのみを実行して詳細確認**（ここでのみ--verbose使用）

   timeout 120 {{test_command}} -- <失敗したテストファイル> --verbose

• 失敗テストの詳細なエラーメッセージ・スタックトレースを取得
• **タイムアウト発生時**: /tsumiki:timeout-fix コマンドを subagent で実行（test_file を指定）
• 成功 → テスト再実行
• 失敗 → レポートに記載して次のテストファイルへ

3. **flaky test の検知**

• テストが失敗した場合、**即座に同じテストを1回だけ再実行**

   {{test_command}} -- <失敗したテストファイル> --verbose

• 2回目に成功した場合: **flaky test と判定**
• /tsumiki:flaky-fix コマンドを subagent（general-purpose）で実行（test_file と error_output を渡す）
• flaky-fix 成功（3回連続成功） → 安定化済みとして通常フローに復帰（修正済みテストとして次のテストファイルへ）
• flaky-fix 失敗 → 従来通り flaky test として記録し、修正対象から除外。次のテストファイルへ
• 2回目も失敗した場合: 安定した失敗と判断し、次の分析ステップへ

4. **エラー原因の構造化分析**

• Task tool (subagent_type: Explore, thoroughness: **medium**) を使用
• **以下のエラー分類フレームワークに従って分析**:
• 🔧 **コードバグ**: 実装コードのロジックエラー、型ミス、計算ミス等
• 🧪 **テストバグの疑い**: テストの期待値が仕様と不整合、テストのセットアップ不備等
• ⚙️ **設定・環境問題**: パス設定ミス、環境変数不足、設定ファイル不備等
• 📦 **依存関係問題**: パッケージバージョン不整合、未インストール等
• 分類結果と修正方針を決定
• **リトライ2回目以降**: 修正履歴（前回の修正内容・失敗原因）を分析プロンプトに含める

5. **テストバグの疑い判定**

• エラー分類で「🧪 テストバグの疑い」と判定された場合:
• 保留リストに追加（保留理由: 「テスト自体のバグの可能性」）
• 詳細な根拠を記録（どの部分がなぜテストバグと疑われるか）
• **このテストファイルの修正は行わず、次のテストファイルへ進む**

6. **環境・依存関係問題の委譲**

• エラー分類で「⚙️ 設定・環境問題」または「📦 依存関係問題」と判定された場合:
• /tsumiki:env-fix コマンドを subagent（general-purpose）で実行（test_command, test_file, error_output, error_classification を渡す）
• env-fix 成功 → テストを再実行し、成功すれば次のテストファイルへ
• env-fix 失敗 → 保留リストに追加（保留理由: env-fix の結果レポートを含める）。次のテストファイルへ

7. **修正実装**（エラー分類が「🔧 コードバグ」の場合）

• <green_task> をTask ツールで直接実行して修正
• パラメータとしてエラーの原因、該当テストファイル、**エラー分類結果**を渡す

8. **該当テストファイルのみを再実行**

   {{test_command}} -- <修正したテストファイル>

9. **リトライ判定**

• ✅ 成功: **修正履歴に「成功」を記録**し、次のテストファイルへ
• ❌ 失敗かつリトライ回数 < 3:
• リトライ回数を+1
• **修正履歴に「失敗: [エラー内容] / 試みた修正: [修正内容]」を記録**
• step2の4に戻って再分析（修正履歴を引き継ぐ）
• ❌ 失敗かつリトライ回数 >= 3:
• このテストは保留リストに追加
• 保留理由を記録（例: "3回の修正試行後も解消できず"）
• **修正履歴全体を保留理由に含める**
• 次のテストファイルへ進む

step3: 全テスト実行による確認

**全ての失敗テストの修正試行が完了した後**:

1. **全テスト実行（簡潔モード）**

   {{test_command}} 2>&1

• **--verboseは使用しない**（全テストの通過確認のみが目的）

2. **結果確認**

• 新たに失敗したテストがないか確認
• 既存のテストが通ることを確認
• 保留テストの状態を確認

3. **追加修正が必要な場合**

• **グローバルラウンドカウンタをチェック**:
• global_round < max_global_round（3）の場合:
• global_round を +1
• 新規失敗テスト: step2に戻って対応（リトライ回数0から開始）
• global_round >= max_global_round（3）の場合:
• **新規失敗テストはすべて保留リストに追加**
• 保留理由: 「グローバルラウンド上限（3回）到達。カスケード障害の可能性」
• step4へ進む
• 保留テストの再試行: ユーザーに確認後、step2に戻って対応

step4: リファクタリング

**全テストが通った後（または保留テストのみ残っている場合）**:

1. <refactor_task> をTask ツールで直接実行してリファクタリングを実施

2. **リファクタリング後の全テスト再検証**

   {{test_command}} 2>&1

• リファクタリングによる回帰がないか確認
• 新たな失敗が発生した場合: リファクタリングによる問題としてレポートに記録（step2には戻らない。リファクタリング起因の問題は手動対応を推奨）

step5: 最終レポート

**最後に全体のテストの成功率を確認してレポート**:

# テストエラー解消レポート

## 結果サマリー
- テストコマンド: {{test_command}}
- 修正前の失敗テスト数: XX個
- 修正後の失敗テスト数: XX個
- 解消したテスト数: XX個
- 保留したテスト数: XX個
- flaky test数: XX個（安定化成功: XX個 / 未解消: XX個）
- テストバグの疑い: XX個
- 環境依存問題: XX個（自動修正: XX個 / 未解消: XX個）
- タイムアウト: XX個（改善: XX個 / 分離: XX個 / 未解消: XX個）
- グローバルラウンド実行回数: X/3
- テスト成功率: XX%

## ビルドエラー（テスト実行前に検出）
（ビルドエラーがあった場合のみ記載）
- エラー種別: [コンパイルエラー / 型エラー / 依存パッケージ未解決]
- build-fix 結果: [成功（自動修正済み） / 失敗]
- エラー内容: [エラーの詳細]
- 推奨対応: [手動での修正が必要な理由と方針]

## 修正内容
1. test/user.test.js
   - エラー分類: 🔧 コードバグ
   - エラー原因: データベース接続エラー
   - 修正内容: 接続プールの初期化を修正
   - 実行時間: 15秒 → 2秒
   - リトライ回数: 1回

2. test/file.test.js