Generates a human-readable security review packet compiled from confirmed findings and exploit chains. Use at the end of a review cycle to produce stakeholder-facing documentation. Don't use for auditing code or verifying patches directly.

Reporter (/mantis report) System Goal Security Reporting Expert. Synthesizes complex, technical finding logs into a high quality, human readable review packet for developers and stakeholders. Command Definition Command: /mantis report Description: Generates a human readable security review packet containing confirmed findings and exploit chains. Input/Output Contract Reads : workspace/findings/ .json (all active finding files for this pass). workspace/archive/findings pass / .json (archived findings from prior passes) and legacy workspace/archive/loop findings/ .json . The report is a campaign wide view: this pass's full findings plus carried forward findings that prior passes stopped retrying (e.g. hit the retry cap) so they do not vanish from the report. workspace/.mantis state.json (to track current loop pass, and to read vcs info and active snapshot { root , snapshot id , snapshot pinned } for provenance). Per finding snapshot provenance fields, all OPTIONAL: discovery commit , repro snapshot id , patch base snapshot . When any is absent/empty it is rendered as "(not recorded)" — never a reason to drop a finding. Writes : workspace/report/review packet pass <N <snapshot tag .md (pass and snapshot tagged markdown report). Falls back to the unsuffixed review packet pass <N .md on a legacy pass with no recorded snapshot. Updates copy/symlink at workspace/report/review packet latest.md . Preconditions : Calibrated and reproduced findings exist in workspace/findings/ or workspace/archive/ . The report is a campaign wide view: it reports the current state of every unresolved finding discovered in this or any prior pass, de duplicated to each finding's latest state. A confirmed but unfixed finding that plan stopped carrying back (e.g. it hit the 2 attempt retry cap) does NOT vanish — it appears here at its most recent archived state. Idempotency Guarantee : Writes to pass and snapshot tagged files. In place overwrite of review packet latest.md . Re running the SAME pass on the SAME snapshot updates the same tagged file. Re running the same pass number on a DIFFERENT snapshot writes a DISTINCT file (the <snapshot tag suffix prevents cross snapshot overwrite). Legacy passes with no recorded snapshot keep the unsuffixed review packet pass <N .md name and overwrite in place, exactly as before. Instructions Step 0 — Locator Resolution. Then the following FINDINGS ONLY notes apply to the Reporter: The Reporter is a FINDINGS ONLY stage (Block A, ROLE step 0): it SKIPS locator steps 2–6, does NOT require or resolve a CODE ROOT, and NEVER stops because a code root or sentinel is unset. It STILL reads active snapshot ( root , snapshot id , snapshot pinned ) and vcs info from workspace/.mantis state.json for provenance — used to build the header, the top banners, and the output file name. Every path the Reporter touches ( workspace/findings/ .json , workspace/.mantis state.json , workspace/report/ , workspace/archive/ ) is STATE RELATIVE and is NEVER prefixed with CODE ROOT. Compile a professional Markdown report detailing the verified/reproduced vulnerabilities and exploit chains. Execute the reporting stage as follows: 1. Load findings — this pass in full, plus carried forward open findings (newest first fold; no script). Build a working set keyed by finding identity, each finding once at its most recent state: SAME BUG PREDICATE (used for ALL current↔archived dedup, fold, and suppression in this stage; over reporting is always safe here, hiding a real finding is never acceptable): two findings are the SAME BUG only if EITHER (i) they have the exact same id (UUID); OR (ii) ALL THREE hold — they share a non empty lineage id , they share a non empty signature , AND at least one code paths entry compared WITH its trailing :line (line inclusive) is identical between them. Otherwise they are DISTINCT — render BOTH. NEVER treat two findings as the same bug on lineage id alone or signature alone: both are coarser than a bug's true identity (basename derived lineage can link two distinct same named files; a signature strips the line number so it collides between distinct same file bugs), and collapsing on either alone can silently drop a real finding. Design note (re anchoring vs fold): mantis plan 's re anchoring (Phase 2\) only provides a line hint that steers RE DISCOVER — it does NOT rewrite the carried finding's code paths . A re discovered finding surfaces at its NEW line on the current snapshot. Because the fold predicate requires a line inclusive code paths match, the re discovered finding will NOT fold with its ancestor (the line numbers differ). This is SAFE over reporting — both entries render, the current one shows the new location. A future phase could relax the predicate to path only matching when BOTH findings carry the same signature AND lineage id AND the ancestor's line is confirmed absent on the current snapshot, but the conservative line inclusive match is used today to prevent any silent drop risk. 1. Read all active workspace/findings/ .json and add every active finding to the working set, keyed by its id (UUID) — all remediation statuses, so this pass's VERIFIED SECURE / MITIGATION PROPOSED fixes still render with their patches in Categories 1/2. NEVER collapse two ACTIVE findings, even if they share a lineage id or signature — keep each active id as its own entry. 2. Scan workspace/archive/findings pass <N / (and legacy loop<N findings/ ) in descending pass order. Add an archived finding only if it is still OPEN (see 4) AND NO finding already in the working set is the SAME BUG as it (per the predicate above) AND no earlier (higher pass) archived copy of the SAME BUG was already added. First copy met = latest state; ignore later same bug copies in lower dirs. (An archived finding is suppressed ONLY when a genuine same bug supersedes it; a mere lineage id or signature coincidence does NOT suppress it.) 3. Supersession fold (Phase 3): When an archived finding IS the SAME BUG (predicate ii) as a current finding, the current finding supersedes it — show a single entry at the current (most recent) state; do not also render the archived copy. When the predicate is NOT satisfied (different signature , e.g. a file rename, or lineage id absent), render both as separate entries (safe over reporting, never hiding). Under reporting safeguard: If the current (superseding) finding FAILS the actionable predicate (step 4 below) but the archived ancestor would have PASSED it (e.g., the ancestor was reproduced and OPEN, but the current pass's reproduce resulted in not attempted due to a transient build/environment failure on the new snapshot), do NOT let the transient downgrade suppress the confirmed open bug. Instead, keep the ancestor's last confirmed state visible in the report (render it with a note "Open — repro pending on new snapshot") so a previously confirmed bug can never silently disappear from the report. The current finding's newer metadata (e.g., updated code paths line numbers) may still be attached as an annotation, but the verdict/status shown must be the ancestor's last confirmed state, never the transient downgrade. 4. Actionable / quality predicate (applies to active AND archived): include a finding only if it is an exploit chain ( constituent findings present, or "Exploit Chain" in title/history) OR repro status is reproduced OR ( repro status is statically confirmed AND it carries empirical execution evidence — an external stack trace, sanitizer trace (ASan/UBSan/MSan/TSan), or crash log). Do not include false positives, NON VIABLE , DUPLICATE , failed to reproduce , or ordinary statically confirmed findings lacking empirical traces. 5. Open predicate (archived carry forward in step 2 only): an archived finding is "still open" if it satisfies (4) AND patch status is NOT VERIFIED SECURE / MITIGATION PROPOSED AND status is not FALSE POSITIVE / DUPLICATE AND production viability is not NON VIABLE . (Active findings are loaded regardless of patch status so this pass's fixes still appear; archived fixed findings are not re listed every pass — use the optional "Resolved this campaign" rollup for a cumulative fixed view.) 6. Scale: process one directory at a time, newest first; never load the whole archive at once. Severity Filtering: Exclude findings with a priority of "LOW" from the main report body. You must place these lower priority issues into a separate, dedicated "Appendix: Low Priority Findings" section at the very end of the report, keeping the main report focused on high risk issues. 2. Extract Key Artifacts: For each reproduced finding, extract and format: Header Metadata: Title, ID (UUID), Inferred Exposure, Final Risk Score, and Qualitative Priority. Campaign Provenance: Annotate each open finding with the pass it was first discovered in vs. the current pass (e.g. discovered pass 2 · still open as of pass 7 ), so carried over findings are visible as such. First seen = the lowest pass number in the finding's history entries (or the pass number of the lowest numbered archive dir that contains it); current state = the copy you kept from the fold above. Duplicate Advisory: If the finding has a possible duplicate of field (set by mantis dedupe when a cross pass candidate was NOT MATCHED), emit an advisory note: Possibly related to finding <UUID (cross pass candidate; snapshots differ — not confirmed duplicate). This makes the advisory regression pointer visible to the stakeholder. Discovery Snapshot: Emit Discovery Snapshot: <discovery commit for the finding. If discovery commit is missing or empty, emit Discovery Snapshot: (legacy — not recorded) . Never omit or drop the finding because this field is absent. Vulnerability Description & Impact: A clear explanation of the bug and the concrete impact on the system. Reproduction Evidence: The PoC script path ( repro file path ) and execution command ( run command ). A clean snippet of the stdout/stderr showing the successful exploit trigger ( repro output ). Evidence base: label the reproduction evidence with the snapshot it was gathered on: Evidence base: <repro snapshot id . If repro snapshot id is missing or empty, write Evidence base: (not recorded) . Do NOT assume it equals the header/pass snapshot. Risk Rationale: The independent validation reasoning ( reasoning ), production viability reasoning ( critic reasoning ), and outrage factor analysis ( outrage commentary ). Remediation & Patch: The recommended mitigation strategy. The verified patch diff ( patch diff ) and re attack status to prove the fix is resilient. Apply against: label the patch diff with the snapshot it applies to: Apply against: <patch base snapshot . If patch base snapshot is missing or empty, write Apply against: (not recorded) . If patch base snapshot is present and differs from this finding's discovery commit , add a one line caution that the diff was generated against a different snapshot and may not apply cleanly to the discove

mantis-report