adversarial-review/docs/superpowers/specs/2026-05-20-adversarial-review-refresh-design.md

Adversarial Review Refresh Design

Overview

This design updates the adversarial-review skill while preserving its core shape: Claude remains the lead, Codex provides an external cross-model adversarial review, and the Sonnet runner isolates mechanical Codex CLI work from the expensive lead context.

The refresh makes the skill more useful to the operator, more robust on modern Codex CLI setups, and less prone to blindly applying reviewer feedback. It does not turn the skill into a larger framework, add mandatory custom agent definitions, or move final decisions from the lead into the runner.

Goals

• Use gpt-5.5 as the default Codex reviewer model while preserving explicit model and reasoning overrides.
• Let Codex reviews use the operator's language while keeping parsed literals stable.
• Improve reviewer capability by avoiding overly restrictive default sandboxing.
• Avoid nested human approval prompts that the operator cannot see from the Claude session.
• Keep runner-side work bounded and disposable so the lead context stays clean.
• Add compact Sonnet triage to reduce repeated review rounds without letting Sonnet make final decisions.
• Require the lead to evaluate findings before applying fixes.
• Support operator sign-off for structural fixes without blocking explicitly autonomous runs.
• Provide a final operator-facing summary of what changed across the review.
• Document Linux sandbox prerequisites clearly enough for a human or installer agent to act on them.

Non-Goals

• Do not require a custom Claude agent type or extra installation artifact.
• Do not use danger-full-access as an automatic fallback.
• Do not make the runner apply fixes, start extra review rounds, or decide final accept / reject / re-scope outcomes.
• Do not move Codex stdout, stderr, or rollout contents into the main Claude context.
• Do not add a mandatory detailed implementation plan for small instructional changes.
• Do not mix documentation languages in repository files.

Default Reviewer Configuration

The default Codex invocation should be optimized for non-interactive review inside a Claude-runner child process:

CODEX_MODEL              = gpt-5.5
CODEX_REASONING          = high
CODEX_SANDBOX            = workspace-write
CODEX_APPROVAL_POLICY    = on-request
CODEX_APPROVALS_REVIEWER = auto_review

workspace-write is the default for all review modes (plan, code, code-vs-plan). The reasoning is load-bearing for this skill, so it is captured here rather than in a comment.

The reviewer needs to actually run things to verify findings: run tests, build the project, query the web or upstream APIs to confirm current behavior, and exercise project CLIs end-to-end. These are write-class operations — test runners produce output and cache files, build commands write artifacts, and most non-trivial CLI execution touches local state. A read-only sandbox blocks all of that.

Read-only is not a total verification blocker. It still allows file inspection, rg / grep searches, MCP-backed doc lookups, and --help-style CLI introspection that does not write to the workspace. But the highest-value findings come from the path read-only blocks: "the reviewer ran the tests and X failed", "the reviewer built the project and Y broke", "the reviewer queried the live API and the assumed signature does not exist." Forfeiting those to gain protection against .gitignored-file side effects is a poor trade.

This applies to plan reviews as much as to code. A plan reviewer should be able to run a test the plan relies on, build the project to confirm a structural claim, or hit an external API to validate an assumption — not just rg for cited filenames. A previous design pass made read-only the default for plan mode and was reverted for this reason.

The safety argument for forcing read-only is also weaker than it appears. The broader obra:superpowers skill family demonstrates that careful prompt-level discipline is sufficient to govern complex agent behavior in security-relevant contexts without sandbox-level restrictions. A concrete instance is superpowers:receiving-code-review: it constrains how a lead processes adversarial feedback — read every finding before reacting, restate the technical claim in own words, verify empirically (especially tool-mechanic claims) before accepting, push back with technical reasoning when wrong, no performative agreement — and that discipline is enforced entirely through prompt instructions, not through any tool-level sandboxing of the lead. The same pattern applies to the reviewer side of this skill: a strict instruction contract (see §Reviewer Behavior), backed by pre/post git status --porcelain and the /tmp sha256 snapshot for after-the-fact detection.

Read-only's specific failure modes are covered without a default sandbox change:

• Tracked-file mutation is caught by git status --porcelain in §Workspace Mutation Detection.
• /tmp review-input mutation is caught by the sha256sum snapshot in the same section.
• Mutation of .gitignored state inside REPO_ROOT is bounded (re-seedable dev state; tests read .env.local, they do not write it) and is mitigated through documentation plus the sandbox:read-only override for operators who knowingly accept the trade-off.

