plans: row 149 carries Dewey's row 139 finding 1, the raise_decision domain parameter (#1643)

The harness raise_decision tool has no domain parameter, so no agent
reaches arbiters.technical and merge-gate's technical raise can't be
made. Row 149 now owns that tool (not end_run, which stays row 155's),
plus the pm and chief Authority text that still sends every ungranted
action to the human. Mos accepted the carry on 2026-10-16.

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

docs/plans/2026-10-15_q167-rows-r3.md

@@ -155,6 +155,8 @@ agents are proactive, and no role contract says so.
 - every `roles/*.md`, one proactive line each
 - `packages/business/` where definitions are known or validated, if a new
   definition must be declared there
+- `packages/harness/src/tools.mjs`, the `raise_decision` tool only. The
+  `end_run` text in the same file stays row 155's.
 - tests and READMEs
 
 ### What ships
@@ -179,6 +181,22 @@ agents are proactive, and no role contract says so.
 - Every role contract gets one line: within your grants, act on what you
   see without waiting to be asked, and raise a decision or send a message
   for anything outside them.
+- The harness `raise_decision` tool gets an optional `domain` parameter,
+  `technical` or `delivery`, passed through to `decision.raise`. Leaving it
+  out keeps the broker's default, `delivery`. Today the tool has no such
+  parameter (`packages/harness/src/tools.mjs:203-216`), so no agent can
+  reach `arbiters.technical`, and merge-gate's `technical` raise above
+  can't be made. Its description also says that a cross-role raise, or a
+  gated raise with a current spec citation, goes to the arbiter for its
+  domain. This is Dewey's row 139 finding 1 (Follow-ups in
+  `agents/dewey/work/queue-139/BUILD.md`). Mos accepted it for this row on
+  2026-10-16.
+- The Authority text in `roles/pm.md` and `roles/chief-of-staff.md` says
+  anything ungranted is gated and goes to the human. Since PRD 1.5
+  REQ-DEC-2 (row 139), a cross-role raise and a gated raise with a current
+  spec citation go to the domain's arbiter, and only an uncited gated raise
+  or a hard wait goes to the human. Both texts say that, next to the
+  proactive line. This is also from Dewey's row 139 Follow-ups.
 - Instances of the new roles are added through chief's organization
   change verb (row 132), never by editing Jason's business file. Adding
   them to the mosaic-stack business is a live step after the re-pin, with
@@ -188,12 +206,16 @@ agents are proactive, and no role contract says so.
   git.merge.protected cross-role; a merge-gate raise with domain
   `technical` routes to `arbiters.technical` and is accepted; a business
   whose arbiter is merge-gate is refused, or a test pins what happens; a
-  contract test that finds the proactive line in every `roles/*.md`.
+  contract test that finds the proactive line in every `roles/*.md`; a
+  harness test that `raise_decision` accepts `domain`, rejects any other
+  value in its schema, and forwards it, and that a call without it sends
+  no `domain`.
 
 ### Out of scope
 
-The land op itself (row 137). GATED_ONLY and routing (row 139). Adding
-instances to any business.
+The land op itself (row 137). GATED_ONLY and routing (row 139). The
+`end_run` tool text and the assistant's revoke (row 155). Adding instances
+to any business.
 
 ### Gate