mantis-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reviewer (/mantis-review)

审查工具（/mantis-review）

System Goal

系统目标

Independent Validator. Reviews consolidated findings against active source code to verify validity and filter out noise and false positives.

独立验证器。对照活跃源代码审查合并后的发现结果，以验证有效性并过滤干扰信息与误报。

Command Definition

命令定义

Command:
```
/mantis-review
```
Description: Independently reviews findings and filters out false positives.

命令：
```
/mantis-review
```
描述： 独立审查发现结果并过滤误报。

Input/Output Contract

输入/输出契约

Reads:
- ```
workspace/findings/
```
  (finding JSON files, including each finding's optional
```
discovery_commit
```
  provenance stamp).
- ```
workspace/.mantis_state.json
```
  (current loop
```
pass_number
```
  ; and, when present,
```
active_snapshot
```
  =
```
{root, snapshot_id, snapshot_pinned}
```
  for snapshot provenance).
- Invocation args when passed by the orchestrator:
```
--snapshot_root
```
  ,
```
--snapshot_id
```
  ,
```
--state_root
```
  (and, rarely,
```
--target_root
```
  ).
- Target source code files at the
```
code_paths
```
  paths/lines, read under the resolved
```
CODE_ROOT
```
  (the pinned snapshot root — see Instructions Step 0 / Block A), never the live tree when a snapshot is pinned.
Writes:
- Updates findings on disk in-place (sets
```
"status"
```
  ,
```
"reasoning"
```
  ,
```
"repro_hints"
```
  ,
```
"triage_checklist"
```
  , and appends history).
- Writes helper script
```
workspace/helpers/append_review.py
```
  .
Preconditions:
- ```
workspace/findings/
```
  exists with finding files.
- Target source code files exist.
Idempotency Guarantee:
- Modifies finding files in-place using the helper script
```
append_review.py
```
  , which MUST carry
```
# MANTIS_HELPER_VERSION = 2
```
  as its first line; regenerate the helper if that marker is absent or a different integer (see Instructions step 5).
- Idempotency key is (pass_number, snapshot). Before (re)writing a finding, scan its
```
history
```
  array:
  - SNAPSHOT MODE OFF (neither
```
--snapshot_id
```
    was passed NOR is
```
active_snapshot
```
    readable in state): SKIP the review update iff a
```
"stage": "reviewer"
```
    entry already exists for the current
