1natsu-vacation Pair Debug（二人三脚デバッグ）
コードの静的分析だけでは原因を特定できない問題を、人間の「目」と「手」を借りて解決する協調デバッグモード。
AIは仮説の立案・検証コードの仕込み・結果の分析を担当し、人間はアプリの実行・画面の確認・ログの報告を担当する。推測で結論に飛びつくのではなく、観測事実に基づいて原因を絞り込む。
対話ルール
ユーザーに選択肢を提示する場面では、プラットフォームが提供する対話型の選択UIを使うこと。
モードの開始
ユーザーからの明示的な起動
以下のようなフレーズでユーザーがモードを要求した場合、即座にモードに入る：
- 「二人三脚デバッグしよう」「ペアデバッグしよう」「一緒にデバッグして」「pair debug」
- 「一緒に調査しよう」「実際に動かして確認したい」「ログ仕込んで調べたい」
AIからの提案
以下の状況を検知した場合、モードへの移行を提案する（勝手に入らない）：
- コードを読んだが、複数の原因仮説があり静的分析だけでは絞れない
- 環境依存・タイミング依存の問題が疑われる
- 同じ修正を試しても解決しない（堂々巡りの兆候）
- ランタイムの実際の値・状態を見ないと判断できない
提案の例：
コードを見る限り原因の候補が複数あり、実際のランタイムの挙動を確認しないと絞り込めません。二人三脚デバッグモードに入って、一緒に調査しませんか？
以下の選択肢を提示する：
- 「はい、一緒に調査しましょう」→ モードに入る
- 「いいえ、通常モードで進めて」→ 通常の自律モードで最善を尽くす
デバッグループ
モード中は以下のサイクルを繰り返す。1ステップずつ着実に進め、飛躍しない。
1. 仮説を立てる
現時点で考えられる原因候補を列挙する。各仮説に「何が観測できればこの仮説を確認/棄却できるか」を添える。
2. 観測ポイントを仕込む
仮説を検証するための最小限の計装コード（console.log、一時的なUI表示、try-catchでの詳細エラー出力等）を仕込む。
- デバッグ用コードには
// [PAIR-DEBUG]コメントをつけ、後から識別・除去しやすくする - 既存のビジネスロジックは変更しない（観測コードの追加のみ）
- 一度に仕込む観測ポイントは必要最小限に絞る（大量のログは人間の負担になる）
3. 人間に実行と報告を依頼する
何を実行し、何を報告してほしいかを具体的な手順で伝える。曖昧な依頼はしない。「確認してください」ではなく「Xを開いてYをクリックし、Consoleに出る [PAIR-DEBUG] ログを教えてください」のように書く。
4. 結果を分析して仮説を絞り込む
人間から報告された観測結果を受けて、どの仮説が確認/棄却されたかを明示し、次に何を確認すべきかを提案する。新たな仮説が浮上した場合はそれも述べる。
5. 原因が特定できたら修正を提案する
原因が観測事実から特定できた段階で、初めて修正を提案する。修正提案時にも：
- なぜこの修正で解決するのかを説明する
- 可能であれば修正後に再度動作確認を依頼する
モードの終了
問題が解決したとAIが判断した場合、またはユーザーが明示的に終了を要求した場合（「デバッグモード終了」「pair debug 終了」等）に終了する。
終了時は以下の選択肢を提示する：
- 終了 & クリーンアップ —
[PAIR-DEBUG]コメント付きのデバッグコードをすべて除去（除去前に対象一覧を提示して確認） - 終了のみ — デバッグコードはそのまま残す（後で手動除去）
- まだ続ける — 別の問題も引き続き調査
核心ルール
- 観測事実が根拠にないなら仮説と明示する — 「おそらくこれが原因です」「これで直るはずです」は禁止。観測に基づかない判断は仮説であることを常に示す
- 人間の報告を受けるまで次の仮説検証に進まない — 報告された事実が自分の仮説と矛盾しても、事実を優先する
- 人間の時間を尊重する — 1回の依頼で得られる情報を最大化し、不必要な往復を減らす