feat: PM-Agent also need to look at PR comments

From Gitea issue #116.

Authored by the PM agent's worker; the merge gate is the approver. Refs #116.

Agent: pm-agent (issue #116, mode implement)

platform/pm-agent/README.md

@@ -5,9 +5,11 @@ A service that runs in the cluster, reads the issues of
 Manager persona this repository already works under**, and runs one worker agent per
 assignment that authors the change, runs the merge gate and opens a pull request.
 
-It reacts to issue creation and to comments on issues. Every assignment and every piece of
-correspondence travels through the issue thread and the pull request, so the whole record of
-what the agent did, and why, is in the same place a human is already looking.
+It reacts to issue creation and to comments on issues. It can also — **off by default** —
+reply when it is `@`-mentioned on a pull request; see
+[Mentions on a pull request](#mentions-on-a-pull-request). Every assignment and every piece
+of correspondence travels through the issue thread and the pull request, so the whole record
+of what the agent did, and why, is in the same place a human is already looking.
 
 It **never pushes to `main`** and **never merges a pull request**. The merge gate remains the
 approver, and a sensitive-path change still needs the human review `ci/approval-policy.sh`
@@ -159,6 +161,111 @@ Job from a committed template. **The model's output is data, never a command.**
 
 ---
 
+## Mentions on a pull request
+
+**Off by default** (`PM_PR_MENTIONS: "false"`), and nothing below has been exercised against
+the live Gitea — see `decisions/2026-11-07-pm-agent-pr-mentions.md`.
+
+With it on, the dispatcher runs a second, independent pass each poll. A mention of the bot
+account on a **pull request** makes the PM read that pull request — its description, its
+changed files, its diff, the thread it was mentioned in and the rest of the conversation —
+and **reply in that same thread**. Both places count: the pull request's conversation, and
+inline review threads against a file and a line.
+
+```
+  @pm-agent in a PR comment ─▶ discover (notifications, else open PRs)
+  or an inline review thread    │
+                                ├─▶ read /issues/{n}/comments, /pulls/{n}/reviews,
+                                │        .../reviews/{id}/comments
+                                ├─▶ decide: self-authored? already answered? mentioned,
+                                │        or a follow-up in an already-mentioned thread?
+                                ├─▶ assemble the PR + diff + thread, every field fenced
+                                │        and labelled UNTRUSTED
+                                ├─▶ ask the model: `comment` or `decline`, and nothing else
+                                └─▶ post the reply in that thread, carrying its own marker
+```
+
+**It can only reply.** `implement` and `revise` are not in the vocabulary this path offers
+the model, and the decision schema has no `branch` and no `brief` field, so the PM cannot
+ask for work in a shape this program would accept. Nothing on the path calls `build_job()`.
+The change-authoring half of issue #116 — revise a branch an agent owns, versus open a fresh
+branch and PR against `main` for somebody else's — is a separate issue and a separate PR.
+
+**"The same thread."** Inline review comments have a thread identity in Gitea (comments on
+the same file and diff position are one conversation). Pull-request conversation comments do
+not — they are a flat list — so the issue path's existing convention is reused: the
+conversation is **one** thread, and from the first mention in a thread onward, every later
+non-bot comment in it continues the conversation without a new mention. A comment made
+*before* the mention is not pulled in, and continuation is per thread, not per pull request.
+That is a policy choice, not a Gitea fact; it is flagged on issue #116.
+
+**Loop prevention.** There is no author gate — anyone who can comment can start a run, which
+is the operator's decision (issue #116, answer 3: *"anyone can talk and have the agent work.
+Authorization of changes is through the CI pipeline"*). That makes the self-authored filter
+load-bearing, so it is the first check made on every comment and it is structural: a
+bot-authored comment can only ever *clear* work, never create it, even if it contains the
+bot's own handle. The reply the PM posts also never contains `@`-the-bot. Both are asserted
+by the selftest.
+
+**Idempotency.** The record that a mention has been answered is a marker inside the reply:
+
+```
+<!-- pm-agent:replied-to=comment-9001,review-comment-77 -->
+```
+
+One atomic write with the reply, so the two cannot get out of step. The failure mode chosen,
+deliberately, is **at-least-once model call, at-most-once reply**: a crash before posting
+costs one repeated decision, a crash after posting is a no-op because the marker is already
+in the thread, and a mention is never silently dropped. The marker is only believed in the
+bot's *own* comments — pasting it into yours does not silence a mention.
+
+### The cheap mention query, and the token scope it needs
+
+The operator asked for "a way to check for '@'s for the bot account instead of scouring the
+entire pull request list and associated threads". That is Gitea's notification list: a
+mention subscribes the mentioned account to the thread, and the subscription then raises a
+notification for **every later comment on it** — which answers discovery and thread
+continuation with one bounded call.
+
+**It will be refused on today's token.** `/api/v1/notifications` sits behind Gitea's
+`notification` scope category, and the bot's token is minted
+`read:user, write:repository, write:issue, read:package` (above). The dispatcher handles that
+explicitly: it logs the refusal, names `read:notification` as the remedy, and falls back to
+listing open pull requests, which needs only `read:repository`. Which query answered is in
+the log every cycle. To get the cheap one, re-mint the token with `read:notification` added —
+same account, same five other scopes, both Secrets updated (`runbooks/pm-agent.md`).
+
+### Look before you turn it on
+
+`PM_PLAN: "true"` makes this path discover, assemble and **print** the exact payload it would
+send and the exact thread it would post into, without asking the model and without posting
+anything:
+
+```bash
+./infra/devcontainer/dev.sh run bash -c \
+  'kubectl --context k3s-prod -n pm-agent logs deploy/pm-agent | sed -n "/^=\{20,\}/,\$p"'
+```
+
+Setting `PM_PLAN` also enables the path, so it is one knob. `PM_DRY_RUN` implies it.
+
+To settle the API shapes by hand before enabling anything (read-only, and the bot's token is
+enough for all but the first):
+
+```bash
+T=<the pm-agent token>; G=https://gitea.home.keithjackson.dev/api/v1
+R=repos/Home-Network/home-network-k3s-impl
+curl -s -H "Authorization: token $T" "$G/notifications?all=true&subject-type=pull" | head -c 2000
+curl -s -H "Authorization: token $T" "$G/$R/pulls/116/reviews"
+curl -s -H "Authorization: token $T" "$G/$R/pulls/116/reviews/1/comments"
+curl -s -H "Authorization: token $T" "$G/$R/pulls/116/files"
+```
+
+The committed fixtures are `infra/agent/testdata/pr-mention-fixtures.json`; they are written
+to Gitea's published 1.24 shapes rather than captured from the server, and the file says so
+at the top. Replacing them with a real capture is the cheapest way to close that gap.
+
+---
+
 ## What the worker can and cannot do
 
 | | |
@@ -251,6 +358,8 @@ five that matter:
 | `PM_MAX_NEW_WORKERS_PER_CYCLE` | `1` | drains a backlog one issue at a time instead of in one stampede the first minute the credentials work |
 | `PM_PUSH_ON_RED_GATE` | `false` | a change the gate refused is not pushed; the issue gets the gate log instead |
 | `PM_DECISION_MAX_TURNS` | `1` (unset) | turns the triage call may take (1–5). The PM holds no tools, so a second turn is only ever the CLI re-asking after an answer that failed the decision schema. Raise it if a triage error logs `subtype='error_max_turns'` |
+| `PM_PR_MENTIONS` | `false` | whether a mention of the bot on a **pull request** triages it. See "Mentions on a pull request" above; read `PM_PLAN` output once before turning it on |
+| `PM_PLAN` | `false` | the pull-request path's dry run: print the payload and the intended thread, ask no model, post nothing. Also enables the path. `PM_DRY_RUN` implies it |
 
 **When a triage fails**, the `[error] issue #N: claude exited …` line carries the CLI's result
 envelope (`subtype`, `is_error`, `api_error_status`, `num_turns`, `result`) and the tails of