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.
3.3 KiB
Filbert review: row 112 round 1 (#1606): changes
Candidate manifest sha256 ac34ebd094fb3bb17d1dd14b8f6e0ca53d661e176ef42463dd5f5c8ecf683d32 (5 files), as named in comment 28376. I rebuilt it in my own worktree at BASE 96656dd21 with build.patch from packet dbf72a2a3. All 5 hashes match, git diff --check is clean, no manifest path has drifted from 96656dd21 to HEAD, and the patch's added lines have no dashes, bidi or control characters.
The brief, item by item
- Tool text.
recommendationnow says exactly one option key, as written, with nothing added, and that the reason goes inquestion.questionasks for the reason.approvalChoicenames theyesdefault and says to pass it when no key isyes.tools.test.mjsasserts each of these. - Broker. The shared line is split. Duplicate keys refuse
invalid-optionsfirst, a recommendation miss then refusesinvalid-recommendation, andinvalid-approval-choiceis unchanged. Count and per-option checks still run before both. There is no schema change. - README. See C1.
- Tests. The new broker test covers
"yes: it matches the direction",maybeand a missing recommendation (allinvalid-recommendation), duplicate keys with a good and a bad recommendation (bothinvalid-options), and a single option (invalid-options). Decision and message counts don't change and the inbox stays empty. A plainyesis accepted and stored asyes. The existing duplicate-key case is unchanged. - Mutants. I reran m1 (shared line restored) and m2 (recommendation check before the duplicate check) from
mutants.pyagainstbroker.test.mjsalone. Each gave 15 pass and 1 fail on the new test. I restored the file each time and rechecked all 5 hashes.
Change requested
-
C1. The
invalid-optionsrow names the wrong code for a malformed option. The row says an option "that isn't{key,text}" refusesinvalid-options. In the broker,keys(o,['key','text'],['key','text'])runs first and refusesinvalid-requestfor that case. I ran a probe against the rebuilt broker withrecommendation: 'yes':options refusal an option with an extra notefieldinvalid-requestan option with no textinvalid-requesta bare string 'yes'as an optioninvalid-requestkey Yes!invalid-optionsempty text invalid-optionsone option invalid-optionsThis row exists so a caller can tell which field to fix, so it shouldn't name a code the broker doesn't return. The lead-in, "each refusal names one field", also doesn't hold for this case. Fix the README text, not the broker. For example: "fewer than 2 or more than 9 options, an option key that isn't a valid id, empty or over-long text, or duplicate keys", plus a sentence saying that an option that isn't exactly
{key,text}refusesinvalid-request. Widening the broker's codes is out of scope under the brief. No test is needed for a README fix.
What I ran (single files, no slot)
bus: broker 16/16, decisions 7/7, review 8/8. harness: tools 11/11. I also ran the mutant reruns and the option probe described above. I didn't rerun the full gate and relied on gate-run.log for it: 14 packages and 9 scripts all pass, GATE_PASSED. The worktree is removed and no process is left in it.
Verdict: changes (C1, README only).