fix(#45): tighten review verdict criteria for medium findings

agents/review.md

@@ -235,10 +235,16 @@ gh api "repos/${REPO_FULL_NAME}/issues/${ISSUE_NUMBER}"
 - `approve` — no medium+ findings; the change is safe (low/info
   findings may be attached as comments)
 - `request-changes` — findings *requiring* resolution: one or more critical or
-  high findings; multiple medium-severity findings which could affect the
-  intended outcome of the PR
+  high findings; two or more medium-severity findings where at least one
+  identifies a functional bug (incorrect behavior, permission error, schema
+  violation, or silent failure). If the summary text states findings
+  should be addressed, fixed, or resolved before merge, the verdict must
+  be `request-changes`, not `comment` — the summary language and the
+  verdict action must be consistent.
 - `comment-only` — medium-severity findings worth noting but none
-  that should block
+  that should block. Use only when medium findings are stylistic,
+  advisory, or process-related — not when any medium finding identifies
+  a functional bug.
 - `reject` — the approach is fundamentally wrong; no amount of
   code-level iteration will make the PR mergeable (wrong design,
   unauthorized change, or the PR should be closed/rethought)

skills/pr-review/SKILL.md

@@ -776,11 +776,13 @@ Merge the reconciled PR-specific findings (from 6e-1) into the
 challenger-adjudicated finding set and evaluate:
 
 - Any **critical** or **high** finding → `request-changes`
-- Multiple **medium** findings which could affect the intended outcome
-  of the PR → `request-changes`
-- One **medium** finding (but no critical/high) → `comment-only`
-  (attach findings as comments so the author sees them, but do not
-  block the PR)
+- Two or more **medium** findings, at least one of which identifies a
+  functional bug (incorrect behavior, permission error, schema
+  violation, or silent failure) → `request-changes`
+- One **medium** finding, or multiple medium findings that are all
+  stylistic/advisory/process-related (no functional bugs) →
+  `comment-only` (attach findings as comments so the author sees them,
+  but do not block the PR)
 - **Low** or **info** findings only (no medium+) → `approve` (attach
   findings as comments; preserve concrete follow-up work with
   `actionable: true` so the post-script can create follow-up issues)
@@ -790,6 +792,17 @@ challenger-adjudicated finding set and evaluate:
   Use `reject` only when no amount of code-level iteration will make
   the PR mergeable.
 
+**Self-consistency check.** Before emitting the final verdict, verify
+that the verdict action is consistent with the language used in the
+summary paragraph of the review body. If the summary states that
+findings "should be addressed before merge," "must be fixed," "need to
+be resolved," or uses equivalent blocking language, the verdict MUST be
+`request-changes` — not `comment`. A `comment` verdict paired with
+blocking language removes the only automated signal that the findings
+require action, because `comment` (COMMENTED review state) does not
+block the PR. When the summary language and the verdict action
+contradict each other, escalate the verdict to match the language.
+
 ### 7. Produce the review result
 
 Compose the review comment using this structure: