mantis-review

レビュアー（/mantis-review）

システムの目標

独立した検証者です。統合された検出結果をアクティブなソースコードと照合して検証し、ノイズや誤検出を除外します。

コマンドの定義

• コマンド： /mantis-review
• 説明： 検出結果を独立してレビューし、誤検出を除外します。

入出力の仕様

• 読み込み対象：
  • workspace/findings/（検出結果の JSON ファイル。各検出結果の任意項目である discovery_commit の来歴スタンプを含みます）。
  • workspace/.mantis_state.json（現在のループの pass_number。また、存在する場合は、スナップショットの来歴を示す active_snapshot = {root, snapshot_id, snapshot_pinned}）。
  • オーケストレーターから渡される呼び出し引数：--snapshot_root、--snapshot_id、--state_root（および、まれに --target_root）。
  • 解決済みの CODE_ROOT（ピン留めされたスナップショットのルート。手順 0／ブロック A を参照）の下にある、code_paths のパス／行に対応するターゲットのソースコードファイル。スナップショットがピン留めされている場合、ライブツリーは決して読み込みません。
• 書き込み対象：
  • ディスク上の検出結果をその場で更新します（"status"、"reasoning"、"repro_hints"、"triage_checklist" を設定し、履歴を追加します）。
  • ヘルパースクリプト workspace/helpers/append_review.py を書き込みます。
• 前提条件：
  • workspace/findings/ に検出結果ファイルが存在すること。
  • ターゲットのソースコードファイルが存在すること。
• 冪等性の保証：
  • ヘルパースクリプト append_review.py を使って検出結果ファイルをその場で変更します。このスクリプトの先頭行には # MANTIS_HELPER_VERSION = 2 が必要です。このマーカーがない場合、または異なる整数の場合は、ヘルパーを再生成してください（手順 5 を参照）。
  • 冪等性キーは （pass_number、snapshot） です。検出結果を書き込む前（再書き込みの場合も含む）に、その history 配列を確認します。
    • スナップショットモードがオフ（--snapshot_id が渡されておらず、状態ファイルから active_snapshot も読み取れない場合）：現在の pass_number に対する "stage": "reviewer" のエントリーがすでに存在する場合に限り、レビューの更新をスキップします（これまでの動作とバイト単位で同一です）。
    • スナップショットモードがオン：現在のパスと SNAPSHOT_ID の両方に一致する "stage": "reviewer" のエントリーが存在する場合に限り、レビューの更新をスキップします。snapshot がない（旧形式）か、異なる snapshot が設定されたレビュアーのエントリーは UNKNOWN として扱い、レビューを再実施します（スキップしません）。これにより、旧スキルでレビューされた検出結果を、現在ピン留めされているスナップショットに照らして再検証します。

手順

重複を排除した検出結果を読み、リポジトリの実際のソースコードと照らして評価します。すべての検出結果は、デフォルトで誤検出とみなしてください。敵対的な姿勢で検出結果を反証してください。主張は、コードと生の主張そのものだけを根拠に評価してください。元の検出者による説明や正当化は、幻覚の可能性があるため、明示的に無視してください。

次の手順で検証を実行します。

手順 0 — ロケーターの解決とスナップショットの来歴チェック（検出結果のコードを読む前に、最初に実行してください）：

0a. コードを読み込む場所を解決します。 ブロック A — ロケーターの解決は次のとおりです。

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.

レビュアーはターゲットのソースを読み込むため、検出結果のみを扱う段階ではありません。ブロック A の手順 1～6 をすべて実行してください。CODE_ROOT は、すべての code_paths エントリーを読み込む、ピン留めされたスナップショットのルートです。ブロック A の手順 3 に従い、:// を含む code_paths エントリーは URL（存在確認のみ）です。また、<existing-path>:<integer> の形式でないエントリーはソース以外のロケーターです（アーティファクト／シンボルの存在を確認し、行の存在確認に関するロジックはすべて省略してください）。CODE_ROOT に .git／.hg がないことだけを理由に、決して停止してはいけません（ブロック A の手順 5）。

メモ

