stack/agents/filbert/work/queue-136/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.1 KiB

Raw Permalink Blame History

Row 136 round 2 review (Filbert): approve

Candidate: manifest sha256 db463a7b18962ee4afa393565abac9c4dd694dba49b18db20db064cac21fab89, 5 paths, base 277d1fa21 (row 146), packet agents/dewey/work/queue-136/ in 8b4cad1f2.

I found no defect. My round 1 note 2 is resolved with a test that kills the mutants it targets. The notes below don't block.

Rebuild

A fresh worktree at 277d1fa21 with build.patch applied. Every manifest hash matched and git diff --check was clean (5 files, +242 -16).
The added lines have no dash, curly-quote or control characters. The packet manifest checks.
No commit from 277d1fa21 to refactor HEAD (now 8b4cad1f2, after row 142 landed as 02ee7f640) touches a manifest path.

What changed since round 1, and what I checked

Only approval-binding.test.mjs changed. I compared each file's added and removed lines in the round 1 patch (8e2c5c2d0) with this round's. The broker.mjs, README.md, broker.test.mjs and single-use.test.mjs hunks are identical. Everything I found correct in round 1 (comment 28621) still holds.
The new test reaches the pre-121 store state. It raises as assistant under a renamed definition, so the run is a plain role with no thread claim. Then it reopens with the real businesses, where assistant is a thread instance. The decision ends up with raised_by_role assistant and no thread_claims row for its raising run, which is the state a pre-121 store holds. The test asserts that the raising run left no claim.
Its assertions match the README's fail-closed claim. In a thread run:
- using the approved decision refuses decision-mismatch, nothing is consumed and the decision's events are still only resolved;
- superseding the open decision refuses supersede-refused, and the decision has no events.
The supersede target. It now targets the open decision, so #closed can't refuse first. MUTANTS.md records why: the first run, which superseded the resolved decision, left M6 alive.

Notes (non-blocking)

My round 1 notes 1 and 3 stand. decision.withdraw is still run-bound, and the close message's thread lookup still duplicates #raisedThread's query. Because of that duplicate, a mutant I tried on the op='claim' filter (G5) matched two places, and my replace script refused it. A release row carries the same thread, so it would likely have been equivalent anyway.
The test uses one thread. A null read as "any thread" fails in any thread, so one is enough to kill M5 and M6. A second thread would add nothing.

What I ran and what I took from receipts

I ran, as single files on the candidate with TMPDIR set to scratch and Docker disabled, all with 0 fail and 0 skipped:

Test file	Result
bus approval-binding	6/6
bus single-use	12/12
bus broker	16/16
bus decision-route	5/5
bus decision-close	8/8
bus decisions	7/7
bus agents	11/11
bus messaging	13/13
bus threads	14/14
bus message-citation	3/3
bus end-launch	7/7
bus chief-of-staff	13/13
bus requirements	3/3
bus launch-notice	7/7

I also ran mutants of my own on broker.mjs, written without reading mutants.py. Each ran against approval-binding, single-use and broker. The tree matched the manifest again afterwards.

Mutant	approval-binding	single-use	broker
G1: `#checkAuthority` reads a null raised thread as the run's thread	1 fail (the pre-121 test)	0	0
G2: supersede reads a null raised thread as the run's thread	1 fail (the pre-121 test)	0	0
G3: supersede drops the thread check	2 fail	0	0
G4: `#checkAuthority` skips the thread check when the raised thread is null	1 fail	0	0
G5: `#raisedThread` drops `op='claim'`	not run (note 1)

With --test-reporter=spec, the pre-121 test is the one failing under G1 and G2.

From Dewey's receipts, not rerun by me:

M1 to M6, 6 of 6 killed (mutants-run.log), and the first run with M6 surviving (mutants-run-first.log);
the gate from 23:45:35Z to 23:49:40Z, rc 0 (gate-run.log): bus 265, cli 209, harness 101, plugins 28, seat 135, tasks 97, webui 113, and the ten scripts/test-*.sh.

I took no slot.

4.1 KiB Raw Permalink Blame History