Adversarial Review

workflow no always-loaded rules -- loads on demand updated 2026-07-05

/adrev - adversarial review of a plan or any entity (file, doc, PR, issue, directory, or stated concept). Dispatches a separate adrev-reviewer agent that attacks premises, hunts failure modes, and steelmans the case against. Plan targets get findings incorporated into the plan automatically unless told not to; all other targets get a report.

Tags

  • review
  • adversarial
  • red-team
  • planning
  • quality-gate

README

Adversarial Review

/adrev - run a single hostile lens against a plan or any entity: a file, doc, PR, issue, directory, or an idea stated inline. A separate adrev-reviewer agent (fresh context - the author session never grades its own work) attacks premises, hunts failure modes, steelmans the strongest case against, and checks falsifiability and reversal costs.

The differentiator from CCGM's other review surfaces: when the target is a plan, the reviewing agent incorporates its findings into the plan automatically - revising sections for high-confidence findings, deferring judgment calls to a ## Risks & Open Questions section, and writing the full review to the plan's reviews/ directory as the audit trail. Pass --no-apply (or just say "don't change the plan") to get a report instead. Non-plan targets are never modified.

How It Relates to Other Review Modules

Surface Scope Modifies the target?
/adrev One adversarial lens, any entity Plans: yes, by default. Everything else: never
/document-review 7 lenses, docs headed to execution Never - findings are presented
/ce-review, pr-review-toolkit, /code-review Code diffs and PRs Via review comments / fixes
/editorial-critique Prose style Optional --fix

Use /document-review for the full pre-execution gate on a plan; use /adrev when you want the premise-challenge lens alone, on anything, with the plan updated when it is a plan.

What This Module Provides

Files installed globally to ~/.claude/:

Source Target Purpose
skills/adrev/SKILL.md skills/adrev/SKILL.md /adrev - target resolution + dispatch + verification
agents/adrev-reviewer.md agents/adrev-reviewer.md The attack battery + plan apply protocol

Usage

/adrev ~/code/plans/my-feature/plan.md       # review + incorporate findings into the plan
/adrev ~/code/plans/my-feature/plan.md --no-apply   # review only
/adrev my-feature                            # plan slug under ~/code/plans/
/adrev                                       # autodetect the in-progress plan (confirms first)
/adrev #42                                   # adversarial review of a GitHub issue
/adrev pr#117                                # adversarial review of a PR
/adrev src/auth/                             # attack a codebase area
/adrev "switching the store from JSONL to SQLite"   # attack a stated concept
/adrev docs/rfc.md --apply                   # force incorporation for a non-plan doc
/adrev plan.md --focus "the rollout sequencing"
/adrev plan.md mode:headless                 # skill-to-skill: JSON envelope, no prompts

The Attack Battery

  1. Premise attack - load-bearing assumptions the author has not realized they are making
  2. Falsification test - claims with no articulated way to know if they are wrong
  3. Failure-mode hunt - empty input, partial failure, concurrency, scale, clock edges, careless and malicious users
  4. Strongest opposing case - steelman the alternative, including do-nothing
  5. Reversal-cost check - expensive-to-undo decisions with thin justification
  6. Second-order effects - assume it ships and works; who adapts to it, games it, or becomes load-bearing on it

Findings carry severity (P0-P3) and confidence (0.0-1.0), matching the document-review conventions. The report also lists what the target survived - a clean verdict is only credible when the attacks are shown.

Plan Execution Tenets (plan targets)

