M7.4: nisse-dev answers a peer

Anyone's comment on an item's PR but an operator's (and its own) is a
peer's point (D5, L11): kept on the item with an id, in the transcript as
a `peer` message labelled with its author, and never an instruction. The
driver answers each with answer_peer, inline on its line or quoting it,
or skips it with skip_peer and a recorded reason. A run going back to
waiting with points open is reminded once; then the harness lists them
on the PR. A peer's comment wakes the item; a wake by peers alone goes
back to the same wait quietly, with one line in the thread. The
operator's inline comments are now answered inline too.

Also corrects ci.yml's header: a push to main runs no end-to-end tests.

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

docs/Architecture.md

@@ -521,8 +521,9 @@ 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.
+  Anyone else's comments are a peer's (R4), whoever wrote them: another agent,
+  a person, a bot. They are weighed on their merits, labelled with their
+  author, and 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
@@ -778,14 +779,26 @@ recovers a VM for now; `nisse-ops` later (O5).
 ### D5. Review and merge
 
 - **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.
+  agent answers with commits to the same PR, replying where the comment was made:
+  on the same line for an inline comment (quoted instead when Gitea won't place
+  it there). Intake is as in L8.
+- **Anyone else's comments are a peer's** (`nisse-review`, Part R, or any other
+  account; its own are skipped): constructive criticism, not instruction. Each
+  comment, review body or inline comment is a **point** with an id, kept on the
+  item and labelled with its author. The agent answers every point where it was
+  made, 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
+  point that needs no reply (an automated notice) is skipped with a reason, which
+  is recorded and said in the item's thread. The harness holds this, not the
+  model: a run that would go back to waiting with points open is reminded once,
+  then the harness lists the unanswered ones on the PR. Points still open when the
+  PR merges or closes are dropped, with a fact saying so.
+- **A peer's comment wakes the item** like an operator's, but going back to
+  waiting afterwards says nothing to the operator beyond one line in the thread
+  (what was answered and skipped). 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.
@@ -921,7 +934,7 @@ Two agents can argue forever, so a PR's exchanges are capped.
 ### 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.
+  each point (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

docs/Development-Plan.md

@@ -632,8 +632,22 @@ waits until two exist to compare. Moved, unchanged in behaviour:
   (`test_review_live.py`, `NISSE_REVIEW_GITEA_TOKEN`) has the local model
   review a PR in a fresh test repository.
 
-**M7.4 `nisse-dev` answers a peer.** *Pre-approved.* Peer comments labelled as a
-peer's, answered point by point with a change or a reason (D5, R4).
+**M7.4 `nisse-dev` answers a peer.** *Done.* Anyone's comment but an operator's
+is a peer's point (D5, L11), not only `nisse-review`'s: settled with the operator,
+since only accounts they made can log in to Gitea, with the model deciding whether
+a bot's comment needs a reply.
+- Each top-level comment, review body and inline comment is a point (P1, P2, …)
+  on the item, in the transcript as a `peer` message labelled with its author
+  (`nisse_core.log.views`). Its own comments are skipped.
+- `answer_peer` answers where the point was made: inline on its line, or quoting
+  it. `skip_peer` records why no reply is needed. The thread gets one line per
+  run on what was answered and skipped.
+- A run going back to waiting with points open is reminded once; then the harness
+  lists them on the PR. A merge or close drops the rest, with a fact.
+- A peer's comment wakes the item; a wake by peers alone returns to the same wait
+  without a note to the operator. The operator's inline comments are now answered
+  inline too.
+- **Tests:** `test_loop_peers.py` over the fake Gitea.
 
 **M7.5 Discussion and rounds.** *Pre-approved.* Later reviews of what changed and
 of earlier points, replies on threads, the round cap and its reset, `stop` and