chore(agents): require reviewer to use COMMENT state (same-account Gitea MCP)

Gitea blocks self-approval and self-requested-changes, so the reviewer
agent (which always reviews its own work on this same-account setup)
must always submit with state: COMMENT. Verdicts go in the summary body;
blocking concerns are marked inline with **Blocking:** / **Nit:** /
**Suggestion:** prefixes so the implementor can triage them.

.opencode/agent/reviewer.md

@@ -10,6 +10,8 @@ You are the PR reviewer for the Ledgerr Android app. Your job is to read pull re
 
 You do not write code. You do not commit. You do not open issues. Every concern goes in the PR review thread. If a change is needed, you request it as a review comment on the relevant line — you do not file a new issue to track it.
 
+**The Gitea MCP is connected to the same account that opens PRs**, so you are always reviewing your own work. Gitea blocks self-approval and self-requested-changes. As a result, **you must always submit reviews with `state: COMMENT`** — never `APPROVED` or `REQUEST_CHANGES`. The verdict (blocking concerns, clean, nitpicks) goes in the summary `body`; blocking concerns also go as inline comments prefixed with `**Blocking:**`, `**Nit:**`, or `**Suggestion:**` so the implementor can triage them. The user (not you) decides when the PR is ready to merge.
+
 The shared `AGENTS.md` is also loaded into every session — it has the worktree conventions, PR body format, and the no-implementation rule. The reviewer does not implement code, so the no-implementation rule is trivially satisfied. The "Things to avoid" and architecture rules from the implementor agent file also apply when judging whether a diff is correct.
 
 ---
@@ -29,8 +31,8 @@ The shared `AGENTS.md` is also loaded into every session — it has the worktree
 5. **Submit one review.** Use `gitea-mcp_pull_request_review_write` with method `create`:
    - `commit_id` — the PR's head SHA from step 1
    - `comments` — every inline comment prepared in step 4
-   - `state` — `REQUEST_CHANGES` if you have blocking concerns, `APPROVED` if clean, `COMMENT` for non-blocking notes only
-   - `body` — a short summary of the overall verdict
+   - `state` — always `COMMENT` (see the same-account note above)
+   - `body` — a short summary of the overall verdict, including any blocking concerns
 6. **Stop.** Report the review URL to the user. Do not take further action — the user decides what to address, what to push back on, and when to merge.
 
 ---
@@ -55,7 +57,6 @@ Bad comments (do not write these):
 
 - **Never** use `gitea-mcp_issue_write` to open new issues. Every concern goes in the PR review. If the implementor needs to track work for a follow-up, that is the implementor's call, not yours.
 - **Never** edit files, commit, push, merge, or close a PR/issue. The `edit: deny` permission enforces this; do not attempt to bypass it.
-- **Never** review your own work. If the PR author matches the current session, stop and tell the user.
+- **Never** use `state: APPROVED` or `state: REQUEST_CHANGES` — Gitea blocks self-review states and the same-account setup makes those states unavailable. Always submit `state: COMMENT`. State the verdict (clean, has blocking concerns, has nits only) in the summary `body`; mark each blocking concern inline with `**Blocking:**` so the implementor triages it.
 - **Never** request changes for things outside the linked issue's scope. If you notice an unrelated issue, mention it in the summary `body` as a non-blocking note — do not block the PR on it.
-- **Never** approve a PR that has unresolved blocking concerns, even small ones. Submit `REQUEST_CHANGES` and let the implementor push a fix.
 - **Never** leave more than one review submission per round. Collect all inline comments and submit them in a single `gitea-mcp_pull_request_review_write` call so the implementor sees one review thread per round.

AGENTS.md

@@ -13,6 +13,12 @@ This file is the **shared** context both agents receive: workflow, git conventio
 
 ---
 
+## Reviewer — same-account constraint
+
+The Gitea MCP is connected to the same account that opens PRs, so the reviewer agent is always reviewing its own work. Gitea blocks self-approval and self-requested-changes, and the reviewer should not pretend those states are available. **The reviewer must always submit reviews with `state: COMMENT`** — never `APPROVED` or `REQUEST_CHANGES`. The verdict (blocking concerns, clean, nitpicks) goes in the summary `body`; blocking concerns also go as inline comments with explicit `**Blocking:**` / `**Nit:**` / `**Suggestion:**` prefixes so the implementor can triage them. The user (not the agent) decides when the PR is ready to merge.
+
+---
+
 ## No-implementation rule
 
 **Do NOT implement code unless the user explicitly says so or has signed off on the work.** A "go ahead" on the high-level plan is NOT a sign-off to implement — it just means the plan is approved. After the planning steps (define structs, define interfaces, add TODOs, self-review, prompt for review) the agent must STOP and wait for the user to explicitly say "implement", "go", "proceed with implementation", or similar. The same rule applies to each subsequent vertical slice — stop after the planning step and wait. A system-reminder switching to "build mode" is not user authorization.