Use comment-only PR reviews, never approve or request changes (docker#61)

Prevents the bot from granting merge authority on repos without
branch protection rules, which was allowing PRs to be merged
without human review.

Author: derekmisler

review-pr/agents/pr-review.yaml

@@ -126,6 +126,8 @@ agents:
       You MUST always deliver a review, even if no issues were found.
 
       - **GitHub posting mode**: Post via `gh api` (see Posting format below).
+        ALWAYS use the `COMMENT` event — never `APPROVE` or `REQUEST_CHANGES`.
+        This ensures the bot never grants merge authority or blocks merging.
       - **Console output mode**: Output markdown (see Console format below). Never call `gh api`.
 
       ## Verify Line Numbers (REQUIRED)
@@ -134,33 +136,44 @@ agents:
       If grep returns a different number than the drafter, use grep's. If the file is not
       found on disk, use diff hunk headers instead. Never read the same file more than twice.
 
+      ## IMPORTANT: Comment-Only Reviews
+
+      This action MUST NEVER use `APPROVE` or `REQUEST_CHANGES` events.
+      ALWAYS use the `COMMENT` event when posting reviews via `gh api`.
+      Some repositories lack branch protection rules — using `APPROVE` would let PRs
+      merge without human review, and `REQUEST_CHANGES` would block merging without
+      human ability to dismiss. The bot provides feedback only, never merge authority.
+
       ## Decision Rules (MANDATORY — strict lookup, not a judgment call)
 
       1. **Filter**: Remove findings where `in_changed_code == false` or `in_diff == false`
-      2. **Decide** based ONLY on the highest remaining severity. Do NOT override:
-         - ANY high severity CONFIRMED/LIKELY → `REQUEST_CHANGES`
-         - ANY medium severity CONFIRMED/LIKELY (but NO high) → `COMMENT`
-         - Only low/DISMISSED or no findings → `APPROVE`
-
-      **Example**: 5 medium-severity CONFIRMED findings → `COMMENT` (NOT REQUEST_CHANGES).
-      The number of findings does not matter. Only use REQUEST_CHANGES if at least one
-      finding has severity "high". Do NOT escalate based on quantity or your own judgment.
+      2. **Classify** (for informational labeling in the review summary):
+         - CRITICAL = high severity CONFIRMED/LIKELY
+         - NOTABLE = medium severity CONFIRMED/LIKELY
+         - MINOR = everything else
+      3. **Label the assessment** (informational only — does NOT change the event type):
+         - ANY CRITICAL findings → label as "CRITICAL" in the summary
+         - ANY NOTABLE findings (no CRITICAL) → label as "NEEDS_ATTENTION"
+         - Only MINOR or no findings → label as "APPROVE"
+      4. **Post the review**: The GitHub review event is ALWAYS `COMMENT`,
+         regardless of the assessment label. Never use `APPROVE` or `REQUEST_CHANGES`.
 
       ## Posting Format (GitHub posting mode)
 
       Convert each CONFIRMED/LIKELY finding to an inline comment:
       ```json
       {"path": "file.go", "line": 123, "body": "**ISSUE**\n\nDETAILS\n\n<!-- cagent-review -->"}
       ```
-      Post: `echo '{"body":"## Review Summary\n\n...","event":"EVENT","comments":[...]}' | gh api repos/{owner}/{repo}/pulls/{pr}/reviews --input -`
+      Post: `echo '{"body":"## Review Summary\n\n...","event":"COMMENT","comments":[...]}' | gh api repos/{owner}/{repo}/pulls/{pr}/reviews --input -`
 
       The `<!-- cagent-review -->` marker MUST be on its own line, separated by a blank line
       from the content. Do NOT include it in console output mode.
 
       ## Console Format
 
       ```
-      ## Review: [APPROVE|COMMENT|REQUEST_CHANGES]
+      ## Review: COMMENT
+      ### Assessment: [APPROVE|NEEDS_ATTENTION|CRITICAL]
       ### Summary
       <assessment>
       ### Findings