investigate

調査する

バグを修正する前に、因果関係を示す証拠を確立します。診断のみを求められた場合は、ソースを編集せずに原因と修正方法を報告します。

症状から始める

エラー、失敗するテスト、課題、または確認された動作を読みます。期待される動作と実際の動作を明らかにし、該当する環境で障害を再現します。関連するコード、呼び出し元、データを調べます。検証済みの根本原因が提示されている場合は、調査を繰り返さず、それを活用します。

直接検証できる原因にはクイックモードを使います。最初の仮説が外れた場合は、調査範囲を広げます。パフォーマンス、環境、またはリグレッションの問題については、specialized.md の該当するセクションだけを読みます。

調査する

簡潔な証拠ログを記録します。内容は、観察、仮説、仮説を否定するための確認、結果、次のアクションです。明白なバグなら数件のメモで十分ですが、長期にわたる調査では一時的な成果物に保存します。ログ全体を何度も読み返すことは避けます。

障害が発生する境界を越えて、データの流れを追います。証拠が示す場合に限り、部分的な更新、古い状態、権限、エンコーディング、時刻／ロケール、依存関係、並行処理、外部との契約を確認します。フレームワークの動作を決めつける前に、インストール済み API を確認します。外部情報を調べる場合は、サニタイズした汎用的なエラーと一次情報源を使い、非公開ログや顧客データをアップロードしないでください。

再現、アサーション、トレース、または制御された実験を使って、具体的な因果仮説を検証します。その仮説を否定できる証拠も探します。仮説が複数回外れても、それはモデルと証拠を見直す理由であり、アーキテクチャが誤っている証明ではありません。有用な確認を続けます。入手できない情報や、重要なスコープの判断によって進行が妨げられる場合は、質問します。

修正して検証する

修正が許可され、原因を裏付ける証拠がある場合は、周辺の整理をせず、原因となっているコードを変更します。凍結された契約と無関係な変更はそのまま維持します。ロジック／契約上のバグでは、プロジェクトが対応している場合、意味のあるリグレッションテストを追加し、修正なしでは失敗し、修正後には通過することを示します。明示的に求められた RED の時系列は保持します。

最終ファイルに対して元のシナリオを再現し、その後、適切なテスト／lint を一度実行します。影響を受ける呼び出し元や障害の証拠が必要性を示す場合は、テスト範囲を広げます。編集後は影響を受けるチェックを再実行します。生のログは保存し、テストスイート全体を二度貼り付けるのではなく、結果を要約します。ファイル数だけを理由に、新たな承認を求める必要はありません。

修正を完全に検証できない場合は、未検証と明記し、立証済みとして提供しないでください。テストを弱めたり削除したりして、見かけ上成功させてはいけません。同じ原因が影響する可能性が十分にある関連経路を確認し、より広範なアーキテクチャ変更は別途提案します。

結果

症状、裏付けのある原因、変更したファイル、再現／テストの証拠、残る不確実性、提供状況を報告します。DONE は、要求された修正と必要な検証が完了したことを意味します。DONE_WITH_CONCERNS は、未完了だが進行を妨げないテスト範囲があることを示します。BLOCKED は、不足している情報または権限を明示します。コミット／プッシュ／マージは、既存のタスク承認の範囲内でのみ行います。