verify-llm-artifacts

LLM アーティファクトの検出結果を検証する

.beagle/llm-artifacts-review.json を対象とした2回目の検証です。検出パスでは再現率を重視しますが、このパスでは適合率を重視し、エージェントがまだ必要なコードを削除したり「整理」したりしないようにします。

実行するタイミング

• review-llm-artifacts スキルの実行後（特にプロジェクト全体のスキャン後）。
• 検出結果に削除、デッドコード、またはリスクが高の項目が含まれている場合、fix-llm-artifacts スキルの実行前。
• 過去の実行で、削除すべきでないアーティファクトが検出された場合。

入力

• 必須： 完了したレビューの .beagle/llm-artifacts-review.json。
• 任意： $ARGUMENTS — --priority-only（最初に dead_code と fix_action が delete の項目を検証し、その後、残りを検証）、--id N（単一の検出結果 ID）。

レビュー用ファイルが見つからない場合は、Run the review-llm-artifacts skill first. を表示して終了します。

前提となるスキル

1. review-verification-protocol スキルを読み込みます。誤検出を防ぐための一般的な手順が記載されており、捏造防止ゲート（判定前に、読み直したソースからアーティファクトを復唱すること）も含まれます。ステップ1の読み込み＋復唱ゲートは、このルールを本スキルに具体的に適用したものです。
2. llm-artifacts-detection スキルを読み込みます。実際の問題とみなす項目のカテゴリ別基準が記載されています。

手順

必須ゲート

検証が完了したと宣言する前に満たすべき客観的な合格条件です。

1. 入力の解析： ステップ1の JSON 読み込みコマンドが終了コード 0 で終了する（トレースバックが発生しない）。合格： .beagle/llm-artifacts-review.json に有効な JSON が保存されている。
2. 判定前の復唱： ステップ1で、このターンに解析した JSON を情報源として、検出結果の表全体（findings[] の各項目につき1行：ID、ファイル、行、カテゴリ、説明）が出力されている。合格： 表が出力に含まれ、行数が len(findings) と一致している。表を出力する前に判定を始めていない。
3. ID の固定： ステップ1で findings[] の正確な ID セットを記録し、明示している。すべての results 項目が固定済みの ID に1対1で対応しており、追加も欠落もない。合格： 固定済みの ID リストが出力されている。対応する固定済み ID のない検出結果と思われる項目が見つかった場合は、その時点で停止する（ステップ1「ID の固定」を参照）。
4. 判定前の証拠： 判定を行う各検出結果について、その category に応じてreferences/verification-checklist.mdを適用する（またはカテゴリが該当しない理由を記録する）とともに、一致した文字列を checks_performed に記録している。合格： チェックリストに基づく確認が少なくとも1つあるか、notes に該当しない旨が明記されていない status がない。
5. 出力の契約： .beagle/llm-artifacts-verification.json の書き込み後、ステップ4の検証コマンドが終了コード 0 で終了する。summary の件数が status 別の results 項目数と一致し、results の ID セットがゲート3で固定した ID セットと完全に一致する。合格： スキーマに適合した JSON があり、results の ID == 固定済み ID == 元の findings[] の ID となっている。

1. 読み込み、ECHO、ID のロック

これは 2 部構成のゲートです。解析は読み込みではありません。終了コード 0 の json.load で確認できるのは、ファイルの形式が正しいことだけであり、検出結果をコンテキストに取り込めたことではありません。判定を行う前に、実際の内容を必ず出力してください。

1a. 検出結果テーブルを解析して出力する。

記憶やブランチ名、周辺ファイルからではなく、解析した findings[] 配列にあるすべての検出結果を出力してください。

python3 - <<'PY'
import json
r = json.load(open('.beagle/llm-artifacts-review.json'))
f = r['findings']
print(f"git_head={r.get('git_head')} scope={r.get('scope')} count={len(f)}")
print("| id | file | line | category | description |")
print("|----|------|------|----------|-------------|")
for x in f:
    desc = (x.get('description') or '').replace('|', '\\|')[:80]
    print(f"| {x['id']} | {x.get('file')} | {x.get('line')} | {x.get('category')} | {desc} |")
print("ids=" + ",".join(str(x['id']) for x in f))
PY

合格条件： コマンドが終了コード 0 で終了し、テーブル（検出結果ごとに 1 行）が出力に表示されること。

検出結果の唯一の情報源は、解析した findings[] 配列です。 ブランチ名、作業ディレクトリ、周辺ファイルから検出結果を推測しないでください。検出結果についての認識と出力したテーブルが異なる場合は、テーブルを優先し、認識を破棄して、上記の行だけを判定してください。

1b. ID のロック（判定前の必須ゲート）。

上記の ids= 行から ID の正確なセットを記録し、ここで明示してください。例：Locked ids: {1, 2, 3, 4, 5, 6, 7}。これをロック済み ID セットとします。ステップ 4 で記述する各結果は、このセットと 1 対 1 で対応していなければなりません。ID の追加も削除もできません。ステップ 4 の出力にある ID チェックでは、再導出したセットではなく、このロック済みセットを参照してください。

検証中に、ロック済みセットに含まれない ID の検出結果を判定しようとしている、またはロック済みの行に記載されていないファイルの結果を書こうとしていることに気付いた場合は、停止してください。これはエージェントのエラーです（レポートではなく、記憶やコンテキストに基づいて推論しています）。上記の ECHO コマンドで findings[] を再度読み込み、判定をやり直してください。その検出結果を false_positive として記録してはいけません（ステップ 3「ステータスの規律」を参照）。

