stack/agents/researcher/work/queue-140/build.md

Row 140 (#1634): the pm asks the chief of staff for staff, and the chief hires and launches

Seat: Researcher. Reviewer: Filbert. Gate owner: Sage. Brief: docs/plans/2026-10-15_q167-north-star-rows.md, the row 140 section (REQ-COS-1).

Base: dda7e31b0 (detached worktree /mnt/storage/scratch/researcher/q140b). Canonical HEAD was 276965d6d at packet time; the one commit after dda7e31b0 changes only docs and agents files (git diff --name-only dda7e31b0 276965d6d has nothing under packages/, roles/ or scripts/). I first built on df5bbfb82 (row 142 round 1). HEAD moved: rows 144 and 145 landed and changed packages/harness/src/bundle.mjs and tools.mjs, so I rebased my diff onto dda7e31b0 before any mutant or gate run. It applied with one conflict, in bundle.mjs: both sides added lines after the reviews lines (row 145's web lines, my staff line). I kept both, web lines first. row140.patch is a diff of my changes only: 11 files, +354 −5. It passes git apply --cached --check on dda7e31b0 and round-trips to the candidate tree e1dd2690111e9839038ffc6b0fbed1aac8a17736 (checked with a temp GIT_INDEX_FILE). candidate-manifest.sha256 lists the 11 files (sha256 of the manifest: df9e3fea692c6a5edf20b9fa9be3b8435ce851bba4bcffef1921688d8f34aaaf; verify with sha256sum -c run in a tree holding the candidate). Secrets scan of the patch (token shapes, PEM headers, password=): no match. No binary content. Nothing is pushed, and no live store, unit, credential or ~/.mosaic file was touched. I hold no Gitea credential; the in-review move and the review request are Sage's.

What the row does

The pm sends the chief of staff a staff request: a task and the roles it needs, with counts. The chief launches through role.launch within the organization's limits and answers by message with the instances it launched, or with the refusal and its reason.

Broker: staff.request (packages/bus/src/broker.mjs)

Args: task_ref (a task ref), roles (1 to 10 entries, each exactly {role, count}, role an identifier, count an integer 1 to 20, no role twice), optional note (up to 16384 characters), optional decision. Order of checks, in the code's order:

1. Shape: unknown or missing keys, a bad task ref, an empty or over-long role list, a bad role entry, a count outside 1..20 or not an integer, a repeated role: invalid-request.
2. Authority: it spends the caller's message.send grant (within the role, or a decision for cross-role), the same grant message.send spends. The action.allowed event names operation: staff.request, target: <chief>, staff_for: <task ref> and the roles. The field is staff_for, not task_ref, because #event refuses an action.* event carrying task_ref unless the event's subject is that task (task-subject-required); this event is filed under the chief it was sent to.
3. Sender: the caller's role definition must be pm, else staff-request-refused.
4. Recipient: the business's launcher (launch.by) must exist and be a chief-of-staff instance, else no-chief-of-staff.
5. #checkMessaging: the definitions' messaging lists apply, sender and recipient (message-recipient-refused, message-sender-refused).
6. It writes one message of class STAFF-REQUEST to the launcher through #reviewMessage (so it routes and queues like any message) and returns {message, to}.

A refused request writes nothing: the broker request runs in one transaction, so the action.allowed event of step 2 rolls back with a later refusal. I checked this directly (a coder's staff.request was refused with staff-request-refused and its action.allowed count stayed 0). review.request has the same order.

Only the pm can send one, and nothing else can forge one. message.send and thread.send keep their class lists (REQUEST, ASSIGNMENT, REVIEW-REQUEST, REVIEW-RESULT, RESULT, INFO, DECISION, REACTION and REQUEST, INFO, REACTION). STAFF-REQUEST is in neither, so invalid-class stops every other writer, the pm and the human included. No schema change: messages.class is free text and no event kind was added.

It grants nothing. The pm still holds no role.launch (roles/pm.json is unchanged and the test reads the shipped file). The chief of staff launches with the role.launch it already holds, so every limit that already applies still applies: the organization's per-model caps, the instance list in launch.instances, the host's capacity refusals, the launcher's own checks. The request adds an input to the chief's decision; it adds no launch path.

Harness

• packages/harness/src/tools.mjs: a pm-only typed tool request_staff (verb staff.request, action message.send) with the same bounds in its schema (roles minItems 1, maxItems 10, items {role, count integer 1..20}).
• packages/harness/src/bundle.mjs: one prompt line for a session that has the tool: it doesn't launch sessions; request_staff names the task and each role with how many; the chief of staff answers by message.
• The chief of staff reads the request as an ordinary message turn and replies with the existing message.send (class RESULT, in_reply_to); no new chief tool.

Role contracts (text only)

• roles/pm.md: the last duty bullet says the pm doesn't launch sessions and asks the chief of staff with request_staff.
• roles/chief-of-staff.md: one new bullet, "Answer a staff request": a STAFF-REQUEST from the pm names a task and roles with counts; no other role can send one; launch with launch within the same limits, one session per instance; reply with the instances launched and, for the rest, the exact refusal; a request never widens the limits. I kept my chief text to the staff request, as the brief says, because row 146 (Dewey) also edits this file.

Files

File	Change
packages/bus/src/broker.mjs	staff.request case, four constants
packages/bus/tests/staff-request.test.mjs	new, 7 tests
packages/harness/src/tools.mjs, bundle.mjs	request_staff, the prompt line
packages/harness/tests/tools.test.mjs, bundle.test.mjs	the pm tool list, a new tool test, a new prompt test
packages/cli/tests/launcher.test.mjs	one end-to-end test (below)
packages/bus/README.md, packages/harness/README.md	the verb row and the class sentence; the tool paragraph
roles/pm.md, roles/chief-of-staff.md	contract text only

Tests

• staff-request.test.mjs (7): pm to chief delivery and the chief's reply; only pm (coder and chief get staff-request-refused; message.send and thread.send with the class get invalid-class from coder, chief, pm and human; the human's staff.request gets agent-required; the reader read-only; the tester tester-refused; the chief receives nothing); a pm without message.send is refused like any gated action; the request goes to the launcher and only when that is a chief of staff (launch null, or by a coder, gives no-chief-of-staff); the messaging lists hold both ways; the shape bounds (19 bad inputs, 3 good ones); the request grants nothing (shipped pm.json lacks role.launch, shipped chief-of-staff.json has it, and the authorization result for both is unchanged by a request).
• launcher.test.mjs: "a launched pm's request_staff reaches the chief of staff; no other session has the tool and the launch limits still hold". It uses the real bwrap runner (the sandbox ran; the test is skipped without one). A launched pm calls request_staff through the tool socket and the chief of staff receives the STAFF-REQUEST; a coder's tool list has no request_staff, and its attempt reads refused: unknown-tool; after the request nothing has launched, the next coder launch works, the reviewer launch is refused capacity-full, and no launch is attributed to the pm. That last part is the "chief's launch stays inside the organization's limits" evidence: the request neither launches anything nor changes what the chief's launch allows.
• tools.test.mjs 18/18 and bundle.test.mjs 21/21 cover the tool's schema, its gate to the pm, and the prompt line only for a session that has the tool.

Mutants

mutants.sh <worktree> <outdir>, 2026-10-15T22:58:49Z, results in mutants-run.txt, one .out, .rc and .patch per mutant in mutants/. A dry run (MUTANT_DRY=1) first showed every edit matches its source exactly once on this base. Three controls (the staff-request, tools and bundle test files on the unmutated candidate) pass 7/7, 18/18 and 21/21. All 21 mutants fail their test by a named assertion (no timeout kills). The worktree was restored (git diff against the index is empty).

Mutant	What it removes or breaks	Killed by
m1	the sender-must-be-pm check	staff-request: only-pm test
m2	the recipient must be a chief of staff	staff-request: launcher test
m3	a missing launcher no longer refuses	staff-request: launcher test
m4	the messaging-list check	staff-request: messaging-lists test
m5	message.send accepts STAFF-REQUEST	staff-request: only-pm test
m6	thread.send accepts STAFF-REQUEST	staff-request: only-pm test
m7 to m9	count maximum, count minimum, integer check	staff-request: shape test
m10, m11	role list maximum and minimum	staff-request: shape test
m12	a role named twice	staff-request: shape test
m13	the task ref check	staff-request: shape test
m14	extra keys in a role entry	staff-request: shape test
m15	the message goes to the sender, not the launcher	staff-request: delivery test
m16	the log no longer names the task (staff_for)	staff-request: delivery test
m17	the request spends a different action than message.send	staff-request: the no-message.send, only-pm and delivery tests
m18	request_staff offered to every role	tools.test
m19	the tool schema's count maximum	tools.test
m20	the tool calls the wrong broker verb	tools.test
m21	the prompt line goes to every role that can send a message	bundle.test

The launcher end-to-end test has no mutant of its own: the mutants above kill each check at the unit that holds it, and the launcher test is the integration check that those pieces meet.

Gate

suites.sh <worktree> <outdir> (the row 142 script, unchanged), 2026-10-15T22:59:28Z to 23:03:08Z (gate-started.txt, gate-finished.txt, suites-run.txt, output per suite in suites/). All rc=0, in the worktree at dda7e31b0 plus the candidate. It runs every scripts/test-*.sh (10 of them) and the node suites:

Suite	Result
cli	208/208
business	106/106
bus	259/259
plugins	28/28
tasks	97/97
webui	113/113
harness	102/102
seat	135/135
scripts/test-auth.sh	15 passed, 0 failed
scripts/test-conductor.sh	17 passed, 0 failed
scripts/test-config.sh	24 passed, 0 failed
scripts/test-discord.sh	78 passed, 0 failed
scripts/test-extension-package.sh	18 passed, 0 failed
scripts/test-foundation.sh	44 passed, 0 failed
scripts/test-land-work.sh	84 passed, 0 failed
scripts/test-queue.sh	28 passed, 0 failed
scripts/test-release.sh	14 passed, 0 failed
scripts/test-task.sh	98 passed, 0 failed

No flake (#258, #261, #262, #263) recurred (no match in any suite output). The slot was Sage's "slot clear" (sage-0406); a busy check by exit status, /proc cwd links only, read CLEAR before the mutants and again before the gate. Docker: the gate left one network, q140b_default, which is mine; I removed it with docker network rm q140b_default and the network list now equals the before-list (suites/networks-before.txt, networks-after.txt).

Notes for the reviewer and for follow-ups

• Row 146 overlap. Row 146 (Dewey) also edits roles/chief-of-staff.md. My change there is one new bullet; expect a rebase on whichever lands second. The sentence "until the broker gives you a verb" in that file is stale for policy.change; Sage asked Dewey to fix it in row 146, so I left it.
• The STAFF-REQUEST body wording is guidance, not enforcement. The broker composes the body ("Launch what the organization's limits allow with launch, then answer this message with the instances you launched, or with the refusal and its reason."). The chief of staff is a model session; nothing makes it answer. What the row enforces is who may ask, the request's shape, and that the request grants no launch.
• The bounds 10 roles and 20 per role are request-shape bounds, not capacity limits (out of scope per the brief). They stop a malformed or runaway request; the organization file and the host's launch enforce actual capacity.
• Carried from row 132, unchanged by this row: the change_organization description says "replaces" while the broker merges per instance; a revision-only call is refused by the writer, not by the schema. Earlier S9/N6 follow-ups also still stand.

Not covered

• A live pm and chief of staff session exchanging a real request. The evidence is the in-process broker tests and the launcher test with the fake adapter; the row goes live in a re-pin.
• Role grants beyond PRD 1.5, and capacity limits (out of scope per the brief).
• Whether a real chief of staff model answers well; that is a prompt question, not a gate.