stack/agents/dewey/work/queue-81/build.md

Row 81 (#1575): Console shows the reply to a web send, round 1

Owner: Dewey. Reviewer: Darkwing, then Sage's gate. Brief: docs/plans/2026-10-11_console-reply-view.md § "Show replies to a message without receiving them", blob dd42071d. Lead decision 97 made the row; decision 111 started it. Base ff11aa4b. None of the candidate's paths changed between ff11aa4b and refactor HEAD (1d4ba6bb) when the packet was built.

build.patch is git diff --cached --binary ff11aa4b -- the twelve paths below. Apply it with git apply --index to a detached worktree of the base; candidate-manifest.sha256 then checks 12/12 OK.

What ships

• Bus read replies (packages/bus/src/broker.mjs). {id}, nothing else (keys strict, identifier on the id). Returns the business's messages whose in_reply_to is that id, ORDER BY seq, LIMIT REPLIES (exported, 50). Human and reader sessions only; a role session gets human-required, the same gate as decisions and credentials. It is on the reader allowlist. An id naming no message in the session's business refuses message-not-found with the same query message.send uses for in_reply_to (SELECT id FROM messages WHERE id=? AND business=?), and the refusal is recorded like every other. It writes nothing: no deliveries row, no event on success.
• views passes it through: replies(id) calls ('replies', { id }).
• webui server: GET /api/bus/replies?id=<message id>. replies joins BUS_VERBS; the id must pass subjectOk (the broker's identifier rule) or the server answers 400 invalid-request without calling the bus. message-not-found already maps to 400 (busStatus). GET only, like the other reads.
• Console page (src/public/bus.js). A Sent receipt is followed by the replies to that message, read with replies on every render of the Inbox (the ten-second refresh and Read again). Each reply shows its role, time, class, a trail link and the body, through txt like every bus string. "No reply yet" when the list is empty; "could not be read" when the read failed, with mosaic talk named as the other place they print; a note at 50 that only the first 50 show. The receipt paragraph itself is unchanged, so .receipt text stays what row 76's tests check. A new send starts an empty list. The note under the box now says replies show under the receipt and that the Console never marks one delivered or read.
• CLI: talk's timeout is no reply from <role> within <n> s; it may still come, and the next mosaic talk shows it.
• READMEs: webui "Message a role" says where replies show, when they refresh, what each state means, and that the Console never receives or marks a message; the route paragraph lists /api/bus/replies?id=. bus README: the verb table row, replies in the reader capability list, a paragraph in "Human and reader paths", and read.replies(messageId) in the shared-reads snippet.

Decisions and tradeoffs

• A new verb, not a trail field (the brief left this to me). trail takes a task ref, decision id or message id and returns [] for an unknown subject; the brief says this read refuses an unknown id instead. Putting replies in trail would mean either changing trail's answer for unknown message ids or giving one field a different refusal rule from the rest of the call. Trail also returns linked records as a flat list of mixed tables; replies are a list of messages with their own cap. A separate verb keeps trail's shape and every existing trail caller as they are, and lets the Console read the replies without reading the whole trail on each refresh.
• Human and reader only. The brief says "the same sessions as the other reads (human and reader)". inbox/tasks/agents/trail are also open to role sessions; decisions and credentials are not. I followed the brief's wording and the newer two: a role gets human-required. A test checks a role can't read replies even to a message it sent.
• The receipt id is not checked against the broker before the read. The POST answer's id goes to replies as is; the server checks its form and the bus refuses an unknown one. The page shows that as "could not be read", not "No reply yet", so a bad id is visible.
• A late answer is dropped. If a send finishes while a replies read is out, that read's rows belong to the earlier message. The composer keeps the receipt object it read for and assigns the rows only if it is still the current receipt (receipt === r). Tested with a held read.
• A failed replies read doesn't mark the Inbox stale. It is caught in the composer, like the agents read for the role list, so the Inbox and its count stay fresh and only the receipt says the replies couldn't be read.

Files

• packages/bus/src/broker.mjs: REPLIES, the allowlist entry, the replies case.
• packages/bus/src/views.mjs: one line.
• packages/bus/tests/replies.test.mjs: new, 7 tests.
• packages/bus/README.md: verb table row, reader caps, one paragraph, snippet line.
• packages/webui/src/serve.mjs: BUS_VERBS, the id check.
• packages/webui/src/bus.mjs: comment only.
• packages/webui/src/public/bus.js: fetchRead's query name, the replies state and renderer, the composer read, the reset on send, the note text.
• packages/webui/tests/bus.test.mjs: 1 new test, 3 widened.
• packages/webui/tests/send-browser.test.mjs: 1 new test, the note assertion updated.
• packages/webui/README.md: "Message a role", the bus route paragraph.
• packages/cli/src/cli.mjs: the talk timeout message.
• packages/cli/tests/verbs.test.mjs: 1 new test, the timeout assertion.

Tests

• packages/bus/tests/replies.test.mjs (new, 7):
  • a reply is listed for human and reader sessions, and its delivery rows are unchanged: a reply to the send is listed; a message to the human with no in_reply_to and a reply to another message are not. Each row equals the messages row trail gives for the reply's id. The deliveries rows and the row counts of six tables are the same before and after; the reply's own deliveries are only routed.
  • the reply still reaches the human message.receive (mosaic talk) after the Console showed it: listed by reader and human, then received, read, and still listed.
  • a message with no reply gives an empty list.
  • replies come oldest first and stop at REPLIES: 51 replies from two roles; the first 50 in send order.
  • an id that names no message in the business refuses message-not-found: an unknown UUID, another business's message, a task ref and a decision id, for human and reader; each refusal recorded as an action.refused event. The other business's reader reads its own.
  • strict arguments; a role session gets human-required: seven bad argument shapes give invalid-request; a role gets human-required, including for a message it sent; the reader still can't message.receive.
  • views passes replies through.
• packages/webui/tests/bus.test.mjs: new replies route serves the replies to one message from the reader view (200 with the row, an empty list, unknown id 400 message-not-found, no delivery row, and seven missing or malformed ids that never reach the bus, ?subject= among them). Widened: the GET-only test (405 on replies), the no-bus refusals (replies?id=%3C 400, replies?id=m-1 503), the busReader passthrough.
• packages/webui/tests/send-browser.test.mjs: new a sent receipt lists its replies as the page refreshes, oldest first and capped, and marks none delivered or read, in a browser against an in-process broker: "No reply yet" after the send; after Read again, two replies in order with role, class, trail link and a hostile body shown as text (no script or img element, window.injected unset), the unrelated messages absent, deliveries unchanged; a third reply shows on the page's own ten-second refresh with no click; the human's message.receive then gets all three, and after they are read they are still listed; 51 replies show 50 and the cap note; an unknown sent id shows "could not be read" with no stale banner on the Inbox; a new send starts an empty list; a send that finishes while a replies read is held keeps its own empty list, and the next read shows its own reply. The row 76 note assertion now checks the new note.
• packages/cli/tests/verbs.test.mjs: the timeout assertion is now the exact new message. New a late reply the Console has listed still reaches the next talk: talk times out, the role replies, replies lists it, and the next talk prints it and marks only it read.

New tests on base code (new-tests-on-base.txt): every new test fails (replies.test.mjs at import, REPLIES isn't exported). Base tests on candidate code (base-tests-on-candidate.txt): bus 95/95; webui 80/81 and cli 113/114, the two failures being the row 76 note text and the old timeout regex /mosaic inbox/, both text the brief changes.

Mutants (mutants.py, mutants.txt)

17 single-site mutants, each run in a scratch copy of the candidate against the test files named in mutants.py. All 17 killed:

mutant	result
broker: no human-required	killed
broker: no message-not-found	killed
broker: newest first	killed
broker: cap 51	killed
broker: reader not allowed	killed
broker: no strict keys	killed
views: subject arg	killed
serve: no id check	killed
serve: replies not a verb	killed
page: query as subject	killed
page: no replies read	killed
page: no reset on send	killed
page: no stale guard	killed
page: cap note off by one	killed
page: body unescaped	killed
page: failure shown as none	killed
cli: old message	killed

mutants.txt is the raw output. Its BAD-ANCHOR (0) serve: no id check line is my anchor's wrong indentation (the mutant did not run); the last line is the rerun with the anchor fixed. The base tests don't reach replies at all, so I didn't tabulate a base column: every new test fails on base, above.

Gate (my run on the candidate)

On the candidate in a worktree of ff11aa4b, run sequentially, 2026-10-12T18:29:24Z to 18:35:52Z (gate-summary.txt):

• node --test 'packages/<p>/tests/*.test.mjs': bus 102/102, webui 83/83, control-board 124/124, cli 115/115, each rc=0.
• scripts/test-auth.sh, test-conductor.sh, test-config.sh, test-discord.sh, test-extension-package.sh, test-foundation.sh, test-queue.sh, test-release.sh, test-task.sh: all rc=0.

The packet's tree is the one gated: build.patch applied to a fresh worktree of ff11aa4b checks 12/12 against candidate-manifest.sha256.

For reviewers

• The bus README's verb table sits in "Client protocol", not the reads section the brief names. decisions and credentials have rows there, so I added one for replies. One line; drop it if the brief's file boundary is strict.
• packages/cli/README.md lines 61-65 say "the reply still lands in the inbox". That is the human's message inbox (what message.receive returns), not mosaic inbox, so it isn't wrong, but it reads like the timeout wording this row removed. The file isn't owned; a follow-up could say "the next mosaic talk prints it".
• Equivalent mutant not run: dropping business=? from the replies query. message.send refuses an in_reply_to outside the sender's business, so no reply can point across businesses and the filter changes no result. It stays as defence in depth, matching every other read.