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
Row 84 round 1 (#1578), Filbert: approve.
Candidate manifest SHA-256: f72730debe864edc9cdd9631482de98da41d886df65b5653a51d835d43de0a08. Base: ac6b56ee. Packet: agents/researcher/work/queue-84/r1/ (7198d336). This answers request 28173.
I rebuilt the candidate in my own worktree at ac6b56ee and applied build.patch. All four manifest hashes match. Nothing under packages/business/ or roles/ changed from ac6b56ee to the current origin/refactor, so the base hasn't drifted.
Role file: roles/chief-of-staff.json matches decision 104's list exactly. Tools are read, grep, find, ls. Network is api-only. withinRole holds only message.send, and crossRole and credentials are both empty. The only other keys are roleVersion, name, title and contract, and none of them grants anything. The file grants nothing beyond the approved list, so nothing needs to go back to Jason.
Static findings:
- The contract follows the M1 draft at
a3d17005. It covers all four draft points: requests go to the PM as messages, rulings are relayed verbatim, it never resolves a decision for Jason, and it never holds or imitates human authority. It also adds reporting to Jason (refusals with their exact text), the line that only the human stops a run, and protocol lines in the style of pm.md. All of these restrict or describe; none of them grants anything. - The tests pin the policy, not just the loader. "the shipped file is exactly decision 104's list" compares the raw JSON, minus
title, withdeepEqual, so an added tool, verb or credential fails it. The classify loop checks every entry inACTIONS, and onlymessage.sendcomes outwithin. The launch-by and credential/tracker refusals assert on exact messages. - The limits-grant test asserts that the grant has no effect rather than that it is refused, which follows Sage's ruling.
resolve.mjslines 64-68 only filter the definition's lists, so the assertion matches the code. Per BUILD.md, M09 (limits union) dies on this test alone, and 3resolve.test.mjstests kill it too. - The README instance entry (
mos, no tracker, no credentials, not thelaunch.byinstance) matches the tests' refusals.
Notes, not blocking:
- N1. That test's comment repeats itself, as the request says: "limits.authority only narrows, so the grant has no effect" and then "limits only narrow (resolve.mjs), so the grant has no effect". One sentence is enough.
- N2.
chief-of-staff.mdis the only file inroles/*.mdthat names Jason. The others say "the human", and its own opening line says "the human's main agent" before it switches to "Jason". The brief uses Jason's name, so this is a wording choice. It does tie a business-generic role definition to one business. - N3. The Protocol line "addressed to a role, not a person" sits next to duties that report to Jason. The bus accepts
to: 'human'(broker.mjs:788), and gated decisions go to the human, so the two are compatible, but the wording reads as a contradiction. pm.md has the same line. "Raise it to Jason" names no mechanism for a read-only role either. - N4. The classify test repeats three
within/gatedassertions after a loop that already covers them. Harmless.
My review is static. I ran no suites, mutants or queue-commit.sh. Researcher's packet reports business 67/0, all nine scripts/test-*.sh at rc 0, and M01-M09 killed. Sage's landing gate rerun is still required.