Files

1 line
3.8 KiB
JSON

{"body":"Filbert (048f3c63), row 119 (#1613) round 1 review. Request: comment 28521. Candidate manifest sha256 8ebb56b55d274c36f8e6e4d617c37e260bbc2a11fa3b05de6299df34e54ac388 (agents/researcher/work/queue-119/candidate-manifest.sha256, packet commit 58643299e), base c6570f142.\n\n**Verdict: changes** (one finding, below).\n\n## What I ran\n\n- Rebuilt in my own worktree: base c6570f142 plus `row119.patch`. All 22 manifest hashes match, `git diff --check` is clean, no candidate path drifted between c6570f142 and HEAD, and the added lines carry no smart quotes, dashes or control characters.\n- Single test files in that worktree: business `assistant` 7/7, `chief-of-staff` 10/10, `role` 13/13, `resolve` 10/10; harness `tools` 13/13. I didn't run the full suites or the mutants. The gate and mutant figures come from Researcher's packet.\n\n## Finding (blocking)\n\n**F1. `roles/assistant.md` lets the assistant relay rulings to any role.** The third duty reads: \"Relay each ruling the user gives verbatim to the role it concerns.\" That sends messages to roles other than the chief of staff, which contradicts:\n\n- REQ-ASSIST-1: the assistant \"passes work for the organization to the chief of staff. It doesn't direct other agents\";\n- REQ-ASSIST-2 and the brief's next step (#1614): the assistant may send only to the user and the chief of staff.\n\nThe line is carried over word for word from the old `chief-of-staff.md` (base lines 15-16, \"Relay each ruling Jason gives verbatim to the role it concerns\"). The broker limit lands in row 120, so for now the contract is the only thing holding the assistant to the chief of staff.\n\nFix: relay each ruling verbatim to the chief of staff, saying whose ruling it is and which role it concerns. A pin in `assistant.test.mjs` would stop it coming back, for example asserting that the contract names no message recipient other than `chief-of-staff` and the user. m12 currently catches only the \"direct other agents\" wording.\n\nDecision 137 check: `grep -rlF assistant.md packages/*/tests scripts/test-*.sh` returns `packages/business/tests/assistant.test.mjs`. The contract is read by a test, so this isn't doc-only.\n\n## Checked and fine\n\n- **Mutant survivors m2c, m2d, m2e.** Researcher's reasoning holds. At `packages/business/src/resolve.mjs:74` `launch` is set only when `business.launch.by === instance` and the role holds `role.launch`. Lines 76-77 strip `role.launch` from every other instance. `broker.mjs:305` gates `role.launch` unless `launch.by === s.role`. A PM role file that regains `role.launch` therefore resolves exactly as before in the harness tools, harness bundle and webui reads tests. The role file itself is pinned by m2a and m2b (rc 1 in `mutants/`), so the survivors are a non-launcher edit with no effective change.\n- **Role JSON.** The assistant holds `message.send` only, with read-only tools, no credentials and no crossRole action. The chief of staff gains `role.launch` (decision 139) and the PM drops it (REQ-LAUNCH-1). The chief's contract claim of a broker `launch` tool matches `packages/harness/src/tools.mjs:95`, which adds the tool only when the resolved record has a launch block.\n- **Org file.** `build.md` gives the `chief` and `assistant` entries and the `launch.by` change as instructions for Jason, and no candidate file touches `~/.config/mosaic-dev/businesses/` (decision 144). The one-window landing order is correct. Once re-pinned, a file still naming `launch.by: \"pm\"` fails to load because `pm.json` no longer holds `role.launch`. Before the re-pin, the pinned chief role can't be named as the launcher.\n- `chief-of-staff.md` and `pm.md` match REQ-COS-1 and decision 140: no user-facing duty, and the PM asks the chief for sessions. README and example follow.\n\nResearcher's noted follow-up (`scripts/test-task.sh` shipped-roles loop) is fine left out of this row.\n"}