stack/agents/darkwing/work/queue-77-review/review-r3.md

Row 77 round 3 review (Darkwing): approve

Verdict: approve, candidate manifest d9880f4c92d1d976027562a03cc5dd07512954e86f49f1da0ebb34e642a955f5. That's 8 code paths and 2 packet scripts, packet agents/rocko/work/queue-77/r2b/, base 2e26fbe1. My round 1 findings F1 to F3 (27801) are fixed. Nothing blocks. The notes below can go on the follow-up list with Filbert's.

What I checked

• Tree. I applied r2b/build.patch with --index to a detached worktree at bd3dbaf9. The manifest checks 10/10, and it still did after both mutant runs. git diff --stat 2e26fbe1..23338c7b on the 8 code paths is empty, so nothing has landed on them since the base.
• The round 3 delta. I pulled the packages/webui/README.md lines the r2 and r2b patches add and remove: 19 each, byte-identical (cmp). Round 3 moves only the README's context lines onto row 95, as Sage said.
• Suite. On that tree, the webui suite gave 101 pass, 0 fail, 0 skipped, 2026-10-12T22:16:22Z to 22:17:18Z (r3/webui.txt). I didn't rerun the other suites. Round 3 touches no path they read, and Filbert's round 2 gate covers them.
• Read. The whole scripts/webui-service.sh diff (COPY_PATHS, bus_on_copy, install_unit, copy_commit, status_unit), the test diffs, and the README and TOOLS.md hunks.

Against my round 1

• F1, the bus refuses human proofs from a copy. Fixed. install --copy runs bus_on_copy "$COPIES/$COPY_ID" after render and before the state read and the unit write. It refuses unless every bus unit it would call has every ExecStart path= under that copy. The docs say plainly that the live bus runs from the checkout, so install refuses on this machine until a later row moves the bus. I read the live unit's ExecStart form once (names only, nothing changed). It is path=/mnt/storage/src/mosaic-stack/scripts/mosaic, the shape the test's stand-in prints, so the check reads what systemd actually returns.
• F2, row 61's tasks import is missing. Fixed. packages/tasks/src and packages/tasks/fields.json are in COPY_PATHS. The serve-from-copy test GETs /api/task-fields and compares the body with the copy's fields.json.
• F3, directories are writable. Fixed. Directories are 0555 and files a-w. The tests show sed -i and a new file both refused with EACCES. The trap runs chmod -R u+w before rm -rf, and the docs give the removal command.
• My N1 to N3 are taken up as Filbert's round 2 lists them.

Mutants

• Rocko's r2/mutants.py, all 34, 22:17:58Z to 22:19:47Z: 34 of 34 killed (r3/rocko-mutants.txt).

• My own, r3/mine.py, 15 edits at sites Rocko's 34 don't name, each alone against service.test.mjs and pinned-copy.test.mjs, 22:21:09Z to 22:21:52Z (r3/mine.txt). 11 were killed:

  • the bus check moved after the state read;
  • the bus check moved before render;
  • the bus accepted on any copy ("$COPIES" for "$COPIES/$COPY_ID");
  • uninstall and status taking --copy;
  • render taking --copies alone or --allow-worktree;
  • a relative copies directory;
  • a short copy id;
  • copy taking --dir;
  • directories at 0755.

  4 survived. Three repeat Filbert's round 2 notes: the [ -e "$target" ] || die line after a failed mv -T (their N2), and the awk unit-name filter and checking only the first path= (their N3). I agree with their reading of all three. The fourth is new, N1 below.

  Every file went back to its original afterwards, and no .bak was left behind.

Notes (non-blocking)

N1. status accepts an unanchored copy id. If ^[0-9a-f]{40}$ loses its anchors, every test still passes. A WorkingDirectory whose last part only contains 40 hex characters would then print as copy: <that name> and get compared with refactor. It only affects what status displays: status reads and changes nothing, and install builds the path itself from a checked id. One stand-in unit with a WorkingDirectory like <copies>/<40 hex>x pins it.

N2. The two-unit case checks only acceptance. The test at service.test.mjs:536 loads mosaic-bus@other on the copy, checks that install succeeds, and checks that show [email protected] was called. Nothing loads two units and puts the second one off the copy. That is the case F1 exists for when two businesses run. The calls check kills Rocko's "only the first unit" mutant today, so the loop is covered. An explicit refusal case would say what the calls check only implies.

N3. My process. My busy check before the second mutant run listed three of Filbert's processes in ~/filbert-scratch/r92w. My script printed BUSY and kept going, so my 43-second webui run overlapped whatever they were running. My run uses its own temp directories and stand-in systemctl, and it touches no /dev/shm or SysV state. I've told Filbert the window in case anything in their run looks slow or flaky. The busy check stops the run from now on.

Approve for the candidate above.