adversarial-plan-hardening

name	adversarial-plan-hardening
description	Iterative adversarial review loop for implementation plans. Run passes, resolve BLOCKERs with version bumps, fold WARNINGs in-place, stop at 0 BLOCKERs, audit necessity, prepare handoff brief. Trigger keywords: red-team loop, multiple passes, harden plan, plan hardening, adversarial refinement, clean pass, necessity audit, handoff brief.

Adversarial Plan Hardening

The Loop

Plan v{N} → Adversarial Pass → Findings
  ├─ BLOCKERs found → Create v{N+1} resolving all findings → repeat
  ├─ WARNINGs only → Fold in-place (no version bump) → DONE
  └─ Clean pass → Necessity Audit → DONE

Step 1: Run Adversarial Pass

Run an adversarial review of the current plan version. Each pass must verify claims against the actual codebase (file search + content grep in your harness), not just review plan text. After the first pass, instruct the reviewer: "Do NOT re-report issues already resolved in previous passes."

Rotate models across passes when possible — different models catch different issues. A rotated or freshly spawned reviewer has NO pass history, so the do-not-re-report instruction is meaningless unless you pass the ledger: include the resolved-findings and accepted-findings lists in every new reviewer's prompt.

Step 2: Triage Findings

• Any BLOCKER → create a new plan version resolving ALL findings (BLOCKERs + WARNINGs). Append a "Pass N" section to the plan's Red-Team History.
• WARNINGs only → fold fixes in-place. No version bump. Run one delta review over the folded edits — fix-introduced regressions are the dominant cost of fix loops, and the fold path must not exit unreviewed — then proceed to Step 2.5 like a clean pass. Every exit from the loop goes through the Necessity Audit and Handoff Brief; "DONE" never skips them. Append pass to history.
• Clean pass → proceed to Step 2.5.

Never skip a BLOCKER. Every BLOCKER must be resolved before execution.

Severity mapping (inbound findings from a general red-team pass use BLOCKER/MAJOR/MINOR/NIT): treat un-accepted MAJORs as BLOCKERs for this loop's triage — resolved or explicitly accepted, never silently carried; MINOR/NIT triage as WARNINGs.

Convergence guard: a finding that survives 3 passes unchanged and unaccepted stops the loop — escalate to the user. Persistent reviewer/author disagreement is the signal; an unbounded harden loop is not.

Step 2.5: Necessity Audit (before handoff)

Adversarial review checks correctness: does the code work, are there race conditions, are the paths right? It does NOT check necessity: does this component need to exist?

Before preparing the handoff brief, run a necessity pass on every new piece of infrastructure in the plan:

• New services, endpoints, database columns, cron jobs, environment variables, third-party integrations
• For each: ask "what happens if we don't build this?" and "is there an existing simpler path?"
• Red flag: infrastructure that handles a failure mode you haven't measured. Automated retry for a webhook you haven't seen fail. Alerting for an error you've never observed. A cache for a slow query you haven't profiled.
• Acceptable simpler paths: manual replay + alert, existing admin tooling, "do nothing and observe first"

A plan that passes many red-team rounds for correctness can still contain significant infrastructure solving for an unmeasured failure rate. Correctness review never catches this — only necessity review does.

Step 3: Prepare Handoff Brief

When the plan is clean, produce a deployment-ready document for the execution agent:

1. Agent-specific preamble — rules the execution agent must follow
2. STOP gates — explicit "stop and report" between phases
3. Dangerous operations flagged — mark every irreversible action
4. Condense — adjust file paths to execution context, strip red-team history, remove review-only annotations. The brief is a SEPARATE artifact: never overwrite the versioned plan with the condensed copy — the plan keeps its full pass-by-pass history.