jason.woltje
b9ea9304fd
Unclaimed files left in the canonical checkout. Inventory: canonical-cleanup-inventory.md (commit-as-evidence groups). detect-secrets scan clean on 2026-11-02: hits are sha256 pins, git object ids, test sentinels already in tracked tests and unit-file lines.
1 line
4.3 KiB
JSON
1 line
4.3 KiB
JSON
{"body":"## Row 120 round 2 review (Filbert): approve\n\nCandidate: manifest sha256 `ae7515b97bb92fdde63e9d2e6fd8473700d3e0c12d9e70fff67e06129fbac1a9` (6 paths), base 66ea40580 (row 122 landed), packet agents/researcher/work/queue-120/ in f758a8e92.\n\nRebuild: a fresh worktree at 66ea40580 with f758a8e92's row120.patch applied. Every manifest hash matched and `git diff --check` was clean. The added lines have no dash, curly-quote or control characters. No commit from 66ea40580 to HEAD touches a candidate path.\n\n### F1 (round 1): fixed under ruling 28540, option (a)\n\n- `review.request` calls `#checkMessaging(s, a.to)` after the commit checks and before the message id, the `review.requested` event and `#reviewMessage`.\n- `review.verdict` calls `#checkMessaging(s, r.from)` after `verdict-exists`, at the same point before anything is recorded.\n- `#consumeAuthority` runs earlier in both cases, but inside the request transaction, so a refusal rolls it back. Test 1 confirms this: two identical refusals, then the decision is still usable, and the `action.allowed` count is unchanged.\n- `#reviewMessage` is untouched. The three message inserts in broker.mjs are the decision close (948), `message.send` (1017) and `#reviewMessage` (1385). The last two are now checked.\n- The new tests cover both directions after a human approval, and a coder-to-reviewer pair with no lists still works. In the mutant log, m16 and m17 each fail exactly their own test.\n\nThe round 2 changes don't overlap row 122's `organization` argument or limits block.\n\n### The DECISION follow-up wording (Doc-only, follow-up)\n\nbuild.md's \"Noted follow-up\" says: \"Today the assistant holds no decision authority and its `crossRole` is `[]`, so it can't be the raiser or the target of one.\" The first half is wrong. The assistant can raise decisions; test 1 has it raise one for `review.request`. The follow-up still holds today, but for this reason:\n\n- A decision the assistant raises is gated (it routes to the human) or within its role (it routes to itself). With `crossRole: []` it never routes to an arbiter. So a DECISION close reaches the assistant only from the human or its own role.\n- Suggested text: \"The assistant can raise decisions, but with crossRole [] they close only by the human or within its own role, so the DECISION close message reaches it only from the human. Gate that insert if a role with messaging lists gets crossRole actions or is named an arbiter.\"\n\nThis is decision 137 doc-only: `grep -rlF build.md packages/*/tests scripts/test-*.sh` finds no file.\n\n### For the follow-up row (non-blocking): the arbiter path\n\nThe decision close also sends in the other direction: the closer sends to the raiser. Nothing stops a business file from naming the assistant as an arbiter; business.mjs:157 only requires that the role exists. I probed this on the candidate:\n\n1. Business with `arbiters.delivery: assistant` and a coder with `crossRole: [\"git.push.working\"]`.\n2. The assistant's `message.send` to the coder: refused, `message-recipient-refused`.\n3. The coder raises a delivery decision. It routes to the assistant, which resolves it with a free-text note.\n4. A DECISION message from the assistant to the coder is stored, with the note in its body.\n\nSo REQ-ASSIST-2 holds today only because the arbiters are other roles; the example names pm and cto. I missed this in round 1, where I said the follow-up holds because of `crossRole: []` alone.\n\nIt's the same decision-close insert that Sage ruled out of scope (28540), and reaching it needs a human edit of the business file, so I'm not blocking on it. The follow-up row should cover both directions of that insert. Alternatively, the validator could refuse a role with messaging lists as an arbiter.\n\n### What I ran and what I took from receipts\n\n**I ran**, as single files with TMPDIR set and Docker disabled:\n\n| Test file | Result |\n|---|---|\n| bus messaging | 12/12 |\n| bus review | 8/8 |\n| business role | 14/14 |\n| business assistant | 8/8 |\n\nI also ran the arbiter probe above.\n\n**From Researcher's receipts, not rerun by me:**\n- the eight package suites (business 88, bus 171, harness 84, cli 195, webui 112, tasks 92, conversation 182, seat 132) and test-task.sh 98/0 on the rebased tree;\n- 21 of 21 mutants caught with 3 controls, including m16 and m17.\n\nI took no slot. The landing gate at the landing target is still Sage's.\n"} |