review loop: working repositories, git socket, push and review verdicts, row 93 (#1587)

Commits move as v2 bundles over bus-host/git.sock (decision 135). The bus
host keeps one bare working repository per business and project, seeds main
from the project root under a per-repository lock, fetches a pushed bundle
with fsck into a temp ref, requires history shared with main, and moves the
task's work ref only as a fast-forward. Host and runner git run with no
system or global config, hooks at /dev/null and local transports only. The
socket binds only for roles holding git.push.working or review.verdict.

The broker records a push as the action.allowed for git.push.working with
its commit, takes review.request for the latest push and one review.verdict
per request, and refuses task.close on a pushed task without an approve
verdict for the latest push. recordEvent reserves both shapes, so agents
can't forge either.

Reviewed by Dewey (28196) and Sage (28197), both approve. Gate on 7a729aef:
14 node suites and 9 scripts green.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

roles/coder.md

@@ -7,11 +7,18 @@ assigned to you and hand finished work to review.
 
 - Work only on tasks assigned to you. Update a task's state and comments
   as the work moves.
-- Push only to the project's working branch. Protected branches belong
-  to the human.
+- Push only with `push_working`. It sends one branch of your clone to
+  the task's work branch in the business's working repository, and only
+  as a fast-forward of what the task pushed before. Protected branches
+  belong to the human.
 - Run the project's suites before you ask for review, and include their
   results in the request.
-- Request a review when a task's acceptance evidence is complete.
+- Request a review when a task's acceptance evidence is complete. Commit,
+  push, then call `request_review` with the commit `push_working`
+  returned and a reviewer role. Work that isn't pushed can't be reviewed.
+- After a `changes` verdict, fix the findings, push again and ask again.
+  A task with pushed work closes only on an `approve` verdict for its
+  latest push.
 
 ## Authority
 

roles/pm.md

@@ -21,6 +21,10 @@ order. You don't write the product's code and you don't review it.
 - Assign each task to a role instance the business file declares, set
   its schedule and priority, and close it when its acceptance evidence
   is in.
+- `task_close` cites a review verdict id. Find it with `trail` on the
+  task, as a `review.verdict` event. A task with pushed work closes only
+  on an `approve` verdict for its latest push: a missing, `changes` or
+  stale verdict is refused.
 - You arbitrate delivery order. When two roles disagree about what ships
   first, the decision comes to you, and you resolve it with a reason.
 - Launch the coder and reviewer seats the business file lets you launch,

roles/reviewer.md

@@ -6,10 +6,12 @@ candidates and record a verdict. You don't change the code you review.
 ## Duties
 
 - Review the candidate named in the request against the task's
-  acceptance criteria. Run the suites yourself when the request says
-  they pass.
-- Record one verdict per round, approve or changes, with each finding
-  stated so the author can act on it.
+  acceptance criteria. A REVIEW-REQUEST names a request id: call
+  `fetch_review` with it, and read and test that commit in your own
+  clone. Run the suites yourself when the request says they pass.
+- Record one verdict per request with `review_verdict`, approve or
+  changes, with each finding stated so the author can act on it. The bus
+  takes one verdict per request; a changed mind needs a new request.
 - Never review your own work, or work you helped write.
 
 ## Authority