Files

4.0 KiB

Filbert review: row 184 round 1 (#1682), approve

Request 29395. Candidate manifest e7e2c76308e1b00391bb758d66fb8b427aad3e2985f30c651f5ef84c02ee2630 (7 paths) on base 7fc98cf19. The brief is the "tester thread verbs in the CLI" section of blob 3b4313cb9f. The design and the changed tests were accepted in sage-1208.

Verdict: approve. No findings and no blocking notes.

What I ran

  • I built ~/filbert-scratch/r184-r1/wt from 7fc98cf19, then ran git apply --index build.patch.
    • sha256sum -c on the manifest passed 7/7, and the manifest file hashes to e7e2c763...c02ee2630.
    • The patch-id is ad846db177b3: 7 files, +345/-28.
  • Base drift: git log 7fc98cf19..refactor (3da362982) on the 7 paths is empty.
  • I then moved the worktree to 3da362982, keeping the staged candidate. The manifest still checks 7/7 and the patch-id is unchanged. So my run has row 182's broker (#testerOwns) in it, where Dewey's run 2 was on 7fc98cf19 and their row 182 check was a code read.
  • I took the slot on sage-1226, with the /proc busy check CLEAR before and after, and TMPDIR ~/fs184. The run went from just after 05:56:50Z to 06:01:19Z.
    • Singles: tester-threads 5/5, thread-cli 11/11, tester-reads 6/6, each rc 0.
    • The cli suite (node --test tests/*.test.mjs in packages/cli): 420/420 pass, 0 fail, rc 0.
    • The counts are awk sums over the spec logs.
  • My mutant M5 removes the await members?.refresh(); that reads the thread before the first message.receive in talk. Killed: tester-threads rc 1, failing only "with --tester a human thread refuses with the bus's code, and nothing is written". Without that read, follow --thread on a human thread receives (and marks read) the tester's waiting reply before any refusal. cli.mjs was restored by git checkout.
  • Dewey's red base, M1a-M4 and run 1 and 2 numbers are their receipts, not mine.

Checked against the brief

  • Item 1. threadCommand (thread.mjs:130) takes --tester for create, open and read. callFor (cli.mjs:185-190) picks the tester transport when the flag is set and skips refuseInsideAgent only then. threadsCommand already took it (row 175).
  • Item 2. The refusal at the base's cli.mjs:361 is gone. talk builds its call through channelCallFor, which wraps callFor, so --thread --tester resolves the thread and sends with thread.send as the tester. The tester's thread.list lists only its own threads, so a label or prefix of a human thread doesn't resolve, and a full id gets the bus's thread-not-owned (test 3 covers both).
  • Item 3. The loop receives with message.receive only, and never calls inbox. Test 2 checks that for --follow and follow --thread, along with the thread filter (messages outside any thread and in the other tester thread stay unread).
  • Item 4. TOOLS.md and the cli README list [--tester] on each form, and the README's refusal list drops the thread verbs. I grepped packages/, docs/TOOLS.md and scripts/ for text that still says the CLI's thread verbs are human-only, and found none.
  • No bus change. Every verb the tester path calls (project.list, thread.list, thread.create, thread.open, thread.send, thread.messages, message.receive, message.read) is in TESTER_VERBS (broker.mjs:98-100).
  • Brief tests 1-3 are new tests 1-3, plus test 4 for the forms without --tester. Test 5 runs the real scripts/mosaic and tester-cli.mjs.
  • Changed tests. thread-cli.test.mjs:311 and the tester-reads exit-4 list drop only the argvs that pinned the removed refusal. The rest of each loop and its writes assert stay.
  • Readers and pins. No 64-hex pin names a changed path. host.test.mjs:826 reads the cli README for a line this row doesn't touch, and it passed in my suite run.

Deviations

I agree with all three. The usage text change (1) is visible only on a usage error. Item 3 needed no code (2), and my M5 shows the read-first order is what keeps a refused follow from writing. thread.send has no waiting field (3).