stack/agents/filbert/work/queue-120/r2/body.md at dev-console

0 Fork 1

Files

T

jason.woltje b9ea9304fd lead: commit filbert's untracked evidence (273 files: queue-101 queue-102 queue-105 queue-107 queue-108 queue-109 queue-110 queue-112 queue-113 queue-114 queue-115 queue-116 queue-119 queue-120 queue-122 queue-123 queue-125 queue-126 queue-128 queue-129 queue-130 queue-131 queue-132 queue-133 queue-134 queue-135 queue-136 queue-137 queue-139 queue-140 queue-141 queue-142 queue-145 queue-146 queue-147 queue-148 queue-149 queue-150 queue-151 queue-152 queue-153 queue-154 queue-155 queue-156 queue-162 queue-163 queue-165 queue-166 queue-167 queue-169 queue-170 queue-175 queue-177 queue-181 queue-182 queue-184 queue-185 queue-186 queue-187 queue-188 queue-49 queue-64 queue-66 queue-70 queue-71 queue-80 queue-84 queue-85 queue-87 queue-88)

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.

2026-11-02 15:05:14 -06:00

4.3 KiB

Raw Permalink Blame History

Row 120 round 2 review (Filbert): approve

Candidate: manifest sha256 ae7515b97bb92fdde63e9d2e6fd8473700d3e0c12d9e70fff67e06129fbac1a9 (6 paths), base 66ea40580 (row 122 landed), packet agents/researcher/work/queue-120/ in f758a8e92.

Rebuild: 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.

F1 (round 1): fixed under ruling 28540, option (a)

review.request calls #checkMessaging(s, a.to) after the commit checks and before the message id, the review.requested event and #reviewMessage.
review.verdict calls #checkMessaging(s, r.from) after verdict-exists, at the same point before anything is recorded.
#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.
#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.
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.

The round 2 changes don't overlap row 122's organization argument or limits block.

The DECISION follow-up wording (Doc-only, follow-up)

build.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:

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.
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."

This is decision 137 doc-only: grep -rlF build.md packages/*/tests scripts/test-*.sh finds no file.

For the follow-up row (non-blocking): the arbiter path

The 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:

Business with arbiters.delivery: assistant and a coder with crossRole: ["git.push.working"].
The assistant's message.send to the coder: refused, message-recipient-refused.
The coder raises a delivery decision. It routes to the assistant, which resolves it with a free-text note.
A DECISION message from the assistant to the coder is stored, with the note in its body.

So 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.

It'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.

What I ran and what I took from receipts

I ran, as single files with TMPDIR set and Docker disabled:

Test file	Result
bus messaging	12/12
bus review	8/8
business role	14/14
business assistant	8/8

I also ran the arbiter probe above.

From Researcher's receipts, not rerun by me:

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;
21 of 21 mutants caught with 3 controls, including m16 and m17.

I took no slot. The landing gate at the landing target is still Sage's.

4.3 KiB Raw Permalink Blame History