stack/agents/filbert/work/queue-146/r1/body.md

Row 146 round 1 review (Filbert): approve

Candidate: manifest sha256 616f953fe09bfc198645886bc4c7228a0fdeafa8c89b1729f2be8a5222689607, 10 paths, base dda7e31b0, packet agents/dewey/work/queue-146/ in 08e327bf5.

I found no defect, and every test the brief lists is there. The notes below don't block.

Rebuild

• A fresh worktree at dda7e31b0 with build.patch applied. Every manifest hash matched and git diff --check was clean (10 files, +396 -16).
• The added lines have no dash, curly-quote or control characters. The packet manifest checks.
• No commit from dda7e31b0 to refactor HEAD touches a manifest path.

What I checked and found correct

• When a notice goes out. #waiting runs at the end of message.send, after the message is stored and routed.
  • It returns null for the human, the tester, a thread instance inside its thread, and a target #recipient finds a claim for.
  • told needs a launch block, a target that isn't launch.by, and a sender that is neither launch.by nor the tester.
  • A thread run sending to a non-thread role works too: #recipient reads the role's holder there, so a stopped pm still tells chief.
• launch.by is always a declared instance. business.mjs:121-126 requires launch.by to be declared and to hold role.launch within-role. So the notice never goes to an unknown role.
• Dedupe "through the store". I agree with BUILD.md call 7:
  • #notice has one caller, #waiting, and message.send calls that once, for the message it has just inserted.
  • Every verb runs inside this.#store.transaction (broker.mjs request), so the notice row is written if and only if the waiting message is. A crash can't leave one without the other.
  • #routeWaiting, #routeThread, release and a restarted Broker only write deliveries rows, and none of them reaches #notice.
  • A lookup by in_reply_to would be dead code. The structural form is stronger: the store holds exactly one notice per waiting message because the notice is part of the message's own transaction.
  • My mutant M2 (below) adds a notice on every re-route, and test 3 kills it. So the property is pinned if a later change adds a path.
• _bus stays internal. The notice is a direct insert, not a verb. ID_PATTERN rejects _bus, and test 7 covers each field a caller controls.
• RESULT. I read the runner's auto-reply path and agree with the correction in BUILD.md: a non-RESULT notice wouldn't loop, but its auto-reply to _bus would refuse, and the notice would stay unread. The runner test covers it at runner level (two turns, one delivered and one read row, no reply, no "reply to ... failed").
• talk. waitingLines prints once, after sent. The business is read only when a restart line prints.
  • The restart line's claims hold. launcher.mjs:467-472 (launchPm) is the only start of launch.by, and bus-service.sh:209 prints pm: on/pm: off from the unit's ExecStart.
• chief-of-staff.md. The _bus duty matches the notice body. The sage-0407 item 3 sentence now names change_organization. tools.mjs:151-158 shows it changes limits, the model table and each instance's model, exactly as the new sentence says. Hiring still goes to policy.change.
• READMEs. The bus and cli README text matches the code.
• Tests against the brief.
  • Exactly one notice: launch-notice test 1.
  • None for a running role: test 2.
  • None at a re-route at claim or a broker restart: test 3.
  • Both of talk's waiting lines and the restart line for launch.by: the new verbs test.
  • The tester and no-launch-block cases are extra.

Notes (non-blocking)

1. No test pins where the notice is routed when launch.by is running. My mutant M1 routes the notice to the target instead of launch.by, and it survives launch-notice (7/7) and runner (24/24).
   • It survives because message.receive selects on to_role, not on the routed holder. So chief still receives it, and the only effect is the evidence: the notice's routed row shows no holder while chief holds the role.
   • The Console's waiting lists read those rows. One assertion in test 1 would pin it: after the second send with chief running, the latest notice's routed holder_run is chief-run.
2. A notice can go to launch.by for a role it can't launch. For a target outside launch.instances (cto, say, in a business whose launch block doesn't list it), chief is told and talk prints "chief has been told". Chief's contract covers this: reply to the sender with why not. A later row could add whether the target is a launch instance to waiting, so talk can say so at once.
3. Row 142. Both rows change talk in cli.mjs and verbs.test.mjs. Sage's plan is for 146 to land first and 142 to rebase. I'll review 142's round 3 on the combined output.

What I ran and what I took from receipts

I ran, as single files on the candidate with Docker disabled, all with 0 fail and 0 skipped. Every file except runner used TMPDIR set to scratch. runner used the default TMPDIR.

Test file	Result
bus launch-notice	7/7
bus messaging	13/13
bus threads	14/14
bus broker	16/16
bus tester	11/11
bus chief-of-staff	13/13
bus csuite-messaging	16/16
cli verbs	7/7
cli tester	7/7
cli follow	6/6
cli limits	4/4
business chief-of-staff	10/10
harness runner	24/24

I also ran three mutants of my own on broker.mjs, one at a time. The tree matched the manifest again afterwards.

Mutant	Result
M1: #notice routes to the target, not launch.by	survives launch-notice 7/7 and runner 24/24 (note 1)
M2: #routeWaiting sends a notice on every re-route	launch-notice 1 fail
M5: launcherRunning reads the target's holder, not launch.by's	launch-notice 2 fail, cli verbs 1 fail

From Dewey's receipts, not rerun by me:

• B1 to B12 and C1 to C5, 17 of 17 killed, 23:06:30Z to 23:11:24Z (MUTANTS.md).
• The gate from 23:11:36Z to 23:15:46Z, exit 0 (gate-run.log): bus 259, business 106, cli 209, harness 101, plugins 28, seat 135, tasks 97, webui 113, and every scripts/test-*.sh.

I took no slot.