mantis-report

Reporter（/mantis-report）

システム目標

セキュリティレポートのエキスパートです。複雑で技術的な調査結果ログを、開発者や関係者向けの高品質で読みやすいレビュー資料にまとめます。

コマンド定義

• コマンド： /mantis-report
• 説明： 確認済みの調査結果とエクスプロイトチェーンを含む、読みやすいセキュリティレビュー資料を生成します。

入出力の契約

• 読み込み対象：
  • workspace/findings/*.json（今回の実行で有効な調査結果ファイルすべて）。
  • workspace/archive/findings_pass_*/*.json（過去の実行でアーカイブされた調査結果）および従来形式の workspace/archive/loop*_findings/*.json。レポートはキャンペーン全体を対象とします。今回の実行の調査結果すべてに加え、過去の実行で再試行が打ち切られた（例：再試行上限に達した）ため引き継がれた調査結果も含め、レポートから消えることがないようにします。
  • workspace/.mantis_state.json（現在のループ実行を追跡し、来歴情報のために vcs_info と active_snapshot（root、snapshot_id、snapshot_pinned）を読み込みます）。
  • 各調査結果のスナップショット来歴フィールド。すべて任意です：discovery_commit、repro_snapshot_id、patch_base_snapshot。いずれかが欠落または空の場合は「（記録なし）」と表示します。調査結果を除外する理由にはなりません。
• 書き込み先：
  • workspace/report/review_packet_pass_<N>_<snapshot_tag>.md（実行回およびスナップショットタグ付きの Markdown レポート）。スナップショットが記録されていない従来形式の実行回では、タグなしの review_packet_pass_<N>.md にフォールバックします。
  • workspace/report/review_packet-latest.md のコピーまたはシンボリックリンクを更新します。
• 前提条件：
  • 調整および再現が確認された調査結果が workspace/findings/ または workspace/archive/ に存在すること。レポートはキャンペーン全体を対象とし、今回または過去の実行で発見された未解決の調査結果すべてについて、各調査結果の最新状態に重複なくまとめます。確認済みで未修正の調査結果が計画上の理由で引き継がれなくなった場合（例：2 回の再試行上限に達した場合）でも、レポートから消えることはありません。アーカイブされた最新状態でここに記載されます。
• 冪等性の保証：
  • 実行回およびスナップショットタグ付きのファイルに書き込みます。review_packet-latest.md は同じファイルに上書きします。同じスナップショットで同じ実行回を再実行すると、同じタグ付きファイルが更新されます。同じ実行回の番号で異なるスナップショットを再実行すると、別のファイルに書き込みます（<snapshot_tag> 接尾辞により、異なるスナップショットのファイルが上書きされるのを防ぎます）。スナップショットが記録されていない従来形式の実行回では、接尾辞なしの review_packet_pass_<N>.md という名前を維持し、これまでどおり同じファイルに上書きします。

手順

ステップ 0 — ロケーターの解決。

LOCATOR RESOLUTION (before reading ANY target code or artifact):
0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),
   you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from
   state for provenance/annotation; NEVER stop merely because a code root is unset.
1. Determine CODE_ROOT, in this priority order:
   a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.
      It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback
      (used when a caller hands you a prepared tree, e.g. a patched shadow).
   b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.
   c. Else read state_root/workspace/.mantis_state.json (state_root from
      --state_root if passed, else ./workspace/... relative to the current dir)
      -> active_snapshot.root / .snapshot_id / .snapshot_pinned.
   d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,
      treat snapshot_pinned = false (MODE-OFF). Do NOT stop.
2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):
   verify CODE_ROOT/.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing
   or different -> STOP "snapshot sentinel mismatch". (A --target_root tree (1a) is
   deliberately mutated and is sentinel-EXEMPT.)
3. PATH FIELDS:
   - SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files
     that are file paths. Strip ONLY a trailing ":<digits>". A code_paths entry
     containing "://" is a URL/endpoint, NOT a file read. A code_paths entry that is
     NOT of the form <existing-path>:<integer> is a non-source LOCATOR
     (symbol/offset/endpoint): only check that the artifact/symbol exists; skip ALL
     line-range and line-existence logic.
   - STATE-RELATIVE (read/write under state_root/workspace, NEVER prefix CODE_ROOT):
     kb_references, repro_file_path, reattack_file_path, helper scripts, report
     files, and all state/findings JSON.
4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that
   compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy
   (mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may
   cd into CODE_ROOT.
5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff/blame command
   run in the LIVE repository root (which still has .git/.hg/.repo), NOT CODE_ROOT
   (the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT
   lacks .git/.hg/.repo.
6. Every shell command uses ABSOLUTE paths and sets its own working directory on
   that call. Do NOT assume the working directory persists between calls.

続いて、Reporter には次の調査結果のみを対象とする注記が適用されます。

• Reporter は調査結果のみを対象とするステージ（ブロック A、ROLE ステップ 0）です。ロケーターのステップ 2〜6 はスキップし、CODE_ROOT を必要とせず、解決も行いません。また、コードルートやセンチネルが設定されていないことを理由に停止することはありません。
• 来歴情報として、workspace/.mantis_state.json から active_snapshot（root、snapshot_id、snapshot_pinned）と vcs_info は引き続き読み込みます。これらはヘッダー、先頭のバナー、出力ファイル名の作成に使用します。
• Reporter が扱うすべてのパス（workspace/findings/*.json、workspace/.mantis_state.json、workspace/report/*、workspace/archive/*）は状態ディレクトリを基準とし、CODE_ROOT を先頭に付加することはありません。

検証・再現済みの脆弱性とエクスプロイトチェーンを詳述した、専門的な Markdown レポートを作成します。

レポート作成ステージを次のように実行します。

1. 調査結果を読み込む — 今回の実行分すべてと、引き継がれた未解決の調査結果（新しいものから順に統合。スクリプトは使用しません）。 調査結果の識別情報をキーとして作業セットを作成し、各調査結果を最新状態で 1 回だけ含めます。 同一バグの判定基準（この段階における現在の検出結果とアーカイブ済み検出結果のすべての重複排除、統合、抑制に使用します。ここでは過剰な報告は常に安全ですが、実際の検出結果を隠すことは決して許されません）：2 つの検出結果が同一バグであるのは、次のいずれかを満たす場合に限ります。（i）id（UUID）が完全に一致する。または、（ii）以下の 3 つすべてを満たす。空でない lineage_id が一致する、空でない signature が一致する、さらに :line の末尾部分も含めて比較した code_paths のエントリが少なくとも 1 つ一致する。それ以外は別個の検出結果として、両方を表示します。lineage_id だけ、または signature だけを根拠に 2 つの検出結果を同一バグとして扱ってはなりません。どちらもバグの実際の識別情報より粗い基準です（ベース名から導出された lineage は、同名の別ファイルを結び付ける可能性があります。また、signature は行番号を除外するため、同一ファイル内の別のバグでも衝突します）。どちらか一方だけを根拠に統合すると、実際の検出結果が気付かれないまま失われる可能性があります。

   設計上の注意（再アンカーと統合の違い）： mantis-plan の再アンカー（フェーズ 2）は、再検出の方向を示す行のヒントを提供するだけで、引き継がれた検出結果の code_paths は書き換えません。再検出された検出結果は、現在のスナップショットにおける新しい行に表示されます。統合の判定基準では code_paths の行番号を含む一致が必要なため、行番号が異なる再検出結果は、その祖先とは統合されません。これは安全な過剰報告です。両方のエントリが表示され、現在の検出結果には新しい位置が示されます。将来のフェーズでは、両方の検出結果が同じ signature と lineage_id を持ち、かつ祖先の行が現在のスナップショットに存在しないことが確認された場合に、判定基準をパスのみの一致へ緩和できる可能性があります。ただし、検出結果が気付かれないまま失われるリスクを防ぐため、現在は保守的な行番号を含む一致を使用しています。

   1. workspace/findings/*.json 内のすべてのアクティブな項目を読み込み、すべてのアクティブな検出事項を id（UUID）をキーとして作業セットに追加します。修正ステータスはすべて対象です。このパスでの VERIFIED_SECURE／MITIGATION_PROPOSED の修正も、カテゴリー 1／2 にパッチとともに引き続き表示されます。lineage_id や signature が同じでも、2 つのアクティブな検出事項を絶対に統合しないでください。各アクティブな id をそれぞれ独立したエントリとして保持します。
   2. workspace/archive/findings_pass_<N>/（およびレガシーの loop<N>_findings/）をパス番号の降順でスキャンします。アーカイブ済みの検出事項は、まだ OPEN であり（4 を参照）、同じ BUG である検出事項が作業セットに存在せず（上記の述語による）、さらに、より前の（パス番号が大きい）アーカイブ済みコピーのうち同じ BUG のものがすでに追加されていない場合にのみ追加します。同じ BUG のコピーを最初に検出した時点が最新の状態です。下位ディレクトリにある同じ BUG のコピーは無視します。（アーカイブ済みの検出事項を抑制できるのは、実際に同じ BUG である検出事項によって置き換えられる場合だけです。lineage_id や signature が偶然一致するだけでは抑制されません。）
   3. 置き換えの統合（フェーズ 3）： アーカイブ済みの検出事項が、現行の検出事項と述語 ii に基づいて同じ BUG である場合、現行の検出事項がそれを置き換えます。現行の（最も新しい）状態で 1 つのエントリのみを表示し、アーカイブ済みのコピーは表示しないでください。述語が満たされない場合（ファイル名の変更などで signature が異なる、または lineage_id がないなど）は、安全のため過剰に報告してもよいので、両方を別々のエントリとして表示します。
      • 過少報告の防止策： 現行の（置き換える側の）検出事項が、実行可能性の述語（以下のステップ 4）を満たさない一方で、アーカイブされた先祖の検出事項が満たしていた場合（たとえば、先祖では reproduced かつ OPEN だったが、新しいスナップショットでの一時的なビルド／環境障害により、現行パスでの再現結果が not_attempted になった場合）、一時的なダウングレードによって確認済みの未修正 BUG が抑制されないようにしてください。その代わり、先祖の最後に確認された状態をレポートに表示します（「Open — repro pending on new snapshot」という注記を付けて表示します）。これにより、以前に確認された BUG がレポートから予告なく消えることを防ぎます。現行の検出事項の新しいメタデータ（更新された code_paths の行番号など）を注釈として付けてもかまいませんが、表示する判定／ステータスには、一時的なダウングレードではなく、必ず先祖の最後に確認された状態を使用してください。
   4. 実行可能性／品質の述語（アクティブな項目とアーカイブ済みの項目の両方に適用）：検出事項は、エクスプロイトチェーン（constituent_findings が存在する、またはタイトル／履歴に「Exploit Chain」が含まれる）、repro_status が reproduced、または（repro_status が statically_confirmed で、かつ実証的な実行証拠（外部スタックトレース、サニタイザーのトレース（ASan／UBSan／MSan／TSan）、クラッシュログのいずれか）を伴う）のいずれかに該当する場合にのみ含めます。誤検知、NON_VIABLE、DUPLICATE、failed_to_reproduce、または実証的なトレースを伴わない通常の statically_confirmed の検出事項は含めないでください。
   5. 未解決の述語（ステップ 2 のアーカイブ済み項目の引き継ぎにのみ適用）：アーカイブ済みの検出事項が「まだ未解決」であるのは、(4) を満たし、patch_status が VERIFIED_SECURE／MITIGATION_PROPOSED ではなく、status が FALSE_POSITIVE／DUPLICATE ではなく、production_viability が NON_VIABLE でもない場合です。（アクティブな検出事項は、パッチステータスに関係なく読み込み、このパスでの修正も引き続き表示します。修正済みのアーカイブ項目はパスごとに再掲載しません。修正済み項目を累積的に表示するには、任意の「今回のキャンペーンで解決」集計を使用してください。）
   6. 規模への対応： 一度に 1 つのディレクトリを、最新のものから順に処理します。アーカイブ全体を一度に読み込まないでください。
   • 重大度によるフィルタリング： 優先度が "LOW" の検出事項は、メインレポート本文から除外します。これらの優先度の低い問題は、レポートの最終位置に専用の「付録：優先度の低い検出事項」セクションを設けて記載し、メインレポートではリスクの高い問題に焦点を当ててください。

2. 重要な成果物を抽出する: 再現された各所見について、次の項目を抽出して整形します。

   • ヘッダーメタデータ: タイトル、ID（UUID）、推定される露出度、最終リスクスコア、 および定性的優先度。
   • キャンペーンの由来: 各未解決の所見について、それが最初に発見されたパスと 現在のパスを注記します（例: discovered pass 2 · still open as of pass 7）。これにより、持ち越された所見が そのように可視化されます。初回検出 = その所見の history エントリ内で最も小さい pass_number（またはそれを含む最小番号のアーカイブディレクトリの pass_number）。 現在の状態 = 上記の折りたたみから保持したコピー。
   • 重複に関する注意: その所見に possible_duplicate_of フィールドがある場合 （クロスパスの候補が NOT_MATCHED のときに mantis-dedupe によって設定されます）、 注意ノートを出力します: Possibly related to finding <UUID> (cross-pass candidate; snapshots differ — not confirmed duplicate). これにより、注意喚起のリグレッションポインターがステークホルダーに可視化されます。
   • 検出スナップショット: その所見について Discovery Snapshot: <discovery_commit> を 出力します。discovery_commit が欠落しているか空の場合は、 Discovery Snapshot: (legacy — not recorded) を出力します。このフィールドが 存在しないことを理由に所見を省略したり脱落させたりしないでください。
   • 脆弱性の説明と影響: バグの明確な説明と、システムへの具体的な影響。
   • 再現証拠:
     • PoC スクリプトのパス（repro_file_path）と実行コマンド （run_command）。
     • エクスプロイトのトリガー成功を示す stdout/stderr のクリーンな抜粋 （repro_output）。
     • 証拠のベース: 再現証拠を、それが収集されたスナップショットでラベル付けします: Evidence base: <repro_snapshot_id>。repro_snapshot_id が欠落しているか 空の場合は、Evidence base: (not recorded) と記述します。これがヘッダー/パスの スナップショットと等しいと仮定しないでください。
   • リスク根拠: 独立した検証の推論（reasoning）、 本番環境での実現可能性の推論（critic_reasoning）、および怒り度合いの 分析（outrage_commentary）。
   • 緩和策とパッチ:
     • 推奨される軽減戦略。
     • 検証済みのパッチ差分（patch_diff）と、修正が堅牢であることを証明する 再攻撃ステータス。
     • 適用対象: パッチ差分を、それが適用されるスナップショットでラベル付けします: Apply against: <patch_base_snapshot>。patch_base_snapshot が欠落しているか 空の場合は、Apply against: (not recorded) と記述します。 patch_base_snapshot が存在し、この所見の discovery_commit と異なる場合は、 その差分が別のスナップショットに対して生成されたものであり、検出スナップショットに クリーンに適用できない可能性がある旨の注意書きを1行追加します。
   • PII とシークレットの伏せ字化: 所見データ（説明、PoC スクリプト/コマンド、 再現ログを含む）をレポートに書き込む前に、ハードコードされた API キー、トークン、 認証情報、PII（氏名、メールアドレス、電話番号）、内部ホスト名/ドメイン名、 および過度に兵器化されたペイロードパラメータを必ずスキャンして伏せ字化し、 <REDACTED_SECRET>、<REDACTED_PII>、<REDACTED_INTERNAL_HOST>、または <REDACTED_PAYLOAD> のような標準的なプレースホルダーに置き換えて、 レポートがより広範な配布に対して安全であることを確保します。

3. レビューパケットを生成する:

   • レポートヘッダーと免責事項: レポートの最上部（エグゼクティブサマリーの前）に:

     スナップショット由来バナー — 以下 item 1 の前に、レポートの最上部に、 それぞれを独立した区切られた引用ブロックとして、この順序で出力します: a. 非権威的 / HALT バナー（3 状態ルール）。 workspace/.mantis_state.json から active_snapshot を読み取ります。 - active_snapshot が存在しない場合（MODE-OFF — --sync が要求されておらず、今日のデフォルト）: このバナーを出力しないでください。実行は今日の動作とバイト単位で同一であり、レポートの VERIFIED_SECURE の検出結果およびその他の判定は今日と同様に有効です。ここで NON-AUTHORITATIVE バナーを出力すると、同じ実行が生成する判定と矛盾することになります。 - active_snapshot が存在するが snapshot_pinned が false の場合（HALT モード）: レポートの最初の行として次を出力します: > **WARNING — NON-AUTHORITATIVE RESULTS:** The target could not be pinned to an immutable snapshot for this pass (HALT mode: the tree raced or was too big / live / copy-failed). Findings may not correspond to a stable, reproducible tree, and the ABSENCE of findings in this report does NOT indicate the target is secure. Treat all results as provisional. active_snapshot が存在しない場合（MODE-OFF）、または active_snapshot.snapshot_pinned が true の場合（PINNED）は、このバナーを省略してください。

     b. ダーティ作業ツリーの警告。 vcs_info.dirty が true の場合、次を出力します: > **WARNING — DIRTY WORKING TREE:** The target had uncommitted local modifications when it was scanned. Results reflect that exact working tree (captured by content hash), NOT a clean committed revision. The recorded commit alone will not reproduce this state.

     c. 混在スナップショットのバナー。 HEADER_SID = active_snapshot.snapshot_id とします。HEADER_SID が存在して空でなく、かつ INCLUDED のいずれかの検出結果の discovery_commit が欠落している、空である、または HEADER_SID と文字列として等しくない場合、次を出力します: > **WARNING — MIXED SNAPSHOTS:** This report combines findings discovered on different code snapshots (e.g. findings retried from earlier passes). The pass snapshot is <HEADER_SID>. Consult each finding's "Discovery Snapshot" before acting; line numbers and code context may differ between snapshots. スナップショット ID は厳密な文字列としてのみ比較してください — あいまい一致や前方一致は行いません。

     1. workspace/.mantis_state.json の "vcs_info" から読み取ったターゲットコードベースのバージョン情報を表示します:

        • "vcs_type" が "git" の場合、次を表示します: Target Version: Git branch [branch] at commit [commit_hash] [(dirty) if dirty is true]。
        • "vcs_type" が "hg" の場合、次を表示します: Target Version: Mercurial branch [branch] at revision [commit_hash] [(dirty) if dirty is true]。
        • "vcs_type" が "multi-vcs" の場合、次を表示します: Target Version: Multi-VCS (repo) manifest [revision] [(dirty) if dirty is true]。
        • "vcs_type" が "none" の場合、次を表示します: Target Version: None (No version control detected)。
        • "vcs_type" が "unknown" の場合、または vcs_info が欠落している場合、次を表示します: Target Version: Unknown (VCS detection failed/error)。

        Target Version: の行の後に、パスのスナップショット識別情報を 2 行目として追加します:

        • active_snapshot.snapshot_id が存在して空でない場合、次を記述します: Snapshot ID: [snapshot_id] (pinned: [snapshot_pinned])。
        • active_snapshot が存在しない、または snapshot_id が空の場合、次を記述します: Snapshot ID: (legacy — snapshot not recorded)。これは表示専用の来歴情報であり、いかなる検出結果もゲートしたり破棄したりしません。

     2. 次の内容を明記した目立つ免責事項を含めます: 「This report was automatically generated by Mantis AI. All findings and patches are AI-generated and must be manually verified by a security or subject matter expert before deployment or disclosure.」

   • パッチ状況によるグループ分け（相互排他）: 検出事項をグループ分けして、エグゼクティブサマリーの表とレポート本文を構成します。**エクスプロイトチェーンは、これらのメイングループから除外し、専用の「Exploit Chains (Not End-to-End Reproduced)」セクションにのみ記載してください。**標準の検出事項（チェーン以外）は、修正状況に基づいて、相互排他的な次の3つのカテゴリに分類します。

     1. カテゴリ1：パッチを個別に検証済み：patch_status が "VERIFIED_SECURE" の検出事項。
     2. カテゴリ2：パッチを提案済み／緩和策を特定済み：patch_status が ["MITIGATION_PROPOSED", "VERIFICATION_INCOMPLETE"] に含まれる場合、または（patch_diff が存在し、patch_status が未設定／空の場合）。
     3. カテゴリ3：未パッチ／検証失敗：patch_status が ["VERIFICATION_FAILED", "ERROR"] に含まれる場合、または（patch_diff が存在せず、patch_status が未設定／空の場合）。

   • エクスプロイトチェーン専用セクション： エクスプロイトチェーン専用のセクションとして、"Exploit Chains (Not End-to-End Reproduced)" というタイトルのセクションを作成します。各チェーンの検出事項について、タイトル、定性的な優先度、リスクスコアを記載し、構成要素となる検出事項（ID と個別のステータス）を詳しく説明します。エクスプロイトチェーンをカテゴリ1、2、3の標準の検出事項と混在させないでください。

   • パス番号付き出力： 実行のたびに同じ review_packet.md ファイルを上書きしないでください。代わりに、パイプラインの現在の実行／パス番号 N を特定します（workspace/.mantis_state.json の "pass_number" から取得します。存在しない場合や無効な場合は、workspace/archive/ 内で findings_pass_N または loopN_findings に一致するフォルダーを検索し、見つかった最大の値 N に 1 を加えます。アーカイブがない場合は 1 をデフォルト値とします）。次に、active_snapshot.snapshot_id から <snapshot_tag> を生成します。スナップショット ID を保存されているとおりに取得し、[A-Za-z0-9.-] に含まれない各文字を単一のアンダースコア _ に置き換えます（切り詰めないでください。結果はファイル名の長さ制限を十分に下回ります）。レポートは次の場所に書き込みます。

     • active_snapshot.snapshot_id が存在し、空でない場合は、workspace/report/review_packet_pass_<N>_<snapshot_tag>.md（例：review_packet_pass_1_content_9f86d081884c...md）に書き込みます。<snapshot_tag> のサフィックスにより、同じパス番号を別のスナップショットに対して再利用した場合でも、別のファイルに書き込まれるため、以前のパケットが上書きされません。
     • active_snapshot が存在しない場合、または snapshot_id が空の場合は、workspace/report/review_packet_pass_<N>.md（サフィックスなし。従来とまったく同じ名前）に書き込み、現在の後方互換性を維持します。

   • 最新コピー／シンボリックリンク： 上記のパス番号付きレポートを書き込んだ後、<snapshot_tag> のサフィックスの有無にかかわらず、そのファイルと同一のファイルへのシンボリックリンクを作成するか、そのコピーを workspace/report/review_packet-latest.md に書き込みます。これにより、常に最新バージョンにアクセスできます。review_packet-latest.md の名前は変更せず、下流のコンシューマーが利用する安定したエントリーポイントとして維持します。

   • メタデータには明確な見出しと表を使用し、ログや差分にはシンタックスハイライト付きのコードブロックを使用して、見やすくプロフェッショナルな Markdown 形式にします。

   • 含まれるすべての検出事項、優先度、リスクスコアを一覧にした、概要レベルのエグゼクティブサマリーの表を冒頭に含めます。

   • 任意のセクション（推奨）：

     • このキャンペーンで解決済み: 同じ折りたたみを使用した短いロールアップですが、patch_status が VERIFIED_SECURE または MITIGATION_PROPOSED である検出結果にフィルタリングします。これにより、ステークホルダーは未解決の検出結果と並べて、修正された内容を可視化したビューを確認できます。
     • 未解決 — 再試行上限到達: 再現試行回数が上限に達している未解決の検出結果をリストしたコールアウトです。この回数は検出結果 JSON のフィールドではありません。キャッシュファイル state_root/workspace/archive/.repro_attempts.json に保存されており、各検出結果の signature でキー付けされています（signature が存在しない場合は、計算された stable_key = normalized_title + "@" + primary_file_path でキー付けされます。これは mantis-reproduce と同じキー選択です）。ワーキングセット内の各未解決の検出結果について、その signature（またはフォールバックとして stable_key）をそのキャッシュ内で検索し、キャッシュされた値が再試行上限に達している場合にこのコールアウトにその検出結果を含めます。キャッシュされた値はスキーマの値形状ルールに従って読み取ります。素の整数 V は {count: V, last_snapshot: UNKNOWN} を意味し、オブジェクトは {count: V.count, last_snapshot: V.last_snapshot or UNKNOWN} を意味します。キャッシュファイルが存在しない場合、または検出結果のキーが存在しない場合は、その回数を 0 として扱います（ここにはリストしないでください）。これらはプランナーが引き継ぐのをやめた項目です。

   メモ

   重複排除の注意点: 重複排除は、このステージの冒頭にある SAME-BUG PREDICATE に従い、検出結果の同一性によって行われます。2 つの検出結果が折りたたまれるのは、(i) まったく同じ id（UUID）を共有している、または (ii) 次の 3 つすべてを満たす場合のみです — 共有された空でない lineage_id、共有された空でない signature、そして少なくとも 1 つの行を含む code_paths の一致。lineage_id のみ、または signature のみで折りたたんでは決していけません（ベース名由来のリネージは、同名の 2 つの異なるファイルをリンクしてしまう可能性があり、signature は行番号を除去するため、同一ファイル内の異なるバグ間で衝突します） — どちらか一方のみで折りたたむと、実際の検出結果を気付かないうちに失う可能性があります。述語 (ii) を満たさない新しい UUID の下で再検出されたバグ — リグレッション、行がずれるファイル名変更、または非決定的な再検出 — は、アーカイブされた祖先とは別のエントリとしてリストされます。過剰報告（安全）であり、決して隠しません。安定した検出結果シグネチャとリネージ追跡が導入されたことで（Phase 3）、再検出された検出結果がその祖先の単一エントリに折りたたまれるのは、述語 (ii) が完全に満たされている場合のみです。UUID のみの一致は、レガシー／未アップグレードの検出結果に対する安全な分岐として残ります。

   • review_packet-latest.md が authoritative: review_packet-latest.md が、キャンペーン全体（最新パスだけでなく）の authoritative な現在の未解決状態になったことに注意してください。パスごとの review_packet_pass_<N>_<snapshot_tag>.md ファイルは、履歴参照用としてそのまま残ります。