jason.woltjeandClaude Opus 5.5
08e327bf58
Candidate manifest 616f953fe09bfc198645886bc4c7228a0fdeafa8c89b1729f2be8a5222689607 on dda7e31b0.
Owner's gate 23:11:36Z-23:15:46Z exit 0; mutants 17 of 17 killed.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
3.4 KiB
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'.