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