## Row 152 round 1 review (Filbert): approve

Candidate: manifest sha256 `c333f4beffec1d901ca23200365698e42003c8256a609ad662429d15e63747c1`, 7 paths, base 56639c99b, packet agents/dewey/work/queue-152/ in ecf1cec07.

I found no defect, and the tests the brief asks for are there: a target inside and outside `launch.instances`, in both the bus result and talk. The notes below don't block.

### Rebuild

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

### What I checked and found correct

- **`launchable` is well defined.** business.mjs `checkLaunch` requires `launch.instances` to be a non-empty distinct list of declared instances whenever a launch block exists, so `launch.instances.includes(to)` never reads a missing list. The same check refuses `launch.by` inside `instances`, so `false` for `launch.by` itself is true to the data, as BUILD.md says.
- **The change is additive.** `waiting` keeps row 146's four keys and adds one. `told`, the routing and the stored message are unchanged; only the notice body is chosen by `launchable`. The new bus test shows the message is stored for `coder`, a later claim delivers it, and no second notice goes out.
- **talk.** In `waitingLines` the `w.role === w.launcher` line still comes first, so the launcher case doesn't change. The launch-block line comes before the told line and prints no restart line. A restart only starts `launch.by`, which still couldn't launch the role, so that's right.
- **The call: launch.by is still told.** I agree with BUILD.md "The call".
  - I checked point 1: nothing under packages/webui/src reads `waiting` or `launchable`. So without a notice, a Console sender would see no reply at all.
  - Point 2 holds: roles/chief-of-staff.md line 22 already has "tell the sender why not with a message `in_reply_to` the waiting message", and the new text asks only for that branch. No contract change is needed.
  - Mutant B4 pins the call.
- **Docs.** The bus README, the cli README paragraph (sage-0481) and TOOLS.md match the code and the test strings.

### Notes (non-blocking)

1. **An older bus without `launchable`.** As Dewey notes, no test sends a `waiting` without the key, so a `!w.launchable` mutant would survive. The `=== false` check and its comment carry it today.
2. **A tester's message to a role outside the launch block** prints the launch-block line, not "a tester's message tells nobody to launch it", because the launchable check comes first. Both lines are true, and the launch-block one says more. No test covers this ordering.

### 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 inherited TMPDIR.

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

I ran no mutants of my own.

**From Dewey's receipts, not rerun by me:**
- B1 to B6 and C1 to C2, 8 of 8 killed, 00:41:24Z to 00:41:36Z (BUILD.md, mutants-run.log).
- The gate from 00:42:47Z to 00:46:38Z, all 0 fail (gate-run.log): bus 276, cli 215, business 108, webui 113, and every scripts/test-*.sh.

I took no slot.