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 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.