stack/agents/dewey/work/queue-63-review/r2/verdict.md

Dewey: approve, round 2, candidate manifest 2a22fd3f0a04c38e65d40d215b95516c07a9eeff6b2199accc49c39422e22859

My round 1 finding is closed. Each of the five sites that had no test now has one that fails if the site goes back to the root, and the code is unchanged from round 1.

What I checked

• build.patch (packet 557b28fb) applied with git apply --index to a detached worktree of cca5f23e checks 6/6. None of the six paths, and not fake.mjs, changed between cca5f23e and refactor 16d5310b.
• verbs.mjs and the harness lines are byte-identical to round 1's. The README change rewraps the task.create paragraph with the same words, which closes my round 1 non-blocking note.
• On the candidate, sequentially, 23:01:50-23:02:57Z, all rc=0: tasks 84, harness 65. Same counts as your gate.
• The test changes: thenFailRead takes the task id to fault, and tree() passes an edit to world() after TREE. The edit that thenFailRead returns holds only fake and fetch, so the spread can't replace TREE's tracker or scopes.

The four new tests against my round 1 mutants

mutants.py and mutants.txt here: round 1's ten mutants, the same swaps, run in a scratch copy of the round 2 candidate against every packages/tasks test. The runner now gives each run its own process group and kills it after 300 s; none hung. All 10 are killed, the five round 1 survivors included. After the run the scratch copy's six files are byte-identical to the candidate again.

Round 1 survivor	Killed by
handle's final read uses the root's project and view	a verb in the child records the final read (non-null etag after task.assign)
create's final read uses the root's project and view	the same test, after the create
create's fallback uses ctx.view.ids.todo	a child create whose final read fails records the child's todo bucket
step's re-read uses the root's project and view	a lost answer in the child is settled by a re-read (in-progress and done, exactly two PUTs)
located reads only the first relation	every related task is read before authority (the second relation names the child with a root task id: task-moved, no write)

The failed-read test also checks that, after a tick, the only task.changed.external is the grandchild's task 1, so a create whose final read failed is not later recorded as an external change.

Merge note. Rows 63 and 90 share five paths. Stacked on a0005d62 in either order, the second patch fails on packages/tasks/README.md and packages/tasks/tests/verbs.test.mjs. Whichever row lands second needs a rebase and a new candidate manifest. I've told Sage.