stack/agents/researcher/work/queue-84/r1/BUILD.md

Row 84 (#1578) build, round 1: chief-of-staff role file, contract and tests

Phase B is done. The gate passed, all nine mutants were killed, and the baseline for M09 was recorded. The packet is ready for the review request. Nothing is committed, the queue row is still in-progress (rev 874, op researcher-h84-start-20261013), and nothing was written to Gitea.

Identity

• Row 84: M1, chief-of-staff role file, contract and tests. Brief: docs/plans/2026-10-12_m1-chief-of-staff-role.md, section "M1 chief-of-staff role file, contract and tests", blob da2a7b7e791e750642383a3d99cc1ce51a2b25ae (not edited).
• Owner: researcher (queue owner, authoritative per Sage's ruling 3). Reviewers: Darkwing and Filbert. Gate: Sage. Dispatch: Mos, 2026-10-13T00:06Z, via Sage (decisions 122 and 129).
• Brief owner line: the brief still says Owner: Rocko and names agents/rocko/work/queue-<row>/. The brief is stale on both. This packet is under agents/researcher/work/queue-84/r1/ per the queue owner. The brief is not edited.
• BASE: ac6b56ee55278077d61f39e6ca42513725427154 (see base.txt). Re-pinned in Phase B from 58a3766d480a59de195bdd75f3f4ad4e41e21f5d.
• Base drift check: git diff --stat 58a3766d4 ac6b56ee5 -- roles/ packages/business/ is empty, and packages/business/src/resolve.mjs is unchanged between the two bases. No candidate path drifted, so the Phase A results carry over, and the gate was run again on the new base anyway.
• Worktree: .claude/worktrees/agent-a1044a9b545fa3a36, detached at BASE. Changes uncommitted. node_modules is a symlink to the canonical root node_modules; no npm install was run.
• Rebase steps: git stash push -u -m r84-phaseB-20261013 (entry 0638f67ec05096f11dbebe73de196e4567e56766), git checkout --detach ac6b56ee5, git stash apply by SHA (not pop), then the stash entry was dropped. The restored test file matches its stashed copy by sha256. Stamp about 14:50 UTC.

Changes

Path	New or modified	What
roles/chief-of-staff.json	new	the role file, roleVersion 2
roles/chief-of-staff.md	new	the duty contract, in the style of roles/pm.md
packages/business/tests/chief-of-staff.test.mjs	new	7 tests, fixture business in a temp directory
packages/business/README.md	modified	new section "Chief-of-staff instance", placed before "Project file", with the instance entry

No other file is touched. vocabulary.mjs, resolve.mjs, role.mjs, business.mjs and vars.mjs are unchanged (ruling 1: no src change). Nothing writes Jason's business file. resolve.mjs was edited twice during the M09 baseline (apply, then restore) and was confirmed back at its pinned hash; see below.

Role file against decision 104, line by line

Decision 104 (lead decisions, lines 2288 to 2313) and the role file:

Decision 104 says	roles/chief-of-staff.json	Match
role named chief-of-staff	"name": "chief-of-staff"	yes
tools read, grep, find, ls	"tools": ["read", "grep", "find", "ls"]	yes, exact, in order
network api-only	"network": "api-only"	yes
authority.withinRole message.send only	"withinRole": ["message.send"]	yes
no crossRole authority	"crossRole": []	yes
no credentials	"credentials": []	yes
every other vocabulary action stays gated, including task.create and role.launch	no other action listed; test checks all of ACTIONS through classify	yes
contract roles/chief-of-staff.md	"contract": "chief-of-staff.md"	yes

Additional keys in the file, not in decision 104's list: roleVersion (2, the version the brief names), title ("Chief of staff"), which the brief asks for ("a title"). Neither grants anything.

Contract (roles/chief-of-staff.md) against decision 104's four points:

• Sends Jason's requests to the PM as messages and asks the PM for work: Duties, first two bullets.
• Relays Jason's rulings verbatim: Duties, third bullet ("verbatim").
• Never resolves a decision for Jason: Authority, second paragraph.
• Never holds or imitates human authority, never routes around a refusal: Authority, first and second paragraphs.
• The contract names the role, not the persona (ruling 2). The word "Mos" does not occur in the file. The instance mos appears only in the README and in the test fixture.

Tests (packages/business/tests/chief-of-staff.test.mjs)

Seven tests, each against a fixture business written to a temp directory (businessDoc from helpers.mjs, plus one chief instance):

1. The role file loads and resolves through loadBusiness.
2. The shipped file equals decision 104's list exactly (every key except title, deep-equal). A widened file fails here.
3. The resolved record's limits and credentials equal the list.
4. classify returns within for message.send and gated for every other action in ACTIONS, including task.create and role.launch.
5. A business that grants the instance task.create and role.launch through limits.authority gets no effect: both stay gated and launch is null (ruling 1; limits only narrow, resolve.mjs lines 64 to 68).
6. A launch block whose by is the chief instance is refused, because the role holds no role.launch.
7. The instance cannot take credential references or a tracker block, and the loader refuses both.

README section

The entry, as Jason would add it under roles in his business file (ruling 2 and decision 116):

"mos": { "definition": "chief-of-staff", "holder": "mos" }

No launch block, no tracker, no credentials. The section says the stack never writes the business file.

Gate (Phase B, on ac6b56ee5, worktree root, UTC stamps from date -u)

Output files are in out/. Every step was gated on its exit status.

• Step 1, business suite: DOCKER_HOST=unix:///nonexistent.sock node --test on the eight packages/business/tests/*.test.mjs files, listed explicitly. Stamp 14:51:04 to 14:51:06. rc 0. 67 tests, 67 pass, 0 fail. All seven chief-of-staff tests ran and passed. Output: out/step1-business.txt. (The glob form was not used; the explicit list is the same set of eight files, helpers.mjs is not a test.)
• Step 2, the nine scripts/test-*.sh, sequential. Only test-task.sh got DOCKER_HOST=unix:///nonexistent.sock.

Script	Stamp (UTC)	rc
test-config.sh	14:51:22 to 14:51:24	0
test-auth.sh	14:51:25 to 14:51:26	0
test-conductor.sh	14:51:27 to 14:51:33	0
test-discord.sh	14:51:34 to 14:51:40	0
test-extension-package.sh	14:51:42 to 14:51:43	0
test-foundation.sh	14:51:44 to 14:52:23	0
test-queue.sh	14:52:24 to 14:52:44	0
test-release.sh	14:52:46 to 14:52:57	0
test-task.sh (dead DOCKER_HOST)	14:52:58 to 14:53:00	0

test-task.sh finished in about 2 seconds with the dead Docker host. I did not check whether it skipped Docker-dependent cases, so its rc 0 shows only that it exits clean.

Output: out/step2-test-*.txt.

Mutants

Runner: mutants.py (in this packet), run as python3 -I mutants.py <worktree> <packet>, no Docker variable. Nine mutants: M01 to M08 on roles/chief-of-staff.json, M09 on packages/business/src/resolve.mjs. Each has one exact-once anchor (all nine were checked before the first run), runs node --test packages/business/tests/chief-of-staff.test.mjs in its own process group under a 180 s timeout, and is restored in a finally. The candidate manifest is checked before the baseline and after the last restore; resolve.mjs is checked against its pinned hash.

Runner corrections made before the first run (Phase B):

• The mutant suite no longer sets DOCKER_HOST. The business suite does not use Docker, and Sage's rule is that only test-task.sh gets the dead host.
• The leftover check skips the runner and its parent processes. The first version would have counted the runner itself, because it starts in the worktree.

Run: stamp 14:53:36 to 14:53:37 UTC. Runner rc 0. Baseline green. Output: out/baseline.log, out/M01.log to out/M09.log, out/summary.txt.

Id	Change	Result	Failing tests (observed)
M01	tools gains bash	killed	shipped-file equality; resolved-record match
M02	tools gains write	killed	shipped-file equality; resolved-record match
M03	network api-only becomes open	killed	shipped-file equality; resolved-record match
M04	withinRole gains role.launch	killed	shipped-file equality; "a launch block whose by is the chief-of-staff instance is refused"
M05	withinRole gains task.create	killed	shipped-file equality; resolved-record match; classify test ("message.send is within role and every other action is gated"); limits-grant test
M06	crossRole gains task.scope.change	killed	shipped-file equality; resolved-record match; classify test
M07	credentials gains a gitea entry	killed	seven tests fail. The fixture load refuses with BusinessError ("roles.chief.credentials must reference exactly the services its role definition needs"), and the equality and classify tests fail on their assertions. Not an assertion-only kill.
M08	withinRole loses message.send	killed	shipped-file equality; resolved-record match; classify test; limits-grant test
M09	resolve.mjs: the limits.authority line becomes a union, so a limits grant widens withinRole	killed	limits-grant test only ("a business grant of a gated action through limits does not widen the role")

Result: 9 of 9 killed. Each kill is a failing test. Eight are assertion failures; M07 also fails through the loader refusal shown above. None is a timeout or a runner crash.

M09 specifically

• The new limits-grant test kills M09. The actual value is withinRole: ['message.send', 'task.create'], where the test expects ['message.send'].
• The pinned hash of resolve.mjs (c50340af650aaa2d0eb15224e823525ba942a91f475ed62bd7e7ad42055f182b) matched before the baseline, after the M09 restore, and at the end.

Baseline M09 (run after the mutants, to check whether the new test is the only catch): stamp 14:53:58 to 14:54:08 UTC.

• The new test file was moved out of packages/business/tests/, M09 was applied to resolve.mjs by exact replacement, and the other eight business test files were run. Output: out/baseline-M09.log.
• Result: rc 1, 57 pass, 3 fail.
• baseline M09: killed by existing tests in packages/business/tests/resolve.test.mjs:
  • "limits narrow the definition and never widen it" (withinRole gains message.send, task.update.assigned, task.close).
  • "limits.authority without role.launch leaves the launcher with no launch block" (a gated action classifies as within).
  • "limits.authority narrows cross-role actions too" (withinRole gains task.create, task.assign, task.reassign).
• So the new test is not the only thing that catches a widening through limits. The existing resolver tests already catch M09. The new test is a second, row-specific kill that pins the decision 104 outcome for the chief instance.
• After the baseline, resolve.mjs was restored by reverse replacement and checked at c50340af.... The test file was moved back and the manifest was checked again: all four entries OK.

Candidate manifest and patch

• candidate-manifest.sha256: four repo-relative entries from files.txt, checked with sha256sum -c from the worktree root (all OK). Entries: roles/chief-of-staff.json 9a29c8ff..., roles/chief-of-staff.md d257bc27..., packages/business/tests/chief-of-staff.test.mjs c4198b67..., packages/business/README.md 875777f3....
• Manifest sha256: f72730debe864edc9cdd9631482de98da41d886df65b5653a51d835d43de0a08.
• build.patch: git add -N on the three new files, then git diff --binary ac6b56ee5 -- <the four paths>. Intent-to-add entries were reset afterwards. 239 lines, four diff --git headers.
• Build patch sha256: 0989637709e8a5dcaba31c88768571837b2276a0f16de49f6340058bcbea94f2.
• Patch check: git apply --index --check and git apply --index on a git archive ac6b56ee5 copy in a scratch directory (removed afterwards). The four resulting files hash to the manifest values.

Packet files

• base.txt: ac6b56ee55278077d61f39e6ca42513725427154.
• files.txt: unchanged, four paths.
• mutants.py: nine mutants, runner corrections above.
• candidate-manifest.sha256, build.patch: new in Phase B.
• out/: step 1, step 2, mutant, and baseline logs. Not in the manifest.

Open items

• The brief's Owner line (Rocko) and its agents/rocko/ path are stale. Recorded here; the brief is not edited.
• The brief's README section says "the exact instance entry for Jason's business file". The entry above is that entry, using mos (decision 116).
• Not done, by instruction: no commit, no queue move, no Gitea or Vikunja write, no push.
• Process check after the runs: no node, python or test process of this worktree is left. The cwd scan showed only the scan's own transient subshells, which had already exited.