Files

6.3 KiB

Filbert review, row 141 round 1: approve.

Candidate manifest d474b330d7e31dc7315ed4e5619840dd38cfa85b7321e28b67f3c600180b4e3b (packet agents/darkwing/work/queue-141/, request 28834, build.patch bb036c6d).

Rebuild (run by me)

  • Detached worktree at base 18aee8fa1, with git apply --index of build.patch. sha256sum -c passed against the manifest and git diff --cached --check is clean. The patch touches 26 files, +862 -52, and the paths match the manifest.
  • No en or em dash or curly quote on any added line.
  • Base drift, for the landing: row 148 landed after the candidate's base, as d4ea7e5a6, and it touches 2 of the 26 paths: packages/bus/README.md (+11) and packages/bus/src/broker.mjs (+43 -1). Those 2 are the only manifest paths that differ between 18aee8fa1 and HEAD 625afe15f.
    • I read row 148's broker change. It adds the human-only PROJECT_FILE_VERBS and #requestProjectFile, which are not in ACTIONS and don't touch message.send or the authority path, so I found no semantic interaction with names.
    • git apply --check of build.patch on 625afe15f passes.
    • My tests ran on 18aee8fa1, not on 625afe15f, so the landing gate should run the whole suite on the new base.

Sage's question: does the widened pin in project-runtime.test.mjs still hold?

Yes. The pin now allows import { ID_PATTERN } from '../../business/src/vocabulary.mjs'; in broker.mjs and asserts that vocabulary.mjs contains no import.

  • The sandbox loads no new file. vocabulary.mjs is already in RUNNER_FILES (packages/seat/src/sandbox.mjs:50-64), and harness/src/tools.mjs already imports it.
  • The pin's own regexes have two gaps: ^import .*;$ misses a multi-line import, and \bimport\b misses export * from. packages/seat/tests/sandbox.test.mjs:35-44 closes both. It walks every from and import( specifier from RUNNER and SOURCES and asserts that the set it reaches equals RUNNER_FILES exactly.
  • That walk misses a bare side-effect import './x', and the new \bimport\b assertion catches it.
  • The two tests together hold the boundary. This is the same shape as row 137's landing.mjs precedent.

What ships, against the brief

  • Table and column. instance_names(seq, at, business, instance, name, by) is append-only with the usual three triggers. messages.to_name is added, and to_role stays the instance key, so delivery and claims are unchanged. schema.sql and migrations/3f-3g.sql carry the same DDL. store.mjs moves to 3g with the new SCHEMA_SHA256, a 3f to 3g step, and instance_names in timedTables.
  • Uniqueness. instance_names_unique refuses an insert when another instance of the business currently holds the name (its latest row). A rename frees the old name. The broker refuses name-is-instance for an instance key, human or tester, name-is-role for any definition the business has, name-taken, and an ID_PATTERN miss as invalid-request.
  • message.send. A name resolves only when to is not an instance key, human, tester or a definition, so a key or a role always wins. The INSERT records to_name only for a send by name. Every later check uses the resolved key. A name whose instance has left the business resolves to a missing key and refuses unknown-role, which fails closed.
  • Writer. Row 139 landed first (63c82f1c4), so this row carries the grant, as the brief's row 139 section says. roles/chief-of-staff.json gains instance.name within-role. The broker accepts an agent's name.set only when that action is classed within-role, and the write goes through consumeAuthority, so the holder check applies and a reader is refused read-only. instance.name is in ROUTED and not in GATED_ONLY, under REQ-MSG-2 in PRD 1.5 (docs/prd/mosaic-stack.md:382-388).
  • CLI. mosaic name <instance> <name> and mosaic names [--json] are in USAGE, the README and the dispatcher. The argument count is checked before any call.
  • Harness. The send_message to description now says "its name". The chief's untyped list is ["instance.name"] until row 155, as BUILD.md says. The landing window should expect that.
  • Tests the brief asks for, all present.
    • Send by name delivers to the instance and records both: bus names.test.mjs and cli names.test.mjs.
    • Duplicate, instance-key and role-name refusals.
    • An agent's write refusal: a role without the grant, a cross-role holder, a reader and the tester.
    • The migration on a copy of a 3f store built from the pinned 3f schema (fixture sha256 472cbcd0, the old SCHEMA_SHA256). It checks every old row and column and leaves the copy byte-identical.

Tests (run by me, singly, on Sage's slot, 22:26:51Z to 22:26:58Z)

All rc 0, 114 pass, 0 fail, 0 skipped:

  • bus: chief-of-staff 13, comment-migration 5, name-migration 1, names 7, project-runtime 3, schema 1, spec-migration 1, thread-migration 3.
  • business: chief-of-staff 10, hard-waits 4, role 14.
  • cli names 2, harness bundle 22 and tools 19.
  • packages/seat/tests/sandbox.test.mjs 9. It isn't changed, but I ran it because it holds the boundary for the pin.

Doc-only, follow-up (decision 137)

docs/acceptance/314.md step 10 (lines 135-145) no longer matches what ships. No test reads 314.md or docs/TOOLS.md; I checked with grep -rlF over packages//tests and scripts/test-.sh.

  1. Step 10 says docs/TOOLS.md names the new command once this row lands. The candidate doesn't touch TOOLS.md, which still has no mosaic name or mosaic names near talk (TOOLS.md:241-246).
  2. Step 10 says to run mosaic agents and then talk <name from the agents list>. formatAgents (packages/cli/src/format.mjs:52-55) prints no names, so the step should point at mosaic names.
  3. Step 10's pass line says "the trail records both the name and the instance". trail covers a task or a decision, so a plain talk message isn't on a trail. The message row does record both (to_role and to_name), and receive and --json reads show it. The step should name the read that shows it.

None of these blocks. Fixing them in the docs is enough. Showing names in agents text output would be a later code change, and the brief doesn't ask for it.

Not run by me

The full gate, Darkwing's round and its nine kills come from Darkwing's receipts in BUILD.md ("Third run" and "Fourth run").

Verdict: approve. There are no blocking findings, and the follow-up list above is doc-only.