debug-mode

デバッグモード

証明された原因だけを修正してください。一度だけテストに通るもっともらしい修正では、何も証明されません。 すでにデバッグモードの実行中であれば、ループを続けてください。

ユーザーが使った動詞を尊重してください。diagnose は Fix の前で終了し、修正は適用しません。 報告する前に、一時ログをすべて削除してください。 debug、または動詞のないバグ報告では、Fix まで実行します。

ワークフロー

1. 把握する。 症状、影響を受ける範囲、期待される動作、実際の動作、再現手順がわかれば完了です。
2. 失敗ループ。 バグのコードパスを実行し、その正確な症状を検証するコマンドを1つ作成します。失敗するテスト、curl スクリプト、フィクスチャを使った CLI の実行、ヘッドレスブラウザーのスクリプト、再生したトレースなどが該当します。決定論的で、高速で、無人で実行でき、単に「クラッシュしなかった」ではなく症状を検証する、簡潔なものにしてください。再現が不安定なバグの場合は、トリガーをループさせる、ストレスを加えるなどして再現率を上げ、デバッグ可能になるまで続けてください。コードが遅い場合、このループはベースラインの計測（計測ハーネス、プロファイラー、クエリプラン、本番環境のトレース）とし、明示したしきい値を超えたら失敗するようにします。実用的なコマンドを用意できない場合（認証が必要、ユーザー固有、本番環境限定など）は、その旨を伝え、手順5〜6の計測に頼ってください。このバグでコマンドが失敗したことを確認するか、失敗していないことを明記すれば完了です。
3. 最小化する。 ループがある場合は、入力、呼び出し元、設定、データ、手順を一つずつ削り、そのたびにループを再実行して再現を縮小します。残った要素がすべて必要になれば完了です。どれか一つを削るとループが成功する状態にしてください。ループがない場合は、手順4に進みます。
4. 仮説を立てる。 2〜3個の仮説に優先順位を付け、それぞれを確認または否定する観察事項を明示すれば完了です。
5. 計測する。 コードが遅い場合は、最小化した再現をプロファイリングするか、既知の正常な状態と異常な状態の間を二分探索します（ループを使って git bisect run を実行）。それ以外の場合は、一時的なログを追加します。秘密情報を漏らしたり動作を変えたりすることなく、観察結果から仮説を区別できれば完了です。動作が変わる場合は、より影響の少ない箇所から観察してください。
6. 再現する。 バグを引き起こし、証拠を収集できれば完了です。ループがある場合は、それを使ってください。認証が必要なフローやユーザー固有のフローの場合は、ユーザーに再現を依頼して待ちます。
7. 分析する。 証拠によっていずれかの仮説を裏付けるか、現在の仮説をすべて明確に否定できれば完了です。すべて否定された場合は、証拠に基づいて新しい仮説を立て、手順5に戻ります。
8. 修正する。 実際のバグパターンを通るシームがある場合は、まず最小化した再現を回帰テストにします。証拠に裏付けられた最小限の修正を適用し、元のシナリオでループ（ある場合）が成功し、一時ログがすべて削除されれば完了です。

ログ

• アプリ独自のロガーまたはローカルファイルを使って、構造化イベントを記録します。記録する項目は、hypothesis_id、event、1回のユーザー操作を関連付けるリクエスト ID またはセッション ID、観測値、タイムスタンプです。
• すべての一時ログに、一意のプレフィックス（例：[DEBUG-a4f2]）を付けます。これにより、grep 1回で削除できます。

報告形式

以下の形式で終了します。

## Symptoms
## Hypotheses Tested
## Evidence Collected
## Confirmed Root Cause
## Fix Applied
## Instrumentation Removed
## Residual Risk

修正を適用していない場合は、その旨を Fix Applied の下に記載し、不足している証拠を明示してください。