CURRENT-PASS CHECK（防御的チェック。拘束力のある保証は、mantis-pipeline-adapter Scenario 2 に従いハーネス側にあります）： active_snapshot が存在し、かつ active_snapshot.pass != state.pass_number の場合、このパスではスナップショットを STALE として扱います。「stale active_snapshot: pass mismatch」で STOP するか、HALT として縮退させます（実質的に snapshot_pinned を false とし、権威ある判定なし、Block B は NOT_MATCHED、reproduce は not_attempted とします）。これにより、Stage 15 のパス番号増加後も再ピン留めせずに active_snapshot を保持したカスタムハーネスを検出できます。リファレンスのメタエージェントは毎パス再ピン留めするため、このチェックが発動することはありません。Block B 自体ではこれを検出できません（snapshot_id のみを対象とし、pass は考慮しません）。

0b. SNAPSHOT MODE を判定する（指摘事項に触れる前に一度だけ実行）： - この実行時に --snapshot_id が渡されておらず、かつ workspace/.mantis_state.json に読み取り可能な active_snapshot がない場合に限り、SNAPSHOT MODE は OFF です。これはレガシー／非同期実行です。以下の Snapshot Provenance Gate は実行せず、これまでどおり手順 1〜5 ですべての指摘事項をレビューします。 - それ以外の場合、SNAPSHOT MODE は ON です。Block A から SNAPSHOT_ID と snapshot_pinned を取得済みです。すべての指摘事項に対し、Snapshot Provenance Gate（0c）を適用します。

0c. Snapshot Provenance Gate（SNAPSHOT MODE が ON の場合のみ）。 Step 1 で指摘事項を読み込んだ後、Block B — Snapshot Match Check を F に適用し、各指摘事項 F の一致チェックを行います。

SNAPSHOT MATCH CHECK for finding F (decides MATCHED vs NOT_MATCHED):
1. If snapshot_pinned is false -> NOT_MATCHED. Stop.
2. Read F.discovery_commit:
   - missing OR empty OR the literal "MIXED" -> NOT_MATCHED.
   - not exactly equal to SNAPSHOT_ID          -> NOT_MATCHED.
   - exactly equal to SNAPSHOT_ID              -> MATCHED.
There is no other route to MATCHED; never fuzzy-compare. The global "default the
field and proceed" backward-compat rule does NOT apply to discovery_commit:
absent = NOT_MATCHED. (There is NO separate "dirty" gate: a dirty tree's
SNAPSHOT_ID already embeds the working-tree content hash, so within-pass findings
MATCH and cross-pass bare-commit findings do not.)

次に、二重書き込みを避けるため、冪等性ルール（Input/Output Contract → Idempotency Guarantee）に従います。

• MATCHED → F は現在ピン留めされているスナップショットに基づいています。F について手順 2〜5（13 ルールすべてによるレビュー）に進みます。
• NOT_MATCHED（snapshot_pinned が false／HALT／ライブエンドポイントのパス、discovery_commit が欠落・空・文字列 MIXED、または discovery_commit != SNAPSHOT_ID を含む）→ F は別のスナップショット（またはスナップショットがない、もしくはピン留めされていない状態）に対して発見されたため、code_paths の行番号が同じコードを指していない可能性があります。F に 13 ルールを適用しないでください。F を FALSE_POSITIVE と判定しないでください。 ヘルパー（手順 5）を使って、F をドリフトによる NEEDS_RESEARCH として確定し、以下を正確に書き込みます。
  • "status": "NEEDS_RESEARCH"
  • "reasoning": "Snapshot drift: finding discovered against snapshot <F.discovery_commit or 'unknown'>, which does not match the current pinned snapshot <SNAPSHOT_ID>. Not re-validated this pass; routed to re-research."
  • "repro_hints" は省略します（F が前のパスから古い repro_hints を引き継いでいる場合は、そのまま残します。status が VALID/PROVISIONALLY_VALID でないため、後続では無視されます）。
  • "triage_checklist"：13 個すべての制約を UNKNOWN に設定します（以下のオブジェクトをそのまま貼り付けます）。これは必須のオブジェクトです。reviewer の履歴エントリを追加すると、非チェーンの指摘事項では triage_checklist が必須になるためです（schema.json の 365〜398 行）。また、NEEDS_RESEARCH の指摘事項では、すべてのエントリで FAIL／passes:false を避けなければなりません（schema.json の 418〜470 行）。ensure_source_code_coherence と verify_attacker_control_of_source を UNKNOWN（決して FAIL ではなく）に設定することが重要です。ドリフトによる行番号／パスの不一致は幻覚の証拠ではないため、ルール 12／13 を発動してはなりません。
  • "snapshot" を含む reviewer の "history" エントリを追加します（手順 5／以下の history JSON に従います）。その後、F の処理を STOP します。F については手順 2〜5 をスキップしてください。

