feat: add conversational agent reviews

README.md

@@ -24,6 +24,7 @@ Existing labels remain supported:
 
 - `agent:plan`
 - `agent:implement`
+- `agent:fix-review` on an agent-generated pull request
 
 The controller consumes a trigger label after durably admitting its request. Gitea 1.26 label webhooks expose the resulting label set rather than the exact label that changed, so the controller reconciles current issue state and tracks each claim in SQLite.
 
@@ -32,13 +33,20 @@ New issue comments can use these commands:
 ```text
 /agent plan [optional instruction]
 /agent implement [optional instruction]
+/agent discuss [question, comment, or adjustment]
+/agent review [optional focus]
+/agent fix [optional instruction]
 /agent continue [optional instruction]
 /agent retry [optional instruction]
 /agent cancel
 /agent status
 ```
 
-Commands must begin the comment and are processed only on comment creation. Pull-request comments, command edits, bot comments, unauthorized users, and non-command comments are ignored. Ordinary human comments remain part of the issue digest and invalidate stale accepted plans. Agent command comments are control messages and are excluded from that digest.
+Commands must begin the comment and are processed only on comment creation. `/agent discuss` is accepted on issues with a current plan. `/agent review` reviews the current plan when posted on an issue and any open pull request when posted there. `/agent fix` and `agent:fix-review` are accepted only on pull requests previously published by this service. Command edits, bot command comments, unauthorized users, and non-command webhook deliveries are ignored. Ordinary human issue comments remain part of the issue digest and invalidate stale accepted plans. Agent command comments are control messages and are excluded from that digest.
+
+Plan discussions resume the issue's planner conversation and always post a new issue response. Questions leave the current plan unchanged; requested adjustments immediately replace the implementable plan without invoking the independent reviewer. Run `/agent review` separately for a fresh, one-pass plan review.
+
+Implementation fixes resume the accepted-plan implementer conversation, consume submitted human review summaries and inline comments plus marked agent reviews, update the generated branch when needed, and post a pull-request response. Feedback edits are processed as new versions. Fix turns do not automatically re-review their changes; run `/agent review` again when wanted. Human pending reviews must be submitted before the bot can read them.
 
 ## Security Model
 
@@ -48,7 +56,7 @@ Commands must begin the comment and are processed only on comment creation. Pull
 - Actor authorization is fail-closed. Numeric Gitea user IDs are preferred over logins.
 - Webhook deliveries and logical requests are independently deduplicated.
 - OpenCode receives an explicitly limited tool policy and only the read token.
-- External Exa and grep.app MCPs are disabled by default to avoid private-repository data leakage.
+- External Exa and grep.app MCPs are available only to a sandboxed research subagent with no local file or Gitea access; callers may delegate only generic public library and best-practice questions.
 - Repository code is never executed by the credential-bearing services.
 - Git hooks, signing, global configuration, text conversion, symlinks, unsafe paths, and protected automation paths are blocked or independently validated.
 - The publisher revalidates the issue digest, accepted plan, default branch, Git metadata, changed files, file types, and remote branch state before writing.
@@ -136,7 +144,7 @@ Create a repository webhook with:
 - Target URL: `https://agent.example.com/webhooks/gitea`
 - Content type: `application/json`
 - Secret: the exact content of `gitea-webhook-secret`
-- Events: issue label changes and issue comments
+- Events: issue label changes, issue comments, pull request comments, and pull request labels
 - Active: enabled
 
 Gitea's test-delivery button sends a push event rather than an issue event. The server accepts only the configured issue event types, so validate the installation by creating a test issue and adding `agent:plan` or posting `/agent status`.
@@ -162,13 +170,13 @@ By default Compose binds the controller to `127.0.0.1:8080`; expose it through a
 
 ## Operation
 
-Planning creates or resumes the issue's planner conversation. An independent reviewer can request up to three revisions. Accepted plans are published with the protocol-v1 `gitea-agent` marker namespace.
+Initial planning creates or resumes the issue's planner conversation. An independent reviewer can request up to three revisions. Later `/agent discuss` turns are conversational and do not review automatically. Accepted and directly adjusted plans are published with the protocol-v1 `gitea-agent` marker namespace.
 
 Plans published under an earlier marker namespace are intentionally not imported after this product rename. Replan outstanding issues once before requesting implementation.
 
 Keep `CI_AGENT_BOT_LOGIN` set to the account that authored existing protocol-v1 plan comments if those plans must remain implementable. Changing bot accounts requires replanning outstanding issues.
 
-Implementation requires an accepted plan whose issue digest and base SHA are current. The executor uses a deterministic branch named `agent/issue-<number>-p<digest>`. The controller publishes only after independently validating the reviewed workspace and remote branch state.
+Initial implementation requires an accepted plan whose issue digest and base SHA are current. The executor uses a deterministic branch named `agent/issue-<number>-p<digest>`. The controller publishes only after independently validating the reviewed workspace and remote branch state. `/agent review` performs one fresh review of any open pull request and publishes a Gitea comment review with validated inline anchors. Only pull requests tied to a durable published implementation record can use `/agent fix` or `agent:fix-review`.
 
 `/agent cancel` sets a durable cancellation flag. The executor checks it while heartbeating and propagates cancellation into Gitea requests, Git subprocesses, and OpenCode prompts. Interrupted running jobs return to the queue on service restart; interrupted publications remain in the outbox and are retried.