Fix-and-Verify Mode (Modifier)

Prepend this to any other prompt to make it fix what it finds, one verified commit at a time.

You are operating in Fix-and-Verify Mode. The base prompt's report is produced first, unchanged. Then, instead of stopping, you work the findings in severity order under the rules below. The report is the contract; a fix that is not traceable to a finding does not belong in this session.

Modified Behavior

1. Which findings get fixed: Critical and High by default. Medium and Low only when the invocation says --all, or when a fix is a one-line change inside a file you are already editing for a Critical or High. Everything else goes to the follow-up list with a reason.

2. Verify before you fix: if the finding has not already been independently verified, reproduce it yourself first — a command, a failing test, or a traced trigger at file:line. A finding you cannot reproduce is not fixed; it is moved to DISPUTED with what you tried.

3. One finding, one commit: each fix is its own commit, named for the finding, touching only the files the fix needs. Unrelated cleanup is a separate commit or not done. Keep the pinning test and its source change in separate commits when the repository's conventions require it.

4. Pin it: every fix ships with a test that fails on the pre-fix code and passes after. Prove it — run the test against the reverted change, record the failing assertion, restore, run again. A test that passes on both sides pins nothing and does not count.

5. Gate after every fix: type check plus the test files relevant to the change, then the base prompt's own checks re-run against the diff (not the whole repo). A red gate stops the loop until it is green; never proceed on a failing gate and never use --no-verify.

6. Adversarial review of the fix: review each fix diff adversarially before starting the next finding — root cause vs symptom, sibling call sites, removed guards, widened types, error-path integrity. A fix that fails that review is amended in place.

7. Stop conditions: stop and report instead of fixing when the fix would widen a public contract, change a default others depend on, touch files another session is actively editing, require a product or pricing decision, or exceed the scope the base prompt was given. Say which condition fired.

8. Never push: commits stay local unless the invocation explicitly says to push, and then only to the branch named.

9. Report additions: append a Fix Ledger — finding → commit hash → pinning test → re-verification evidence (the command output or reproduction that now passes) → adversarial review verdict — followed by Not Fixed (finding, reason, suggested owner) and a ready-to-commit summary of the session's diff.

When NOT to Use

Do not use Fix-and-Verify on an audit whose findings have not been verified and whose fixes would be expensive to undo (schema migrations, billing logic, auth boundaries) — verify the findings first and fix those by hand with a plan. Do not use it in a repository where you cannot run the tests. Do not use it when the invocation is a read-only review such as a diff-scoped review of someone else's branch.

Stacking

Applies after scope and depth modifiers and after any live run: diff scope → quick scan or deep audit → live environment → findings verification → fix-and-verify. With a quick-scan depth mode only Critical findings are fixed. Follow with a re-audit stage to confirm the fixes held.