dx-devops-test-failures-analyze

DevOps Center のテスト失敗を分析する

テスト失敗または Code Analyzer 違反のペイロードを解析し、平易な言葉で説明して、優先順位を付けた改善案を提示します。また、ユーザーから明示的な依頼があった場合に限り、追跡可能な修正作業項目を作成します。パート 1～2 は推論のみ（書き込みなし）で、パート 3 は任意の、確認を必須とする書き込み操作です。

生の JSON、スタックトレース、内部 Salesforce エラーコードをユーザーに決して見せないでください。 必ずファイル名、メソッド、行番号、平易な説明に置き換えてください。

---

前提条件

• パート 1～2（分析）： 失敗のペイロードがすでにコンテキスト内にある場合、前提条件は必要ありません。これは推論のみの処理です。ペイロードを自分で取得する必要がある場合は、前提条件（references/prerequisite-checks.md、Prereqs 1～4）を実行し、dx-devops-test-suite-run（ポーリング手順）で実行結果を取得してください。
• パート 3（作業項目）： Prerequisites 1～4 を実行してください。また、作業項目の登録先となる DevopsProjectId と、担当者となる OwnerId が必要です。references/work-item-creation.md を参照してください。

---

パート 1 — 各失敗を分類して説明する

失敗のカテゴリを特定し、各失敗について、該当するファイル／クラス、メソッド、行番号、違反したルールまたはアサーション、修正の方向性（コードは記述しない）を抽出して、平易な言葉で説明してください。複数のカテゴリがある場合は、カテゴリごとに失敗をまとめてください。

カテゴリ	説明
アサーション失敗	テストのアサーションが失敗した（期待値と実際の値が一致しない）
例外	未処理の例外がスローされた
Code Analyzer 違反	静的解析ルールに違反した（例：ApexCRUDViolation）
タイムアウト	テストの実行時間が制限を超えた
コンパイルエラー	クラスのコンパイルに失敗した

出力形式：

Test failure summary:

<N> failure(s) found:

1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
   What happened: <plain-language description>
   Rule violated: <ruleName or assertion description>
   Fix direction: <plain-language suggestion>

カテゴリ／パターンの全一覧と Code Analyzer ルールの翻訳については、references/failure-categories.md と references/code-analyzer-violations.md を参照してください。

空／データなしの場合： ペイロードに失敗や違反が含まれていない場合は、その旨を明確に報告してください（例：「提供された実行結果に失敗は見つかりませんでした。」）。その後、処理を終了してください。失敗や提案を捏造しないでください。

---

パート 2 — 改善案

これは、静的ソースではなく、実行が失敗を伴って完了した後に実行してください。失敗したテストごとに、失敗メッセージ（最も重要な手掛かり）からテストが処理できていない内容を推測し、具体的で実行可能な提案と修正箇所（Test または Production code）を提示してください。失敗パターンから提案への対応表の全一覧は、references/failure-categories.md にあります。

Test improvement suggestions based on execution results:

`<testMethodName>()` — [Assertion Failure / Exception / etc.]
Failure: "<failure message>"
What this reveals: <plain-language explanation>
Suggestion: <specific, actionable recommendation>
Fix location: Test | Production code

Overall: <N> improvement(s) across <M> failed test(s).

テストを書き直さないでください。変更が必要な内容と理由だけを説明してください。修正箇所：Production code は、妥当なテストで明らかになったコードの不具合を示します（テスト品質上の阻害要因とは分けて追跡してください）。修正箇所：Test は、テストの強化（セットアップ、アサーション、エッジケース）が必要であることを示します。

---

パート 3 — 修正作業項目を作成する（任意、依頼があった場合のみ）

ユーザーが修正作業項目の作成、修正内容の記録、または開発者への失敗の割り当てを希望した場合にのみ開始してください。これは、確認を必須とするゲートを設けた書き込み操作です。入力項目、件名／担当者／プロジェクトの確認ゲート、sf data create record --sobject WorkItem の呼び出し、エラー処理については、references/work-item-creation.md に従ってください。

WorkItem（名前空間なし）を使用してください。DevopsWorkItem は、この組織のバージョンでサポートされている sObject ではありません。

組織に DevopsProject が存在しない場合は、プロジェクトがセットアップされるまで作業項目を作成できないことを報告してください。プロジェクトを捏造したり、処理を進めたりしないでください。

---

関連スキル

• dx-devops-test-suite-run — このスキルに渡す失敗のペイロードを（ポーリング手順で）生成します。
• dx-devops-test-suite-assignments-configure — テストが失敗しているスイートを割り当てたり、強化したりします。
• platform-apex-generate / platform-apex-test-generate — 修正コードや新しいテストクラスを実際に記述します（ここでは対象外です）。