Feature Remediation and Fixes

Feature: Remediation & Fixes (opt-in)

The audit is detection-only by hard design — Guardrails & Safety keeps the repo read-only through the whole detection path. Remediation is a separate, opt-in flow (argo fix, POST /runs/{id}/fixes) that turns confirmed findings into proposed patches for a human — never auto-applied, never submitted.

How it works

1. Propose. One model session per confirmed finding (read-only repo, artifact tools) describes the change in a FIX.json — either a full-file rewrite (new_content) or, for large files, search/replace edits (each search must match the file exactly once). Argo then computes the unified diff mechanically (difflib) into runs/<id>/patches/<id>.diff. Because the model never writes hunk headers, it can't miscount @@ ranges — the "corrupt patch" failure mode that broke multi-hunk diffs on large real repos. (A raw *.diff is still accepted as a legacy fallback.)
2. Verify, on an isolated copy (the source mount is never touched):
   • baseline build/compile check on the copy → error set B;
   • apply the patch (git apply -p1, falling back to patch --fuzz=0);
   • patched build/compile check → error set A;
   • new_errors = A − B (error signatures normalized so a patch that only shifts line numbers isn't mistaken for a regression). verified = applied ∧ compiles ∧ no new_errors.

Pre-existing breakage never fails a patch — only errors it introduces do. The build runs locally (auto-detected: py_compile, node --check, go build, cargo check, …) or in Docker (--network=none, offline) via an explicit --build-cmd.

argo fix --run RUN_ID                          # propose + verify all confirmed findings
argo fix --run RUN_ID --only ID,ID             # just these findings
argo fix --run RUN_ID --no-verify              # skip the build/compile check
argo fix --run RUN_ID --docker IMAGE           # verify inside this image
argo fix --run RUN_ID --re-audit               # see below

Optional re-audit — "is the bug actually gone?"

With --re-audit, after a patch verifies, Argo runs a focused, unbiased audit session on the patched copy — scoped to the finding's affected file(s), and deliberately not told which bug to look for. If the re-audit no longer reports the original vulnerability class in that file, the verdict carries re_audit.confirmed_fixed. This is a probabilistic signal (the model could miss the bug for unrelated reasons), reported alongside the build check, never instead of it. Folded into the benchmark as patch_quality.re_audit_confirmed_rate.

In the web UI

The Fixes results tab: "Propose & verify fixes" generates a reviewable diff per confirmed finding and shows each with its verify verdict — ✓ verified, compiles, no new errors, or ⚠ with the reason. Patches are proposals for a maintainer — never auto-applied or submitted. See Web UI.

Known limitation — diff fidelity on large real repos

On a real large multi-module run (Java, deep paths), 7 of 11 model-generated unified diffs failed git apply with "corrupt patch" — the model miscounted multi-hunk @@ line ranges (the simpler single-hunk diffs applied and verified fine). verify_patch correctly flags non-applying patches (they remain useful as guidance, just not auto-appliable). The robust long-term fix is having the model emit the full rewritten file instead of a hand-counted diff, and computing the diff mechanically — planned but not yet built.

Related

• Benchmarks & Costs — where --fixes folds the verified-patch rate into a benchmark run.
• Runtime Verification — reuses the same isolated-copy / --network=none build machinery.