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

Candidate: manifest sha256 `cb831847239e9ea60bd77ed8c765dafbf607a03cadeed3d0fc8d8284846878ed`, 2 paths, base 686fc1cb6, packet agents/dewey/work/queue-151/ in 20c0ee1c6.

I found no defect, and both tests the brief asks for are there. The note below doesn't block.

### Rebuild

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

### What I checked and found correct

- **launch-notice test 1.** After the second send with chief running, the new assertion reads the latest notice's `routed` delivery and expects `holder_run` `chief-run`. This is exactly the row 146 note 1 gap: message.receive selects on `to_role`, so this row is the only thing that shows where the notice was routed.
- **The new talk test.** pm is `launch.by` and running, and cto is stopped.
  - pm's INFO note arrives on the first poll. It has no `in_reply_to`, and talk's filter is `m.in_reply_to !== sent.id`, so the note exercises that filter directly.
  - cto claims and replies on the second poll.
  - The exact stdout pins three things: `sent`, the waiting line printed once with no restart line (pm is running), and only the reply.
  - `polls == 2` shows the note came first. Only the reply is marked read, and inbox shows pm's note as 1 unread.
- **Against the brief.** Mutants for the routing, the reply filter and the `waitingLines` write are all killed (Dewey's B1, C1 and C2, and my F1). No product code changes.

### Note (non-blocking)

1. **The new test's non-reply comes from another role.** My F3 makes talk's filter check the sender (`m.from_role !== to`) instead of `in_reply_to`. It survives the new test, because pm's note is skipped either way. Row 142's two talk tests kill it, so the property is pinned. If a later row wants the new test to stand alone, the first poll could also carry a non-reply message from cto.

### What I ran and what I took from receipts

**I ran**, as single files on the candidate with Docker disabled and TMPDIR set to scratch, all with 0 fail and 0 skipped:

| Test file | Result |
|---|---|
| bus launch-notice | 7/7 |
| cli verbs | 8/8 |
| cli follow | 6/6 |
| harness runner | 24/24 |

In Sage's slot (sage-0473), from 00:22:04Z to 00:22:32Z, I ran three mutants of my own, one at a time. The sources matched their sha256 again afterwards.

| Mutant | Result |
|---|---|
| F1: `#notice` routes to the target, not `launch.by` (my row 146 M1) | launch-notice 1 fail |
| F2: talk marks every skipped message read | verbs 3 fail: the new test and row 142's two talk tests |
| F3: talk's filter checks the sender, not `in_reply_to` | verbs 2 fail: row 142's two talk tests; the new test passes (note 1) |

**From Dewey's receipts, not rerun by me:**
- B1 and C1 to C3, 4 of 4 killed, 00:13:46Z to 00:13:59Z (BUILD.md, mutants-run.log).
- The gate on 686fc1cb6 from 00:14:06Z to 00:16:58Z, exit 0 (gate-run.log): bus 265, cli 213, and every scripts/test-*.sh.