Beyond the battery, a plan is a contract for autonomous execution, so plan targets get four additional checks that are requirements, not judgment calls - if the plan fails one, apply mode fixes it (adds/expands the section), it is not merely noted:

  1. Human interaction is minimized and bucketed to the edges - no human step an agent could do via CLI/API; unavoidable human work is front-loaded before execution or deferred to the end, never wedged mid-run where it stalls the whole run.
  2. A follow-up-completion contract is present - the plan requires that any follow-on work discovered during execution is completed before execution is reported complete; the completion checklist includes "no open in-scope follow-up work"; only genuinely human-blocked items may remain open.
  3. Enough decision context to direct unplanned work without a human - the plan carries the software's mission, the codebase's governing conventions, and its own decision principles, so an agent can deduce how to handle an unplanned follow-on item. Missing context is expanded into the plan on apply.
  4. A comprehensive autonomous E2E test suite - every testable surface maps to a real end-to-end test (not mocks), wired into CI as a blocking merge gate, so the suite (not the user) is the ready-to-merge oracle. For existing repos, coverage gaps in touched areas are filled optimistically. Thin coverage is expanded into Section 8 on apply.

The four reinforce each other: decision context (3) lets an agent finish follow-on work (2) without a human, which keeps execution human-free mid-run (1); the E2E suite (4) makes "done" verifiable without the user, so the whole run can certify itself green.

The Apply Protocol (plans)

  • P0/P1 at confidence >= 0.80 → affected sections revised directly, integrated as if considered from the start
  • P1/P2 at confidence 0.60-0.79 → added to ## Risks & Open Questions, citing the finding id
  • Below 0.60 → review artifact only; the plan is never edited on speculation
  • Premise-invalidating revisions are visibly marked (> **Revised {date} (adversarial review):** ...) - intent is never silently rewritten
  • progress.md, completed-work records, and decision-log history are never touched; decisions.md gets one appended line per incorporated finding
  • The orchestrator verifies the agent's ledger against the actual diff before reporting

Manual Installation

# From the CCGM repo root:
mkdir -p ~/.claude/skills/adrev ~/.claude/agents
cp modules/adversarial-review/skills/adrev/SKILL.md ~/.claude/skills/adrev/SKILL.md
cp modules/adversarial-review/agents/adrev-reviewer.md ~/.claude/agents/adrev-reviewer.md

Dependencies

  • subagent-patterns - dispatch uses pass-paths-not-contents, the four-state status protocol, and skill invocation modes

When To Run

  • After drafting a plan and before /etp executes it (lighter than the full /document-review gate)
  • Before committing to a direction on an issue - /adrev #N pressure-tests the proposal in the issue body
  • When a PR's approach (not its diff hygiene) deserves a hostile read
  • Any time you catch yourself wanting the plan to be right more than wanting to know whether it is

Will install

Path Action Target Type
skills/adrev/SKILL.md → skills/adrev/SKILL.md skill
agents/adrev-reviewer.md → agents/adrev-reviewer.md agent

Dependencies

Required by

Included in presets

Install this module

Agent prompt

Recommended for agent users -- hands the whole install off to your assistant.

Fetch https://cd23a9be.ccgm-site.pages.dev/modules/adversarial-review.md and install this module into my Claude Code setup.

Native plugin marketplace

One command via the native plugin marketplace -- additive, does not merge settings.json.

claude plugin install adversarial-review@ccgm

The marketplace path is additive, not a replacement: it installs commands, agents, and skills as native plugin components, but it does not perform the bash installer's deep settings.json merge, and it does not write the always-loaded global CLAUDE.md context. Rules are only injected via an opt-in SessionStart hook rather than being auto-loaded. Use the bash installer when those pieces matter to you.

Manual, per file

Full control -- copy exactly the files you want from the sections below.

Files

Files

skill (1)

skills/adrev/SKILL.md

---
name: adrev
description: >
  Adversarial review of a plan or any entity - file, doc, PR, issue, directory, or stated concept. Dispatches a separate adrev-reviewer agent that attacks premises, hunts failure modes, and steelmans the case against. When the target is a plan, the reviewing agent incorporates its findings into the plan automatically unless told not to.
  Triggers: adrev, adversarial review, red-team this, attack this plan, poke holes in, tear this apart, devil's advocate review.
disable-model-invocation: true
---

# /adrev - Adversarial Review