レポートに記載された git_head と scope を記録してください（1a ですでに出力されています）。作業ツリーの状態が一致しなくなっている場合は、行番号がずれている可能性があることを警告してください（任意の厳密モード：git rev-parse HEAD と比較）。

2. 検出結果の順序

デフォルトの順序：

1. category == "dead_code"、fix_action == "delete"、または risk == "High"
2. 残りの検出結果は (risk の降順、id の昇順) で並べる

--priority-only を指定した場合は、dead_code カテゴリと fix_action: delete のすべてを処理した時点で終了します（処理した検出結果については、引き続き出力全体を記述してください）。

3. 各指摘を検証する

各指摘について、references/verification-checklist.md に従ってください。すべてのカテゴリで最初に行う確認は、存在の前提条件です。シンボルや使用状況を確認する前に、引用された file が source_git_head に存在することを確認してください。

指摘ごとに必要な最低限の証拠：

• まず存在を確認する： file が source_git_head に存在することを確認します（git cat-file -e <head>:<file> または test -f）。引用されたファイルが存在しないのは通常のことではありません。削除済みファイルに関する指摘（その旨を記録してください）であるか、実際のレポートを参照していないことを示しています。ファイルが見つからない結果が大量にある場合は、そこで停止し、findings[] を読み直してください（手順 1a）。見つからないファイルを黙って受け入れないでください。
• 引用された場所のファイルを読み、判断に必要なだけのコンテキスト（親シンボル、インポート）を確認します。
• 未使用／デッドコードに関する指摘では、削除しない場合に限り、純粋にスタイル上の問題である場合を除いて、リポジトリ内を検索します（シンボル、エクスポート、文字列フック）。

合格： checks_performed には、実際に実行した確認だけを記載します（例：file_exists、read_symbol、ripgrep_symbol）。notes には、決め手となった所見を記載します。

次のステータスを 1 つ割り当てます。

status	意味
confirmed_issue	レポートの指摘は妥当です。対応するのが適切です。
false_positive	レポート内の指摘は無効です（事実に反しているか、「修正」すると有害です）。自動修正しないでください。
inconclusive	人間または製品に関するコンテキストが必要です。fix-llm-artifacts ではリスクの高い指摘として扱ってください。

証拠がどれだけ直接的かに基づいて、confidence を high、medium、low のいずれかに設定します。

ステータスの厳守（必須ルール）： false_positive は「レポートにある指摘が無効である」ことを意味します。「この指摘はレポートにない」という意味では決してありません。ロック済み ID セット（手順 1b）のエントリと一致しない、見かけ上の指摘に遭遇した場合、それはエージェントのエラーであり、誤検出ではありません。そこで停止し、手順 1a のエコーコマンドで findings[] を読み直して、判定をやり直してください。ロック済みセットに含まれない ID に false_positive（またはいずれかのステータス）を付けることは禁止されています。

4. 出力を作成する

必要に応じて .beagle を作成します。次のファイルを書き込みます。

.beagle/llm-artifacts-verification.json：

{
  "version": "1.0.0",
  "created_at": "2026-04-19T12:00:00Z",
  "source_report": ".beagle/llm-artifacts-review.json",
  "source_git_head": "<from review>",
  "review_scope": "all|changed",
  "results": [
    {
      "id": 1,
      "status": "confirmed_issue|false_positive|inconclusive",
      "confidence": "high|medium|low",
      "checks_performed": ["file_exists", "read_symbol", "ripgrep_symbol", "export_trace"],
      "notes": "1-3 sentences of evidence"
    }
  ],
  "summary": {
    "confirmed_issue": 0,
    "false_positive": 0,
    "inconclusive": 0
  }
}

作成したファイルを検証します。

python3 -c "import json; json.load(open('.beagle/llm-artifacts-verification.json'))"

合格： コマンドが 0 で終了すること。ファイルを再度開き、（a）summary が results と一致していること（各 status の件数を数える）、（b）results の ID セットが手順 1b のロック済み ID セットと完全に一致していること（ID の追加・欠落がないこと）を確認します。ID セットが異なる場合、検証は失敗です。出荷せず、findings[]（手順 1a）を読み直して照合してください。

5. ユーザー向けに要約する

短い Markdown テーブルを出力します。列は、id、category、元の 1 行の説明、判定、confidence です。

最後に、次の内容を記載します。

• 確認済み、誤検出、判断不能の件数。
• 推奨事項：確認済みのものだけに対して fix-llm-artifacts を実行してください（検証ファイルがある場合は、そのスキルを参照してください）。

ルール

• 新たな問題を作り出さないでください。既存の findings[] エントリだけを判定してください。
• 削除によって動的な使用やリポジトリ間の使用が壊れる可能性がある場合は、confirmed_issue よりも inconclusive を優先してください。
• 指摘の id 値は、元のレポートのとおり正確に維持してください。

統合

• fix-llm-artifacts： このファイルがある場合、false_positive の ID はスキップし、inconclusive はリスクの高い修正として扱います。
• fix_action の引き継ぎ： fix_action フィールド（refactor／delete／simplify／extract）は review-llm-artifacts が出力し、fix-llm-artifacts がリスクゲートとして使用します。検証ではこの値を変更せず引き継ぎ、再検証は行いません。