Review Severity

Two Tiers

• Every review finding is blocking or advisory
• The test is behavioral — does fixing the finding change what an agent or the pipeline does?
• Blocking: the fix changes behavior or closes a contract gap
• Advisory: the fix changes only presentation

Blocking — Gates the Merge

• Correctness and security defects
• Policy-contract violations: a carve-out's unmet preconditions, no-secrets, ci-safety gate-evasion, surface-sync that breaks publish
• A rule directive whose violation changes agent behavior
• A style finding whose fix changes meaning — an atomic-bullet split that alters what the bullet directs

Advisory — Never Gates

• Pure prose and style: context-writing-style connective or em-dash placement, a presentation-only atomic-bullet split
• CHANGELOG wording, naming taste, synonym preference
• Anything whose fix changes only presentation, not behavior

Gating Predicate

• Any blocking finding present → the reviewer posts CHANGES_REQUESTED and the merge gates
• Only advisory findings → the reviewer posts APPROVED or COMMENTED and the merge is allowed
• Each reviewer's posted state already encodes this — the event is derived from per-finding severity (see .github/codex-review/post-review.sh and .github/claude-review/review.py)
• The merge watcher gates on either Codex policy or Claude quality CHANGES_REQUESTED (see skills/release/watch-pr-reviews.sh header)

Judge-Weighed Finding Carve-Out

• Narrow exception for merging with a blocking policy finding a weighing ruled defer or decline
• Applies only to policy findings when fixing costs more than the failure it prevents
• Preconditions are binding: read skills/release/references/review-severity-carve-outs.md Judge-Weighed Finding Carve-Out before relying on it
• Every other blocking finding is fixed before merge, including Claude code-quality findings

Split Reading From Acting

• Read every finding in full first — severity never licenses skipping a body (see rules/reviewer-feedback-reading.md)
• Blocking → fix before merge
• Advisory → note it directly in the existing review conversation or the authorized task record without simulating team artifacts
• Fold an advisory only when an already-required blocking correction touches the same surface and it adds no push or verification round
• Never make an advisory a task prerequisite or spend a push, review round, issue, or pull request solely on it