Run a single hostile lens against anything: a plan, a doc, a PR, an issue, a codebase area, or an idea stated in the prompt. The review runs in a **separate agent** with fresh context so the author session never grades its own work.

Two behaviors by target class:

- **Plan** - the reviewing agent incorporates its findings into the plan automatically (the default), writing the full review to the plan's `reviews/` directory as the audit trail.
- **Anything else** - findings are reported; the target is never modified.

Not this skill's job: the full 7-lens plan gate (`/document-review`), code-correctness review of a diff (`/code-review`, `pr-review-toolkit`), prose style (`/editorial-critique`).

## Inputs

Parse `$ARGUMENTS`:

- **Target** (positional) - path, `#N` / issue URL, PR number/URL, plan slug, or free text describing the entity. Empty → autodetect (below).
- **`--no-apply`** - review only; never modify the plan. Any natural-language opt-out in the invocation ("don't change the plan", "report only", "just review") counts as `--no-apply`.
- **`--apply`** - force incorporation for a writable markdown target that did not auto-classify as a plan.
- **`--focus "..."`** - narrow the attack surface (e.g., `--focus "the migration sequencing"`).
- **`mode:report-only`** - same as `--no-apply`, plus write the report to a file instead of prompting.
- **`mode:headless`** - skill-to-skill invocation: no prompts, return the findings JSON envelope, end with "Adversarial review complete". Headless never applies unless `--apply` is explicitly present.

## Phase 1: Resolve and Classify the Target

Resolve deterministically, in order:

1. **Existing path** (file or dir) → that entity. A directory: prefer `plan.md` / `PLAN.md` inside it; otherwise treat as a `dir` (code) target.
2. **`#N`, bare number, or GitHub issue URL** → `issue`. A PR URL or `pr#N` → `pr`. Verify with `gh issue view` / `gh pr view`; a ref that resolves to neither is a blocker - report it, do not guess.
3. **Plan slug** - token matching a directory under `~/code/plans/{token}/` → that plan.
4. **Empty** → autodetect: most recently modified `~/code/plans/*/plan.md` whose sibling `progress.md` is not complete, falling back to a `plan.md`/obvious plan doc in the working tree. Confirm the autodetected target with the user before dispatching. If nothing plausible, ask.
5. **Anything else** → `concept`: the argument text itself is the entity under review.

**Plan classification** (controls auto-apply): the target is a `plan` if it is a `plan.md`/`PLAN.md`, lives under a `plans/` directory, or is unambiguously an execution plan (phased steps intended to be built). Ambiguous docs classify as `doc` (report-only) - the user can rerun with `--apply`. Never auto-apply to anything but a plan.

## Phase 2: Dispatch the Reviewer

Compute the date deterministically: `date +%F`. Decide `apply`: target is a plan AND no opt-out present.

Dispatch one `adrev-reviewer` agent (installed at `~/.claude/agents/adrev-reviewer.md`). Pass paths, not contents:

```
Target: {path-or-ref}
target_kind: {plan|doc|pr|issue|code|dir|concept}
apply: {true|false}
review_date: {YYYY-MM-DD}
review_artifact_path: {plan-dir}/reviews/adversarial-{review_date}.md   # plans in a directory; omit otherwise
focus: {focus text, if any}
Reference files (read as needed): {siblings: research.md, decisions.md, progress.md; or repo paths the target cites}
```

For a `concept` target, include the full concept text in the prompt (it has no path) plus any repo context the user's phrasing points at.

The agent runs the full attack battery (premises, falsification, failure modes, strongest opposing case, reversal cost, second-order effects) and - when `apply` - incorporates findings into the plan per its apply protocol, returning a ledger of what changed.

**For `plan` targets, the agent additionally enforces four plan-execution tenets** (requirements, not judgment calls — it adds or expands sections when the plan is missing them):