Operators with a concrete reason to opt into read-only (sensitive local state, untrusted reviewer prompt source, or any other case where sandbox-level write protection outweighs verification capability) can do so per-run via sandbox:read-only. The override stays available exactly because the trade-off is real — for those operators. Defaulting the rest of the user base to that mode would gut the skill's main value.

The intended initial codex exec shape:

codex exec --json \
  -m gpt-5.5 \
  -c model_reasoning_effort=high \
  -s workspace-write \
  -c approval_policy='"on-request"' \
  -c approvals_reviewer='"auto_review"' \
  -C "<REPO_ROOT>" \
  -o /tmp/codex-review-<REVIEW_ID>.md \
  -

Codex CLI 0.132+ removed the top-level --ask-for-approval / -a flag from codex exec; approval policy is now expressed only through -c approval_policy=<value>. The spec uses -c form for both approval_policy and approvals_reviewer so the command shape stays self-consistent and future-proof against further short-flag churn. The implementation should verify the supported approval-control surface against the actual installed Codex CLI version during smoke testing.

-o writes only the assistant's final message. The reviewer prompt must deliver the full structured review (findings, severity tags, VERDICT) inside that final message; intermediate tool calls and reasoning will not appear in the review file.

workspace-write gives the reviewer enough capability to run local checks without forcing every useful command through a read-only wall. approval_policy="on-request" keeps boundary crossings explicit. approvals_reviewer="auto_review" avoids human approval prompts inside the nested Codex process, which the operator cannot reliably see or answer from the parent Claude session.

Auto-review is not a security boundary. It reviews approval requests; it does not inspect actions already permitted by the selected sandbox. The skill still needs strong reviewer instructions and workspace mutation checks.

Existing overrides remain:

• model:<name>
• low, medium, high, xhigh

New minimal overrides:

• sandbox:read-only | workspace-write | danger-full-access | inherit
• approvals:user | auto_review | never

Rules:

• Default -s is workspace-write for every review mode. Read-only is a deliberate operator opt-in via sandbox:read-only, never an automatic per-mode default.
• sandbox:inherit omits -s and relies on the user's Codex config. Because the effective sandbox is unknown until Codex actually launches, the runner skips bwrap preflight under inherit. If the inherited config selects a bwrap-backed mode on a host where bwrap is misconfigured, the failure surfaces as a §Runner Result Schema degraded_environmental result and is treated as terminal infrastructure failure on the initial dispatch per the dispatch table.
• approvals:auto_review (the default) passes -c approval_policy='"on-request"' plus -c approvals_reviewer='"auto_review"'.
• approvals:user passes -c approval_policy='"on-request"' only, omitting the approvals_reviewer override so Codex falls back to its default user reviewer. Allowed only by explicit override because nested human approvals can hang the run.
• approvals:never passes -c approval_policy='"never"'; boundary crossings fail instead of asking.
• sandbox:danger-full-access is explicit-only and should surface a warning.
• Codex's untrusted approval policy is intentionally not exposed as an override; the skill needs predictable boundary semantics, not per-command trust prompts.
• No silent fallback may change sandbox or approval semantics.

Resume commands should respect Codex CLI support for resume: sandbox and approval mode are properties of the initial session unless the current CLI explicitly supports changing them on resume. Do not pass unsupported -s flags or approval-related -c overrides to codex exec resume.

Runner Responsibilities

The runner remains a Sonnet subagent responsible for Codex CLI mechanics:

• parse the input block;
• write the prompt with the attempt-scoped session marker;
• launch exactly one Codex operation (initial, resume, or fresh-exec);
• own the one internal retry budget;
• validate exit code, stderr, review file, and session id;
• archive failed-resume diagnostics;
• write the authoritative result JSON;
• return the RUNNER_RESULT_AT: <path> line.

The runner gains bounded analysis:

• run sandbox preflight when the selected mode requires a bwrap-backed sandbox;
• detect obvious degraded reviews, such as sandbox or environment failures disguised as reviewer output;
• extract finding count, maximum severity, and review quality;
• produce compact triage metadata.

Triage rules:

• Cover all critical and high findings.
• Cover up to 10 medium findings.
• If more medium findings remain, summarize the remainder and set an explicit truncation flag.
• Use only cheap checks: file existence, section existence, simple rg, and small read-only snippets.
• Do not run long test suites, web searches, or broad documentation lookups during triage.
• Do not produce final accept, reject, or re-scope decisions.
• If uncertain, mark that lead judgment is needed.

If triage fails but the Codex review is valid, the review should continue with a warning. If the review itself is degraded by infrastructure failure, the runner should not count it as a normal round.

Runner instructions must include negative examples:

• Do not edit project files.
• Do not apply fixes.
• Do not run multiple Codex review rounds in one dispatch.
• Do not delete /tmp/codex-* files.
• Do not decide which findings the lead must accept.
• If a command unexpectedly changes project files, stop and report it.

Runner Result Schema

The runner writes a single JSON file at RESULT_PATH. The schema below is the authoritative contract between runner and lead. New fields added by this refresh are marked (new); everything else preserves the pre-refresh shape.

{
  "result":              "success | timeout | launch_failure | infra_error | input_error",
  "verdict":             "APPROVED | REVISE | null",
  "review_file":         "<absolute path or null>",
  "codex_session_id":    "<uuid or null>",
  "attempt_id":          "<string>",
  "errors":              "<string or null>",
  "archived_stdout":     "<path or null>",
  "archived_stderr":     "<path or null>",
  "user_warning":        "<string or null>",
  "review_quality":      "valid | degraded_environmental | degraded_content | unknown",  // (new)
  "triage": {                                                                            // (new)
    "status":              "ok | skipped | failed",
    "finding_count":       "<int>",
    "max_severity":        "critical | high | medium | none",
    "covered_critical":    "<int>",
    "covered_high":        "<int>",
    "covered_medium":      "<int>",
    "truncated":           "<bool>",
    "needs_lead_judgment": "<bool>"
  }
}

Field semantics:

• review_quality=valid — review file passes R4 checks and content matches a normal review shape.
• review_quality=degraded_environmental — Codex returned an exit-0 pseudo-review caused by sandbox or environment failure (bwrap-EPERM, trust prompt, rate-limit stub, etc.). The text may contain VERDICT: and severity tags but describes an inability to perform the review.
• review_quality=degraded_content — review parses cleanly but the runner's cheap heuristics suggest the body is not actionable (e.g. only a sandbox self-report, no concrete findings backing severity tags). Conservative catch — when in doubt, mark valid and let the lead decide.
• review_quality=unknown — triage could not classify (e.g. triage step itself crashed). The lead should treat this as valid plus a warning.
• triage.status=ok — triage ran, fields populated.
• triage.status=skipped — triage skipped because Codex itself failed (no review to triage).
• triage.status=failed — triage crashed; counts and severity may be missing. Review remains usable if review_quality=valid.

Lead-side dispatch is operation-aware because degraded_environmental on the first dispatch has no prior valid round to fall back on. The full table:

result	OPERATION	review_quality	Lead action
success	any	valid	Proceed to Step 5: show review verbatim, run evaluation matrix, advance round.
success	any	degraded_content	Emit user_warning, show review verbatim, ask operator whether to advance the round.
success	any	unknown	Emit user_warning, treat as valid for advancement, note in final operator summary.
success	initial	degraded_environmental	Emit user_warning, do NOT show review verbatim, treat as terminal infrastructure failure. No prior valid review exists to recover from.
success	resume	degraded_environmental	Emit user_warning, do NOT show review verbatim, do NOT count as a round, route to fallback chain using prior round's severity.
success	fresh-exec	degraded_environmental	Emit user_warning, do NOT show review verbatim, terminal not-verified. Fresh-exec already was the fallback; a second environmental failure means the env is reliably broken.
timeout	any	n/a	Terminal at main per existing rules.
launch_failure	any	n/a	Terminal at main per existing rules (resume launch_failure routes to fresh-exec fallback per existing §7.4).
infra_error	any	n/a	Show errors, abort.
input_error	any	n/a	Show errors, abort (orchestration bug).

Backward compatibility: a runner that omits review_quality or triage fields entirely is treated as review_quality=unknown with triage.status=skipped. Existing field semantics (result, verdict, review_file, codex_session_id, user_warning, etc.) are unchanged.

Reviewer Behavior

The Codex reviewer is an auditor, not a contributor. The prompt should allow useful verification while prohibiting project mutation:

You may run commands to verify findings when useful.
Do not create, edit, delete, commit, or apply fixes to project files.
Prefer commands that do not mutate the working tree.
Do not run commands likely to rewrite generated files, snapshots, migrations,
lockfiles, or configs.
If verification would require mutation, report that limitation instead.
If a command unexpectedly changes files, stop and report it.

This is a deliberate compromise. A reviewer locked into a strict read-only sandbox often cannot run the checks needed to validate tool behavior, tests, or documentation-dependent claims. The primary safeguard is the instruction contract plus post-dispatch mutation detection, not a hard read-only shell.

Lead Responsibilities

The lead owns all product decisions. After each valid Codex review:

1. Show the Codex review to the operator verbatim before applying fixes.

2. Use runner triage only as a hint.

3. Build a compact evaluation matrix:

   finding | severity | evidence | action | reason
   

4. Choose one of three first-class actions for each finding: accept, re-scope, or reject with reasoning.

5. Apply only accepted or re-scoped fixes.

6. Send the reviewer a structured re-review prompt with Applied, Re-scoped, and Rejected with reasoning sections.

Reviewer findings are suggestions to evaluate, not orders to follow. The lead should verify findings proportionally to risk. Critical and high findings need more scrutiny; medium findings can often be accepted, narrowed, or rejected based on local checks and reasoning.

For plan reviews, the lead and reviewer must judge the plan at its declared level of abstraction. Missing implementation details are findings only when their absence blocks feasibility, safety, rollback, verification, or a public contract.

Operator Language

The skill should detect the operator language from recent user messages and ask Codex to respond in that language. If detection is unclear, use English.

Prompt block:

<language>
Respond in the operator's language: <detected language>.
Keep these machine-readable literals unchanged in English:
- [severity: critical|high|medium]
- VERDICT: APPROVED
- VERDICT: REVISE
</language>

Runtime prose shown to the operator should use the operator's language when practical. Repository documentation and skill files remain English.

Prompt Changes

Plan review prompts should add abstraction-level calibration:

Judge the plan at its declared level of abstraction.
Do not demand implementation details unless their absence blocks feasibility,
safety, rollback, verification, or a public contract.
If a detail can reasonably be decided during implementation, do not count it
as a finding.

Re-review prompts should replace the current "I've revised based on your feedback" shape with:

I've evaluated the findings.

## Applied
- ...

## Re-scoped
- ...

## Rejected with reasoning
- ...

## Specific asks for re-review
1. Are my rejections technically valid?
2. Did the applied/re-scoped fixes resolve the original findings?
3. Did the fixes introduce new issues?

Sonnet triage metadata should not be passed to Codex automatically. Codex sees verbatim findings and the lead's decisions, not the runner's notes.

Structural Operator Gate

Before applying structural fixes, the lead should pause once and ask the operator to approve the batch unless the operator explicitly requested autonomous work.

Structural changes include:

• invocation grammar or argument semantics;
• output format or parsed literals;
• workflow steps, fallback semantics, or terminal states;
• sandbox, approval, or security guarantees;
• public configuration semantics;
• schema, migration, or data format changes;
• broad architectural rewrites;
• any fix whose scope the lead is uncertain about.

Non-structural fixes include wording, factual clarifications, examples, and local changes that do not alter external behavior.

If the operator explicitly requested autonomous mode, the lead may apply structural fixes without pausing, but the final summary must state that structural changes were applied without operator sign-off due to autonomous mode.

Workspace Mutation Detection

Mutation detection runs at two layers: the repo tree (git-tracked + new untracked files) and the skill's own /tmp review inputs. A third class of mutation — gitignored files already inside REPO_ROOT — is documented as a known, operator-mitigated risk rather than detected automatically.

Repo tree. The main thread should snapshot workspace state with git status --porcelain before and after each runner dispatch, before Step 5 applies any fixes.

If tracked files changed during the runner dispatch, the skill must hard stop before applying fixes and show an operator diagnostic. This catches reviewer or runner mutation without requiring a custom agent type.

If only untracked generated artifacts appeared, the skill should warn and gate continuation. Some tools leave local artifacts, but the skill must not silently fold them into fixes.

Review inputs in /tmp. The materialized plan file (/tmp/codex-plan-<REVIEW_ID>.md when present), the prompt body (/tmp/codex-body-<REVIEW_ID>.md), and the resume body (/tmp/codex-resume-body-<REVIEW_ID>.md) sit outside REPO_ROOT and are not covered by git status. The main thread must hash these files before dispatch and re-hash after the runner returns:

sha256sum /tmp/codex-{body,plan,resume-body}-<REVIEW_ID>.md 2>/dev/null \
  > /tmp/codex-inputs-pre-<REVIEW_ID>.sha
# ... runner dispatch ...
sha256sum /tmp/codex-{body,plan,resume-body}-<REVIEW_ID>.md 2>/dev/null \
  > /tmp/codex-inputs-post-<REVIEW_ID>.sha
diff -q /tmp/codex-inputs-pre-<REVIEW_ID>.sha \
        /tmp/codex-inputs-post-<REVIEW_ID>.sha

A non-empty diff is treated identically to a tracked-file mutation: hard stop before applying fixes and surface the operator diagnostic.

Out-of-scope: gitignored files inside REPO_ROOT. .gitignored files that already exist inside REPO_ROOT (local SQLite DBs, .env.local, service-state directories, build caches) are NOT detected by either layer. Full-tree snapshotting would be too expensive to run every round, and a pre-dispatch confirmation about "ignored files present" would trigger on essentially every repo (node_modules, target/, .next/) and produce confirmation fatigue — security theater rather than protection.

The realistic mutation vector for these files is the reviewer running a project test or build command that side-effects on the ignored file — for example pytest triggering an unintended migration on dev.sqlite because the test settings point at it. The damage is bounded (the state is re-seedable; tests generally read .env.local, they do not write to it), but it is real on default workspace-write reviews.

The skill mitigates this with three operator-facing affordances rather than architectural force:

1. The sandbox:read-only override is always available — operators who know they have sensitive ignored state can opt out of test execution at the cost of empirical verification (the reviewer loses the ability to run tests, linters, and most MCP-backed verification).
2. The README must include a "Safety considerations" section with the concrete pytest → dev.sqlite vector, the opt-out guidance (with its explicit verification trade-off), and the worktree-isolation pattern (git worktree add /tmp/review-worktree <ref>) for sensitive repos.
3. At the start of every review, the skill emits a one-line runtime hint: workspace-write in effect; pass sandbox:read-only if sensitive ignored state lives under REPO_ROOT. The hint appears exactly once per review (not per round) and is suppressed when the operator passed an explicit sandbox:* override.

This is a deliberate trade-off. Defaulting reviews to read-only or to an isolated worktree would gut the reviewer's empirical verification capability (tests, linters, builds, MCP doc lookups, web searches all require execute) — and empirical verification is precisely what makes adversarial review more valuable than a same-model self-check. The mitigation level is documentation and operator awareness rather than architectural force.

Linux Sandbox Prerequisites

The README should document sandbox prerequisites for Linux users and installer agents. With the default workspace-write mode, Codex may rely on bubblewrap and unprivileged user namespaces.

Diagnostic probe:

bwrap --dev-bind / / --unshare-net /bin/echo ok

If the probe fails on Ubuntu 24.04+ due to AppArmor user namespace restrictions, recommend the official bwrap AppArmor profile:

sudo apt install -y apparmor-profiles apparmor-utils
sudo install -m 0644 /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

Then verify:

bwrap --dev-bind / / --unshare-net /bin/echo ok

The README should link to the official OpenAI Codex sandboxing documentation: https://developers.openai.com/codex/concepts/sandboxing.

Installer agents should not change AppArmor policy silently. They should probe, show the exact commands, request explicit permission, apply the profile only after approval, and re-run the probe.

Final Operator Summary

At every terminal state, the skill must provide an operator-facing summary in the operator's language. This summary comes after the final verbatim reviewer response and does not replace it.

Include:

• final status: approved, maximum rounds reached, not verified, or aborted;
• what changed across all review rounds;
• findings applied, re-scoped, and rejected;
• structural changes and whether operator sign-off was obtained;
• verification performed and verification not performed;
• remaining findings or risks;
• a short explanation of what the status means for non-approved terminal states.

Constraints:

• Do not include full diffs.
• Do not repeat full reviewer findings unless unresolved findings matter.
• Keep it concise and useful to the operator.
• Build it from per-round decision summaries already shown in conversation.
• Do not read Codex stdout, stderr, or rollout files from the main thread.
• If context compaction makes history incomplete, state that limitation explicitly instead of inventing details.

Documentation Language Rule

Repository documentation and skill files stay in English:

• SKILL.md
• references/runner.md
• README.md
• docs/DESIGN.md
• design specs under docs/superpowers/specs/

Runtime output may use the operator's language. Do not mix Russian and English inside repository documentation paragraphs except for machine-readable literals, CLI flags, config keys, JSON keys, or quoted runtime examples.

Files To Update

Expected implementation touches:

• SKILL.md

  • default model, sandbox, approval parsing (note: approval policy is expressed via -c approval_policy=..., not the removed -a flag);
  • language detection and language block;
  • runner input schema extensions;
  • runner result schema consumption (review_quality, triage.*) and the operation-aware lead-side dispatch table from §Runner Result Schema;
  • evaluation matrix;
  • structural operator gate;
  • structured resume prompt;
  • workspace mutation snapshots at both layers (git status --porcelain AND sha256sum of /tmp/codex-{body,plan,resume-body}-*);
  • one-line runtime hint at the start of every review about the workspace-write default and the sandbox:read-only opt-out (suppressed when an explicit sandbox:* override is passed);
  • final operator summary.

• references/runner.md

  • default Codex command flags (config-based approval policy via -c);
  • bwrap preflight before every dispatch that selects a bwrap-backed sandbox mode;
  • degraded-review detection;
  • bounded triage metadata;
  • emit the full runner result schema (§Runner Result Schema), including review_quality and the triage object;
  • stronger mandate and negative examples.

• docs/DESIGN.md

  • rationale for reviewer permissions;
  • default model update;
  • nested approval reasoning;
  • Sonnet triage compromise;
  • operator-language behavior;
  • final summary rationale;
  • version and verification log update after smoke testing.

• README.md

  • updated defaults (including config-based approval policy via -c, not -a);
  • sandbox/approval behavior;
  • Safety considerations section: the gitignored-file mutation vector (pytest → dev.sqlite migration), residual risk acknowledgment, the sandbox:read-only opt-out (with the explicit caveat that read-only blocks empirical verification — operators trade verification for write-protection), and the git worktree-based isolation pattern for sensitive repos;
  • Linux bwrap/AppArmor setup;
  • operator language behavior;
  • final summary behavior.

Do not renumber existing docs/DESIGN.md sections.

Verification

Use the existing smoke protocol in docs/DESIGN.md §7, updated for the new model and flags where needed.

Additional manual smoke checks:

• codex exec launches with -s workspace-write, -c approval_policy='"on-request"', and -c approvals_reviewer='"auto_review"' on the target Codex CLI version (verify against the actual installed version — codex exec --help must list -s and -c; the absence of -a/--ask-for-approval is expected on 0.132+).
• codex exec resume does not receive unsupported sandbox or approval flags.
• bwrap-backed sandbox failure for workspace-write produces an early diagnostic before Codex launches, instead of a fake review round.
• sandbox:read-only override still works and the runner skips approval prompts inside the nested process (the operator can verify this by running a review against a known-bwrap-failing host with the override).
• language block preserves parseable [severity:] and VERDICT literals.
• runner result JSON contains review_quality and triage fields when triage runs; legacy result JSON (no review_quality, no triage) is accepted by the lead as review_quality=unknown / triage.status=skipped.
• triage failure does not fail an otherwise valid review.
• a synthetic success + degraded_environmental on OPERATION=initial is treated as terminal infrastructure failure (no prior round to recover from); the verbatim review is NOT shown.
• a synthetic success + degraded_environmental on OPERATION=resume emits the warning, does not consume a round, and routes to the existing fallback chain using the prior round's severity.
• a synthetic success + degraded_environmental on OPERATION=fresh-exec is treated as terminal not-verified.
• a synthetic success + degraded_content (on any operation) emits the warning, shows Step 5 verbatim, and prompts the operator for explicit advancement.
• pre/post git status --porcelain catches workspace-tree mutation.
• pre/post sha256sum of /tmp/codex-{body,plan,resume-body}-<REVIEW_ID>.md catches reviewer mutation of /tmp review inputs.
• the runtime hint about workspace-write and the sandbox:read-only opt-out appears exactly once per review (regardless of mode) and is suppressed when the operator passed an explicit sandbox:* override.
• final operator summary appears at approved, max-rounds, not-verified, and aborted terminal states.

Dogfood the result with:

• plan review of this design;
• code review after implementation.

No automated CI is required for this refresh.