# Row 146 (#1640) mutants

There is one mutant per new check: 12 in packages/bus/src/broker.mjs (`#waiting`, `#notice` and
message.send's result) and 5 in packages/cli/src/cli.mjs (`waitingLines` and its print).
mutants.py applies each one to ~/dewey-scratch/r146/wt, then runs these files, with each
package as the working directory:

- bus: tests/launch-notice.test.mjs
- harness: tests/runner.test.mjs
- cli: tests/verbs.test.mjs and tests/tester.test.mjs

It restores the source after each mutant and again in `finally`. The run ended with
`restored True`, and the candidate manifest checked DIGESTS_OK afterwards.

No control step runs inside the harness. The control is the single-file runs on the unmutated
candidate at 23:05:29Z, all 0 fail: launch-notice 7, runner 24, verbs 7, tester 7.

The run went from 2026-10-15T23:06:30Z to 23:11:24Z, in the slot (sage-0417). The logs are in
mutants/ and the console output is in mutants-run.log.

**Result: 17 of 17 killed.**

| Mutant | Fault | Killed by |
|---|---|---|
| B1-recipient | drop the holder check, so a running role gets a notice too | bus "a message to a running role sends no notice…", bus "no notice for a message to launch.by…", cli verbs |
| B2-to-human | drop `to === 'human'` | bus "no notice for…" |
| B3-to-tester | drop `to === 'tester'` | bus "no notice for…" |
| B4-thread-instance | drop the thread-instance exception | bus "no notice for…" |
| B5-to-launcher | drop `to !== by` | bus "no notice for…", cli verbs |
| B6-from-launcher | drop `sender !== by` | bus "no notice for…"; 7 harness tests |
| B7-from-tester | drop `sender !== 'tester'` | bus "no notice for…", cli tester |
| B8-no-launcher | drop `by !== null` from `told` | bus "a business with no launch block…", cli verbs |
| B9-notice-sent | never call `#notice` | bus tests 1, 3, 4 and 7; harness launch-notice test; cli verbs |
| B10-class-result | notice class INFO, not RESULT | bus test 1 (class assert); harness "the bus's launch notice is one turn with no reply…" |
| B11-launcher-running | `launcherRunning` always false | bus tests 1 and 5, cli verbs |
| B12-result-waiting | message.send never returns `waiting` | bus tests 1, 4, 5 and 6; harness launch-notice test; cli verbs and tester |
| C1-printed | talk never prints the waiting lines | cli verbs, cli tester |
| C2-no-launch-by | drop the no-launch.by line | cli verbs |
| C3-launcher-down-self | drop the line for a message to launch.by itself | cli verbs |
| C4-tester-line | drop the tester line | cli tester |
| C5-launcher-down-either | drop the "either" restart line when launch.by is stopped too | cli verbs |

## B6 and the harness tests

The harness fixture's launch block has `by: pm`. Under B6, pm's own message to a stopped coder
sends pm a notice. The runner then takes that notice as a turn ahead of the message the test
sent. For example, "a task closed on the tracker…" got the notice body where it expected its
open-task block.

That is the self-wake that call 4 excludes. Without the exception, launch.by's own traffic
wakes it.

## B10 in the runner

With class INFO, the runner's auto-reply to `_bus` is refused and the read is skipped. The
harness test fails at its first wait, for the notice's `read` row: `Error: timed out waiting`
(mutants/B10-class-result.log, line 76). The read never comes, so the notice stays unread. That
is the outcome BUILD.md describes, and it is not a loop. The bus test fails on its class assert,
`'INFO'` against `'RESULT'`.