feat(cli): add deterministic minimality and coding-style patch reviews

README.md

@@ -23,6 +23,7 @@ npx @openai/codex-security scan .
 npx @openai/codex-security scan . --patch
 npx @openai/codex-security scan . --patch --patch-severity high --json
 npx @openai/codex-security scan . --patch --patch-severity high --create-pr
+npx @openai/codex-security scan . --patch --review-minimality --review-style
 npx @openai/codex-security scan . --model gpt-5.6-terra --effort high
 npx @openai/codex-security scan . --scan-prompt-file scan.md --post-scan-prompt-file follow-up.md
 npx @openai/codex-security scan . --validation-prompt-file validation.md
@@ -47,6 +48,14 @@ Use `--patch --patch-severity high` to fix high and critical findings. Add
 verified files and open a draft GitHub pull request. Ordinary scans do not
 change repository files.
 
+Add `--review-minimality` or `--review-style` to `scan --patch` or `patch`
+to trigger a deterministic review workflow. The CLI runs each selected review
+as a separate, independent, read-only model invocation: minimality first, then
+local coding style. Both reviews are optional and disabled by default.
+Set `--max-review-revisions 5` to allow up to five author revisions across
+actionable review findings; later-stage revisions restart earlier reviews, and
+blocked reviews still stop immediately.
+
 Deep-scan discovery stops after 96 hours by default. Set `--max-time-hours` to
 any positive number of hours, including fractional hours, up to 96. Completed
 findings are preserved and returned when the limit is reached.

sdk/typescript/README.md

@@ -252,6 +252,7 @@ npx @openai/codex-security scan /path/to/repository --headless
 npx @openai/codex-security scan /path/to/repository --patch
 npx @openai/codex-security scan /path/to/repository --patch --patch-severity high --json
 npx @openai/codex-security scan /path/to/repository --patch --patch-severity high --create-pr
+npx @openai/codex-security scan /path/to/repository --patch --review-minimality --review-style
 npx @openai/codex-security scan /path/to/repository --model gpt-5.6-terra
 npx @openai/codex-security scan /path/to/repository --model gpt-5.6-terra --effort high
 npx @openai/codex-security scan /path/to/repository --path src --path tests
@@ -305,6 +306,7 @@ npx @openai/codex-security patch "Missing authorization check" --effort high
 npx @openai/codex-security patch OCCURRENCE_ID
 npx @openai/codex-security patch --scan SCAN_ID --severity high --json
 npx @openai/codex-security patch --scan SCAN_ID --severity high --create-pr
+npx @openai/codex-security patch --scan SCAN_ID --review-minimality --review-style
 npx @openai/codex-security patch --resume-pr codex-security/patch-SCAN_ID
 npx @openai/codex-security patch --scan latest --severity medium
 npx @openai/codex-security patch --linear-issue SEC-123 --linear-issue SEC-124
@@ -503,6 +505,16 @@ saved-finding `patch` command to commit only verified patch files and open a
 draft pull request with `gh`. If the push or pull request fails, run the printed
 `patch --resume-pr BRANCH` command from the same repository. It uses the saved
 commit without running Codex again and refuses to publish if the branch changed.
+Add `--review-minimality` or `--review-style` to either patching workflow
+to trigger a deterministic review workflow. The CLI runs each selected stage
+as a separate, independent, read-only model invocation, in minimality-then-style
+order. Minimality review removes unnecessary or unrelated changes; style review
+checks project instructions, local conventions, and applicable style guides.
+Both stages are disabled by default.
+Set `--max-review-revisions 5` to allow up to five author revisions across the
+selected review stages. After a later-stage revision, earlier selected reviews
+run again; blocked reviews still stop immediately. Without this option,
+minimality and style each permit one revision.
 JSON scan results include `patchSeverity`. Scan and
 saved-finding results include one `patches` entry per selected finding with
 status `verified`, `no_change`, `blocked`, or `failed`, plus `pullRequest` when

sdk/typescript/_bundled_plugin/skills/fix-finding/SKILL.md

@@ -20,6 +20,8 @@ Judge the result in this order:
 
 Never trade an earlier property for a later one. Minimal means the smallest repository-native change that satisfies all earlier properties, not the fewest lines.
 
+Keep the patch small, concise, focused on the demonstrated vulnerability, and easy to review. Treat remediation suggestions in the finding as hypotheses, not a checklist: implement only what is necessary to close the demonstrated security boundary. Do not redesign working code, protocols, data representations, architecture, or testing infrastructure when a narrower behavior-preserving fix closes the finding. Improving general testability is not the goal; record worthwhile testability improvements, refactoring, and broader hardening in a PR comment, or in the patch summary when no PR exists, instead of implementing them.
+
 ## Patch Contract
 
 Before editing, establish from repository evidence:
@@ -39,6 +41,7 @@ Use this guidance whenever reproducing the finding, running tests, or validating
 
 - Complete the patch contract before broad setup; start with the smallest high-signal check through the real vulnerable boundary.
 - Use repository-supported setup commands. Keep repair effort bounded so it does not displace path analysis, patching, or focused verification.
+- Reuse existing tests and test infrastructure. Do not add extensive testing infrastructure or move, extract, or export production code solely to make it easier to test.
 - Do not stop a progressing command merely because it is slow. Inspect process state, logs, artifacts, or resource use first.
 - If runtime validation remains unavailable, use the strongest targeted static or harness-based artifact that preserves the real integration boundary. Do not substitute a simplified harness that removes the behavior being protected. Record every unrun check as unknown.
 
@@ -64,9 +67,10 @@ The investigation requires repository-relative evidence and a clear separation b
    - If the issue no longer reproduces before any code changes, investigate whether it was already fixed and preserve the validation evidence.
 3. Choose the patch strategy.
    - Determine whether a narrow tactical change can close the boundary while preserving the patch contract.
+   - Treat broad issue descriptions and proposed remediation as leads, not mandatory scope. Do not add downstream controls, sibling fixes, or infrastructure when the narrowest complete change already closes the demonstrated attack path.
    - Consider broader remediation only when the narrow option cannot close the boundary without breaking supported behavior. Remove or disable functionality only when repository or product evidence supports that mitigation.
    - If the only complete fix requires an unresolved decision about product policy, public-API compatibility, or cross-subsystem ownership, return `blocked` with the options, security tradeoff, and likely owner or codeowner when available.
-   - Use nearby variants to test the chosen boundary. Report unrelated sibling findings or longer-term architectural work separately instead of expanding this patch.
+   - Use nearby variants to test the chosen boundary. Report unrelated sibling findings or longer-term architectural work in a PR comment, or in the patch summary when no PR exists, instead of expanding this patch.
 4. Implement the fix and its proof.
    - Make the smallest repository-native change that fully enforces the invariant.
    - Prefer existing helpers and abstractions. Preserve APIs, legitimate inputs, and error semantics unless changing them is required by the security contract.