chore: silence bot reviewers (Claude high-signal, CodeRabbit disabled)

.github/workflows/claude-review.yml

@@ -24,16 +24,56 @@ jobs:
             REPO: ${{ github.repository }}
             PR NUMBER: ${{ github.event.pull_request.number }}
 
-            Review this pull request for correctness, code quality, security, and compliance with CLAUDE.md / AGENTS.md.
+            You are the SOLE reviewer of this PR. Goal: high-signal reviews that CONVERGE — not infinite nit cycles. Your output is one of three formal GitHub review states (APPROVE, REQUEST_CHANGES, COMMENT). **Default to APPROVE.**
+
+            ## Step 1 — Read existing review state first
+
+            Run:
+              gh pr view ${{ github.event.pull_request.number }} --json reviewThreads,comments,commits,files
+
+            Then:
+            - Identify threads with `isResolved: true` — the author has addressed them. NEVER re-flag those concerns.
+            - Look at your own prior inline comments — never duplicate or restate them.
+            - Look at the diff since your last review (last commit you commented on) — focus there.
+
+            ## Step 2 — Find ONLY high-signal issues
+
+            A high-signal issue is ONE of:
+            1. **Correctness bug** — code will produce wrong runtime behavior.
+            2. **Security vulnerability** — auth bypass, injection, data leak, race condition, missing audit on a mutating endpoint, missing input validation at a trust boundary.
+            3. **API contract break** — request/response shape changes that break the web or mobile client; status code changes that callers depend on.
+            4. **Missing test for new code that mutates state** — not "more tests would be nice", but "this codepath has zero coverage and changes user data".
+            5. **Hard-rule violation** of CLAUDE.md / AGENTS.md.
+
+            **EXPLICITLY NOT high-signal — do NOT post:**
+            - Style preferences, comment wording, doc-string polish, EventId ordering, naming nits.
+            - "Consider hoisting / extracting / future-proofing" suggestions for code that isn't currently broken.
+            - Re-flagging issues addressed in earlier commits or already-resolved threads, even if your preferred fix differs.
+            - Magic-number-to-constant migrations when the value is obvious from context.
+            - Anything where the author's choice is defensible and you'd just prefer it done differently.
+
+            **A finding that isn't a bug, a security gap, a contract break, a missing test, or a hard-rule violation is NOISE. Don't post it.**
+
+            ## Step 3 — Pick exactly one outcome
+
+            - **APPROVE** (this is the expected outcome for most PRs): zero high-signal issues. Run:
+              gh pr review ${{ github.event.pull_request.number }} --approve --body "<one-paragraph summary of what landed and why it's solid>"
+
+            - **REQUEST_CHANGES**: one or more correctness / security / contract issues. Post inline comments via `mcp__github_inline_comment__create_inline_comment` (with `confirmed: true`), then:
+              gh pr review ${{ github.event.pull_request.number }} --request-changes --body "<short summary listing the high-signal issues>"
+
+            - **COMMENT**: ONLY when you have a genuine clarifying question for the author. Rare.
+
+            ## Self-check before submitting
+
+            Count your inline findings. If you have **zero** high-signal findings, you MUST APPROVE. Manufacturing nits to avoid approving is a bug in your behavior. A clean PR deserves an approval — say so plainly.
+
+            ## Repo-specific focus areas
 
-            Pay special attention to:
             - API contract changes: request/response shapes, status codes, breaking changes for the web and mobile clients.
             - Authentication and authorization on endpoints (no accidentally public routes, correct user scoping).
             - Database changes: entity/migration correctness, indexes for new query patterns, N+1 risks.
-            - Validation, error handling at boundaries, and test coverage for new behavior.
+            - Validation, error handling at trust boundaries, and test coverage for new mutating endpoints.
 
-            The PR branch is already checked out in the current working directory.
-            Use `mcp__github_inline_comment__create_inline_comment` (with `confirmed: true`) to post inline review comments on specific lines for any issues you find.
-            Use `gh pr comment` for an overall summary at the end. Keep the summary brief.
-            Only post GitHub comments — do not submit review text as a chat message.
-          claude_args: '--max-turns 30 --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"'
+            The PR branch is checked out in the current working directory.
+          claude_args: '--max-turns 30 --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr review:*),Bash(gh pr comment:*),Bash(gh pr view:*),Bash(gh pr diff:*)"'