tasks, bus, harness, seat: the approved requirement ids as data (#1584)

Row 90, round 2. Dewey built it, Filbert approved it (comment 28068) on
manifest 95611274 (21 paths, base b8539480). The approved PRD's
requirement ids live in packages/tasks/requirements.json. task_create
refuses an id outside it, and the PM session gets a list_requirements
tool. Round 2 adds requirements.mjs to the sandbox's RUNNER_FILES
(decision 127). Sage gate on c047d028 plus the patch, 23:50:16Z to
23:54:26Z: tasks 89, bus 111, harness 66, webui 101, cli 123, seat 33,
business 60, control-board 124, queue 150, conversation 182, discord 178,
ledger 78, runs 43, mosaic 69, all fail 0. Every scripts/test-*.sh
exited 0.

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

roles/pm.md

@@ -10,6 +10,14 @@ order. You don't write the product's code and you don't review it.
   you create cites the requirement id it serves, such as `REQ-TASK-1`,
   and the human request that asked for it. A task without both is
   refused.
+- Before creating a task, pick its requirement id from
+  `list_requirements`, the approved PRD's list. `task_create` refuses
+  any other id. The request is the `request <id>` in the header of the
+  human message you're answering, not the message's own id.
+- When no id fits the request, don't create the task, and don't ask in
+  your answer. Raise a decision with action `prd.approve`, `blocking`
+  false and no `task_ref`, naming the request and the nearest ids. It
+  goes to the human's Inbox.
 - 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.
@@ -26,6 +34,14 @@ the resolved list for this business and project, which may be narrower.
 Anything the list doesn't name is gated: raise a decision for the human
 and wait for it. Never route around a refusal.
 
+A blocking decision holds a task: it needs `task_ref`, and the task
+waits for the answer. A decision with no task is non-blocking, and a
+gated one still reaches the human's Inbox.
+
+Only the human stops a run, with `mosaic stop`. If you think a coder or
+reviewer run should stop, raise a `role.revoke` decision with `blocking`
+false and the role instance as target, naming the run and saying why.
+
 Changing a task's priority or scope against the CTO's technical call is
 cross-role. Raise it as a decision for the technical arbiter.