Files
jason.woltjeandClaude Opus 5.5 c740f56ee6 agents: Dewey row 139 round 2 packet, Jason's ruling Q169 (#1633)
Candidate manifest 7a1fcae1 (patch 7a29d911) on 5661bd233. Only the chief of
staff, or a decision the human resolved through the CLI, ends or revokes the
assistant; a revoke of it is a hard wait. PRD 1.6 text in PRD-1.6.md for Mos.
Gate 14/14 rc=0 and mutants m1-m9 killed under slot sage-0533. SMOKE.md plan,
not run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-16 14:11:43 -05:00

6.3 KiB

Row 139 live smoke plan (#1633): not run

Written by Dewey for Sage (sage-0521). It runs only on Mos's go, and only from the tester path: scripts/mosaic ... --tester, with every talk text starting [mos test]. Dewey doesn't run it. Target: business "stack", project stack, spec/north-star.md at Jason's init commit ae0b17c, which Mos read read-only.

Preconditions (each checked by Mos, read-only)

  1. Row 139 has landed and the live tree contains it. Since row 85, the bus runs from copies/. Before a copy and re-pin that includes 139, the live broker still has the old GATED, and step A would route to Jason. That would be a precondition failure, not a 139 failure. Check with ps that the bus and role sessions run from the new copy.
  2. bus.tester is true for the business.
  3. The live business's arbiters.delivery names a running instance other than the raiser in step A. The example file has delivery pm, technical cto and launch.by chief. The plan below assumes chief raises and pm arbitrates. If the live file differs, swap the names.
  4. That arbiter's session was launched after the re-pin. Only an instance the business names as an arbiter gets the resolve_decision tool (packages/harness/src/tools.mjs:209), and the tool list is fixed at launch.
  5. The read_spec tool, called with project stack, returns a file commit with confirmed: true. Step A asks chief to report it, so Mos sees the commit before anything is raised.

Steps

A. A cited gated raise goes to the delivery arbiter (REQ-DEC-2):

scripts/mosaic talk chief "[mos test] row 139 smoke, routing only. Call read_spec for project stack and tell me the file commit and whether it is confirmed. Then raise a non-blocking decision: action policy.change, project stack, spec_path spec/north-star.md, spec_commit that file commit, options yes/no, recommendation no, question '[mos test] row 139 routing smoke; no policy changes; resolve no'. Reply with the decision id." --tester --follow
scripts/mosaic trail <decision-id> --tester --json
  • Pass: the trail shows gated policy.change → pm, or the live delivery arbiter, with the cited spec_path and spec_commit. The decision is not in Jason's mosaic inbox.
  • Then: scripts/mosaic talk pm "[mos test] resolve decision <id> with no, note 'row 139 smoke'" --tester --follow.
  • Pass: the trail shows the decision resolved no by pm, via broker.

B. A cited hard wait still goes to Jason (REQ-DEC-2, REQ-WAIT-1):

scripts/mosaic talk chief "[mos test] row 139 smoke. Raise a non-blocking decision: action network.expose, the same project, spec_path and spec_commit as before, options yes/no, recommendation no, question '[mos test] row 139 hard-wait smoke; nothing is exposed; Jason resolves no'. Reply with the decision id." --tester --follow
scripts/mosaic trail <decision-id> --tester --json
  • Pass: the trail shows gated network.expose → human, citation recorded, and the decision is in Jason's mosaic inbox.
  • Non-blocking, so per REQ-DEC-4 it goes to the daily digest, not a Discord DM.
  • This puts one test item in Jason's inbox. The step needs Jason's agreement beforehand, and Jason resolves it: mosaic decide <id> no --note "row 139 smoke".
  • If pm's resolve_decision on this id is tried, it must refuse human-required. That attempt is optional and changes nothing.

C. Optional refusal, nothing stored: ask chief to raise policy.change citing a made-up 40-hex commit.

  • Pass: chief reports stale-spec (broker.mjs:996 compares the cited commit to the spec file's current commit, so any other 40-hex value fails there), and no new decision appears in trail or the inbox.
  • The bus suite already covers the stale and unconfirmed cases. Run C only if Mos wants live evidence.

D. Optional, round 2 (Jason's ruling Q169, sage-0528): a cited revoke of the assistant goes to Jason. Ask chief to raise a non-blocking, cited role.revoke with target assistant, recommendation no, question [mos test] row 139 assistant-revoke smoke; nothing is revoked; Jason resolves no.

  • Pass: gated role.revoke → human, in Jason's inbox. pm's resolve_decision on it refuses human-required.
  • Like B, this puts a test item in Jason's inbox, so it needs Jason's agreement, and Jason resolves it no. Even a yes stops nothing until row 155 (#1649) lands (see finding 3).
  • Don't ask chief to end the assistant to test Q169's other half. Under 139 the broker lets the chief's end through the protection and then refuses not-held, so it stops nothing. The bus and harness suites cover that refusal. Once row 155 lands, the same request ends Mos's run.

I left out an uncited control (uncited policy.change → Jason). That is the existing route; the suite covers it, and running it would add a second test item to Jason's inbox.

Evidence

Mos keeps, for each step: the talk --follow output, trail --json for each decision id, and, for step B, the mosaic inbox line. Neither decision is followed by an action: policy.change and network.expose have no executor on the bus.

Findings from writing this plan and round 2, for Sage

  1. The harness raise tool has no domain field. packages/harness/src/tools.mjs:195-208 lists none, and decision.raise defaults domain to delivery (broker.mjs:1204). So a live agent's raise, cross-role or cited gated, always goes to the delivery arbiter. The technical arbiter is reachable only through the broker API, which the bus tests use. REQ-ROLE-5 has merge-gate raise in the technical domain. Row 149 adds the field (sage-0528). Not in row 139's files.
  2. If the live delivery arbiter is the raiser, step A goes to Jason through the existing self-route fallback. That is correct behaviour, not a failure. Precondition 3 avoids it.
  3. A role.revoke of the assistant, or the chief's end of it, can't execute yet. Since row 121 the assistant's run holds a thread claim (thread_claims), not a role claim. decision.raise records holderRun as #holder(...)?.holder_run ?? null, which is null. #checkAuthority compares it with #holder(...)?.holder_run, which is undefined, so a cited revoke refuses decision-mismatch. With no role claim it would refuse not-held next. The chief's end refuses not-held. This predates 139. Under Q169, 139 decides who may remove the assistant, and row 155 (#1649) makes the removal execute (sage-0528).