diagnose

診断

モデルを選択する前に、ブランチを選んでください。調整作業と決定論的なコマンドは、呼び出し権限の範囲内で進めます。現在のロールでこの方法を適用してください。ワーカーへのディスパッチは行いません。ワーカーをディスパッチする場合は、shared/references/model-preview.md と、そこで承認されている唯一のルートスナップショットを使用してください。ネストされたスキルとランナーは、再選択やワーカーなしでこれを使用します。

観察された失敗の証拠と関連コードから原因を特定します。パターン照合は診断ではありません。見慣れた症状から得られるのは仮説です。症状 → メカニズム → 原因を結び付けるのが、証明の成果物です。

このつながりが裏付けられれば、診断は完了です。調査で原因を特定できない場合は、残る不確実性と、それを解消するために必要な証拠を報告してください。依頼で許可されている場合は、修正を適用してください。

証拠を確認する

提供されたエラー、ログ、トレース、値、失敗したテスト結果、およびそれらが示すコードパスを確認してください。その証拠が、影響を受けるバージョンと条件に当てはまることを確認します。現在のタスクで得られた十分な証拠は再利用してください。

新たにローカルで再現しなくても、既存の証拠で原因を証明できる場合があります。たとえば、次のように関連性を説明します。「トレースが証明の成果物です。再試行時に接続が開いたままになるため、プールが枯渇します。」

未解決の疑問に対処する

残る不確実性を解消できる手法だけを使用してください。

1. 必要に応じて再現します。 未解決の仮説を確認または否定できるコマンド、入力、環境を選びます。正確なコマンドと出力を記録してください。
2. 試行回数に上限を設けます。 プローブを繰り返す前に、試行回数または時間の上限を設定します。依頼者から上限が提示されている場合は、それを使用してください。証拠によって疑問が解消されたとき、または上限に達したときに停止します。失敗を繰り返しても、上限はリセットされません。
3. 必要に応じて最小化します。 考えられる原因を切り分けられる場合、または利用可能な回帰テストケースを作成できる場合は、入力やセットアップを簡素化します。
4. 原因を識別できる最も低コストのプローブを選びます。 複数の原因が考えられる場合は、結果によって原因を区別できるプローブを選びます。証拠によって原因が確立した後に、別の可能性を作り出してはいけません。
5. 不足している証拠を計測します。 既存の証拠だけでは不十分な場合に限り、対象を絞ったログ、アサーション、ブレークポイントを追加します。失敗状態を保持し、タイミングや動作への影響を考慮してください。

プローブを実行できない場合、または失敗を再現できない場合は、その結果を記録してください。原因の解明に役立つ、他に利用可能な証拠を使って調査を続けます。調査上限に達しても不確実性が残る場合は、裏付けられたつながり、未解決の仮説、および不足している最小限の証拠を報告してください。

修正と検証

コード修正が許可されている場合：

1. 変更が、証明されたメカニズムにどう対処するかを説明します。
2. tdd を適用し、そのメカニズムを回帰テストに反映します。修正前に想定どおり失敗し、修正後に成功することを確認してください。焦点を絞ったテストであれば、本番環境のインシデント全体を再現せずにメカニズムを確立できる場合があります。すでに記録されている有効な失敗テストの証拠は再利用してください。
3. 修正の影響を受けるチェックを実行し、その結果を記録します。必須の検証を実行できない場合は、その制約を報告し、修正が未確認であることを明示してください。
4. 診断中に追加した一時的な計測とスクラッチ再現コードを削除します。回帰テスト、有用な証拠記録、および実際の不変条件を保護するアサーションは残してください。

評価の依頼は、診断と証拠の提示で終了します。実装や新たな回帰テストは必要ありません。

証拠のルール

1. プロセスを再起動したり状態をクリアしたりする前に、関連する証拠を保存します。
2. プローブごとに変更する変数は1つにし、結果からその影響を特定できるようにします。
3. 複数のコード変更で症状が消えた場合、どの変更が原因を解決したかを主張する前に、それぞれの影響を切り分けます。
4. 因果関係を裏付けられない場合は、未解決として明示します。テストが成功したことや症状が消えたことだけでは、原因は確立されません。

パイプラインモード（mode:pipeline）

質問のために作業を中断しないでください。呼び出し元のパイプラインのエスカレーションルールと、shared/references/pr-watch-contracts.md のステータス用語に従ってください。

{
  "status": "fixed-and-pushed | diagnosed-no-fix | flaky-infra | needs-human",
  "reproduced": true,
  "root_cause": "<causal chain: symptom → mechanism → cause>",
  "evidence": "<the artifact of proof>",
  "fix": "<commits or diff, null when no fix>",
  "regression_test": "<test name/path, or null>",
  "residuals": [{ "title": "...", "decision_context": "..." }]
}

再現をこの実行中に確認した場合、または提供された再現の証拠によって裏付けられる場合にのみ、reproduced を true に設定してください。それ以外の場合は false に設定してください。evidence では、再現が不要だった場合、再現できなかった場合、または試みたものの失敗を再現できなかった場合を区別してください。

ログやトレースによって原因が証明されている場合は、false と併記できます。原因が不明のままの場合は、その旨を root_cause に記載し、証拠の不足を residuals に記録してください。修正が検証され、承認されたプッシュが成功した場合にのみ、fixed-and-pushed を使用してください。

境界

1. tdd がテスト実行のループを担当します。原因が把握された失敗テストは、そのループ内にとどめてください。
2. fable-mindset が証拠の扱い方を担当します。このスキルでは診断手法を提供します。
3. safe-incremental-coding は、既存の未テスト動作を保護します。その動作が予期せず、その原因を調査する必要がある場合は、この手法を適用してください。