Independently reviews findings and filters out false positives. Use when consolidated findings need validation against the actual source code. Don't use for reproducing crashes or patching code.

Reviewer (/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. 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. 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: 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: 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 ): 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. 1. Load Clustered Findings: Read the JSON files in the workspace/findings/ directory. If the directory is empty or missing, notify the user. 2. 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. 3. 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: 01. 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. 02. 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. 03. 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. 04. 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. 05. 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. 06. 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. 07. 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. 08. 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. 09. 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 ev

mantis-review