## Filbert review, row 149 round 4: approve Candidate manifest `6b4af9c2685be260b7d874a831fd869690bbd067f7f5be45cc5b62a4c2cfcc96` (21 paths), build.patch `df0fec543dba4627...`. Dewey built on `ac55e84fe`; I reviewed and ran on `0f715a054` plus build.patch, the tree Sage's gate and the landing use. The patch applies cleanly there, all 21 manifest hashes match, and `git log ac55e84fe..0f715a054` on the 21 paths is empty. ### Round 3 finding (28913): resolved Round 3 found the relaunched merge-gate run had `land_work` but no turn to call it on, because the approval went to the raising run. Round 4 closes it in the role texts: - `roles/cto.md:15-17`: the cto's message to the chief of staff names `raised_by_role`, the decision id and the task reference (the decision's `authorization.target`). `#decisionView` returns `authorization.target` from the decision context, so the cto can read it. - `roles/chief-of-staff.md:49-53`: once `launch` succeeds, the chief of staff sends the instance one message naming the task reference and the decision id, with the reason (a run takes a turn only on a message it receives). - `roles/merge-gate.md:29-39`: the later run lands on that message, and a `decision-consumed` refusal, in the `land_work` reply or the later RESULT, is reported as landed with no second land or raise. The "decision-consumed means landed" reading holds in the broker: only an `action.allowed` event with a non-`decision.raise` operation spends a decision (`#spent`), a decision is consumed only by its own action (decision-mismatch otherwise), MERGE `action.allowed` events are reserved, and `recordLand` is the only MERGE consumer. The `authorize()` callers (runtime role.launch, tasks verbs) never spend a merge decision. `packages/business/tests/workflow-roles.test.mjs` asserts each new sentence. ### Checked and correct - The `raise_decision` domain param (brief section "Security-reviewer and merge-gate roles, and proactive contracts") is unchanged since round 3, where I verified it and ran raise-domain.test.mjs. - merge-gate.json has no `message.send`, so the runner's RESULT reply to the chief of staff's message is refused. `packages/business/README.md:186-189` already documents this for any role without `message.send`; pre-existing, not a finding. - No stale copy of the old merge-gate wording remains; bus README mentions of decision-consumed are consistent. ### Doc-only, follow-up (decision 137: .md, no test reads it) a. `packages/business/README.md:194-196` still says merge-gate "lands once the technical arbiter resolves it", without the relaunch and the chief of staff's message. b. A business must list its merge-gate instance in `launch.instances` for the chief of staff to relaunch it (`packages/business/src/business.mjs:128-132`, `packages/harness/src/tools.mjs:115-118`). Dewey recorded this already; the README should say it. This is a doc gap, not a silent failure. If the instance isn't listed, the chief of staff's `launch` schema offers only the listed instances, and the host refuses an unlisted one `instance-not-listed` (`packages/cli/src/launcher.mjs:198`, tested at `packages/cli/tests/launcher.test.mjs:261-262`). A business with no launch block is refused `launch-not-configured` (`launcher.mjs:197`) and gives the chief of staff no `launch` tool, so the human launched the raising run and relaunches it too. `roles/chief-of-staff.md:36-37` makes the chief of staff report every refusal with its exact text, a message to an unlaunchable instance comes back `launchable: false` (`packages/bus/src/broker.mjs:2326`), and the approved decision stays unspent and visible. Adding the instances is Jason's business-file edit and out of scope for this row (brief, "Adding instances to any business"). ### Ran by me Slot from sage-0753, on 0f715a054 plus build.patch; busy check CLEAR first. - Singles, 16:33:06Z to 16:33:12Z: 21 files run one at a time (all of packages/business/tests, harness bundle and raise-domain, bus workflow-roles and land), 162/162 pass, 0 skipped, manifest checked before and after. - Mutants, 16:33:12Z: my own 8 text mutants on the round 4 sentences, each removed or changed in the role file and restored with a hash check. Control passes; 8 of 8 caught by workflow-roles.test.mjs test 7. They cover: the cto naming the decision id and task reference; the chief of staff's launch condition, its send_message to the instance, and the reason; merge-gate's turn on that message; decision-consumed in the reply or the later RESULT; reporting it landed without another land or raise; and "means the landing already happened". ### Not mine Dewey's round 4 receipts (sage-0712 slot, agents/dewey/work/queue-149/r4/): singles 15:07:57Z to 15:09:09Z, 39 files pass; mutants 15:09:13Z to 15:09:19Z, control passes, 25 of 25 caught.