```
pass_number
```
    (byte-for-byte today's behavior).
  - SNAPSHOT MODE ON: SKIP the review update iff a
```
"stage": "reviewer"
```
    entry exists whose
```
pass_number
```
    equals the current pass AND whose
```
snapshot
```
    equals
```
SNAPSHOT_ID
```
    . A reviewer entry that lacks
```
snapshot
```
    (legacy) or carries a different
```
snapshot
```
    counts as UNKNOWN → RE-REVIEW (do NOT skip), so a finding reviewed under the old skill is re-grounded against the current pinned snapshot.

读取：
- ```
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_paths
```
  路径/行对应的目标源文件，在解析后的
```
CODE_ROOT
```
  （固定快照根目录——参见说明步骤0/模块A）下读取，当快照被固定时，绝对不能读取实时代码树。
写入：
- 就地更新磁盘上的发现结果（设置
```
"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"
```
    的条目，则跳过审查更新（与当前行为完全一致）。
  - 快照模式开启：如果存在
```
"stage": "reviewer"
```
    的条目，且其
```
pass_number
```
    等于当前轮次、
```
snapshot
```
    等于
```
SNAPSHOT_ID
```
    ，则跳过审查更新。缺少
```
snapshot
```
    （旧版）或
```
snapshot
```
    与当前不同的审查条目视为未知→重新审查（不跳过），因此在旧工具下审查过的发现结果会重新基于当前固定的快照进行验证。

Instructions

说明

Read and evaluate the deduplicated findings against the actual source code of the repository. Assume every finding is a false positive by default. Your job is to disprove the finding using an adversarial stance. Evaluate the claim based ONLY on the code and the raw claim itself. Explicitly ignore the original finder's prose reasoning and justification, as they may be hallucinated.

Execute your validation as follows:

Step 0 — Locator Resolution & Snapshot Provenance Gate (do this FIRST, before reading any finding's code):

0a. Resolve where to read code. Block A — Locator Resolution here:

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.

The reviewer READS target source, so it is NOT a findings-only stage: run all of Block A steps 1-6.

CODE_ROOT

is the pinned snapshot root you will read every

code_paths

entry under. Per Block A step 3, a

code_paths

entry containing

://

is a URL (existence check only), and any entry not of the form

<existing-path>:<integer>

is a non-source locator (check the artifact/symbol exists; skip all line-existence logic). Never STOP merely because

CODE_ROOT

lacks

.git

.hg

(Block A step 5).

[!NOTE] CURRENT-PASS CHECK (defensive; the binding guarantee is on the harness per
mantis-pipeline-adapter
Scenario 2): if
active_snapshot
is present AND
active_snapshot.pass != state.pass_number
, treat the snapshot as STALE for this pass — STOP "stale active_snapshot: pass mismatch" or degrade as HALT (
snapshot_pinned
effectively false: no authoritative verdicts, Block B NOT_MATCHED, reproduce
not_attempted
). This catches a custom harness that preserved
active_snapshot
across the Stage 15 pass increment without re-pinning. The reference meta-agent re-pins every pass, so this check never fires there. Block B itself cannot detect this (it is
snapshot_id
-only, not
pass
-aware).

0b. Determine SNAPSHOT MODE (once, before touching findings): - SNAPSHOT MODE is OFF iff

--snapshot_id

was NOT passed on this invocation AND

workspace/.mantis_state.json

has no readable

active_snapshot

. This is a legacy / non-sync run: do NOT run the Snapshot Provenance Gate below; review EVERY finding with steps 1-5 exactly as before. - Otherwise SNAPSHOT MODE is ON. From Block A you now hold

SNAPSHOT_ID

and

snapshot_pinned

. Apply the Snapshot Provenance Gate (0c) to every finding.

0c. Snapshot Provenance Gate (SNAPSHOT MODE ON only). After Step 1 loads the findings, apply the match check to EACH finding F via Block B — Snapshot Match Check, applied to 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.)

Then, using the idempotency rule (Input/Output Contract → Idempotency Guarantee) to avoid double-writes:

MATCHED → F is grounded in the current pinned snapshot. Proceed to steps 2-5 (the full 13-rule review) for F.
NOT_MATCHED (includes:
```
snapshot_pinned
```
false / HALT / live-endpoint pass;
```
discovery_commit
```
missing, empty, or the literal
```
MIXED
```
; or
```
discovery_commit != SNAPSHOT_ID
```
) → F was discovered against a different (or absent/unpinned) snapshot; its
```
code_paths
```
line numbers may no longer point at the same code. DO NOT run the 13 rules on F. DO NOT mark it FALSE_POSITIVE. Finalize F as a drift
```
NEEDS_RESEARCH
```
via the helper (step 5), writing EXACTLY:
- ```
"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."
```
- omit
```
"repro_hints"
```
  (and, if F carried stale
```
repro_hints
```
  from a prior pass, leave them — they are ignored downstream because status is not VALID/PROVISIONALLY_VALID).
- ```
"triage_checklist"
```
  : all 13 constraints set to
```
UNKNOWN
```
  (paste the object below verbatim). This object is REQUIRED: appending a
```
reviewer
```
  history entry makes
```
triage_checklist
```
  mandatory on a non-chain finding (
```
schema.json
```
  lines 365-398), and for a
```
NEEDS_RESEARCH
```
  finding every entry MUST avoid
```
FAIL
```
  /
```
passes:false
```
  (
```
schema.json
```
  lines 418-470). Setting
```
ensure_source_code_coherence
```
  and
```
verify_attacker_control_of_source
```
  to
```
UNKNOWN
```
  (never
```
FAIL
```
  ) is the whole point: a line/path mismatch caused by DRIFT is NOT evidence of hallucination, so Rules 12/13 must NOT fire on it.
- append the
```
reviewer
```
```
"history"
```
  entry (with
```
"snapshot"
```
  , per step 5 / the history JSON below). Then STOP processing F — skip steps 2-5 for it.

Drift

triage_checklist

(paste verbatim; all 13 keys, all

UNKNOWN

json

{
  "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" }
}

Findings finalized as drift

NEEDS_RESEARCH

in Step 0c are DONE — do not process them again in steps 2-5. Only MATCHED findings (SNAPSHOT MODE ON) or all findings (SNAPSHOT MODE OFF) flow into steps 2-5 below.

Load Clustered Findings: Read the JSON files in the
```
workspace/findings/
```
directory. If the directory is empty or missing, notify the user.
Source Code Inspection: For each finding that reached this step (in SNAPSHOT MODE ON, only findings that were MATCHED in Step 0c; findings finalized there as drift
```
NEEDS_RESEARCH
```
are already done and are skipped), read the file under
CODE_ROOT
(the pinned snapshot root resolved in Step 0 / Block A — resolve every
```
code_paths
```
path relative to
```
CODE_ROOT
```
, never the live tree) to inspect the exact files and line numbers listed in
```
code_paths
```
and confirm the finding is grounded in the actual snapshot state. Do not make assumptions about the validity of a path without inspecting the source code first.
Strict Validation Filtering (Apply the 13 Negative Constraints): Evaluate each finding against these strict criteria. Mark a finding as FALSE_POSITIVE if it violates any of the following rules:
1. Ignore Hypothetical Misuse: Do not flag security flaws that rely on a calling API hypothetically misusing a function, writing bad fallback logic, or sending invalid parameters if the function itself behaves safely.
2. Ignore Missing Hygiene / Defense-In-Depth: Do not report missing HTTP security headers (e.g.,
```
X-Content-Type-Options
```
  ), missing authentication on local-only test functions, or hardcoded mock databases as security flaws.
3. Require Strict Reproducibility: Only mark a finding as VALID if a direct, unambiguous, and triggerable flaw exists within the boundaries of the code logic. If the finding is extremely fragile (e.g., relies on unstable timing that cannot be automated or brute-forced, or requires unrealistic environmental conditions to trigger), mark it as FALSE_POSITIVE. Note on Race Conditions: Do NOT dismiss race conditions or timing bugs simply because they have a low success probability (e.g., 1 in a million), provided the attack path can be automated and repeatedly attempted by an attacker to eventually trigger the exploit.
4. Avoid Pedantic Linting: If the code uses standard safe libraries (such as
```
json.loads
```
  , parameterised SQL queries, or secure standard library hashes) but lacks extreme paranoia, mark it as FALSE_POSITIVE.
5. No Security Flaw Stretching on Mitigations: If you are reviewing a mitigation or a safe variant of a function that successfully blocks the original security flaw class, do NOT invent complex protocol-level bypasses or adjacent security flaw classes (e.g., SSRF when reviewing Command Injection fixes). If the primary security flaw is successfully blocked, mark it as FALSE_POSITIVE.
6. Evaluate Questionable File Paths: Do NOT instantly dismiss a finding simply because its path contains
```
/test
```
  ,
```
/experimental
```
  , or
```
/mock
```
  . Code in these paths is sometimes compiled into production targets or reachable via production endpoints. Do not blindly assume it is safe; instead, take reasonable measures to trace its usage to confirm whether it is actually exposed in production.
7. Ignore Resource Exhaustion DoS: Do not flag functions for lacking recursion limits, input size boundaries, or cycle constraints unless the primary stated purpose of the module is to defend against DoS attacks.
8. Intrinsic Security Flaws: If a function uses a fundamentally broken algorithm (such as MD5, SHA1), hardcodes static secrets, or contains direct injection paths in its own logic, mark it as VALID even if it is not currently called anywhere in the codebase.
9. Verify Mitigations Pragmatically: Do not hallucinate flaws in active mitigations. If the code adds trailing validation slashes or configures safe parsing flags, accept that the mitigation works.
10. Refine
  code_paths
  Strictly: The
```
code_paths
```
  field should only include the exact
```
filename:line_number
```
  of the flawed code block. Strip out any helper files, test harnesses, or correct caller files from
```
code_paths
```
  .
11. Ignore SIMD/Vector Padding Violations: If a finding represents an out-of-bounds read or write inside optimized vector routines (e.g., NEON, SSE, AVX, VSX), verify if the library employs a global memory allocation contract (such as trailing safety padding, like
```
row_bytes + 16
```
  ). If the out-of-bounds access is mathematically guaranteed to reside entirely within this pre-allocated padding buffer under all execution paths, mark the finding as a FALSE_POSITIVE (By Design).
12. Ensure Source Code Coherence (Anti-Hallucination): Verify that every file path listed in
```
code_paths
```
  exists in the repository, and that function names, variable names, or line numbers actually exist at those locations. If references are missing or incorrect, immediately mark the finding as a FALSE_POSITIVE to prevent downstream agents from wasting resources on hallucinated bugs.
13. Verify Attacker Control of the Source (Trust-Boundary Tracing): Before marking a data-flow finding VALID, identify and cite the file:line where untrusted data enters the analyzed codebase (the "Ingress Point") from which the specific tainted field's value flows to the sink, OR where that field is populated by an untrusted writer.
  - If you have access to the untrusted-side code (e.g. Guest/Client in a multi-component repo), cite the writer.
  - If you only have access to the trusted-side code, cite the Host/Server ingress point on the data-flow path (e.g., reads from shared memory, IPC handlers, HTTP request parameter retrieval).
  - If the source data is proven to originate solely from trusted-side origins (server-authored static config, host-plane internal state), mark FALSE_POSITIVE.
  - Exception: Do not apply this rule to Intrinsic Security Flaws (Rule 08) where the vulnerability exists in library code independent of active callers.
- Status Resolution:
  - Mark as FALSE_POSITIVE if it violates any of the 13 rules above.
  - Mark as VALID if it passes all rules and has a clear, triggerable flaw.
  - Mark as PROVISIONALLY_VALID if it passes the rules, but you are uncertain of its feasibility without dynamic verification (e.g. requires complex heap grooming or precise timing).
  - Mark as NEEDS_RESEARCH if the review is inconclusive due to high complexity, unresolved external APIs, or massive call graphs — OR because the finding was NOT_MATCHED by the Step 0c Snapshot Provenance Gate (snapshot drift). Drift findings are finalized in Step 0c and never reach these 13 rules; do NOT re-classify a drift finding as
```
FALSE_POSITIVE
```
    .
  - SCHEMA-CRITICAL:
```
FALSE_POSITIVE
```
    is the ONLY status for which a
```
triage_checklist
```
    entry may be
```
"FAIL"
```
    (or
```
"passes": false
```
    ). For any
```
VALID
```
    ,
```
PROVISIONALLY_VALID
```
    , or
```
NEEDS_RESEARCH
```
    finding, EVERY checklist entry must be
```
PASS
```
    /
```
NOT_APPLICABLE
```
    /
```
UNKNOWN
```
    — never
```
FAIL
```
    — or
```
schema.json
```
    (lines 418-470) will reject the finding. If a rule looks failed but you are NOT setting status to
```
FALSE_POSITIVE
```
    (e.g. Rule 12/13 references look off only because of snapshot drift), use
```
UNKNOWN
```
    with a
```
reason
```
    , not
```
FAIL
```
    .
- Checklist Construction:
  - Construct the
```
triage_checklist
```
    object evaluating all 13 negative constraints. For each rule, set
```
outcome
```
    to:
    - "PASS"
      : if the finding satisfies the constraint (does not violate the rule, meaning the bug remains potentially valid).
    - "FAIL"
      : if the finding violates the rule. Setting ANY entry to
      "FAIL"
      REQUIRES the finding's
      status
      to be
      FALSE_POSITIVE
      (
      schema.json
      lines 418-470 reject
      FAIL
      on
      VALID
      /
      PROVISIONALLY_VALID
      /
      NEEDS_RESEARCH
      ). A
      FAIL
      entry also REQUIRES a
      reason
      (
      schema.json
      lines 788-797).
    - "UNKNOWN"
      : if the rule applicability is unresolved/needs research (REQUIRES a
      reason
      ). Use this — not
      "FAIL"
      — whenever the finding is not being marked
      FALSE_POSITIVE
      , including all rules on a drift
      NEEDS_RESEARCH
      finding (Step 0c).
    - "NOT_APPLICABLE"
      : if this rule is entirely irrelevant to this class of bug (REQUIRES a
      reason
      ).
  - Consistency rule: if
```
status
```
    is
```
VALID
```
    , every entry must be
```
PASS
```
    or
```
NOT_APPLICABLE
```
    (no
```
UNKNOWN
```
    , no
```
FAIL
```
    ) per
```
schema.json
```
    lines 471-507.
Construct Reproduction Script Hints: For every finding marked as VALID or PROVISIONALLY_VALID, provide high-signal
```
"repro_hints"
```
explaining how a reproducer agent can trigger the bug, what inputs or payload parameters are required, and what crash condition, sanitizer trace (ASan/UBSan/MSan/TSan), or functional validation result (e.g., an unexpected HTTP 200 OK) is expected to confirm the security flaw.

Token-Optimized File Updates: To minimize LLM output tokens, do not re-emit or manually rewrite the entire JSON object in your output. Instead, write a reusable helper script (e.g.,

workspace/helpers/append_review.py

) during your first finding update. For all subsequent findings, do not regenerate the script; simply execute the existing helper script with the new parameters to append the required fields.

Helper version guard (mechanical): the helper's FIRST line MUST be the comment

# MANTIS_HELPER_VERSION = 2

. Before reusing an existing

workspace/helpers/append_review.py

, check that first line (a one-line grep): if the marker is ABSENT or a DIFFERENT integer, REGENERATE the helper (an old persisted helper would silently omit the

snapshot

provenance field and mishandle the drift path). The regenerated helper MUST:

accept parameters for

status

reasoning

, optional

repro_hints

triage_checklist

(JSON),

pass_number

timestamp

, and

snapshot

(write it under key

"snapshot"

, never

"snapshot_id"

);

write the reviewer
```
history
```
entry INCLUDING
```
"snapshot"
```
(the current
```
SNAPSHOT_ID
```
; omit or write
```
""
```
only in SNAPSHOT MODE OFF, where no snapshot is in play);
enforce the (pass_number, snapshot) idempotency check (Idempotency Guarantee): do nothing if a matching reviewer entry already exists.

You must append the following to the existing object:

"status"

field (one of

"VALID"

"FALSE_POSITIVE"

"PROVISIONALLY_VALID"

, or

"NEEDS_RESEARCH"

A
```
"reasoning"
```
field.

"repro_hints"

field (optional for

"NEEDS_RESEARCH"

"FALSE_POSITIVE"

"triage_checklist"

object containing evaluations for all 13 negative constraints (each key in the object maps to the constraint of the matching name from Section 3 above):

json

{
  "ignore_hypothetical_misuse": { "outcome": "PASS" },
  "ignore_missing_hygiene": { "outcome": "PASS" },
  "require_strict_reproducibility": { "outcome": "FAIL", "reason": "Requires unstable 1-in-a-million race condition that cannot be automated." },
  "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" }
}

For backward compatibility, the schema also permits

"passes": <bool>

as an alternative to

"outcome"

, but

"outcome"

is preferred. The

reason

must be provided if the outcome is

FAIL

UNKNOWN

, or

NOT_APPLICABLE

(or if

passes

false

) to explain the evaluation; it should be omitted for

PASS

true

to save tokens.

An entry to the
```
"history"
```
array (now carrying the snapshot the review was performed against, for
```
(pass_number, snapshot)
```
idempotency):

json

{
  "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>"
}

In SNAPSHOT MODE OFF (no snapshot in play), set

"snapshot": ""

(or omit the field).

schema.json

history_entry

has no

additionalProperties:false

, so this extra field validates unchanged.

When complete, notify the user.

读取并评估去重后的发现结果，对照仓库的实际源代码进行验证。默认假设每个发现结果都是误报。你的任务是采用对抗性立场推翻该发现结果。仅基于代码和原始声明本身评估该主张。明确忽略原始发现者的推理和理由，因为它们可能是虚构的。

按以下步骤执行验证：

步骤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）。

[!NOTE] 当前轮次检查（防御性；绑定保证由
mantis-pipeline-adapter
场景2中的工具提供）：如果存在
active_snapshot
且
active_snapshot.pass != state.pass_number
，则将该快照视为当前轮次的过期快照——停止执行并提示"stale active_snapshot: pass mismatch"，或降级为暂停状态（
snapshot_pinned
视为false：无权威结论，模块B判定为NOT_MATCHED，重现状态为
not_attempted
）。这可以捕获自定义工具在第15轮次递增时保留
active_snapshot
但未重新固定的情况。参考元代理每轮都会重新固定快照，因此此检查不会触发。模块B本身无法检测到这一点（它仅识别
snapshot_id
，不识别轮次）。

0b. 确定快照模式（在处理发现结果前执行一次）： - 若本次调用未传递

--snapshot_id

且

workspace/.mantis_state.json

中无法读取到

active_snapshot

，则快照模式关闭。这是旧版/非同步运行：无需执行以下快照溯源检查；按之前的步骤1-5审查所有发现结果。 - 否则快照模式开启。从模块A中获取

SNAPSHOT_ID

和

snapshot_pinned

。对每个发现结果应用快照溯源检查（0c）。

0c. 快照溯源检查（仅快照模式开启时执行）。 步骤1加载发现结果后，通过模块B — 快照匹配检查对每个发现结果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.)

然后，使用幂等性规则（输入/输出契约→幂等性保证）避免重复写入：

MATCHED → F基于当前固定快照。继续对F执行步骤2-5（完整的13条审查规则）。
NOT_MATCHED（包括：
```
snapshot_pinned
```
为false/暂停/实时端点轮次；
```
discovery_commit
```
缺失、为空或字面为
```
MIXED
```
；或
```
discovery_commit != SNAPSHOT_ID
```
）→ F是基于不同（或不存在/未固定）的快照发现的；其
```
code_paths
```
行号可能不再指向相同的代码。不要对F执行13条规则。不要将其标记为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
```
  ，保留即可——由于状态不是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不得触发。
- 追加
```
reviewer
```
  类型的
```
"history"
```
  条目（包含
```
"snapshot"
```
  ，参见步骤5/下方历史JSON）。然后停止处理F——跳过步骤2-5。

漂移状态的

triage_checklist

（逐字粘贴；包含全部13个键，均为

UNKNOWN

）：

json

{
  "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" }
}

步骤0c中最终标记为漂移状态

NEEDS_RESEARCH

的发现结果已处理完成——无需在步骤2-5中再次处理。仅匹配的发现结果（快照模式开启）或所有发现结果（快照模式关闭）进入以下步骤2-5。

加载聚类后的发现结果： 读取
```
workspace/findings/
```
目录中的JSON文件。如果目录为空或不存在，通知用户。
源代码检查： 对于进入此步骤的每个发现结果（快照模式开启时，仅步骤0c中匹配的发现结果；步骤0c中最终标记为漂移状态
```
NEEDS_RESEARCH
```
的发现结果已处理完成，将被跳过），在
```
CODE_ROOT
```
（步骤0/模块A中解析的固定快照根目录）下读取文件——将每个
```
code_paths
```
路径相对于
```
CODE_ROOT
```
解析，绝不能读取实时代码树——检查
```
code_paths
```
中列出的准确文件和行号，确认发现结果基于实际快照状态。在未检查源代码前，不要假设路径的有效性。
严格验证过滤（应用13项否定约束）： 根据以下严格标准评估每个发现结果。如果发现结果违反以下任何规则，标记为FALSE_POSITIVE：
1. 忽略假设性误用： 如果函数本身行为安全，请勿标记依赖调用API假设性误用函数、编写错误回退逻辑或发送无效参数的安全漏洞。
2. 忽略缺失的防护措施/纵深防御： 请勿将缺失HTTP安全头（如
```
X-Content-Type-Options
```
  ）、本地测试函数缺失认证或硬编码模拟数据库报告为安全漏洞。
3. 要求严格可重现性： 仅当代码逻辑范围内存在直接、明确且可触发的漏洞时，才将发现结果标记为VALID。如果发现结果极不稳定（如依赖无法自动化或暴力破解的不稳定时序，或需要不切实际的环境条件才能触发），标记为FALSE_POSITIVE。关于竞争条件的说明： 只要攻击路径可自动化且攻击者可反复尝试最终触发漏洞，请勿仅因成功概率低（如百万分之一）就排除竞争条件或时序漏洞。
4. 避免迂腐的代码检查： 如果代码使用标准安全库（如
```
json.loads
```
  、参数化SQL查询或安全标准库哈希）但未达到极端偏执的程度，标记为FALSE_POSITIVE。
5. 不得扩展已修复的安全漏洞： 如果正在审查的是成功阻止原始安全漏洞类别的缓解措施或安全变体函数，请勿发明复杂的协议级绕过方法或相邻的安全漏洞类别（如审查命令注入修复时提出SSRF问题）。如果主要安全漏洞已成功阻止，标记为FALSE_POSITIVE。
6. 评估可疑文件路径： 请勿仅因路径包含
```
/test
```
  、
```
/experimental
```
  或
```
/mock
```
  就立即排除发现结果。这些路径中的代码有时会被编译到生产目标中或可通过生产端点访问。不要盲目假设其安全；相反，应采取合理措施追踪其用法，确认是否实际暴露在生产环境中。
7. 忽略资源耗尽型DoS： 除非模块的主要明确目的是防御DoS攻击，否则请勿标记缺少递归限制、输入大小边界或循环约束的函数。
8. 固有安全漏洞： 如果函数使用根本有缺陷的算法（如MD5、SHA1）、硬编码静态密钥或自身逻辑中包含直接注入路径，即使代码库中当前未调用该函数，也标记为VALID。
9. 务实验证缓解措施： 不要虚构有效缓解措施中的漏洞。如果代码添加了尾部验证斜杠或配置了安全解析标志，应认可该缓解措施有效。
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前，识别并引用不可信数据进入分析代码库的文件:行（"入口点"），特定受污染字段的值从该点流向 sink，或该字段由不可信写入方填充的位置。
  - 如果可以访问不可信端代码（如多组件仓库中的Guest/Client），引用写入方。
  - 如果仅能访问可信端代码，引用数据流路径上的Host/Server入口点（如从共享内存读取、IPC处理程序、HTTP请求参数检索）。
  - 如果源数据被证明仅来自可信端来源（服务器编写的静态配置、主机平面内部状态），标记为FALSE_POSITIVE。
  - 例外：对于固有安全漏洞（规则08），无需应用此规则，此类漏洞存在于库代码中，与活跃调用方无关。
- 状态判定：
  - 如果违反上述13条规则中的任何一条，标记为FALSE_POSITIVE。
  - 如果通过所有规则且存在明确可触发的漏洞，标记为VALID。
  - 如果通过规则，但不确定在无动态验证的情况下是否可行（如需要复杂的堆整理或精确时序），标记为PROVISIONALLY_VALID。
  - 如果由于高度复杂性、未解析的外部API或庞大的调用图导致审查结论不明确——或由于步骤0c快照溯源检查未匹配（快照漂移），标记为NEEDS_RESEARCH。漂移发现结果在步骤0c中已处理完成，不会进入这13条规则；请勿将漂移发现结果重新分类为
```
FALSE_POSITIVE
```
    。
  - 架构关键要求：
```
FALSE_POSITIVE
```
    是唯一允许
```
triage_checklist
```
    条目为
```
"FAIL"
```
    （或
```
"passes": false
```
    ）的状态。对于任何
```
VALID
```
    、
```
PROVISIONALLY_VALID
```
    或
```
NEEDS_RESEARCH
```
    发现结果，每个检查条目必须为
```
PASS
```
    /
```
NOT_APPLICABLE
```
    /
```
UNKNOWN
```
    ——绝不能是
```
FAIL
```
    ——否则
```
schema.json
```
    （第418-470行）会拒绝该发现结果。如果某个规则看似违反但未将状态设置为
```
FALSE_POSITIVE
```
    （如规则12/13引用仅因快照漂移而异常），请使用
```
UNKNOWN
```
    并附带
```
reason
```
    ，不要使用
```
FAIL
```
    。
- 检查清单构建：
  - 构建
```
triage_checklist
```
    对象，评估所有13项否定约束。对于每条规则，将
```
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
      发现结果的所有规则（步骤0c）。
    - "NOT_APPLICABLE"
      ：如果此规则与该类漏洞完全无关（必须附带
      reason
      ）。
  - 一致性规则：如果
```
status
```
    为
```
VALID
```
    ，每个条目必须为
```
PASS
```
    或
```
NOT_APPLICABLE
```
    （无
```
UNKNOWN
```
    ，无
```
FAIL
```
    ），符合
```
schema.json
```
    第471-507行的要求。
构建重现脚本提示： 对于每个标记为VALID或PROVISIONALLY_VALID的发现结果，提供高价值的
```
"repro_hints"
```
，说明重现代理如何触发漏洞、需要哪些输入或负载参数，以及预期的崩溃条件、 sanitizer跟踪（ASan/UBSan/MSan/TSan）或功能验证结果（如意外的HTTP 200 OK）以确认安全漏洞。

优化Token的文件更新： 为减少LLM输出Token，请勿在输出中重新生成或手动重写整个JSON对象。相反，在首次更新发现结果时编写可重用的辅助脚本（如

workspace/helpers/append_review.py

）。对于后续所有发现结果，不要重新生成脚本；只需使用新参数执行现有辅助脚本，追加所需字段即可。

辅助脚本版本检查（机械性要求）： 辅助脚本的第一行必须为注释

# MANTIS_HELPER_VERSION = 2

。在重用现有

workspace/helpers/append_review.py

前，检查第一行（单行grep）：如果标记缺失或版本号不同，重新生成辅助脚本（旧的持久化脚本会静默省略

snapshot

溯源字段并错误处理漂移路径）。重新生成的辅助脚本必须：

接受

status

、

reasoning

、可选的

repro_hints

、

triage_checklist

（JSON）、

pass_number

、

timestamp

和

snapshot

的参数（写入

"snapshot"

键下，绝不能是

"snapshot_id"

）；

写入包含
```
"snapshot"
```
的
```
reviewer
```
历史条目（当前
```
SNAPSHOT_ID
```
；仅在快照模式关闭且无快照时，省略该字段或写入
```
""
```
）；
执行（pass_number, snapshot）幂等性检查（幂等性保证）：如果已存在匹配的审查条目，则不执行任何操作。

你必须向现有对象追加以下内容：

"status"

字段（取值为

"VALID"

、

"FALSE_POSITIVE"

、

"PROVISIONALLY_VALID"

或

"NEEDS_RESEARCH"

之一）。

```
"reasoning"
```
字段。

"repro_hints"

字段（

"NEEDS_RESEARCH"

或

"FALSE_POSITIVE"

状态下可选）。

"triage_checklist"

对象，包含对所有13项否定约束的评估（对象中的每个键对应上述第3节中同名的约束）：

json

{
  "ignore_hypothetical_misuse": { "outcome": "PASS" },
  "ignore_missing_hygiene": { "outcome": "PASS" },
  "require_strict_reproducibility": { "outcome": "FAIL", "reason": "Requires unstable 1-in-a-million race condition that cannot be automated." },
  "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" }
}

为向后兼容，架构也允许使用

"passes": <bool>

替代

"outcome"

，但优先使用

"outcome"

。如果结果为

FAIL

、

UNKNOWN

或

NOT_APPLICABLE

（或

passes

为

false

），必须提供

reason

以解释评估结果；结果为

PASS

true

时可省略

reason

以节省Token。

```
"history"
```
数组中的一个条目（现在包含审查所基于的快照，用于
```
(pass_number, snapshot)
```
幂等性检查）：

json

{
  "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": ""

（或省略该字段）。

schema.json

中的

history_entry

没有

additionalProperties:false

，因此该额外字段可正常通过验证。

完成后，通知用户。