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.
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user