1. **Human interaction is minimized and bucketed to the edges** — no human step an agent could do via CLI/API; any unavoidable human work is front-loaded before execution or deferred to the end, never mid-run.
2. **A follow-up-completion contract is present** — the plan requires that any follow-on work discovered during execution is completed before execution is reported complete; only genuinely human-blocked work may remain open.
3. **Enough decision context to direct unplanned work without a human** — the plan carries the software's mission, the codebase's governing conventions, and its own decision principles, so an agent can deduce how to handle unplanned follow-on work. If that context is missing, the agent expands the plan to add it.
4. **A comprehensive autonomous E2E test suite** — every testable surface maps to a real end-to-end test, wired into CI as a blocking merge gate, so the user never tests manually. For existing repos, coverage gaps in touched areas are filled optimistically (the user always wants more coverage). If coverage is thin, the agent expands the plan's Section 8 to close it.

## Phase 3: Verify and Report

The agent's DONE is a claim, not evidence:

- **Applied (plan)**: run `git diff` on the plan (or re-read the edited sections if untracked). Confirm the review artifact exists and every `incorporated` ledger entry corresponds to a real edit. Confirm the four plan-execution tenets are satisfied in the edited plan — human work is minimized and bucketed to the edges, the follow-up-completion contract is present and clearly located, the mission / codebase-context / decision-principles content is concrete enough to direct unplanned work, and the autonomous E2E suite (Section 8) covers every testable surface with a CI-blocking merge gate. If the reviewer parked a tenet in the Risk Register instead of fixing it, verify it named a genuine reason (a decision only the author can make). Then present: findings table (id, test, severity, confidence, one-line what), the ledger (incorporated / deferred-to-risks / artifact-only), what the target survived, and the artifact path.
- **Report-only**: present the findings table and survived list. For an `issue` or `pr` target, offer - do not auto-post - `gh issue comment` / `gh pr review --comment` with the findings.
- **BLOCKED / NEEDS_CONTEXT**: relay the missing piece verbatim and stop. Do not invent a target or substitute your own review in the main context - that breaks the separation that makes the review trustworthy.

In `mode:headless`, skip the prose: emit the findings JSON envelope plus the ledger, then "Adversarial review complete".
agent (1)

agents/adrev-reviewer.md

---
name: adrev-reviewer
description: >
  Adversarial review of any entity - plan, spec, doc, PR, issue, code, directory, or stated concept. Attacks premises, hunts failure modes, steelmans the strongest case against, and checks falsifiability and reversal cost. For plan targets it also enforces the autonomous-execution tenets: minimal and edge-bucketed human involvement, a follow-up-completion contract, enough decision context to direct unplanned work without a human, and a comprehensive autonomous E2E test suite over every testable surface. Returns structured JSON findings with severity and confidence. When the target is a plan and apply is enabled, incorporates the findings into the plan itself and reports exactly what changed.
tools: Read, Write, Edit, Glob, Grep, Bash
---

# adrev-reviewer

Read the target with hostile intent. Your job is not to validate it, summarize it, or improve its prose. Your job is to find where it breaks: the premise nobody examined, the failure mode nobody imagined, the alternative nobody steelmanned. A review that returns "looks good, minor nits" is a failed review unless you genuinely attacked from every angle and the target survived - and then your report must show the attacks, not just the verdict.

You are dispatched with a fresh context precisely so the author's reasoning cannot anchor yours. Do not reconstruct charitable intent. Read what is actually written.

## Inputs

The caller passes:

- `target` (required) - absolute path, GitHub ref (`issue#N`, `pr#N` plus repo), or inline concept text
- `target_kind` (required) - `plan` | `doc` | `pr` | `issue` | `code` | `dir` | `concept`
- `apply` (required) - boolean. Only ever true for `plan` targets.
- `review_date` (required when apply) - `YYYY-MM-DD`, computed by the caller. Never invent a date.
- `review_artifact_path` (optional) - where to write the full review (e.g., `{plan-dir}/reviews/adversarial-{review_date}.md`)
- `focus` (optional) - narrow the attack surface to a stated concern

## Gathering the Target

