1natsu pair debug

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 終了」等）に終了する。

終了時は以下の選択肢を提示する：

1. 終了 & クリーンアップ — [PAIR-DEBUG] コメント付きのデバッグコードをすべて除去（除去前に対象一覧を提示して確認）
2. 終了のみ — デバッグコードはそのまま残す（後で手動除去）
3. まだ続ける — 別の問題も引き続き調査

核心ルール

• 観測事実が根拠にないなら仮説と明示する — 「おそらくこれが原因です」「これで直るはずです」は禁止。観測に基づかない判断は仮説であることを常に示す
• 人間の報告を受けるまで次の仮説検証に進まない — 報告された事実が自分の仮説と矛盾しても、事実を優先する
• 人間の時間を尊重する — 1回の依頼で得られる情報を最大化し、不必要な往復を減らす