report-analyzer-issue

スキル：Report Analyzer Issue

エンジンレベルの問題が疑われる場合に、自己完結型の .opentaint/issues/<slug>.md レポートを作成します。このスキル自体は分析を実行せず、呼び出し元から提供された情報をもとにレポートを作成するだけです。種類は次の2つです。

• analysis issue — ルールやモデルでは解決できなかった、エンジンレベルの taint 伝播に関する問題が疑われるケース（アナライザーの結果が誤っているように見える）
• resource issue — 許可された再試行、メモリ上限、またはタイムアウト時のバックストップを経ても、プロジェクト全体のスキャンで SARIF が生成されなかったケース。taint の診断は行わず、エンジンチームが再現できるよう、問題を引き起こしたセットアップのみを記録します

Inputs

呼び出し元から提供されます。省略された場合はデフォルト値を使用します。必須の入力がなく、妥当なデフォルト値もない場合に限り、確認してください。

• project-root（任意） — 対象プロジェクトのルートです。Opentaint はすべての分析成果物を固定の <project-root>/.opentaint/ ディレクトリの下に保存するため、以下の .opentaint/... パスはすべてそこを基準に解決されます。デフォルト：カレントディレクトリ
• diagnosis（analysis では必須） — 呼び出し元が把握しているエンジンレベルの原因の概要です。taint がどのあたりで失われているように見えるか、その理由を簡潔に記します。確証のあるトレースではなく、短い引き継ぎ情報です。
• artifact（analysis では必須） — issue が対象とするルールまたは近似です。ルールの場合は完全な ID とルールセット、近似の場合は対象のメソッドを指定します。
• name（任意、analysis） — 対象の成果物をトレースしたテストプロジェクト名です。そのツリーは .opentaint/test-projects/<name>、モデルは .opentaint/test-compiled/<name> にあり、エンジンチームが再現できるよう記載します。
• setup（resource では必須） — SARIF が生成されずにスキャンが失敗した際に実行されていた内容です。ルールセット、近似ディレクトリ、プロジェクトモデル、最終的なメモリ上限、タイムアウト／バックストップの結果、スキャンログ、およびコミットハッシュ（git rev-parse HEAD）を含めます。

Workflow

1. Gate

入力によって種類を決定します。diagnosis（および artifact）があれば analysis issue、setup があれば resource issue です。

analysis issue では、呼び出し元が提供した原因の概要をそのまま使って作成してください。自分で検証、再現、実行を行わないでください。これはエンジンチームへの初期段階の概算的な引き継ぎ情報であり、確証のある診断ではありません。呼び出し元から提供された内容だけでレポートを作成できます。

resource issue の条件はより簡単です。呼び出し元が、プロジェクト全体のスキャンで、許可された再試行／バックストップを経ても有効な SARIF が生成されなかったことを確認します。taint の診断は不要です。セットアップの情報をもとにレポートを作成してください。

2. レポートを作成する

.opentaint/issues/<slug>.md に、単独で完結する成果物を作成します。<slug> は症状を表す短いケバブケース名です。エンジンチームがひと目でトリアージできるよう、固定ヘッダーで始め、その下に自由形式の詳細を記述します。

両方の種類に共通するヘッダー：

• Type — analysis または resource
• Setup — 再現するための正確なコマンドです。analysis の場合は opentaint test rule … / test approximation run、resource の場合は失敗した opentaint scan を指定し、それぞれモデル、ルールセット、近似ディレクトリを含めます（resource の場合は最終メモリとタイムアウト／バックストップの結果も含めます）。
• Run logs — 実行のログファイルをパスで示します。analysis の場合は、呼び出し元が挙げたデバッグログまたはファクト到達可能性 SARIF があれば記載します。resource の場合は、スキャンの出力ログを記載します。
• Minimal repro — 問題を示す最小限のファイル／フォルダー一式です。analysis の場合は、名前が示されていればテストプロジェクト .opentaint/test-projects/<name> を記載します。resource の場合は、対象となるプロジェクトモデル、ルールセット、近似ディレクトリをおおよそのサイズとともに記載します。
• TL;DR — 症状を2〜3文で説明します。analysis の場合は、汚染がどこで途切れているように見えるかと、代わりにエンジンがどう動作すべきかも記載します。

ヘッダーの下には自由形式で、少なくとも次の内容を記載します。

• analysis — テスト対象の artifact（ルール ID とルールセット、または近似対象のメソッド）と、呼び出し元が簡潔に説明した原因を記載します。呼び出し元から提供されている場合は、観測結果と期待される結果、ファクト到達可能性のトレースも含めます。エンジンの誤動作に関する仮説を1〜3文で記述します（修正方法ではなく、仮説を記載してください）。
• resource — モデルのおおよそのサイズ（判明していればクラス／モジュール数）と、モデルのビルド元のコミットハッシュ（git rev-parse HEAD）を記載します。

簡潔にまとめます。ヘッダーと本文を合わせて、画面1枚程度にしてください。

出力

成果物

• .opentaint/issues/<slug>.md — 単独で完結する課題レポート（成果物）

概要

• 種類（analysis / resource）と症状を1行で記載します。analysis の課題の場合は、汚染がどこで途切れているように見えるかも記載します。