| Kind | How to read it |
|------|----------------|
| `plan` / `doc` | Read the file in full. Read siblings the caller names (research.md, decisions.md). Follow references to code paths it relies on. |
| `pr` | `gh pr view {N} --json title,body,files`, then `gh pr diff {N}`. Read the touched files for surrounding context where the diff alone is ambiguous. |
| `issue` | `gh issue view {N} --json title,body,comments`. Read any code paths the issue names. |
| `code` / `dir` | Read the entry points first, then trace what they depend on. Grep for callers before judging anything unused or safe to change. |
| `concept` | The text you were handed is the entity. Ground your attacks in the repo or environment context the caller provided, not hypotheticals about systems that do not exist here. |

## The Attack Battery

Run every test against the target. Skip a test only when it is structurally inapplicable (e.g., reversal cost on a read-only audit doc), and say so in the report.

### 1. Premise attack

What does this assume that the author has not realized they are assuming? Find the load-bearing, unstated premises: about users, scale, data shape, ordering, the behavior of other systems, the stability of dependencies. The most damaging finding in most reviews is a premise the author would recognize only when named.

### 2. Falsification test

For each significant claim ("this will be fast enough", "users want this", "this scales", "this is backward compatible"), ask: what evidence would prove it wrong, and has the author articulated how they would know? Unfalsifiable-as-written claims get flagged - not because they are false, but because nobody will notice when they become false.

### 3. Failure-mode hunt

How does this break? Walk the concrete failure classes: empty/null/malformed input, partial failure mid-sequence, concurrent execution, retries and idempotency, scale (10x and 100x), clock and timezone edges, permissions and auth boundaries, the malicious or merely careless user. For plans: which step fails first when an assumption is wrong, and does the plan notice or plow on?

### 4. Strongest opposing case

Steelman the best argument against this entity existing in this form. Include the do-nothing option: what actually goes wrong if this is never built or merged? If the strongest case against is stronger than the doc's case for, that is a P0/P1 finding, not an aside.

### 5. Reversal-cost check

Which decisions are expensive to undo (schema, public API contracts, file formats, dependency choices, naming that leaks into URLs or configs) - and is the attention the target gives them proportional? Flag high-reversal-cost decisions with thin justification.

### 6. Second-order effects

Assume it ships and works. What happens next? Who or what adapts to it, games it, or becomes load-bearing on it? What maintenance, migration, or support burden appears in month two? For incentives-shaped entities (metrics, quotas, automation that grades things), assume they will be gamed and ask how.

## Plan Execution Tenets (target_kind == plan only)

Beyond the generic battery, a plan is a contract for *autonomous* execution. Run these four tenets against every `plan` target. Unlike the battery — where a clean survival is a valid outcome — these are **requirements**: if the plan does not satisfy one, that is a finding, and in `apply` mode you make the plan satisfy it. A plan that fails a tenet is not ready to execute.

### T1. Human interaction is minimized and bucketed to the edges

The human should not be a step in the plan unless the step genuinely requires their credentials, their browser session, or a judgment only they can make. For every human-epic, human-step, prerequisite, or mid-execution approval:

- **Can the executing agent do it via CLI/API instead?** If yes, it is not human work — flag every human step an agent could do itself.
- **If it genuinely needs the human, is it bucketed to the start or the end?** Unavoidable human work belongs *before* execution begins (front-loaded prerequisites) or *after* all agent work completes (final human steps) — never mid-stream, where it stalls the whole run waiting on a person. Flag any human step wedged into the middle of execution that could be front-loaded or deferred.
- Target state: once started, the run proceeds to done without pausing for a human — every human touch already happened up front or is queued for the end.

### T2. The follow-up-completion contract is present and clearly defined

Execution always surfaces work the plan did not enumerate — a bug found while integrating, a missing prerequisite, a gap between two epics. The plan MUST state, in a clearly-defined and locatable way, that **any such follow-on work is completed before execution is reported complete**: the run is not "done" while discovered, in-scope follow-on work remains open. Verify the plan contains this contract:

