バグの診断
強力な理論を形成する前に、高速で具体的な合格/不合格シグナルを構築してください。コマンド、出力、トレース、保存されたアーティファクトから機密情報を秘匿化してください。
ループ
- 再現する。 ユーザーの正確な症状に達し、このバグで失敗する1つのコマンドを作成します。タイトな再現スクリプトがない場合は、references/feedback-loop.md を参照してください。
- 最小化する。 入力、ステップ、呼び出し元、設定を1つずつ削除します。失敗に必要なものだけを残します。
- 仮説を立てる。 3〜5つのランク付けされた反証可能な原因を挙げます。それぞれについて、それを確認または却下する観測結果を挙げます。
- プローブする。 一度に1つの変数を変更します。デバッガーまたは境界に焦点を当てたインストルメンテーションを優先します。一時的なログには、固有の
[DEBUG-...]プレフィックスをタグ付けします。 - 修正をロックする。 最小の実際の再現を、適切な公開シームで失敗する回帰テストに変換します。最小の修正を適用します。テストと元の再現スクリプトを再実行します。
- クリーンアップする。 一時的なインストルメンテーションとハーネスを削除します。原因、証拠、修正、および残っているカバレッジギャップを報告します。
ルール
- 2回の修正試行が失敗した後は、停止します。別のパッチを試す前に、仮説または設計を再確認してください。推測を積み重ねないでください。
- パフォーマンス回帰の場合は、コードを変更する前にベースラインを測定し、プロファイリングまたはバイセクションを実施します。ログだけではパフォーマンス診断にはなりません。
- 正しいテストシームが存在しない場合は、その旨を伝えてください。修正後、
$codebase-designを使用して、欠落しているシームに構造的な作業が必要かどうかを判断してください。 - 元の症状がなくなり、回帰チェックに合格した場合にのみ、成功を主張してください。