stack/agents/dewey/work/queue-143/REVIEW.md

**Row 143 review, round 1: changes.** Reviewer: Dewey.

- Candidate: manifest digest `34567470796a3afe67f8cf4d24a2c46436f81592ea89d434fa1091a12890d3f0` (rev 1634), packet `agents/researcher/work/queue-143/`.
- Base: 8517e5f45.
- My evidence: `agents/dewey/work/queue-143/`.

### What I ran

All of it ran in my test slot (sage-0653), in my own worktree at 8517e5f45 with `row143.patch` applied. Every manifest hash checks there.

- **Base drift:** none. No manifest path changed between 8517e5f45 and 203481725.
- **Single files:**
  - spec-review 11/11
  - spec-review-contracts 2/2
  - harness tools 20/20
  - business assistant 11/11
  - business role 14/14
  - bus csuite-messaging 16/16
  - bus decision-route 5/5
  - harness spec-tools 2/2

  This confirms the "final file passes 11/11 singly" claim.
- **Whole packages:** bus 344, business 115, harness 109, all pass. gate-r1's bus 343 is from before the forged-notice test was added; 344 includes it.
- **Researcher's `mutants.sh` on my tree:** 3 controls pass. 29 mutants: 28 fail a test and `t3` survives, which matches mutants-r1 and r1b.
- **Two mutants of mine on `#specThread`** (`extra-mutants.sh`; Researcher can rerun them):
  - `d1`, `t.instance=?` → `(t.instance=? OR 1)`: survives, but it's equivalent. thread.create refuses unless the business has exactly one threaded instance (broker.mjs:2081-2083), so every thread already belongs to that one assistant.
  - `d2`, `p.repo=?` → `(p.repo=? OR 1)`: survives, and it isn't equivalent. See N1.

### Change (blocks)

**N1. Nothing tests the project condition in `#specThread`.**

Under `d2`, the relay goes into the user's most recently opened assistant thread in any project. That case is reachable, because the one assistant instance holds the user's threads in every project. Example: Jason saves the spec in project A, but the last thread he opened is in project B. The BLOCK summary then lands in B's thread.

The test "the relay lands in the user's most recently opened thread of the notice's project" (spec-review.test.mjs:127) puts both of its threads in one project, so it doesn't check what its title says.

Fix:
1. Add a more recently opened assistant thread in a second project.
2. Assert that the relay lands in the notice project's thread.
3. Show `d2` failing.

### For Sage (outside this candidate's files)

**F1. Acceptance 314 step 9 can't pass as 314 is written.** This answers note 1: step 3 doesn't give Jason an assistant thread.

- `mosaic talk assistant` sends a plain human `message.send` REQUEST (cli.mjs:331).
- The assistant is the threaded instance, so the bus refuses that REQUEST with `thread-required-use-thread-send` (broker.mjs:288). Steps 3 and 6 therefore fail at their first `talk`, before row 143 is involved.
- No shipped CLI or Console code calls project.create, thread.create, thread.open or thread.send (I grepped packages/ and scripts/, outside the broker and tests).
- So no 314 run has a Jason-owned assistant thread in a projects row with repo `stack`, and step 9's relay is refused with `thread-required-reply-to-thread-message`. Researcher's BUILD.md states this limit, and a test covers it.

The fix belongs in 314 and row 128, not in this candidate:
- add row 128 (#1622, queued) to 314's prerequisites;
- add a before-the-run step that creates the bus project with repo `stack` and Jason's assistant thread in it.

**F5. Nothing tells the chief of staff how to relay.**

- The relay reaches the assistant only as a reply on the chain back to the notice.
- chief-of-staff.md says only "Report to the assistant what the roles answer" (line 36). It says nothing about replying `in_reply_to` the BLOCK or the accept.
- A relay sent without that link is refused with `thread-required-reply-to-thread-message`. The code asks for a reply to a thread message, and the BLOCK isn't in a thread, so the code doesn't tell the chief what would work.
- The tests set `in_reply_to` on the relay by hand.

chief-of-staff.md is outside the brief's files, and row 149 edits it. Sage decides between:
- adding the file to row 143 for one bullet in round 2 (whichever row lands second rebases), or
- a follow-up before the 314 run.

I recommend round 2.

### Doc-only (follow-up, doesn't block)

- **F2.** BUILD.md says `t3` shows that the `from_role` test adds no behaviour. `t3` removes the body test (`m.body.startsWith(SPEC_NOTICE)`) and keeps `from_role`. The equivalence does hold for the body test. The only other `_bus` body, the launch notice (broker.mjs:2324-2325), starts "Message <id> from", so the regex in `#specThread` can't match it at that offset.
- **F3.** BUILD.md says row 149 touches `tools.test.mjs`. It doesn't; row 149's harness test is the new `raise-domain.test.mjs`. Both rows touch `tools.mjs`, in different hunks: `MESSAGE_CLASSES` here, `raise_decision` there.
- **F7.** In pm.md, a blank line comes before the new bullet, so it renders as a second list. cto.md and assistant.md don't have the gap. Cosmetic.

### Accepted as built

- **F6.** The brief says a BLOCK "goes to the assistant". Here the BLOCK goes to the chief of staff, and the chief's relay goes to the assistant. REQ-ASSIST-2, the assistant's shipped messaging lists and the `message_threads_match` trigger leave no other path. The brief's own "summarize chief's text" also expects the chief in between.
- **Notice class.** The notice is class RESULT, so the runner takes a turn and sends no automatic reply (runner.mjs:387). pm, cto and chief-of-staff hold message.send with no messaging lists.
- **Docs.** The TOOLS.md and bus README text match the code. `thread.send` already refuses BLOCK at base.
- **Gate log.** gate-r1.log matches BUILD.md.

### Overlap with row 149

- Row 149's candidate patch applies over this one with no conflict.
- None of row 149's paths changed between 4b1795a8c and 8517e5f45.
- On the combined tree, all 12 touched test files of both rows pass (`runs/combined/`).
- Whichever row lands second still rebases and reruns every touched file.