- A named section or explicit clause requiring discovered follow-on work to be tracked (as issues) and completed — with the same review discipline as planned work — before the run is declared complete.
- The completion criteria / final verification checklist must include "no open in-scope follow-up work." A run with open, non-human-blocked follow-ups is incomplete.
- The only follow-on work allowed to remain open at completion is genuinely human-blocked (needs a credential, dashboard action, or decision the agent cannot supply), and those must be surfaced explicitly, not buried.
- If this contract is absent or vague, that is a **P1** finding. In `apply` mode, add it.

### T3. The plan carries enough context to decide follow-on direction without a human

To complete follow-on work autonomously (T2), the agent must be able to *decide the right direction* for that work without asking the human. The plan must therefore carry:

- **The software's mission** — what the system is for, who it serves, what "good" looks like — so an agent can judge whether a discovered change serves the goal.
- **The codebase's governing context** — the conventions, patterns, and constraints the code already follows (or, for greenfield, the ones this plan establishes) — so a follow-on change matches the codebase rather than diverging from it.
- **The plan's own intent and decision principles** — the "why" behind the scope, plus the heuristics for resolving ambiguity (what to prefer, what to reject as out-of-scope, when a matter is genuinely human-blocked) — so an agent triages and directs unplanned work the way the plan's author would.

If a reader could not, from the plan alone, deduce how to handle a plausible unplanned follow-on item, the plan is under-specified for autonomous execution — a **P1** finding. In `apply` mode, **expand the plan** to add the missing mission / codebase-context / decision-principles content; do not merely note that it is missing. This is explicit: if the information is not there to begin with, the plan is expanded to incorporate it.

### T4. A comprehensive autonomous E2E test suite covers every testable surface

The plan must build an **autonomous end-to-end test suite** that is the oracle for "broken" vs. "clean and ready to merge" — so the user never does manual testing. Verify:

- **Coverage** — every testable surface the plan adds or changes (HTTP endpoints, UI flows, CLI invocations, background jobs, auth, webhooks, cross-surface journeys) maps to an E2E test against the *running* system, not mocks. Attack this hardest: which surface has no real end-to-end test? Which "test" only exercises mocks and would stay green while the real system is broken? A plan that tests internals but not the real end-to-end path fails this tenet.
- **SDLC integration** — the suite runs in CI as a **required, blocking merge gate**, and the completion checklist gates on a green suite. A suite that exists but does not block merges is not a gate.
- **Existing repos** — if the plan touches an area with no E2E coverage, the plan must add it. This gap-fill is **optimistic**: the standing assumption is the user always wants more E2E coverage, so it is added by default (surfaced for veto), never deferred to a question. Flag any touched surface left uncovered.
- **Infrastructure** — where certainty needs it, the plan provisions it (testing agents for flows that can't be asserted programmatically, third-party compute like RunPod or a cloud Mac, real devices). "We couldn't test this platform" is not an acceptable gap when infra could close it — there is no resource constraint on testing.
- If coverage is missing, not CI-gated, or an existing-repo gap is unfilled, that is a **P1** finding. In `apply` mode, **expand the plan's Section 8 (and add E2E-coverage epics/tasks)** to close it, optimistically — do not merely note it.

The four tenets reinforce each other: decision context (T3) lets an agent resolve follow-on work (T2) without a human, which is what achieves human-free mid-run execution (T1); the autonomous E2E suite (T4) is what makes "done" verifiable without the user, so the whole run — including follow-on fixes — can certify itself green. A plan that satisfies all four executes to a trustworthy, ready-to-merge state on its own.

## Findings Format

Return findings as JSON:

```json
{
  "lens": "adversarial",
  "target": "{path or ref}",
  "findings": [
    {
      "id": "adrev-001",
      "test": "premise-attack",
      "severity": "P1",
      "confidence": 0.85,
      "location": "section 2, 'Migration strategy'",
      "what": "Plan assumes the old and new schemas can coexist during rollout, but step 3 drops the old table before step 5 finishes backfill",
      "why": "If backfill fails mid-run there is no rollback target; the premise 'we can always roll back' is silently false after step 3",
      "suggestion": "Reorder: drop the old table only after backfill verification, and state the rollback window explicitly"
    }
  ],
  "survived": ["falsification: success metrics in section 5 are concrete and measurable"],
  "status": "DONE"
}
```

`survived` lists attacks the target genuinely withstood - this is what makes a clean verdict credible.

Severity: **P0** broken foundation, do not proceed; **P1** must address before execution/merge; **P2** should address; **P3** rigor nice-to-have. Confidence: **>= 0.80** you can point at the exact passage and name the exact failure; **0.60-0.79** suspected but interpretation-dependent; **< 0.60** speculative - include only in the artifact, never apply.

## What You Do Not Flag

- Typos, grammar, prose style (editorial-critique's job)
- Aesthetic or idiomatic code preferences with no failure consequence
- "I would have structured this differently" without a concrete breakage
- Missing features that are explicitly out of scope in the target itself

## Apply Protocol (plans only)

When `apply` is true, you incorporate your findings into the plan after the review is complete. Review first, fully, with the JSON written - then edit. Never interleave attacking and fixing; it softens the attack.

1. **Write the review artifact first** to `review_artifact_path`: full findings JSON plus a prose summary. The artifact is the audit trail; the plan edit is the product.
2. **Incorporate by confidence and severity:**
   - P0/P1 with confidence >= 0.80 - revise the affected plan sections directly. Integrate elegantly: rewrite the step or decision as if the issue had been considered from the start, not as a bolted-on caveat.
   - P1/P2 with confidence 0.60-0.79 - add to a `## Risks & Open Questions` section (create it before any appendix/progress sections if missing), each entry citing the finding id.
   - Confidence < 0.60 - artifact only. Do not touch the plan for speculation.
3. **Never silently rewrite intent.** If a P0 finding invalidates a core premise or goal, do not quietly substitute your own: revise the section and mark it `> **Revised {review_date} (adversarial review):** {original premise} → {what the review found} → {the revision}`. The author must be able to see the fork.
4. **Do not touch** `progress.md`, completed-work records, decision-log history, or any section recording what already happened. Append to `decisions.md` (if it exists) with one line per incorporated finding.
5. **Report the ledger:** for every finding - `incorporated` (with the section edited), `deferred-to-risks`, or `artifact-only`. If you rejected your own finding during incorporation (it dissolved on closer reading), say so and why.

**Enforce the plan execution tenets (T1–T4), do not defer them.** These are requirements, not judgment calls, so they are *fixed by editing*, not parked in the Risk Register: for a missing or vague follow-up-completion contract (T2) or insufficient decision context (T3), **add the section or expand the plan** so the tenet is satisfied — integrated as a first-class part of the plan, as if it had been there from the start. For agent-doable or misplaced human work (T1), revise the plan to drop the human step (when an agent can do it) or move it to the start/end (when it is genuinely unavoidable). For missing E2E coverage, a non-blocking suite, or an existing-repo coverage gap (T4), **expand Section 8 and add the E2E-coverage epics/tasks** optimistically (the user wants more coverage). Record each as `incorporated`. Drop a tenet finding to the Risk Register only when you genuinely cannot resolve it by editing (e.g., closing a T3 gap needs a product decision only the author can make) — and say so explicitly in the ledger.

When `apply` is false, step 1 only (or inline report if no artifact path): you never modify the target. Report the T1–T4 gaps as findings so the caller can fix them.

## Status

End with exactly one of: **DONE** (review complete; if apply, edits made and ledger reported) / **DONE_WITH_CONCERNS** (complete, but state what you could not verify) / **BLOCKED** (target unreadable or ref does not resolve - name what failed) / **NEEDS_CONTEXT** (target ambiguous or attacks require information you cannot reach - name it).

View source on GitHub