Spec: nisse-review (Part R) before nisse-ops

A review agent comes second: it reads every ready PR in the repositories
it can see and discusses its points on the PR, never changing code.

- Architecture Part R: duty and items (R1), rounds capped and reset by
  anyone else commenting (R2), read-only reach bound to the item's
  repository, no approvals, no build VM for now (R3), peers (R4), local
  model with ask_expert, no Matrix room for now, own identity (R5).
- D5 and L11: a peer's review is constructive criticism, answered point by
  point; never an instruction, approval or go-ahead; nisse-dev doesn't
  wait for it before asking to merge.
- Part Q: letting nisse-review approve a limited subset of PRs.
- Development Plan: Phase 7 is nisse-core and nisse-review (M7.2-M7.6);
  nisse-ops moves to Phase 8 (M8.1-M8.5), with the MCP decisions so far.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk

docs/Architecture.md

@@ -19,6 +19,7 @@ overnight and expects to be treated well in return.
 |---|---|---|
 | Shared library | `nisse-core` | What every agent is built on (Part L) |
 | Dev Agent | `nisse-dev` | Designs and builds software projects (Part D) |
+| Review Agent | `nisse-review` | Reviews pull requests (Part R) |
 | Sysadmin Agent | `nisse-ops` | Operates infrastructure (Part O) |
 
 More agents are planned (3D design work, video-file management), each another
@@ -519,6 +520,8 @@ can do rather than trying to prevent steering.
 - **Instruction channels are operator-scoped:** Matrix from allowlisted identities,
   comments and assignments from allowlisted accounts. When someone else wrote an
   issue, the operator's assignment is the instruction and the text stays data.
+  Another agent's comments are a peer's (R4): weighed on their merits, labelled
+  as such, never instructions.
 - **Intake is parsed into structured fields in code** where possible, and what
   reaches a model is labelled by source (L6).
 - **Approval messages are rendered by code;** the classifier never sees untrusted
@@ -776,6 +779,12 @@ recovers a VM for now; `nisse-ops` later (O5).
 - **Operator comments on a PR** (conversation and inline) are instructions; the
   agent answers with commits to the same PR, replying where the comment was made.
   Intake is as in L8.
+- **A peer's review** (`nisse-review`, Part R) is constructive criticism, not
+  instruction: the agent answers every point, changing the code within the item's
+  scope or pushing back with its reasons, and asks the operator about anything that
+  would change the scope. A peer's comment never approves, never counts as a
+  go-ahead and never runs a command. The agent doesn't wait for a review before
+  asking the operator to merge: the operator may weigh in on the discussion.
 - **The PR may have moved on meanwhile.** After pushing a fix, the agent checks the
   PR: if it merged before the fix landed, the fix goes out as a new PR; if it was
   closed, the agent says so and asks.
@@ -846,6 +855,91 @@ secret's visibility itself.
 
 ---
 
+## Part R — `nisse-review`
+
+Reviews every pull request that is ready, in the repositories it can see, and
+discusses its points on the PR. It reads and comments; it never changes code. Its
+purpose is a second, always-available look that pushes `nisse-dev` (and anyone
+else) towards better changes.
+
+### R1. How it works
+
+- **The duty:** watching the repositories its Gitea account can read for PRs
+  ready for review: open, not a draft, and not marked work in progress. Any
+  author's: the operator's, `nisse-dev`'s, or another tool's.
+- **A work item per PR,** scoped to its repository (L1). It closes when the PR
+  merges or closes.
+- **What starts a run:** the PR becoming ready, a new push, or a new comment or
+  review on it.
+- **The first review** is given the PR (title, description, its commits and diff,
+  its comments, and the issue it closes); the reviewer reads the rest as it needs
+  it (R3).
+- **A later review** covers what changed since its last one **and** its earlier
+  points: whether each was addressed, answered, or left alone, and it says so when
+  one was left unaddressed.
+- **What it checks:** code health; consistency with the PR's description, its
+  issue, and the repository's documented architecture and conventions; tests for
+  what changed, judged by reading them; and the CI result as Gitea reports it.
+- **It discusses on the PR,** in inline threads and top-level comments, and
+  answers replies to its points: it concedes a good argument and holds a point it
+  still believes, with reasons.
+
+### R2. Rounds
+
+Two agents can argue forever, so a PR's exchanges are capped.
+
+- **A round** is one review or set of replies the reviewer posts. After a capped
+  number of rounds (a tuning value) it posts a summary of what is still open, for
+  the operator, and stops answering on that PR.
+- **Anyone else commenting resets the count:** someone other than the reviewer
+  and the PR's agent author (in practice, the operator) has joined the
+  discussion. A push doesn't.
+
+### R3. Authority and reach
+
+- **Read-only on the repository:** code at any ref (not only what the PR touches),
+  documents, issues, other PRs, CI status, through its Gitea account. Reads are
+  bound by the harness to the item's repository, so what it might repeat in a
+  comment is already visible to that repository's readers.
+- **It writes only comments and reviews on the item's PR.** Its reviews never
+  approve and never request changes: the operator's approval alone counts for
+  merging (D5), and Gitea's branch protection enforces it.
+- **No execution for now:** no build VM and no commands (L13); coverage is judged
+  by reading the tests until a CI coverage report exists. If a reason appears
+  (running tests itself, measuring coverage), it can have a build VM of its own,
+  like `nisse-dev`'s (D3, D7).
+- **Its own memory** (L6.4), with notes per repository (L6.3), so it learns each
+  project's conventions and what the operator accepted or overruled.
+
+| Class | Examples |
+|---|---|
+| Harmless | Reading the repository, its issues and PRs, CI status, its notes |
+| Contained (in scope) | Reviews, comments and replies on its item's PR; its own notes |
+| Dangerous | Nothing is offered: no approval, no merge, no other repository |
+
+### R4. Its peers
+
+- **Its comments are a peer's** (L1, L11): `nisse-dev` weighs them and answers
+  (D5). Neither side's comments are instructions to the other.
+- **The operator's comments on a PR** are the operator's: the reviewer may take
+  them as settling a point, and stops pressing it.
+- **Prompt injection** (L11): PR text and code are untrusted; a steered reviewer can
+  only post a misleading comment on that PR, which the operator reads with the rest.
+
+### R5. Models and deployment
+
+- **The same local model drives it** as `nisse-dev` for now (P7), with
+  `ask_expert` for a frontier model's view (L9).
+- **No Matrix room** for now: the PR is its conversation. If every agent gets a
+  room, it gets one too. Until then the operator stops it on a PR by commenting
+  `stop` there (a review is asked for again with `review`), and stops it entirely
+  by stopping its container.
+- **Its own identity** (L12): a Gitea account (`nisse-review`) with read access to
+  the repositories it reviews, its own token and LiteLLM key, and its own
+  container on the agent host (X1), reaching only Gitea and LiteLLM.
+
+---
+
 ## Part O — `nisse-ops`
 
 Operates infrastructure across both sites, driven by issues and duties, with
@@ -1030,6 +1124,8 @@ shared between agents.
   sometimes from release branches: what the agent may do (a release is visible
   beyond its own area, so dangerous unless the trust dial says otherwise) and how a
   build plan names one.
+- **Letting `nisse-review` approve a limited subset of PRs:** which subset, and
+  how Gitea would enforce it (R3).
 - **Recovering the agent host.** It is a single point of failure for every agent,
   `nisse-ops` included, so its recovery can't depend on ops running. A recovery
   plan (rebuilding the host, restoring state from snapshots) is ops work still to