-
Target Agnosticism (Binaries vs Source): If the target is source code,
proceed with generating and applying a code patch as described below. If
the target is a compiled binary or firmware blob without source code
available, do not attempt to modify the binary or write binary patching
scripts. Instead, skip the branch isolation/modification/diff steps and
generate a general, high-level recommendation for how this issue could be
mitigated in a production environment without requiring deep technical
depth. Output this mitigation string in place of the patch_diff field,
and set "patch_status" to "MITIGATION_PROPOSED".
-
Exploit Chains: If the finding is an exploit chain (identified by
"Exploit Chain:" in the title, or history details, or if the
"constituent_findings" property is present and non-empty), do not
generate a code patch or diff. Instead, identify its sub-findings by
reading the "constituent_findings" array of UUIDs. Monitor the patch
status of these constituent findings (listed on disk as
workspace/findings/<uuid>.json). Important: Defer evaluating exploit
chains until all individual findings in the batch have been processed, so
that the latest patch statuses of their constituents are available on disk.
Evaluate the exploit chain status using these propagation rules (evaluated
in order):
-
Validity Check: Read the validity "status" of each constituent
finding. If any constituent's "status" is "FALSE_POSITIVE", update
the exploit chain finding's "status" to match it (e.g.
"FALSE_POSITIVE") and immediately skip any further
patching/verification for the chain. If any constituent's "status" is
"DUPLICATE", resolve it to its canonical finding by recursively
following its "duplicate_of" property.
Duplicate Resolution Process:
- Locate the Finding File: The finding file for the duplicate (or
any parent in the duplicate chain) may have been moved. Search for
<uuid>.json in the following locations in order:
workspace/findings/<uuid>.json (active findings)
workspace/findings/.trash/<uuid>.json (de-duplicated trash)
workspace/archive/findings_pass_*/<uuid>.json or
workspace/archive/loop*_findings/<uuid>.json (archives from
previous passes) If the file cannot be found in any of these
locations, treat it as a missing file error.
- Cycle Detection: Maintain a set of visited finding UUIDs during
the resolution. If you encounter a UUID that has already been visited
in the current resolution chain, raise a validation error (cycle
detected).
- Maximum Depth: Limit the recursion depth to a maximum of 5 steps.
If the chain is deeper, abort and report an error.
- Extract Status: Once you resolve to the canonical finding (one
whose
"status" is not "DUPLICATE" or does not have
"duplicate_of"), use that canonical finding's "status" and
"patch_status" for all downstream checks and propagation. Do not
update the exploit chain finding itself to "DUPLICATE".
-
Missing Files: If any constituent finding's JSON file is missing
from the disk, set the chain's "patch_status" to "ERROR".
-
Constituent Unset or Stale (Pending): A constituent counts as
NOT-YET-VERIFIED if EITHER its "patch_status" is unset (null or
missing, indicating it has not yet been reproduced/processed) OR its
"patch_status" is terminal but its patch_base_snapshot is
absent/empty/different from the current SNAPSHOT_ID (verified against a
stale snapshot — Snapshot & Locator Resolution step 0). If ANY
constituent is NOT-YET-VERIFIED, the chain's "patch_status" must
remain unset (null or missing) and you must defer/suspend further
evaluation of the chain until that constituent is re-verified on the
current snapshot. (In LEGACY mode, where there is no SNAPSHOT_ID, apply
only the "unset" half of this rule, exactly as before.)
-
Constituent Errors: If any constituent's "patch_status" is
"ERROR", set the chain's "patch_status" to "ERROR".
-
Constituent Failures: If any constituent's "patch_status" is
"VERIFICATION_FAILED", set the chain's "patch_status" to
"VERIFICATION_FAILED".
-
Successful Propagation: If all constituents have finished
verification AGAINST THE CURRENT SNAPSHOT (each is in
{"VERIFIED_SECURE", "MITIGATION_PROPOSED", "VERIFICATION_INCOMPLETE"}
AND — except in LEGACY mode — each terminal constituent's
patch_base_snapshot equals the current SNAPSHOT_ID):
- If any constituent is
"MITIGATION_PROPOSED", set the chain's
"patch_status" to "MITIGATION_PROPOSED".
- If no constituent is
"MITIGATION_PROPOSED" and any constituent is
"VERIFICATION_INCOMPLETE", set the chain's "patch_status" to
"VERIFICATION_INCOMPLETE".
- If all constituents are
"VERIFIED_SECURE", set the chain's
"patch_status" to "VERIFIED_SECURE".
Skip branch isolation, testing, and re-attack steps for the chain finding
itself.
-
Optional Parallel Trajectory Search: If your framework supports
subagents, you may spawn multiple concurrent subagents to design diverse
patch implementations. Test all generated patches that successfully secure
the code without breaking standard functionality, and select the best
patch (e.g., the most minimal, readable, and idiomatic fix) rather than
just the first one that works.
-
Read the original flawed file to grasp function dependencies and
structures.
-
Design a minimal, correct patch to mitigate the security flaw (e.g. adding
bound checks, validating sizes, inserting NUL-terminators) without breaking
other features.
-
Transactional Isolation (VCS-Agnostic & Safe): To ensure safety,
reliability, and VCS-agnosticism, do NOT use VCS-based branch operations
(such as git branch, git checkout, or git stash).
You must ensure transactional isolation using a method appropriate for the
operating environment. Isolation-method gate (mechanical):
- If snapshot_pinned is true (PINNED mode) → Option A (Temporary
Directory Shadowing) is MANDATORY. Option B and any method that writes
under CODE_ROOT are FORBIDDEN (Block A step 4: never write under a
pinned snapshot).
- Else if the finding is a RETRY (it already carries a prior
"patch"
history entry or a patch_base_snapshot) OR (PINNED mode AND its
Snapshot Match Check result is NOT_MATCHED) → Option A is MANDATORY
(do not risk editing a live tree that no longer matches the finding). The
PINNED mode AND qualifier on the NOT_MATCHED clause is essential: in
LEGACY mode (snapshot_pinned=false), Block B returns NOT_MATCHED for
every finding as an artifact of no snapshot, not as a signal of drift —
so NOT_MATCHED must only fire when it means "the snapshot changed"
(PINNED), not when it means "no snapshot exists" (LEGACY).
- Otherwise (snapshot_pinned is false AND first attempt — no prior
"patch" history entry and no patch_base_snapshot) you may choose
Option A (recommended), Option B: File-Level Backups, or
design/implement Option C: Alternative Isolation (e.g., namespace
isolation, container volumes, or local sandboxes) as long as it fully
satisfies the invariants below. This covers both LEGACY and HALT mode
first-attempt findings (neither has a prior patch to protect, and neither
is in the PINNED read-only snapshot regime).
Whichever method you choose, you must guarantee these invariants:
- Zero Workspace Pollution: No backup or intermediate build files left
in the original source tree.
- Concurrency Safety: Isolation methods must not conflict with other
concurrent agents.
- Guaranteed Rollback: Wrap all actions in error traps or
try...finally blocks to restore the original state on failure.
-
3-Way Patch Rebasing (Phase 2 incremental efficiency): When a prior
pass's snapshot and patch are still present on disk (see the reachability
check below), the patcher can attempt to REBASE a prior pass's patch onto
the current snapshot instead of generating a fresh patch from scratch. This
is an optimization for the common case where a prior fix still applies with
minor line-number shifts.
- How: If ALL reachability conditions (a)-(d) below hold, read
3-Way Patch Rebasing with your
file-reading tool for the 3-way merge mechanics (
base/ours/theirs
scratch copies, git merge-file / diff3 invocation, conflict-marker
handling). On ANY uncertainty or if the reference cannot be loaded, fall
back to fresh patch generation (Phase-1 behavior).
- When to use (reachability by OBSERVABLE state, not a flag the patcher
cannot read): attempt rebasing ONLY when ALL hold: (a) the prior pass's
snapshot directory AND the file's prior unpatched version actually EXIST
on disk under
<state_root>/.mantis_snapshots/ (retention kept them; if
the base snapshot was GC'd this fails → fall back); (b) the finding's
signature matches an archived finding with a prior patch_diff (same
bug, same signature) — this is the ARCHIVED finding referenced by the
remaining gates; (c) the ARCHIVED finding's patch_base_snapshot is
present and DIFFERENT from the current SNAPSHOT_ID (the snapshot the
prior patch was verified against has changed; this is the correct
"snapshot changed" test — do NOT test Block B on the CURRENT finding,
whose discovery_commit is always == SNAPSHOT_ID in PINNED mode
because researcher stamps it, dedupe backfills it, and plan only
copy-verbatim's MATCHED findings preserving the original
discovery_commit); if the archived finding's patch_base_snapshot is
ABSENT or EMPTY (legacy prior pass, or a pre-Phase-2 patcher that did not
write it — detected by the helper-version marker at step 6), the
snapshot-changed test is UNKN and you MUST fall back to fresh patch
generation (do NOT rebase onto a possibly-unchanged base); and (d) the
finding's primary file is in changed_files. If signature is absent
(legacy finding), condition (b) cannot be satisfied — fall back to fresh
patch generation. Do NOT gate on --snapshot_keep: that flag is set on
the orchestrator and is NOT passed to or readable by the patch stage; the
on-disk presence check (a) is the correct observable substitute and works
under any retention setting (the default keep-2 already retains the
immediately-prior pass). and are
read from (the same state object read for
).
-
When rebasing SUCCEEDS / FAILS / Guardrail: See
3-Way Patch Rebasing for the success (clean
merge → use rebased patch, still run Block G, history note
patch-rebased-from: pass_<N-1>), failure (merge conflict / file deleted /
renamed → fall back to fresh patch generation), and guardrail (on ANY
uncertainty, fall back to Phase-1; never apply a rebased patch with
unresolved conflicts or unrelated changes).
-
Unpatched-Baseline Re-run in --reattack (Phase 2): When the
@mantis-reproduce --reattack sub-agent is re-attacking a patch on a NEW
snapshot (Block B NOT_MATCHED, meaning the snapshot changed since the patch
was verified — in PINNED mode only), the re-attack MUST first re-establish
the unpatched baseline on the CURRENT snapshot before testing the attack
against the patched build. This ensures the re-attack is meaningful: if the
bug no longer triggers on the current unpatched snapshot (e.g., upstream
code fixed it), the re-attack result is inconclusive, not a pass.
- How: Before running the attack on the patched shadow, run the
reproducer against a FRESH UNPATCHED copy of the current snapshot (per
Block G step 1). If the unpatched baseline does NOT trigger (evidence
absent), set
reattack_status = "inconclusive_baseline_changed" with a
history note, and do NOT claim failed_to_bypass (the patch was not
tested against a live bug). If the unpatched baseline DOES trigger,
proceed with the attack on the patched build as normal.
- HALT-mode note: In HALT mode (
snapshot_pinned=false, live:
SNAPSHOT_ID), Block B is always NOT_MATCHED, but this does NOT represent
a genuine snapshot change — it means the tree couldn't be pinned. The
@mantis-reproduce --reattack sub-agent skips the C5 re-baseline in HALT
(see reproduce C5 HALT guardrail) and follows the existing HALT ceiling.
- Guardrail: This does NOT change the VERIFIED_SECURE gate — Block G
still requires the unpatched baseline to trigger. This only adds a
re-baseline step to the re-attack path when the snapshot changed.