diagnose

診断

バグを引き起こすメカニズムを特定します。このスキルは診断を行うものであり、診断後にユーザーから実装を明示的に依頼されない限り、修正は実装しません。

triangulate-diagnosis から呼び出された場合は、指定された観点を使用し、 triangulate-diagnosis/REFERENCE.md に記載された 「診断レポート」の形式に厳密に従って回答します。

入力

次のいずれでも受け付けます。

• バグ報告、エラーメッセージ、期待どおりに動作しない状況、スクリーンショット、ログ、または貼り付けられたスタックトレース。
• 再現手順または失敗するテスト。
• すでにコンテキスト内で利用可能なローカルの課題、仕様、チケット、PR、コミット、ブランチ、またはファイルパス。
• triangulate-diagnosis から指定された診断の観点：再現優先、データフロー、または最近の変更／環境。

症状または対象となるリポジトリ領域が曖昧で着手できない場合に限り、簡潔な質問を1つだけしてください。それ以外の場合は、前提を明示して作業を進めてください。

シークレットを安全に扱うためのエビデンス境界

診断コマンド、出力、または成果物を表示、引用、委任、または永続的に記録する前に、シークレットの編集境界を適用してください。診断上の判断材料となる最小限の非シークレット情報は残しつつ、シークレット値とシークレットを含む引数を<REDACTED>に置き換えてください。フィードバックループを構築する際は、認証情報そのものではなく、環境変数への参照を使用してください。

編集によって、残りの仮説を見分けるのに必要なエビデンスが失われる場合は、その境界で作業を止め、安全に編集された成果物、または別途承認された計測手段のみを求めてください。未編集のシークレットを求めたり、繰り返し出力したり、永続的に記録したりしてはいけません。

プロセス

1. 症状と範囲を言い換える

簡潔な作業概要を記述します。

• 観測された動作。
• 期待される動作。
• 影響を受けるエントリーポイント、モジュール、ワークフロー、またはコマンド。
• 制約と対象外事項。
• すでに利用可能なエビデンス。

事実に基づいて記述してください。原因を決めつけてはいけません。

2. フィードバックループを構築する

自動再現を優先します。

• 既存の失敗するテスト。
• 新たに作成する、対象を絞った失敗するテスト。
• 最小限のスクリプト、コマンド、curlリクエスト、フィクスチャ、リプレイ、または手動の一連の手順。

ループを構築できない場合は、不足している成果物やアクセス権を特定するところまでにとどめてください。最終的な確信度は低いと明記します。

3. 現在の動作を調査する

観測可能な症状から原因となる境界に向かって、バグの経路をたどります。

• 入力、永続化された状態、設定、環境、フィーチャーフラグ。
• 影響を受ける経路上の呼び出し元と呼び出し先。
• エラー処理、フォールバック経路、キャッシュ、タイミング、並行処理。
• 関連する場合は、最近の変更、マイグレーション、依存関係の変更、またはデプロイの差異。

調査の範囲は症状に見合うものにしてください。広範な検索を始める前に、近接するコードとテストを確認します。

4. 仮説を立て、反証する

候補となるメカニズムを短く列挙します。重要な候補ごとに、次のことを行います。

• メカニズムを具体的に示す。
• それが正しい場合に、どのようなエビデンスが得られるか予測する。
• 確認または反証できる最小限のチェックを実行する。
• 具体的なエビデンスとともに、除外した別の可能性を記録する。

「このコードは怪しい」というだけでエビデンスとみなしてはいけません。

5. 根本原因を特定する

エビデンスによって、症状を引き起こすメカニズムが特定された時点で調査を終了します。起点となるファイル、モジュール、インターフェース、データ境界、または設定元を明示します。行番号が安定していて役に立つ場合は使用しますが、長期的に参照しやすいモジュール名や関数名を優先してください。

複数の原因が依然として考えられる場合は、単一の回答に無理にまとめず、可能性ごとの分岐を報告します。

6. 修正方針を推奨する

整合性のある最小限の修正箇所と方針を説明します。

• 何を変更すべきか。
• その変更が、なぜメカニズムに対処できるのか。
• 修正を実証するには、どのテストまたはフィードバックループを使うべきか。
• 注意すべきリスクや周辺の動作。

同じターンでユーザーからバグ修正を明示的に依頼されていない限り、ファイルを編集してはいけません。

出力

次の形式を使用します。

## Diagnosis Report - lens: <single-pass | repro-first | data-flow | recent-change>

### Root cause
<One paragraph: the mechanism that produces the symptom and where it originates.>

### Evidence
- <Concrete observation from a test, command, log, instrumentation, code path, or trace.>

### Feedback loop built
<Failing test, command, script, replay, or manual sequence. State if none could be built.>

### Fix location and approach
<Where the fix goes and the smallest coherent shape of it.>

### Alternatives ruled out
- <Hypothesis and the evidence that falsified it.>

### Confidence: <high | medium | low>
<One line explaining the confidence level.>

ユーザーが実装も依頼している場合は、まず診断を完了してから、依頼された修正を進めるか、依頼されたワークフローに応じて to-spec、to-tickets、または execute-ticket に結果を引き継ぎます。