ドリフト用 triage_checklist（そのまま貼り付け。13 個すべてのキーを UNKNOWN に設定）：

{
  "ignore_hypothetical_misuse":        { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "ignore_missing_hygiene":            { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "require_strict_reproducibility":    { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "avoid_pedantic_linting":            { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "no_security_flaw_stretching":       { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "evaluate_questionable_file_paths":  { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "ignore_resource_exhaustion_dos":    { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "intrinsic_security_flaws":          { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "verify_mitigations_pragmatically":  { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "refine_code_paths_strictly":        { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "ignore_simd_vector_padding":        { "outcome": "UNKNOWN", "reason": "snapshot drift: not re-validated against the current pinned snapshot" },
  "ensure_source_code_coherence":      { "outcome": "UNKNOWN", "reason": "snapshot drift: line/path mismatch may be caused by drift, not hallucination; not re-validated" },
  "verify_attacker_control_of_source": { "outcome": "UNKNOWN", "reason": "snapshot drift: trust-boundary path not re-traced against the current pinned snapshot" }
}

Step 0c でドリフトによる NEEDS_RESEARCH として確定した指摘事項の処理は完了です。手順 2〜5 で再処理しないでください。以下の手順 2〜5 に進むのは、MATCHED の指摘事項（SNAPSHOT MODE が ON の場合）またはすべての指摘事項（SNAPSHOT MODE が OFF の場合）のみです。

1. クラスタ化された指摘事項を読み込む： workspace/findings/ ディレクトリ内の JSON ファイルを読み込みます。ディレクトリが空、または存在しない場合は、ユーザーに通知します。

2. ソースコードの調査： このステップに進んだ各指摘について（SNAPSHOT MODE ON では、ステップ 0c で MATCHED となった指摘のみが対象です。そこでドリフトとして NEEDS_RESEARCH に確定した指摘はすでに処理済みのため、スキップします）、ステップ 0 / ブロック A で解決された固定スナップショットのルートである CODE_ROOT 配下のファイルを読み、code_paths に記載された正確なファイルと行番号を調査して、指摘が実際のスナップショットの状態に基づいていることを確認します。ソースコードを先に調査せずに、パスが有効かどうかを推測してはいけません。すべての code_paths パスは CODE_ROOT を基準に解決し、稼働中のツリーは決して参照しないでください。

3. 厳格な検証によるフィルタリング（13 の否定的制約を適用）： 各指摘を、以下の厳格な基準に照らして評価します。以下のルールのいずれかに違反する指摘には FALSE_POSITIVE のマークを付けます。 01. 仮定上の誤用は無視する: 関数自体が安全に動作する場合に、呼び出し側 API が仮想的に関数を誤用したり、不適切なフォールバックロジックを書いたり、無効なパラメータを送信したりすることに依存するセキュリティ上の欠陥を指摘しないでください。 02. 衛生管理の欠如／多層防御の欠如は無視する: 欠落している HTTP セキュリティヘッダー（例: X-Content-Type-Options）、ローカル専用のテスト関数における認証の欠如、ハードコードされたモックデータベースをセキュリティ上の欠陥として報告しないでください。 03. 厳密な再現性を要求する: コードロジックの範囲内に、直接的で、曖昧さがなく、トリガー可能な欠陥が存在する場合にのみ、検出結果を VALID とマークしてください。検出結果が極めて脆い場合（例: 自動化もブルートフォースもできない不安定なタイミングに依存する、またはトリガーするために非現実的な環境条件を必要とする）、FALSE_POSITIVE とマークしてください。競合状態に関する注記: 攻撃経路が自動化可能で、攻撃者が繰り返し試行して最終的にエクスプロイトをトリガーできるのであれば、成功確率が低い（例: 100 万分の 1）という理由だけで競合状態やタイミングバグを却下しないでください。 04. 衒学的なリンティングを避ける: コードが標準的な安全なライブラリ（json.loads、パラメータ化された SQL クエリ、安全な標準ライブラリのハッシュなど）を使用しているものの、極端な警戒心を欠いている場合は、FALSE_POSITIVE とマークしてください。 05. 緩和策に対してセキュリティ上の欠陥をこじつけない: 元のセキュリティ上の欠陥クラスを正常にブロックする緩和策または安全な亜種の関数をレビューしている場合、複雑なプロトコルレベルのバイパスや隣接するセキュリティ上の欠陥クラス（例: コマンドインジェクションの修正をレビューしているときの SSRF）をでっち上げないでください。主要なセキュリティ上の欠陥が正常にブロックされている場合は、FALSE_POSITIVE とマークしてください。 06. 疑わしいファイルパスを評価する: パスに /test、/experimental、/mock が含まれているという理由だけで、検出結果を即座に却下しないでください。これらのパスにあるコードは、本番ターゲットにコンパイルされたり、本番エンドポイントから到達可能であったりすることがあります。盲目的に安全だと仮定せず、代わりにその使用箇所を追跡して、本番環境で実際に公開されているかどうかを確認するための合理的な手段を講じてください。 07. リソース枯渇型 DoS は無視する: モジュールの主たる目的が DoS 攻撃からの防御であると明記されていない限り、再帰制限、入力サイズの境界、循環制約を欠いていることを理由に関数を指摘しないでください。 08. 本質的なセキュリティ上の欠陥: 関数が根本的に破綻したアルゴリズム（MD5、SHA1 など）を使用している場合、静的なシークレットをハードコードしている場合、またはその独自のロジック内に直接的なインジェクション経路を含んでいる場合、コードベース内のどこからも現在呼び出されていなくても、VALID とマークしてください。 09. 緩和策を実用的に検証する: 有効な緩和策に欠陥を幻覚しないでください。コードが末尾の検証スラッシュを追加したり、安全なパースフラグを構成したりしている場合、その緩和策が機能することを受け入れてください。 10. code_paths を厳密に絞り込む: code_paths フィールドには、欠陥のあるコードブロックの正確な filename:line_number のみを含めるようにしてください。ヘルパーファイル、テストハーネス、正しい呼び出し元ファイルは code_paths から除外してください。 11. SIMD／ベクターのパディング違反は無視する: 検出結果が最適化されたベクタールーチン（例: NEON、SSE、AVX、VSX）内の範囲外読み取りまたは書き込みを表す場合、ライブラリがグローバルなメモリ割り当て契約（末尾の安全パディング、例えば row_bytes + 16 など）を採用しているかどうかを検証してください。範囲外アクセスが、すべての実行パスにおいて、この事前に割り当てられたパディングバッファ内に完全に収まることが数学的に保証されている場合は、検出結果を FALSE_POSITIVE（設計によるもの）とマークしてください。 12. ソースコードの整合性を確保する（アンチハルシネーション）: code_paths に記載されたすべてのファイルパスがリポジトリに存在すること、および関数名、変数名、行番号がそれらの場所に実際に存在することを検証してください。参照が欠落しているか不正確な場合は、下流のエージェントが幻覚のバグにリソースを浪費するのを防ぐため、検出結果を直ちに FALSE_POSITIVE とマークしてください。 13. 攻撃者によるソースの制御を検証する（信頼境界のトレース）: データフローの検出結果を VALID とマークする前に、信頼できないデータが分析対象のコードベースに入る file:line（「イングレスポイント」）を特定して引用してください。そこから特定の汚染されたフィールドの値がシンクへ流れ込むか、またはそのフィールドが信頼できない書き込み元によって設定される箇所です。 - 信頼できない側のコード（例: マルチコンポーネントリポジトリにおける Guest／Client）にアクセスできる場合は、書き込み元を引用してください。 - 信頼できる側のコードにのみアクセスできる場合は、データフローパス上の Host／Server のイングレスポイント（例: 共有メモリからの読み取り、IPC ハンドラー、HTTP リクエストパラメータの取得）を引用してください。 - ソースデータが信頼できる側の起源（サーバーが作成した静的設定、ホストプレーンの内部状態）のみに由来することが証明された場合は、FALSE_POSITIVE とマークしてください。 - 例外: このルールを本質的なセキュリティ上の欠陥（ルール 08）には適用しないでください。その脆弱性はアクティブな呼び出し元とは無関係にライブラリコード内に存在します。

   • ステータスの解決:

     • 上記の 13 のルールのいずれかに違反する場合は、FALSE_POSITIVE としてマークします。
     • すべてのルールに合格し、明確でトリガー可能な欠陥がある場合は、VALID としてマークします。
     • ルールには合格するものの、動的な検証なしではその実現可能性が不確かな場合 (たとえば、複雑なヒープグルーミングや正確なタイミングが必要な場合) は、PROVISIONALLY_VALID としてマークします。
     • 高い複雑さ、未解決の外部 API、または巨大なコールグラフのためにレビューが結論に達しない場合 — または、Step 0c Snapshot Provenance Gate によって検出結果が NOT_MATCHED となった (スナップショットドリフト) ために結論に達しない場合は、NEEDS_RESEARCH としてマークします。ドリフト検出結果は Step 0c で確定され、これらの 13 のルールには決して到達しません。ドリフト検出結果を FALSE_POSITIVE として再分類しないでください。
     • SCHEMA-CRITICAL: triage_checklist のエントリが "FAIL" (または "passes": false) になり得るのは、FALSE_POSITIVE のステータスのみです。VALID、PROVISIONALLY_VALID、または NEEDS_RESEARCH の検出結果では、すべてのチェックリストエントリが PASS / NOT_APPLICABLE / UNKNOWN でなければなりません — 決して FAIL にしてはなりません — そうでないと schema.json (418-470 行) が検出結果を拒否します。ルールが失敗しているように見えても、ステータスを FALSE_POSITIVE に設定していない場合 (たとえば、スナップショットドリフトのためだけに Rule 12/13 の参照がずれて見える場合) は、FAIL ではなく reason を付けて UNKNOWN を使用してください。

   • チェックリストの構築:

     • 13 の否定的制約をすべて評価する triage_checklist オブジェクトを構築します。各ルールについて、outcome を次のように設定します:
       • "PASS": 検出結果が制約を満たす場合 (ルールに違反していない、つまりバグが潜在的に有効なままである場合)。
       • "FAIL": 検出結果がルールに違反する場合。任意のエントリを "FAIL" に設定するには、検出結果の status が FALSE_POSITIVE であることが必須です (schema.json の 418-470 行は VALID/ PROVISIONALLY_VALID/NEEDS_RESEARCH に対する FAIL を拒否します)。FAIL エントリには reason も必須です (schema.json の 788-797 行)。
       • "UNKNOWN": ルールの適用可否が未解決である / 調査が必要な場合 (reason が必須)。検出結果を FALSE_POSITIVE としてマークしない場合は常に — ドリフトした NEEDS_RESEARCH 検出結果 (Step 0c) のすべてのルールを含めて — "FAIL" ではなくこれを使用してください。
       • "NOT_APPLICABLE": このルールがこのクラスのバグに完全に無関係である場合 (reason が必須)。
     • 整合性ルール: status が VALID の場合、すべてのエントリは PASS または NOT_APPLICABLE でなければなりません (UNKNOWN も FAIL も不可)。これは schema.json の 471-507 行に基づきます。

4. 再現スクリプトのヒントの構築: VALID または PROVISIONALLY_VALID としてマークされたすべての検出結果について、再現エージェントがどのようにバグをトリガーできるか、どのような入力やペイロードパラメータが必要か、およびセキュリティ上の欠陥を確認するためにどのようなクラッシュ条件、サニタイザートレース (ASan/UBSan/MSan/TSan)、または機能検証結果 (たとえば、予期しない HTTP 200 OK) が期待されるかを説明する、高シグナルの "repro_hints" を提供します。

5. トークン最適化されたファイル更新: LLM の出力トークンを最小化するために、出力内で JSON オブジェクト全体を再出力したり手動で書き換えたりしないでください。 代わりに、最初の検出結果の更新時に再利用可能なヘルパースクリプト (たとえば workspace/helpers/append_review.py) を作成します。以降のすべての検出結果については、スクリプトを再生成せず、既存のヘルパースクリプトを新しいパラメータで実行して、必要なフィールドを追加するだけにします。

   ヘルパーバージョンガード (機械的): ヘルパーの最初の行は、コメント # MANTIS_HELPER_VERSION = 2 でなければなりません。既存の workspace/helpers/append_review.py を再利用する前に、その最初の行を確認します (1 行の grep): マーカーが存在しないか、異なる整数である場合は、ヘルパーを再生成します (古い永続化されたヘルパーは snapshot プロベナンスフィールドを黙って省略し、ドリフトパスを誤って処理します)。再生成されたヘルパーは次の条件を満たさなければなりません:

   • status、reasoning、省略可能な repro_hints、 triage_checklist（JSON）、pass_number、timestamp、および snapshot のパラメーターを受け取ります（"snapshot" キーの下に書き込み、決して "snapshot_id" には書き込みません）。
   • "snapshot"（現在の SNAPSHOT_ID）を含むレビュアーの history エントリーを書き込みます（スナップショットが使われていない SNAPSHOT MODE OFF では省略するか、"" を書き込みます）。
   • (pass_number, snapshot) の冪等性チェック（冪等性保証）を適用します。一致するレビュアーエントリーがすでに存在する場合は何もしません。

   既存のオブジェクトに以下を追加する必要があります。

   • "status" フィールド（"VALID"、"FALSE_POSITIVE"、 "PROVISIONALLY_VALID"、または "NEEDS_RESEARCH" のいずれか）。

   • "reasoning" フィールド。

   • "repro_hints" フィールド（"NEEDS_RESEARCH" または "FALSE_POSITIVE" の場合は省略可能）。

   • 13 個すべての否定的制約の評価を含む "triage_checklist" オブジェクト（各キーは、上記のセクション 3 にある同名の制約に対応します）。

     {
       "ignore_hypothetical_misuse": { "outcome": "PASS" },
       "ignore_missing_hygiene": { "outcome": "PASS" },
       "require_strict_reproducibility": { "outcome": "FAIL", "reason": "自動化できない、不安定な100万分の1の競合状態が必要です。" },
       "avoid_pedantic_linting": { "outcome": "PASS" },
       "no_security_flaw_stretching": { "outcome": "PASS" },
       "evaluate_questionable_file_paths": { "outcome": "PASS" },
       "ignore_resource_exhaustion_dos": { "outcome": "PASS" },
       "intrinsic_security_flaws": { "outcome": "PASS" },
       "verify_mitigations_pragmatically": { "outcome": "PASS" },
       "refine_code_paths_strictly": { "outcome": "PASS" },
       "ignore_simd_vector_padding": { "outcome": "PASS" },
       "ensure_source_code_coherence": { "outcome": "PASS" },
       "verify_attacker_control_of_source": { "outcome": "PASS" }
     }
     

     下位互換性のため、スキーマでは "outcome" の代わりに "passes": <bool> も使用できますが、"outcome" が推奨されます。評価結果が FAIL、UNKNOWN、NOT_APPLICABLE の場合（または passes が false の場合）、評価内容を説明する reason が必要です。PASS / true の場合はトークン節約のため省略してください。

   • "history" 配列へのエントリー（レビューの実施対象となったスナップショットを含み、(pass_number, snapshot) の冪等性に使用します）。

   {
     "stage": "reviewer",
     "action": "reviewed",
     "details": "Determined status as [VALID/FALSE_POSITIVE/PROVISIONALLY_VALID/NEEDS_RESEARCH] because [reason]",
     "pass_number": <current_pass_number>,
     "snapshot": "<SNAPSHOT_ID>",
     "timestamp": "<current_iso8601_timestamp>"
   }
   

   SNAPSHOT MODE OFF（スナップショットが使われていない）の場合は、"snapshot": "" を設定します（またはフィールドを省略します）。schema.json の history_entry には additionalProperties:false がないため、この追加フィールドをそのまま検証できます。

完了したら、ユーザーに通知してください。