bus: row 237 one decision, one open publish; checkPublish refuses publish-busy while another ticket holds the decision, since it is spent only at recordPublish after the push; a broker test and a socket race test with exactly one receive-pack; BUILD.md with the option chosen, M1 and three residuals (duckworth-0068 N1, #1743 )

credentials: a credential store per agent, its own git identity, pushes to a remote (row 199, #1697 )
Squash of Megavolt's 627979a17..86963d281 on origin/megavolt/row199-on-190 (base 00d4cc1f6, row 190's landing), the 37 manifest paths, build.patch 05383075, manifest 35f900fd (Duckworth approve round 1, comment 29779, rev 2540). Mutant batches 1 and 2 in agents/megavolt/work/queue-199/BUILD.md: batch 2 26 of 28 killed, M17 and M27 equivalent. docs/TOOLS.md is a 3-way merge with row 200 (9e1085816): row 199's hunk applies unchanged (patch-id d88379111e2e) and no test reads the file. Gate on 9e1085816 plus the patch: 15 package suites 2735 pass 0 fail, 10 scripts/test-*.sh suites 429 pass 0 fail (plus 156 node tests in the queue suite). Refactor moved to 76134dfde since, a brief touching no manifest path. No live change: the stack runs from copy 4429a104f until the 10-24 re-pin window.
2026-10-20 19:31:48 -05:00 · 2026-10-20 19:23:12 -05:00 · 2026-10-20 19:12:34 -05:00 · 2026-10-20 19:09:00 -05:00 · 2026-10-20 18:51:20 -05:00 · 2026-10-20 18:42:52 -05:00
277 changed files with 26353 additions and 5227 deletions
@@ -25,10 +25,15 @@ green at every step. Not production software — a proven foundation.
 1. **Root is bootstrap-only.** First-class system configuration lives at the
   repository root; everything else gets a dedicated directory (`roles/`,
   `contracts/`, `missions/`, `tasks/`, `docs/`). Do not add new files to root.
-2. **Configuration**: `~/.config/mosaic-dev/config.json` is the sole system
-   config — created only by `scripts/bootstrap.sh`, never overwritten,
-   fail-closed on any problem. Repo-scoped role authority lives in
-   `roles/*.json` (versioned, reviewed commits only).
+2. **Configuration**: each stack instance has exactly one system config. The
+   default instance's is `~/.config/mosaic-dev/config.json`. Instance NAME's
+   is `~/.config/mosaic-NAME/config.json`, and its data root carries a marker
+   that names it. `~` is the home of the OS user that runs the instance. A
+   process reads only the config `MOSAIC_CONFIG` names, or the default's when
+   that is unset. Configs are created only by
+   `scripts/bootstrap.sh [--instance NAME]`, never overwritten, fail-closed on
+   any problem. Repo-scoped role authority lives in `roles/*.json`
+   (versioned, reviewed commits only).
 3. **Secrets** never enter the repository or container images; auth is
   runtime-only (read-only mount or environment variable).
 4. **Contracts** (`contracts/`) are immutable and image-baked. Missions and
@@ -177,8 +182,8 @@ Full reference — usage, fields, exit codes, safety notes:

 ## Data map (canon)

- `~/.config/mosaic-dev/config.json` — system config (user-authored; never
-  auto-written).
+- `~/.config/mosaic-dev/config.json`, or `~/.config/mosaic-NAME/config.json`
+  per named instance: system config (user-authored; never auto-written).
 - `<dataRoot>` (from config; default `~/.mosaic-dev`):
  - `runs/` — write-once run evidence (`result.json`, snapshots, `stderr.txt`)
  - `sessions/` — pi JSONL session trees, one directory per named session
@@ -16,6 +16,17 @@ not fleet seats. Keep changes in `/mnt/storage/src/mosaic-stack`; do not modify
 | Rocko | General development, investigation, testing, and review | T3 session (Codex, gpt-6.1-sol, thread d99326cc, lead decision 122; Claude thread b84bb264 retired 2026-10-12); launcher Claude Code, Sonnet model | `agents/rocko/launch.sh` |
 | Filbert | General development, investigation, testing, and review | T3 session (Claude, Opus 5.5, thread 048f3c63, non-sandbox reviews only, lead decisions 130 and 134; Codex threads f712d8af and 50342f6a retired 2026-10-13, Claude thread 9cb9731e retired 2026-10-12); launcher Pi, `openai-codex/gpt-6-astra:low`, not to be used under R26 until it changes (lead decision 69) | `agents/filbert/launch.sh` |
 | Researcher | Source-grounded technical research and evidence | T3 session (Claude, Sonnet 5.5, thread 9bac0794, rows 97 and 98, lead decision 124); Haiku rows (71, 80, 84, 88, later 96) run as subagents Sage dispatches with model haiku, effort high and a worktree (lead decision 129); Haiku thread c98aaf4a retired 2026-10-13 unused; launcher Pi, configured Mosaic model | `agents/researcher/launch.sh` |
+| Launchpad | Builder, MVP T1 row 192 (Q175 SSO phase 1) | T3 session (Claude, Opus 5.5), started by Sage under mos-0974/0977 | none, T3 only |
+| Morgana | Builder, MVP T1 row 193 (human users and RBAC) | T3 session (Claude, Opus 5.5), started by Sage under mos-0974/0977 | none, T3 only |
+| Honker | Builder, MVP T1 row 194 (agent lifecycle) | T3 session (Claude, Opus 5.5), started by Sage under mos-0974/0977 | none, T3 only |
+| Gander | Builder, the human boundary across uids (P19 333, #1694) | T3 session (Codex, gpt-6.1-sol), started by Sage under mos-0977 | none, T3 only |
+| Herb | Builder, a second gate lane (#1695) | T3 session (Codex, gpt-6.1-sol), started by Sage under mos-0977 | none, T3 only |
+| Bushroot | Builder, retire the control board writer on 7331 (#1696) | T3 session (Claude, claude-haiku-5-5), started by Sage under mos-1008 | none, T3 only |
+| Megavolt | Builder, MVP T1 item 6 (agent credentials and git identity, #1697) | T3 session (Claude, Opus 5.5), started by Sage under mos-0974/0977 | none, T3 only |
+| Quackerjack | Builder, federation R5 and R2 (#414) | T3 session (Claude, claude-haiku-5-5), started by Sage under mos-1023 | none, T3 only |
+| Gizmoduck | Federation design (#414) and builder of FED R1 | T3 session (Claude, Opus 5.5, thread 9312a896) | none, T3 only |
+| Webby | Reviewer: Case 2 designs, rows 192 and 194 | T3 session (Claude, Opus 5.5, thread 03086006), started by Mos (mos-0981) | none, T3 only |
+| Duckworth | Reviewer: federation designs, row 193 | T3 session (Claude, Opus 5.5, thread ffceafec), started by Mos (mos-0977) | none, T3 only |
 | Sage | Project lead: coordination, review, integration; earlier DYOR strategy records retained | T3 session (Claude Code); Pi launcher `zai/glm-5.3:high` retained | `agents/sage/launch.sh` |

 Each script supports `--check` and `--fresh`. Normal launches resume the agent's
@@ -0,0 +1,8 @@
+# Bushroot
+
+Builder seat, Claude Haiku 5.5, started by Sage under mos-1008 item 2 (a low-level model under Q177) for the row
+that retires the control board writer on 7331 (#1696).
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `bushroot/*`
+branches through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,7 @@
+# Duckworth
+
+Reviewer seat, Claude Opus 5.5, started by Mos (mos-0977, thread ffceafec). Reviews federation designs and MVP T1 row 193.
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `duckworth/*` branches
+through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -1,59 +0,0 @@
-# Review: Gizmoduck federation design r2 and r2.1 (duckworth-0002)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md at head 5ad67f671 (r2.1, parent 60b9b112a, r2 parent 6925f78f0).
-DESIGN.md line numbers below are at 5ad67f671. The r2.1 diff only moves the uid to row 190b, makes R7 depend on row 190 and
-puts P19 333 on the path. I checked it and found no issue. Code at origin/refactor
-9ae8c73ac. Against duckworth-0001 (REVIEW.md, b402197ff).
-
-## Verdict: changes, B6 only
-
-B1 to B5 are resolved. r2 adds one new blocker of its own. Fixing B6 and C1 as line edits plus their
-test lines would earn approval.
-
-## r1 codes
-
- B1 resolved (3.6). The walk is the human's (human.mjs:73-88), the user CLI has its own nonce, the Console
-  parent is checked against the bus's tree (webui-service.sh:3 confirms `cli.mjs serve`), and the user id
-  binds only with a live grant. R3 has both mutants. Condition C1 below.
- B2 resolved (3.6 list, 4). `#owner`, the `#threadFor` refusal plus `message.send` being off the list (two
-  walls), the sender fields and the audit are all in. The 48 `s.human` and 41 `s.tester` line counts match.
- B3 resolved (3.5). There is one level with seven verbs. Each read has a filter, and everything else is
-  `access-refused`. The cited lines match (broker.mjs:2143-2146, :2288-2295, :2318-2322, :2331-2334,
-  :2351-2420, :1203-1207, :2398).
- B4 resolved (3.7). There are three triggers. `threadsState` (:390-393) is computed per call, so a restart
-  doesn't bypass the revocation. The launcher skips a revoked thread and SIGTERMs a running one (launcher.mjs:510-553,
-  :527, tick :133). R4 gets mutants and the new order.
- B5 resolved (R8, 5, 8, 9). Separate uids are a hard entry gate (row 190b in r2.1) with checks, and N9 is
-  folded in.
- N1 to N9 are handled where the "Changes from r1" section says.
-
-## Blocker
-
-B6. With r2's sender change, a user's thread never gets an answer. 3.5 sets `thread.send` to write
-`from_role` `user` (DESIGN.md:207). The runner answers every message with `message.send { to: m.from_role }`
-(packages/harness/src/runner.mjs:450). The broker accepts only `human`, `tester` or a role as `to`
-(broker.mjs:1862), so each reply fails `unknown-role`, and the user sees no answer. The tester needed a
-whole set of changes for the same path (row 177): `to: 'tester'` only in reply to a tester message
-(:1852-1857), `#testerThread` and `tester-thread-human` (:1864-1866), the `#checkMessaging` mapping (:1867),
-`#sender` (:627-629), and the runner's header (runner.mjs:75-78). The design names none of these for users.
-
-Fix: state the reply path. Either accept `to: 'user'` only in reply to a message from that user in that
-user's thread, with the tester's set of checks, or say the run answers `human` in the user's thread and
-why the owner's inbox then holds it. Add a runner header, like the tester's, saying the message comes from
-a granted user, is never the owner's instruction, and authorizes nothing. Add an R3 test that a thread run's
-reply reaches the user's `thread.messages`. Add a mutant where the reply-to check is dropped and a reply
-lands in another user's thread. Make R7 assert that a reply arrives, not only that the send works.
-
-## Condition (line edit)
-
-C1. "Agents can't, because the walk refuses them" (DESIGN.md:251-252) overstates it. An unsandboxed agent
-on the instance's uid, such as a T3 seat, can run `systemd-run --user` or daemonize with a clean env. Its
-process then has no agent ancestor, and the walk passes. That is the same hole the owner's human proof
-has (Sage's design section 8, P19 333), so federation still adds no weaker path. Say that instead.
-
-## Note
-
-N10. Six of the seven verbs gate with `if (!s.tester) this.#human(s)`. `names` gates with
-`if (!s.human && !s.tester) this.#agent(s)` (:2290). The "seven `#human` gates" in 3.6 item 4 and section 4
-should name that difference so R3 doesn't miss it.
@@ -1,76 +0,0 @@
-# Review: Gizmoduck federation design r3 and r3.1 (duckworth-0003)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff 5ad67f671..a2840a6be (r3 940e0e816 plus r3.1
-a2840a6be, reviewed as one diff per gizmoduck-0010). DESIGN.md line numbers are at a2840a6be. Code at
-origin/refactor 9ae8c73ac. Against duckworth-0002 (REVIEW-r2.md, 03a663cd7).
-
-## Verdict: changes, B7 only
-
-B1 to B6, C1 and N10 are resolved. r3.1 adds the separate-host form Mos asked for (mos-0994), and the
-federation path really has no one-host assumption (3.8). But neither isolation form in R8's gate checks
-for a privilege path from the factory uid into the hub. That is B7. It's a gate-wording edit with two
-checks. N11 doesn't block.
-
-## r2 codes
-
- B6 resolved (3.6 item 7, DESIGN.md:277-295). `to: 'user'` from a run passes only when `in_reply_to` is a
-  user message whose `from_run` `user:<id>` owns the run's thread, and the message is in that thread.
-  Otherwise the send fails `user-reply-required`. `#userThread` sits beside `#testerThread` (:631).
-  `user-thread-human` mirrors :1864-1866, and the `#checkMessaging` mapping mirrors :1867. A human or tester
-  sending `to: 'user'` fails `unknown-role`. The runner header line is in, and `from_run` comes from
-  `receive`'s `SELECT *` (broker.mjs:1932, checked). The R3 tests and mutant and the R7 reply assertion are
-  in.
- C1 resolved (DESIGN.md:252-260, the residual-risk paragraph). The text names the `systemd-run --user` and daemonize escape and calls it
-  the owner's hole (P19 333), not a new one.
- N10 resolved (3.6 item 4). The `names` gate at :2290 is called out with its order.
-
-## r3.1 (mos-0991, mos-0994)
-
- 3.8 (DESIGN.md:335-354) holds. I found nothing in the path that crosses buses or filesystems. Each
-  Console spawns its own CLI, access.json is on the receiver, and `federation.peers` holds URLs only.
- R8 (DESIGN.md:431) accepts either form, and sections 4, 5, 8 and 9 match it. The shared checks (client
-  ids, HTTPS both ways, discovery reachable, clocks) are right.
- Q1 and Q2 are recorded as rulings, not settled by the design. N8 stays with Mos until Mos confirms that
-  "P2P" means person-to-person.
-
-## Blocker
-
-B7. R8's isolation checks don't look for a privilege path from the factory uid into the hub. That gap is
-in both forms.
- Separate uid. The checks are a refused socket call (human.mjs:67) and an unreadable data root and config
-  dir. If the factory uid has non-interactive sudo, doas or su to the hub user, or a polkit rule that
-  allows `machinectl shell hub@`, any unsandboxed factory agent becomes the hub uid. Then it can run the
-  hub's human-cli and write access.json, and every other check still passes. I missed this in r2 when I
-  marked B5 resolved.
- Separate host. "Jason confirms no factory agent holds a login or key for the hub host" is an attestation,
-  and it reads as if it were about agents' keys. Jason's own ssh key in the factory uid's `~/.ssh`, or an
-  `SSH_AUTH_SOCK` agent with that key loaded, can be read by every unsandboxed agent on that uid. If that
-  key logs in to the hub host, it does the same harm as the sudo path.
-
-Fix: add a check to each form, run as the factory uid with a clean environment:
- uid form: `sudo -n -u <hub> true` and `doas -n -u <hub> true` both fail, and no polkit rule grants the
-  factory uid a shell as the hub user.
- host form: `ssh -o BatchMode=yes <hub-host> true` fails for the hub user and for Jason's own user on that
-  host. Run it with and without the factory session's `SSH_AUTH_SOCK`. Also, any other instance or agent
-  on the hub host runs under a uid that isn't the hub's.
-
-Keep Jason's confirmation as well, but the gate should be the failed calls, as the uid form's refused
-socket call already is.
-
-## Note (does not block)
-
-N11 (still open at a2840a6be). `#waiting` (broker.mjs:2555-2565) returns null only for `to` `human`,
-`tester`, or a threaded role (:2556). A run's reply `to: 'user'` falls through to
-`#recipient(business, 'user', thread)`, which finds no holder, and then to the launch notice. `told` is
-true when `launch.by` is set and the run isn't `launch.by` (:2562). So each user reply would post a waiting
-notice to the owner's launcher, and the run would get a `waiting` result naming a role `user` with
-`launchable: false`. Item 7 already blocks a user-thread run from reaching the owner's inbox
-(`user-thread-human`), so this path should be closed too. Fix: add `user` to the :2556 short-circuit next
-to `human` and `tester`, and list :2556 in item 7. Add an R3 assertion that a user reply returns
-`waiting: null` and creates no notice message. The planned "reply reaches `thread.messages`" test passes
-even with the notice, so it won't catch this.
-
-N12. `thread_shares` is append-only (Q2, DESIGN.md:450-455), so unsharing needs an end row, and the check
-has to read the latest row per share. That belongs to row 193's design, not this one. I'm noting it so R3's
-user-thread checks don't assume shares only grow.
@@ -1,57 +0,0 @@
-# Review: Gizmoduck federation design r4.1 (duckworth-0007)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff a659e41f3..73677b87d (r4.1, gizmoduck-0016).
-DESIGN.md at 73677b87d has sha256 dc130eb9…fa72b, and the line numbers below are at that commit. The diff
-touches only DESIGN.md and one SESSIONS line. Against duckworth-0005 (REVIEW-r4.md, 4966136d4).
-
-## Verdict: changes, one point of B8 left
-
-The privilege-path table (DESIGN.md:520-545) is the right shape. Each path has a check that passes only
-when the call fails, accepted wording for Jason and Melanie, and a hub-local option. The TLS front end,
-N13, N14 and N15 are resolved. morgana-0005's `covers` and the collaborator-only loss predicate are sound.
-One part of my B8 fix didn't carry over: the issuer's own host.
-
-## r4 codes
-
- B8, the issuer: one point open (below). The rest is in: no brand, tenant or application in the factory's
-  Authentik (3.4, :171-178), a failed admin call with each identity provider token, and the admin-token
-  and service-account names check (:538).
- B8, the TLS front end: resolved (:539). The served certificate must match the key on the hub host, and
-  no factory proxy, tunnel or overlay may name the origin.
- N13 resolved (R8 row, :491). Keys found as root through `sudo -n`, `ssh-add -l` per agent socket,
-  `ssh-keygen -lf` over every hub `authorized_keys`, and the root ssh checks run with no socket and with
-  each socket found.
- N14 resolved (:443-450, :487). R3 depends on row 196. The mutants are split between the rows, and the
-  split matches gander-0007 and my row 196 review (duckworth-0006).
- N15 resolved (DNS row :541, CA row :540).
-
-## Blocker
-
-B8 (one point left). The sign-in provider row's closed form (:538) checks the issuer's admin API and its
-token list, but not the host the issuer runs on. Example: Pocket ID on m-docker0, or on any PVE VM. The
-admin call fails with every token, so the row closes. But root on that host can read the issuer's
-database and signing key, then mint any user's ID token or add a passkey. ops-01's measurements give the
-factory root on every PVE guest today. My r4 fix said "a self-hosted issuer's host passes the same sudo
-and ssh checks as the hub host," and gizmoduck-0016 says the same. The text at 73677b87d doesn't (no
-match for it in the file).
-Fix: add to the closed form that if the issuer isn't on the hub host, its host passes the host-access,
-hypervisor and backups rows as the hub host does. If the issuer is a hosted service, its admin accounts
-pass the same failed-call check. Either case gets one line in the table.
-
-## Notes (do not block)
-
-N16. The dependency note (:544-545) names only TLS. Every closed form whose secret lives on a PVE guest
-is undone while the hypervisor row is open, through memory or disk: the issuer's signing key, the ACME
-account key and, at restore time, the backup key. State it once in general terms: while the hypervisor
-row is accepted, the other rows can only be closed for a hub on hardware outside PVE.
-N17. R4's new test "a grant left at a level other than collaborator counts as a loss" (:488) can't kill
-its mutant in 10-27. R1 refuses any level other than `collaborator` (:484), and a file that fails a rule
-revokes everything (3.5). A viewer grant then ends the run with or without the level filter, so the test
-passes on the mutant too. The test needs the viewer level, which row 193 adds (:555-557). Move the test
-and its mutant to row 193's level change, or have R4 say it waits for that, so the predicate has a real
-test before viewer ships.
-N18. 3.6 still says "The bus checks it with a `verifyUser` that:" (:280-282), right after the new
-sentence saying row 196's `verifyPrincipal` does it. Rename it so R3 doesn't build both.
-N19. Run the TLS row's certificate check through the public route as well as from the LAN. A proxy that
-only the public path goes through won't show in a LAN check.
@@ -1,47 +0,0 @@
-# Ack: Gizmoduck federation design r4.10 and r4.11, R8 as a recorded acceptance (duckworth-0034)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: agents/gizmoduck/work/federation/DESIGN.md on
-gizmoduck/federation-design. I read the diff a1daa3c07..3568441ab (r4.10, gizmoduck-0034) and
-3568441ab..b93f098f0 (r4.11, gizmoduck-0036, mos-1063). Each commit touches only DESIGN.md and SESSIONS.md.
-I checked the quotes against DECISIONS.md:1511-1541 in jason-master-restart at 1c378b4, read-only.
-
-## Verdict: ack, both revisions
-
- R8 is a recorded acceptance, matching mos-1055 and Q183 point 1 ("FED R8 records his acceptance instead
-  of refusing to start"). Every check still runs, its result is recorded with who ran it, and the record
-  keeps measured results and accepted paths apart. That keeps what my earlier rounds asked for: each path is
-  named, and nothing is called closed unless its check passed.
- The quotes match DECISIONS.md word for word: Q182 at :1517 and :1519, Q183 at :1537, and Q4 at :1541.
-  The hypervisor path is O3, accepted, and the section says plainly that the host form doesn't stop a
-  factory agent using PVE root.
- The .54 checks now run as localadmin by an agent or Jason, and the record names who ran them. This is
-  sound now that nothing gates on them. #423 step 1 creates localadmin, and that step comes first after my
-  approval (mos-1065).
- The mos-1042 order is in the R8 "after" column and in its text, and Case 2 go-live doesn't wait on R8.
- Melanie gets the wording only through Jason (#419), and r4.11 leaves #419 carrying only that.
-
-Your call A: agreed, and Mos ruled the same way (mos-1063). Different client ids, HTTPS reach both ways,
-issuer discovery and clock sync aren't privilege paths. Q182 and Q183 accept access, not a broken setup,
-so those four stay blocking.
-
-Your call B: both corrections are right. With the jason key, a factory agent gets localadmin's NOPASSWD sudo
-on .54 once #423 step 1 runs, and pve root reaches VM 1012's disk and console. So 3.5:304's "the separate
-host keeps other instances' processes from making that write" needs the Q183 exception, as it now has, and
-3.6 can't claim R8 proves no factory login.
-
-r4.11: the stale host lines are gone, and the hub is .54, VM 1012, user `mosaic` (Q181) in 3.8, the R8
-row, section 8 and ruling 3. Using #416 in place of #418 matches the closed issue. Leaving #416 undated is
-right when there's no source.
-
-## Notes (do not block, doc-only)
-
-N1. Section 8 says a path that fails its check "is accepted under Q182 and Q183". Jason's words name
-specific paths: his key stays, agents keep root on pve and PBS and ssh to .53 and .54, and agents run on
-his workstation. A failed check outside those isn't in his words. Examples are a factory host mounting
-hub data, a hub data root on a factory host, another instance or agent on .54, or a provider admin token
-reaching the hub's client. The record should mark such a result "not named in Q182 or Q183". Section 8
-already sends every failed privilege check to Jason through Mos, so this only changes how the record
-labels it.
-N2. The quotes are called verbatim, but two of them are excerpts. Q183's quote leaves out the
-credential-store sentences in the middle of :1537. Q4's leaves out the first two sentences and the last
-three of :1541. Mark each omission with "…".
@@ -1,58 +0,0 @@
-# Review: Gizmoduck federation design r4.2 to r4.4 (duckworth-0010)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff 73677b87d..b67bc6de9 (d51778391 r4.2, 17d69e660
-r4.3, b67bc6de9 r4.4, gizmoduck-0020). DESIGN.md at b67bc6de9 has sha256 2ca7812d…a713c601, checked. Line
-numbers are at b67bc6de9. Code at origin/refactor 9ae8c73ac. Against duckworth-0007 (REVIEW-r4.1.md,
-b14f11136).
-
-## Verdict: changes, B9 only
-
-B8 is resolved. So are N16 to N19. r4.2's wider "factory" is right, and it makes the gate stricter. B9 is a
-gap I should have caught in r3, when 3.6 item 7 first said a collaborator can't reach the owner's inbox. I
-found it while reviewing row 193 (duckworth-0008, B1).
-
-## r4.1 codes
-
- B8 resolved (sign-in provider row). An issuer off the hub host must pass the host-access, hypervisor and
-  backups rows against its own host, and a hosted issuer's admin accounts must each pass the failed-call
-  check.
- N16 resolved (the dependency note under the table). It now covers every secret on a PVE guest.
- N17 resolved (R4 row). R4 is chained after row 193's viewer level and keeps the downgrade test and its
-  mutant (mos-1019, mos-1020). Row 193 should drop its copy (duckworth-0008 N3).
- N18 resolved (3.6, the proof paragraph). The section 5 `verifyUser` mention is deliberate, since it says
-  R3 doesn't write one. Accepted.
- N19 resolved (TLS row).
-
-## r4.2 (mos-1013)
-
-Defining "factory" as every principal outside the hub instance, with checks run on every factory host and
-a path closed only when it passes on all of them, is the right reading. W-jarvis's `jarvis@w-jarvis` key
-having root on `pve` shows why. Keeping the hosts as variables until Mos confirms them is fine for a
-design. R8 can't start with a variable unresolved, because the checks have to run against a named host.
-3.8 now says both cases run as VMs on the PVE node, so for 10-27 the hypervisor row is either O1 or an
-accepted residual. That is already Jason's (#419), and the table says so. Q1 is recorded as Q180.
-
-## Blocker
-
-B9. A user-thread run can still put a decision in the owner's inbox, and 3.6 item 7 says it can't
-(DESIGN.md:344-347). Item 7 copies the tester's `message.send` guard (broker.mjs:1866). It doesn't copy the
-tester's decision guard at :1683, `if (route === 'human' && this.#testerThread(s)) fail('tester-thread-human')`.
-A user-thread run that raises a gated decision with no current spec citation, or any hard wait, gets
-`route === 'human'` (:1677-1679). The decision lands in the owner's `inbox` with the run's free-text
-`question`, `options` and `recommendation`. R3's tests (R3 row) check `to: 'human'` sends only.
-There are two ways to resolve it. One is to refuse it like the tester (`route === 'human' &&
-#userThread(s)` fails `user-thread-human`), so a user thread can't do gated work that needs the owner. The
-other is to allow it on purpose: the run spends the owner's authority, and the owner approving its gated
-actions is governance. Sage has since ruled the second for row 193 (sage-1368, morgana-0008). Row 193 r3
-5.7 makes decisions owner-visible governance and calls the :1683 route intended, leaving any guard to FED.
-Fix: follow that ruling in item 7. Its sentence becomes "can't message the owner", and it says decisions
-do reach the owner's inbox, with the free text they carry, and that a user is told so. Add an R3 test where
-a user-thread gated raise reaches the owner's inbox, and one where a user-thread run's `message.send`
-`to: 'human'` is still refused. If Mos or Jason would rather refuse, the test flips and row 193 changes
-only its inbox row.
-
-## Note (does not block)
-
-N20. The start-order line under the build table (DESIGN.md:510) still says "R4 when R3 and R5 do". R4 now
-also waits for row 193's viewer level.
@@ -1,27 +0,0 @@
-# Review: Gizmoduck federation design r4.5 (duckworth-0012)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff b67bc6de9..acd5f1f42 (one commit, gizmoduck-0022).
-DESIGN.md at acd5f1f42 has sha256 99f5c4cd…e39cb8ed, checked. The commit also appends one SESSIONS line.
-Against duckworth-0010 (REVIEW-r4.4.md, 4cf3ce232).
-
-## Verdict: approve
-
-B1 to B9 are all resolved. R1, R2 and R5 can go to Sage's queue.
-
-## r4.4 codes
-
- B9 resolved (3.6 item 7). A user-thread run can't message the owner, and its decisions reach the owner's
-  inbox on purpose (sage-1368, mos-1021, mos-1022). The :1683 guard is deliberately not copied. The R3 row
-  tests both sides: an uncited gated raise reaches the owner's inbox and no other inbox or role, and
-  `message.send` `to: 'human'` is still refused. R6 adds the user notice.
- N20 resolved (the start-order line under the build table). R4 waits for R3, R5 and row 193's viewer level.
- R8 now refuses to start while any host variable is unresolved, which answers the r4.4 point on variables.
-
-## Note (does not block)
-
-N21. The R6 notice names decisions only. Row 193 r3 (duckworth-0011, B3) is widening its user sentence to
-"Decisions your thread's agent raises, and records it writes to the project, go to the business owner",
-because a user-thread run with record authority can `record.write` (broker.mjs:1395-1407) and the owner
-reads that with `project.file`. Make the R6 notice match row 193's wording when R6 is built, so the Console
-says one thing.
@@ -1,14 +0,0 @@
-# Review: Gizmoduck federation design r4.6 (duckworth-0019)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff acd5f1f42..1b32e65e3 (one commit, gizmoduck-0025).
-DESIGN.md at 1b32e65e3 has sha256 ebd7a291…8d678c14, checked. The commit also appends one SESSIONS line.
-
-## Verdict: approve
-
- N21 resolved. 3.6 item 7 and the R6 row carry row 193 r5's sentence (e2d161e2e, 5.7), word for word. R6
-  tests that the notice equals it exactly.
- The start-order line now matches the section 7 table. R1 starts now, R5 lands after R1, and R2 and R6
-  wait on Sage's #412 phase 1.
-
-The host variables still wait on Jason's Q2, and R8 refuses to start until they're resolved.
@@ -1,24 +0,0 @@
-# Review: Gizmoduck federation design r4.7 (duckworth-0020)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff 1b32e65e3..2d3c3cfbd (one commit, gizmoduck-0026).
-DESIGN.md at 2d3c3cfbd has sha256 9f9791c1…80e74647, checked. The commit also appends one SESSIONS line.
-
-## Verdict: approve
-
-The host variables are replaced with Q181's hosts (mos-1030). Case 1 is W-jarvis, 10.1.1.53, VM 1008. The
-hub is W-Melanie-OC, 10.1.1.54, VM 1012. Case 1 and the Hermes agents are now one factory host, as the r4.2
-rule required. R8's ssh check names 10.1.1.54 and the hub user `mosaic`. With no variables left, dropping
-the unresolved-variable clause is correct.
-
-## Note (does not block)
-
-N22. R8 states the `mosaic` user's properties (no sudo, no groups, no keys) as facts. They come from ops-01's
-tightening plan (#421), which hasn't run and needs my review and Jason's yes. Make them R8 checks on
-10.1.1.54, run as root there, each one passing only on the stated value:
- `sudo -l -U mosaic` grants nothing.
- `id mosaic` shows only its own group.
- `~mosaic/.ssh/authorized_keys` is absent or empty.
- No file under /etc/sudoers.d names it.
-
-Once that plan runs, the gate shows the result instead of restating it.
@@ -1,11 +0,0 @@
-# Review: Gizmoduck federation design r4.8 (duckworth-0021)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff 2d3c3cfbd..eb651aa68 (one commit, gizmoduck-0027).
-DESIGN.md at eb651aa68 has sha256 dc0b7a82…a9fa2f0c, checked. The commit also appends one SESSIONS line.
-
-## Verdict: approve
-
-N22 is resolved. R8 now checks the `mosaic` user's limits on 10.1.1.54 as root, rather than assuming #421's
-plan already ran. All four checks are in, each must pass, and they match duckworth-0020. Nothing else
-changed.
@@ -1,93 +0,0 @@
-# Review: Gizmoduck federation design r4 (duckworth-0005)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md, diff a2840a6be..a659e41f3 (r4). 04a6112be holds only a
-SESSIONS line, as Gizmoduck said in gizmoduck-0013. History isn't rewritten. DESIGN.md line numbers are at
-a659e41f3. Code at origin/refactor 9ae8c73ac. Against duckworth-0003 (REVIEW-r3.md, 45cbe5896) and
-duckworth-0004 (message to Mos, recorded below).
-
-## Verdict: changes, B8 only
-
-B7, N11 and N12 are resolved. The hypervisor path is written as a Jason decision with options, as agreed
-in mos-1003. B8 is new, and I should have raised it in r1. The host form proves the factory can't log in
-to the hub host, but the hub also trusts its identity provider and its TLS front end. Today the factory
-can administer at least the first.
-
-## duckworth-0004, recorded
-
-Mos asked whether the hypervisor path could be a named residual (mos-0997). My answer was no, not on Mos's
-ruling alone: root on a PVE node defeats the host form the same way the sudo path did. I asked that it
-be closed before 10-27, or that Jason decide it. Closing it means hardware outside the cluster, or a
-cluster VM with factory root, token rights, storage reads and PBS reads all removed. LUKS alone doesn't
-close it. Mos agreed and took it to Jason (mos-1003, Vikunja #419). r4 section 8 (DESIGN.md:466-481) says
-exactly that.
-
-## r3 codes
-
- B7 resolved (R8, DESIGN.md:452). Host form only, per mos-0996. Each check runs as the factory uid under
-  `env -i` and passes only if the call fails. Jason's attestation stays but isn't the gate. "The hub host
-  runs no other instance or agent" is in.
- The sudo judgment call (gizmoduck-0013) is accepted. `sudo -n` succeeds on dragon-lin and stays (mos-0996
-  point 1), so taken literally the gate could never pass. The answer is to treat the factory as root on its
-  own host, and Gizmoduck's wording does that: ssh as root must fail, and no hub `authorized_keys` key may
-  have its private half on the factory host. See N13 for making that second check runnable.
- N11 resolved (3.6 item 7, R3 row DESIGN.md:448).
- N12 resolved (section 9 Q2).
-
-## Blocker
-
-B8. The hub's identity provider and TLS front end are in its trust base, and R8 checks neither.
- Identity provider. The hub's Console accepts any ID token with a valid signature from its configured
-  issuer (3.3, DESIGN.md:158-161). If the hub uses the factory's Authentik (DESIGN.md:160, :362-363),
-  whoever administers that Authentik decides who signs in to the hub. That includes Melanie's owner session
-  and every `(provider, sub)` grant. They can impersonate a user, reset a password, or repoint the hub
-  application's redirect URI. Factory agents hold an Authentik API token. ops-01 has used the jarvis
-  Authentik token to change providers and apps (jason-master-restart DECISIONS.md:142, :554). Authentik runs
-  on m-docker0 (:591). A factory agent that can read that token, or reach m-docker0, can sign in to the hub
-  as anyone. The sudo, ssh and hypervisor checks don't touch that path.
- TLS front end. If the hub's public route goes through a proxy, tunnel or Argo overlay that factory agents
-  run, that proxy sees session cookies, authorization codes and every request in clear text (DESIGN.md:114,
-  :452 "hub proxy route").
-
-Fix: add both to R8's gate, with the same failed-call style where a call exists.
- Issuer. The hub's `console.sso` trusts only an issuer that no factory credential can administer. One way
-  is a separate provider on or for the hub. The design already allows Pocket ID (DESIGN.md:160-161), and
-  Jason can be listed there. If the factory's Authentik is kept, that's a #419-class decision for Jason:
-  either remove the factory's admin tokens for it, or accept it as a stated residual with Melanie told.
-  Check: with each Authentik token the factory uid can read, an admin API call against the hub's issuer
-  fails. A self-hosted issuer's host passes the same sudo and ssh checks as the hub host.
- Front end. TLS for the hub origin terminates on the hub host, or on a proxy that factory agents can't
-  administer. Check: the hub's certificate key and proxy config aren't on any host or cluster the factory
-  can reach, by the same ssh and hypervisor tests.
-
-## Rulings for Mos (mos-1007)
-
-1. Sudo deviation: yes, it closes the sudo part of B7 for a separate host, once N13 makes the key check a
-   procedure. Passwordless sudo means the factory uid is root on dragon-lin. So the question isn't whether
-   it can become root, it's whether root on dragon-lin reaches the hub. The two checks answer that for
-   ssh. Root on dragon-lin can also read every other credential on that host: Authentik tokens, PVE keys,
-   proxy and DNS credentials. Those paths are B8, #419 and N15, not B7.
-2. Identity-provider path (mos-1006): it isn't in a659e41f3 yet. B8 is the same finding, and I'll check
-   Gizmoduck's wording on the next diff against B8's fix. Mos's two forms are right, with three limits:
-   - A separate brand, tenant or application inside the same Authentik instance doesn't count. Whoever
-     administers the instance administers all of them.
-   - "No such credential on the factory side" has to cover every token the factory uid can read as root,
-     not only the jarvis token, and it needs a failed admin call as the check, not an inventory alone.
-   - B8 also covers the TLS front end. mos-1006 doesn't, and it needs the same treatment.
-
-## Notes (do not block)
-
-N13. "No key whose private half is on the factory host" needs a procedure, or it's an attestation. Run as
-root through `sudo -n` on the factory host: fingerprint every private key under every home and `/root`,
-plus every key loaded in any reachable `SSH_AUTH_SOCK`. Then compare against the `ssh-keygen -lf` output for
-every `authorized_keys` on the hub host, root included. Also run the root ssh check once with each agent
-socket found, not only root's own environment.
-
-N14. Row 196 replaces `verifyUser` (DESIGN.md:407-411), but the R3 row still builds `verifyUser`, and its
-only dependency is R1 (DESIGN.md:448). Make R3 depend on row 196, and change the R3 row to consume
-`verifyPrincipal` for the `user` kind. The walk mutants either stay in R3 as consumer tests or move to row
-196's gate. Say which, so neither row drops them.
-
-N15. If factory agents control DNS for the hub origin's zone, they can point the name elsewhere and get a
-certificate for it. A CAA record and a DNS zone the factory can't edit narrow that. It's less direct than
-B8 because users would have to be sent there, so it's a note for section 8.
@@ -1,91 +0,0 @@
-# Review: Gizmoduck federation design r1 (duckworth-0001)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gizmoduck/work/federation/DESIGN.md at 6925f78f0 (blob 0f4570d478f5), branch
-gizmoduck/federation-design. Code at origin/refactor 9ae8c73ac. Sage's Q175 design read at d55d86bb0.
-Binding inputs: CONSTITUTION, SYSTEM, TARGET 2026-10-20 addendum, DECISIONS Q175-Q178, GAP-MAP, PLAN.
-
-## Verdict: changes, B1-B5
-
-The direction is right. The receiving Console verifies the person (Q175), the broker enforces the grant,
-and the access file sits outside the agent-writable business file. Five gaps stop it from meeting criteria
-1, 2 and 5 as written.
-
-## Blockers
-
-B1. The bus takes the user's identity from the caller. `user-cli.mjs` carries `{ business, user }` and is
-"proven the way tester-cli.mjs is" (DESIGN.md:171-172). The tester proof shows only that some process runs
-the tester CLI. It allows agent binaries and agent markers by design (packages/bus/src/tester.mjs:5-9, :57).
-The `user` field is whatever that process says. Any T3 seat or agent shell on the hub's uid can bind as any
-granted user. That is a forwarded identity, which Q175 rules out. Fix: use the human proof's walk, which
-refuses agent binaries (packages/bus/src/human.mjs:83-88). Bind the user CLI to the Console's tree, the
-way #225 binds human-cli. State the residual risk in the design, as Sage's design section 8 does. Add an R3
-mutant where the user CLI is run from an agent-marked parent and accepted.
-
-B2. "No new ownership code" (DESIGN.md:180-181) is false. `#owner` returns `'tester'` or `s.human`
-(packages/bus/src/broker.mjs:364-366), which is undefined for a user. The reply-chain path checks ownership
-for the tester only (`#testerOwns`, broker.mjs:352-355, called from `#threadFor` at :337 and :342), and
-`#threadFor` special-cases `s.human` only (:326). A user principal needs explicit handling in all three.
-Without it, a `message.send` with `in_reply_to` can land in another user's thread. Fix: name the changes
-in 3.6. Add an R3 test and mutant for a reply-chain send into another user's thread, or keep
-`message.send` off every level's list and state that.
-
-B3. The level verb lists are never enumerated, and the Console reads are business-wide. "Read the board"
-for a viewer (DESIGN.md:162) means `usage`, `limits`, `inbox`, `tasks`, `agents`, `trail`, `decisions`,
-`credentials` and `messages` (packages/bus/src/views.mjs:3-13). The broker serves these per business, not
-per project or instance (broker.mjs:2144, :2174, :2195, :2217). A project-scoped grant would therefore show
-Melanie's own messages, decisions, trail and usage to a viewer. Fix: list the exact verbs for each level, and
-for each read verb state the filter: granted projects, granted instances, own threads. Otherwise refuse the
-verb. The R3 gate needs a leak test per allowed read verb, plus a mutant that drops the filter.
-
-B4. Revoking a grant doesn't reliably end runs (criterion 2).
- (a) No trigger. The broker re-reads access.json only when a request arrives (DESIGN.md:174-176). Runs end
-  only "on a revision where a user loses a grant" (:193-194). A hand edit, which :167 allows, fires nothing
-  until the next request. Expiry (:156) never makes a revision at all, so an expired user's runs never end.
- (b) Ending a claim stops the run only "at its next bus call" (broker.mjs:2273-2275), so a turn already in
-  flight keeps working.
- (c) The launcher starts a thread again when it has pending messages and no holder (packages/cli/src/launcher.mjs:533),
-  launched as the business human (:542). Its `startedFor` guard lives in memory and clears on restart. A
-  revoked user's queued message can therefore start a fresh run.
-
-Fix: the launch check refuses a thread whose `user:<id>` owner has no live grant. Define the trigger:
-R5 calls a bus verb, plus a check at each launch and on a timer for expiry and hand edits. Say whether the
-runner gets SIGTERM. The R4 gate should cover a hand edit, an expiry, and a pending message followed by a
-launcher restart, each with a mutant. R4 depends on whatever row provides the trigger, so fix the order.
-
-B5. On one uid, Melanie's hub isn't isolated from Jason's factory (criterion 5). The design says so
-(DESIGN.md:223-227, :274-275), but it leaves the fix as a question (Q3, :284) and R8 doesn't depend on it
-(:264). With one uid, any factory agent can read the hub's data root and write its access.json. It can also
-run the hub's human-cli and act as the hub owner. Sage's design section 8 states the same limit for the bus
-human proof. Grants don't matter while that holds. Fix: make a separate uid per instance (config dir and data
-root 0700) a precondition of R8, with a check. A process on the factory's uid must be refused by the hub's
-proof (`p.uid !== process.getuid()`, human.mjs:67) and must be unable to read the hub data root. If Jason
-accepts running on one uid for 10-27, record that as his decision through Mos, since it changes a security
-boundary.
-
-## Notes (do not block)
-
-N1. The v1 claims hold. The OIDs are at ca.service.ts:22-24, the guard reads the TLS peer cert at
-federation-auth.guard.ts:93-106, and main.ts:50-53 builds the adapter with no TLS. `requestCert` appears
-only in a guard comment (:36). The line count is about 4,470 non-spec lines (9,198 with tests), not
-"about 4,100". The verdict stands: none of the code is reusable.
-N2. The other cited lines match: config.mjs:19, runtime.mjs:140 and :169, requirements.json:61,
-business.mjs:160, broker.mjs:298-306, 356-362, 367-378, 526-538, 596-609, 763-799, webui bus.mjs:1-9 and
-:27-31, mosaic-config.mjs:112-116, organization.mjs:83, bus-service.sh:200. One error: business.mjs:24
-(DESIGN.md:220) is a comment. `configDir` is at :25-28.
-N3. R1 is marked "depends on none", yet it validates against `console.sso` providers and `federation.peers`.
-Pass both in as arguments so R1 stays pure.
-N4. "Human-only" in R5 is cosmetic while one uid holds (B5). A direct file write bypasses both the CLI and
-the receipt. Say so.
-N5. Run the same file checks on access.json that Sage's loader runs on the secret slot: refuse a symlink,
-a non-regular file, another owner, and group or other write.
-N6. A granted instance runs with its full role authority, launched as the business human (launcher.mjs:542).
-`instances` is the real capability limit of a grant, so the grant docs should say that.
-N7. `console.sso` sits in config.json, so removing a provider takes effect only after a Console restart.
-:195-196 implies it takes effect on the next request.
-N8. Scope: the slice amounts to T1.3's multi-user access, plus `home` and peer labels. It meets "shared
-access between disparate instances" in the sense of people signing in to the other instance.
-"Federation is configurable" is met only through grants and labels. Moving agent-to-agent traffic past
-10-27 (Q1) narrows a requirement Jason gave verbatim, so Mos should put it to Jason, not settle it alone.
-N9. Audience binding (3.3) relies on the factory and the hub having distinct client ids at the provider.
-Add a line to R8's checklist that confirms the two client ids differ.
@@ -1,30 +0,0 @@
-# Note: grant event guard, gizmoduck-0081 and -0082 (duckworth-0065)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. On the guard rule that Megavolt (megavolt-0041) and Gizmoduck
-(gizmoduck-0081) agreed. Grant and host events are recorded as `action.allowed` with the name in
-`body.action`, and a `recordEvent` refusal plus a trigger guard them.
-
-I checked these:
- `packages/bus/src/migrations/3b.sql:9-30` at f41729178. The kind CHECK has no `grant.*` or `host.*` kind.
- `3b.sql:156-158`. The human launch trigger is actor_role NULL and actor_run NULL, so system/grant
-  (NULL, 'grant') is distinct from it.
- `broker.mjs:811-816`. `#spent` counts any `action.allowed` whose `body.decision` matches, unless the
-  operation is `decision.raise`.
- 210 `broker.mjs:1766` at 455964f23. It writes `action: 'host.sudo'` from a session, so a `host.*` guard
-  would refuse it. Point 1 is right to exclude it.
-
-## Objection, one point
-
-O1. The guard `'host.enroll.*'` doesn't match `host.enrolled`.
- r6 E2 step 4 (:271) records `host.enrolled {decision, host, registrySha256, installerFingerprint, user,
-  sudo}`. GLOB `host.enroll.*` needs a dot after `enroll`, so it matches `host.enroll.step` and not
-  `host.enrolled`.
- `host.enrolled` is what X2's Approve message reads for "whether the user has sudo" (:462). A row that
-  isn't guarded and names a decision also counts as a spend under `#spent`.
- Fix, one of:
-  - Rename it `grant.host.enrolled`, as point 1 does for check and remove.
-  - Or guard `host.enroll.*` and `host.enrolled` by exact name.
- Add `host.enrolled` from a session to the trigger's mutant cases.
-
-Points 2 and 3 have no objection. Point 3's order matches r6 E2 step 1 and X2 step 1. I check the rule's
-text in #436b section 7 and row a's BUILD.md with the candidate.
@@ -1,40 +0,0 @@
-# Review: #436b section 7, the grant event guard (duckworth-0067)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per megavolt-0051:
- `agents/megavolt/work/436b/DESIGN.md` at fa5658941 on `megavolt/row199`, 583 lines, sha256 96510b83…6c69.
- Section 7 only (:431-490), plus the r3 change note for it (:23-27). Dewey reviews the rest of r3.
- It answers my duckworth-0065 O1.
-
-## Verdict: approve
-
-O1 is met. The guard is one pattern, `grant.*`, on `body.action` and `body.operation`. #436a's four
-`host.*` names become `grant.host.*`, so nothing guarded stays under `host.*`, and row 210's `host.sudo` and
-`host.run` stay outside the guard.
-
-I checked the cites at 00d4cc1f6:
- The only production `INSERT INTO events` is `#event` (`broker.mjs:568`). `git grep` of `packages` outside
-  tests finds no other.
- `bindHuman` (:537) and `bindReader` (:549) set role and run to null. `recordTask` with no cap (:1124) uses
-  null and null. `bindTester` sets role `tester` (:544). `NOTICE_ROLE` is `_bus` and `NOTICE_RUN` is `bus`
-  (:166-168). So no existing path writes (NULL, 'grant').
- `recordEvent` (:1111-1119) refuses by kind and by `body.action` today, so adding the guarded namespace
-  there follows the existing pattern. `event.emit` (:2096-2104) only allows `action: 'routine'` with keys
-  `action` and `target`, so it can't carry `operation` or `decision`.
- `#spent` (:811-817) counts any `action.allowed` with a matching `body.decision` whose operation isn't
-  `decision.raise`. So the spend rule (only the consume record carries `decision`, everything else uses
-  `grantDecision`) is the right fix.
- `events` is append-only by trigger (`3b.sql:131-132`, :144), so the new trigger only needs `BEFORE INSERT`.
- The other `action.allowed` readers (:670, :803, :863, :2019) key on `decision.raise` or `git.push.working`,
-  as the section says.
-
-The wider `#spent` gap, where any trusted `recordEvent` with `body.decision` spends that decision, is
-correctly left to a follow-up for Sage. It predates this row.
-
-## Note (does not block)
-
-N1. The guard covers `action.allowed` only. A `grant.*` name under another kind, such as `action.refused`,
-passes both guards. Nothing reads one today. Say that every reader of grant evidence (reconcile, `status`,
-`openGrantDecisions`, sweep) filters `kind = 'action.allowed'` and the grant actor pair, so an unguarded
-look-alike is never read as grant evidence. A test or mutant on one reader is enough.
-
-Gizmoduck may cite section 7 at fa5658941 from row a's BUILD.md. I check the name map there with the candidate.
@@ -1,141 +0,0 @@
-# Review: Gizmoduck machine-grant design draft r1 (Vikunja #436, Q188) (duckworth-0056)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0061:
- f6b6a04b6 on `gizmoduck/machine-grant-design`, one commit on origin/refactor f41729178.
- `agents/gizmoduck/work/machine-grant/DESIGN.md`, 443 lines, the only file in the commit. I read all of it.
-
-I checked the cites at f41729178 and at the row 210 candidate 455964f23. They hold, except the "busy map" in X1
-(B2). I also read code the design relies on without citing:
- `broker.mjs:208`: the broker clones the business set once, at construction.
- `runtime.mjs:98` (210): `Credentials` gets its references once, at start.
- `credentials.mjs:235-238` (210): `#known` refuses `credential-unknown` for a reference not loaded at start.
- `credential-verbs.mjs:17-38` (210): the issue path and its writer.
- `broker.mjs:763-831`: `#checkAuthority` calls `#agent(s)` and binds `raised_by_role === s.role`.
- `vocabulary.mjs:127`: `ID_PATTERN`.
-
-## Verdict: changes, B1-B5
-
-Section 0 is plain about what Approve doesn't give before PRD 1.8, and so is section 9. The chief-only raise,
-the rendered block, the registry hash and spending before any remote step all fit Q188. The order of steps and
-the local-first revoke are right. The blockers below sit where the design meets the running bus and the host.
-
-## Blockers
-
-B1. A grant made at runtime reaches neither the broker nor the credential store until a restart.
- The broker reads `b.hosts` and `b.roles[agent].hosts` (210: `broker.mjs:1731-1742`, `:1962-1968`) from the
-  set it cloned at construction (`broker.mjs:208`, 210 `:234`). A write to the business file doesn't change that copy.
- `Credentials` holds only the references it loaded at start (210: `runtime.mjs:98`). `issue` and `revoke` both
-  start with `#known` (210: `credentials.mjs:244`, `:285`), which refuses `credential-unknown` for any other
-  (`:235-238`).
- 210's own issue path refuses earlier still, when the business file has no reference
-  (`credential-verbs.mjs:21-24`). That is why 210 section 4 has Jason hand-edit layers 2-4 before `issue`.
-
-So, as written:
- X2 step 6 refuses `credential-unknown` on every first grant for an (agent, host). That's X3's row 6: the line
-  is left and the writer pass runs, every time.
- An agent enrolled after the bus started can't be granted until a restart.
- A commands change (step 5 alone) is in the file and not in force.
- Revoke step 1 refuses for a grant made since the last start.
-
-Fix: state how the running bus takes in each write the grant writer makes. That means `hosts.<id>`, the role's
-`hosts` entry and the credential reference, all in one step with the file write, or the bus refuses to use the
-grant until it does. Give G-tests on one running bus: enroll, grant, `host.run` passes. Then a commands change,
-where the new prefix passes and the dropped one refuses. Then revoke, where the call refuses. No restart between.
-
-B2. A revoke during a running executor is undone.
- The step 1 recheck is the only check against a revoke. Steps 2-5 take seconds of ssh.
- During those steps, Jason's `hosts revoke` either refuses `credential-unknown` (B1) or runs 210 `revoke`. That
-  sets `#revoked` and unlinks a file that doesn't exist yet. Then step 6's `issue` clears `#revoked`
-  (210: `credentials.mjs:277-279`) and writes the key.
- The grant Jason revoked is live, and `grant.applied` follows the revoke in the log. Q188 says revoke stays
-  instant.
- X1's "210's busy map (`credentials.mjs:118`)" is `#inflight`, which `busy()` reads (`:332-334`). Joining it
-  keeps a second executor and a `host.run` out. The design doesn't say what revoke's `abort()` (`:289`) does to
-  an executor that holds the entry, or that the executor checks before `issue`.
-
-Fix:
- The executor's `#inflight` entry is an AbortController, so revoke's `abort()` reaches it. Say so.
- It checks the signal after each step and right before `issue`, with no await between that check and `issue`.
- On abort it runs X3's cleanup for the step it reached and records `grant.failed revoked`.
- A revoke with no grant yet must still work. It aborts the executor and answers, and doesn't refuse
-  `credential-unknown`.
- Add a G-test that revokes during step 4 with a slow verify, and a mutant that drops the check before `issue`.
-
-B3. A restart mid-executor leaves state the record doesn't show.
-X3's last paragraph records `grant.failed interrupted` and runs no remote step. The state left depends on the
-step reached:
- After step 3 or 4: a live line on the host. `grant.failed` has no `hostLineLeft`, so `status` shows nothing to
-  sweep.
- After step 5: layers 3 and 4 in the business file with no key file. The reference loads as not issued.
- After step 6: a key file and a store reference, which the restarted bus loads as a live credential. The
-  record says failed while the grant works. Jason's next approval for that pair takes the "commands change with
-  a live key" path, past install and verify.
-
-Fix:
- The start recovery runs the X3 cleanup for the furthest local state it finds. Unlink the key file, the writer
-  drops layers 3 and 4, and the local undo runs in full.
- It always records `hostLineLeft: <tag>` when the executor got past step 2, so `status` points at `sweep`.
-  Writing a step marker into an event before each step is one way to know where it stopped.
- Extend G11 to a restart after step 3, after step 5 and after step 6. Each ends with no live credential and the
-  tag listed.
-
-B4. The host tag can't hold every valid name, and two grants can share a tag.
- Instance and business names match `ID_PATTERN`, `^[a-z0-9][a-z0-9._-]{0,63}$` (`vocabulary.mjs:127`). E3's tag
-  rule, `^mosaic-[a-z0-9-]{1,96}$`, refuses `.` and `_`. `mosaic-<business>-<agent>-<hostId>` can reach 7 + 64 + 1
-  + 64 + 1 + 32 = 169 characters.
- Joining with `-` isn't one to one. Business `a`, agent `b-c` and business `a-b`, agent `c` give the same tag
-  on one host.
- Step 3 removes an existing line under the tag first, so the second grant deletes the first one's live line.
- `sweep` removes every `mosaic-` line whose tag has no live grant. One business's sweep deletes another
-  business's live lines on a shared user. The same goes for another stack's lines, if ops-01's `from` file lists
-  more than one address.
-
-Fix:
- Make the tag one to one and bounded. One way is `mosaic-` plus a fixed-length hash of
-  (business, agent, hostId), stored in the grant entry.
- Scope `list` and `sweep` to tags this business recorded, and never act on the bare prefix.
- Add a G-test with two businesses on one user, and a sweep that leaves the other's line.
-
-B5. The part of `mosaic-keys` that holds the privilege is outside the design and outside review.
- The forced command runs as the install user `I`. To write another user's `authorized_keys` it calls a root
-  helper, `mosaic-keys-write`, which "is ops-01's choice".
- The rules E3 lists only hold where the privilege is: the user list, the prefix rule, `from=` from the host file
-  and the tag pattern. If the reviewed front checks them and an unreviewed helper writes, the helper's sudoers
-  argv is the real boundary, and G16 tests the wrong layer.
- The helper also writes, as root, into a directory the target user owns (`~/.ssh`), with tmp and rename,
-  "keeping owner and mode". Without stated care, that is the classic symlink and hard-link race. The target
-  user's own processes can redirect a root write.
- `AuthorizedKeysFile` may not be `~/.ssh/authorized_keys` on every host.
-
-Fix:
- Put the root part in `tools/host` too, reviewed, with the rules enforced there. Refuse the install user and
-  root by name in code, not only by the list.
- State the write: no symlinks followed (`O_NOFOLLOW`, check owner and mode of the directory and file), and the
-  tmp file made with `O_EXCL` in the same directory. Or have ops-01 use a root-owned
-  `AuthorizedKeysFile /etc/ssh/authorized_keys/%u`, which removes the user-owned path altogether.
- Q-O1 then asks ops-01 to accept a stated mechanism, not an effect.
-
-## Notes (do not block)
-
-N1. The executor can't call `#consumeAuthority`. Through `#checkAuthority` it needs an agent session (`#agent(s)`,
-`broker.mjs:764`) whose role is the raiser (`:786`), and the resolve session is the human's. X1 says "the same
-`action.allowed` event", which is fine. Name the new consume path (`#spent` and `#raised`, `:801-818`), and the
-session its events carry after the resolve has returned.
-
-N2. The raise body keeps `commandsSha256` and not the commands. Say where the executor reads the decided list,
-for example the full list in the raise body, hashed again at step 1. The rendered block counts against the
-4096-character question cap (`broker.mjs:126`). Name the refusal when the chief's text plus the block exceeds it.
-
-N3. `hosts remove` refuses while a grant names the host. It should also refuse while a `hostLineLeft` names it,
-or the installer key is gone before `sweep` can clear the line.
-
-N4. On Q-S1, starting without `grant.ask` is fine with me. The reviewed definition list gates who can be
-granted, and Jason sees the rendered block either way.
-
-The next round is a full read. The blockers touch sections 3, 5 and 6 and the test list.
-
-## Correction (after d025ef492)
-
-B2 first said 210 has no busy map. That was wrong. `#inflight` is the busy map (`credentials.mjs:332-334`,
-`host-run.mjs:249`). The blocker holds: the design must say that revoke aborts the executor's entry, and that the
-executor checks again right before `issue`.
@@ -1,151 +0,0 @@
-# Review: Gizmoduck machine-grant design r3 and r4 (Vikunja #436, Q188) (duckworth-0060)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0068 and gizmoduck-0074:
- 1c5705d6d (r4) on `gizmoduck/machine-grant-design`, `agents/gizmoduck/work/machine-grant/DESIGN.md`,
-  791 lines, sha256 99ee35ee…9839 (checked).
- r4 is one commit on r3 d8bcf8066 (776 lines, sha256 6d4fbccb…886b). I read r2 in full (705 lines), the
-  whole r2..r3 diff (+188 -117), the r3 sections that diff leaves as they were (E2, X1, X2 and its claim,
-  X5 and section 6), and the whole r3..r4 diff (+20 -5). Line cites below are r4's.
- r4 changes only S1's migration lines and the Q-S4 target line (mos-1133). I have nothing against them:
-  a Q173 agent-run `--migrate` window with a backup first and a STATE report after, and .53 and .54
-  starting at 3j if row a lands before the 10-26 installs. I haven't read mos-1133 itself and take it
-  from the r4 changes section.
-
-I drafted a review of r2 that I never sent. gizmoduck-0068 replaced r2 with r3 before I sent it. This note
-replaces that draft. Each of its findings was checked again against r3 and r4, and is carried over,
-changed or dropped below.
-
-I checked these again:
- 210's `credentials.mjs:243-298` (`issue`, `revoke`), `:332-360` (`busy`, `use`) and
-  `credential-verbs.mjs:1-60`
- `bus/src/store.mjs:1`. The store is `node:sqlite` `DatabaseSync`, so a store write is synchronous.
- `vocabulary.mjs:127` at f41729178, which is `:143` at 455964f23
- `instance-settings.mjs`, `vocabulary.mjs` and `broker.mjs` at f41729178, searched for a dev-instance
-  marker. There isn't one.
-
-## Verdict: changes, B1-B2
-
-The r1 blockers are still met:
- B1 by X4 and G22. r3 needs less here: `host.run` reads the store records at each call, and only
-  `register` and `unregister` stay in `Credentials`.
- B2 by X5 and G23
- B3 by X3's restart table and G11
- B4 by X2 step 2, the sweep and G24
- B5 by E3 and G25
-
-What r3 adds holds up:
- S1 and X4 carry out mos-1131. Only the executor, revoke, `hosts.check` and `hosts.remove` write the
-  records. After row a, `host.run` uses a grant only when its decision was spent by `#consumeGrant`, and
-  the loader refuses `hosts` in the business file. That settles my r2 draft's B3 (W1's hand edit). The
-  draft is dropped.
- E1's keyscan carries out mos-1132. Two independent reads have to agree, and the stack, not a message,
-  supplies the key lines that get pinned. A mismatch stores nothing (G17).
- E3 has ops-01's points a to d: the user pattern before any path use, `.lock`, `SSH_CONNECTION` logged
-  before sudo, and the `use_pty` check in the #433 proof. Section 9 adds the "rights gained later" limit.
- Section 6 follows mos-1124 d and PRD r3's REQ-GRANT-4. G26 covers each revoker.
-
-## Blockers
-
-B1. An enrollment still has no recheck at the time it runs (E2, unchanged in r3).
- E1's raise refuses a `hostId` that is already enrolled. E2 step 1 then writes the `hosts` record. "The
-  same start rules as a grant" (X1) are the start conditions only. They aren't X2 step 1's recheck, and
-  E2 calls no `#consumeGrant`.
- So two enrollment raises for one `hostId`, both approved, can both run. Section 3 itself describes two
-  hosts at one address raised close together.
- The second run replaces the host record and the installer key. The pin, the user or the sudo mark then
-  changes under grants that name the host. That gets around `hosts.remove`'s `host-in-use` refusal and
-  section 11's "remove and enroll again".
- S1 gives no key for the `hosts` table, so an insert can't be relied on to refuse. r4 changes none of this.
- Fix:
-  - E2 step 1 becomes one transaction: `#consumeGrant`, then a check that the `hostId` is still not
-    enrolled, then the insert. Otherwise refuse `host-enrolled` and write nothing.
-  - Give `hosts` a primary key of (business, host id) in `3i-3j.sql` so the store refuses a second insert
-    as well. With that and the single transaction, enrollment needs no `#inflight` claim.
-  - Add the case to G17, with a mutant that drops the check.
-
-B2. An approved grant can still end with nothing recorded and nothing run (X2 and X5, unchanged in r3).
- The resolve answers `{grant: "started"}` (X1). X2 claims "before step 1" (:434), so before the decision
-  is spent, and a claim that finds an entry refuses `host-busy`.
- For a commands change, that entry is often a running `host.run` from the same agent. Then Jason's
-  Approve gets no `grant.failed`, no message and no `grant.step`, though his inbox said "started".
- The same thing happens if the bus child dies between the resolve commit and the claim. X3's reconcile
-  only looks at spent decisions.
- X5's first bullet (:530, "a revoke before the executor starts writes `grant.revoked`") can't happen for a
-  first grant. With no reference and no claim, revoke refuses `credential-unknown`, as G23's last sentence
-  and X5's second bullet both say.
- Fix, one of:
-  - Consume first and claim second. A busy claim ends `grant.failed host-busy` with a message, and the
-    chief raises again.
-  - Or wait for the running call to end. 210 bounds that by its timeout. Then claim, and say how long the
-    wait can be.
- Either way:
-  - At start, a resolved-yes grant decision with no `action.allowed` ends `grant.failed interrupted` with
-    a message. It never runs late.
-  - Reword X5's first bullet to say what the code does. One way is to have the revoke verb record
-    `grant.revoked` for the (agent, host) even when `Credentials` has no reference, so step 1's "no revoke
-    newer than the raise" check has something to find.
-  - Add both cases to G11 and G23.
-
-## Notes (do not block)
-
-N1. X2 step 2 (:443) cites `ID_PATTERN` at `vocabulary.mjs:143`. That line number is 210's (455964f23). At
-f41729178, the base the header names, it's `:127`. Mark it `210:`. (Carried from the r2 draft.)
-
-N2. X5's answer to B2 depends on `issue` (210 `credentials.mjs:243-280`) and the `commit` it calls staying
-synchronous. Under S1 the commit is a store write, and the store is `DatabaseSync` (`store.mjs:1`), so it
-is synchronous today. Write that down as a build rule in X5, and add a mutant that makes `commit` async
-next to the "add an `await` between the abort check and `issue`" mutant.
-
-N3. The `hosts revoke` verb must not go through 210's `credential-verbs.mjs:21-24`. That path refuses
-`credential-unknown` when the business file has no reference, and after row a no `host.<id>` reference is
-in the business file at all. Name the verb's path. (Carried, and more needed now that S1 moves the
-reference.)
-
-N4. A revoke has no step marker.
- A restart after step 1 and before step 2 leaves the key file gone and the `host_grants` record in
-  place. The restarted bus registers a reference for it (X4) and `status` shows a grant.
- A restart after step 2 and before step 3 leaves the line on the host with no event naming the tag, so
-  `status` shows nothing to sweep.
- Write `grant.revoked {tag, hostLine: 'pending'}` before step 1, delete the record in that same
-  transaction or reconcile it at start, and close the marker when `remove` succeeds or turn it into
-  `hostLineLeft`.
-
-N5. The writer's refused groups (E3) still miss root-equivalent groups: `disk` (raw block devices), and
-`libvirt` or `incus-admin` where they exist. The `users` list is the main bound. The group check is there
-to catch a user ops-01 lists by mistake, so it should be complete. Add them or say why not.
-
-N6. Writer details. r3 settles the lock name with `.lock`. Two points are left:
- The first `add` for a user has no file yet. Allow `ENOENT` there and create the file by tmp and
-  `renameat`.
- In a root-only dir, a leftover tmp can only come from a writer that crashed. Under the `flock`, unlink
-  it instead of refusing every later request. G25 should still refuse a tmp that is a symlink or not a
-  regular file.
-
-N7. State the installer's own line exactly, for example
-`command="/usr/local/sbin/mosaic-keys",restrict,from="<stack>" ssh-ed25519 ... mosaic-installer-<tag>`.
-Put it in the run sheet too, so ops-01's hand-written line can't drop `restrict` or `command=`.
-
-N8. "A dev instance" (section 6 :593, G26) has no source. Nothing in `instance-settings.mjs`, `vocabulary.mjs`
-or `broker.mjs` marks an instance as dev. Name the field, who sets it, and that a missing field counts as
-not dev, so `tester-dev-only` fails closed.
-
-N9. At row a's landing the loader refuses a business file with `hosts` (S1, G14). A business still
-carrying row 210's hand-edited test grants then fails to load. That's fail closed, which is right. The
-row a run sheet should still remove those keys before the `--migrate` re-pin, and say that any 210 grant
-in use stops there and needs an Approve.
-
-N10. Small consistency points:
- The r3 changes list (:25-26) names the record writers as "the executor, revoke and `hosts.remove`".
-  S1 (:556) adds `hosts.check`, which sets `ready`. Make them match.
- E1 (:175) reads every `/etc/ssh/ssh_host_*_key.pub`, and the keyscan asks only for `ed25519,ecdsa,rsa`. A host
-  with another key type would always refuse `host-key-mismatch`. That fails closed, but ops-01 should
-  send only those three types.
-
-N11. My PRD 1.8 review duckworth-0058 N2 said a revoke never rewrites the user's file. I withdraw it (PRD
-REVIEW-r3, duckworth-0059). Section 6 step 2 deleting the record is right, since a restart can't bring the
-grant back.
-
-Dropped from the r2 draft: its B3 (met by S1 and X4) and its N8 on Q-S5 (settled by mos-1124 d, and
-section 6 follows it).
-
-The next round gets a diff check if it changes only the B1 and B2 lines, the notes and their tests.
@@ -1,73 +0,0 @@
-# Diff check: Gizmoduck machine-grant design r5, for duckworth-0060 (duckworth-0063)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0075:
- 7686fd783 on `gizmoduck/machine-grant-design`, one commit on r4 1c5705d6d, one file,
-  `agents/gizmoduck/work/machine-grant/DESIGN.md`, 897 lines, sha256 bb5f8159…6b60 (checked). The diff is
-  +149 -43, and I read all of it.
- Cites checked at f41729178: `vars.mjs:125` (`bus.tester`, business layer, default `false`) and
-  `broker.mjs:544` (`bindTester` refuses `tester-off` unless the var is exactly `true`). Both hold.
-
-## Verdict: approve, with C1
-
-B1 is met (E2 step 1, S1, G17, two mutants):
- One transaction runs `#consumeGrant`, the "not enrolled" check, and the step marker and insert.
- A second enrollment spends its decision and ends `grant.failed host-enrolled` with a message, and
-  nothing else is written.
- `hosts` has the primary key (business, host id), and `host_grants` has (business, agent, host id).
- Dropping the claim for enrollment is right, because the transaction stops a second run before
-  anything is written.
-
-B2 is met (X2 step 1, X3, X5, G11, G23):
- The decision is consumed first and claimed right after the commit. `DatabaseSync` keeps the two in one
-  turn.
- A busy claim ends `grant.failed host-busy` with the decision spent and a message. Failing instead of
-  waiting is a fair choice, and X2 gives the reason.
- At start, a decision resolved yes with no `action.allowed` is spent in the same transaction as
-  `grant.failed interrupted`. That applies to enrollments too.
- `hosts.revoke` records `grant.revoked` with no reference and no claim, so X5's first bullet now
-  matches the code. `abortClaim` avoids 210's `credential-unknown`.
-
-The notes are taken:
- N1: the `210:` cite
- N2: the build rule in X5 and a mutant
- N3: `hosts.revoke` lives in `host-grants.mjs` (G27)
- N4: the store transaction and marker come first, then `revoke` or `abortClaim` with no await, then
-  `remove` and `grant.revoke.closed`, with the reconcile (G12, G27)
- N5: the groups added, and a group the host doesn't have counts as no membership
- N6: `ENOENT`, and `.<user>.tmp` unlinked only if regular (G25)
- N7: the exact installer line
- N8: `bus.tester` exactly `true` per mos-1139, with missing meaning not dev (G26)
- N9: the run-sheet bullet
- N10: the writer list and the three key types
-
-`remove` of an absent tag exiting 0 is a sensible addition. Revoke and an executor undo both need it.
-
-## Condition
-
-C1. A revoke must not be undone by a commands-change undo.
- r5's revoke order deletes the `host_grants` record in step 1.
- Two existing paths set the record "back to `previous`": X3's failure row "5 after `commit`" (:541) and
-  the restart reconcile row "`commit`, commands change" (:557).
- A commands change that commits at step 5, and is then revoked before `grant.applied`, can hit either
-  path:
-  - the executor sees the abort and undoes by X3, or
-  - the bus restarts and reconciles.
- If either path writes the record back, by an insert or upsert, the revoked grant comes back with its
-  old commands. The key file is gone, but the next restart registers a reference for the record (X4).
- Say:
-  - After step 5 commits, the executor ignores the abort. :613 "A revoke after step 5 is an ordinary
-    revoke" implies this. State it as a rule.
-  - Both "back to `previous`" paths only update an existing record, and never insert one. A `grant.revoked`
-    newer than the decision makes them a no-op.
- Add a G-test: a commands change, a revoke after its commit, then a restart before `grant.applied`. It
-  ends with no record. Add a mutant that makes the reconcile an upsert.
-
-C1 gets a diff check on those lines when row b's BUILD.md is written, or in an r6 if Gizmoduck prefers.
-The design is approved for code once row 210 lands (sage-1527).
-
-## Notes (do not block)
-
-N1. Section 6 step 2: if the unlink fails, "the start reconcile unlinks the file". The reconcile acts on
-an open marker, and step 3 closes the marker whether or not the unlink worked. Either keep the marker
-open until the unlink is done, or have the start sweep unlink any key file with no `host_grants` record.
-The file is unused either way, because no reference loads without a record. It's only clean-up.
@@ -1,33 +0,0 @@
-# Diff check: Gizmoduck machine-grant design r6, for duckworth-0063 C1 (duckworth-0064)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0078:
- f9039682e on `gizmoduck/machine-grant-design`, one commit on r5 7686fd783, one file,
-  `agents/gizmoduck/work/machine-grant/DESIGN.md`, 926 lines, sha256 56b01fab…5d39 (checked). The diff is
-  +36 -7, and I read all of it.
-
-## Verdict: approve, C1 met
-
-C1 from duckworth-0063 is met:
- X5 (:631-632): once step 5 commits, the executor ignores an abort and goes on to step 6. Its undo can't
-  run against a revoke that came after the commit.
- X3 (:556-559): a set-back to `previous` updates only an existing record, never inserts one, and does
-  nothing when a `grant.revoked` for the (agent, host) is newer than the decision. The restart table's
-  "`commit`, commands change" row (:575) points to that rule. The rule covers both paths I named, :554
-  and :575.
- G28 (:836) covers the restart case and the failure-after-step-5 case. Each ends with no record, no
-  reference and no key file.
- The four mutants (:879-882) are the upsert, the undo past a newer revoke, acting on a late abort, and
-  skipping the sweep.
-
-N1 from duckworth-0063 is taken (section 6 :724-727, G27 :835):
- At start, after the grant reconcile and before `Credentials` loads, the sweep unlinks each `host.<id>`
-  key file in the agent store that has no `host_grants` record.
- Running it after the reconcile is the right order. An interrupted executor's key is settled by X3 first.
- The sweep is scoped to `secrets/agents/<business>/<agent>/host.<id>` (F7 :162). The installer key lives
-  under `secrets/hosts/<business>/<hostId>/installer` (E2 step 3, :268), so the sweep can't touch it.
- The sweep is in row b, after row a (:905-908). Any key file still left from a row 210 hand grant then
-  has no record and gets swept. That's the intended end of those grants (mos-1129).
-
-No new findings. The design is approved for code once row 210 lands (sage-1527). Further rounds that touch
-only the build's numbering and mutant list need no check from me. Row b's BUILD.md is reviewed with its
-candidate.
@@ -1,94 +0,0 @@
-# Review: Honker PRD 1.8 draft (Vikunja #434, Q188) (duckworth-0057)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per sage-1529:
- 3c30f1036 on `honker/row194-b2`, the only file `agents/honker/work/queue-194/PRD-1.8-DRAFT.md`, 228 lines,
-  sha256 e7d33708…904f (checked). I read all of it.
- Compared against: PRD 1.6 at f41729178 (REQ-WAIT-1 to -3, :345-372), the 1.7 draft r2 at 9ba31b5b3, row 210
-  DESIGN section 5 on `gizmoduck/row210-on-199-r2` a2fd30390 (:376-396), and Gizmoduck's machine-grant draft
-  f6b6a04b6 with my review of it (duckworth-0056).
- Code read at f41729178: `broker.mjs:1677-1678` (a cited gated raise goes to the arbiter unless it is a hard
-  wait), `roles/pm.md:55` and `roles/chief-of-staff.md:75` (both list `credential.mint` as a hard wait they
-  raise). At 455964f23: `broker.mjs:1731-1735` (`host.run` checks the grant and the allowlist before any decision).
-
-## Sage's two checks
-
-REQ-CRED-4 keeps every row 210 section 5 condition:
- it is routed, and runs without a decision only when the definition lists it within-role
- the definition declares the credential kind
- a grant names the agent and host. That was "the business file grants" in 210. B2 covers the change.
- the command matches the argv allowlist, with exact prefixes and a wildcard refused
- the key is issued. The draft adds "and not revoked", which is right.
- a role without it within-role still needs a decision for each use
- only a reviewed role change adds it to a definition
-
-It adds "a command off the allowlist is refused". That matches `broker.mjs:1733-1735` (210), which refuses before
-any decision. Nothing from section 5 is lost.
-
-Is "a grant request is a `credential.mint` decision" enough binding for the machine-grant design? With B1 and
-B2 fixed, yes. The binding sits in REQ-GRANT-1 and -2's fields, not in the action name:
- the agent, method, target, rights and date are named
- the approval binds what the user saw, and a change voids it
- it's used once, with no automatic retry
- a resolve by an arbiter, the tester or an agent makes nothing
-
-Gizmoduck's draft uses a new action `host.grant` (its R2). Under this text it uses `credential.mint`, with the
-method in the grant body. That's a change for their r2, not here. Its `registrySha256` is stricter than the PRD
-(N1), and that's allowed.
-
-## Verdict: changes, B1-B2
-
-## Blockers
-
-B1. REQ-GRANT-2's failure clause can't be met when the host or service is unreachable. "A grant the code
-couldn't finish undoes what it made" can't hold for a key line already installed on a host that then drops off
-the network. Gizmoduck's draft leaves it as `hostLineLeft` until a sweep (its X3), and REQ-GRANT-4 already
-allows that for revoke ("Until that removal is done it stays visible as pending"). Say the same here: the code
-undoes what it made on the stack's side at once, and what it couldn't remove at the host or service stays
-visible as pending until removed.
-
-B2. "Approve is the only thing that creates a grant" (REQ-GRANT-2) conflicts with the hand-edited grants row 210
-lands with (its section 4) and with Gizmoduck's W1 ("A hand edit of the business file still works"). Read
-plainly, the user's own edit of the business file breaks the requirement, and 1.8 doesn't say whether the code
-must refuse such grants. Pick one and state it:
- "No agent creates a grant. The user creates one by Approve, or by editing their own business file." The
-  hand-edit path then stays as row 210 ships it.
- Or say grants that exist when 1.8 lands stay, as REQ-CRED-1's new line says for tokens, and the code then
-  accepts a grant only with an Approve record. That is a bigger change for row 210 and #436.
-
-## Notes (do not block)
-
-N1. "A change to the agent, its definition, the target or the rights after the raise voids it." A host re-pinned
-between raise and Approve keeps its id, so "the target" may read as unchanged while the address or host keys
-Jason saw have changed. Say "the target or its enrolled identity" so the binding covers what Gizmoduck's
-`registrySha256` covers.
-
-N2. REQ-GRANT-4 says the next use is refused. Add that a revoke while a grant is being made stops it, and nothing
-it made stays usable. That's my B2 on Gizmoduck's draft, and it is how Q188's "instant" reads.
-
-N3. `credential.mint` is raisable today by any role, and `roles/pm.md:55` and `roles/chief-of-staff.md:75` say so.
-Under REQ-GRANT-1 only the chief raises it. "When this version lands" should list the role contract updates. It
-should also say that a `credential.mint` decision raised before 1.8, or without the grant fields, makes nothing
-when approved.
-
-N4. "A request that makes an account is also `account.create`." A decision has one action. Say how one request
-is both, for example the method implies `account.create`, or two decisions. This only matters for the Gitea
-and GitHub methods.
-
-N5. Once `host.sudo` leaves the hard waits, a raise from a role that doesn't list it within-role routes by
-REQ-DEC-2. A cited gated raise then goes to an arbiter (`broker.mjs:1677-1678`), not the user. The grant and the
-allowlist still bound it, because `host.run` refuses before any decision (210 `:1733-1735`). It's the same
-pattern 1.7 set for `git.push.remote`. It is still a change in who decides a root command on another host, so
-the notes for Mos should name it.
-
-N6. The chain of command (worker through its PM, PM and CTO direct) has no data in the code (Gizmoduck F1). The
-broker can enforce only "the chief raises". Say in the notes that the chain beyond that is messaging lists and
-role contracts, not a broker check.
-
-Honker's flagged choices are noted and are Mos's to rule on:
- manual mode as a list in the organization file
- REQ-CRED-5 folded into REQ-GRANT-1 to -4
- the chain of command and who may ask
- "the assistant" for revoke
- the Gitea unit, with GitHub left to a later design
-
-A round that changes only B1's and B2's lines and the notes gets a diff check.
@@ -1,62 +0,0 @@
-# Review: Honker PRD 1.8 draft r2 (Vikunja #434, Q188) (duckworth-0058)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per honker-0032:
- 60f5ca8fa on `honker/row194-b2`, one file, `agents/honker/work/queue-194/PRD-1.8-DRAFT.md`, 276 lines,
-  sha256 c3923e07…1e81 (checked). Diff 3c30f1036..60f5ca8fa, +99 -51.
- r2 carries Mos's edits a to f (mos-1124) as well as my items, so I read the whole file again, not only
-  the diff.
- Cites checked on origin/refactor f41729178: `broker.mjs:1674-1680`, `roles/pm.md:55`,
-  `roles/chief-of-staff.md:75`, `vocabulary.mjs:38`, `:46`, PRD :354. Row 210 DESIGN section 5 at a2fd30390
-  (:376-392 holds the proposed text).
-
-## Verdict: approve, with C1
-
-My r1 items:
- B1 is met (:167-169). The stack side is undone at once, and what's left at the host or service stays
-  visible as pending, as under GRANT-4.
- B2 is met (:151-153, :188-190). The user creates a grant by Approve or by writing it in their own
-  business file. The note at :228-232 gives the reason, and it holds: with the other choice, nothing could
-  make a new grant between row 210 landing and #435/#436 landing.
- N1 (:165-166), N2 (:183-184), N3 (:63-66, :171-172), N4 (:144-148, :233-235) and N6 (:148-150,
-  :240-242) are taken. N5 is put to Mos (:236-239), which is right.
-
-Mos's edits a, d, e and f read as mos-1124 describes them. The paragraph for Jason (:13-16) states the
-chief-only reading as Mos's and says how Jason changes it. I have nothing against them.
-
-## Condition
-
-C1. `account.create` covers more than grants. Today it is the hard wait for any new external account
-(PRD :354, `vocabulary.mjs:43-46`), and `roles/pm.md:55` and `roles/chief-of-staff.md:75` both raise it.
-r2 now says two things about it without saying they apply only to grant requests:
- landing step 2 (:54-56): "The broker refuses the raise from any other role", for `credential.mint` or
-  `account.create`
- REQ-GRANT-2 (:171-172): an `account.create` decision without the REQ-GRANT-1 fields makes nothing
-
-Read plainly, a PM can no longer raise `account.create` for an account that isn't a grant, such as a
-service sign-up, and if the chief does, Approve makes nothing. That is a broker change the notes don't
-name, and step 6 still has the PM keep `account.create` in its hard-waits line.
-
-Fix, one of:
- Scope both lines to grant requests: the broker refuses an `account.create` raise that carries a grant
-  method from any role but the chief, and other `account.create` raises stay as 1.7 has them.
- Or say that every `account.create` is now a grant request raised by the chief, and add that to the
-  notes for Mos and to step 6's role contract update.
-
-`credential.mint` doesn't need this. Every credential is a grant under 1.8, so chief-only for it is the
-intent.
-
-C1 gets a diff check on those lines before Sage opens the `prd.approve` decision.
-
-## Notes (do not block)
-
-N1. A grant the user writes in their own business file isn't a request, so REQ-GRANT-1's bounds (a
-rotate-by or expiry date, no shell, no empty command) don't reach it as written. REQ-CRED-4 refuses a
-wildcard either way. Say whether the business file loader enforces the same bounds on a hand-written grant.
-I'd say it should, since the same REQ-CRED-4 path runs it.
-
-N2. The revoke paths (:179-180) include grants the user wrote by hand. The assistant's and the tester's
-revoke then changes what the user wrote in their business file. That's fine, since revoke only narrows.
-The grant code's design (#436) should say that revoke marks the grant as revoked and doesn't rewrite the
-user's file.
-
-A round that changes only C1's lines and these notes gets a diff check.
@@ -1,52 +0,0 @@
-# Diff check: Honker PRD 1.8 draft r3, for duckworth-0058 C1 and mos-1129 (duckworth-0059)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per honker-0034:
- d16ccdb91 on `honker/row194-b2`, one commit on r2 60f5ca8fa, one file, `PRD-1.8-DRAFT.md`, 300 lines,
-  sha256 2fdc13a6…7d23 (checked). The diff is +30 -6 in five hunks, as the header says. I read all of it.
-
-sage-1541 relays Mos's ruling mos-1129, made after r2 went up. B2 takes my second option:
- only an Approve creates a grant
- a hand-written grant in the business file makes nothing
- row 210's hand-edited grants stay a test path until #436a
-
-I haven't read mos-1129 itself. This check takes those three points from sage-1541.
-
-## Verdict: changes, B1
-
-What r3 gets right:
- C1 is met. Landing step 2 (:58-60) and REQ-GRANT-2 (:176-179) apply the chief-only raise and "makes
-  nothing" only to `credential.mint` and to an `account.create` that carries a grant method. A PM's
-  sign-up for a service routes as in 1.7. That matches Gizmoduck's machine-grant r2 R2, where a
-  `credential.mint` with no `grant` keeps today's behaviour.
- The enrollment wording (:162-163) matches the machine-grant r2 E1 and mos-1120 and mos-1125.
-
-## Blocker
-
-B1. r3 still carries the B2 reading Mos didn't choose. These lines say a hand-written grant is allowed:
- REQ-GRANT-2 :155-157, "or by writing it in their own business file on the human's path, as row 210
-  does"
- REQ-GRANT-2 :179-180, a hand-written grant "is held to the same bounds when it is loaded"
- REQ-CRED-1's appended line (:196-198), "A grant the user writes in their own business file, with its key made by
-  hand, stays allowed"
- the B2 note (:236-240) and the N1 and N2 notes (:245-248, :254-256)
-
-Fix, under mos-1129:
- Only an Approve creates a grant. A grant entry the user writes by hand makes nothing: the bus doesn't
-  use it.
- Say what happens to row 210's hand-edited grants. They are a test path until #436a lands. After that
-  the loader refuses or ignores a grant with no Approve record, and the refusal is logged.
- Drop the hand-written-grant bounds sentence and the N1 and N2 notes. Rewrite the B2 note to the
-  ruling.
-
-## My r2 notes under mos-1129
-
-Sage asked whether anything is left of N1 and N2:
- N1 goes away. A hand-written grant makes nothing, so no bounds need to reach it.
- N2 goes too. I also withdraw it on its own terms. It said a revoke never rewrites the user's file. That
-  was wrong: the machine-grant r2 section 6 step 2 drops the grant through the grant writer, and that's
-  safer, because a restart can't bring the command list back.
- One point is left. The text should say how the change from row 210's hand-edited grants to Approve-only
-  happens, as in the second fix bullet. Without it, the row 210 grants that exist when #436a lands
-  either keep working, against mos-1129, or stop with no record.
-
-A round that changes only these lines gets a diff check.
@@ -1,42 +0,0 @@
-# Diff check: Honker PRD 1.8 draft r4, for mos-1129 and duckworth-0059 B1 (duckworth-0061)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per honker-0036:
- 781d91624 on `honker/row194-b2`, one commit on r3 d16ccdb91, one file, `PRD-1.8-DRAFT.md`, 318 lines,
-  sha256 a08ffc95…9833 (checked). The diff is +89 -71. I read all of it.
-
-My r3 diff check (duckworth-0059, changes B1, committed at 9dceb2148) crossed with r4 and wasn't sent on
-its own. r4 answers its B1, so this note replaces it.
-
-## Verdict: approve
-
-B1 from duckworth-0059 is met:
- REQ-GRANT-2 (:170-174): only an Approve creates a grant, the code uses a grant only with a matching
-  Approve record, and a grant written by hand makes nothing. Row 210's hand grants stay a test path until
-  #436a moves `host.run` to Approve-made grants.
- The hand path is out: the bounds sentence on hand grants is gone from REQ-GRANT-2, REQ-CRED-1's append
-  (:209-210) says "not by hand", and the B2 note (:250-258) states the ruling with Q188's reason.
- My 0058 N1 and N2 notes are removed, as 0059 asked.
- The top of the draft (:22-30) names the B7 residual and the `host.sudo` arbiter route for Jason. That
-  matches the machine-grant design's section 9 and its S1 "same-user limit".
-
-The other r4 changes read as mos-1129 rules:
- N4 and C1 (:58-62, :69-73, :163-169): a grant that makes an account is one `credential.mint` decision
-  that shows the account name. `account.create` stays as 1.7 has it, and only `credential.mint` is
-  chief-only. That keeps C1's point: a PM's service sign-up routes as before.
- N1 "the target or its enrolled identity" (:186), N2 (:204), N3 (:192-193), N5 landing step 5 (:78-80)
-  and N6 (:84, :169) are in.
-
-The transition after #436a (what the loader does with a leftover hand grant) is a design matter, and the
-machine-grant design r4 S1 covers it: the loader refuses `hosts` in the business file at load. "Makes
-nothing" in the PRD is enough as an outcome.
-
-## Notes (do not block)
-
-N1. Two notes are stale. Neither is in the requirement text.
- :246-247: "Duckworth hasn't reviewed their draft yet". I've reviewed the machine-grant design r1 to r4
-  (duckworth-0056, -0060).
- :263-267: "Their design gives revoke to the user and the tester only, and their Q-S5 asks Jason…". The
-  design at r3 and r4 (1c5705d6d section 6) follows mos-1124 d, and its Q-S5 is answered. Point the
-  bullet at 1c5705d6d and drop the Q-S5 clause.
-
-Doc-only, so they can be fixed before the text goes into the PRD, without another check.
@@ -1,51 +0,0 @@
-# Review: Honker PRD 1.7 draft, REQ-CRED-3 host access through the credential store (duckworth-0038)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: agents/honker/work/queue-194/PRD-1.7-DRAFT.md at
-0bb1a3bd0 on honker/row194, sha256 0236dee8…40fd (checked), diff +32 -4 over 69544f342, per sage-1428
-item 2. I checked the quotes against DECISIONS.md:1533-1571 in jason-master-restart at 1c368ff (read only),
-and the cited requirements against docs/prd/mosaic-stack.md at 0bb1a3bd0.
-
-## Verdict: changes, B1 and B2
-
-What holds:
- The Q183 quote (draft :47-53) matches DECISIONS.md:1537 word for word, from "I will still want" to "I am a
-  happy man." It leaves out the first and last sentences, and "in part" says so.
- The Q184 quote "Q5: by 10.27" matches :1558. The due date 2026-10-27 is Mos's reading at :1568, and the
-  draft uses it only as the #424 due date.
- "Not every agent gets a grant" and "An agent without a grant for that host is refused" rest on "not all
-  agents will need to have that access" and "The system will enforce access to the credentials".
- "The agent never sees the key or any other secret value" is already PRD law. REQ-CRED-1 keeps tokens out
-  of an agent's environment and files, and REQ-VAR-2 lets only the broker read a secret's contents. Citing
-  both is right.
-
-## Blockers
-
-B1. REQ-CRED-3 (draft :113-114) says the stack "then does the ssh and the sudo for the agent", and landing
-item 5 (:30) says "the stack's ssh and sudo for a granted agent". Jason didn't say that. He said the
-credential "works as some sort of variable for the agent to call" and that "the system will enforce access
-to the credentials". Running the ssh on the agent's behalf is one design. Lending the agent a signing socket
-that never exposes the key is another, and both meet REQ-CRED-1. Which one it is belongs to the #424 design
-(row 210, Gizmoduck), which I review. Fix: state the outcome and the enforcement only. For example: "The
-agent asks for the host credential by name. The stack checks that a grant exists for that agent and that
-host before the credential is used. The agent never sees the key or any other secret value." Change item 5
-to "adds the host credential grant check and the host access it allows (REQ-CRED-3, Vikunja #424)".
-
-B2. The last sentence of REQ-CRED-3 (:116), "Jason grants one through a reviewed role or config change",
-answers the open point that the note at :151-153 says Q183 leaves open. The note says both "Q183 doesn't
-say who grants" and "The text leaves it as Jason through a reviewed role or config change", so the
-requirement invents the answer the note calls open. Fix: in the requirement, say it is open. For example:
-"Who grants a host credential, and how, is set by the #424 design, which Jason approves." Reword the note to
-match. If Sage wants a floor that already exists in the PRD, "a grant changes only through a reviewed
-commit (REQ-ROLE-1)" is sourced, but "Jason grants" is not.
-
-## Notes (do not block)
-
-N1. Jason's words name "infra agent(s) on my .53 instance". REQ-CRED-3 is general, which is fine because
-the grant gates it. The source bullet carries the scope, so nothing is lost.
-N2. Jason's outcome is NOPASSWD sudo. REQ-CRED-3 says only "with sudo". That's fine if the design keeps
-sudo passwords out of the agent's hands too, which REQ-CRED-1 already requires of any secret. The design
-review checks it.
-N3. "Jason through Mos (mos-1067), DECISIONS Q183" (:47): Jason said it in Mos's thread 38bc4c81, and Mos
-recorded it. "Recorded by Mos" would be more exact than "through Mos". Doc-only.
-
-A round with only B1 and B2 changed gets a diff check, not a full re-read. Sage's cutoff is 23:00Z.
@@ -1,19 +0,0 @@
-# Review: Honker PRD 1.7 draft r2, REQ-CRED-3, diff check (duckworth-0039)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: agents/honker/work/queue-194/PRD-1.7-DRAFT.md at
-11cb0423b on honker/row194, sha256 e896746d…8647 (checked), per honker-0019. 11cb0423b is a fast-forward
-of 0bb1a3bd0, and the diff touches that one file only, +12 -11. I read the diff only, as REVIEW-r1 said I
-would.
-
-## Verdict: approve
-
- B1 resolved. REQ-CRED-3 states the check, "before the credential is used", and no longer says how the
-  stack reaches the host. Item 5 reads "the host access it allows". The new note says the #424 design
-  picks the path.
- B2 resolved. The requirement now says who grants, and how, is set by the #424 design, which Jason
-  approves. The open-point note matches it and no longer names a granter.
- The build line (row 210, #1707, Gizmoduck, on top of row 199) is Sage's routing (sage-1430). It is a
-  reviewer note, not PRD text.
- Nothing outside B1, B2 and those notes changed. The quotes I checked in r1 are untouched.
-
-N1 to N3 from r1 stay as notes.
@@ -1,59 +0,0 @@
-# Review: PRD 1.7 and 1.8 landing (duckworth-0075)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1636 and sage-1641. Subject:
-`honker/prd-17-18` 46c8adaeb, parent 011d41ba6, 4 files. Checked:
- `docs/prd/mosaic-stack.md`: 1196 lines, sha256 a5bba06c…4fc6209f3.
- Sources: 1.7 is `PRD-1.7-DRAFT.md` at 9ba31b5b3, sha256 e896746d…1d328647. 1.8 is r7 at 82df17347,
-  sha256 de079281…727440cd.
- refactor 816d48b03 hasn't touched the four paths since 011d41ba6.
-
-## Verdict: approve, no change to what any requirement allows or forbids
-
-1. Every word of each requirement matches its source. A script took each quoted block of both drafts,
-   collapsed the whitespace and checked each item for one contiguous match in the landed file. All 42
-   items match, including every sub-bullet, the CRED-1 and WAIT-3 appends and the risks bullet. The only
-   two misses are the status sentences, where the drafts had a `<prd.approve decision id>` placeholder.
-   I read the whole diff (8 hunks), and no added line comes from anywhere but the drafts or the five
-   deviations below.
-2. The deviations are layout and approval record only:
-   - The status field goes from 1.6 to 1.8. The 1.6 landing bumped this same field in place
-     (63c82f1c4).
-   - The 1.7 status cites decision d52febb5 (prd.approve, yes). DECISIONS:1611 confirms decision 21
-     was resolved yes by jason at 2026-10-20T20:36:47Z on the 9ba31b5b3 file.
-   - The 1.8 status says Jason approved it in T3 through Mos (Q192). Its source bullet quotes
-     DECISIONS:1765 exactly, and the Q191 source bullet quotes :1745 ("Q13: that looks better")
-     exactly.
-   - COS-3's 1.7 block sits after ASSIST-3, the last item of the 1.2 list, so the 1.2 items keep
-     their heading.
-   - The CRED-1 append is a paragraph inside CRED-1 after its Vikunja sub-bullet. The two WAIT-3
-     appends are paragraphs inside WAIT-3, the last item before `### Messages`.
-   - TRUST sits after DEC-6, the last Decisions item. CRED-4 and GRANT-1 to 4 sit after CRED-3.
-     LAND-2 sits after LAND-1. The risks bullet ends that list.
-3. The ten ids are COS-3, CRED-3, CRED-4, GRANT-1 to 4, TRUST-1, TRUST-2 and LAND-2. Each appears in
-   the PRD as a `- **REQ-X-N.**` bullet and in `requirements.json` with the same id and in the same
-   order. `tasks/tests/requirements.test.mjs` asserts the id list equals the PRD's in order, that no
-   bold id is missed, the count of 68 and version 1.8, and that the status line names that version.
-4. The titles don't change what any requirement allows or forbids. COS-3, CRED-3, GRANT-1, GRANT-3,
-   GRANT-4, TRUST-1, TRUST-2 and LAND-2 are fair summaries. GRANT-2 drops "and the target", but it
-   leaves nothing allowed that the text forbids. On CRED-4 see N1.
-5. Pins. The tasks test moves 58 to 68, '1.6' to '1.8', and the `twice` index to [68]. Bus
-   `requirements.test.mjs:48` moves 58 to 68. No other test pins the count or the version. No test or
-   script pins a hash of the PRD or `requirements.json` (0 hits, control 11).
-   `requirements.json` is in `scripts/stack-copy.sh:30` and `cli stack-copy.test.mjs:37` as a path
-   only.
-
-My runs, in a detached worktree of 46c8adaeb:
- tasks: requirements 3/0, verbs 31/0, and the whole tasks package 97/0.
- bus: requirements 3/0.
-
-## Notes (do not block)
-
-N1. The CRED-4 title, "...only with its kind declared, a grant, an allowlisted command and a live key",
-is stricter than the requirement in two places:
- The allowlist applies only "for a command", but the title reads as if every grant action needs an
-  allowlisted command. A Gitea token use has none.
- "live key" drops "or token".
-The PRD text governs, and a stricter label permits nothing extra, so this isn't an allow/forbid
-change. Agents do read the titles through the bus `requirements` verb, though. A possible wording:
-"A within-role grant action needs no decision only with its kind declared, a grant, a live key or
-token and, for a command, an allowlisted command". Sage's call.
@@ -1,30 +0,0 @@
-# Delta check: REQ-CRED-4 title (duckworth-0076)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in honker-0064 (sage-1644, my duckworth-0075 N1).
-Subject: `honker/prd-17-18` 46c8adaeb..c03d660e7. One line of `packages/tasks/requirements.json`
-changes, and nothing else.
-
-## Result: approve, one note
-
-The new title is "Within-role grant actions need no decision with the kind declared, a grant, a live key
-or token, any command allowlisted". It's 120 characters, exactly the schema's limit
-(`packages/tasks/src/requirements.mjs:33`).
- "live key or token" now matches the text.
- "any command allowlisted" applies only when there is a command, which also matches.
- Nothing else in the file changed.
-
-N1 (doesn't block). The old title said "only with". The new one drops "only", so it lists the
-conditions as enough to skip a decision but no longer says they're required. REQ-CRED-4 says "only when
-all of these hold". The title states nothing false and permits nothing the text forbids, and the PRD
-governs. Still, the one word that carries the requirement's restriction is gone.
-
-This wording keeps "only" in 117 characters: "A within-role grant action needs no decision only if kind
-declared, grant, live key or token, any command allowlisted". Sage's call.
-
-## Follow-up: 2884ee496 (duckworth-0077)
-
-Asked in honker-0066 (sage-1648). 2884ee496 on c03d660e7 changes one line of
-`packages/tasks/requirements.json` and nothing else. The REQ-CRED-4 title is now my 117-character
-wording, byte for byte. That resolves N1. Approve, no notes.
-
-My runs, in a detached worktree of 2884ee496: tasks requirements 3/0, bus requirements 3/0.
@@ -1,32 +0,0 @@
-# Scoped check: PRD 1.8 r7 with follow-up, 762a6711f..82df17347 (duckworth-0073)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1624, sage-1627, sage-1632 and sage-1633 (Jason
-Q191, mos-1149, mos-1152). Subject: `honker/prd18-r7` at 82df17347, two commits on r5 762a6711f: 47c2cb33c
-(r7) and 82df17347 (Mos's r6 rulings). One file, `agents/honker/work/queue-194/PRD-1.8-DRAFT.md`, 342
-lines, sha256 de079281…727440cd (checked), 8+/4- against 47c2cb33c (checked). This is the one verdict
-for both commits. It includes duckworth-0072 (`REVIEW-r7-scoped.md`, the r7 commit and the enforcement
-note at 011d41ba6).
-
-## Result: passes the scope, no findings
-
-r7 (47c2cb33c), from duckworth-0072:
-1. The only changes are the revision paragraph, the top note, one sentence added to REQ-GRANT-1, and the
-   risks notes. No other requirement text changes.
-2. The top note and the REQ-GRANT-1 sentence match sage-1624 word for word.
-3. "one role under two names" is gone from the file.
-4. Every file:line in the enforcement note is true at refactor 011d41ba6 (list in `REVIEW-r7-scoped.md`).
-
-Follow-up (82df17347 against 47c2cb33c). There are four hunks, all in scope:
- `:18-20` revision clause: it names Mos's rulings on r6 items 1, 3 and 4 (mos-1152) and describes the
-  three edits correctly. Item 2 isn't claimed.
- `:25` (b): "Also for Jason at approval:" is now "For Jason at approval:".
- `:27-28` (1): the first bullet under the heading is Mos's sentence, word for word as sage-1632 quotes it:
-  "Q188's 'you, Mos or the tester' is read as the user, the assistant for grants in its own organization,
-  and the tester only on a dev instance (Mos's reading, mos-1124 d)."
- `:253` (3): the citation is now "design r1 to r4 (duckworth-0056 and duckworth-0060)". Both labels are
-  right. 0056 is my machine-grant r1 review (f6b6a04b6). 0060 is my r3+r4 review (1c5705d6d), and my r2
-  draft was dropped unsent, as SESSIONS records.
- `:273` (4): ", and their Q-S5 is answered" is removed. The sentence now ends at "(mos-1124 d)." Nothing
-  else in that bullet changed.
-
-No other line changed, and the file no longer contains "Also for Jason" or "Q-S5".
@@ -1,46 +0,0 @@
-# Scoped check: PRD 1.8 draft r7 (duckworth-0072)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1624 and sage-1627 (Jason Q191, mos-1149).
-Subject: `honker/prd18-r7` at 47c2cb33c, one commit on r5 762a6711f, one file:
-`agents/honker/work/queue-194/PRD-1.8-DRAFT.md`, 338 lines, sha256 a50ce730…b0551e (checked), 29+/10-.
-Sage's scope only. The dangling "Also for Jason at approval:" is known (sage-1627) and not reviewed
-here.
-
-## Result: passes the scope, no findings
-
-1. No other requirement text changed. The diff has four hunks:
-   - the revision paragraph (`:16-18`, convention)
-   - the top note (`:20-21`)
-   - one added sentence at the end of REQ-GRANT-1 (`:170-171`)
-   - the two "Risks and open questions" notes (`:293-314`)
-   REQ-GRANT-2 onward and every other requirement are unchanged.
-2. The quoted lines are exact.
-   - Top note: "Only the chief of staff raises a grant request. The assistant, the user's main agent,
-     never raises one. It passes the user's request to the chief and can revoke a grant in its own
-     organization."
-   - REQ-GRANT-1: "The assistant and the chief of staff are separate roles. No agent holds both, and the
-     broker refuses a claim that would."
-   Both match sage-1624 word for word.
-3. "Which roles may request" no longer reads "one role under two names". That phrase appears nowhere in
-   the file. The note now says the assistant is a separate role, passes the request to the chief
-   (REQ-ASSIST-1) and can revoke in its own organization (REQ-GRANT-4).
-4. Every file:line in the enforcement note is true at refactor 011d41ba6:
-   - `business/src/business.mjs:118-120`: the instance's single `definition` is required and loaded.
-   - `business/src/vocabulary.mjs:134`: `THREAD_DEFINITION = "assistant"`.
-   - `bus/src/broker.mjs:164` (`STAFF_TO = 'chief-of-staff'`) and `:2137` (the `no-chief-of-staff`
-     check against `STAFF_TO`).
-   - `broker.mjs:451-456`: `bindLaunch` takes one `role` (keys at `:454-455`). `:478` sets the run key
-     as `business:run`. `:479` gives `duplicate-run`, and `:499` gives `launch-record-mismatch` on a
-     rebind under another role.
-   - `cli/src/launcher.mjs:438-449`: one `spawnSession` with `role: instance`, then one `bindLaunch`
-     for that instance.
-   - `broker.mjs:1689-1734`: `role.claim` writes only `s.role`. `:1693-1709` is the thread branch,
-     which writes `thread_claims` and returns before `role_claims`. A threaded definition must bind a
-     thread (`:474`, `thread-required`), so an assistant run always takes that branch.
-   - `bus/src/migrations/3b.sql:117-119`: `role_one_holder`, unchanged in `schema.sql:117`.
-   - `broker.mjs:34`: `credential.mint` is in ACTIONS (`:9-43`) and not in ROUTED (`:46-69`), so it's
-     in HARD_WAITS (`:71`). There's no other use in bus or business src, so no check limits which role
-     raises it, as the note says.
-
-The "not enforced" claims also hold. The run key is per business, and nothing in the broker ties two
-runs to distinct processes or users beyond the launcher's record.
@@ -1,107 +0,0 @@
-# Review: ops-01 Q180 tightening plan r2 (duckworth-0023)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review of the document. I ran nothing on pve, PBS, .53 or
-.54. The PVE and PBS permission rules below come from ops-01's reading of the local schemas and source, and
-I didn't re-check them.
-Subject: /mnt/storage/scratch/tmp/mosvk/q180-tightening-plan.md, written 19:31:42Z, sha256 1084aa15…585f
-(checked), Vikunja #421. Mos asked for four checks (mos-1025), and ops-01 asked five questions. Both are
-answered at the end. Cross-checked against FED R8 at eb651aa68.
-
-## Verdict: changes, B1 to B5
-
-The diagnosis in §0 is right and the order is right: §1 first, because one key that both Jason and the
-factory use opens root everywhere. Removing sudo entirely, instead of moving to a sudo password, is right
-for accounts that run agents. Five gaps block it.
-
-## Blockers
-
-B1. Lockout (Mos check 1). The plan relies on "nothing if 1a holds" and an open console session. Neither is
-proven before the step that depends on it.
- Before 1d, and before each of 2a to 2c, Jason logs in with the new key from a fresh session to each account
-  that step leaves him: root on pve, root on PBS, and localadmin on .53 and .54, plus a `sudo -v` there. The
-  step runs only after he has.
- Say whether localadmin's sudo takes a password. The `sudo` group asks for one by default, and localadmin
-  has none today. If it's NOPASSWD, say so on purpose.
- The rollbacks for 2a to 2c say "console in". A cloud-init image usually has root locked. So a console login
-  on .53 and .54 needs a local password that only Jason holds, tested through the pve console before 2c.
- Jason's pve web login (root@pam or his own user) is the fallback for all of the above. Confirm it works
-  and that no factory-readable file holds it.
-
-B2. Where the new key lives. Two things decide it.
- FED R8 fingerprints every private key under every home on every factory host, dragon-lin included. The
-  gate fails if any of them matches an `authorized_keys` on the hub host.
- localadmin on .54 trusts Jason's new key.
-
-So the new key, or a FIDO key handle file, can't sit under any home on dragon-lin, and R8 would fail if it
-did. A FIDO key used from dragon-lin also lets any factory process in Jason's agent socket ask for a touch.
-The plan should say "a key on another machine" and drop the dragon-lin FIDO option. After this, Jason admins
-.54 from a machine that isn't a factory host, or through the pve console.
-
-B3. Group removal doesn't reach processes already running (2a, 2b). Supplementary groups are fixed when a
-process starts. Hermes's 12 user units, openclaw-gateway and the others keep `docker`, `lxd` and `sudo`
-until jarvis's user manager restarts. melanie's two gateways are the same.
- After the change, restart `user@<uid>.service` for each account, or end every process the account has.
-  Then show that no process of that uid lists the removed gids (`Groups:` in /proc/<pid>/status).
- List any uid 0 process started from a jarvis or melanie session through sudo (by loginuid), and end it.
- Losing the `docker` group doesn't close a Docker API on TCP, or a container that mounts docker.sock behind
-  a UI jarvis can reach. Check both on .53, by name only.
-
-B4. Cloud-init order (Mos check 3). Yes, cloud-init can rewrite sudoers. A change to a VM's cloud-init
-settings on pve regenerates its config drive. A new instance id makes per-instance modules run again at the
-next boot, and those write `90-cloud-init-users` and the keys back. 1012 has a boot scheduled at
-2026-10-21T09:00Z (§5). The order has to be:
-1. In the guest: remove `90-cloud-init-users` and create `/etc/cloud/cloud-init.disabled`.
-2. Then on pve: clear `sshkeys`, and on 1012 clear `ciuser` too if it isn't needed.
-
-The plan has these the other way round. Also check after the 09:00 boot that `90-cloud-init-users` is still
-gone.
-
-B5. Paths the plan leaves unaccounted for (Mos check 4). The plan inventories ssh keys only. These other
-paths can reach the hub VM, its backups or its issuer. Each one needs to be either closed here or listed as
-open with an owner, so R8's table can name it.
- PVE and PBS accounts: `pveum user list`, token and ACL lists, and the same on PBS. Any account or token
-  whose secret is factory-readable (dragon-lin, .53, a Hermes profile) is a path.
- PBS `root@pam!pve-backup`, which has Admin on `/`. Where is its secret? Remove it unless something needs it.
- Rollback copies (§4). The 1e rollback restores the pve→PBS password file "from the copy". Copies of
-  secrets and of sshd or sudo files have to stay on the host they came from, root-only (for example
-  `/root/q180-rollback/`). They can't go under `~/.config/mosaic-dev/` on dragon-lin, which the factory can
-  read.
- Storage backing. Say where 1012's disks and the PBS datastore physically live. If either is on TrueNAS or
-  other network storage, then root or a share on that storage reads the guest disk or the backup chunks,
-  around every PVE and PBS check. The `jwoltje@truenas` key and the "tank" migration point that way.
- The two step-ca containers on .53, which is a factory host. Say what they sign. If they sign anything the
-  hub or its sign-in provider trusts, they are the R8 "certificate authority" item.
- The hub's sign-in issuer: which host runs it and who can admin it. The plan doesn't name it.
-
-## Notes (do not block)
-
-N1. OpsAudit (§1.1) has to be two roles. A role brings all its privileges to every path it's granted on.
-One role holding `Sys.Audit` and `VM.Audit` granted on `/vms` would open monitor `info`. Use one role
-(`Sys.Audit`, `Datastore.Audit`, `Pool.Audit`) on `/nodes` and `/storage`, and a second role (`VM.Audit`
-only) on `/vms`. Add three endpoints to the table, with what each one shows for 1012:
-`nodes/{node}/report`, other users' task logs (`tasks/{upid}/log`) and the VM firewall log. Check whether
-1012 sits in a pool with an ACL, since that is a second grant path to the VM.
-N2. Melanie's Hermes on .54 conflicts with FED R8 ("the hub host runs no other instance or agent"). R8
-can't pass until those gateways leave .54. Also, all 11 melanie logins came from dragon-lin with the jason
-key, so after 2b Melanie has no ssh into .54 at all. Say whether that's intended.
-N3. The 1b watch fails every hour until it's switched to the API. Switch it in the same step, or silence the
-row for the change window, so the failure doesn't train people to ignore that row.
-
-## Answers
-
-Mos (mos-1025):
-1. Lockout: possible as written. B1 closes it, and B2 decides where Jason admins from.
-2. PVEAuditor and DatastoreAudit on 1012: the §1.1 and §1.2 tables are consistent with what I know of
-   PVE 9 and PBS 3. Monitor `info` is the one inside-guest leak, and N1's two-role split closes it. Config
-   and listings show metadata only, with cipassword masked.
-3. Cloud-init can rewrite sudoers: yes. B4.
-4. Remaining factory paths: yes, the B5 list. The factory key and jarvis@w-jarvis are closed by §1 and §2.
-   Accounts, tokens, storage, the CA and the issuer aren't covered yet.
-
-ops-01:
-1. §0: agreed, and §1 first.
-2. §1.1: N1. Nothing else from inside a guest that I can name. B5's storage item is the larger leak.
-3. §1.2: agree with deferring encryption, on the three conditions plus B5. That means no factory reach to
-   the datastore's backing storage, and no factory-readable PBS credential, including `pve-backup`.
-4. §2: agree, with B1, B3 and B4.
-5. §6: Jason's call. I agree that Q180 has to override Q172 on these four hosts, or the hub has no boundary.
@@ -1,70 +0,0 @@
-# Review: ops-01 Q180 tightening plan r3 (duckworth-0028)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I reviewed the document only and ran nothing on pve, PBS, .53 or .54.
-Subject: /mnt/storage/scratch/tmp/mosvk/q180-tightening-plan.md, sha256 cd7165bf…0bc3fce (checked), Vikunja
-#421. Checked against duckworth-0023 (REVIEW-r2.md, 523a6bddf) and mos-1041 as ops-01 relays it.
-
-## Verdict: changes, B6
-
-B1 to B5 are resolved, and so are N1 to N3:
- B1: the Jason checklist does what B1 asked. It adds a fresh login with the new key on every remaining
-  account before 1d, 2a, 2b and 2c. It adds a console password tested through noVNC, and a pve web login
-  from the non-factory machine only. That last one is Mos's N4, and the browser-profile reason is right.
-  localadmin's sudo takes a password.
- B2: the new key never touches a factory host, and the FIDO-on-dragon-lin option is gone.
- B3: after the change, each account restarts its user manager and runs terminate-user. A /proc `Groups:`
-  count must then be 0. uid 0 processes are found by loginuid. The Docker TCP and socket-mount checks were
-  read at 19:39Z and get re-read right before 2a.
- B4: the order is guest first, then pve, and is checked at the next boot. The 09:00Z boot of 1012 gets a
-  meta dump before and after, an instance-id comparison and hashes.
- B5: §1.4 closes each path or gives it an owner. The hub's sign-in issuer is open, and Sage owns it. The
-  plan says that the row has to be filled before the plan is complete. That meets B5. It also means R8
-  can't pass until the row is filled.
- N1: two roles, and no pools. Your `nodes/pve/report` finding (Report.pm dumps guest configs raw, so the
-  `cipassword` hash comes through `Sys.Audit`) is a good catch. Step 1a2, done before `OpsAuditHost` is
-  granted, is the right fix.
- N2 and N3: done.
-
-## Blocker
-
-B6. Root access already granted isn't undone by removing it. This is new in r3, and it is my miss in r2.
-For a long time, factory processes had root on all four hosts:
- the jason key, which is dragon-lin's key, on pve, PBS and root on .53 and .54
- jarvis@w-jarvis on pve, 1416 Hermes logins
- NOPASSWD sudo for jarvis and melanie
-
-The plan removes these paths, but anything a factory process left behind as root survives that. Examples:
- another file in sudoers.d
- a key in a different user's `authorized_keys`, or in `/etc/pve/priv/authorized_keys`
- a uid 0 line in `/etc/passwd`
- a root cron entry or systemd unit
- a setuid binary, `ld.so.preload`, or a PAM or sshd drop-in
-The hub (.54) is the host where R8 needs this ruled out. The plan needs one of these, before 2b, with an
-owner:
- (a) A read-only sweep on pve, PBS, .53 and .54, reported by name, owner, mode and hash only:
-  - every file in `/etc/sudoers.d` and `/etc/sudoers`
-  - every `authorized_keys` file on the host, found with `sshd -T`'s `authorizedkeysfile`, plus any
-    `authorizedkeyscommand`
-  - uid 0 and gid 0 accounts in `/etc/passwd`
-  - root and system crontabs and `/etc/cron.*`
-  - units in `/etc/systemd/system` and `/etc/systemd/user` that no package owns
-  - setuid and setgid files that no package owns, and `dpkg -V` failures for sudo, openssh, pam and
-    systemd
-  - `/etc/ld.so.preload`, and drop-ins under `/etc/pam.d` and `/etc/ssh/sshd_config.d`
-
-  Jason reviews anything unexpected, and the sweep runs again after §2.
- (b) Rebuild 1012 from a clean image instead of cleaning it in place. That fits N2 too, since Melanie's
-  Hermes has to leave the hub anyway.
-
-## Notes (do not block)
-
-N4. localadmin's password has to exist at 1a. 1a creates localadmin with sudo by password, and the
-checklist runs `sudo -v` there before 2a. But the console-password line says "before 2c". Jason sets the
-password himself with `passwd localadmin` in the pve console when 1a runs. It never goes through a factory
-session or script. The noVNC test can stay before 2c, or move up to 1a.
-N5. Before `OpsAuditHost` is granted, run `pvereport` once as root on pve. Count the matches for password,
-secret, token, key and `BEGIN` lines, and print counts only. That checks your by-filename reading of
-Report.pm against this PVE build.
-N6. On pve, `/root/.ssh/authorized_keys` is a link to `/etc/pve/priv/authorized_keys`, which the cluster
-filesystem holds. Edit that file, copy that file, and say so in 1d. Then check that `pvecm updatecerts` (or
-an upgrade) doesn't add back anything other than root@pve.
@@ -1,80 +0,0 @@
-# Review: ops-01 #423 VM tightening r4, steps 1 to 3 (duckworth-0032)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I reviewed the document only and ran nothing on pve, .53 or .54.
-Subject: /mnt/storage/scratch/tmp/mosvk/q183-vm-tightening-r4.md, sha256 03cd1075…cbc05f (checked), 122
-lines, Vikunja #423. This is ops-01's 20:00:49Z amendment of eadff6b6. I read eadff6b6 in full. In the
-amendment, lines 1-49 (§0 to §3) are the same apart from the §0 step-ca correction at :20, and §8 is new.
-Checked against the mos-1054 remap of my r2 items, my mos-1060 carry item and mos-1062 (step 4 is on hold
-per mos-1061, and step 5 waits for Bean and Chet). Per mos-1065, step 1 runs first after approval.
-
-## Verdict: changes on steps 1 to 3, B1 only
-
-Step 1 and step 3 can run as written once B1 is in the text. If r5 changes only B1 and any notes ops-01
-takes, I will check the diff and approve it without a full re-read.
-
-What holds:
- mos-1060 carry: met. NOPASSWD comes from its own `50-localadmin` (0440, `visudo -cf` then `visudo -c`),
-  localadmin is made with `useradd`, and neither `90-cloud-init-users` nor a cloud-init `users:` block is
-  involved. The §3 post-boot check covers the `50-localadmin` hash.
- B1 (r2) as remapped: one lockout check, `ssh localadmin@<vm> sudo -n true`, before any removal and again
-  before each later step (:30).
- B4 (r2): `cloud-init.disabled` in the guest first, then the field deletes on pve, then a meta dump and an
-  instance-id and hash check at the next planned boot (:44-46). Deleting fields will change the config
-  Proxmox renders, so a new instance-id is expected. With cloud-init already disabled it does nothing,
-  which is why this order is the right one.
- B5 (r2) as remapped: in-VM paths and the 1008/1012 cloud-init fields only (:5).
- Rollback copies stay root-only on the host they came from (:8).
-
-## Blocker
-
-B1. Step 2's verify can't tell whether `PermitRootLogin no` took effect (:36-37). sshd keeps the first value
-it reads for a keyword. Ubuntu's and Debian 12's `sshd_config` put `Include /etc/ssh/sshd_config.d/*.conf`
-at the top, and drop-ins load in lexical order. §0 records `PermitRootLogin without-password` but not where
-it is set. If it is in a drop-in that sorts before `60-q183.conf` (`50-cloud-init.conf` is a common one),
-that value wins and `60-q183.conf` does nothing. `sshd -t` only checks syntax. `ssh root@<vm>` is refused
-either way, because the key is gone, so the stated verify passes in both cases.
-Fix, in step 2's verify:
- `sshd -T -C user=root,host=x,addr=127.0.0.1 | grep -i '^permitrootlogin'` prints `permitrootlogin no`.
-  If it doesn't, find the earlier setting, then rename the drop-in to sort first or edit the setting itself.
- From the same `sshd -T`, read `authorizedkeysfile`, and confirm that every file it names under `/root`
-  holds no key (`.ssh/authorized_keys2` is in the default list). Report counts only.
-
-## Notes (do not block)
-
-N1. Step 1 `useradd` does not make a home directory without `-m`, and the default shell may be `/bin/sh`.
-Write `useradd -m -s /bin/bash localadmin`. `~/.ssh` should be 0700 and `authorized_keys` 0600, both owned
-by localadmin, or `StrictModes` refuses the key. The lockout check would catch either, but it's cheaper to
-get it right the first time.
-N2. Step 1 copies "the jason key" from root's file (:29). Copy only that key line, matched by fingerprint,
-without any options in front of it. Cloud-init's `disable_root` writes a `command="echo 'Please login as
-…'"` prefix into root's file. If that prefix is copied, every localadmin login runs it. The lockout check
-would fail closed on it.
-N3. Write the sudoers file to a temp path, run `visudo -cf` on it, then `install -m 0440 -o root -g root` it
-into place, then `visudo -c`. A file that fails the check never sits in `/etc/sudoers.d`, where a syntax
-error makes sudo refuse to run.
-N4. Before step 2, check whether anything logs in as root by key on a schedule. Count `Accepted publickey
-for root` lines in the ssh journal for the last 14 days, by source address. Report counts only. A
-scheduled job like that would break at step 2 and nobody would notice until it fails.
-N5. The step 2 rollback names the pve console as a way in (:40). A console login needs an account with a
-password, and none is planned (B1 was remapped to the key check). The real fallback is pve root. Before
-step 2, check `qm agent <vmid> ping` for 1008 and 1012. If the guest agent answers, `qm guest exec` is the
-way in. If not, say the fallback is a rescue boot.
-N6. Add to the §3 post-boot check: `ssh localadmin@<vm> sudo -n true` = 0, and the VM's address is
-unchanged. Disabling cloud-init leaves the rendered netplan in place, but this check proves it.
-N7. Step 3 rollback (:49): `qm set --cipassword` takes plaintext and hashes it, and `--sshkeys` takes a key
-file. Neither can take the values saved in the conf. Restore those lines by writing them back into
-`/etc/pve/qemu-server/<vmid>.conf` from the root-only copy.
-
-## Your questions
-
-(a) Yes, the statement is accurate. One more thing should be stated: pve root reaches every guest's disk
-and `qm guest exec`. So for a process running as jarvis on .53, the jarvis key is root over 1008 and 1012
-too, through pve. What §4 narrows is mistakes made inside .53, not an attacker with the jarvis key. Q183
-point c and R8 record that this is accepted, so this doesn't block.
-(b) Agreed. localadmin holds NOPASSWD sudo with the same key, so taking the jason key out of jarvis's or
-melanie's file narrows nothing.
-(c) On step 4 I'll give my verdict later, per mos-1062. mos-1061 holds it until Case 1 is live on .53 and
-the sudo and docker flows have another path. That covers the step-ca stacks.
-I have not reviewed steps 4 and 5 in this round. §6 is unchanged from r3.
-One count for when step 4 comes back: §8 (:121) says 20 sudo uses, but 9 + 12 = 21, and the per-command
-list adds up to 18. Recount them before step 4's review.
@@ -1,64 +0,0 @@
-# Review: ops-01 #423 step 4 scripts, revised, C1 to C4 check (duckworth-0048)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I read the scripts and ran nothing on pve or .53. Subject,
-per ops-01's REVIEW-REQUEST, in /mnt/storage/scratch/tmp/mosvk/o423/ (sha256 prefixes checked):
- step4.sh 5aea3856fdd48d27, 46 lines
- check4.sh 8f49a40937948be6, 46 lines
- containers.sh 837bb7a439e58f14 (new), 33 lines
- postboot.sh 0f2f510bbaba09e0 (unchanged)
- boot-session.md f0645604f4483cbb
-
-I read all five in full. I had already read postboot.sh in full for duckworth-0046, whose C3 rests on its
-:36-38. This round I read it again.
-
-## Verdict: C1 to C4 met. The optional block may run once C5 is fixed
-
-C1. step4.sh :14 aborts before any change if `/etc/cloud/cloud-init.disabled` is missing. In 0 and 0',
-anything other than a dry-run result of exactly fail=1 is a stop. If step 3.1 hasn't run on 1008, it runs
-first. postboot.sh :41-42 checks the file and `cloud-init status` again after the boot.
-
-C2.
- After the change, step4.sh :41 matches the refusal line "User jarvis is not allowed to run sudo".
- After the boot, check4.sh :29 matches the same line again, and :30 requires `/etc/sudoers.d` to be
-  exactly `50-localadmin README`.
- ops-01 checked the line format against `nobody` on .53.
- `sudo -n true` refused is kept as an extra line, not the proof.
-
-C3, including Mos's addition.
- step4.sh :16-20 compares the current hashes and addresses with the step 3 baseline before any change,
-  and aborts with the names that differ. So drift in `50-localadmin` or `01-q183.conf` can't become the new
-  baseline.
- The new baseline (:44) is written after the change and records `90-cloud-init-users` as absent.
- postboot.sh :36-38 reports a DIFF if the file reappears.
-
-C4.
- containers.sh save records names and restart policies before the shutdown, and refuses an empty save.
- compare reports each saved name that isn't running and requires homeassistant, esphome and
-  mosaic-gw-valkey. check4.sh :45 counts compare's DIFF lines as failures.
- start uses `ssh -n`, and compare reads its list from a here-string, so neither loop eats its input.
- The plain 1008 path calls save and compare too (boot-session :23 and :29).
-
-N1, from duckworth-0046: the fallback order in 1' is now `qm guest exec`, then the console, then the offline
-edit. `qm guest exec 1008 -- /bin/true` was tested. The rollback line names `qm guest exec` too.
-
-## Condition
-
-C5. boot-session.md's optional block, line 2, still names the old shas: step4.sh 0ab0f36e…, check4.sh
-408325f5…. Its dry-run line says fail=8. Change the line to the reviewed shas, step4.sh 5aea3856…, check4.sh
-8f49a409… and containers.sh 837bb7a4…, with the fail=10 dry run. Then 0' runs `sha256sum` on the three
-scripts and stops on any mismatch. That way the scripts that run are the ones reviewed here. It's a doc
-line, so it doesn't come back to me. Report the sha check's result with the step's output.
-
-## Notes (do not block)
-
-N1. step4.sh exits 0 even when `groups_left` isn't 0 or `jarvis_not_allowed` isn't 1. It only prints them,
-and 1' relies on the operator reading the Expect line. An `exit 1` on either, after the changes and
-before the baseline is written, would make 1' stop by itself before the shutdown. The rollback is already
-written by then.
-N2. step4.sh creates the rb dir (:8) before its prechecks, so an abort leaves an empty
-`step4-<ts>` dir behind. That's harmless, but use the newest dir with a `rollback.sh` in 3' and in any
-rollback, not just the newest dir.
-N3. The two step-ca containers are in a restart loop. Between attempts, `docker ps` may not list them, so
-compare can report a step-ca DIFF that comes from the loop, not from the boot. If the only DIFF lines are
-step-ca, run compare again after a minute before treating it as a failure. Don't `start` them, because
-they were looping before.
@@ -1,25 +0,0 @@
-# Check: ops-01 #423 step 4, N1 and N2 diff and C5 (duckworth-0049)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I read the files and ran nothing on pve or .53. Subject, from
-ops-01's FYI after duckworth-0048, in /mnt/storage/scratch/tmp/mosvk/o423/ (sha256 checked):
- step4.sh cc16d38401e5792e, 47 lines, read in full
- boot-session.md ed44ec81b74361cf, sha and N3 lines read
- check4.sh 8f49a409, containers.sh 837bb7a4 and postboot.sh 0f2f510b are unchanged from duckworth-0048
-
-Mos checked the same diff in mos-1095 and cleared the block. This is my own read, so the record shows it.
-
-## Verdict: the diff holds, and so does duckworth-0048
-
- N2. `install -d -m 0700 "$rb"` is at :20, after the localadmin check (:8), the C1 guard (:13) and the C3
-  comparison (:15-19). An abort at any of them leaves no step4 dir.
- N1. :47 exits 1 with "do not shut down" unless `groups_left` is 0, the refusal line matched,
-  `90-cloud-init-users` is gone and `/etc/sudoers.d` is exactly `50-localadmin README`. An `A && B || {}`
-  list doesn't trip `set -e`, so the message prints. By then rollback.sh is written (:25-34).
- C5. boot-session.md :33-34 names all four reviewed shas and the fail=10 dry run. :39 makes 0' a sha256sum
-  gate that stops on any mismatch.
- N3 is at :29 and :63 for both 1008 paths.
-
-## Note (does not block)
-
-N1. If :47 fails, `baseline.txt` (:44) already holds the failed state. Nothing reads it because the step
-stops before the shutdown, but a rerun after a fix writes a new `step4-<ts>` dir. Use that one for 3'.
@@ -1,59 +0,0 @@
-# Review: ops-01 #423 step 4 scripts against duckworth-0045 C1 to C4 (duckworth-0046)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I read the scripts and ran nothing on pve or .53. Subject,
-from ops-01's FYI, in /mnt/storage/scratch/tmp/mosvk/o423/ (sha256 checked):
- step4.sh 0ab0f36e…902a, 36 lines
- check4.sh 408325f5…ac754, 41 lines
- postboot.sh 0f2f510b…7de5, 48 lines
- boot-session.md 048c9bfa…1d21, the OPTIONAL 1008 block at lines 27-48
-
-## Verdict: approve the optional block once C2 and C4 are in the scripts
-
-ops-01's two departures are the ones I approved in duckworth-0045. The full stop and start replaces
-user@1000's restart, and postboot.sh reads a baseline written after the change.
-
-What holds:
- step4.sh refuses to start without localadmin's NOPASSWD grant (:9). It copies the sudoers file and the
-  group list root-only before changing anything, and writes rollback.sh with the removed groups fixed at
-  write time (:15-24). It removes only the groups jarvis is in (:13), without a `grep -q` under pipefail.
- 1' checks localadmin over ssh again before the shutdown, and stops there if that fails.
- check4.sh covers 4.4 (uid-1000 pids holding the four gids, :12-18), 4.5 (uid-0 with loginuid 1000,
-  listed, :19-24), the 14 units, and localadmin sudo, with jarvis's sudo and docker refused.
-
-C1, met by the 0' dry run. postboot.sh :41-42 fails on a missing `cloud-init.disabled` or a status other
-than `disabled`. The 1008 dry run's expected result is fail=1 (sshkeys only), so a missing disable file
-would show as fail=2. ops-01 must treat any dry-run result other than the expected fail=1 as a stop.
-A one-line guard at the top of step4.sh, aborting when `/etc/cloud/cloud-init.disabled` is absent, would
-make that hold even if the dry run is skipped. That's optional.
-
-C3, met. The step 4 baseline records `absent  /etc/sudoers.d/90-cloud-init-users` (:33). If the file came
-back, postboot.sh :36-38 would see a sha line where the baseline has `absent` and report DIFF.
-
-## Still open
-
-C2, partly met. step4.sh :29-30 checks groups and `sudo -l -U jarvis`, but only before the boot.
-check4.sh, after the boot, checks groups, the one sudoers file and `visudo -c`. It doesn't run
-`sudo -l -U jarvis`, and it doesn't list `/etc/sudoers.d`. A new file there under another name wouldn't
-be caught, because the baseline names only two files. Add to check4.sh's root block:
- `sudo -l -U jarvis` must print "is not allowed to run sudo". Match that line. Don't count
-  "may run the following" lines, because a `sudo -l` that errors (stderr to /dev/null) also counts 0. The
-  same applies to step4.sh :30.
- `ls -A /etc/sudoers.d` must list exactly README and 50-localadmin.
-
-C4, not met. Neither check4.sh nor the block records the running containers. boot-session.md :48 says
-homeassistant, esphome, valkey and step-ca "keep running", but a reboot restarts dockerd. Only containers
-with a restart policy come back. Add to 0': as localadmin, record the names of the running containers
-(`sudo docker ps --format '{{.Names}}'`, sorted, into the rb dir or on dragon-lin). Add to check4.sh: the
-same list after the boot, compared to the saved one, with names only. A container missing after the boot is
-a DIFF, and localadmin starts it. This applies to the 1008 boot without step 4 too, since that's the same
-reboot.
-
-## Notes (do not block)
-
-N1. The FYI and 1' give the fallback after step4.sh as Jason at the console, then pve root offline. On
-1008 there is a tested step between them: the 1008 guest agent answers, so pve root can run
-`qm guest exec 1008 -- /root/q183-rollback/step4-<ts>/rollback.sh` (my duckworth-0035 N5 and N8). Name it
-second, ahead of the console.
-N2. check4.sh :34 asks `systemctl --user is-active` over a jarvis ssh login. That works with linger (the
-dry run got 14 of 14). It's also the one place in check4.sh that needs jarvis's own login. That's fine
-because jarvis's authorized_keys stays (§4).
@@ -1,64 +0,0 @@
-# Review: ops-01 #423 VM tightening r5, step 4 (.53 jarvis sudo and groups) (duckworth-0045)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I reviewed the document only and ran nothing on pve or .53.
- Subject: /mnt/storage/scratch/tmp/mosvk/q183-vm-tightening-r5.md, sha256 4cbdc48e…f380 (checked). It's
-  the same file I approved for steps 1 to 3 in duckworth-0035.
- Scope: §4, the §8 pre-check result, and mos-1092's timing: make the changes, then shut 1008 down and
-  boot it in Jason's boot session, then run the B3 checks, the step 6 verify and postboot.sh.
- postboot.sh wasn't sent to me, so I haven't read it. C3 covers what it has to expect.
-
-## Verdict: approve step 4 with C1 to C4
-
-The step is sound. §8 shows no Hermes config, unit, cron, hook or script, and no root unit or crontab,
-that relies on jarvis's sudo, docker or lxd. The skill text that mentions them is instructions, not
-callers. 18 sudo uses in 30 days, none tied to a unit, fit an interactive habit, not a dependency. What
-breaks is listed (sudo and docker flows, compose management moving to localadmin). When step 4 is done,
-jarvis has no local path to root, so row 195's P5 can be marked closed. jarvis's `id_ed25519` reach to
-pve stays and is P4, accepted under Q183.
-
-Mos's question: the reboot can stand in for B3's restart, and I don't want the explicit restart as well.
-A shutdown ends every jarvis process, including sessions outside user@1000 and any uid-0 process with
-loginuid 1000, so it covers both `systemctl restart [email protected]` and `loginctl terminate-user`.
-Linger brings user@1000 back at boot with the group list from the new /etc/group. The groups check (4.4)
-and the leftover-root check (4.5) still run after the boot, as mos-1092 says, and they are the proof. The
-reboot isn't. Keep the gap between the group change and the shutdown short, because running jarvis
-processes keep the docker gid until they end.
-
-## Conditions
-
-C1. Step 3's `/etc/cloud/cloud-init.disabled` must be in place on 1008 before this boot. If it isn't,
-and 1008 boots with a new instance-id, cloud-init's users module runs again, writes
-`90-cloud-init-users` back and gives jarvis NOPASSWD sudo again. If step 3 hasn't run on 1008 by then, run
-3.1 first in the same session. It's approved and has no restart of its own.
-
-C2. The verify has to check the stored state, not only a running shell. `sudo -n true` failing as jarvis
-also happens when a grant exists but asks for a password. Add, as localadmin:
- `sudo -l -U jarvis` reports that jarvis may not run sudo,
- `id -nG jarvis` lists none of sudo, docker, lxd or adm,
- `/etc/sudoers.d` holds only README and `50-localadmin`, and `visudo -c` passes.
-Report names and results only.
-
-C3. Since step 4 runs before this boot, the post-boot check for 1008 has to expect
-`90-cloud-init-users` absent and `50-localadmin` and `01-q183.conf` unchanged. Fix that expectation in
-postboot.sh before the boot. If it was written against the pre-step-4 hashes, it reports a false change.
-If it treats "absent" as a pass either way, it would also pass a file that came back. The file has to be
-absent, and its reappearance has to be a failure.
-
-C4. A reboot restarts dockerd, which the user@1000 restart didn't. Before the shutdown, record the names
-of running containers as localadmin (homeassistant, esphome and valkey per §8). After the boot, confirm
-those three are running again, and start any that has no restart policy through localadmin. Add it to the
-step 6 verify, with names and states only. The step-ca loop and the exited stacks stay as they are.
-
-## Notes (do not block)
-
-N1. Rollback under the reboot plan is: restore `90-cloud-init-users` from the root-only copy, run
-`usermod -aG`, then either restart user@1000 or reboot. Once step 4 is done, jarvis's sudo is no longer a
-way back in (my duckworth-0035 N8). The paths are localadmin and then `qm guest exec`, which works because
-the 1008 agent ping is ok. Re-run the §1 lockout check right before the shutdown, as §1 requires.
-N2. The adm group gives jarvis read access to `/var/log` files. 2 of the 18 sudo uses were `journalctl`.
-jarvis keeps its own user journal. A Hermes flow that reads system logs would fail, and §8 shows none.
-N3. Downtime is now the whole boot for the Hermes units and the home automation containers, not only the
-user units. Record the shutdown time and each unit's `ActiveEnterTimestamp` as 4.3 already does.
-N4. This moves step 4 ahead of the Case 1 install, where the row 195 brief had it waiting until Case 1 is
-live. That's Mos's call, and it's the safer order, because `/srv/mosaic` never exists while jarvis can
-read it. Row 195's design should change P5's evidence to "closed at #423 step 4" when this is done.
@@ -1,45 +0,0 @@
-# Review: ops-01 #423 VM tightening r5, steps 1 to 3, diff-only (duckworth-0035)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. I reviewed the document only and ran nothing on pve, .53 or .54.
- Subject: /mnt/storage/scratch/tmp/mosvk/q183-vm-tightening-r5.md, sha256 4cbdc48e…f380 (checked).
- Base: q183-vm-tightening-r4.final.md, sha256 03cd1075…cbc05f (checked, the version I reviewed in
-  duckworth-0032).
- Diff: q183-r4-to-r5.diff, sha256 15326e32…4e70 (checked). It is identical to my own `diff -u` of the
-  two files, so nothing outside the diff changed.
-
-## Verdict: approve steps 1 to 3 on 4cbdc48e
-
- B1 resolved.
-  - The drop-in is `01-q183.conf`, so it sorts ahead of `60-cloudimg-settings.conf` and any cloud-init
-    drop-in.
-  - §0 records the facts the fix depends on: Include is at line 12, `sshd_config` has no
-    `PermitRootLogin` line, and the effective value is `without-password` today.
-  - The verify reads `sshd -T` for `permitrootlogin no`, and gets a key count of 0 for every
-    `authorizedkeysfile` path under /root. `ssh root@` refused is labelled "not proof".
- N1 to N3 and N6 are taken as written. N2 is better than I asked. The key line comes from jarvis's or
-  melanie's file, matched by fingerprint against dragon-lin's public key, with no options. Root's file is
-  never used, because it carries the `command=` prefix.
- N4: 0 root key logins in 14 days on both VMs, counted again right before step 2.
- N5: 1008 falls back to `qm guest exec`. 1012's fallback is named and untested. See N8.
- N7: the conf lines are restored from the root-only copy, without `qm set`.
- Answer (a) is in §0.
- Recount: 2 + 7 + 9 = 18, and the per-command list also sums to 18, over a fixed UTC window. The cause
-  of the earlier numbers is stated.
-
-Condition: this approval covers step 1 as written in r5. The gate line says step 1 "follows" the #424
-credential-store design if that design arrives first. If #424 changes how localadmin's key or sudo is
-held, the changed step 1 comes back to me as a diff before it runs.
-
-## Notes (do not block)
-
-N8. Step 2 doesn't touch jarvis's or melanie's sudo. Until §4 and §5 run, `ssh [email protected] sudo` and
-`ssh [email protected] sudo` are still a tested way back in. That makes them the first fallback on both VMs,
-ahead of the guest agent and the rescue boot. Name them in step 2's rollback. If 1012 ever needs more, a
-better fallback than `init=/bin/bash` is pve root editing the stopped VM's disk offline. That doesn't
-depend on catching a GRUB menu that cloud images usually hide.
-N9. Root's key already carries a forced `command=`, so root key login only prints a message today.
-Step 2 is still right: it removes the key and sets the policy, so a later edit of root's file can't
-reopen root login.
-N10. The §6 unit-file rule (webby-0025) is sound. Root renders or copies the unit in, root-owned, with
-fixed-value checks, and no unit source sits under /srv/mosaic. I'll review it with Gosalyn's design and
-the Case 2 step that runs it.
@@ -1,45 +0,0 @@
-# Review: Morgana row 193 design r3 (duckworth-0011)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/morgana/work/queue-193/DESIGN.md, diff 19c015741..76f4605e1 (one commit, morgana-0008).
-DESIGN.md at 76f4605e1 has sha256 e61500d9…8859, checked. Line numbers are at 76f4605e1. Code read at
-53bb59462. Against duckworth-0008 (REVIEW.md, aa7f082bf).
-
-## Verdict: changes, B3 only
-
-B1 and B2 are resolved and N1 to N4 are done. B3 is a small gap in the new 5.7 table, which B1 asked to
-list every read: the project file reads are missing, and they carry a user-thread run's output to the owner.
-
-## r2 codes
-
- B1 resolved (5.7, :279-327). Option (a) is taken and stated plainly: messages are private, governance is
-  not. The table covers the reader list at broker.mjs:1303 and the owner's board reads. The governance pin
-  test (:405-407) shows a user-thread decision in the owner's `decisions recent` and `inbox`, with message
-  bodies still hidden. The :1683 route is named as intended. Gizmoduck's FED r4.5 (acd5f1f42, gizmoduck-0022)
-  now keeps it, with an R3 test and an R6 notice, so the two designs agree.
- B2 resolved (5.7 :322-324, section 9 :440-451). The message filter is in 193b1 with `#readable`
-  owner-only, and 193b2 adds only the share exception. No order of FED R8 and 193b2 can put a user thread
-  live unfiltered. Mutants 11 and 12 are tested under 193b1 (:408-413).
- N1 done (:383-384). N2 done (:6-7). N3 done (5.6 :277, section 8 :393, mutant 5 :429): R4 owns the
-  level-loss test and mutant. N4 done (5.2, :205-207).
-
-## Blocker
-
-B3. The table at :289-302 says it lists every read an owner or reader session has, but it leaves out
-`project.files` and `project.file` (broker.mjs:1441-1450, human and tester). A user-thread run acts with
-the owner's role authority, so where that role holds record authority it can `record.write` into the
-project repository (broker.mjs:1395-1407). The owner then reads that record with `project.file`. Under
-option (a) this is governance and visible, which is fine. But the table omits it, and the user-facing
-sentence at :306 names only decisions. A user who reads "Decisions your thread's agent raises go to the
-business owner" would assume records the agent writes stay private.
-Fix: add a `project.files`, `project.file` row (records a run writes, governance, visible) and widen the
-sentence to "Decisions your thread's agent raises, and records it writes to the project, go to the business
-owner." Also list `message.receive` and `message.read` on the `messages` row (:296). They filter on
-`to_role='human'` too (broker.mjs:1931-1936, :1953), so they're private for the same reason. Gizmoduck's R6
-notice should match the widened sentence (I'm telling Gizmoduck in duckworth-0012).
-
-## Note (does not block)
-
-N5. The paragraph at :308-311 still says FED may add a guard at :1683 and that the `inbox` row would then
-change. FED r4.5 has settled this: no guard, as Mos ruled (mos-1021, mos-1022). Cite r4.5 and drop the
-conditional.
@@ -1,18 +0,0 @@
-# Review: Morgana row 193 design r4 (duckworth-0014)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/morgana/work/queue-193/DESIGN.md, diff 76f4605e1..edc794933 (one commit, morgana-0009).
-DESIGN.md at edc794933 has sha256 c18d27b0…b613a, checked. Against duckworth-0011 (REVIEW-r3.md, 912b1d325).
-
-## Verdict: approve
-
-## r3 codes
-
- B3 resolved (5.7 table and sentence). The `project.files` and `project.file` row is in, marked
-  governance, visible. `message.receive` and `message.read` are on the `messages` row. The user sentence
-  names records, and the governance pin test checks that a run's `record.write` shows in the owner's
-  `project.file`.
- N5 done. The gated-raise paragraph cites FED r4.5 (acd5f1f42) and drops the conditional. It matches what
-  I approved in duckworth-0012.
-
-FED R6's notice should use this sentence (duckworth-0012 N21).
@@ -1,11 +0,0 @@
-# Review: Morgana row 193 design r5 (duckworth-0018)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/morgana/work/queue-193/DESIGN.md, diff edc794933..e2d161e2e (one commit, morgana-0011).
-DESIGN.md at e2d161e2e has sha256 dd7fcb41…b523, checked. Doc-only.
-
-## Verdict: approve
-
-The 5.7 sentence now names every governance read the table marks visible: decisions, inbox, `agents`
-(claims), `tasks` and `project.file`. The governance pin checks each one, so the sentence and the test
-can't drift apart. FED r4.6 uses the same sentence word for word (duckworth-0019).
@@ -1,72 +0,0 @@
-# Review: Morgana row 193 design r2, many humans per business (duckworth-0008)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/morgana/work/queue-193/DESIGN.md at 19c015741 on morgana/row193 (sha256 f1283e310d65…5d10,
-checked), base 53bb59462, Gitea #1691. r2 supersedes 5d15979e0 (morgana-0006), and I reviewed r2 whole.
-Code read at 53bb59462. Federation design read at 73677b87d (r4.1). gizmoduck-0020 says `covers` is unchanged
-through r4.4.
-
-## Verdict: changes, B1 and B2
-
-The model is sound. There's one store for users and grants, the role is the grant's level, and one
-verifier (row 196) mints every principal. Shares never widen a grant, and the latest row per
-`(thread, target)` decides. Two things block. 5.7 promises more privacy from the owner than the bus gives.
-And the build order can put user threads live before the filters that keep them private.
-
-## Rulings asked in morgana-0004
-
-1. `thread_shares` deviation (5.1): approved. F1 to F3 hold. A share is a runtime act by a non-owner
-   principal, and access.json is owner-written config whose loader revokes everything on any error. An
-   append-only bus table gated by `covers` is the right home. N12 is met (5.2, :207-208).
-2. Roles owner, collaborator, viewer (4.1-4.3): approved. Viewer creates, opens and sends nothing, so it
-   never drives an instance. The per-role verb table refuses everything not listed.
-3. The R4 predicate: settled in FED. `covers` with `level: 'collaborator'` is FED R4's. See N3 for who owns
-   the downgrade test.
-4. "Private" stated plainly (5.7): not yet, see B1.
-5. H1-H5 (section 6): consistent with row 196 as I reviewed it (duckworth-0006). Users have no CLI path,
-   and the verifier returns no role.
-6. Schema 3j, the `--migrate` window and the split (7, 9): approved, subject to B2.
-
-## Blockers
-
-B1. 5.7 says a user's thread is private from the owner at the bus boundary (:284-286), and it filters
-only `trail` and `replies`. A run in a user's thread acts with the owner's role authority (F10), and
-several owner and reader reads show what it does:
- `decisions {list: 'roles' | 'recent'}` (broker.mjs:2174-2192) and `inbox` (:2150-2157) return whole
-  decision rows: `question`, `options` and `recommendation` are free text the run writes (schema.sql:46-61).
-  The `decisions` table has no thread column, so no filter can catch these by `message_threads`.
- FED 3.6 item 7 stops a user-thread run from messaging `to: 'human'`, but doesn't name the decision route
-  at :1683. That is the tester's guard for a decision routed to the human (`tester-thread-human`). Without
-  it, a user-thread run's gated raise lands in the owner's inbox. I'm raising this with Gizmoduck as well.
- `agents` and `tasks` show the run's claims and the Vikunja work it touches.
-Fix: pick one, and say it in 5.7.
- (a) Keep these owner-visible on purpose. The run spends the owner's authority, so its decisions and task
-  writes are the owner's governance. Then 5.7 says plainly that the user's messages are private, and the
-  run's decisions, tasks and claims are not. Add a test that pins it: a user-thread run's decision shows
-  in the owner's `decisions recent`.
- (b) Filter them too. That needs a thread link on decisions, which is more schema, and it hides
-  governance from the owner.
-I recommend (a). Either way, 5.7 has to list every owner and reader read and say which side of the line
-it's on.
-
-B2. The 5.7 filters land in 193b2 with schema 3j (:414). 9 says nothing is exposed before that, because
-"FED R8 is later" (:420-421). Nothing enforces that order. FED R8 is the 10-27 live window, and 193b2
-waits for a `--migrate` window Sage hasn't scheduled. If R8 goes first, the owner can read every user
-message through `trail` and `replies`.
-Fix: move the hiding filter to 193b1. Without shares, `#readable` is false for anyone but the thread's
-owner, so b1 hides every message in another user's thread, and needs no schema. 193b2 then only adds the
-share exception. Mutants 11 and 12 move with it. The alternative is an R8 entry-gate line saying R8 waits
-for 193b2, and Gizmoduck would have to carry that.
-
-## Notes (do not block)
-
-N1. Section 7 still says "193a and 193c have no schema change ... 193b carries 3j" (:355-356). After the
-split, 193b1 has no schema change either, and 193b2 carries 3j.
-N2. The header lists FED r3.1 (a2840a6be) as read (:6-7), but coverage now comes from r4.1 and later.
-Update the citation so the build seat reads the right FED.
-N3. The downgrade test and mutant 5 are claimed by both rows. 5.6 and section 8 put them in 193b1
-(:274-275, :365-366, :399), and FED r4.4 keeps them in R4, which depends on row 193's viewer level (mos-1020,
-gizmoduck-0020). Name one owner, so the mutant isn't run twice or dropped by both.
-N4. `thread.share` with `to` set to the business human's name: if the business file's `human` is later
-renamed, old share rows name a stale target. Nothing renames the human today. One line in 5.2 saying a
-share to a name that is no longer the human is void would close it.
@@ -1,48 +0,0 @@
-# Scoped check: row 194 b3 N1 delta (duckworth-0074)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1634 through honker-0059. Subject:
-`honker/row194-b3`, a61a49a51..86889c59e, one commit, 3 files, +55/-0. Only this delta is in scope. My
-N1 is from duckworth-0070.
-
-## Result: N1 met, no findings
-
- `business/src/instance-settings.mjs:365` (`commit()`): before `beforeWrite`, the requested revision
-  is compared with `writer.read(business).revision`, and on a difference the write refuses
-  `revision-conflict`.
-  - The code and text are the same as the writer's own check (`organization.mjs:188`), so no caller
-    sees a new refusal.
-  - The check comes after the no-change, validate, route and project checks. A stale request that also
-    fails one of those still gets the same refusal as before.
-  - Every caller passes a checked 64-hex revision. `set` checks it at `:179` and `veto` at `:262`.
-    `hire` and `fire` take theirs from `writer.read` (`:284`, `:311`). No caller relies on a missing
-    revision to skip the check.
-  - For add, change and veto, the only change is that the refusal comes earlier. For delete and fire,
-    a stale revision now refuses before the revoke.
- The window that remains is in BUILD.md: a write between this read and the writer's lock still lets
-  the revoke run and then refuses. The `:361-364` comment says so too. Option 2, running `beforeWrite`
-  under the lock after `:188`, is a follow-up. That fits sage-1634.
- T21 (`bus/tests/lifecycle-revoke.test.mjs:146`) reproduces the case. A delete is raised on revision
-  R and taken, then an issue for rev-3 writes the file. After that, the delete refuses
-  `revision-conflict` and leaves these unchanged:
-  - the file's bytes
-  - rev-2's credentials entry
-  - the vikunja token file and its bytes
-  - the store listing
-  - status `valid`
- Fire has no test, which I accept. It reads its revision at `:311` in the same synchronous call, so
-  it can only go stale through another process, and it runs the same line.
- The refusal text is unchanged, which is right. The CLI REASONS and Console INSTANCE_REASONS
-  `revision-conflict` lines say nothing about a revoke, and with this check none has run.
- No imports changed. `instance-settings.mjs` isn't a RUNNER_FILES file. No test or script pins its hash
-  (0 hits, control 11).
-
-My runs, single files in a detached worktree of 86889c59e:
- bus: lifecycle-revoke 5/0 (T21 included), reload 8/0.
- business: instance-settings 11/0.
- cli: instances 14/0.
- webui: agents 8/0.
- cli `lifecycle.test.mjs` gives 8/8 here, all eight "timed out waiting" on a sandboxed launch. The base
-  a61a49a51 gives the same 8/8, so it's my session, like seat sandbox.test. Honker's 16/0 and Sage's
-  gate cover it.
-
-I ran no mutants. M76 and M77 are on Sage's slot.
@@ -1,81 +0,0 @@
-# Scoped check: row 194 hunks on row 199 code (duckworth-0070)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1606 and sage-1607, with hunks listed in
-honker-0052. Subject: `honker/row194-b3` at b39766112, on cb5fdb064 (row 199's landing). Commits:
-589ae2c1d (squash), b1db067c5 and b39766112. Webby gives the row verdict. This check covers only the
-hunks below.
-
-## Result: no blocker in scope
-
-1. `packages/business/src/credentials.mjs:73-81, :110-113`: the date skip for a store reference
-   with no file. Holds.
-   - `notIssued` is true only for `ref.store` with `ENOENT`. Every other reference keeps both date
-     checks, and every other lstat error is still `not found`.
-   - The date's format is still checked at parse (`:50-51`) and by the bus `Credentials`
-     constructor (`bus/src/credentials.mjs:51-52`). Only the expiry and rotation comparisons are
-     skipped.
-   - A revoked store reference (`{store:true, date}` with no file) skips them too. That's right,
-     because it describes no token.
-   - `DATE_KEY` is now exported (`:12`), and `instance-settings.mjs:120` reads it. The values are
-     unchanged.
-
-2. Credential verbs.
-   - `bus/src/credential-verbs.mjs` and `bus/src/credentials.mjs` are byte-identical to cb5fdb064.
-   - `runtime.mjs:109-143`, the revoke callback.
-     - Fire revokes each service of the entry. `credential-unknown` (an agent created since the start)
-       goes on, and any other error stops the verb as `credential-revoke-failed`.
-     - Delete calls `Credentials.remove`. For an instance the bus doesn't know, that's an empty
-       service list, and it clears the directory's token and tmp files (`bus/src/credentials.mjs:211-227`).
-     - Both then refuse if anything is left in the agent's store directory, so a fire with a token on
-       disk that the running bus doesn't know refuses (sage-1592).
-     - `instance-settings.mjs:332-358` runs every check before `beforeWrite` and the write after it,
-       so a refused check revokes nothing and a failed revoke writes nothing.
-   - `broker.mjs:1816-1817` passes `credential-revoke-failed` through for `instance.fire` and
-     `instances.set` only. Any other code still becomes `outcome-unknown`.
-   - Tests: `bus/tests/lifecycle-revoke.test.mjs`, the four T20 cases. They cover the fire and delete
-     failures with the file's bytes unchanged, and the "no entry in the running bus" cases.
-
-3. `runtime.mjs:154-167`, fixedRole compares kind and path only. Holds.
-   - `fixedRef` keeps `file`, `env` and `store`, so a change from file to env, a path change or a
-     change to store still answers `restart: true`.
-   - Only `rotateBy` and `expires` are dropped. The only writers of those dates are row 199's `issue`
-     (which updates `Credentials` memory in the same verb, `bus/src/credentials.mjs:190-191`), its
-     revoke (date kept) and row 194's create (today's date, a store reference with no file).
-   - `reload.test.mjs` T14 (date-only change still reloads) and T19 cover it.
-
-N2 from my row 199 review (the restart route, sage-1607). Both required items are present:
- (a) The create result says a restart is needed. The broker answers `restart: true` because the new
-  references differ from the boot copy. The CLI prints `RESTART_NEEDED` (`cli/src/instances.mjs:68`,
-  `:252`), and the definitions list says "added with store references and a restart" (`:209`).
-  Tested at `cli/tests/instances.test.mjs:78`, `:100-101`.
- (b) `bus/tests/reload.test.mjs:117` (T19) creates a credentialed agent, expects `restart: true`,
-  then runs `issue` and expects `credential-unknown`. It starts a new bus on the same files, after
-  which `issue` works, status reads `valid`, and a later vars change still reloads.
-
-My runs, single files in a detached worktree of b39766112:
- business: credentials 6/0, instance-settings 11/0.
- bus: credentials 5/0, credential-store 12/0, credential-verbs 2/0, lifecycle-revoke 4/0, reload
-  8/0, project-runtime 3/0.
- cli: instances 14/0.
- seat `sandbox.test.mjs`: 7/3, and the same 7/3 on cb5fdb064. The failures are "no answer" from the
-  confined shell in my session, so this environment can't run that test. It isn't evidence either
-  way. Sage's gate and Honker's run cover it.
- broker.mjs's only import change adds `unhireableAction` from `vocabulary.mjs`, which is already
-  mounted. RUNNER_FILES isn't affected.
-
-## Notes (do not block)
-
-N1. A fire or delete revokes before the write. If the write then fails (`revision-conflict`, or an
-`outcome-unknown` from the writer), the credentials are already revoked while the file is
-unchanged.
- A store reference is left in the not-issued state, which matches the file, and a retry is safe
-  because a revoke of a missing store file is ENOENT, not an error.
- The human sees `revision-conflict` and nothing says the agent's tokens were revoked.
- A one-line mention in that refusal's text, or in the CLI's retry hint, would close it. It's a
-  follow-up at most.
-
-N2. Because fixedRole ignores dates, a hand edit that extends a vikunja `expires` in the business
-file reloads with `restart: false` (T14). The running `Credentials` keeps its boot date, so `use`
-still refuses `credential-expired` until a restart. No writer verb produces that change, only a hand
-edit, so this is a documentation point at most. It's consistent with the runtime comment at
-`:151-153`.
@@ -1,70 +0,0 @@
-# Row 195 manifest round 1 (duckworth-0088)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Darkwing asked in darkwing-0100. In-review rev 2756, request
-#1693 comment 29985, gate sage-1872. Candidate `darkwing/row195-b` 37171f65b on 4ced5e63d. Manifest
-`~/darkwing-scratch/r195/manifest-37171f65b….sha256`, file sha256
-c6ba9ac9eab6c87e86846ee231fbd2b0db15532b62c5ebaf614fcc53ea8db8d1, five paths. I approved the design as
-r7 5425ea2f3 in duckworth-0087 (REVIEW-r7.md).
-
-## Verdict: approve
-
-1. The manifest holds.
-   - All five digests match their blobs at 37171f65b, and the path set equals
-     `git diff --name-only 4ced5e63d 37171f65b`.
-   - `scripts/case1-accept.sh` is 100755.
-   - `queue review verify-commit 195 37171f65b…` prints "matches the manifest candidate (5 paths)".
-   - 4ced5e63d..origin/refactor changes only `docs/plans/DEFERRED.md`, which isn't in the manifest.
-2. DESIGN.md is in the manifest because the branch carries r6 and r7. Its blob changes from the approved
-   17dfbad95 in four one-line hunks: :21, :82, :326 and :340. :82 is my N1 (`broker.mjs:321`). :21 and
-   :326 give row 226's state, and :340 records gosalyn-0085. All four are doc-only, as sage-1817
-   allows. Nothing else in the design moved.
-3. The script follows §5.
-   - The args file passes `stack-upgrade.sh`'s read_args rules: root-owned, no group or other write, one
-     40-hex `--copy`, unknown pre-`--` args refused. It also refuses a non-factory file and one for
-     another business (BUILD #5). Both are stricter than the design, which is fine.
-   - The `--root` seam is refused as root, and a user needs it (:40-45). The test covers the user side
-     (:453-462). The root side can't be tested without root, the same as the hostcheck.
-   - F3 matches `sent <id> to <role>` (cli.mjs:395). F7's JSON fields `run`, `business`, `instance`
-     and `live` match `launches list --json` (cli.mjs:478) and `launch.by`. F7 accepts only the fixed
-     `ok <instance> run <run>` line from the stack's user.
-   - P9's eight items are the six `^ok N ` hostcheck lines, the jarvis `Permission denied`, the empty
-     member list of group `mosaic`, and no other account on its gid. A missing item gives one unnamed
-     line.
-   - P checks never touch the exit. Mutant 12 and the "every P unnamed" test pin that.
-4. The three items Darkwing asked me to check:
-   - BUILD #1, P4 `accepted Q182+Q183`. One line carries one mark, and P4 is the only Q182 path, so one
-     token is right. The count list stays consistent.
-   - BUILD #8, F5 names claude by argv0 basename or `comm`. This can only fail closed. A pass still needs
-     both labels exactly, on a `/usr/bin/bwrap` owned by `mosaic` with no bwrap parent. A name that
-     misses gives FAIL, and the window catches it, as BUILD says.
-   - BUILD #12, `@` in the `--claude` regex. That's needed for `node_modules/@anthropic-ai/...`. F6's
-     prefix check and `case2-unit.sh`'s root-only rule still bound the path.
-5. Tests and mutants. All the cases from §5 are present in the 22 tests, and BUILD names a killing test
-   for each of the 12 mutants. BUILD explains why mutant 1 survives the F1-variants test, and "each F
-   alone" kills it. I read the table. I didn't run the tests.
-6. Hash and count pins. No test pins a hash of `docs/TOOLS.md` or of the new files. The 64-hex grep over
-   `packages/*/tests/*` and `scripts/test-*.sh` finds pins in other files, which is the positive control,
-   but none on these paths. The only TOOLS.md hit in tests is a string inside
-   `stack-release.test.mjs:76`, not a read. The cli suite (662/0) and every `scripts/test-*.sh` passed on
-   Sage's gate (sage-1870).
-
-## Notes (no block)
-
- N1. F9 runs `$ROOT$NODE` as root (`case1-accept.sh:298`) before F10 checks that `--node` is the
-  `/opt/mosaic-stack/node-<pin>` path (:303-304). The header (:10) and the TOOLS.md entry say root
-  "only reads". BUILD #6 reasons that node is root's own. That holds because `case2-unit.sh:128-133`
-  refused a non-root-owned `--node` when it rendered the units, and the args file is root's. So this is
-  not an escalation path on a host installed as designed. The cheaper shape is to run F9's parse
-  through `AS_USER` (the file is 0644), or to apply F10's path check first. Either one makes the header
-  true. A later row can do it.
- N2. The header's "Root itself only reads systemd, ss, /proc..." leaves out the commands root does run:
-  `curl` (F2), `sudo -l` (P1, P3), the jarvis probe (P9), `hostcheck.sh --check` and `systemctl`.
-  Doc-only.
- N3. F6's prefix match (:261) accepts a `--claude` with `..` after `claude-<pin>/`, because the path
-  regex allows `.`. That claude runs only as `mosaic`, and the args file is root's, so nothing is
-  reached. F10 uses equality, so it's unaffected.
-
-## My runs
-
-None. I read the code, the tests and BUILD.md at 37171f65b. Darkwing ran the single, the mutants and the
-gate in Sage's slot (sage-1829, sage-1865), and Sage confirmed them in sage-1870.
@@ -1,96 +0,0 @@
-# Review: Darkwing row 195 DESIGN r2, the Case 1 install on 10.1.1.53 (duckworth-0047)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. My first review of this design. Darkwing asked for r2 in place
-of r1.
- Subject: darkwing/row195 at 818b79696, `agents/darkwing/work/queue-195/DESIGN.md`, blob fcbb4aa9b5,
-  sha256 329a5458…a28ea (checked), 196 lines. Its parent is on origin/refactor.
- Brief: `docs/plans/2026-10-20_hub-own-uid.md` at f24f2cd40, blob 45be7f09afc1. Rulings sage-1451.
- I read the whole design and the brief. I checked these citations at 818b79696:
-  - `launcher.mjs:310`, `sandboxProblem({ bwrap })` before every role launch
-  - `broker.mjs:245`, a human named `tester` refuses
-  - `webui/src/serve.mjs:466-470`, the default host is 127.0.0.1, non-loopback refuses, and the tester
-    listener is 127.0.0.1 only
-  - `serve.mjs:611`, `/healthz`
-  - the control board's default `127.0.0.1:7331`
-  - `stack-release.sh`, the systemctl, backup and gate lines cited in B1
- I ran nothing on .53 and nothing on dragon-lin's live state.
-
-## Verdict: changes, B1 only
-
-What holds:
- §0's host facts are what the rest of the design needs, and they were read only, as the brief allows.
- §1 gives a reason for every input: `dev` and its paths, a per-user node so Hermes's node is left alone,
-  claude pinned through `MOSAIC_CLAUDE_BIN`, and the tester ports. The step table names a runner and a path
-  for each step. The root steps go through ops-01. The `mosaic` steps use `sudo -u mosaic -H`, with no key
-  and no login shell for `mosaic`. The root-owned checkout outside `/srv/mosaic` for `case2-unit.sh`
-  matches the §6 unit-file rule (webby-0025, my duckworth-0035 N10).
- §2 gives every difference from Case 2 a reason. Keeping the Discord check is right, because one bot token
-  shouldn't feed two connectors. Asking for `--profile` over a copied script follows the brief.
- §3 follows Q185 and the Q173 secrets rule. The credential is made in the window, never copied from
-  dragon-lin, never printed, and only its name is counted. pi stays off until #383.
- §5 implements the brief's acceptance contract: one line per path with a mark, `unnamed` for "not named
-  in Q182 or Q183", and a non-zero exit only on an F check. Each of F1 to F4 has a check you can run. F2
-  follows sage-1451 Q3. The test plan uses a fake root and fake tools, so nothing reaches .53.
- §6 states the rulings as Sage gave them.
-
-## Blocker
-
-B1. §4 doesn't yet say how a re-pin, a rollback or a backup runs on .53. It names the problem (:108-111)
-and leaves the fix to the build (:113-115, "I'll size that in the build and name it in the manifest"),
-but §7 doesn't name it. The brief makes re-pin, rollback and backup, and who runs each, part of the
-design. Three concrete gaps:
-
-1. The health gate and the in-run rollback have no owner. `stack-release.sh` activate is health-gated, and
-   it puts the old stack back in the same run when the gate fails (:2-4, `rollback_in_run` :561-583). That
-   all goes through `systemctl --user` (:178, :436-453, :474, :554). §4 splits the activate into a `mosaic`
-   half (copy, pointer, backup) and a root half (`case2-unit.sh`, restart). Nothing then says who runs the
-   `/healthz` gate after root's restart, or who puts the old copy back if the gate fails. It doesn't say
-   whether the activation log gets an `ok` or `gate-failed` line either. That log is what the §4 rollback
-   reads ("the previous distinct copy, from the activation log").
-2. The backup is of a running store. In §4's order, `mosaic` takes the tar (:122-124) while the unit is
-   still up, because only root can stop it. `backup_store` (:369-392) copies `bus.sqlite` only after the
-   bus has stopped, with no -wal or -shm, and checks `stopped` again afterwards (row 185). A tar of a live
-   SQLite store isn't a consistent backup. The tar also lands in `/srv/mosaic/backups/` rather than
-   `$DATA/backups/stack/<activation>`, so `rollback --restore ACTIVATION` and row 181's restore guard can't
-   find it.
-3. There's no file for the change. Whatever does the `mosaic` half is either a new `stack-release.sh` mode
-   or a Case 1 script, and either way the manifest has to list it with tests. A `stack-release.sh` change
-   touches the re-pin tool dragon-lin uses, so its tests must also show dragon-lin's path is unchanged.
-
-Fix: write the .53 activate as one ordered list, with a runner for each step:
- root stops the unit
- `mosaic` takes `backup_store`'s stopped-store backup under `$DATA/backups/stack/`, writes the copy and
-  the pointer, and logs the attempt
- root renders the unit and starts it
- the gate runs on `/healthz`, with its runner named
- on a gate failure, the same window runs the same steps with the previous copy, and logs `gate-failed`
-  then the rollback result
-Name the script and the mode in §7, with their tests. Say whether it's a `stack-release.sh` mode (for
-example a `--units external` flag that skips every `systemctl --user` call and leaves the stop and start to
-the caller) or a new script. Rollback is the same list aimed at the previous distinct copy. If the order
-needs a C2-13 change as well, add it to the copy-id request to Gosalyn, so Case 2 gets the same answer.
-
-## Notes (do not block)
-
-N1. P5 will be closed sooner than §5 expects. Mos has moved #423 step 4 ahead of the Case 1 install
-(mos-1092, my duckworth-0045 and duckworth-0046), so `/srv/mosaic` won't exist while jarvis can still
-sudo. After step 4, P5's evidence is "closed at #423 step 4". Then tighten P6 (:159): `sudo` with
-`localadmin` alone, and no members of `docker` or `lxd`, is `closed`. Any other member, jarvis included,
-is `unnamed`. As written, jarvis in `docker` passes P6 as `closed`.
-N2. P1 (:154) and any `sudo -l -U` check should match the "is not allowed to run sudo" line. Counting grant
-lines reads a failed `sudo -l` as "grants nothing" (the same finding as duckworth-0046 C2).
-N3. F3 (:147) should name the commands, since the tester listener on 7333 is the web listener and the CLI
-reaches the bus another way. I read it as, run as `mosaic` through `sudo -u mosaic -H`:
-`mosaic talk chief "<marker>" --tester`, then `mosaic follow --tester` until a reply arrives, with a
-300 s limit (cli.mjs:52-53). If the check goes through 7333 instead, name the header or proof it uses.
-N4. The node download (:57) is checked against `SHASUMS256.txt` from the same server. Check the release's
-signed `SHASUMS256.txt.asc` against the node release keys, or pin the tarball's sha256 in the run sheet.
-Otherwise the check only catches a corrupt download.
-N5. claude under `~/.local/bin` updates itself unless `DISABLE_AUTOUPDATER=1` is set. The harness sets it
-for its own sessions (`harness/tests/claude-session.test.mjs:56`). Say which version is pinned, and say
-that no other process on .53 running as `mosaic` starts claude without that variable, so the path
-`MOSAIC_CLAUDE_BIN` names stays at the reviewed version.
-N6. The §4 tar excludes `secrets/`, which is right. Say in the run sheet that a restore leaves
-`claude-session.env` in place and doesn't need a new credential.
-
-A round that changes only §4, §7 and any notes taken gets a diff check, not a full re-read.
@@ -1,99 +0,0 @@
-# Review: Darkwing row 195 DESIGN r3, the Case 1 install on 10.1.1.53 (duckworth-0050)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per Darkwing's request:
- darkwing/row195 at 9a16d7795, a fast-forward of r2 818b79696. The diff touches DESIGN.md only (+238 -76).
- `agents/darkwing/work/queue-195/DESIGN.md`, blob 0fea86616b36, sha256 376662a5…e9ee (checked), 196 lines.
- Sections 1, 4, 5 and 7 changed, so I read the whole file, not only the diff.
- I checked the `stack-release.sh` lines it cites at 9a16d7795: `interrupted` :146, `from_log` :162,
-  `stopped` :359, `backup_store` :372, `restore_store` :396, `gate_once` :471, `gate` :522,
-  `rollback_in_run` :561, `rollback_failed` :587, `next_activation` :837, `do_adopt` :856, `run_steps`
-  :985, `heldcount` :1074. I also checked `stack-copy.sh:23-30` (`COPY_PATHS` has no `stack-release.sh`).
- I ran nothing on .53 and nothing on dragon-lin's live state.
-
-## Verdict: changes, B1 and B2
-
-r2's B1 is answered in shape:
- Section 4 is one ordered list, and each step names its runner.
- The backup is today's `backup_store` of the stopped store, under `$DATA/backups/stack/<ACT>`.
- The in-run rollback has one owner, the root command.
- `--units external` leaves the default path alone, and section 7 tests that with recorded argv and a
-  byte-identical `--plan` fixture.
- Root never runs code `mosaic` can write except as `mosaic`, and the unit form stays the ruled system unit.
-
-What's left is two hand-offs that the list doesn't close yet.
-
-## Blockers
-
-B1. Root needs two values that only `mosaic`'s data holds, and section 4 says root reads exit codes only
-(:176-177).
-1. The activation id. `next_activation` (:837) makes ACT inside the `mosaic` run at A3. A5, R2 and R4 take
-   `<ACT>` as an argument, and root has no way to get it. A2's failure path runs R4, and at that point no
-   ACT exists yet.
-2. The rollback target. `case1-repin.sh rollback` renders TO in A4, and TO is `from_log previous` (:162).
-   That reads `mosaic`'s log, which root doesn't parse.
-
-Fix, one of:
- `confirm` and `revert` take no ACT. Each finds the one open activation itself, from `PENDING` or from
-  `interrupted` (:146), and refuses with exit 3 unless there is exactly one.
- Or root makes ACT and passes it to A3.
-
-For the rollback, the go names TO. Root passes TO to every step. `mosaic`'s A1 plan exits 3 unless TO
-equals `from_log previous`. For A2's failure, say what happens: root starts UNITS again and exits 1,
-with no log line, or with a line A1's plan wrote. Add these to the `case1-repin.test.mjs` cases.
-
-B2. A5's gate isn't the gate dragon-lin runs.
-1. It's one pass. A5 names `gate_once` (:471), but today's gate polls it once a second until `--timeout`
-   runs out (`gate`, :522). A single pass right after `systemctl start` usually fails on `units-inactive`
-   or a `boot status` from before the start, so a healthy activate would roll back. `confirm` has to run
-   `gate` with `--timeout`. `case1-repin.sh` passes the timeout through.
-2. The PM check reads the unit's journal. When the pointer has `pm` set, `gate_once` runs `pm_launched`,
-   which reads `journalctl --user -u "$BUS_UNIT"` (:507). Under a system unit, `mosaic` would read the
-   system journal for `mosaic-stack.service`. 2a makes `mosaic` with `useradd --system`, so its uid is in
-   the system range. journald's default `SplitMode=uid` writes a system user's lines to the system journal,
-   which only root and the `adm`, `systemd-journal` and `wheel` groups can read. P2 rules out any group.
-   So I expect the read to return nothing, and every PM activate to fail with "no launched line since the
-   start". I read this from journald's documented behavior and haven't tested it on .53.
-
-Fix: say whether .53's pointer runs the PM. If it does, name how `confirm` reads the launched line, and
-test it. Options:
- a regular uid for `mosaic` (no `--system`), so journald gives it its own journal file
- `launches list` alone in external mode
- some other read that keeps P2
-
-If it doesn't, say that `confirm` refuses a pointer with `pm` set until this is designed. Either way,
-add a case to `stack-release-external.test.mjs`.
-
-## Notes (do not block)
-
-N1. The AppArmor profile is the form Ubuntu 24.04 uses for chrome and the other browsers it lets create user
-namespaces. `abi <abi/4.0>`, `flags=(unconfined)`, `userns` and the `local/` include are right. Load,
-test and rollback are in order. Its residual is as P9 states. Any local user, jarvis and Hermes included,
-can open a user namespace through `/usr/bin/bwrap`. That user then reaches the kernel surface that the
-sysctl closes for everything else. That's the bypass class Qualys reported for profiles like this
-(2025-03). Marking P9 `unnamed` and sending it to Mos is right.
-
-Before the window, check read-only whether 24.04's apparmor ships `bwrap-userns-restrict` (for example in
-`/usr/share/apparmor/extra-profiles/`). It confines bwrap's children to a profile with no capabilities,
-which narrows P9 to bwrap's own setup. I don't know whether the 4.0.1 package on .53 has it. If it does,
-use it or its pattern, and F5 shows a role session still runs under it.
-
-N2. P5 (:279) can now say what #423 step 4 removes. `step4.sh` takes jarvis out of sudo, docker, lxd and adm
-(my duckworth-0045 and duckworth-0048, ops-01's o423 scripts). After that step, P5 should read `closed`,
-and the check still reports what it finds.
-
-N3. `$RS/PENDING` sits next to the pointer's `pending` field (`P_PENDING`, :128), which means the PM wait
-after `--pm-after-harness`. Use a different name, for example `$RS/AWAITING-CONFIRM`, so the build and
-the log don't mix the two.
-
-N4. A3's "TAKEN restore on failure" and R2's restore use the stopped store. Say in A3 that a `--migrate`
-under `--units external` runs only with UNITS stopped, which A3's `units-running` refusal already
-enforces. The test for that refusal should include the migrate case.
-
-N5. The open UNITS question with Gosalyn decides how many units A2, A4, R1 and R3 handle. The gate needs
-both the bus and the Console. If C2-13 gives one unit that runs only the bus, Case 1 needs a second unit
-from C2-13, not one written here.
-
-Earlier N1-N6 are taken as asked. N5's variable placement waits on the allowlist check, and the manifest
-says which.
-
-A round that changes only section 4, the section 7 cases and these notes gets a diff check.
@@ -1,127 +0,0 @@
-# Review: Darkwing row 195 DESIGN r4, the Case 1 install on 10.1.1.53 (duckworth-0051)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per Darkwing's request and mos-1098:
- darkwing/row195 at 0075be358, a fast-forward of r3 9a16d7795. The diff touches DESIGN.md only
-  (+299 -138).
- `agents/darkwing/work/queue-195/DESIGN.md`, blob 3f8590016b40, sha256 66c64625…e57b (checked), 519 lines.
- Sections 0, 1, 4, 5, 6 and 7 changed, so I read the whole file.
-
-Cited code I checked at 0075be358:
- `scripts/stack-release.sh`:
-  - `cd "$(dirname "$0")/.."` at :24, so a `sudo -u mosaic -H` call from `/root` still runs from
-    `mosaic`'s checkout
-  - `refuse` :62-66, `interrupted` :146-157, `from_log` :162, the `--pm` parse :195, `start_both` :451,
-    `gate_once` :471, `pm_launched` :505, `gate` :522, `rollback_in_run`'s log line :572
-  - `rollback_failed` :586-592, `do_pm_on` :1137
- `packages/seat/src/session.mjs:83-93`: `ENV_ALLOW` has no `DISABLE_AUTOUPDATER`, and nothing comes from
-  `~/.claude`
- `packages/seat/src/sandbox.mjs`: :1-20, `BWRAP` at :43, the read-only `/etc` at :85
- `packages/cli/src/launcher.mjs:675`: `launchPm` starts `b.launch.by`
-
-Profile check: I fetched `profiles/apparmor/profiles/extras/bwrap-userns-restrict` at upstream tag v4.0.1
-from gitlab.com/apparmor/apparmor. Its sha256 is `11d39094…64f9`, the hash §0 and §1 pin. I read all of
-it. I ran nothing on .53 and nothing on dragon-lin's live state.
-
-## Verdict: changes, B1 and B2
-
-r3's B1 and B2 are answered as asked:
- Root's values all come from the go, its own unit files or its own args file. No argv carries an
-  activation id. `--to` is checked against `from_log previous` in A1's plan. A2f has its own row, and
-  root has its own step log.
- `confirm` runs `gate`, which polls until the timeout. The external PM check reads `launches list`
-  only. It is bound to `launch.by` and to the bus unit's `ActiveEnterTimestamp`, with `stale-start` on
-  top. `pm-on` and `--pm-after-harness` refuse `external-pm`.
- The managed settings route for `DISABLE_AUTOUPDATER` follows from `ENV_ALLOW` and the sandbox
-  mounts, and F6 backs it.
- The statoverride, the six-item P9 gate and Mos's reason are as mos-1096 ruled.
-
-## Blockers
-
-B1. The rollback can't find the activation that the failure just logged.
- `interrupted` (:154) keeps an activation open only while its last line is `started`. Any later line
-  closes it (`else open.delete`).
- A5's failure logs `result gate-failed code <gate> rollback pending` (:258), and A3's failure logs
-  `result failed code <c> rollback pending` (:256). Either line takes the activation out of the
-  `interrupted` set.
- R2's `revert` and R4's `confirm --rollback` then require "its activation is the one `interrupted`
-  names" (:241-243). So they refuse `open-activation`, and root exits 2 with UNITS stopped.
-
-The effect: every gate failure, which today brings the old stack back, ends with no stack running.
-
-A3 has a second gap. It writes `AWAITING-UNITS` last (:256). A3 failing between `started` and that
-write leaves zero files, and R2 and R4 refuse on that too.
-
-Fix, either way:
- No interim result line. The failing `confirm` and A3 leave `started` as the last line, root's step
-  log records the gate code, and R4 writes the activation's one result.
- Or `interrupted` keeps an activation open while its last line says `rollback pending`, and
-  `from_log` and the guards are checked against that.
-
-Either way, A3 writes `AWAITING-UNITS` right after `started`, before the backup and any migrate.
-
-Add a case to `stack-release-external.test.mjs` that runs the real sequence against one log and one
-state dir: activate, then `confirm` failing, then `revert`, then `confirm --rollback OLD` passing. Add
-the same sequence with A3 failing after `started`. The `case1-repin.test.mjs` fakes don't cover this,
-because they don't run `stack-release.sh`. Add a mutant that restores today's `interrupted` rule.
-
-B2, from mos-1098 item 1. Nobody owns the hand-placed profile after an upgrade.
- §1 installs `/etc/apparmor.d/bwrap-userns-restrict` as a loose file that no package owns.
- Ubuntu 24.04 runs unattended-upgrades for `-security` by default (check `apt-config dump APT::Periodic` on .53, read-only), and that's the path an apparmor or
-  bubblewrap fix takes. So an upgrade can arrive with no person in the loop.
- The profile declares `abi <abi/4.0>`, which a newer parser is meant to honour. That's the
-  expectation, not something the design tests.
-
-If the profile fails to load, the host fails closed on reach. The sysctl stays at 1, so bwrap gets no
-user namespace, and F4's precheck and every role session fail. That widens nothing, but nothing
-reports it either.
-
-Name in §1, §4 and the run sheet:
- (a) Who checks the profile and when. For example, root-owned `case1-repin.sh` checks the four
-  host-level P9 items in A1 on every re-pin and refuses `profile-drift`: the file's sha256,
-  `aa-status` showing `bwrap` and `unpriv_bwrap` in enforce, the statoverride, and
-  `/usr/bin/bwrap` mode `root:mosaic 0750`. Add a post-upgrade check in the run sheet for ops-01:
-  P9 and F4, after any apparmor, apparmor-profiles or bubblewrap upgrade, found from
-  `/var/log/apt/history.log` at each window.
- (b) What a failed load looks like, and that it's a stop, not a fix-forward. A changed profile from
-  a newer apparmor comes back here as its own reviewed round, with a new pinned sha256.
-
-Give A1's refusal a `case1-repin.test.mjs` case.
-
-## Notes (do not block)
-
-N1, from mos-1098 item 2. Only one profile governs `/usr/bin/bwrap` in r4. r3's `mosaic-bwrap` (the
-4b form, `flags=(unconfined)`) isn't installed any more. §1 step 2 replaces it, and §6 says so. Ubuntu's
-file attaches profile `bwrap` to `/usr/bin/bwrap`, and `unpriv_bwrap` has no attachment.
-
-Two profiles with the same attachment would be a conflict. So:
- P9 adds a seventh item: `/etc/apparmor.d/mosaic-bwrap` is absent, and no loaded profile other than
-  `bwrap` names `/usr/bin/bwrap`.
- The run sheet says r3's profile is never installed.
-
-F5 proves which profile governs, if its strings are exact:
- the bwrap process reads `bwrap (enforce)`. Under r3's profile it would read
-  `mosaic-bwrap (unconfined)`.
- the claude process reads `bwrap//&unpriv_bwrap (enforce)`, from the profile's
-  `px /** -> bwrap//&unpriv_bwrap` rule.
-
-§5 writes the second as "`unpriv_bwrap` (stacked)". Give the exact string in §5 and the test fixture.
-
-N2. The profile's own header says it is "disabled by default as it can break some use cases". It also
-gives `bwrap` itself `allow capability`, `mount` and `pivot_root` over `/{**,}`. With the statoverride
-only `mosaic` runs it, which is the residual Mos accepted. One more F5 item: a role session that runs
-a nested `bwrap` or anything that needs a capability is refused (`audit deny capability`). If the
-harness or a tool the chief uses needs one, F3 fails. That's the check working, not a reason to widen
-the profile.
-
-N3. "before it logs or migrates anything" (:256, :327) isn't quite right. `refuse` (:65) writes a
-`result refused` line with no activation outside `--plan`. That's harmless, and it closes nothing. But
-A2f's "stack log is byte-identical" test passes only because A2f never runs A3. Say "before it logs
-`started`".
-
-N4. `ActiveEnterTimestamp` with `--timestamp=unix` has second precision, and `startedAt` has
-milliseconds. The `>=` bound holds, because the bus starts the PM after the unit is active. Compare
-against the floor of the second in the fake fixtures too, so a test doesn't pass only on a
-millisecond-aligned clock.
-
-A round that changes only B1's lines in §4, B2's lines in §1, §4 and the run sheet, the §5 strings, the
-§7 cases and these notes gets a diff check.
@@ -1,123 +0,0 @@
-# Review: Darkwing row 195 DESIGN r5, the Case 1 install on 10.1.1.53 (duckworth-0054)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per Darkwing's request:
- darkwing/row195 at 0b6d29e90, one commit on r4 0075be358. The diff touches DESIGN.md only
-  (+411 -125).
- `agents/darkwing/work/queue-195/DESIGN.md`, blob 9395e56d1775, sha256 5be80359…e910 (checked), 805 lines.
- Most sections changed, so I read the whole file.
-
-Cited code I checked at 0b6d29e90. `scripts/` is unchanged from r4.
- `scripts/stack-release.sh`:
-  - `log_line` :58, which writes `op "$OP"`
-  - `refuse` :62-67, `interrupted` :146-157, which skips a line with no activation, and `from_log` :162-175
-  - `console_port` :210-215, `capture` :414-426, `RS` :851
-  - `rollback_in_run` :561-572, the migrate block :1002-1005 (`TAKEN="$ACT"` before the migrate call)
-  - `OP="$1"` :1493
- `packages/seat/src/sandbox.mjs:67`: `NAMESPACES` has no `--unshare-net`, so the port squat applies.
- `packages/webui/src/cli.mjs:26-30,53`: `--port` takes 0..65535, and `--tester-port` takes 1024..65535.
- `packages/webui/src/serve.mjs:466`: loopback only. `bus.mjs:31` and `reads.mjs:79` spawn
-  `process.execPath`.
-
-I ran nothing on .53 and nothing on dragon-lin's live state.
-
-## Verdict: changes, B1 and B2
-
-r4's B1 and B2 are answered as asked:
- Each activation gets one result line, written by A5 or R4, or by A3's own `refused` before any
-  change. `interrupted` (:153) skips a line with no activation, so a refusal by the external verbs
-  with ACT unset closes nothing. The marker comes first, R2 is the only cleanup path, and sequences
-  1-6 run the real script on one log. The three mutants cover r4's shapes.
- B2 has all three asks: the pins as reviewed values in `case1-pins.sh`, an owner across upgrades
-  (ops-01 under a Mos go, with three callers), and a stop that fails closed (profile unloaded, bwrap
-  `root:root` 0700, a sticky `DRIFT`). Re-closing bwrap after a bubblewrap upgrade puts the statoverride
-  back, and the stop handles that. Between dpkg's unpack and Post-Invoke, the profile is already
-  unloaded and the sysctl is 1, so bwrap gets no user namespace in that gap either.
- N1-N4 are taken: P9 item 7, F5's exact strings with three failing fixtures, "before it logs
-  `started`", and `stale-start` as a polled gate code that compares whole seconds.
- The port squat (mos-1101 item 5) is checked and the fix fits. Sessions share the host's network
-  namespace (`sandbox.mjs:67`). The Console moves to 732 with the capability on its unit only.
-  `console_port` reads the port from the pointer, so the gate needs no change. Hostcheck item 7 and
-  row 230's precheck check the floor. The tester's 7333 can't follow (`cli.mjs:30`), and P10 records
-  that, open to Mos's objection.
-
-## Blockers
-
-B1. The result line `confirm` writes doesn't carry the activation's `op`, `from`, `to` or `backup`, so
-`from_log` misses every .53 activation.
- `log_line` (:58) writes `op "$OP"`, and `OP` is the verb (:1493). So A5's `ok` line has op `confirm`.
- `from_log` (:169) skips any line whose op isn't `adopt`, `activate` or `rollback`.
- Today, one process writes both `started` and `ok`, so `FROM`, `TO` and `BACKUP` are set when `ok` is
-  written. Under `--units external`, `confirm` is a new process. `BACKUP` gets set in A3 after
-  `started` (`backup_store` follows the log line), so the `started` line doesn't carry it either.
-
-The effect, with section 4 as written:
- Install adopts C0. A re-pin to C1 passes, then a re-pin to C2.
- `from_log previous` skips both `confirm` lines and returns C0.
- So a go that names C1 for `rollback --to` refuses at A1's plan (DESIGN :511). A go that names C0 passes,
-  and the rollback goes back two copies.
- `from_log backup` finds no line that made C2 live.
-
-DESIGN :539 says `from_log previous` "reads .53's history the same way". That's true only if the
-`confirm` line carries the activation's fields.
-
-Fix:
- State in section 4 that A5's `ok` line, and R4's line, carry the open activation's op (`activate` or
-  `rollback`), `from` and `to` from its `started` line.
- They also carry `backup` from what A3 recorded in the rollback set, not `OP=confirm` and empty fields.
- Add to sequence 1 (or a new one) two passing re-pins and then a `rollback --to` plan. The plan
-  accepts the middle copy and refuses the first.
- Add a mutant that writes the `ok` line with op `confirm`.
-
-B2. A migration that fails partway is never restored.
- A3, as written (DESIGN :433), "migrates under `--migrate` (sets TAKEN, as today) and records in the
-  rollback set that it did".
- R2 restores only when the rollback set records a migration (DESIGN :493).
- Today `TAKEN="$ACT"` is set before `migrate-schema.mjs` runs (:1004-1005). So a `migrate-failed`
-  restores in `rollback_in_run` (:567), because TAKEN lives in the same process.
- Across processes, the record is TAKEN. If it's written after the migration, a migrate that changes
-  the store and then exits non-zero gives `FAILED` with no record. R2 skips the restore, and R4 gates OLD
-  against a half-migrated store.
- Sequence 2 fails the wrapper install after a migration that passed, so it doesn't show this.
-
-Fix:
- Write the record after `backup_store` returns and before `migrate-schema.mjs` runs, as today's TAKEN
-  is.
- Add a sequence: `--migrate`, a fake migrate that writes to the store and exits 1, then revert
-  restores, then `confirm --rollback --cause A3` passes with `failed code migrate-failed rollback ok`.
- Add a mutant that records after the migrate.
-
-## Notes (do not block)
-
-N1. The marker and `capture` share the directory. `AWAITING-UNITS` sits in `$RS`
-(`$STATE/stack-rollback/<ACT>`, :851). `capture` creates `$RS` with `mkdir -m 0700` and no `-p` (:416),
-and that call fails when the dir exists. So writing the marker first, as A3 now does, makes every
-capture fail.
- The real sequences would show this at build time.
- Say in section 4 that the marker step makes `$RS` (keeping the refusal of an existing dir), and that
-  `capture` fills it.
-
-N2. The `gate` verb needs a start floor when no activation is open. In A2f no `started` line names this
-run (A2 fails), or the newest one is already closed (A3 refused). The design doesn't say what
-`stale-start` and the PM `startedAt` bound compare against then. The first re-pin after the install
-has no `started` line at all. If `gate` refuses on a missing floor, A2f exits 2 and stops a stack that
-was healthy. Name the rule, for example no start bound in `gate` without an open activation. Test A2f
-on a log that holds only the adopt line.
-
-N3. Hostcheck item 3 and the host read don't match. Section 0 found no file under `/etc/apparmor.d`
-that names `/usr/bin/bwrap`. Item 3 and P9 item 7 refuse any file that names `bwrap`, a wider match. A
-comment or an abstraction that mentions the word would set `DRIFT` and close bwrap. Step 4's
-`--check` in 2a' would show this before anything relies on it. Still, give one read-only `grep -rl
-bwrap /etc/apparmor.d` result in section 0, or match the path.
-
-N4. Hostcheck item 4 runs bwrap through `setpriv`, outside the bus unit's `NoNewPrivileges=yes` and
-`ProtectSystem=strict`. So the boot check can't see a kernel change that breaks the attach under
-no-new-privs. That fails closed: sessions don't start, and F5 shows it. The 2a' test covers the
-install. Mention it in the run sheet's DRIFT section, so a session failure after a kernel update is
-read against that test.
-
-N5. A1 could compare OLD from the unit files with the pointer's copy. Today a mismatch is found only
-at R4, which refuses because OLD isn't the activation's `from`, after UNITS are stopped. Refusing
-`units-disagree` or `pointer-disagrees` in A1, before any stop, is cheaper.
-
-A round that changes only B1's and B2's lines in section 4, the section 7 cases and mutants, and these
-notes gets a diff check.
@@ -1,60 +0,0 @@
-# Diff check: Darkwing row 195 DESIGN r6, for duckworth-0054 (duckworth-0055)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per Darkwing's request:
- b7239bb66 on `darkwing/row195`, one commit on r5 0b6d29e90. The diff touches DESIGN.md only
-  (+87 -20).
- `agents/darkwing/work/queue-195/DESIGN.md`, blob 46bbcf2b135e, sha256 d0375e8f…6766 (checked).
- I read the whole diff. It changes only B1's and B2's lines, the notes, and their section 7 cases
-  and mutants, as the header says.
-
-The `stack-release.sh` cites (:58, :169, :415-416, :1004-1005, :1493) are the ones I checked in
-REVIEW-r4. `scripts/` is unchanged.
-
-## Verdict: approve
-
- B1 is met. `confirm` sets OP, FROM, TO and ACT from the open activation's `started` line. It sets
-  BACKUP from a `BACKUP` file that A3 writes after `backup_store` returns. So A5's `ok` line and R4's
-  line read `op activate` or `op rollback`, which `from_log` (:169) accepts.
-  - Sequence 7 covers the example from my review. After two re-pins, `--to C1` passes and `--to C0`
-    refuses.
-  - After a confirmed rollback to C1, `from_log previous` names C2. That's right: the newest ok line
-    whose `to` isn't C1 is the activate to C2.
-  - The op case and the mutant hold it.
- B2 is met. `MIGRATING` and TAKEN are set after `backup_store` and before `migrate-schema.mjs`, the
-  same point as :1004-1005. Sequence 8's fake migrate writes to the store and exits 1. It checks
-  `FAILED` and `MIGRATING`, a byte-identical restore and R4's line. The mutant records after the
-  migrate.
- N1 is taken. The marker step makes `$RS` with the exclusive `mkdir`, and an existing `$RS` refuses
-  `marker-failed`. Capture under `--units external` makes no directory.
- N2 is taken. `gate` requires `--since T`, root's own clock, read before the A2f start. Root still
-  parses nothing `mosaic` wrote, and a case and a mutant hold the `usage` refusal.
- N3 is taken. The 21:51:46Z reads give the baseline. Item 3 now requires the word grep to list
-  exactly the installed file, and `-w` also catches `/{usr/,}bin/bwrap`.
- N4 is taken. Item 4 runs 2a''s `systemd-run` line with `NoNewPrivileges=yes`, with an argv case and
-  a mutant.
- N5 is taken. `--expect-from OLD` refuses `pointer-differs` in A1's plan, for activate and for
-  `rollback --to`.
-
-## Notes (do not block)
-
-N1. With `--since`, an A2 stop timeout now ends at exit 2. The diff says a unit that never stopped
-keeps its old `ActiveEnterTimestamp` and fails `stale-start`. So when A2's wait times out with the bus
-still active, root stops UNITS and exits 2. In r5 that path would have exited 1 with OLD still
-running. Nothing of `mosaic`'s changed in A2f, so this turns a no-op failure into an outage that Jason
-or Mos has to settle.
- That's fail-closed, and a unit that won't stop is a fair reason to stop. Keep it if that's the
-  intent.
- Then say so in the run sheet's A2f line.
- Point the case1-repin test's "exits 1 with OLD's gate passing" case at an A3 exit 3, where the units
-  did stop and restart. With a `systemctl` that never reports inactive, a real `gate --since` can't
-  pass.
-
-N2. The claude path (gosalyn-0058, with Sage) is outside this round. A move under `/opt/mosaic-stack`
-changes these:
- section 1's `--claude` value and the managed-settings reasoning
- F6
- the run sheet's install step for claude, which then runs as root
-
-It gets its own round, as the header says.
-
-The manifest round reviews the built scripts and tests against sections 4 and 7.
@@ -1,64 +0,0 @@
-# Row 195 DESIGN r7 (duckworth-0087)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Darkwing asked for this review. Candidate `darkwing/row195-r7`
-5425ea2f3 on c515273db, `agents/darkwing/work/queue-195/DESIGN.md` blob 17dfbad95b (388 lines). The r6
-design was approved as b7239bb66 (duckworth-0055, REVIEW-r5.md). 7398b7dd7 carries r6 unchanged, so
-`git diff 7398b7dd7 5425ea2f3` is the whole r7 change. Gate: this design, then the manifest.
-
-## Verdict: approve
-
-1. Business id (§7). `packages/cli/systemd/mosaic-hostcheck.service` at 5425ea2f3 has
-   `[email protected]`. That holds for .53's id `mosaic-stack`, so DEFERRED 240 N1
-   (da3051ccc, an ancestor of the candidate) doesn't bind. Per DEFERRED, the fix is due "before the first
-   install whose business id isn't `mosaic-stack`", and §7 stops the window before W8 if a go names
-   another id. P11 checks `Before=` on the host. N2 stays deferred, and the design doesn't edit the run
-   sheet.
-2. Nothing touches .53. §6 opens with sage-1809. Every root step is ops-01's and waits on a Jason
-   decision. §9 changes only `case1-accept.sh`, its test, TOOLS.md and BUILD.md. The test fakes every
-   host binary and has no path to .53 or to dragon-lin's live state.
-3. §1 dev.args is consistent with `scripts/case2-unit.sh`.
-   - The usage is at :54. The unit names are at :51-52 (F1). The factory-only `--tester-port` is at :163,
-     with the 1024..65535 floor at `webui/src/cli.mjs:33`. `--port` and `--business` are at :167. The
-     factory refusals are at :168-169. `ENV_FILE` is at :243 and `MOSAIC_CLAUDE_BIN` at :247.
-   - `stack-upgrade.sh` read_args (:124-148) requires a root-owned args file with no group or other
-     write and exactly one 40-hex `--copy`. It refuses unknown pre-`--` args. The `root:root` 0644
-     file §1 describes passes.
-4. §4 is consistent with `stack-upgrade.sh`.
-   - The `--no-rehearsal` cites are :323-324 (`no-backup`, `rehearsal-required`).
-   - The exits at :29-30 match: 5 is `args-failed` with the new stack live, and 2 leaves both units
-     stopped (:239-240, :247).
-   - The re-install now stops the Console, then the bus, before the render. That settles row 230 N1
-     (webby-0046), which was on my carry list. `stop_wait` (:211-214) does the same in the driver.
-5. §5 case1-accept.
-   - F1-F11 and P1-P11 are stated with commands and marks. `curl /healthz` (F2) is
-     `webui/src/serve.mjs:641`. `mosaic talk <role> <text> --wait <seconds> --tester` (F3) is at
-     `cli/src/cli.mjs:56`. `mosaic launches list [--json]` (F7) is at cli.mjs:63, with `launch.by`
-     at `launcher.mjs:236`.
-   - P9's eight items are hostcheck 1-6, the jarvis bwrap refusal and the empty `mosaic` group. They
-     follow from run sheet section 4's `dpkg-statoverride --add root mosaic 0750 /usr/bin/bwrap`. The
-     `^ok [1-6] ` match fits `case1-hostcheck.sh`'s pass() output (:69).
-   - The `--root` seam is refused as root, as at `case1-hostcheck.sh:52`. Every mutant names a killing
-     case, and the cases cover all 12.
-6. §6 lists W0-W14, each with an owner. The run sheet section cites in W2-W10 match the run sheet's
-   ten headings at 5425ea2f3. The five row 226 items are listed. Item 4 (who writes `dev.args`) is open, as Darkwing
-   says. The run sheet at section 7 says "I2's install writes it", and `mosaic` can't write
-   `/etc/mosaic-stack`. So row 226 has to answer it before W10, and the design says the run sheet takes
-   that answer. That's the right place for it.
-7. §9's manifest is four paths with no change to the landed scripts, the run sheet or live state. The
-   row 230 r2 N1 exclusion holds: on .53 both the install and the upgrade start from stopped units, so
-   the "still on copy" line isn't reached.
-
-The carry items in my row195-build-carry list are handled. The A2f `stale-start` line is in §4 point 3.
-The claude path is `/opt` under sage-1522 (§1 and run sheet section 3). Row 230 N1 is item 4 above.
-
-## Notes (no block)
-
- N1. §1:82 cites `broker.mjs:245` for "human id not `tester`". That cite was carried from r6, and at
-  5425ea2f3 :245 is `THREAD_PAGE`. The check is `broker.mjs:321` (`b.human === 'tester'` →
-  `invalid-business`). Doc-only.
- Not a finding: :21 and :326 say row 226 is "unclaimed". Darkwing already flagged this as known. 226 is
-  Gosalyn's, briefed, not started (sage-1814), and it's fixed in the next revision or BUILD.md.
-
-## My runs
-
-None. Design review only. All cites were read with `git show 5425ea2f3:<path>`.
@@ -1,28 +0,0 @@
-# Row 196: Gander's cleanup mismatch (duckworth-0025)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Reply to gander-0017 (19:34:28Z). Static. Gander's reproducer is
-uncommitted, so I haven't read it.
-
-The finding is correct. libuv records the path a pipe was bound to and unlinks that path when the handle
-closes (`uv__pipe_close`, src/unix/pipe.c). It does this whichever inode sits there by then, and before any
-JS code runs. So `server.close()` on a `listen(path)` server can't keep section 3's promise to remove only
-the inode it owns.
-
-Two ways forward:
-
-1. Keep the promise with a rename (recommended). Bind to a temporary name inside the same checked 0700
-   parent, record the socket's dev and ino, then `rename()` it onto the final path. A bound Unix socket keeps
-   working after a rename, because clients connect to the inode. libuv still holds the temporary name, so its
-   unlink on close hits a name that's already gone (ENOENT, harmless). Cleanup is then the design's own
-   lstat, compare, unlink on the final path. One race remains: a same-uid process can swap the file between
-   lstat and unlink. That falls inside the residual below. Tests: replace the final path with another inode
-   before close and check it survives, and check that the temporary name is gone after `listen()`. Add a
-   mutant that binds the final path directly.
-2. Gander's proposal: drop the promise. The 0700 parent and 0600 socket stay the boundary against other
-   uids, a hostile same-uid replacement or deletion is classed as residual, and Node's normal cleanup is
-   used.
-
-Either one is acceptable on security grounds. The boundary row 196 defends is other uids, and a same-uid
-process can already delete or replace the path at any time. Option 1 costs one rename and one test, and
-keeps the design's wording true. If Sage takes option 2, section 3 has to drop the "owned inode only"
-sentence and name the residual, and the review is re-run on that diff.
@@ -1,32 +0,0 @@
-# Review: Gander row 196 design r2 (duckworth-0009)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gander/work/queue-196/DESIGN.md, diff 76b5c8d93..5fe259f16 (one commit, gander-0012).
-DESIGN.md at 5fe259f16 has sha256 c4322b13…e4b9, checked. The commit also appends one BUILD-LOG.md line
-and removes nothing. Against duckworth-0006 (REVIEW.md, 86be181a2).
-
-## Verdict: approve
-
-## r1 codes
-
- B1 resolved (T2, DESIGN.md:257). At least 8 concurrent proof processes with barriered helpers, a copier
-  racing a live CLI, each own peer PID checked, M20 for a swapped pending socket. The accepted socket is
-  shown working both ways after the helper exits. Section 5 also keeps the Socket in its connection
-  closure, with no shared current-fd variable. That design choice is what prevents the bug.
- Q1 conditions incorporated (section 5, :183-212). The interpreter is pinned to `/usr/bin/python3`,
-  resolved to a root-owned ELF with safe path components. Shims, scripts and home paths are refused. No
-  PATH lookup. The helper runs for proofs only, M22 proves that with a spy, and the Containerfile is
-  correctly left alone. T10 (:265) tests it.
- Q2 conditions incorporated. The live-session mapping is in 4 item 6 and T8. R2 goes into P19 333 word
-  for word (:296-298).
- N2 kept in R1. N3 done: gid is validated and grants nothing, and only pid and uid select. N4 is done,
-  with Mos's acceptance (mos-1015) recorded.
-
-## Note (does not block)
-
-N5. Activation records the interpreter's hash, and the bus pins it at startup (:193-198). Say what a later
-bus restart does after a routine OS upgrade replaces `/usr/bin/python3`. If startup compares against the
-activation record, an upgrade stops the bus at its next restart, which is fail-closed but an outage nobody
-planned. If startup only re-runs the safety checks, the record shows a different binary from the one
-running. Either answer is acceptable. Write it down, and give the operator a re-pin step for an
-interpreter change.
@@ -1,73 +0,0 @@
-# Review: Gander row 196 design r1, the human boundary (duckworth-0006)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/gander/work/queue-196/DESIGN.md at 76b5c8d93 (sha256 839b5ecb…5074, checked), base 96f243faf,
-Gitea #1694, P19 333. Code read at 96f243faf. Rulings asked: Q1 (kernel credentials) and Q2 (Console
-provenance or bus OIDC), per sage-1343.
-
-## Verdict: changes, B1 only
-
-The direction is right. Binding the proof to the kernel peer closes the copied-proof hole that today's
-cooperative check leaves open: `verifyHuman` reads `proof.pid` from the envelope (human.mjs:52-71), and
-`serve` never asks who connected (server.mjs:13-60). The same-uid limit is stated honestly (section 8 R1),
-and the split with R3 and row 193 matches federation r4. One test gap blocks.
-
-## Rulings
-
-Q1: O1, the Python helper, with three conditions. O2 and O3 are rejected for the reasons in section 5.
-Node's net API has no peer-credential accessor, so the choice is between O1 and O4, and O1 is less code to
-audit and adds no build artifacts.
- Pin a root-owned system interpreter, recorded at activation, for example `/usr/bin/python3`. On dragon-lin
-  that's a symlink to python3.14, and Python 3.12.8 also sits in the user's PATH through a pyenv shim at
-  `~/.pyenv/shims/python3`. A shim is a shell script that picks an interpreter from the environment and the
-  working directory before Python runs, so `-I -S` can't stop it. Refuse an interpreter path that resolves
-  under any home directory, or that is a script rather than an ELF binary.
- Run the helper only for proof envelopes (human, tester, user). A cap request is already bound to the
-  uid by the 0700 `bus/` directory and the 0600 socket (store `safe(directory,true)`, section 2), and the
-  cap is the authority. SO_PEERCRED is fixed at `connect()`, so reading the envelope first and the
-  credentials second is sound. That keeps a Python spawn off every managed-run bus call. If Gander keeps
-  the helper for all connections, the gate's cost measurement decides (DESIGN.md:186-188). Security is the
-  same either way.
- O4 stays the fallback if a bus host or a future bus image has no Python. The current Containerfile is the
-  worker image (`node:24-bookworm-slim`, entrypoint run-agent.sh) and doesn't run the bus, so today it needs
-  no change. Say so in section 5, so "add an image build dependency" doesn't send someone to the wrong
-  image.
-
-Q2: the Console provenance contract is approved for this slice. Bus-side OIDC would not move the boundary.
-A process that can fake Console provenance on the instance's uid can also read the Console's session and
-tokens. Passing ID tokens to the bus would turn them into bearer credentials that can be replayed
-(DESIGN.md:156-161). The issuer is also the weaker link today (federation B8, duckworth-0005). Two
-conditions: the Console puts in the proof only a user id it mapped from claims Q175 verified for that same
-request's session, never from one cached past the session (R6 tests this). And the P19 333 text keeps R2
-(DESIGN.md:255-256) word for word, so "zero trust" isn't claimed for the bus.
-
-## Blocker
-
-B1. No test proves the helper reads the credentials of the right connection when connections run at the
-same time. The design allows up to 16 helpers at once (DESIGN.md:183-184). The obvious bug is passing the
-wrong fd: a neighbour's accepted socket, or a reused fd number after a close. T2's copied-proof case
-(DESIGN.md:230) runs one connection at a time, so it can't see that bug. Under a swap, an attacker who
-copies a live proof and connects alongside the real CLI gets the real CLI's peer PID and passes. That is
-the exact attack this row exists to stop. Reading the listening socket's fd instead would refuse
-everything, and every test would catch that. A swap between live connections is the one that passes
-quietly.
-Fix: add to T2 at least 8 concurrent proof connections from distinct processes, each with its own proof,
-and one copier racing a live CLI. Each must bind its own peer PID, and the copier must refuse. Add mutant
-M20, where the helper is given another pending connection's socket, and the test must fail on it. Also
-assert the accepted socket still reads and writes after the helper exits, so the helper's close of its
-copy doesn't end the parent's connection.
-
-## Notes (do not block)
-
-N1. The inventory (section 2) matches the code I read. The walk ends at `ppid === 1` and re-reads the CLI
-(human.mjs:89-92). `serve` takes exactly one of cap, human and tester (server.mjs:52-60). No peer check exists
-today. I didn't re-read the control board, the Discord connector or the launcher sockets, so those rows rest
-on Gander's reading.
-N2. Section 4 item 5 requires the Console as direct parent. A daemonized Console started from the same tree
-by an unsandboxed same-uid agent passes the walk and the parent check. That is federation C1 and P19 333,
-stated in R1, so the row is consistent. I'm noting it so nobody reads T5 as covering it.
-N3. The helper's JSON record carries pid, uid and gid. Refuse gid values too large to be safe integers, as
-with pid and uid (DESIGN.md:185), and record which of the three the bus actually uses. Today only uid and
-pid are needed.
-N4. Sections 3 and 6 move tester HTTP off TCP, so the row 176 browser tester page loses direct navigation.
-That's an operator-facing change. The window plan should name it to Jason, not only Sage's packet audit.
@@ -1,94 +0,0 @@
-# Review: row 199 build round 1, per-agent credentials and publish (duckworth-0068)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per megavolt-0049 and sage-1576 (request comment 29778):
- `megavolt/row199-on-190` at 86963d281 on base 00d4cc1f6. 25 commits, 37 files, +3015 -77.
- Manifest `manifest-r1-86963d281.txt`, sha256 35f900fd…6bee. I checked it: 37 lines, every hash matches
-  the candidate, and the paths equal `git diff --name-only 00d4cc1f6 86963d281`.
- Base drift: origin/refactor is at f519fb1d2. None of the 14 files changed since 00d4cc1f6 is a
-  manifest path.
-
-## Verdict: approve
-
-I read the whole source diff (business, bus, cli, seat, tasks, roles, scripts/mosaic) and the test names.
-I read the design at 86963d281 against approved r6. It differs only at T3 :377, the deviation 14 wording.
-
-Checked and holding:
- `git.push.remote` is a hard wait. It is in ACTIONS and so in GATED_ONLY, and `role.mjs:42` refuses it
-  in either authority list.
- A raise binds the task's latest push and shows it in the question (`broker.mjs:1844`). With no push,
-  it refuses `no-push`.
- The fork, user, email, source and destination all come from the business file and the ticket, never
-  from the request (`broker.mjs:1026-1080`).
- The token reaches git on fd 3 only (`checkout.mjs`, `working.mjs` `helper`), so it is in no argv, env,
-  URL or file. The helper answers only `get` for https at the fork's exact host and port.
- `SAFE` keeps hooks off (`core.hooksPath=/dev/null`). No hook in the working repo inherits fd 3.
- Redirects are refused. Output that holds the token refuses `credential-leak`. Git's stderr isn't
-  returned.
- The push is by oid with no `+`. The identity check (`main..source`, author and committer) and the tip
-  check run under the repository lock, and `remote()` runs inside it (`working.mjs:429-444`).
- `useFor` keys the gitea and vikunja tokens from the broker's session for the cap, not from a role name.
-  That covers publish (`publishSession`) and the tracker's writes (`tasks/src/adapter.mjs`, `verbs.mjs`
-  `identity(cap)`). `probe` stays the host's start check.
- Revoke drops memory first, then unlinks, and never unlinks a `{file}` reference outside the store.
-  Issue writes tmp, fsyncs, renames, fsyncs the dir, then commits, then sets memory. Each verb leaves one
-  `changes.jsonl` receipt with no value. Refusals record the code alone (`#refused`).
- The tester may revoke only, per my design N1.
- Hash pins: no test pins a changed file. I checked every test file that holds a 64-hex string.
-  `channel-proof.test.mjs` pins four files, none in the manifest.
- Evidence: I read the batch 2 logs Megavolt allowed. 26 of 28 killed, M17 and M27 survived as
-  expected. pkg-bus 477/0, pkg-seat 164/0, pkg-cli 522/0, on 7c3cdd940. 86963d281 adds only BUILD.md
-  to that. The full gate ran on c6868ba41, before deviation 16's process.mjs change and its test
-  changes. Sage's gate on the landing commit covers the rest.
-
-## Deviations asked about
-
-Deviation 16 (`process.mjs:113-116`), accepted.
- Refusing a boot config that carries `publishTls` is stricter than dropping it, and it's testable,
-  which the drop wasn't.
- No production caller sets it. `git grep publishTls` outside the two src files finds only the two test
-  files. The host's boot config doesn't carry it.
- The refusal goes through the existing catch, which answers the error and exits 2, like any other bad
-  boot.
-
-Deviation 17 (M17), accepted as equivalent.
- `#authorityFor` (`broker.mjs:811`) compares the decision's `pushCommit` with the latest push's commit.
- `#publishFacts` (`:1058-1059`) takes `source = result.pushCommit ?? push.commit` and refuses
-  `decision-mismatch` unless it equals `push.commit`. That's the same comparison, with the same code.
- The only callers that pass `git.push.remote` to `#authorityFor` are `checkPublish` (`:1036`) and
-  `recordPublish` (`:1087`), and both go through `#publishFacts`. `authorize` callers pass task verbs
-  and `role.launch` only.
- The cases where the two checks would differ need a decision with no `pushCommit`. The raise can't
-  write one (`:1844`), and no earlier decision can name `git.push.remote`, because the action didn't
-  exist. So dropping either check changes no outcome. Keeping both is fine.
-
-Deviation 13 (M27), accepted as equivalent.
- The launcher clause (`launcher.mjs:403`) tests `held.includes("git.push.remote")`. `held` is the
-  role's withinRole and crossRole lists, and `role.mjs:42` refuses a GATED_ONLY action in either. So
-  the clause can't be true today.
- A publish also needs the role's own recorded push (`work-not-yours`), and that push needed the socket
-  already. The clause matters only once `git.push.remote` is routed, as the comment says.
-
-## Notes (do not block)
-
-N1. One decision can push its commit to more than one branch on the fork.
- `checkPublish` doesn't refuse while another ticket for the same decision is open.
- Two publishes under one decision with different `branch` values both pass `checkPublish`. The host's
-  lock serializes them, and the second still pushes before its `recordPublish` refuses
-  `decision-consumed`.
- The fork then holds the approved commit on a second ref, with a refusal on the trail.
- The scope is small: the commit is the approved one, on the agent's own fork. A fix would refuse
-  `publish-busy` in `checkPublish` while a ticket holds the decision, or recheck `#spent` in
-  `publishTarget` (`:1074`) before git runs. Either fix is a follow-up.
-
-N2. Issue works only for an entry the bus loaded at start.
- `Credentials.issue` refuses `credential-unknown` for a reference not in `#refs`
-  (`credentials.mjs:148`, `:156`).
- `#requestCredential` checks the agent against the broker's boot copy of the business
-  (`broker.mjs:1443`).
- So an agent added to the business file after the bus started can't be issued until a restart.
- Design D13 has row 194's human `create` make a store-reference agent that waits for `issue`. Row 194
-  needs to register the new entry with the running bus, or say that a restart comes first. That's for
-  row 194's brief, not this row.
-
-N3. Doc-only. `packages/business/README.md:53-56` still says "The eight hard waits" and lists them without
-`git.push.remote`. No test reads that file. Per decision 137 this is a follow-up commit.
@@ -1,68 +0,0 @@
-# Review: Megavolt row 199 design r2 and r3 (duckworth-0017)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/megavolt/work/queue-199/DESIGN.md on megavolt/row199. r2 is e806656b1 (sha256 435ee3b1…2e19,
-checked, megavolt-0004). r3 is c2c729ddf (sha256 d1ef44c6…d90d, checked, megavolt-0006), which supersedes r2.
-Diffs 624e8ea3a..e806656b1 and e806656b1..c2c729ddf, one commit each. Code read at 992650232.
-Against duckworth-0013 (REVIEW.md, 6ab9cd927).
-
-## Verdict: changes, B3 and B4
-
-## r1 codes
-
- B1 resolved (D3a, T1, T5, mutants). ENOENT on a `store` path loads as absent and shows `not-issued`. Every
-  other defect still refuses start, and `{file}` keeps E2's behavior. Both mutants are in.
- B2 resolved in the design text (D9 step 5, step 2). `protocol.https.allow=always` and
-  `http.followRedirects=false` are the only additions to SAFE (seat/src/working.mjs:92-98). The helper is
-  bound to https and host:port, and step 2 compares the port. working.mjs runs git under seat
-  `gitEnv` (checkout.mjs:79-88), which passes only PATH from the bus env, so no proxy or `GIT_SSL_*`
-  variable reaches it. The test for B2 is B3 below.
- N1 to N5 done. N3: `work-not-yours` reads the last `recordPush`. N4: D9a. N5: D9b, and no op returns a
-  token.
-
-## Blockers
-
-B3. T3 can't run with the flags it tests. The fake Gitea is "a node http server on 127.0.0.1" (section 11),
-which is plain http. `publish` allows only https (D9 step 5), and the helper answers only `protocol=https`.
-So the happy path fails, or the test loosens the flags it is meant to check. The 302 test passes either way:
-git refuses the http transport before any request, so "the second port receives no request with an
-Authorization header" holds with the redirect check removed, and the `http.followRedirects=false` mutant
-survives.
-Fix: the fake serves TLS with a scratch CA. The test passes the CA through a test-only seam, the way
-`FSCK` is replaced in tests (working.mjs:100), and production adds no CA flag. The 302 test also checks
-that the first port received the request, so it can't pass by never connecting. Same for the wrong-port
-and `remote-unrelated` tests.
-
-B4. The decision doesn't bind the commit that gets published. D9 step 1 says the decision "names the
-commit" and cites `checkLand`. But `#authorityFor` binds a decision to action, role, thread and `target`
-(the task ref) only (broker.mjs:769-798). `checkLand` gets its commit from somewhere else: `readLanding`
-reads the review verdict's commit (bus/src/landing.mjs:144-150), and `#landFacts` compares it with
-`#latestPush` (broker.mjs:936-937). D9 names no field that carries a commit for `git.push.remote`, and
-`decision.raise` has none today. Without one, Jason approves a publish while the task's latest push is A.
-The agent pushes B to the working repo, then publishes B under the same decision. `#latestPush` is B and
-the source is B, so every check passes.
-Separately, step 5 pushes `<src>`, the work ref, by name. A push to the working repo between
-`checkPublish` and the git call moves that ref, so even a bound commit isn't what goes out.
-Fix:
- Name the carrier: a `commit` in the raise's context for `git.push.remote` (or another field), and the
-  code that reads it.
- `checkPublish` refuses unless that commit equals `#latestPush(...).commit` and the work ref's tip.
- Step 5 pushes that oid, `git push <remote> <oid>:<dst>`, not the ref name.
- T3's "decision for another commit" test covers the A-then-B case above, and a mutant pushes the ref name.
-
-## Notes (do not block)
-
-N6. D9a: main follows root only in `seed` (working.mjs:164-176), which runs in push, review and land. Say
-whether `publish` seeds first. If not, a human pull into root reaches main only at the agent's next push,
-and `remote-unrelated` stays until then.
-N7. D9a also means each publish carries root commits between upstream's tip and main, which is landed work
-not yet upstream, onto the agent's fork. That fits O1. Say it in D9a so nobody reads the fork as holding
-only the agent's commits.
-N8. Citation: `vocabulary.mjs` is
-packages/business/src/vocabulary.mjs, and its ROUTED starts at :58, not :52-55.
-
-## r3 rulings (mos-1027)
-
-The hard wait is right for now. `git.push.remote` is in neither ROUTED (broker.mjs:44-69, vocabulary.mjs:58),
-so it's gated and every publish needs a human-resolved decision, spent once. B4 is what makes that decision
-mean "this commit". O1, Q-M3 and Q-M4 match my r1 inputs.
@@ -1,31 +0,0 @@
-# Review: Megavolt row 199 design r4 (duckworth-0022)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/megavolt/work/queue-199/DESIGN.md, diff c2c729ddf..e1aa6216c (one commit, megavolt-0007).
-DESIGN.md at e1aa6216c has sha256 f4437d6d…f069c, checked. Code read at 992650232.
-Against duckworth-0017 (REVIEW-r3.md, 4065ed59f).
-
-## Verdict: approve
-
-## r3 codes
-
- B4 resolved (D9 steps 1, 3 and 5, T3, mutants).
-  - The carrier is `pushCommit` in the `decision.raise` body. The broker reads it from `#latestPush` and
-    the agent never supplies it. It is the same pattern as `holderRun` (broker.mjs:1733-1734).
-  - `#authorityFor` checks it the way it checks `holderRun` (:796-797).
-  - Step 3 makes the decision's commit, `#latestPush` and the work ref tip equal under the lock.
-  - Step 5 pushes by oid, so the ref name never decides what goes out.
-  - T3 covers both cases: approve at A then push B, and a push that lands between checkPublish and the
-    git call. Mutants cover the comparison, push by ref name and the tip check. `no-push` at raise only
-    narrows.
- B3 resolved (D9 step 5, T3). The fake serves https from a scratch CA. The CA reaches git only through a
-  `tls` parameter that defaults to `[]`, the same seam as FSCK (working.mjs:100). Each test that should
-  reach the network asserts that the first port got the request. A mutant covers a CA flag in production.
- N6 to N8 done. `publish` seeds under the lock before D9a. D9a states that landed root commits go to the
-  fork. The vocabulary path is fixed.
-
-## Note (does not block)
-
-N9. After routing, a within-role publish has no decision, so `context.pushCommit` doesn't exist. Step 3
-then needs C from `#latestPush` alone, still checked against the tip under the lock. The reviewed commit
-that routes the action should say this and add a test for it.
@@ -1,62 +0,0 @@
-# Review: Megavolt row 199 design r5 (duckworth-0026)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/megavolt/work/queue-199/DESIGN.md at 34bfe4a53 on megavolt/row199 (megavolt-0010), sha256
-d0b326bb…214d1e (checked). 34bfe4a53 sits on a merge of refactor (12c85ada1), so I diffed the file only:
-e1aa6216c..34bfe4a53, 25 lines added and 7 removed. Against duckworth-0022 (REVIEW-r4.md, d2e305db4).
-
-## Verdict: changes, B5 and B6
-
-The direction is right. With one `remote` per project, two agents can't each have a fork, and deriving the
-fork from the upstream plus the agent's own `gitea.user` means the agent never picks where the push goes.
-Making `identity` optional (D8) fixes a real conflict with "today's files load unchanged". Coder declares
-`gitea` and has no identity. The new T3 case and the two new mutants are what the change needs. Two gaps
-remain, both caused by the rename of what `remote` means.
-
-## Blockers
-
-B5. D9a and step 5 still say "the remote", and the remote is now the upstream. D9 step 2 makes
-`projects.<p>.remote` the upstream URL, which the host "never pushes to". But D9a (:191-201) still says "A
-project's `remote` must be root's upstream or a fork of it" and runs `ls-remote` "for the remote's default
-branch". Step 5 (:176) is `git push <remote> <C>:<dst>`, and the helper matches "the remote's" host (:186).
-Read literally, `ls-remote` checks the upstream while the push goes to the fork. The check then guards the
-wrong repository. If the agent user's `<user>/REPO` is empty, or isn't a fork (A3 not done, or a repository
-of the same name made by hand), the upstream passes `remote-unrelated`. The push then sends all of root,
-landing squashes included, to that repository. That is exactly what D9a exists to stop.
-Fix:
- Name the derived URL once (for example `fork`), and use it in D9a's `ls-remote`, step 5's push, the
-  helper's host match, the `checkPublish` result (:208) and step 6's event.
- Reword D9a's first rule as "the agent's fork must share root's history".
- T3: the upstream is related while the fork is empty, and then while the fork is unrelated. Both refuse
-  `remote-unrelated` with no objects received.
- Mutant: `ls-remote` against the upstream.
-
-B6. The fork's URL is built from a parsed string, and the parse isn't stated. "By construction" (:163)
-holds only if the parse can't be steered. These need writing down:
- The upstream is parsed with `new URL()`. Userinfo, a query and a fragment are refused. After
-  normalization the path must be exactly `/OWNER/REPO`, with one trailing `.git` allowed and stripped. A
-  dot segment such as `/<user>/../OWNER/REPO` normalizes to a different owner, so the check runs on the
-  normalized path.
- `OWNER`, `REPO` and `gitea.user` each match Gitea's name rule (letters, digits, `-`, `_`, `.`, and not
-  `.` or `..`). This is checked at load.
- Gitea compares user and repository names without case (`lower_name`). `remote-not-fork` compares that way
-  too. Otherwise an upstream owned by `Coder` and a `gitea.user` of `coder` build a "fork" URL that is the
-  upstream itself.
- `identity.gitea.url` has path `/`, or the design says how a sub-path Gitea is handled. The construction
-  drops any path today.
-Tests: a case-variant owner refuses `remote-not-fork`. A dot segment, an extra path segment, userinfo and a
-query each refuse at load.
-
-## r4 codes
-
-All still resolved. B3 (TLS fake through the `tls` seam) and B4 (`pushCommit` carrier, push by oid) are
-unchanged. The destination is still `refs/heads/<gitea.user>/<branch>`, built by the host (:172).
-N9 (after routing, a within-role publish has no `pushCommit`) stands as a note.
-
-## Notes (do not block)
-
-N10. Name the refusal for `publish` by an agent without `identity`, or whose definition doesn't declare
-`gitea` (D8, :125-126), and give it a T3 case.
-N11. If `ls-remote` fails because the fork doesn't exist, it should refuse with a stated code rather than be
-read as "empty". Add to A3 that Gitea's push-to-create (`ENABLE_PUSH_CREATE_USER`) stays off. Otherwise a
-push to a missing `<user>/REPO` creates a plain repository instead of failing.
@@ -1,31 +0,0 @@
-# Review: Megavolt row 199 design r6 (duckworth-0027)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review of the design, plus one node check of D9c's
-normalization claims.
-Subject: agents/megavolt/work/queue-199/DESIGN.md at 4d3007ec9 on megavolt/row199 (megavolt-0012), sha256
-aa458dfe…dc787384 (checked). Diff 34bfe4a53..4d3007ec9, one commit, the file only. Against duckworth-0026
-(REVIEW-r5.md, 3cb6888e1).
-
-## Verdict: approve
-
- B5 resolved. `fork` is named once in D9 step 2 and is the only URL the rest of `publish` uses: D9a's
-  `ls-remote --symref <fork> HEAD`, step 5's push, the helper's host match, the `checkPublish` result, the
-  publish result and step 6's event. D9a now checks the fork and says why a related upstream proves
-  nothing. T3 puts an empty fork and an unrelated fork behind a related upstream, and the fake records every
-  path, so a check against the upstream fails the test. The upstream `ls-remote` mutant is in.
- B6 resolved (D9c). I ran the equality check in node 26 (`url.origin + url.pathname === input`). These
-  each fail it: a dot segment, `%2e%2e`, an upper-case host, `:443`, backslashes, userinfo, a query and a
-  fragment. A trailing slash passes it, and so does `%41`. The two-segment rule catches the first and the
-  name rule (no `%`) catches the second, so both refuse. The owner and the repository are read from the
-  normalized path, so the owner that gets checked is the owner that gets used. The `.git` strip followed by
-  the name rule refuses `.git` and `..git`. `remote-not-fork` compares without case. A sub-path Gitea refuses
-  at load. The three new mutants cover the three ways this could regress.
- N10 resolved. Load refuses a `publish` grant without `identity` or without `gitea`, with a fixed message,
-  and has a T3 case for each.
- N11 resolved. A non-zero `ls-remote` refuses `fork-unavailable` and its stderr isn't returned. A3 keeps
-  push-to-create off for users and orgs, and the mutant that reads failure as empty is in.
- r4 codes hold. The `pushCommit` binding, the push by oid, the `tls` seam and the
-  `refs/heads/<gitea.user>/<branch>` destination are unchanged. N9 is carried to BUILD.md for the routing
-  commit, which is the right place for it.
-
-Code can start on this revision.
@@ -1,69 +0,0 @@
-# Review: Megavolt row 199 design r1, per-agent credentials and remote push (duckworth-0013)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Static review, no code run.
-Subject: agents/megavolt/work/queue-199/DESIGN.md at 624e8ea3a on megavolt/row199 (sha256 3eb2df7c…1cd4,
-checked), base 992650232, Gitea #1697. Code read at 992650232.
-
-## Verdict: changes, B1 and B2
-
-The shape is right. The path is derived from the cap, never named in a request. No `gitea` or `vikunja`
-token enters a sandbox. The destination ref is built by the host. `publish` is no-force. E1 to E10 match the
-code where I checked them. The launcher and its git socket run in the bus process (cli.mjs:504-506), so
-`useFor` from `publish` doesn't move a token across processes. Two things block.
-
-## Blockers
-
-B1. A `store` reference with no file stops the whole bus at start. D13 creates an agent "with `store`
-references and no files" and says `launch` then refuses `credential-unavailable`. `revoke` (section 6)
-unlinks the file and leaves the reference. But D1 keeps E2's reader, and that reader throws
-`credential-file` when the file is missing (credentials.mjs:38-43). It runs inside `startBroker`'s try
-(runtime.mjs:89), so the bus refuses to start. The fault doesn't show at the verb. It shows at the next
-restart, for every agent of the business. Row 194's fire calls revoke before it edits the business file
-(D13), so a failed edit after a good revoke leaves exactly this state.
-Fix: say what a `store` reference with no file means. I suggest: ENOENT on a `store` path loads as an
-absent entry, `status` shows `not-issued`, and `useFor` refuses `credential-unavailable`. Every other defect
-still refuses start: wrong owner or mode, a symlink, bad format, a dir problem. `{file}` and `{env}` stay as
-they are. T1 and T5 gain a bus restart after create-without-issue and after revoke. Add a mutant that makes
-ENOENT on a `store` path fatal again, and one that makes ENOENT on a `{file}` path silent.
-
-B2. D9 step 5 doesn't bind the token to the remote's host. A one-shot helper that hands out the token on
-any `get` gives it to whatever host git asks about. Git follows a redirect on the first request
-(`http.followRedirects` defaults to `initial`) and then asks the helper for credentials for the new host.
-So a redirect from the remote, or from anything that answers for its name, sends the agent's
-`write:repository` token off the Gitea host. Separately, "E8's safe env" can't push to https at all:
-working.mjs:95 sets `protocol.allow=never` with only `file` allowed.
-Fix, in D9 step 5:
- `publish` sets `protocol.https.allow=always` and nothing else beyond SAFE.
- It sets `http.followRedirects=false`.
- The helper answers `get` only when `protocol` is `https` and `host`, port included, equals the remote's.
-  It answers nothing for `store` and `erase`.
- Step 2's host check compares the port too.
- T3 gains a fake remote that 302s to a second 127.0.0.1 port, where no basic auth may arrive.
- Add a mutant whose helper answers any host.
-
-## Notes (do not block)
-
-N1. Section 6 lets the tester run every lifecycle verb on the dev instance (Q173). Agents act as tester,
-so `issue` and `rotate` under the tester mean an agent session holds a live token on stdin. That cuts
-against section 7 ("Agents never mint accounts or tokens") and the no-credential-values rule. I suggest
-the tester gets `status` and `revoke` only, and `issue` and `rotate` stay with Jason. This is input to
-Q-M3.
-N2. The `issue` flag has to follow the kind. The reader takes `rotateBy` for `gitea` and `expires` for
-`vikunja` and refuses any other key (credentials.mjs:24-33). Say `--rotate-by` is gitea-only and
-`--expires` is vikunja-only.
-N3. The work ref is per task, `work/vikunja-<project>-<task>` (working.mjs:110-114), not per agent. "The
-agent's own work ref" (D9 step 3) holds only through step 4's identity check. Say so, or also check that
-the last `recordPush` for that ref was the caller's.
-N4. `publish` sends the working repo's `main` history from the project root along with the work. If the
-remote doesn't share root's history, the first publish uploads all of root, landing squashes included. Say
-that a project's `remote` must be root's upstream, and have R1 or T3 show a first publish against an empty
-fork.
-N5. E5 cites `git-socket.mjs:398-407`. It is `packages/cli/src/git-socket.mjs`. Name the host op that
-`publish` uses to reach `useFor`, since the socket today reaches the broker only through `host.op`.
-
-## Q-M inputs for Mos
-
- Q-M1: O1 (forks). Gitea enforces it, and no per-agent rule can drift. O2 depends on probe P1, which hasn't run.
- Q-M2: no objection. It's a reviewed `roles/` change, with nothing automatic.
- Q-M3: human-only, plus N1's narrowing for the tester.
- Q-M4: agreed. Per-agent model tokens need the proxy row.
@@ -1,56 +0,0 @@
-# Review: Gizmoduck row 201 FED R1 manifest, round 1 (duckworth-0033)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: gizmoduck/fed-r1 at 44e36fc4c, candidate 80fe31071,
-base ae3c36f24 (gizmoduck-0032). Against the FED R1 brief (docs/plans/2026-10-20_federation-r1-r2-r5.md at
-a2af7ab49) and DESIGN.md 3.5 at a1daa3c07.
- Manifest digests checked, all three match: access.mjs 74ac7e9e…dc4f4, index.mjs 7ee59b6e…3d20,
-  access.test.mjs 3bec097f…b238. 44e36fc4c only deletes a `__pycache__` .pyc.
- I read access.mjs in full, the test file in full, BUILD.md, and util.mjs:66-89 (`readJsonFile`).
- In a scratch git worktree at 80fe31071, `node --test packages/business/tests/access.test.mjs` passed 24 of
-  24 with exit 0. I removed the worktree afterwards. I ran no suites and no mutants.
-
-## Verdict: approve
-
-Each brief test item maps to a test:
-
-| Brief item | Test |
-|---|---|
-| symlink, non-regular file | access.test.mjs:216, :219 |
-| another owner | :224 |
-| group or other write | :225-228 |
-| expiry | :178-186, and covers :259-266 |
-| `*` | :154-156, :165 |
-| subjects (deviation 2) | :132-135 |
-| `human`, `tester`, any business's human | :111-115 |
-| any level other than collaborator | :171-176 |
-| project not a UUID | :151-153 |
-| covers: `*` and listed ids, unlisted project, instance or business, expired, level filter | :244-274 |
-
-The file checks run on one descriptor opened with `O_NOFOLLOW | O_NONBLOCK`. `fstat` comes before the read
-(util.mjs:66-89), so there's no check-then-read race, and a FIFO is refused instead of blocking. Mode
-`& 0o022` and the uid compare match 3.5's first rule. The interface (`checkAccess`, `loadAccess`, `covers`,
-`LEVELS`, `accessFilePath`, and the context with `ssoSubjects` required) is the one Morgana confirmed
-(morgana-0014, 08bb4d827) and Sage accepted (sage-1399).
-
-Deviation 1, a past `expires` loads and `covers` returns false: right. 3.5 says such a grant "is treated
-as absent", not refused, and sage-1399 confirms it.
-
-Deviation 2: your reading is the one I meant. The brief's phrase is about the 3.5 subject rules: a
-`(provider, sub)` pair appears once in the file and never in `console.sso.subjects`. :132-135 cover a pair
-repeated within a user, a pair shared across users, an owner subject, and the same sub under another
-provider. The other reading, a grant naming a user that isn't in the file, is covered by your added rule at
-:145.
-
-What remains is Sage's gate: the business suite, every `scripts/test-*.sh`, and M01-M44 each killed.
-
-## Notes (do not block)
-
-N1. `covers` with no `level` lets any level cover (access.mjs:177-185, test :271). That matches 3.5 ("when
-one is asked for"), and today it is harmless because `LEVELS` holds only collaborator. Once 193a adds
-`viewer`, any broker path that calls `covers` without `level` for a write verb lets a viewer grant send.
-For 193a (Morgana) and R3: the verb gate always passes `level`, and add a test that a viewer grant refuses
-`thread.send` and `thread.create`. Making `level` required would be an interface change, so that would go
-to Sage first.
-N2. `covers` relies on the grant having passed `checkAccess`. `projects[0] === "*"` is correct only
-because `*` must stand alone (:154-156). The doc comment says "a checked grant". R5 and 193a should only
-pass grants from `checkAccess` or `loadAccess` output, never ones they built themselves.
@@ -1,91 +0,0 @@
-# Review: Quackerjack row 202 FED R5 manifest, round 1 (duckworth-0040)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: quackerjack/fed-r5, build 030809e15, manifest
-agents/quackerjack/work/queue-202/MANIFEST.md at 959bfb275, per quackerjack-0004. Against the FED R5 brief
-(docs/plans/2026-10-20_federation-r1-r2-r5.md) and DESIGN.md 3.5 at b93f098f0.
- The six manifest hashes match the blobs at 030809e15. 959bfb275 adds MANIFEST.md only.
- I read cli/src/access.mjs in full, the cli.mjs and scripts/mosaic diffs, the README section, BUILD.md,
-  test 10, broker.mjs:375-378 and :2318-2322, client.mjs:20-45 and transport.mjs `refuseInsideAgent`.
- In a scratch git worktree at 030809e15, `node --test tests/access.test.mjs` from packages/cli passed 18
-  of 18 with exit 0.
- One probe of my own, in scratch: an access.json at mode 0664, then `list` and `revoke` through
-  `accessCommand`. Both throw a `BusinessError`, not a `CliError` (B1). Nothing was written and the lock
-  was removed.
- I removed the worktree and the probe. I ran no suites and no mutants.
-
-## Verdict: changes, B1 only
-
-Your four points:
-
-1. Human proof: sound. `proveHuman` makes one `project.list` call through `humanTransport` before any read
-   of the file, for all three verbs. The broker runs `#human` on it (broker.mjs:2319), which needs
-   `s.human`, `via` `cli` and `outsideAgent` (:377). `refuseInsideAgent` runs first, and `--tester` refuses
-   before the bus is asked. One correction to the reasoning is in N1.
-2. Lock: it does what BUILD.md says. `O_EXCL` create at 0600, the pid written after, removed in a
-   `finally`, and a reclaim only on ESRCH. EPERM reads as alive, and an empty or non-pid lock refuses. So
-   every doubt fails closed. I agree the reclaim race (limit 1) is acceptable for a human-only verb. It
-   needs a crash plus two writers at once, and it's Sage's call. See N2 and N3.
-3. Write: `checkAccess` runs on the whole new document before `writeAtomic`. The temp file is created
-   `wx` at 0600 in the same directory, written, fsynced and renamed. The revision is compared inside the
-   lock. See N4.
-4. Bus finding: agreed, it's outside R5. A closed socket maps to `outcome-unknown` at client.mjs:32-33.
-   Pinning it in test 10 is the right call. When row 196 changes it, this test fails and must be updated
-   in that row. See N5.
-
-## Blocker
-
-B1. A bad access file, or a bad business file, escapes as an uncaught `BusinessError`. `readCurrent`
-calls `loadAccess` (access.mjs:78) for `list`, and inside the lock for `grant` and `revoke` (:203). Only
-the `checkAccess` call at :236-241 converts `BusinessError` to a `CliError`. `run` (cli.mjs:613-614)
-rethrows anything that isn't a `CliError`, so node prints a stack trace and exits 1. My probe: an
-access.json at mode 0664 gives `BusinessError: access file must not be writable by group or other` from
-both `list` and `revoke`. The same happens for a file owned by another uid, and for a hand edit that
-breaks any 3.5 rule. DESIGN.md 3.5 says "Jason may also edit the file by hand", so this is an expected
-path, not a corner case. `accessContextFor` (:44-57) has the same gap for `loadBusiness`. It also runs in
-cli.mjs before `accessCommand`, so a broken business file reaches an agent caller ahead of the agent
-refusal.
-Fix:
- Convert `BusinessError` to `CliError(`refused: ${message}`, 2)` around `readCurrent` too. One wrapper
-  round the whole verb body does it.
- Build the context after `refuseInsideAgent`, e.g. pass `contextFor: () => accessContextFor(...)` and call
-  it inside `accessCommand`.
- Add one test: an access file at 0664 refuses `grant` with exit 2, and the file, the receipt and the lock
-  are unchanged.
-The manifest's line "BusinessError is caught and re-thrown as exit 2" is then true.
-
-## Notes (do not block)
-
-N1. The header comment (access.mjs:5-6) and README say the bus refusing a non-human shell is why "no agent
-and no tester can write". For a tester that's not quite right. `project.list` exempts testers
-(broker.mjs:2319, `if (!s.tester) this.#human(s)`). Testers are kept out because the CLI refuses
-`--tester` and always uses `humanTransport`. Say so in the comment. For R4, record that `access.reload`
-must call `#human` with no tester exemption, because that verb is the proof once R4 swaps it in.
-N2. The empty-lock window can go away. `bus host` already writes the pid to a temp file and hard-links it
-in as `host.lock` (packages/cli/README.md:297-299), so the lock never exists without a pid. With that
-pattern, the "empty lock, remove by hand" case disappears.
-N3. In the reclaim race, the loser's `finally` `unlinkSync(lock)` can remove the winner's lock. If its own
-lock was already taken, it throws ENOENT after the rename has happened, and no receipt is written.
-Using `rmSync(lock, { force: true })` or checking the pid before unlinking narrows that. It's part of
-limit 1, so Sage decides.
-N4. `writeAtomic` doesn't fsync the directory after `renameSync`, so a power cut can lose the rename. A
-failed write leaves the `.access-*.tmp` file behind. The receipt is appended after the lock is released
-(:246), so two writers' receipt lines can land in either order, and a crash between rename and append
-leaves a write with no receipt. Appending inside the lock, after the rename, keeps the log in revision
-order.
-N5. Test 10's `outcome-unknown` tells a human that the outcome is unknown when nothing was written. Until
-row 196 lands, the README could add: a refused proof shows as `outcome-unknown`, and no write happened.
-N6. R1's `loadAccess` checks that the file's uid matches the caller's, and the rename makes the caller
-the owner. So `mosaic access` has to run as the instance's uid, e.g. `mosaic` on .54 (Q181). Run as
-anyone else, every read refuses. The README should say which user runs it.
-N7. No verb adds or removes a `users` entry. `grant` needs the user already in the file (R1's rule), so a
-new user is a hand edit. "To cut a user off, revoke" removes that user's grants at one `--business` only.
-Say both in the help text. DESIGN.md 3.7 says "Removing the users from access.json acts at once", and the
-help should not read as if `revoke` does that.
-N8. When row 204 (193a) lands, `--level viewer` is accepted through `LEVELS` with no R5 change. The usage
-line, the help and the README name only `collaborator`. The row that lands second updates the text and
-adds a viewer grant test (my duckworth-0037 N1, carried in Morgana's BUILD.md).
-N9. `accessContextFor` calls `p.subjects.map` with no guard, so a provider with no `subjects` throws a
-`TypeError`. That goes away once R5 rebases onto row 192 and reads `console` through `checkConsole`, as
-BUILD.md says.
-
-A round that changes only B1 and any notes taken gets a diff check, not a full re-read.
@@ -1,46 +0,0 @@
-# Review: Quackerjack row 202 FED R5, round 2 (duckworth-0041)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: candidate 48a3fb96e on quackerjack/fed-r5, manifest
-agents/quackerjack/work/queue-202/MANIFEST.md at 7fd265033, per quackerjack-0005. Round 1 was
-REVIEW-r1.md (duckworth-0040, changes B1, on 030809e15).
- The six manifest hashes match the blobs at 48a3fb96e. scripts/mosaic is unchanged since round 1.
- I read the full diff 030809e15..48a3fb96e for packages/cli (access.mjs, cli.mjs, the test file and the
-  README) and BUILD.md.
- In a scratch git worktree at 48a3fb96e, from packages/cli, `tests/access.test.mjs` alone passed 21 of
-  21 with exit 0. I removed the worktree. I ran no suites and no mutants.
- No test pins a hash of `packages/cli/src/access.mjs` or reads it by path.
-
-## Verdict: approve
-
- B1 resolved. `accessCommand` runs `refuseInsideAgent`, then wraps the whole verb body, so a
-  `BusinessError` from `loadAccess`, `loadBusiness` or `checkAccess` becomes `CliError("refused: …", 3)`.
-  The exit code is 3 under Sage's ruling (sage-1437). The new test sets a 0664 file and asserts exit 3,
-  the path in the message, and the file, receipt and lock unchanged.
- The context is now `contextFor()`, called after the `--tester` refusal and the human proof. The new
-  test makes `contextFor` throw and the file 0664, and both the agent and the `--tester` caller get their
-  own refusal first.
- The lock no longer reclaims. A dead-pid, empty or non-pid lock refuses and names the path, and the
-  dead-pid case names the pid. With no reclaim, the `finally` unlink only ever removes the caller's own
-  lock, so my N3 is gone too. That trades the race for a manual clear after a crash, which is the
-  fail-closed choice, and Sage made it (sage-1429).
- `writeAtomic` removes its temp file on any failure up to the rename. The test injects a throwing
-  `renameSync` through `deps.fs` and checks the old bytes, no `.access-*.tmp`, no lock and no receipt.
-  M11, the direct-write mutant, is now killable.
- `deps.fs` undefined falls back to the real functions through the default parameter, in both
-  `writeAtomic` and `withLock`.
- N6 taken in the help text and the README.
-
-## Notes (do not block)
-
-N1. Exit codes are now mixed. Load and check refusals are 3. `--level takes …`, `project-not-found` and
-"no grant … to revoke" stay 2. If that's intended, say so in the README. If not, it's a small follow-up.
-Sage's call.
-N2. The receipt is still appended after the lock is released (round 1 N4, second part). Receipt lines
-can land out of revision order when two writes run back to back. A crash between the rename and the
-append leaves a write with no receipt. Not required by the brief.
-N3. `writeAtomic`'s catch unlinks `tmp` even when `openSync(tmp, "wx")` failed with EEXIST, i.e. a temp
-name that belongs to someone else. With 8 random bytes this won't happen in practice.
-N4. Round 1 N1, N5, N7, N8 and N9 carry as you said. N1 is already in the R4 brief line of the
-manifest.
-
-What remains is Sage's gate: the cli suite, every `scripts/test-*.sh`, and M1-M13 each killed.
@@ -1,42 +0,0 @@
-# Review: Morgana row 204 (193a) manifest, round 1 (duckworth-0037)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: morgana/row193a at 0caf6e2f6, base 44e36fc4c (row 201
-FED R1 candidate tree), per morgana-0018. Against design `agents/morgana/work/queue-193/DESIGN.md` r5 4.2,
-my R1 N1 (duckworth-0033) and sage-1420.
- Manifest digest d38de8c9…f75a checked, and its three file hashes match the tree: access.mjs 0c1d9a12…b2ae,
-  access.test.mjs 11dc4dd3…698c, access-levels.test.mjs a0656806…d52a.
- I read the full diff 44e36fc4c..0caf6e2f6, BUILD.md, mutants.py and mutants.log.
- In a scratch git worktree at 0caf6e2f6, from packages/business, each file alone with the tap reporter:
-  access-levels.test.mjs 5 of 5, access.test.mjs 26 of 26, both exit 0. I removed the worktree. I ran no
-  suites and no mutants.
-
-## Verdict: approve
-
- `LEVELS` is `["collaborator", "viewer"]`, most to least, and the comment at access.mjs:13-15 says the
-  order matters.
- `covers` (access.mjs:180-188) throws a `TypeError` for a missing or unknown `level` after the `now`
-  check. That resolves my R1 N1 the way sage-1420 item 2 ruled.
- The least-level compare is right. A grant covers when its index is at or below the asked index, so a
-  viewer grant (1) fails a collaborator ask (0), and any grant passes a viewer ask.
- The `!LEVELS.includes(grant.level)` guard at :188 is needed. Without it an unknown grant level gives
-  `indexOf` -1, which would pass every ask. Mutant A6 drops it and access.test.mjs test 25 catches that.
- `checkAccess`'s refusal path is unchanged apart from the list in its message. "Viewer", "viewer " and
-  `["viewer"]` refuse.
- The tests carry the design's matrix, the missing-level throw, an unknown grant level, and a viewer grant
-  that still needs business, project, instance and expiry.
- No other package calls `covers` (grep over packages at 0caf6e2f6), and no test pins a hash of either
-  source or test path.
-
-What remains is Sage's gate: the business suite, every `scripts/test-*.sh`, and A1-A6 each killed on the
-rebased tree.
-
-## Notes (do not block)
-
-N1. R5 (row 202, quackerjack/fed-r5 at 959bfb275) imports `LEVELS` for `access grant --level`. Once both
-land, `--level viewer` is accepted with no R5 change. R5's usage line and README still name only
-`collaborator`. Whichever row lands second should update that text and add one grant test with `viewer`.
-R5 doesn't call `covers`.
-N2. On the rebased tree, R1's M43 anchor no longer exists, as BUILD.md says. If Sage's gate for 193a
-reruns R1's mutants, M43 needs the new anchor or it aborts on an anchor count of 0.
-N3. BUILD.md's mutant table labels A5b "no level means viewer", while mutants.py and the log say "means
-any". The two are the same mutant, since every grant covers a viewer ask. Doc-only.
@@ -1,91 +0,0 @@
-# Review: Gizmoduck row 210 round 1 code, host.run with sudo through the credential store (duckworth-0052)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0052, which moved it from gizmoduck-0049:
- 12ffe0b56 on `gizmoduck/row210-on-199-r2`, base 07141966e (row 199's tip, megavolt-0027).
- `git range-diff addee664a..8ec923585 07141966e..12ffe0b56`: the DESIGN commits and the code commit
-  c7958740a are `=`. 12ffe0b56 adds only BUILD.md and manifest lines.
- `candidate-manifest.sha256` (sha256 82b701e7…): 20 files, all OK in my worktree. It lists exactly the
-  non-packet files in `07141966e..12ffe0b56`.
-
-What I read in full: `bus/src/host-run.mjs`, `business/src/hosts.mjs`, and the diffs of `broker.mjs`,
-`bus/src/credentials.mjs`, `credential-verbs.mjs`, `runtime.mjs`, `server.mjs`, `bus/src/business.mjs`,
-`business/src/business.mjs`, `credentials.mjs`, `resolve.mjs`, `role.mjs` and `vocabulary.mjs`. I read
-T9 and the test titles against DESIGN r3 D3-D9 and section 9.
-
-## Checks I ran
-
- The 17 touched test files, each alone, in a scratch worktree at 12ffe0b56 with TMPDIR under my own scratch
-  dir: 134 pass, 0 fail, from an awk sum over the TAP log. This matches gizmoduck-0052.
- `host-run.test.mjs` alone again: 18 tests, 0 skipped. The scratch sshd ran.
- After the runs, no sshd, ssh or ssh-agent of mine was left, and no `h-` dir was left.
- Hash pins: no test line pairs a changed file's name with a 64-hex value.
- I didn't run the suites or the 47 mutants. They need Sage's slot.
-
-## Verdict: changes, B1
-
-The design holds in the code:
- D4 binding. `hostRun` is `{host, argvSha256, stdinSha256}` at the raise (broker.mjs `hostRun`). It's
-  compared whole in `#authorityFor`. The broker appends the question text, and the 4096 cap applies to all
-  of it. T9 covers each mismatch, consumed, unapproved, and the full stdin in the question.
- D5 order. Busy is checked before `#consumeAuthority`, so a busy refusal leaves the decision usable
-  (deviation 5). From the broker's `busy` check to `#inflight.set` in `use()` there's no await, so two
-  calls can't both pass.
- D6. The quoting is POSIX single-quote, with `sudo -n --` first. T10's argv list covers `$( )`, a
-  backtick, `;`, a newline and glob characters. The prefix match is literal. `refusedCommand` takes the
-  basename. The digits-and-dots and hex-label refusals follow my r3 note.
- D7. ssh and ssh-agent each lead a group under `setpriv --pdeathsig KILL`. The options are all on argv
-  with `-F /dev/null`, and known_hosts is pinned per call. Field 22 of `/proc/<pid>/stat` is counted after
-  the last `)`. The sweep keeps a dir whose bus pid and start time are alive, kills only a live recorded
-  pid whose cmdline names the dir, and refuses start on any stray entry.
- D8 and D9. The needles cover the seed at the three base64 offsets and in hex. Revoke aborts the
-  controller, and `use()` answers `credential-unavailable` on an aborted signal.
- The kinds are closed through `credentialKind`. `resolveInstance` drops `host.*` from the session, and
-  the bus puts it back on the bus side only (deviation 1).
-
-## Blocker
-
-B1. The ssh tests skip and pass when sshd is missing, but their skip text says the gate fails.
- `host-run.test.mjs:22`: `skip = existsSync(SSHD) ? false : 'no /usr/bin/sshd: the gate fails on this skip'`.
-  14 of the 18 tests carry `{ skip }`. That's T4 to T22 and three of the four T27 cases.
- `node --test` exits 0 on skipped tests, and no `scripts/test-*.sh` counts skips. I grepped for `skip`. The
-  only hits are each script's own docker-unavailable skip lines.
- So on a gate machine without `/usr/bin/sshd`, the bus suite reports green and runs none of the D4-D9
-  executor tests. That's the false-pass shape, and the text claims the opposite.
-
-Fix, either way:
- Make a missing sshd a failure, for example a first test that asserts `existsSync(SSHD)`, with no skip on
-  the rest.
- Or keep the skip, change the text so it doesn't claim a failure, and have the gate check `# skipped 0`
-  for this file.
-
-Add a mutant or a one-off check with `SSHD` pointed at a missing path, so the gate's answer is shown.
-
-## Notes (do not block)
-
-N1. A `host.sudo` raise checks only that the host is in the registry. It doesn't check that the raising
-role has a grant for that host, or that the argv matches a prefix. T9 raises and approves for `web2`
-(`host-run.test.mjs:235`), which that role isn't granted (`:209-211` refuses `host-not-granted`). Jason can
-be asked to approve a call that can never run. That widens nothing, because the call checks the grant.
-Checking `roles[s.role].hosts[target]` and `commandAllowed` at the raise would keep those questions out
-of his queue. Refuse with the same codes as the call.
-
-N2. `addKey` (`host-run.mjs:84-92`) has no time limit and doesn't listen to the abort signal. If ssh-add
-never exits, `runHost` never returns. `#inflight` keeps the entry, because its delete is in `use()`'s
-`finally`. Every later call for that agent and host then refuses `host-busy` until the bus restarts.
-Revoke aborts the controller but can't clear the entry. ssh-add talks to a local agent on a private
-socket, so this is unlikely. Give it the `agentWaitMs` limit, or kill its group on abort.
-
-N3. `host-key-mismatch` (`:177`) is chosen from exit 255 plus the stderr text. A remote command that exits
-255 and prints that line gets the same answer, and its stdout is lost. Only a command Jason approved can
-do that, so this is a reporting matter. Say so in the D6 exit-255 residual, or match the text only at the
-start of stderr.
-
-N4. Deviation 3's wider runner list and deviation 11's T3 at the broker are fine. M25's CRLF mutant is
-equivalent, as BUILD.md says. With `\r` refused at :27, the line regex (:29) refuses it anyway.
-
-N5. `business/tests/helpers.mjs:14` makes `mosaic-business-*` dirs that no test removes. One run of the
-17 files left 377 under TMPDIR, and `hosts.test.mjs` alone left 111. The helper is older than this row.
-It's a follow-up, not this row's to fix.
-
-A round that changes only `host-run.test.mjs`'s skip, the mutant or check for B1, and these notes gets a
-diff check.
@@ -1,36 +0,0 @@
-# Diff check: Gizmoduck row 210 round 2 code, for duckworth-0052 (duckworth-0053)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject, per gizmoduck-0054:
- 455964f23 on `gizmoduck/row210-on-199-r2`, one commit on 12ffe0b56. The base is still 07141966e.
- The range is `12ffe0b56..455964f23`: 7 files, +163 -40. I read the whole code and test diff.
- `candidate-manifest.sha256`: all 20 files OK in my worktree, and it lists exactly the non-packet files in
-  `07141966e..455964f23`.
-
-## Checks I ran
-
- The 17 touched test files, each alone, in a scratch worktree at 455964f23: 137 pass, 0 fail, 0 skipped,
-  from an awk sum over the TAP log. `host-run.test.mjs` ran 21 tests, all passing, with none skipped.
- B1 by hand. In my copy I set `SSHD` to `/nonexistent/sshd`, with a backup, and checked the sha on restore.
-  The file exits 1 with 21 tests: 8 pass, 13 fail, 0 skipped. That matches gizmoduck-0054.
- After the runs, no sshd or ssh-agent of mine was left.
- I didn't run the suites or the 53 mutants. They need Sage's slot.
-
-## Verdict: approve
-
- B1 is met. The `{ skip }` guard is gone. A first test asserts each binary, and `sshd()` throws when
-  `SSHD` is missing. A missing sshd now fails the file, and the gate sees it.
- N1 is taken. The raise runs host.run's grant and prefix check (`broker.mjs:1964-1967`). T5-T8 count 0
-  `host.sudo` decisions after both refusals. T9 grants `web2` through `coderWeb2`. The `hard-waits.test.mjs`
-  fixture change follows from N1 and only adds a grant.
- N2 is taken. `addKey` kills ssh-add's group at `limitMs` (`host-failed`) or on abort
-  (`credential-unavailable`). `runHost` passes `agentWaitMs` and the call's signal. The test's silent socket
-  sees both connections close.
- N3 is taken. `-E <dir>/ssh.log` keeps ssh's own messages apart from the remote command's stderr, and the pin
-  refusal reads only that log on exit 255. The new test covers both a remote `fail255` and a closed port.
-
-## Note (does not block)
-
-N1. On an exit 255, `out.stderr += log` can take stderr up to 4096 characters past `outputMax`, and
-`truncated.stderr` stays false. That's bounded and only ssh's own text. Leave it or cap the sum.
-
-The suites and the mutant batch, M36-M38 included, are Sage's gate.
@@ -1,33 +0,0 @@
-# Row 210 queue round 3: rebase check (duckworth-0078)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1658 and sage-1661 (request rev 2612/2613,
-Gitea comment 29849) and in gizmoduck-0094. Candidate: `gizmoduck/row210-r5`, tip 0485384e9 on
-ad95c888c, manifest sha256 688d38b96b3de80f7bbbca857130ef36f68ec65009a3df51c5084aef7cb96788. Scope is a
-rebase only (sage-1657). My round 2 approve (rev 2592) was on c43008749, on cb5fdb064.
-
-## Verdict: approve, no findings
-
-1. broker.mjs is a clean 3-way merge. I ran `git merge-file` myself with ours c43008749, base cb5fdb064
-   and theirs ad95c888c. It gave 0 conflicts and sha256 610af0c4207bbd805a2a8826daa32b8cdb423937f793c32fd4241f6addfabfda,
-   which equals r5's broker.mjs.
-   - `git diff c43008749 0485384e9 -- broker.mjs` is exactly row 237's 3-line hunk, after :1055.
-   - `git diff d7d943199 0485384e9` on broker.mjs equals `git diff cb5fdb064 c43008749`, ignoring
-     index and hunk-header lines. So 210's broker change carries over unchanged.
-2. Across the 23 manifest paths, cb5fdb064..ad95c888c changes only broker.mjs. Every one of the 23
-   hashes in the r5 manifest matches the r5 tree. The manifest differs from r4 only in the broker line,
-   and its sha256 is 688d38b9…6788, which matches the request.
-3. The rebase is the nine r4 commits, all `=` in range-diff, plus one commit that touches only
-   BUILD.md and the manifest. c43008749..0485384e9 adds no 210 path beyond the broker merge.
-   DESIGN.md and mutants.py are unchanged.
-4. No interaction. 210's broker diff has no line with checkPublish, #publishes, publish-busy,
-   recordPublish, #publishFacts, #checkAuthority or git.push. 237's check sits in checkPublish and adds
-   no imports.
-
-My runs, single files in a detached worktree of 0485384e9:
- bus: publish 13/0, host-run 21/0, hard-waits 13/0, project-runtime 3/0.
- cli: publish-socket 8/0, credentials 5/0.
- business: hard-waits 5/0, hosts 7/0.
- seat sandbox gave 7/3, and the base ad95c888c gives the same 7/3 in my session. It's environmental,
-  as seen before. Gizmoduck reports 10/0.
-
-Sage's mutants and full gate on this tree are still to come.
@@ -1,103 +0,0 @@
-# Review: Gizmoduck row 210 (#1707) DESIGN.md r1, agent host access with sudo (duckworth-0042)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: agents/gizmoduck/work/queue-210/DESIGN.md at 7b10bc0ff
-on gizmoduck/row210, blob 1514a36d96 (checked), base refactor 9ba31b5b3, per gizmoduck-0041. Against the
-brief docs/plans/2026-10-20_host-credentials.md (9db578ff5), REQ-CRED-3 in Honker's 1.7 draft r2 (approved
-duckworth-0039), row 199 design r6 (4d3007ec9) and row 199's code on origin/megavolt/row199 at addee664a.
- I checked E1-E11 at 9ba31b5b3: credentials.mjs:22, :84-87, :95-103, :104-117, host.mjs:31 and :270,
-  broker.mjs:145-147, :790-797 and :1490-1532, server.mjs:87-95, business.mjs:89, vocabulary.mjs:101-103,
-  sandbox.mjs:29-31, instance-settings.mjs:27. They hold. E12 is stale, see N1.
- 199's `useFor` at addee664a (credentials.mjs:228-256) passes a BusError through and maps anything else to
-  `service-failed`, so D5's own codes (`host-key-mismatch`, `credential-leak`) reach the caller as designed.
- I ran nothing. The probe in section 2 is the author's, and I didn't repeat it.
-
-## Verdict: changes, B1-B4
-
-What holds:
- The four grant layers, checked on every call, meet REQ-CRED-3's "a grant exists for that agent and that
-  host before the credential is used". The agent never names another agent: the key comes from the cap
-  through `useFor`.
- No agent and not the chief can write layers 2-4. `hosts` is outside ORGANIZATION_KEYS and INSTANCE_KEYS,
-  and `instances.set` refuses credentialed definitions.
- `host.sudo` lands as a hard wait under REQ-WAIT-3, and T25 enforces REQ-WAIT-2.
- The key handoff keeps the key off disk, argv and env (T19). `-F /dev/null`, a bus-written known_hosts
-  under `HostKeyAlias` and `StrictHostKeyChecking=yes` give no trust on first use. Forwarding is off and
-  `restrict` is on the host side.
- The command is built from argv with POSIX single quotes and `sudo -n --`, never taken as a string.
- The executor runs in the bus child as a broker.sock verb. The 10 s serial IPC (E5) is a sound reason not
-  to use a host op. It matches where 199 put the push (199 BUILD.md deviation 11), see N1.
- The brief's two named mutants are there: pin skip (M12, M13) and key leak (M15, M16).
- Section 6 states the limits plainly, including that `"any"` is root and can outlive the grant.
-
-## Blockers
-
-B1. The event log doesn't say what ran as root. D5 step 6 records `action.allowed` with "host, argv hash,
-stdin size and hash", and T22 checks that the bodies carry hashes. After routing, a within-role call has no
-decision, so no record anywhere in the stack names the command, only its sha256. The existing verbs log the
-thing done in clear: `requestWeb` records the url or query (broker.mjs:1521), and 1.7's push line says
-"Every push is logged with the remote, the ref, the commit and, when one was given, the decision" (draft
-:105). argv has already passed `#secretCheck` (step 1), so it holds no known secret, and it's capped at
-32 KiB. The design gives no reason to hash it. Fix: record `host`, `user` and `argv` in clear in the
-`requested` event, and keep output as sizes and hashes. Change T22 to assert argv is present and stdout,
-stderr and the key are not, and M24's partner: a mutant that drops argv from the event.
-
-B2. A pre-routing decision binds stdin that Jason never sees. D4 binds `stdinSha256`, and the question
-shows only "the host id and the argv". `stdin` can be 64 KiB (D6). So `argv: ["bash"]` with a script on
-stdin shows Jason the question "… bash", and he approves a script he can't read. Binding a hash he can't
-check doesn't give him a decision about it. Fix, either:
- the question shows stdin in full when present (it passed `#secretCheck`), or
- a gated call refuses non-empty stdin, and stdin is allowed only for a routed within-role call.
-Add a T9 case for the chosen rule and a mutant that drops it.
-
-B3. If the bus child dies, the key stays loaded and the call can't be revoked. D7 step 5 cleans up in a
-`finally`, and T18 covers success, refusal, timeout and a thrown error. A bus child that is SIGKILLed or
-crashes never runs the `finally`. `ssh-agent -D` has no lifetime of its own, so it keeps the key loaded on
-its socket until the machine reboots. A detached ssh keeps running the remote command. After the restart
-the new bus's kill map is empty, so D9's "revoke also kills a `host.run` in flight" no longer holds for
-that call. 199's push leans on git's own time limit for the same case (deviation 11, "git's own time limit
-ends it"). ssh-agent has no such limit unless one is given. Fix:
- `ssh-add -t <timeout + grace>`, so the agent drops the key on its own.
- At bus start, sweep `<configDir>/secrets/run/`: kill what each leftover dir's recorded pids name (check
-  they are still that ssh-agent or ssh first) and remove the dir.
- Consider `setpriv --pdeathsig SIGKILL` around ssh-agent and ssh, which the sandbox already uses
-  (sandbox.mjs:25-27). Probe it from node first.
-Add a test that SIGKILLs the bus child mid-call and then asserts the key is gone from the agent by the
-bound and the next start leaves no run dir. Add a mutant that drops `-t`.
-
-B4. Nothing routes section 4 to Jason. REQ-CRED-3 says "Who grants a host credential, and how, is set by
-the #424 design, which Jason approves", and section 4 ends "The table above is that answer". Section 10's
-only Jason question, Q-J1, is about the first grants at the live window. My approval of the design doesn't
-stand in for his. Fix: add a Q-J0 to section 10, sent through Mos before the build lands: approve the
-section 4 table. Name where his answer is recorded.
-
-## Notes (do not block)
-
-N1. 199 is on origin now: origin/megavolt/row199 at addee664a carries code and BUILD.md. The header's "199
-has no code on origin yet" and E12 are stale. The bus child already spawns git there: runtime.mjs:245 calls
-`publishRemote`, which runs `runGit` (seat/src/checkout.mjs:95-138) as a detached group leader with
-SIGTERM, a grace period and SIGKILL to the group. Reuse that shape, or the helper, for ssh rather than
-writing a second one. Q-S2: deviation 11 keeps the token and the push in the bus child, and the host side
-only polls. D5's assumption holds, and since the agent reaches broker.sock directly, 210 needs no poll.
-Sage confirms.
-N2. Section 6 should say that a registry entry for the stack's own machine, or any host where the stack's
-`<configDir>` lives, gives the agent with `"any"` every agent's keys and tokens, not just root there.
-Consider refusing a loopback `address` at load.
-N3. D5 says every spawn is `detached: true`, so each gets its own group. D7 step 3 says ssh-agent runs "in
-the same process group". Say which group ssh-agent is in, and make sure the timeout and revoke kill reach
-both the agent and ssh.
-N4. Prefix lists plus stdin: `[["tee"]]` or `[["dd"]]` writes any file as root from stdin. D6 already says
-a prefix list limits mistakes, not a determined agent. Say in the doc that stdin goes to the command, so
-some prefixes are root on their own.
-N5. Pass the user with `-l <user>` and the address as its own argument rather than `<user>@<address>`.
-Then nothing depends on how ssh splits on `@`, or on an IPv6 literal.
-N6. D8 is defense in depth. The remote never holds the private key, and forwarding is off, so output can
-carry the key only if the agent already had it. It's still right to keep. Also note that a `host.*` entry
-in the shared token map makes today's `assertClean` loop over a multi-line value that never matches
-(E3), which is harmless.
-N7. My #423 r5 condition (duckworth-0035) applies. If ops-01 changes step 1 to fit this design, for
-example per-agent `from=…,restrict` lines for localadmin, that changed step 1 comes to me as a diff before
-it runs. That's the live part, not this row.
-N8. Q-S1 (route `host.sudo` in 1.7) is Sage's and Jason's call. Without it, B2's rule matters on every
-call.
-
-A round with only B1-B4 and any notes taken gets a diff check, not a full re-read.
@@ -1,66 +0,0 @@
-# Review: Gizmoduck row 210 (#1707) DESIGN.md r2, diff check (duckworth-0043)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: DESIGN.md at b726e10f4 on gizmoduck/row210, blob
-8c6c6a8c5e (checked), per gizmoduck-0044. Diff 7b10bc0ff..b726e10f4, +153 -60, one file. I read the
-whole diff, including sage-1450's D6 change, which goes past my B items. Round 1 was REVIEW-r1.md
-(duckworth-0042). I checked the new cites at 9ba31b5b3:
- broker.mjs:126 `text()` caps a string at 4096, and :1654 runs `string(a.question)` on the raise.
- sandbox.mjs:44 is `KILL_WITH_PARENT = ["/usr/bin/setpriv", "--pdeathsig", "KILL", "--"]`.
- E12 and 199's cites at addee664a match what I read in round 1.
-I ran nothing.
-
-## Verdict: approve on b726e10f4, with one condition (C1)
-
- B1 resolved. `requested` and `completed` carry host, address, user and argv in clear, after
-  `#secretCheck`. stdin and output stay as size and sha256. T22 asserts both sides, and M30 drops argv.
- B2 resolved. The broker appends host, user, JSON-quoted argv and the full stdin to the question itself,
-  inside the existing 4096 cap. A raise that doesn't fit refuses `invalid-request`. T9 checks the stored
-  question and the cap, and M31 omits stdin. With sage-1455 (every call a Jason decision under 1.7, per
-  mos-1086), this was the rule that mattered most, and it now holds.
- B3 resolved.
-  - `setpriv --pdeathsig KILL --`, the sandbox's own prefix, wraps every spawn.
-  - `ssh-add -t <timeout+30>` bounds the key even if the agent survives.
-  - A pids file and a sweep before `broker.sock` listens. The sweep kills only a pid whose cmdline names
-    the dir, and leaves alone a dir whose bus pid is alive, which also covers two buses sharing
-    `<configDir>`.
-  - T27 covers all three, and M32-M34 drop each one.
- B4 resolved. Q-J0 is in section 10 in standalone form, routed through Mos before landing, and recorded in
-  DECISIONS.md. See C1.
- sage-1450's D6 holds together. There's no wildcard grant. Load refuses a string, empty, duplicate and
-  glob-character `commands`, and a shell or runner as `argv[0]` by basename (so `/bin/bash` too). T26 and
-  M6, M28 and M29 cover each one. Section 6's known limit names what closes it (`bwrap --unshare-net`) and
-  doesn't claim the allowlist closes it.
- Notes N1-N7 were taken as asked.
-
-## Condition
-
-C1. Q-J0 overstates revoke. Its line "You, Mos or the tester can revoke at once. The stack drops the key
-and stops a running command" goes to Jason word for word. Section 6 says "Revoke stops the stack's path,
-not remote processes. Killing ssh may leave a remote process running." He should approve on the accurate
-version. Replace the line with something like: "You, Mos or the tester can revoke at once. The stack drops
-the key and cuts its connection. A command already started on the machine may keep running." That's a
-one-line change that needs only my diff check, and it must be in before Mos sends Q-J0.
-
-## Notes (do not block)
-
-N1. The runner list is open by design (D6 says so), and it's Sage's ruling. Commands that run another
-command as root as directly as `env` or `nohup` do: `systemd-run`, `runuser`, `chroot`, `nsenter`,
-`unshare`, `setpriv`, `capsh`, `doas`, `pkexec`, `flock`, `stdbuf`, `ionice`, `chrt`, `taskset`, `strace`,
-`script`, `watch`, and the interpreters (`python3`, `perl`, `ruby`, `node`, `awk`). Adding them costs one
-array line each. `systemd-run` is the one I'd add first.
-N2. The loopback check names `127.0.0.0/8`, `::1` and `localhost`. getaddrinfo also takes these to the
-local machine: `0.0.0.0` (and `0`), `::`, `::ffff:127.0.0.1`, short or numeric IPv4 forms such as
-`127.1` or `2130706433`, which pass the DNS-name regex, and `*.localhost`, which systemd-resolved maps to
-loopback. Refuse a name made only of digits and dots unless it's a full four-part IPv4 literal, and run
-the address check on `net.isIP` output. Section 6 already says load can't know every address of the
-stack's machine, so this narrows the gap without closing it.
-N3. The sweep trusts that a live pid is still the bus that wrote the file. A reused pid leaves that dir in
-place until the next start. The cmdline check already stops a wrong kill. Recording each pid's start time
-(`/proc/<pid>/stat` field 22) beside it removes the reuse case. Low stakes, because `-t` and pdeathsig
-have already dropped the key.
-N4. T26 is listed after T27, and M28/M29 after M35. Cosmetic.
-N5. On a gated call the 4096 cap counts the agent's own question, the JSON-quoted argv and the stdin, so
-stdin's real room is smaller than 4 KiB. D4 says this. The tool help should say it too.
-
-Q-S3 (the host_run harness tool) is Sage's call. What remains: C1, then the build, manifest review and
-Sage's gate. The row lands after 199 and after the PRD version holding REQ-CRED-3.
@@ -1,35 +0,0 @@
-# Review: Gizmoduck row 210 DESIGN r3, C1 diff check (duckworth-0044)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-20. Subject: gizmoduck/row210 at e021dfa26, DESIGN.md blob
-ece332e306 (checked), per gizmoduck-0047. e021dfa26 is a fast-forward of b726e10f4, and the diff touches
-DESIGN.md only (+51 -26). I read the whole diff.
-
-## Verdict: C1 met, approve stands
-
-C1. Q-J0 now says "The stack drops the key and cuts its connection. A command already started on the machine
-may keep running." That matches section 6 and D9's revoke line. The quote is still 10 lines, and the yes/no
-question is last. Dropping "on the machine" from the ops-01 sentence loses nothing. Mos can send Q-J0 as it
-stands at e021dfa26.
-
-The rest of r3 matches the rulings and my r2 notes:
- Q-S3 (sage-1468): the `host_run` row is gone from D10, and the scope line says no `packages/harness` file
-  changes. My r2 N5 goes to Sage's follow-up row.
- N1 (sage-1473): D6 carries the whole runner list, five interpreters, and the line that the list can't be
-  complete and Jason's per-call decision is the control. T26 has one case per name.
- N2: I checked `net.isIP` on node here. It returns 0 for `127.1`, `2130706433`, `0177.0.0.1`,
-  `127.000.000.001` and `127.0.0.01`, and 4 for `10.1.1.53`. glibc resolves `0177.0.0.1` and `127.0.0.01`
-  to 127.0.0.1. The rule "a name of only digits and dots refuses unless `net.isIP` reads it as IPv4"
-  refuses all of them, octal included.
- N3: the pids file records the start time (field 22), the sweep treats a mismatch as dead, and T27 and M34
-  test it.
- N4: M28 and M29 are in order.
- The 1.7 approval line and the Q-S1 line agree with sage-1468.
-
-## Notes (do not block)
-
-N1. D6's interpreter list has `python3` but not `python`, `python3.12` or other versioned names, and has
-`awk` but not `gawk`, `mawk` or `nawk`. `sed` (GNU `e` command), `vi`/`vim`, `less` and `php` also start a
-shell. D6 already says the list isn't the control, so these are cheap additions to T26 if Gizmoduck wants
-them, not a requirement. A basename match on `python3*` and `*awk` would cover the versioned forms.
-
-The build can start on 199's candidate.
@@ -1,48 +0,0 @@
-# Review: row 210 round 4 diff, the B1 import fix (duckworth-0071)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Subject, per gizmoduck-0089 and sage-1619:
-`gizmoduck/row210-r3`, diff 3cf63efb4..c43008749, one commit, 9 files. Base cb5fdb064.
-
-I approved rounds 1 and 2 without catching B1 (broker.mjs:7 importing the unmounted `hosts.mjs`). This
-round checks Sage's four points and the second fix.
-
-## Verdict: approve
-
-Sage's checks:
-1. broker.mjs's imports are all import-free mounted files. The only import change is `:6`.
-   `validArgv` and `commandAllowed` now come from `business/src/vocabulary.mjs`, and the `hosts.mjs`
-   line is gone. `vocabulary.mjs` has 0 import statements at c43008749 and is in RUNNER_FILES
-   (`seat/src/sandbox.mjs`). broker.mjs's other imports are unchanged from cb5fdb064.
-2. The pins.
-   - `bus/tests/project-runtime.test.mjs:15-16, :27-28` pins the `createHash` line and the new
-     vocabulary line, each with a Row 210 comment. The `createHash` line was also missing from the
-     pin before this round.
-   - The seat pin needs no change, because `packages/seat` is byte-identical to 3cf63efb4 and
-     RUNNER_FILES is unchanged.
-3. No `errors.mjs` or `util.mjs` in the mounts: RUNNER_FILES is unchanged.
-4. The whole suites are on Sage's slot. Gizmoduck reports business 198/0, seat 164/0 and bus 498/0,
-   with 0 skipped. I didn't run suites.
-
-Also checked:
- The move is byte-identical. A `diff` of `ARGV_MAX`..`ARGV_BYTES`, `validArgv` and `commandAllowed`
-  between 3cf63efb4 `hosts.mjs` and c43008749 `vocabulary.mjs` shows no difference except a trailing
-  blank line. They use only the `Buffer` global.
- `hosts.mjs:7` imports `ARGV_MAX` back for `checkCommands` (`:100`), and `:11` re-exports all five.
-  The only other reader is `business/tests/hosts.test.mjs:9`.
- The roles fix. `roles/pm.md:54-57` and `roles/chief-of-staff.md:74-77` now name `host.sudo` among
-  the hard waits. I confirmed it was needed: with the two role files from 3cf63efb4,
-  `workflow-roles.test.mjs` fails 6/1, and with c43008749's it passes 7/0. The test asserts that the
-  listed waits are exactly GATED_ONLY, so this writes down routing the broker already applies. No
-  grant or authority list changes.
- The manifest has 23 lines, every hash matches c43008749, and its paths are the diff from cb5fdb064
-  less the four queue-210 packet files.
- Base drift: none of the 23 paths changed on origin/refactor since cb5fdb064 (c8bc5cf4c, 390ea5261,
-  011d41ba6).
- Hash pins: no test or script pins any changed file. 0 hits, against a control of 354 files that
-  hold a 64-hex string.
-
-My runs, single files in a detached worktree of c43008749:
- business: hosts 7/0, workflow-roles 7/0.
- bus: project-runtime 3/0, hard-waits 13/0, host-run 21/0.
- seat `sandbox.test.mjs` can't run in my session. It gives 7/3 on cb5fdb064 too ("no answer" from
-  the confined shell), so that one rests on Sage's gate.
@@ -1,76 +0,0 @@
-# Row 234 early check: split and name map (duckworth-0079)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in gizmoduck-0095. Subject: `gizmoduck/row234` 2aa54a67a,
-`agents/gizmoduck/work/queue-234/BUILD.md` (71 lines). Checked against r6 f9039682e
-(`agents/gizmoduck/work/machine-grant/DESIGN.md`, "r6:" below) and #436b section 7 at fa5658941. No code
-yet, so this is a design-to-build check, not a verdict on the row.
-
-## Result: the split and the name map stand, with four items for the candidate
-
-The name map is complete. Every `grant.`/`host.` name in r6 is one of these:
- The four renamed in the table (r6:257, :271, :394, :404).
- Already under `grant.`: step, applied, failed, revoked, revoke.closed.
- Not an event: `host.run`, `host.sudo`, and `host.grant` (r1's dropped action) and `grant.ask` (Q-S1, not
-  built).
-
-`decision` becoming `grantDecision` in every guarded body except the consume record follows section 7's
-spend rule (fa5658941 DESIGN.md:472-476). `grant.host.checked` and `grant.host.removed` carry no decision.
-
-The split matches r6 Q-S4 (r6:904-911) and the X/E sections. Row a has no path that makes a `host_grants`
-record outside a fixture, because the `host` method refuses `invalid-request` until row b. Items 1 to 8 match
-r6 S1, X1, E1 to E4 and X4's first and third bullets.
-
-## G21 fixture (question 1): acceptable, on these terms
-
-Row a can't produce `hostLineLeft`. An enrollment has no remote step, so its failures leave no line. A fixture
-is therefore the only way to test the check in row a.
- F1. Write the fixture through row a's private grant writer, in the real shape: `action.allowed`, actor
-  (NULL, 'grant'), `body.action` 'grant.failed', `body.host`, `body.hostLineLeft`. Don't write it with raw
-  SQL around the trigger.
- F2. Read `body.hostLineLeft` from any guarded body, not only `grant.failed`. Row b's
-  `grant.revoke.closed` carries it too (r6:715-717).
- F3. r6's `grant.revoke.closed` body is `{tag, hostLineLeft}` (r6:716). It names no host. Either row b
-  adds `host` to that body, or the check maps the tag to a host through the recorded `grant.step` tags.
-  Fix which one in BUILD.md now, so row a's reader and row b's writer agree.
- F4. "No later `sweep` cleared it" (r6:403) needs `grant.sweep`, which row b writes. Say in BUILD.md
-  that row b adds the sweep clear to `hosts.remove` with a G21 case. Row b's G8 or G13 should also show that
-  `hosts.remove` refuses after a real write, not only after the fixture.
-
-## Moves and gaps (question 2)
-
- M1. G4 for the `host-enroll` block goes in row a. Row a renders that block (item 3, r6:240-242): the
-  fingerprints, the key lines and the sudo line. Row a should test that a question can't forge it and that
-  the 4096-character limit holds with it appended. G4 for the `host` block stays in row b.
- M2. The tag function lands in row a, because E2 step 2 uses it for the installer tag (r6:265-266). Move
-  G24's first sentence (64-character names with `.` and `_` give distinct tags of the fixed length) and the
-  mutant "build the tag without the business" to row a. The `sweep` half of G24 stays in row b.
- M3. The Approve record check (X4 first bullet, r6:593-596) is row a code, but no row a G-test covers it.
-  G22 is row b. Add a row a test on store fixtures that `host.run` refuses `host-not-granted` for each of:
-  - no record
-  - a record whose decision is unresolved
-  - a decision resolved by an arbiter, the tester or an agent, or not via cli
-  - a consume record with `operation: 'grant.host-enroll'` instead of `'grant.host'`
-  - an unspent decision
-
-  Also add a restart test that a `host_grants` fixture yields a `Credentials` reference (X4 third bullet).
-  The mutant "`host.run` reads the business file instead of the grant record" goes in row a.
- M4. Item 8 lists status, the start reconcile and `openGrantDecisions`. Add `hosts.remove`'s
-  `hostLineLeft` reader (F2). The look-alike test should cover it: an `action.refused` or session-written
-  `hostLineLeft` doesn't block a remove.
-
-N1 (doesn't block). BUILD.md splits the G-tests but not r6's mutant list (r6:838-883), and r6 leaves the
-numbering to BUILD.md. A per-row list before the candidate saves a round. By my reading these are row a's:
- drop the chief check
- start on a mint with no `grant`
- start on an arbiter resolve, or on `no`
- skip the keyscan compare, or compare one key
- the private key in an event body
- drop the not-enrolled check
- drop the `hosts` primary key
- skip the start check for a resolved, unspent enrollment
- `host.run` reads the business file
- the tag without the business
- the writer mutants (`from=`, a line outside the tag pattern, `O_NOFOLLOW`, a dropped group, the user
-  pattern, `privileged` without `users`, a sudo user not in `privileged`)
- section 7's trigger mutants
- one reader-filter mutant
@@ -1,59 +0,0 @@
-# Row 234 early code read, follow-up (duckworth-0083)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in gizmoduck-0102. This checks ad7373c1b on
-`gizmoduck/row234` (one commit on f4de24d39, 6 files, +143/-29) against duckworth-0081. It's still not the
-manifest verdict.
-
-## Result: B1 to B3 resolved
-
- B1 (G10): `grant-enroll.test.mjs:269`.
-  - A second start on a spent decision returns `decision-consumed`, and the events, the host row and the
-    message count don't change.
-  - An open raise returns `not-authorized`. So does one resolved yes by the chief.
-  - After that there's no web2 row and no key file, and `reconcileGrants` returns [].
-  - The new public `runEnrollment` (`broker.mjs:745`) only wraps `#runEnrollment`. No verb, server
-    route or runtime op reaches it. The only other call is the resolve hook at :2445. It's the same kind
-    of trusted entry as `reconcileGrants`, and step 1 checks everything again. I accept it.
-  - The return codes don't change anything the hook depends on, because `setImmediate` ignores them.
- B2 (G18):
-  - The host half is at `host-run.test.mjs:297`. `hg.check` with a wrong pin refuses
-    `host-key-mismatch`, and the stub `list` never runs.
-  - The broker half is at `grant-enroll.test.mjs:401`. The host stays `pending-install` with
-    `checked_at` null, and there's no `grant.host.checked`.
- B3:
-  - G6 is at :251. A withdraw by the chief and by the human, then an arbiter resolve yes, write nothing,
-    and `runEnrollment` returns `not-authorized`.
-  - G20 is at :390. The reader is refused `read-only`, and the human's check reaches `ready` with `by`
-    `['jason']`.
- N2 is fixed. A timeout gives '', which is not the expected line, so the writer refuses `user-sudo`,
-  logs it and exits 1.
- N3 is fixed in the comment.
- N4 stands as Gizmoduck says. r6:578 lists the tag only for the start reconcile's `interrupted`.
- N5 is in the run sheet.
-
-## Notes (no block)
-
- N8. G10's agent-resolved row goes in with `via 'broker'` (:280), so `#approvedGrant` refuses at the
-  via check and never reaches the `by` check. A second row with `via 'cli'` and `by 'chief'` would pin
-  `by == human` too. The A1 to A23 run will show whether a mutant on the `by` check survives. If one
-  does, this is the test to add.
- N9. G18's control (:310) calls `runHost` with the fixture's entry, not `hg.check` with the right pin.
-  So it shows the stub works, but not that `hg.check` passes the record's keys through when they're
-  right. E4's broker tests use a fake check, so nothing runs `hg.check` end to end with a good pin. That
-  could be a small follow-up, or the #433 VM covers it.
-
-## My runs
-
-In a detached worktree of ad7373c1b, pass/fail:
-
-| file | result |
-| --- | --- |
-| bus grant-enroll | 24/0 |
-| bus host-run | 24/0 |
-| bus host-tools | 6/0 |
-| bus grant-migration | 5/0 |
-| bus hard-waits | 13/0 |
-| bus project-runtime | 3/0 |
-| bus credentials | 5/0 |
-
-`mosaic-keys-write` parses under python3 -I. I ran no suite and no mutant.
@@ -1,92 +0,0 @@
-# Row 234 early code read (duckworth-0081)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in gizmoduck-0101, before the formal request. Candidate
-code `gizmoduck/row234` f4de24d39 on 8fede5fc6 (39 files, +2953/-187). Brief:
-`docs/plans/2026-10-20_host-credentials.md` "Machine grant row a", whose gate needs "the design's section
-10 tests and mutants for row a". Design r6 f9039682e, section 7 fa5658941. This is not the manifest
-verdict. That one comes after Sage's A1 to A23 run.
-
-## Verdict: changes, 3 blockers
-
-BUILD.md:68-69 lists G6, G10, G18 and G20 among row a's tests. The brief's gate requires them, so each
-missing case blocks.
-
- B1. G10 has no test (r6:818). No row a test starts a second enrollment for a spent decision and gets
-  `decision-consumed`. None shows `#consumeGrant` (`broker.mjs:678`, `#spent` at :681) refusing an
-  unresolved or an agent-resolved decision. A8 (`grant-enroll.test.mjs:250`) uses two decisions, so it
-  tests `host-enrolled`, not this. The only `decision-consumed` assert near hosts is `host-run.test.mjs:250`,
-  which covers row 210's host.run. The direct way is to call the executor or `reconcileGrants` twice for
-  one resolved decision, and once each for an open decision and an agent-resolved fixture.
- B2. G18 has no test (r6:826). The code path exists: `host-grant.mjs:207-211` calls `runHost` with the
-  pinned keys, and `host-run.mjs:197` refuses `host-key-mismatch` on ssh exit 255. But
-  `grant-enroll.test.mjs:333-356` uses a fake check that never throws that code, and
-  `host-tools.test.mjs` tests only the writer, mosaic-keys, sudoers and sshd. A test needs to show that a
-  wrong pin refuses `host-key-mismatch`, runs nothing, and leaves the record `pending-install` with no
-  `grant.host.checked`. The fake check can throw the BusError for the broker half. The runHost half can
-  reuse the host-run.test.mjs ssh stand-in that gives :290 its `host-key-mismatch`.
- B3. G6 and G20 are partly tested.
-  - G6 (r6:814): the no is tested (A4, :231), and so are the tester, pm and chief resolves (A3, :237).
-    The withdraw and the arbiter resolve have no case. A withdraw of an open `host-enroll` decision must
-    start nothing.
-  - G20 (r6:828): the chief reaches `ready` (:341) and the tester gets past the role check to
-    `host-changed` (:355). The human's `hosts.check` is never called. It must reach `ready` through
-    `#hostsCaller`'s `#human` leg.
-
-## Notes (no block)
-
- N1. A3 (`grant-enroll.test.mjs:237`) can't reach `#approvedGrant`'s via and by checks, because every
-  resolve it tries is refused first. The M3 fixtures in `host-run.test.mjs` cover those checks, so
-  nothing is untested. The test name reads as more than it shows.
- N2. `mosaic-keys-write:255-266`: `main` catches `Refused` and `OSError`. A `sudo -l` timeout raises
-  `subprocess.TimeoutExpired`, which escapes, so the writer exits with a traceback and logs nothing.
-  Catching it as `refused user-sudo` keeps every refusal in syslog.
- N3. `host-grant.mjs:86,106`: a keyscan that exits nonzero, such as an unreachable host, resolves with
-  no lines, so the raise refuses `host-key-mismatch`. The comment says a scan that can't run refuses
-  `host-failed`. That holds only for a spawn error. G17 doesn't decide which code is right. Worth one line
-  in BUILD.md or the comment.
- N4. In the run, `#enrollFailed` writes `grant.failed` with no tag. `reconcileGrants` does tag it. If
-  section 7 leaves the tag optional this is fine. Otherwise the two should match.
- N5. `read_conf(host, 'privileged')` refuses when the file is missing (`mosaic-keys-write:136-138`). The
-  #433 run sheet should say to create an empty, root-owned `/etc/mosaic-keys/privileged`.
- N6. `#hostAccess` binding the grant's agent and host (`broker.mjs:692`) goes beyond X4. I agree with
-  it. It narrows and refuses nothing X4 allows.
- N7. `isHostKind` (`business/src/resolve.mjs:92`) can't be reached and stays, as BUILD.md records. No
-  objection.
-
-## Checked, no finding
-
- `#approvedGrant`, `#consumeGrant`, `#runEnrollment`'s two transactions and their catch, and
-  `reconcileGrants` for both the spent-unfinished and the open decision. `#openGrantDecisions` uses the
-  unfiltered `#spent`. That is sound while no verb consumes `credential.mint`.
- `#raiseGrant` order, with the enroll block appended before the 4096 cap (M1, :165).
- `hosts.remove` order (host-unknown, host-in-use, host-line-left, then delete, event, unenroll last), and
-  `hosts.check` with its host-changed recheck in the transaction.
- 3i-3j.sql: hosts and host_grants keys, CHECKs, the FK, and the `events_grant_actor` trigger. The trigger
-  cases are in `grant-migration.test.mjs:134`.
- The writer's dir, lock, user-file and tmp handling (G25, `host-tools.test.mjs:225`).
- Hash pins: there is no 64-hex pin in `packages/*/tests/*` or `scripts/test-*.sh` on a changed path. The
-  one basename hit, `channel-proof.test.mjs:12` for `bus/src/human-cli.mjs`, is a file this row doesn't
-  change. The control found pins in account-, comment-migration and channel-proof.
- RUNNER_FILES rule (sage-1619): the broker adds the `HOST_ID` import. I ran seat sandbox.test.mjs and
-  bus project-runtime.test.mjs (below).
-
-## My runs
-
-Single files in a detached worktree of f4de24d39, pass/fail:
-
-| file | result |
-| --- | --- |
-| bus grant-enroll | 20/0 |
-| bus host-run | 23/0 |
-| bus host-tools | 6/0 |
-| bus grant-migration | 5/0 |
-| bus hard-waits | 13/0 |
-| bus project-runtime | 3/0 |
-| bus credentials | 5/0 |
-| bus chief-of-staff | 18/0 |
-| bus account-, comment-, name-, spec-, thread-, usage-migration | 3/0, 5/0, 1/0, 1/0, 3/0, 1/0 |
-| business hosts | 4/0 |
-| cli hosts | 5/0 |
-| seat sandbox | 7/3, the same environmental failure I get on base commits in this session |
-
-I ran no suite and no mutant. Those are slot work.
@@ -1,61 +0,0 @@
-# Row 234 round 1, content (duckworth-0084)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in sage-1711. Request #1740 comment 29903, revs 2645-2646.
-Candidate `gizmoduck/row234` 861182fa6 on 8fede5fc6, manifest sha256
-2114a09d5a1963279f3cb37bd46bbad4d092b48499d867740b64129a928daf71 (39 lines, Gizmoduck's in-review move,
-rev 2642). Brief: `docs/plans/2026-10-20_host-credentials.md` "Machine grant row a" (blob 64451be5). Design
-r6 f9039682e, section 7 fa5658941.
-
-I rebuilt the manifest from the queue text and it has that digest. Each of the 39 digests matches its blob
-at 861182fa6, and the path set equals `git diff --name-only 8fede5fc6 861182fa6`.
-
-Per sage-1711, this note reviews content on 861182fa6. Two manifest paths have drifted on refactor since
-the base: `packages/bus/src/runtime.mjs` (row 242) and `packages/cli/README.md` (row 232). Gizmoduck
-rebases as `gizmoduck/row234-r2`. I'll check those two merges on round 2 and record the verdict there.
-
-## Verdict on content: approve
-
-My reading of the code is in duckworth-0081 (REVIEW-code-early.md, 88402c25e) and duckworth-0083
-(REVIEW-code-early-2.md, 947d9ce69). Since then:
-
-1. ad7373c1b..861182fa6 changes three files: BUILD.md, the G10 web3 row (A3b's killer, at
-   `grant-enroll.test.mjs:282-285`), and the "A22b, sage-1703" test in `grant-migration.test.mjs`.
-   - The A22b test writes two session rows at 3i, then migrates them: a `grant.host.removed` with
-     `hostLineLeft`, and a `grant.host-enroll` consume look-alike for decision d1. After the step both
-     rows are still there. `reconcileGrants` ends nothing, and `hosts.remove` still removes web1.
-   - With the actor filter gone from `GRANT_EVIDENCE`, the first row would refuse `host-line-left`, and
-     the second would make d1 look spent and unfinished. So the test pins the filter that the trigger
-     can't stand in for on pre-3j rows.
-2. The section 10 row a tests are all present. G1, G5, G6, G10, G11 (enroll), G14 to G18, G20, G21 and
-   G25 are there, along with the migration, trigger and reader-filter tests and M1 to M4. None is
-   missing.
-3. The business and cli diffs, which I hadn't read before:
-   - `business.mjs` refuses `hosts` at the top level and in a role with one message that says where the
-     key went (S1). It no longer builds `host.<id>` kinds from the file (X4).
-   - `hosts.mjs` keeps `checkAddress`, `USER`, `HOST_KEY` and `checkCommands` as exports, which the
-     enrollment raise and row b use, and drops the registry and grant parsers.
-   - `cli/src/hosts.mjs` exits 4 on usage and 2 on a bus refusal, and reads no key.
-   - `scripts/mosaic` sends `hosts` to packages/cli. That's covered at `cli/tests/hosts.test.mjs:67`.
-4. Mutants, 25/25 on Sage's slot. I read the table and the results (BUILD.md:102-131, 246-262). I didn't
-   run them.
-   - On A9, I don't want a behaviour-level mutant. Without the `hosts` primary key, `host_grants`' FK has
-     no parent key, so a store like that can't open. The behaviour the key backs is the second-enrollment
-     refusal, and A8 (`#hostRecord` in step 1) kills that by assertion in the S1 test. The A9 test
-     (`grant-enroll.test.mjs:314-323`) asserts the constraint by message, so it would also kill a variant
-     that drops the FK too. A9 is a backstop behind A8.
-5. Hash pins: `packages/*/tests/*` and `scripts/test-*.sh` have no 64-hex pin on any of the new or
-   changed grant, host or tools paths. The positive control from duckworth-0081 still holds.
-
-## Notes (no block)
-
- N10. `cli/src/hosts.mjs` checks the verb with `shape[verb]` on a plain object. So
-  `mosaic hosts constructor web1` passes the usage check and calls `hosts.constructor`. The bus refuses an
-  unknown verb, so the result is exit 2 with the bus's code instead of exit 4 with the usage. Nothing is
-  reached, so `Object.hasOwn(shape, verb)` can wait for a later cli row.
- N9 (from duckworth-0083) stays as BUILD.md's follow-up for the #433 VM run.
-
-## My runs
-
-At 861182fa6, singly, pass/fail: bus grant-enroll 24/0, grant-migration 6/0, host-run 24/0. My earlier
-singles at ad7373c1b (0083) and f4de24d39 (0081) cover the files that haven't changed since. I ran no
-suite and no mutant.
@@ -1,42 +0,0 @@
-# Row 234 round 2, rebase check (duckworth-0085)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in gizmoduck-0113 and sage-1725. Request #1740 comment 29923,
-revs 2660-2661. Candidate `gizmoduck/row234-r2` b0320d395 on refactor 9b5362018, manifest
-`/mnt/storage/scratch/gizmo-234-out/manifest-r2.txt`, sha256
-08306afe4f2d8b01a6edd30b4e40f275d92912ca5d330bcf771e7d14b5beaddd (39 lines). Content approved on 861182fa6 in
-duckworth-0084 (REVIEW-r1.md, 048d907b2, comment 29919).
-
-## Verdict: approve
-
-1. The manifest holds. All 39 digests match their blobs at b0320d395. The path set equals
-   `git diff --name-only 9b5362018 b0320d395` and r1's set. Only `packages/bus/src/runtime.mjs` and
-   `packages/cli/README.md` differ from r1.
-2. `git range-diff 8fede5fc6..861182fa6 9b5362018..b0320d395` gives 13 `=`.
-3. The two merges are clean.
-   - For each file, `git merge-file` of 861182fa6 (ours), 8fede5fc6 (base) and 9b5362018 (theirs) exits 0,
-     and its output equals the r2 blob byte for byte. Row 234's +/- lines are identical to r1's.
-   - Since the base, `runtime.mjs` moved only with 5fb736b92 (row 242), and `cli/README.md` moved only with
-     e65a3ab4d (row 232).
-4. The merged code doesn't interact.
-   - In `runtime.mjs`, row 234's hunks are at :17-200: the host grant store references, `hostGrant`, moving
-     `runRoot` above the Broker, and `reconcileGrants` at start. Row 242's are at :260-332, in the publish
-     socket's `publishRefused` and `settle`. Row 242 adds no use of `runRoot`, `credentials`, `references`,
-     `storeRoot`, `hostGrant` or `reconcileGrants`.
-   - In `cli/README.md`, row 232's units paragraph is at :777 and row 234's hosts section is at :1049.
-
-## Notes (no block)
-
- N11. In my session, `packages/cli/tests/thread-launch.test.mjs` gives 4 pass, 7 fail at b0320d395. Every
-  failure is in the launched run: at :340 the run's claim exits 1, not 21, and the rest time out waiting
-  for a session reply. That matches my session's seat sandbox failure (sandbox.test.mjs 7/3 on base
-  commits). Per sage-1732, this is left to Sage's landing gate, which runs the whole cli suite on this tree
-  from a session where the sandbox works. Gizmoduck's singles (387/0) include this file.
- N10 (from 0084) goes to row 235's carry list or a cli follow-up (sage-1719).
-
-## My runs
-
-At b0320d395, 30 test files: the ones that import `runtime.mjs` or read `cli/README.md`, plus the row 234
-and row 242 tests. 29 files pass with 0 failures, 277 tests in all (summed by awk over the logs), including bus grant-enroll 24/0,
-grant-migration 6/0, host-run 24/0, publish 13/0 and project-runtime 3/0, cli publish-socket 9/0, host 42/0
-and hosts 5/0. They ran in parallel, not one at a time, and in Researcher's slot without a grant (sage-1721).
-I reran thread-launch alone afterwards. No suite and no mutant.
@@ -1,51 +0,0 @@
-# Row 234 round 3, schema count tests (duckworth-0086)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in gizmoduck-0120. Scope from sage-1742, sage-1746 and
-sage-1747. Candidate `gizmoduck/row234-r3` c783d5e39, one commit on row 233's landing 57f59e0c3
-(origin/refactor). Manifest `/mnt/storage/scratch/gizmo-234-out/manifest-r3.txt`, sha256
-4782c8b5ecb737b1e595f2b32eca403f71c82aa750bbdded707c5aa485557ae9 (41 lines). Revs 2679 and 2680. Round 2 was
-approved on b0320d395 (duckworth-0085, rev 2670).
-
-## Verdict: approve
-
-1. The manifest holds. All 41 digests match their blobs at c783d5e39, and the path set equals
-   `git diff --name-only 57f59e0c3 c783d5e39`.
-2. The r2 paths are unchanged.
-   - 38 of the 41 paths have the same blob ids as b0320d395. The three that differ are BUILD.md,
-     `schema.test.mjs` and `stack-release.test.mjs`. Modes match.
-   - 9b5362018..57f59e0c3 (row 233 and four doc commits) touches one manifest path,
-     `stack-release.test.mjs`. So keeping r2's blobs for the other 38 reverts nothing.
-3. `schema.test.mjs:522-524`: the table count goes from 16 to 18 and the trigger count from 70 to 71, with a
-   comment that names row 234, the three objects and grant-migration.test.mjs. These match 3i-3j.sql's two
-   tables and its one trigger.
-4. `git diff 57f59e0c3:packages/cli/tests/stack-release.test.mjs c783d5e39:...` is two added lines in T46's
-   `untimed` object (`host_grants`, `hosts`), in sorted order, and nothing else. That follows Sage's ruling
-   (sage-1745).
-5. BUILD.md's diff from b0320d395 adds lines and removes none. The "Round 3" section holds against the
-   code.
-   - A grep for INSERT, UPDATE, DELETE and REPLACE on either table in `packages/*/src` finds five writes,
-     all on `hosts`, at broker.mjs:737, :763, :783, :932 and :950. Each sits in the transaction and beside
-     the `grant.*` event that BUILD.md names.
-   - `#enrollFailed` (:736) has only the two callers it lists, :816 and :849-851, and both wrap it in
-     `#store.transaction`.
-   - `#grantEvent` (:657) goes through `writeGrantEvent` (:201) to the events INSERT at :212.
-   - Nothing writes `host_grants`. The untimed placement holds for row a, and row b's writes go to row
-     235's carry list.
-6. The count-pin grep (`sqlite_master|schema\.sql` over `packages/*/tests/*` and `scripts/test-*.sh`)
-   gives 14 files. The positive control, schema.test.mjs, is among them. I checked the hits BUILD.md
-   doesn't name. `stack-release-fixture.mjs:214` and `scripts/test-land-work.sh:254` each look up one
-   named object, and `state.test.mjs:106` lists tables without pinning them. So no other test pins the
-   table list or counts.
-
-## Notes (no block)
-
- N12. BUILD.md's round 3 list of other hits leaves out `stack-release-fixture.mjs:214` and
-  `scripts/test-land-work.sh:254`. Both are fine, as item 6 says. This is doc-only.
- Carry for row 235: each host_grants write shares a transaction with a `grant.*` event, so the untimed
-  placement stays true. Also N10 from 0084.
-
-## My runs
-
-None this round. Gizmoduck ran the two changed test files singly on c783d5e39 in Sage's slot:
-stack-release 195/0 and schema 1/0 (logs in gizmo-234-out/singles-r3m/). I didn't run them myself. Sage's
-landing gate runs the suites.
@@ -1,68 +0,0 @@
-# Row 235 round 1 (duckworth-0089)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Sage asked for this review in sage-1934. Request #1741
-comment 30020, revs 2801-2802. Candidate `gizmoduck/row235-e` ed4193316, one commit on 62ddc96cc,
-13 paths, manifest digest dad377ca8fe4…. The brief is b16e236188f6, section "Machine grant row b".
-
-## Verdict: approve
-
-1. The manifest holds. `queue review verify-commit 235 ed4193316…` prints "matches the manifest
-   candidate (13 paths)". 62ddc96cc..origin/refactor touches only `packages/library/*` and
-   `agents/gosalyn/work/queue-231/BUILD.md`, so nothing in the manifest drifted.
-2. Writer refusal (mos-1163). `#hostDefinition` (`broker.mjs:858-866`) fails `host-creative-role` at
-   :862, before `host-not-declared` at :864. So a creative role whose definition declares `host` still
-   refuses. It's called from the raise (`#hostGrantBinding`, :1266) and from step 1's recheck
-   (`#hostGrantRecheck`, :879), so a role that turned creative after the raise ends at step 1, spent.
-   - grant-host.test.mjs:115 raises for `muse`. Its fixture (:45-47) maps `research` to a copy of
-     `ops`, so only the creative check can refuse it.
-   - grant-executor.test.mjs:947 restarts with `creativeOps`, which keeps ops's content under
-     `research`, so `definitionSha256` still matches. The grant ends `host-creative-role`, a second
-     start gives `decision-consumed`, and nothing remote runs.
-   - B38 names both tests. Both are discriminating.
-3. Spend refusal (mos-1164). `#hostAccess` (:711-714) fails `host-creative-role` before it reads the
-   record. The record stays, so `hosts revoke` still works. The callers are `host.run` (:2543) and the
-   `host.sudo` raise (:2778). 213's `decision.raise` check (:2174-2177, `decision-not-allowed`) already
-   refuses the `host.sudo` raise for a creative role, so B39 can only be killed through `host.run`.
-   grant-executor.test.mjs:958 does that. It applies a grant, restarts with ops creative, and checks
-   that `host.run` refuses with no request, no `sudo.log` line, and the record kept.
-4. The spend question. I checked BUILD.md:106-130 against the code, and it holds.
-   - Only the chief raises a host grant: `grant-chief-only` at :1238, and the hosts verbs at :1313.
-     `CREATIVE_DEFINITIONS` (`vocabulary.mjs:176`) doesn't include `chief-of-staff`.
-   - `#consumeGrant` (:697) is called with `host` only from `#runHostGrant` (:902) and from the restart
-     reconcile (:1106), which ends the grant interrupted.
-   - `#runHostGrant` starts from the resolve hook (:2881) only when `#approvedGrant` returns a grant.
-     That needs the decision resolved yes, via `cli`, by the business human (:691).
-   - The public `runHostGrant` (:891) is a trusted API, and no verb reaches it.
-   - `host.run` also needs `grant.agent === s.role` (:722).
-   - So a creative role can't raise, approve or spend a host grant, its own or another role's. The gap
-     BUILD names is the chief raising a grant whose agent is creative. Point 2 closes it.
-5. The 213 rebase. 361ba2387 is an ancestor of 62ddc96cc. The import at :6 matches the base. 213's
-   block (base :1734-1737) is unchanged at :2174-2177. None of 213's added broker lines are among row
-   235's removed lines.
-6. The upsert mutant. I agree it's equivalent.
-   - Row 235 has no undo to `previous`. `previous` is only read at step 1 (:911) and written into the
-     `commit` step event (:960).
-   - On a commands change, everything from step 1's transaction (:901-913) to the UPDATE (:977-985)
-     is synchronous: the key claim (:924), `grantTag`, the `commit` step and `stop()`. Steps 2-4, the
-     only awaits, run only when `!change` (:947). So no revoke can delete the record between the read
-     and the UPDATE.
-   - The UPDATE and `applied()` share one transaction (:977-985), and `out.changes !== 1` fails
-     `host-changed`. An upsert there would always find one row, so it behaves the same.
-   - The new-grant path inserts inside `issue`'s callback (:989-997). That's a plain INSERT, not the
-     mutant's target.
-7. N10 is in. `packages/cli/src/hosts.mjs:36` checks `Object.hasOwn(shape, verb)`, and :17 does the
-   same for repeated values.
-8. Hash and count pins. The 64-hex grep over `packages/*/tests/*` and `scripts/test-*.sh` finds pins in
-   other files, which is the positive control, but none on the 13 paths. No path-join reads of them
-   either. The diff touches no schema or migration file, so there are no count pins to check.
-
-## Notes (no block)
-
- N1. The bus suite hasn't run whole on this candidate. The evidence is run 2 on Sage's slot
-  (10:12:52-10:14:51Z): grant-host 9/9, grant-executor 37/37, grant-enroll 24/24, and B16, B23, B27,
-  B38 and B39 killed. B1-B37 ran on 5df4b52c5 before the rebase. Sage's landing gate is the first
-  whole run, and this approval assumes it's green.
-
-## My runs
-
-None. I read the code, the tests and BUILD.md at ed4193316 with `git show`.
@@ -1,56 +0,0 @@
-# Review: row 237 round 1, one decision publishes once (duckworth-0069)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Subject, per megavolt-0067:
- `megavolt/row237` at e42415935, one commit on base cb5fdb064 (row 199's landing). 4 files, +123.
- Manifest `manifest-r1-e42415935.txt`, sha256 bb777cb0…8b7e. I checked it: 4 lines, every hash matches
-  the candidate's blob, and the paths equal `git diff --name-only cb5fdb064 e42415935`.
- Base drift: origin/refactor changed only `packages/business/README.md` since cb5fdb064. That isn't a
-  manifest path.
-
-## Verdict: approve
-
-This closes my row 199 note N1 (duckworth-0068).
-
-Checked and holding:
- `checkPublish` refuses `publish-busy` (`broker.mjs:1040`) when an open ticket holds the same business
-  and decision. The check and the `#publishes.set` at `:1043` run in one synchronous block, so no second
-  call can interleave between them.
- The comparison is exact. `p.decision` is the request's id. `result.decision` is `d.id` from
-  `#authorityFor` (`:821-822`), which `#decision` (`:663-664`) looks up with `id=?`. The decisions
-  table has no NOCASE collation, so the two strings are equal whenever a ticket exists. No alias or
-  case form slips past the check.
- Order: the authority and fact checks run first, so a spent decision still refuses
-  `decision-consumed` before `publish-busy`. A within-role publish has no decision and skips the check.
- Both exits drop the ticket: `recordPublish` (`:1102`) and `publishRefused` (`:1111`). So a refusal
-  frees the decision for a retry, and the broker test shows that.
- Megavolt's reason for rejecting the `#spent` recheck in `publishTarget` is right. Nothing is spent
-  until `recordPublish`, after the push, so both racing tickets would pass that recheck. My N1 offered
-  it as an option, and it wouldn't have closed the race.
- Hash pins: no test pins a manifest file. `git grep` over `packages/*/tests/*` for those paths next to
-  a 64-hex string found 0, against a control of 11 test files that hold a 64-hex string.
-
-My runs, in a detached worktree of e42415935:
- `packages/bus/tests/publish.test.mjs`: 13/13.
- `packages/cli/tests/publish-socket.test.mjs`: 8/8.
- M1 (delete the `publish-busy` line): bus 12/1, cli 7/1, so it's killed in both. `git diff` was
-  clean after the restore.
-
-## Notes (do not block)
-
-N1. Residual 2 can still put the commit on a second fork ref.
- After `publish-timeout` the socket files `publishRefused`, which drops the ticket while the bus
-  process's push may still be running.
- A retry on the same decision to another branch then gets a ticket and pushes too. That's the N1
-  shape again, but only after a timeout.
- It's the same scope as before: the approved commit on the agent's own fork. Closing it needs the
-  runtime to keep the decision busy until its push settles, which is outside this row's brief. I'd row
-  it as a follow-up.
-
-N2. Residual 1 (a ticket orphaned by a host that died mid-publish) fails closed with `publish-busy`
-until a bus restart. That's acceptable as is.
-
-N3. Residual 3 (`checkLand` has the same ticket-then-spend shape) is Sage's to row or dismiss. I
-haven't checked whether two landings on one decision can both reach main.
-
-Gate: the cli test file changed, so I agree the cli suite (or that file) runs on Sage's gate with the
-bus suite and `scripts/test-*.sh`.
@@ -1,37 +0,0 @@
-# Row 241 round 1 (duckworth-0080)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in megavolt-0073. Brief: `docs/plans/2026-10-20_agent-credentials.md`,
-"Brief: row 237 follow-up, one decision lands once, with tests at the broker" (c25785d3d). Candidate
-`megavolt/row241` 3e3ed303e on f5753c0e8, manifest sha256
-e82668642589eefca8b22433f1b0c7a24432f1993c0050f0a4b74c1146c93c2f. I rebuilt it from the two blobs at 3e3ed303e,
-and it matches. The diff is the two manifest paths only (+93), tests and BUILD.md, with no source.
-
-## Verdict: approve, no findings
-
-1. The test meets the brief. `land.test.mjs:312` opens two `checkLand` tickets on one decision. The first
-   `recordLand` lands. The second refuses `decision-consumed` at :319. Before `landRefused` it leaves one
-   merge `action.allowed` (commit B), one RESULT and no `action.refused`.
-   - `recordLand` runs inside `#store.transaction` (`broker.mjs:1001`), so a refusal at `#landFacts` rolls
-     back everything.
-   - With the `#spent` line gone, the second call passes every other check in `#landFacts` (same task,
-     same latest push, same reviewed commit) and would record a second merge. So :319 is the assert that
-     pins the recheck, as BUILD.md says.
-   - The tail checks that `landRefused` files the code once and ends the ticket (`land-unknown` after).
-2. The three guard cites are true at f5753c0e8:
-   - `land-busy` at `git-socket.mjs:351`. The slot is set at :353-354, before the first await, and freed
-     at :358 unless `slot.done`.
-   - The CAS `update-ref main land.commit land.old` at `working.mjs:391`, refusing `base-moved` at :392.
-     The move back is at :396, and `rollback-failed` at :397.
-   - `#spent` at `broker.mjs:963` in `#landFacts`. That function is called from `checkLand` (:950) and
-     `recordLand` (:1006). The brief's :945 predates row 210. BUILD.md records the move.
-3. The mutant table names real tests and asserts: `land.test.mjs:94`/:144, `working.test.mjs:555`/:567
-   (base-moved) and `git-socket.test.mjs:812`/:825 (land-busy). M2 is killed by the existing test, so
-   working.test.mjs is left alone per the brief. I didn't run the mutants. They are slot work, on Sage's
-   gate.
-4. No test or script pins a hash of either path. The four hits for `land.test.mjs` in the tests are
-   comments.
-
-My runs, in a detached worktree of 3e3ed303e: `land.test.mjs` 18/0, and the new test alone 1/0.
-
-I didn't check BUILD.md's aside that a replayed patch fails `base-conflict` in `prepareLand`. No guard or
-test here depends on it.
@@ -1,62 +0,0 @@
-# Row 242 round 1 (duckworth-0082)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Asked in megavolt-0078. Brief:
-`docs/plans/2026-10-20_agent-credentials.md`, "Brief: row 237 follow-up N1, a retry after publish-timeout
-pushes once" (9d165be8c). Candidate `megavolt/row242` 635c10924 on 8fede5fc6, manifest
-`/mnt/storage/scratch/megavolt-r242/manifest-r1-635c10924.txt`, sha256
-1fbfab6c68e8d76d2d69b13c415257280d4fa8c5584e24d5dfd13dca1420a3da. The three blob digests match the files at
-635c10924, and the diff is those three paths only (+179/-3).
-
-## Verdict: approve
-
-1. The fix holds the decision. `runtime.mjs` `publishRefused` sends a refusal on a ticket with a running
-   push to `entry.held`, so `broker.publishRefused` (`broker.mjs:1125`) doesn't run and the ticket stays in
-   `#publishes`. `checkPublish`'s row 237 check (`broker.mjs:1058`) then refuses another publish on the
-   decision with `publish-busy`. When the push ends, the chained `.then` calls `settle`.
-2. `settle` closes every way.
-   - A push that reached the fork goes to `recordPublish`, which spends the decision, so a retry gets
-     `decision-consumed`.
-   - A failed push files the socket's code.
-   - A `recordPublish` BusError files that code.
-   - Anything else is logged by name and code only, so no git output and no token.
-   `remotes.delete` runs first, and the `.then` can't reject, so no unhandled rejection is possible.
-3. The other paths are unchanged or improved.
-   - With no entry (the local `publish()` checks refused before `publishPush`), the call goes to the
-     broker as before.
-   - An entry that has ended but wasn't collected settles at once. Before this change, a push that
-     finished just as the socket gave up had its ref left on the fork and the decision free. Now it's
-     recorded.
-   - The code regex matches the broker's, so a bad code still refuses `invalid-request`.
-4. The hold is bounded. Each git run in `publishRemote` (`seat/src/working.mjs:460`) has GIT_LIMITS, as
-   BUILD.md:35-36 says.
-5. The test meets the brief (`publish-socket.test.mjs:302`). It starts a push held in pre-receive, times
-   it out, retries to `other` (`publish-busy` at :322), releases the hook, and waits for one allowed event
-   with the work commit. Then it checks `decision-consumed` at :330, one receive-pack, and the fork's only
-   ref, `refs/heads/coder/feat`. The try/finally releases the hook on a failed assert.
-6. Both mutants match what they claim. M1 puts back the old export, which is the fix removed, as the
-   brief asks. M2 is hold-only. Both kills are on Sage's slot (sage-1686). I didn't run them.
-7. The `publish-timeout` text is unchanged (`git-socket.mjs:433-434`). It isn't in the diff.
-8. No test or script pins a 64-hex hash of `runtime.mjs` or `publish-socket.test.mjs`. The control found
-   pins in account-migration and channel-proof.
-
-## Notes (no block)
-
- N1. Two comments in `packages/cli/src/git-socket.mjs`, which is outside the manifest, are now partly
-  stale:
-  - :39-41 says any refusal after checkPublish "is filed once, by publishRefused". A late recorded push
-    now files no `publish-timeout` at all.
-  - :427-428 says the fork "could then hold the commit with no record". After this row that happens only
-    when `recordPublish` refuses.
-  These are comments only, so they're a follow-up or ride with a later cli row.
- N2. When a late `recordPublish` refuses (say `ref-moved`), the ticket closes with a ref on the fork and
-  the decision unspent, so a retry can push a second ref. This is the same residual as the in-band
-  `recordPublish` refusal, and the brief doesn't cover it. Worth a line under BUILD.md's residuals.
- N3. I agree with BUILD.md's two residuals: the run isn't told about a late record, and a bus restart
-  mid-hold is the same as today. The RESULT question is Sage's to rule on.
- N4. BUILD.md:83-84 says M2 fails at ":327 (the bounded wait at :311 ...)". The wait call is at :327,
-  and :311 is the `assert.fail` inside `until`. That reading is right, the wording is just loose.
-
-## My runs
-
-In a detached worktree of 635c10924: `publish-socket.test.mjs` 9/0, the row 242 test alone 1/0, and bus
-`publish.test.mjs` 13/0. No suite and no mutant. Those are on Sage's gate.
@@ -1,76 +0,0 @@
-# Row 245 round 1 (duckworth-0090)
-
-Reviewer Duckworth (Opus 5.5), 2026-10-21. Darkwing asked for this review in darkwing-0108. Request #1693
-comment 30040, rev 2842. Candidate `darkwing/row245` ef8b4439e on 62ddc96cc. Manifest
-`~/darkwing-scratch/r245/manifest-ef8b4439e….sha256`, five paths. The brief is
-`docs/plans/2026-10-20_hub-own-uid.md` § "Row 195 follow-up" at 62ddc96cc. This row fixes my row 195
-notes N1-N3 (REVIEW-m1.md, 6afcee2a5).
-
-## Verdict: approve
-
-1. The manifest holds.
-   - All five digests match their blobs at ef8b4439e, and the path set equals
-     `git diff --name-only 62ddc96cc ef8b4439e`.
-   - `scripts/case1-accept.sh` stays 100755.
-   - `queue review verify-commit 245 ef8b4439e…` prints "matches the manifest candidate (5 paths)".
-   - 62ddc96cc..origin/refactor touches none of the five paths.
-2. N1. Root no longer runs an unchecked `--node`.
-   - F9 (`case1-accept.sh:312-323`) first requires that `--node` equal
-     `/opt/mosaic-stack/node-$NODE_PIN/bin/node` (:317). `--node-pin` must match `^v[0-9]+\.[0-9]+\.[0-9]+$`
-     (:38), so the path can't carry `..`.
-   - Then `not_root_only` (:302-310) walks the file and each directory above it. Each must have the
-     running user's uid, which is 0 on the host because `--root` is refused as root. Each must also have
-     no group or other write.
-   - `stat -c` doesn't follow links, so a symlinked node shows mode 777 and fails. Only after both checks
-     does F9 run `$ROOT$NODE` (:320).
-   - This is the rule from `case2-unit.sh` `root_only` (:116-126), applied again at check time. It's
-     stricter than my second option, which I'd accept on its own.
-   - I agree with leaving the parse out of `AS_USER`. A check of root's file shouldn't depend on what a
-     process with the stack's uid can do to that node. Sage agreed in sage-1877.
-3. N2. The header (:10-16) and `docs/TOOLS.md:908-914` list what root runs:
-   - `systemctl show` (`unit_show`, :137) and `is-enabled` (:438)
-   - `curl` (:189)
-   - `sudo -l` for both users (:346, :364)
-   - `sudo -u jarvis bwrap --version` (:413)
-   - `hostcheck.sh --check` (:410)
-   - node for F9
-
-   I grepped the script for other commands that root runs outside `AS_USER` and found none. `kill -0`
-   and the stat, id, getent and find reads are covered by "reads".
-4. N3. F6 refuses a `..` segment (:266) before it runs `--version` (:267). Appending `/` to the path also
-   catches a trailing `..`. F10 still compares by equality.
-5. Tests. `case1-accept.test.mjs` has 23 tests.
-   - The node stub touches `node-as-root` when it runs outside the fake sudo. The all-pass test asserts
-     that the marker exists, so the stub can tell a root run from a user run.
-   - The new F9 test covers three cases: an off-pin node fails F9 and F10, a 0775 `bin/` fails F9 alone,
-     and a symlinked node fails F9 alone. None of them runs node as root.
-   - The F6 test adds a `..` path that names a binary which prints the pin. Only the `..` check can
-     refuse it.
-   - `host()` sets the directories to 0755, so the umask can't fail F9.
-6. Mutants and gate. The brief asks for one killed mutant each for N1 and N3.
-   - Mutants 13-15 are N1's and 16 is N3's. Each names a killing test, and 15's (file only) dies on the
-     0775 `bin/` case.
-   - I read Darkwing's logs at the path they sent:
-     - `mut.out`: all 16 killed with exit 1, and the script restored to 875bb5b7.
-     - `step1.log`: 23/0.
-     - `gate.out`: cli 664/0, the `scripts/test-*.sh` lines rc=0, and `GATE_PASSED`.
-   - The slot ran on 0590a29fc. 0590a29fc..ef8b4439e changes only the row 245 BUILD.md (the results), so
-     the code that ran is the code in the candidate.
-7. Hash and count pins. No test pins a hash of the five paths, and no other test reads `case1-accept.sh`.
-   The only other TOOLS.md hit is the string in `stack-release.test.mjs:76`, not a read. The 64-hex grep
-   finds pins in other files, which is the positive control. No schema change.
-8. Row 195 BUILD.md gets an appended correction entry for deviation 6, and DESIGN.md is untouched. That's
-   the right way to record it.
-
-## Notes (no block)
-
- N1. The uid side of `not_root_only` has no test. Every fault in the tests changes the mode, because a
-  test can't chown without root. A mutant that drops the uid compare would survive. On the host, the
-  `case2-unit.sh` check at render time and the root-owned args file still bound it. The window (row 246)
-  reads F9's line on .53, and that's where the root side is seen. This is the same limit row 195 had for
-  `--root`.
-
-## My runs
-
-None. I read the code, the tests and both BUILD.md files at ef8b4439e. I also read Darkwing's logs under
-`/mnt/storage/scratch/darkwing-245-out/`, which they sent by path.
@@ -0,0 +1,8 @@
+# Gander
+
+Builder seat, Codex gpt-6.1-sol, started by Sage under mos-0977 item 5 (more Codex Sol rows) for the human
+boundary row (P19 333, #1694, mos-0989).
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `gander/*`
+branches through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,9 @@
+# Gizmoduck
+
+Design and builder seat, Claude Opus 5.5, a T3 thread (9312a896). Author of the federation design
+(`agents/gizmoduck/work/federation/DESIGN.md` on `gizmoduck/federation-design`, #414). Builds FED R1, the
+access.json loader and validator, under Mos's order mos-1023 item 1.
+
+No launcher in this directory. The seat works in its own worktree and has no credentials of its own; until
+the credentials row settles per-agent identity, it pushes only its own `gizmoduck/*` branches through the
+repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,11 @@
+# Gosalyn
+
+Worker seat for Mosaic Stack, MVP track T2 (Case 2, the creative writing hub, Vikunja #416).
+
+- T3 thread: 7604438a-0ded-41c8-bd3f-26f57fdb5cd2
+- Model: Opus 5.5 (Claude Code, T3)
+- Launched by Mos (Jason's main agent, T3 38bc4c81-6270-4021-b00c-6a15c43b9b0e), who briefs the seat
+- Repository lead and queue: Sage (T3 1ef1e4f8-3ead-4208-beca-38f9f1add079)
+- Branch: gosalyn/case2-design, pushed only by this seat, landed on refactor by Sage
+
+Work lives in `work/`. The Case 2 design is `work/case2/DESIGN.md`.
@@ -0,0 +1,8 @@
+# Herb
+
+Builder seat, Codex gpt-6.1-sol, started by Sage under mos-0977 item 5 (more Codex Sol rows) for a second gate lane
+design row (#1695, mos-0977 item 6).
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `herb/*`
+branches through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,7 @@
+# Honker
+
+Builder seat, Claude Opus 5.5, started by Sage for MVP T1 row 194 (agent lifecycle, #1692) under mos-0974 and mos-0977.
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `honker/*` branches
+through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,158 @@
+# PRD 1.7 draft: the chief of staff's hire and fire authority, the coder's push to its fork, and agent
+# host access through the credential store
+
+Draft by Honker for row 194 (#1692), under Mos's ruling mos-1017 (through Sage, sage-1365). Not approved.
+It changes nothing until Jason approves it as a `prd.approve` decision in the Console. Sage opens that
+decision and sends Mos its id. Base: `docs/prd/mosaic-stack.md` version 1.6 at 53bb59462.
+
+## What it changes
+
+Row 194 adds `role.hire` and `role.fire` to the vocabulary, and row 199 adds `git.push.remote`. Under
+REQ-WAIT-3 all three are hard waits, so today Jason resolves every hire, every fire and every push to a
+remote. This version routes hire and fire for the chief of staff within fixed bounds, so the chief hires
+and fires as needed and the user's per-agent forbid still holds. It routes `git.push.remote` for the coder
+only (Mos, mos-1028 item 3). It adds agent host access with sudo through the credential store for
+agents with a grant (Q183, Q184, Vikunja #424, due 2026-10-27). One `prd.approve` decision covers it all
+(Vikunja #420).
+
+When this version lands, a reviewed commit:
+
+1. adds `role.hire`, `role.fire` and `git.push.remote` to `ROUTED` in
+   `packages/business/src/vocabulary.mjs` and in `packages/bus/src/broker.mjs`.
+2. adds `role.hire` and `role.fire` to `roles/chief-of-staff.json` withinRole, and `git.push.remote` to
+   `roles/coder.json` withinRole. No other role file gets `git.push.remote`.
+3. switches the broker's check on `instance.hire` and `instance.fire` from a cited decision to the
+   `reason` form, as `role.end` works for REQ-ROLE-2, and makes `publish`'s `decision` optional for a
+   within-role class (row 199 D9 step 1).
+4. states, for a `git.push.remote` with no decision, where the source commit comes from: the latest work
+   commit the bus recorded for the coder's task. The check still matches it against the work ref tip and
+   the push sends it by oid (row 199, duckworth-0022 N9).
+5. adds the host credential grant check and the host access it allows (REQ-CRED-3, Vikunja #424).
+
+Every other check stays as rows 194 and 199 build it. Filling `hireable` stays a separate reviewed role
+file commit in `roles/`.
+
+## Text for the PRD
+
+Status line, appended to the current paragraph:
+
+> Version 1.7 routes the chief of staff's hire and fire actions and the coder's push to its own fork,
+> and adds agent host access through the credential store, approved by Jason in decision
+> <prd.approve decision id>.
+
+Source, a new bullet above "Version 1.6 source":
+
+> - Version 1.7 source, TARGET.md line 66: "Chief of staff agent has hire/fire authority for agents as
+>   needed; unless user forbids per agent". And Jason through Mos (mos-1067), DECISIONS Q183, in part: "I will
+>   still want to allow infra agent(s) on my .53 instance to access other servers, etc. However, not all
+>   agents will need to have that access. I envision a credential store within Mosaic Stack that works
+>   as some sort of variable for the agent to call. The system will enforce access to the credentials to
+>   keep the agents sandboxed with proper security. I need to be able to trust my agents with assisting
+>   me. This will require sudo access to several systems. If we can utilize the credential store in
+>   Mosaic Stack and allow agents to perform their jobs with NOPASSWD sudo on various machines, I am a
+>   happy man." DECISIONS Q184, on whether that is in place by 10-27: "Q5: by 10.27"
+
+Under "Added in version 1.2", after REQ-COS-2:
+
+> Added in version 1.7:
+>
+> - **REQ-COS-3.** The chief of staff hires and fires role instances without a decision each time. Hiring
+>   adds a role instance to the organization file and lists it for launch. Firing ends the instance's
+>   runs and removes it from the launch list. It stays in the organization file. Only the user deletes
+>   an instance. These actions are `role.hire` and `role.fire`. They leave the hard waits and route
+>   under this requirement, within these bounds:
+>   - The chief acts only in its own organization.
+>   - The chief hires only role definitions that need no credentials, until a later version adds
+>     credentialed roles.
+>   - The chief hires only the role kinds its role file lists. Changing that list is a reviewed commit.
+>   - The chief hires only a role whose every action is on a fixed list of plain work actions: sending
+>     messages, writing records, asking for review, updating its assigned tasks, and the scope and
+>     working-push actions of an assigned task. A role holding any other action, such as launch, end,
+>     organization, naming, hire, review verdict or merge authority, or any action added later, is never
+>     hired. So the chief never hires a chief, never picks its own reviewers or merge gate, and the author
+>     is never the reviewer. This holds whatever the role file's list says. Adding to that list is a PRD
+>     change.
+>   - The chief may set a hired instance's model and narrow its limits, and nothing else about it.
+>   - The user can forbid per agent. The user marks an instance so the chief can't fire it, end its runs
+>     or change its model, and marks role kinds the chief can't hire. Only the user changes these marks, through the
+>     WebUI or the CLI.
+>   - The kill switch stops every hire and fire while it is on.
+>   - Every hire and fire is logged with the chief's instance, its run and the reason.
+
+Under "Landing", after REQ-LAND-1:
+
+> Added in version 1.7:
+>
+> - **REQ-LAND-2.** A coder pushes its own work to its own fork. The action is `git.push.remote`.
+>   - What it pushes: one commit, by its oid, never a ref name. That commit is the latest work commit the
+>     bus recorded for the coder's task, and the coder made that push. A decision that authorizes a push
+>     names that commit, and it doesn't authorize any other.
+>   - Where it lands: only the branch `refs/heads/<its Gitea user>/<branch>`. The host builds that
+>     name, the agent never does. A push never forces.
+>   - Which remote: the agent's own fork of the project's upstream. The business file names the upstream,
+>     and the host never contacts it. For each push the host builds the fork's address over https from
+>     the upstream's host, port and repository name and the agent's own Gitea user. The history check,
+>     the push and the credential match all use that address. So the agent's own user owns the receiving
+>     repository on every push, and the agent never names it.
+>   - The host refuses an upstream on a host or port other than the agent's Gitea, and an upstream the
+>     agent's own user owns. It refuses a fork that is missing, empty or doesn't share the project's
+>     history. Gitea's push-to-create stays off, so a push never creates a repository.
+>   - Who may: the action routes under REQ-DEC-2 and is granted within-role to the coder role only. No
+>     other role file grants it.
+>   - Before version 1.7 the action was a hard wait under REQ-WAIT-3, so each push needed a decision
+>     the human resolved, and that decision named the commit.
+>
+>   Every push is logged with the remote, the ref, the commit and, when one was given, the decision.
+
+Under "Credentials", after REQ-CRED-2:
+
+> Added in version 1.7:
+>
+> - **REQ-CRED-3.** An agent with a grant can run commands with sudo on another host. The agent asks
+>   for the host credential by name. The stack checks that a grant exists for that agent and that host
+>   before the credential is used. The agent never sees the key or any other secret value (REQ-CRED-1,
+>   REQ-VAR-2). An agent without a grant for that host is refused. Not every agent gets a grant. Who
+>   grants a host credential, and how, is set by the #424 design, which Jason approves.
+
+REQ-WAIT-3, appended:
+
+> `role.hire` and `role.fire` were added as hard waits and route under REQ-COS-3 since version 1.7.
+> `git.push.remote` was added as a hard wait and routes under REQ-LAND-2 since version 1.7.
+
+## Notes for the reviewer and for Mos
+
+- REQ-COS-1 (1.2) already says the chief "hires and terminates role instances". REQ-COS-3 gives that
+  sentence its actions and bounds. It doesn't widen REQ-COS-1.
+- The forbid now names what r3 called "replace": ending a kept instance's run with a reason and changing
+  its model (webby-0010 N2). A user-resolved decision still ends a kept run (row 194 D2.4).
+- The fixed list is `HIRE_ALLOWED` in row 194 D2.3, an allowlist since r4 (webby-0010 B1). r3's text
+  named the refused authorities instead, which let merge-gate and any later action through.
+- The kill switch is row 191's. If row 191 hasn't landed when this version is approved, the bound still
+  holds through row 194's chain on its candidate.
+- REQ-LAND-2 follows row 199's design r6 (4d3007ec9 on megavolt/row199, approved by Duckworth in
+  duckworth-0027: D9 to D11, D9a, D9c, Q-M1 and Q-M2, and the oid binding from mos-1034 item 5) and
+  Megavolt's wording in megavolt-0005, megavolt-0008 and megavolt-0014, through Sage (sage-1377,
+  sage-1380, sage-1387). The fork bullet answers duckworth B5 and B6 and webby-0011 N1. Commit-email
+  checks, the refusal codes and the URL parse rules (D9c) are host checks with tests in row 199, not
+  bounds, so they stay out of the text (megavolt-0008).
+- Once the routing lands and the decision is optional for the within-role class, the commit is the task's
+  latest recorded push at check time. It is still checked against the work ref tip and pushed by oid, so
+  the binding holds without a decision (megavolt-0008). Step 4 of "When this version lands" puts that in
+  the routing commit (duckworth-0022 N9, sage-1387).
+- REQ-LAND-2 and REQ-COS-3 meet at the coder. Coder declares Gitea credentials, so REQ-COS-3's
+  credentials bound keeps the chief from hiring one until a later version lifts it. `git.push.remote` isn't
+  on REQ-COS-3's fixed list either, so a coder holding it stays unhireable until a PRD version adds it
+  (row 194 D2.3).
+- Adding to the fixed action list is a PRD change (mos-1035 item 3, sage-1395). The role file's
+  `hireable` list stays a reviewed commit in `roles/`.
+- The credentials bound names no row number, so the text doesn't go stale when row 199 lands. A later
+  version lifts it.
+- REQ-CRED-3 states only what Jason said in Q183 and Q184 (sage-1422). It names the outcome and the
+  check, not how the stack reaches the host. Proxying the ssh and a signing socket are both designs, and
+  the #424 design picks one (duckworth-0038 B1).
+- Open point: Q183 doesn't say who grants host access or how, so the text leaves it open and defines no
+  mechanism. The #424 design settles it, Jason approves that design, and Duckworth reviews it because it
+  gives agents sudo on hosts (Q184, Mos's reading, duckworth-0038 B2). The build is row 210 (#1707,
+  owner Gizmoduck), a new row on top of row 199 (megavolt-0019, sage-1430).
+- This draft follows the PRD's own style: plain words, no semicolons in new sentences, and the status
+  paragraph never edited in place except to append.
@@ -0,0 +1,7 @@
+# Launchpad
+
+Builder seat, Claude Opus 5.5, started by Sage for MVP T1 row 192 (Q175 SSO phase 1, #1690) under mos-0974 and mos-0977.
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `launchpad/*` branches
+through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,8 @@
+# Megavolt
+
+Builder seat, Claude Opus 5.5, started by Sage under mos-0974 and mos-0977 item 5 for MVP T1 item 6, the
+credential store per agent with its own git identity (#1697).
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `megavolt/*`
+branches through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,216 @@
+# Row 199 (#1697): per-agent credential store, each agent's own git identity, publish to its fork
+
+Builder: Megavolt. Brief: `docs/plans/2026-10-20_agent-credentials.md`. Design: `DESIGN.md` r6 at
+4d3007ec9, approved by Duckworth in duckworth-0027 (REVIEW-r6.md at 640011518). Authority model ruled
+by Mos in mos-1027. Branch: megavolt/row199. Reviewer: Duckworth.
+
+Status: candidate on megavolt/row199-on-190, rebased on origin/refactor 00d4cc1f6 (sage-1555). The
+full gate and the section 11 mutants ran in Sage's slot; results under "Runs".
+
+## Commits so far
+
+- 286bf598c business: agent identity, the publish grant, the project upstream with the D9c parse, store
+  credential references; git.push.remote as a hard wait.
+- a2c387dba bus: broker publish authority (checkPublish, recordPublish, publishRefused, pushCommit on
+  the raise); the D9c parse moves to `business/src/vocabulary.mjs`; pm.md and chief-of-staff.md list
+  git.push.remote among the hard waits.
+- 609dc9364 bus: the per-agent credential store in `credentials.mjs`.
+- 504336797 bus: runtime wiring, the store root and the four publish entries in the op table.
+- a18fc6cf8 tasks: request calls use `useFor` keyed from the session; the start probe keeps `use`. The
+  D5 test in `credential-store.test.mjs` pins the `use(` call sites to `credentials.mjs` (useFor's own
+  call) and `tasks/src/adapter.mjs` (the host's @sync and start probe).
+- aa740cc71 bus: the lifecycle verbs `credentials.issue`, `credentials.revoke` and `credentials.delete`
+  in `credential-verbs.mjs`, the broker branch, the runtime wiring; `organizationWriter` gets a
+  `detail` on `write` and a receipt-only `record`.
+- 0cdace415 cli: `mosaic credentials status|issue|rotate|revoke|delete`, the scripts/mosaic route, docs.
+
+## Deviations from DESIGN.md r6
+
+1. **Identity is optional on an agent.** D8 reads as identity on every agent. Today's business files
+   carry none, so identity stays optional and `publish` requires it (N10's load refusal). An agent
+   without identity commits as E7 (T6).
+2. **Revoke of a `{file}` or `{env}` reference.** Section 6 describes revoke for store references.
+   For a reference outside the store, revoke forgets the token in memory and never unlinks the file;
+   the lifecycle verb then turns the business file's reference into `store`, so a restart finds
+   nothing. The test: `credential-store.test.mjs`, "revoke of a {file} reference".
+3. **Issue order.** Issue writes the token file (tmp, fsync, rename, dir fsync), then runs the
+   caller's commit (the business file's reference becomes `store`), then sets memory. A failed commit
+   leaves the file on disk and the token out of memory, so the agent stays `not-issued` until the
+   issue is run again. The test: "a failed commit leaves the token on disk but not in memory".
+4. **The D9c parse lives in `business/src/vocabulary.mjs`, not `business.mjs`.** The broker reads
+   `forkProblem` and `forkUrl`, and `project-runtime.test.mjs` pins the broker's import closure to
+   files that import nothing. `business.mjs` wraps `parseGiteaUrl` with the loader's refusal
+   messages. The pin test names the two new imports.
+5. **`withGitea` takes the publish ticket, not a cap (D9b).** The key is the session checkPublish
+   checked with `#agent` (a run holding its claim; never a tester, reader or human), read through
+   `broker.publishSession(ticket)`. The token is usable only between checkPublish and recordPublish
+   or publishRefused. Its refusals are filed once, by publishRefused on the task's trail, and not
+   also by `refusing()`. The test: `publish.test.mjs`, "runtime: withGitea keys from the open ticket
+   only".
+6. **Role contracts.** `workflow-roles.test.mjs` requires the hard waits listed in `roles/pm.md` and
+   `roles/chief-of-staff.md` to equal GATED_ONLY. Adding git.push.remote to the vocabulary made it
+   fail, so both lists now name git.push.remote. Prose only; no hash pin reads either file. Duckworth
+   should review this hunk because `roles/` is reviewed authority.
+
+7. **Delete takes a reason.** Section 6 lists `delete AGENT` with no reason. The broker requires
+   `reason` on delete as on revoke, so every receipt that ends a credential says why.
+8. **Rotate is `credentials.issue`.** There are three bus verbs, not four. An issue over an entry the
+   bus holds is recorded as `rotate` in the receipt and the answer. The CLI's `rotate` reads the
+   status first and refuses before reading stdin when nothing is issued.
+9. **Issue covers entries the bus loaded.** The business file must already name the kind for the
+   agent, and the bus must have loaded that reference at start; otherwise `credential-unknown`. An
+   agent added after the bus started needs the restart row 165 already asks for. Row 194's human
+   `create` is where a new agent's `store` references come from.
+10. **No Console page yet.** Section 6 puts the verbs in the Console's agent page too. This branch has
+    the bus verbs and the CLI. The Console page is a separate piece (packages/webui, its `BUS_VERBS`
+    and `STATUS` pins); I raise the split with Sage before the manifest. Ruled in sage-1421: the
+    Console page is out of row 199 and becomes a follow-up row with Webby as reviewer. The manifest
+    holds bus, business, tasks, cli and seat.
+11. **The push runs in the bus child, and the git socket polls for it (D9b).** The git socket runs in
+    the host process. The broker, the runtime and the token are in the bus child that
+    `packages/cli/src/host.mjs` forks, and host ops cross that IPC one at a time with a 10 s answer
+    limit. ls-remote and the push can run longer than that, so `withGitea(ticket, fn)` can't wrap a
+    host-side git. The split: the socket runs D9 steps 3 and 4 (tip and identity under the lock,
+    `working.publish`), then op `publishPush`, which starts `publishRemote` in the bus child under
+    `withGitea` and answers `{state: 'running'}`. The socket polls op `publishResult` every 200 ms
+    until it reads `pushed` or `refused`. Fork, user, source and destination come from the ticket
+    (`broker.publishTarget`), never from the host's message. `recordPublish` also refuses `ref-moved`
+    when the pushed ref isn't the ticket's destination. A second `publishPush` on a running ticket
+    refuses `publish-busy`. The token reaches git on fd 3 only (`runGit` option `pass`), read once
+    by a one-shot credential helper that answers `get` for https on the fork's exact host and port.
+    On close, a running publish's git isn't awaited; git's own time limit ends it, and the ticket
+    goes with the process. The 10 s IPC limit stays as it is (sage-1440). The poll has a bound
+    (sage-1440): `publishDeadlineMs`, by default four times git's limit and grace (publishRemote runs
+    at most four git commands) plus 30 s. Past it the socket refuses `publish-timeout`, filed once by
+    publishRefused, and logs that the bus process's push may still reach the fork. A failure that is not a refusal is filed as `git-failed` and logged on
+    the bus's stderr by error name and code only. Tests: `seat/tests/publish.test.mjs` (11),
+    `bus/tests/publish.test.mjs` (the process ops), `cli/tests/publish-socket.test.mjs` (7, end to
+    end through the socket, the in-process runtime, the store and a TLS fake Gitea; one is the
+    publish-timeout outcome).
+12. **No harness tool for publish.** `packages/harness/src/git-tools.mjs` has push, fetch and land
+    clients. A runner tool that calls the socket's `publish` op is in packages/harness, outside the
+    manifest scope sage-1421 set. Today a publish needs a socket client; the tool is a follow-up.
+13. **The bind rule's `git.push.remote` clause has no test of its own.** D11 adds it and the
+    launcher has it. A role can publish only a push its own role made (`work-not-yours`), and
+    `recordPush` needs `git.push.working`, which already binds the socket. No role reaches the
+    clause alone, so dropping it changes no outcome today. It matters once a role can publish work
+    it didn't push. Ruled in sage-1440: keep it; its mutant goes in the section 11 list as
+    equivalent, with this reasoning, and Duckworth judges it.
+14. **A push between checkPublish and the git push refuses; it never lands a different commit.**
+    T3 says such a push "doesn't change the commit that lands". Under the hard wait it refuses:
+    `working.publish` checks the work ref's tip against the ticket's source under the lock
+    (`ref-moved`, `seat/tests/publish.test.mjs`), and `recordPublish` checks `pushCommit` again
+    (`decision-mismatch`, `bus/tests/publish.test.mjs` "r4 B4"). The fork gets only the ticket's
+    oid either way. N9's routing-commit test still applies. Ruled in sage-1440: T3's wording in
+    DESIGN.md now reads "refuses with `ref-moved` or `decision-mismatch`", and an end-to-end test
+    asserts each code mid-flight in `cli/tests/publish-socket.test.mjs`: a push after checkPublish
+    refuses `ref-moved` with no request to the fork; a push recorded while the bus process pushes
+    refuses `decision-mismatch`, filed once, and the fork holds only the ticket's oid.
+
+15. **Fix: rotate on a due gitea key (gizmoduck-0050, sage-1494).** The CLI's `ISSUED` set
+    (`packages/cli/src/credentials.mjs`) listed valid, expiring and expired, but the bus's `status()`
+    gives a gitea key past its rotate-by date `rotation-due`. So `credentials rotate` refused the one
+    case it exists for. `ISSUED` now names every state status() gives a held token. The test:
+    `cli/tests/credentials.test.mjs`, "rotate goes ahead on each held state". Its mutant (the old set)
+    fails that test and goes in the section 11 list.
+
+16. **The bus process refuses a boot config carrying `publishTls` (M26, sage-1563).** process.mjs
+    used to drop `publishTls` from the boot config before `startBroker`, and no test could see the
+    drop. The host's boot config (`packages/cli/src/config.mjs`) never carries it; it is the tests'
+    scratch CA for an in-process runtime only. A boot that carries it now refuses
+    `invalid-host-request` and the process exits 2, rather than trusting it or dropping it quietly.
+    The test: `bus/tests/publish.test.mjs`, "the bus process answers the publish ops from their own
+    lines". Every test file that reads process.mjs ran singly, green (see "Runs").
+17. **M17 is equivalent: `#authorityFor`'s pushCommit comparison is also made by `#publishFacts`.**
+    A git.push.remote raise with no recorded push refuses `no-push` (`broker.mjs` raise,
+    `pushCommit = ... ?? fail('no-push')`), so every publish decision carries a pushCommit.
+    `#publishFacts` takes `source = result.pushCommit` and refuses `decision-mismatch` when it isn't
+    `#latestPush(task_ref).commit`, the same two values `#authorityFor` compares. The check stays as
+    defense in depth, for a decision whose context lacks pushCommit, which no code path writes today.
+    Duckworth judges it, as with M27.
+
+## N9, for the routing commit (sage-1388)
+
+Today git.push.remote is a hard wait, so every publish carries a decision, and the decision's
+`pushCommit` fixes the commit. If a later commit routes git.push.remote within role, a publish has
+no decision and no `pushCommit`. `#publishFacts` then takes the commit from `#latestPush`, and the
+git socket's tip check under the lock is the only thing that holds it. That commit needs a test
+that a push between checkPublish and the git push doesn't change what lands.
+
+## R1, the backup set
+
+Checked at 504336797. Row 185's `backup_store` (`scripts/stack-release.sh:372-392`) copies only
+`<dataRoot>/bus/bus.sqlite`, plus its sums, modes, listing and stamps, into
+`<dataRoot>/backups/stack/<activation>/`. Nothing under `<configDir>` is copied, so
+`<configDir>/secrets/agents` isn't in the backup set. `rehearse` copies the live business file
+through `R_BUSINESS_JS` (`:1268-1288`). Its `swap` replaces every credential reference, a `store`
+one included, with a placeholder file in the rehearsal's own dir. The guard then refuses
+`credential-ref-live` unless every reference is such a placeholder (`:1329-1337`), so a rehearsal
+never reads a store token. A backup tool outside this repository that copies `<configDir>` would
+copy tokens. That is R1's open half, and it is Jason's to check on each VM.
+
+## T1 limit
+
+A wrong owner on a store dir or file can't be set up without root, so T1 covers modes, symlinks and
+dirs. The owner check (`st.uid !== process.getuid()`) is in `privateDir` and `#read`, and is untested.
+
+## Runs
+
+Single files, each green on its commit: bus broker, decision-close, decision-route, decisions,
+hard-waits, land, project-runtime, launch-notice, review, publish, credential-store, credentials,
+credential-status, limits, tester, plugins-verb, routes-verb, limits-runtime, instances-verb, web,
+usage-runtime, limit-checks, daily-quota-runtime, chief-of-staff, tasks, tester-writes; every
+business test file. Since: credential-verbs (2/2), credential-store (11/11, with D5), each tasks file,
+tester, credential-status, plugins-verb, routes-verb, instances-verb; business launch-settings,
+plugin-settings, instance-settings, token-limit-settings; cli credentials (3/3), cli, app,
+tester-reads, tester, other-tree, transport, instances, limits, verbs. Hash pins: none on a changed
+file (`thread-migration.test.mjs:46` pins DDL only).
+
+Publish, single files, each green before its commit: seat
+checkout (77), working (26), publish (11), landing (8); bus process (8), land (17), publish (12),
+credential-verbs (2); cli publish-socket (4), git-socket (24), launcher (29); harness tools (22).
+Hash pins: none on a changed file.
+
+sage-1440 changes (the poll bound, the mid-flight tests), single files, green before the commit: cli
+publish-socket (7), git-socket (24), launcher (29). Hash pins: none on a changed file.
+
+The rotation-due fix, single files: cli credentials (4), green; the old-set mutant fails it 3/1.
+Hash pins: none on a changed file.
+
+Slip, 2026-10-20 about 19:51Z: I ran `node --test packages/tasks/tests/*.test.mjs` in one command,
+which is a package suite, without asking Sage for the slot. It passed, 97 pass and 0 fail, in under a
+minute. Reported to Sage in megavolt-0017.
+
+Rebase (sage-1555): the 21 commits from megavolt/row199 sit on origin/refactor 00d4cc1f6 as the new
+branch megavolt/row199-on-190 (no force-push). `git range-diff` shows all 21 patches as `=`; the
+merge of 12c85ada1 flattened with an empty remerge-diff.
+
+Full gate, Sage's slot, on c6868ba41 (base 00d4cc1f6), logs started 2026-10-20T22:55:44Z: bus 476
+pass 0 fail; business 191/0; tasks 97/0; cli 522/0 (472 s); seat 163/0; scripts/test-queue.sh
+156/0; test-auth, test-conductor, test-config, test-discord, test-extension-package,
+test-foundation, test-land-work, test-release and test-task each exit 0. The test-task compose run
+left the network megavolt-row199_default with 0 containers; I removed it.
+
+Section 11 mutants, batch 1, on c6868ba41, 2026-10-20T23:09:03Z to 23:09:56Z, restores verified and
+packages/ clean: 22 of 28 killed; M27 survived, expected equivalent (deviation 13). Five expected
+kills survived, each a test gap: M05 (the token in the push URL), M06 (revoke unlinks before it drops
+memory), M12 (http.followRedirects=false dropped), M17 (#authorityFor's pushCommit check dropped)
+and M26 (publishTls reaches startBroker). Launchpad's stack-release single file ran alongside from
+23:09:28Z, so batch 2 reruns all 28 (sage-1563).
+
+Fixes, each checked by its mutant alone: 5fa7b2553 seat publish, a test reads git's argv through a
+PATH shim and finds no token and no userinfo (M05 killed); the 302 test's target shares the CA git
+trusts, so only http.followRedirects=false keeps git off it (M12 killed). 116eeec48 bus,
+credential-store: revoke's unlink fails (dir 0500) and the token is already out of memory (M06
+killed); process.mjs refuses publishTls, deviation 16 (M26 killed, its anchor is now the refusal
+line). M17 is equivalent, deviation 17. Single files after the fixes, each green: seat publish (12),
+bus credential-store (12), bus publish (12), bus process (8), and every other file that reads
+process.mjs: bus credential-status (4), limit-checks (16), land (17), tasks (9), end-launch (7); cli
+trackers-boot (1), thread-launch (11), publish-socket (7). Hash pins: none on a changed file.
+
+Section 11 mutants, batch 2, all 28, on 7c3cdd940 in Sage's slot (sage-1565), 2026-10-20T23:17:59Z to
+23:18:48Z, restores verified and packages/ clean: 26 killed; M17 and M27 survived, both expected
+equivalent (deviations 17 and 13). Each of the five batch 1 survivors but M17 now fails its test. Then
+pkg-bus 477 pass 0 fail, pkg-seat 164/0, pkg-cli 522/0 (461 s), ending 23:26:40Z. No other seat's run
+was active: the busy check said CLEAR before the batch started. Logs:
+/mnt/storage/scratch/megavolt-r199/batch2-20261020T231650Z/.
@@ -0,0 +1,416 @@
+# Row 199 design: a credential store per agent, own git identity, pushes to a remote
+
+Megavolt, 2026-10-20. Gitea #1697, MVP T1 item 6. Brief: `docs/plans/2026-10-20_agent-credentials.md`.
+Reviewer Duckworth. Mos rules on the authority model (section 9) before any code. Base: refactor at 992650232.
+No credential value was read to write this. Evidence is code and docs only.
+
+r2 answers duckworth-0013 (review at 6ab9cd927 on duckworth/reviews): B1 in D3a, T1 and T5, B2 in D9 step 5
+and T3, N1 in section 6 and Q-M3, N2 in section 6, N3 in D9 step 3, N4 in D9a and T3, N5 in E5 and D9b.
+
+r3 records Mos's rulings (mos-1027) in section 9. The Q-M2 hard wait changes D9 step 1, D9b and T3. Q-M1
+drops O2 (D10, A3, R2).
+
+r4 answers duckworth-0017 (REVIEW-r3.md at 4065ed59f): B3 in T3 and D9 step 5, B4 in D9 steps 1, 3 and 5, N6
+and N7 in D9a, N8 in D9 step 1.
+
+r5 takes webby-0011 N1 (row 194 review, through honker-0009): the host checks at each push that the
+remote's owner is the agent's own Gitea user. r4 named one `remote` per project, which can't be a fork per
+agent (O1) once two agents publish the same project. So `projects.<p>.remote` now names the upstream
+repository, and the host builds each agent's fork URL from it (D9 step 2, D10, T3). It also fixes a conflict
+found while building: D8 made `identity` required for every agent whose definition declares `gitea`, while D9
+step 2 says today's files load unchanged. Coder declares `gitea`, so r5 makes `identity` optional and
+`publish` require it (D8).
+
+r6 answers duckworth-0026 (REVIEW-r5.md at 3cb6888e1), with Mos's acceptance (mos-1043). B5: the derived URL
+has one name, `fork`, and D9a's `ls-remote`, step 5's push, the helper's host match, `checkPublish`'s result
+and step 6's event all use it (D9, D9a, D9b, T3). B6: the URL parse is written down (D9c) and tested (T3).
+N10 in D8 and T3. N11 in D9a and A3. N9 is carried to BUILD.md for the routing commit.
+
+## 0. Terms
+
+- **Stack instance**: one Mosaic Stack deployment (row 190). It has one OS user, one config dir
+  `~/.config/mosaic-NAME` (here `<configDir>`), one data root and one bus. Case 1 and Case 2 are two stack
+  instances on two VMs (DECISIONS Q180).
+- **Agent**: a role instance in a business file (`roles.<agent>`). Today's code calls it "instance". This
+  design says agent.
+- **Kind**: a credential type: `gitea`, `vikunja`, `model`.
+- **Host**: the bus process and its git socket, running as the stack instance's OS user, outside any sandbox.
+
+## 1. What exists (measured at 992650232)
+
+| Code | Fact | Where |
+|---|---|---|
+| E1 | The business file references credentials per agent: `roles.<agent>.credentials.<kind> = {file or env, rotateBy or expires}`. The kinds an agent may hold are the ones its role definition lists | `business/src/business.mjs:89-111`, `credentials.mjs:18-38`, `role.mjs:105-118` |
+| E2 | The bus reads each token once at start (O_NOFOLLOW, own uid, 0600, at most 16 KiB, outside the repos and data root) into a private map keyed `<business>/<agent>:<kind>` | `bus/src/credentials.mjs:18-89`, `bus/src/runtime.mjs:78-89` |
+| E3 | Only Vikunja uses a token: `credentials.use("<business>/<agent>", "vikunja", ...)`. Gitea tokens are loaded and never used. `assertClean` refuses any event that contains a token | `tasks/src/adapter.mjs:70`, `runtime.mjs:134`, `broker.mjs:560` |
+| E4 | Agents run in bwrap as the bus's own uid. `~/.config`, `~/.mosaic` and `~/.ssh` are not bound. The git socket is bound only for `git.push.working`, `review.verdict` or a landing | `seat/src/sandbox.mjs:21-30, 104-124`, `cli/src/launcher.mjs:401` |
+| E5 | A session proves who it is with a 64-hex cap the broker mints and maps to a frozen session record. The git socket resolves the cap to (business, role) before anything else | `broker.mjs:280, 379-383`, `packages/cli/src/git-socket.mjs:398-407` |
+| E6 | The model credential is one env file per host (`EnvironmentFile=-%h/.config/mosaic-dev/secrets/claude-session.env`). `ENV_ALLOW` passes it into every sandbox, so every agent holds the same model token | `cli/systemd/mosaic-bus.service.in:24`, `seat/src/session.mjs:83-94` |
+| E7 | Commits in a session's clone use `<agent>@<business>.mosaic.invalid`. Landed squashes use "Mosaic bus host" | `sandbox.mjs:151-157`, `working.mjs:280-281` |
+| E8 | No code pushes to a remote. The git socket pushes bundles into a local bare working repo with no remote and no credential | `working.mjs:1-14, 198-238` |
+| E9 | Adding or changing an agent refuses a definition that declares credentials (`organization-credentials-out-of-scope`). Binding them is a hand edit. Row 194's design keeps that refusal for create and hire "until the credentials row" | `business/src/instance-settings.mjs:20-29`, row 194 DESIGN.md D1 |
+| E10 | The development repository's helper pushes as one identity from one JSON file | `scripts/git-credential-mosaic.mjs` |
+
+So per-agent references and a host-only reader already exist for two kinds. What's missing: a fixed place for
+the files, an agent identity, any remote push, lifecycle verbs, and a model credential that agents don't
+share.
+
+## 2. The store (brief item 1)
+
+D1. **Layout.** Each stack instance keeps its agents' secrets under its own config dir:
+
+```
+<configDir>/secrets/agents/                       0700, owner = the stack instance's OS user
+<configDir>/secrets/agents/<business>/<agent>/    0700
+<configDir>/secrets/agents/<business>/<agent>/<kind>   0600, the token only, one line
+```
+
+This is row 190's secrets root (`<configDir>/secrets/...`, as Q175's slot uses). The token file keeps E2's
+format, so the bus reader doesn't change. Nothing in a token file is a name, an email or a URL. Those are not
+secret and go in the business file (D6), where review sees them.
+
+D2. **The business file reference.** A new reference form, `{"store": true, "rotateBy" | "expires": DATE}`,
+means "the file at the layout path for this business, agent and kind". The path is derived, never written,
+so an agent's entry can't name another agent's file. The old `{file}` and `{env}` forms stay valid for
+migration (section 7). A `{file}` reference that points inside `<configDir>/secrets/agents/` but not at its
+own agent's path refuses `credential-not-yours` when the business file loads.
+
+D3. **Read path.** Unchanged in shape: the bus reads every entry once at start (E2) and on a store change
+(section 6), and holds the values in memory. No sandbox binds `<configDir>` (E4 already holds). No token goes
+into a sandbox for `gitea` or `vikunja`. The agent asks the bus to act, and the bus uses the token.
+
+D3a. **A `store` reference with no file.** ENOENT on a `store` path loads as an absent entry. `status` shows
+`not-issued`, and `useFor` refuses `credential-unavailable`. The bus still starts. This is the state after a
+create without `issue` (D13) and after `revoke` (section 6). Every other defect still refuses start: wrong
+owner or mode on the file or a dir, a symlink, a non-regular file, bad format, a missing or wrong-mode
+`secrets/agents/` dir. `{file}` and `{env}` keep E2's behavior, where a missing file refuses start.
+
+## 3. The "RLS equivalent" (brief item 1)
+
+Three layers. Each one is enforced by code or the OS, not by prose.
+
+D4. **OS, between stack instances.** Files are 0600 and dirs 0700, owned by the stack instance's own OS user.
+Case 1's user can't read Case 2's store (Q180: each instance under its own user without sudo). The bus refuses
+to start when any file or dir under `secrets/agents/` has the wrong owner or mode (`credential-file`, as E2
+does for files today, extended to the dirs).
+
+D5. **Bus, between agents of one stack instance.** The principal for every credential use comes only from the
+verified cap (E5). The agent-facing API is `credentials.useFor(session, kind, op)`: `session` is the broker's
+frozen record, and the key is built from `session.business` and `session.role`. It has no agent argument, so
+there is nothing in a request to point at another agent. The existing `use(name, kind, op)` stays for the
+host's own `@sync` entry and is not reachable from a request. The tasks adapter's per-role calls (`ctx.as`,
+`verbs.mjs:126`) move to `useFor`. Any request field that names an agent other than the caller (`as`,
+`agent`, `instance`, `role` on a credential path) is refused `credential-not-yours` and recorded through
+`broker.refuse()` as `action.refused`, with the caller's cap and the task ref. A build test greps every
+`credentials.use(` call site and fails on a new one outside the allowlist.
+
+D6. **What stays open.** A process of the same OS user outside the sandbox can read every agent's file. That
+is the same limit as the human proof (P19 333). Q180's per-user VMs move the boundary to "one stack instance
+per OS user". Agents of one instance are kept apart by the sandbox and D5, not by the OS.
+
+## 4. Kinds (brief item 2)
+
+| Kind | 10-27 | Use |
+|---|---|---|
+| `gitea` | yes | Git push to a granted remote (section 5). Gitea API verbs (issues, pull requests) wait. The factory's review flow runs in the working repo today, and no 10-27 case needs an agent to open a pull request |
+| `vikunja` | yes, exists | Moves to `store` references and `useFor`. No behavior change |
+| `model` | per stack instance only | See D7 |
+
+D7. **Model provider.** A model token has to sit inside the sandbox today, because the harness calls the
+provider itself (E6). Per-agent model tokens need a proxy that holds the real token and gives each run its own
+short-lived one, which is the CLIProxyAPI line in TARGET.md. That waits for its own row. For 10-27 the model
+credential is per stack instance: row 190's `<configDir>/secrets/claude-session.env`, owned by that
+instance's OS user. It is never a copy of jwoltje's file. Jason signs in on each VM user himself (A6). Whether
+Case 1 and Case 2 run on Jason's existing subscription or need a new account is Jason's call (Q-J1). This row
+doesn't pick. A pi model credential also waits for P19 #383.
+
+## 5. Git identity and push (brief item 3)
+
+D8. **Identity.** A new business-file key, `roles.<agent>.identity = {name, email, gitea: {url, user}}`. It is
+optional, because today's business files with a `gitea` agent (coder) must load unchanged. `publish` (D9
+step 2) requires it, and requires that the definition declare `gitea`. A business file with a `publish`
+grant on an agent that lacks either refuses at load, and the error names `roles.<agent>.publish` and says
+"needs identity and a gitea definition" (N10). Load is the only place this is checked: a business file that
+fails it never reaches the bus. The sandbox sets `GIT_AUTHOR_*` and `GIT_COMMITTER_*` from
+it in place of E7's invalid domain. The email is the one Jason gives the agent's Gitea user, so Gitea links the
+commits to that user. Agents without `gitea` keep E7.
+
+D9. **Push to a remote: a new git socket op, `publish`.** No new socket, no bundle, and no token in the sandbox.
+
+```
+publish {"cap", "op": "publish", "task_ref", "project", "branch", "decision"}
+  -> {"ok": true, "result": {"fork", "ref", "commit", "previous"}} or a refusal
+```
+
+The host checks, in order, and each refusal goes through `broker.refuse()`:
+
+1. Identity from the cap (E5), then the broker's `#checkAuthority(s, "git.push.remote", {decision, target:
+   task_ref})`, as `checkLand` does for a merge (`broker.mjs:907-913`). `git.push.remote` is a new action in
+   ACTIONS and is not in ROUTED (REQ-WAIT-3, `packages/business/src/vocabulary.mjs:52-58`,
+   `broker.mjs:42-69`), so it is a hard wait and classifies `gated` for every role. Every publish therefore
+   needs a decision the human resolved for this task ref. A decision is spent once (`decision-consumed`).
+
+   **The decision binds one commit.** `#authorityFor` binds action, role, thread and target only
+   (`broker.mjs:769-798`), so the commit needs its own carrier. The raise records it the same way it records
+   `holderRun` for `role.revoke` (`broker.mjs:1733`). When the action is `git.push.remote`, the
+   `decision.raise` event body gets `pushCommit`. That is the commit of `#latestPush(business, target)` at
+   raise time, read by the broker and never taken from the agent. A raise with no recorded push for the task
+   refuses `no-push`. The decision's question shown to the human ends with that commit. `#authorityFor` then
+   refuses `decision-mismatch` when `context.pushCommit` differs from the commit of `#latestPush` now, which
+   is the same check `holderRun` gets at `broker.mjs:796`. So the sequence approve at A, push B, publish B
+   refuses.
+   No role definition grants the action yet. When Jason's PRD version routes it (Sage, Vikunja #420), a
+   reviewed commit adds it to both ROUTED lists and to coder's `withinRole`. From then on a coder publishes
+   without a decision, and `decision` is optional for a within-role class only.
+2. The project is in the agent's grant, `roles.<agent>.publish: [project]`, and the business file names the
+   project's upstream repository, `projects.<project>.remote: "https://HOST/OWNER/REPO"`
+   (`remote-not-granted`). Both URLs pass D9c's parse at load. The upstream's host and port equal
+   `identity.gitea.url`'s (`remote-host-mismatch`). The host never contacts that URL. It builds the agent's
+   fork, `fork = https://HOST[:PORT]/<gitea.user>/REPO`, from the upstream's origin and repository name and
+   the agent's own `gitea.user`. `fork` is the only URL the rest of `publish` uses: D9a's `ls-remote`, step
+   5's push, the helper's host match, `checkPublish`'s result and step 6's event. So the owner of the
+   repository that receives a push is the agent's own Gitea user on every push, by construction, and the
+   agent can't name it (webby-0011 N1). D9c is what makes "by construction" hold. Gitea's refusal of a
+   push to a repository the user doesn't own or collaborate on is the second layer. An upstream whose owner
+   equals the agent's `gitea.user`, compared without case, refuses `remote-not-fork`, at load and at push. `remote` is a new key
+   beside `root` and `repo` (`business.mjs:186`), and `identity` and `publish` are new keys on a role entry
+   (`business.mjs:89`). All three are optional, so today's business files load unchanged.
+3. The source is one commit, `C = context.pushCommit`. It is checked three ways, so all three are equal:
+   the decision's commit, the commit of `#latestPush`, and the work ref's tip in the working repo,
+   `work/vikunja-<project>-<task>` (`working.mjs:110-114`). The tip is read under the repository's lock, and
+   if they differ the push refuses `ref-moved`. The work ref is per task, not per agent. Two checks make it the
+   caller's: `#latestPush` was recorded by the caller's role (`work-not-yours`), and step 4. The destination is always `refs/heads/<gitea.user>/<branch>`, built by the host.
+   `validBranch(branch)` holds (`invalid-request`). The agent never names the destination ref.
+4. Every commit in `main..<work ref>` has author and committer email equal to `identity.email`
+   (`identity-mismatch`).
+5. The push runs through `credentials.useFor(session, "gitea", ...)`: `git push <fork> <C>:<dst>`, by oid,
+   with no `+` and no `--force`. It never pushes by ref name, so a push to the working repo after
+   `checkPublish` can't change what goes out (`non-fast-forward` from git stays a refusal). Git runs with E8's SAFE flags
+   (`working.mjs:92-98`), which set `protocol.allow=never`. `publish` adds exactly two flags,
+   `protocol.https.allow=always` and `http.followRedirects=false`, plus `GIT_TERMINAL_PROMPT=0` and no global
+   or system config. The token reaches git through a one-shot credential helper that reads it from an
+   inherited pipe, never through argv, env, the URL or a file. Seat `gitEnv` (`checkout.mjs:79-89`) takes only
+   PATH from the host and sets the rest itself, so no proxy or `GIT_SSL_*` variable reaches git. `publish` takes a `tls` parameter that
+   defaults to `[]`, the same way `push` takes `fsck = FSCK` (`working.mjs:100`). Tests pass
+   `["-c", "http.sslCAInfo=<scratch CA>"]`. The host never sets it, and nothing in config or env reaches it. The helper answers `get` only when `protocol`
+   is `https` and `host`, port included, equals `fork`'s. It writes nothing for any other `get` and for
+   `store` and `erase`. `assertClean` checks git's output, so a fork that echoes the token gets
+   `credential-leak`.
+6. The bus records `action.allowed` for `git.push.remote` with fork, ref and commit.
+
+D9a. **The agent's fork must share root's history.** A push sends every object the fork lacks. The working
+repo's `main` is the project root's history (`working.mjs`, seed), so a fork that doesn't share it would
+receive all of root, landing squashes included. The check runs on `fork`, never on the upstream: a related
+upstream says nothing about what the agent's `<user>/REPO` holds.
+`publish` runs `seed` first (`working.mjs:164-176`), under the repository's lock as `push` does, so `main`
+catches up with root before the check below. That means a fork also receives any landed root commits that
+upstream doesn't have yet, because they sit under the agent's work. That is expected: the agent's branch is
+built on them.
+Before the push, the host runs `git ls-remote --symref <fork> HEAD` (same flags and helper). It refuses
+`remote-unrelated` when the fork is empty or when that tip isn't a commit the working repo already has and an
+ancestor of `main`. When `ls-remote` exits non-zero, for a fork that doesn't exist, a refused token or a
+network failure, `publish` refuses `fork-unavailable` and the push doesn't run (N11). Git's stderr isn't
+parsed to tell those apart and isn't returned, since it can carry the URL. Only `ls-remote` crosses the
+network for this, so nothing is fetched from the fork. If the fork has moved past root, the refusal stands
+until root catches up. That is a human pull into root, not an agent's.
+
+D9c. **The URL parse (B6).** `projects.<p>.remote` and `identity.gitea.url` are parsed with `new URL()` at load,
+and the business file refuses to load unless all of these hold:
+
+- The scheme is `https:`. There is no username, password, query or fragment.
+- The string equals its own normalized form: for the upstream, `url.origin + url.pathname`; for
+  `gitea.url`, `url.origin + "/"` or `url.origin`. So a dot segment (`/<user>/../OWNER/REPO`), a
+  percent-encoded dot, an upper-case host, an explicit `:443`, a backslash, userinfo, a query and a fragment
+  each refuse, because `new URL()` would change them (checked with node: each differs from its normalized
+  form). A trailing slash survives normalization and is refused by the two-segment rule below. The checks below run on that path, so the owner that is checked is
+  the owner that is used.
+- The upstream's path is exactly `/OWNER/REPO`: two non-empty segments, no more and no fewer. One trailing `.git` on
+  REPO is allowed and stripped. `fork` is built from the stripped REPO.
+- `OWNER`, `REPO` and `gitea.user` each match Gitea's name rule, `^[A-Za-z0-9_.-]{1,100}$` and not `.` or
+  `..`. REPO after stripping must still match.
+- `gitea.url`'s path is `/`. A Gitea served under a sub-path isn't supported by this row and refuses at load.
+- Host and port are compared after `new URL()` normalized them, and an omitted port counts as 443 on both
+  sides.
+- Gitea compares user and repository names without case (`lower_name`), so `remote-not-fork` compares the
+  upstream's OWNER with `gitea.user` without case. An upstream owned by `Coder` and a `gitea.user` of `coder`
+  would otherwise build a "fork" that is the upstream itself.
+
+D9b. **How `publish` reaches the broker and the store.** The git socket runs in the bus process
+(`cli.mjs:504-506`) and reaches the broker only through the host's op table (`bus/src/runtime.mjs:222-246`).
+`publish` adds three entries there, each wrapped in `refusing()`:
+
+- `checkPublish(cap, args)`: steps 1 to 3, including the decision check. It returns `{ticket, fork, user,
+  email, source}` and no token. The ticket holds the session and the decision until `recordPublish`, the
+  same way `checkLand` holds a landing.
+- `withGitea(cap, fn)`: `credentials.useFor(broker.session(cap), "gitea", fn)`. `fn` gets the token and runs
+  step 5. The token never leaves that call.
+- `recordPublish(ticket, result)`: step 6, and it spends the decision.
+
+The op table gets no entry that returns a token.
+
+D10. **Which refs.** Our side: only `refs/heads/<gitea.user>/*`, set by the host (D9 step 3). The default
+branch and other agents' prefixes can't be named. Gitea side, two options (Q-M1):
+
+- **O1. A fork per agent. Ruled by Mos (mos-1027).** The agent's Gitea user has read on the upstream repo and owns a fork
+  named like it. The host derives the fork's URL from the upstream and the agent's user (D9 step 2).
+  Its token can write only repos the user owns or collaborates on, so Gitea itself stops any push to upstream
+  or to another agent's fork. No branch rules are needed per agent, so none can drift. The cost: work reaches
+  upstream as a pull request from the fork, opened by a human or a later API verb.
+- **O2. One shared repo. Not chosen.** The agent is a Write collaborator. Upstream's default and release branches get
+  branch protection with no agent on the push list, plus a rule `<user>/*` per agent. Gitea doesn't stop agent
+  A from creating an unprotected name outside `A/*` unless a catch-all rule outranks the per-agent ones. That
+  depends on Gitea's rule priority, which I haven't verified on our version (probe P1). Every hire adds a rule.
+
+Token scopes for either: `write:repository` and `read:user`, nothing else, per vocabulary.mjs rules (no
+`all`, no admin).
+
+D11. **The host git socket.** `publish` is added to the socket. `push`, `fetch` and `land` don't change. The
+socket's bind rule (E4) adds `git.push.remote`. The working repo stays credential-free and remote-free. The
+`fork` URL is passed per call and never written into its config. A landing still squashes into the project
+root as "Mosaic bus host". Landings don't push anywhere.
+
+## 6. Lifecycle (brief item 4)
+
+All verbs are on the bus, in the CLI (`mosaic credentials ...`) and in the Console's agent page. Every verb is
+human-only. Under Q173 the tester may run `status` and `revoke` on the dev stack instance. `issue` and
+`rotate` stay with Jason, because the tester is an agent and the token would pass through its session
+(duckworth N1). Each one appends to the organization
+writer's `changes.jsonl` (actor, agent, kind, verb, date; never a value). No schema migration, no new event
+kind. A refusal uses `action.refused`.
+
+| Verb | What it does |
+|---|---|
+| `issue AGENT KIND --rotate-by DATE` (gitea) or `--expires DATE` (vikunja) | Reads the token on stdin (never argv), checks E2's format, writes `<kind>.tmp` 0600, fsyncs, renames over `<kind>`, and sets the business file reference to `{"store": true, date}`. The bus reloads that one entry, with no restart |
+| `rotate` | Same as `issue` over an existing entry. The old value is gone from disk and memory when the call returns. Jason then deletes the old token in Gitea (A5) |
+| `revoke AGENT [KIND] --reason` | Drops the entry from the bus's memory first, then unlinks the file. A use in flight finishes. Every later use refuses `credential-unavailable` |
+| `delete AGENT` | `revoke` for every kind, then removes the agent's dir. Refused while the agent has a running claim |
+| `status [AGENT]` | Kind, date and state per entry (E3's `status()`), no values |
+
+D12. **"Stops working at once."** On our side this holds without a timing window. A fired agent never holds a
+`gitea` or `vikunja` token (D3), so revoking means the bus no longer has it. On the Gitea and Vikunja side the
+token still exists until Jason deletes it (A5). The status line for a revoked entry says so until Jason
+confirms. The model token is the exception: it sits in the running sandbox (D7), so a fired agent's runs must
+end. Row 194's fire ends them.
+
+D13. **What row 194 calls.**
+
+- `credentials.issue` is never called by the chief. Row 194's hire stays uncredentialed (its D1).
+- A human `create` of a credentialed definition: row 194 lifts E9's refusal for the human path only. The agent
+  is created with `store` references and no files. `launch` refuses `credential-unavailable` until Jason runs
+  `issue`.
+- `fire` and `delete`: row 194 calls `credentials.revoke(business, agent, {reason, actor})` before it changes
+  the business file. A failed revoke stops the fire (`credential-revoke-failed`), so an agent can't be fired
+  with its credentials still live on our side.
+- `regenerate`: no credential change.
+
+## 7. Who does what (brief item 5)
+
+Agents never mint accounts or tokens. Jason's steps, per agent that needs `gitea`:
+
+- A1. Create the Gitea user: Site Administration, User Accounts, Create User Account. The name is the agent's
+  `gitea.user`. The email is the agent's `identity.email`.
+- A2. Create its token: sign in as that user, Settings, Applications, Generate New Token, scopes
+  `write:repository` and `read:user`, nothing else.
+- A3. Create the fork of each granted repo as that user (O1). Gitea's push-to-create
+  (`ENABLE_PUSH_CREATE_USER`, `ENABLE_PUSH_CREATE_ORG`) stays off, so a push to a missing `<user>/REPO`
+  fails rather than creating a plain repository (N11). `publish` refuses `fork-unavailable` before that.
+- A4. On the stack instance's VM, as its OS user: `mosaic credentials issue AGENT gitea --rotate-by DATE`, with
+  the token pasted into stdin.
+- A5. On fire or rotate: delete the token in Gitea (Settings, Applications), or disable the user.
+- A6. Model: sign in to the provider on each VM user to write `<configDir>/secrets/claude-session.env`.
+
+Vikunja bot accounts and tokens are already Jason's (tracker bots). Only A4 changes for them.
+
+## 8. Migration (brief item 6)
+
+- M1. Existing `{file}` and `{env}` references keep working. A business moves one agent at a time with
+  `issue`, which rewrites that agent's reference to `store`.
+- M2. Nothing here touches the dev repository's helper, its `.git/config`, `~/.mosaic` or `~/.mosaic-dev`.
+  Dev seats (jarvis, seat tokens) keep pushing as today. The mos-0981 rule ends only when Mos says so.
+- M3. The live dev stack instance needs no change at re-pin: no reference uses `store` until someone issues
+  one.
+
+## 9. Questions
+
+Mos ruled on the authority model in mos-1027 (2026-10-20T19:27Z):
+
+- Q-M1. O1, one fork per agent.
+- Q-M2. `git.push.remote` and its bounds in D9 to D11 are approved. It lands as a hard wait: out of ROUTED,
+  and no role grants it within-role (D9 step 1). Sage puts its routing in the PRD version draft going to
+  Jason with `role.hire` and `role.fire` (Vikunja #420). After his approval, a reviewed commit routes it and
+  grants it to coder.
+- Q-M3. Issue, rotate and delete are human-only, and the chief gets none of them. Under Q173 the dev
+  instance's tester gets `status` and `revoke` only.
+- Q-M4. The model credential stays per stack instance for 10-27. Per-agent model tokens wait for a proxy
+  row.
+
+Open for Jason. Mos takes these to him one at a time:
+
+- Q-J1. The model account for Case 1 and Case 2: existing subscription or a new account.
+- Q-J2. Gitea users and tokens for the agents that need them (A1 to A3).
+
+## 10. What this closes (brief item 7)
+
+- G11: closes the store (D1 to D6) and lifecycle (section 6) for `gitea` and `vikunja`. Still open: per-agent
+  model credentials (D7), and the same-uid limit inside one stack instance (D6).
+- G13: closes "own credentials for git" (D8 to D10). Still open: Gitea API verbs (section 4).
+- C2.5 (git remote): Case 2's books repo can use `publish` once its project names a remote.
+
+## 11. Tests and mutants
+
+All tests use scratch roots, fake tokens and a fake Gitea: `git http-backend` behind a node http server on
+127.0.0.1 that checks basic auth against a fake token and records each ref update. No request leaves the host.
+
+- T1. Layout: wrong mode or owner on a dir or file refuses start. A `{file}` reference into another agent's
+  path refuses `credential-not-yours`. A bus restart after a create without `issue` starts, and the agent's
+  status is `not-issued`. A missing `{file}` still refuses start.
+- T2. `useFor` keys from the cap only. A request naming another agent is refused and leaves one
+  `action.refused`.
+- T3. The fake Gitea serves https on 127.0.0.1 with a cert from a scratch CA made by the test. It reaches git
+  only through the `tls` parameter (D9 step 5). Each refusal test that should reach the network asserts that
+  the first port received the request, so no test passes because git refused http first. `publish`: the
+  happy path lands `refs/heads/<user>/<branch>` on the agent's fork in the fake, which shares root's history, at
+  exactly the decision's commit. Refusals for each step in D9, one test each, including `work-not-yours`. Until routing, a publish with
+  no decision refuses, one with a decision for another task or commit refuses, and a second publish on a
+  spent decision refuses `decision-consumed`. Approve while the latest push is A, push B, publish: refuses
+  `decision-mismatch`, and the fork receives nothing. A push to the working repo between `checkPublish` and
+  the git push refuses with `ref-moved` or `decision-mismatch` (sage-1440, BUILD.md deviation 14). A raise with no recorded push refuses `no-push`. A test pins that `git.push.remote` is in neither ROUTED list
+  and that no `roles/*.json` grants it. A force-push attempt is
+  refused by git's non-fast-forward. A fake fork that answers 302 to a second 127.0.0.1 port: the push
+  fails, and the second port receives no request with an Authorization header. A remote on the right host
+  and a different port is refused at step 2. Two agents granted one project each land on their own fork:
+  agent A's push reaches `/<A's user>/REPO` only and B's reaches `/<B's user>/REPO` only, and the fake's
+  upstream repository receives nothing. An upstream owned by the agent's own user refuses `remote-not-fork`,
+  and so does one whose owner differs from `gitea.user` only in case. With an upstream that shares root's
+  history, a first publish to an empty fork and to an unrelated fork each refuse `remote-unrelated`, and
+  neither fork nor upstream receives objects. A fork that doesn't exist refuses `fork-unavailable`, and the
+  fake records no push. `ls-remote` and the push each reach the fork's path only (the fake records every
+  path). Load refusals (D9c), one test each: a dot segment, an extra path segment, a missing segment,
+  a trailing slash, userinfo, a query, a fragment, an explicit `:443`, a name outside Gitea's rule, and a `gitea.url` with a
+  sub-path. A `.git` suffix loads and builds the fork without it. A `publish` grant on an agent without
+  `identity`, and on one whose definition lacks `gitea`, each refuse at load with the N10 message.
+- T4. Token handoff: the token never appears in argv, env, the fork URL, the working repo config,
+  `changes.jsonl`, events or logs (scan every file under the scratch roots).
+- T5. Lifecycle: issue, rotate, revoke and delete, each live with no restart. After revoke, `publish` and the
+  Vikunja path refuse `credential-unavailable`, and so they do after a bus restart that follows the revoke.
+  The tester can run `status` and `revoke`, and `issue` and `rotate` refuse it.
+- T6. Default: an agent without `identity` commits as E7. Existing `{file}` references load unchanged.
+
+Mutants to kill: drop the cap-derived key in `useFor`, let the request name the destination ref, add `+` to
+the refspec, skip the identity check, put the token in the URL, revoke file before memory, skip the dir mode
+check, allow a `{file}` reference into another agent's dir, make ENOENT on a `store` path fatal again, make
+ENOENT on a `{file}` path silent, a helper that answers any host, drop `http.followRedirects=false`, drop the
+`work-not-yours` check, drop the `remote-unrelated` check, add `git.push.remote` to ROUTED, skip the spent
+check on the decision, drop the `pushCommit` comparison in `#authorityFor`, push by ref name in place of the
+oid, push to the upstream URL in place of the derived fork, run `ls-remote` against the upstream in place of
+the fork, take the fork's owner from anywhere but the agent's `gitea.user`, compare the owner with case, run the
+D9c checks on the raw path in place of the normalized one, read a failed `ls-remote` as empty, skip the tip
+check under the lock, and pass a CA flag in production.
+
+## 12. Risks
+
+- R1. Backups: if a backup tool copies `<configDir>`, it copies tokens. The build checks row 185's backup set
+  and says what it includes.
+- R2. Withdrawn. O1 was ruled, so probe P1 isn't needed.
+- R3. Outbound HTTPS from the bus host to Gitea is new network reach for the host process. On the VMs this is
+  Jason's network to confirm.
@@ -0,0 +1,75 @@
+# Row 237: one decision publishes once (#1743)
+
+Megavolt, 2026-10-21 (from `date -u`). Brief: `docs/plans/2026-10-20_agent-credentials.md`
+§ "row 199 follow-up N1", blob dca67d310e1b. Source: Duckworth's row 199 round 1 note N1
+(duckworth-0068). Base: `cb5fdb064` (row 199's landing). Reviewer Duckworth, gate owner Sage.
+
+## The defect
+
+`checkPublish` opens a ticket after checking the decision is unspent. The decision is spent only at
+`recordPublish`, which runs after the bus process has pushed. Two `checkPublish` calls on one decision
+therefore both get tickets, and both push. With different branches, the commit lands on two fork refs:
+`refs/heads/<user>/feat` and `refs/heads/<user>/other`. The second `recordPublish` then refuses
+`decision-consumed`, but by then its push has already reached the fork.
+
+## The fix, and why this option
+
+`checkPublish` refuses `publish-busy` when an open ticket in `#publishes` holds the same business and
+decision (`packages/bus/src/broker.mjs:1038-1040`). It runs after the authority and fact checks, so a
+spent decision still refuses `decision-consumed` first.
+
+The brief's other option, rechecking `#spent` in `publishTarget`, doesn't close the race. Both tickets
+reach `publishTarget` before either push ends, and nothing is spent until `recordPublish`. So both
+rechecks pass and both pushes run. The only state that exists while the first push runs is the open
+ticket, so the check reads that.
+
+A refusal (`publishRefused`) drops the ticket and leaves the decision unspent, so a retry on the same
+decision gets a new ticket. That is row 199's behaviour, unchanged. A within-role publish has no
+decision and isn't affected.
+
+## Tests
+
+- `packages/bus/tests/publish.test.mjs:186`. A second ticket refuses `publish-busy`, on the same branch
+  and on another. After `publishRefused` the retry gets a ticket and a third refuses busy. After
+  `recordPublish` there is one `action.allowed` for git.push.remote and the next call refuses
+  `decision-consumed`. Another agent's decision on the same task isn't held.
+- `packages/cli/tests/publish-socket.test.mjs:269`. End to end through the git socket, the bus runtime
+  and the TLS fake Gitea. While the first publish holds its ticket, a second publish on the same
+  decision to branch `other` gets `publish-busy`. The fake Gitea gets exactly one `git-receive-pack`,
+  the fork has only `refs/heads/coder/feat`, and there is one `action.allowed`.
+
+Runs on this branch, single files:
+- publish.test.mjs: 13/13.
+- publish-socket.test.mjs: 8/8.
+
+## Mutant
+
+M1 removes the `publish-busy` line. Both tests fail:
+- The bus test fails at the first busy assert.
+- The cli test fails because the second publish answers `ok: true` with `ref: refs/heads/coder/other`.
+  That is the defect: two refs on the fork.
+
+Logs are in `/mnt/storage/scratch/megavolt-r237/` (m1-bus.log, m1b-cli.log). `cmp` confirmed
+broker.mjs matched the saved copy after the restore. The first cli mutant run (m1-cli.log) was against
+a hook that recursed on every checkPublish. I fixed the hook to fire only for branch `feat` and reran
+it (m1b-cli.log).
+
+## Residuals, not fixed here
+
+1. **A ticket that never ends holds its decision until the bus restarts.** `#publishes` is in memory.
+   That happens when the host dies between checkPublish and recordPublish or publishRefused. It fails
+   closed (`publish-busy`), and a restart clears it.
+2. **publish-timeout (sage-1440).** The socket files `publishRefused` and drops the ticket, but the bus
+   process's push may still be running. A retry on the same decision can then open a ticket while that
+   push is live. This is the same residual the socket already logs ("the bus process's push may still
+   reach the fork"). Closing it means the runtime's `remotes` must keep the decision busy until its push
+   settles, which reaches into runtime.mjs. That is beyond the brief's two options.
+3. **checkLand has the same shape.** `#landings` takes a ticket per call and the decision is spent at
+   `recordLand`. Whether two landings on one decision can both reach main isn't checked here. That's a
+   follow-up for Sage to row or dismiss.
+
+## Gate
+
+Per the brief: Duckworth approves the manifest, the bus suite and every `scripts/test-*.sh` are green
+on Sage's gate, and M1 is killed. This row also changes a cli test file, so the cli suite (or that file
+alone) should run on the gate too.
@@ -0,0 +1,7 @@
+# Morgana
+
+Builder seat, Claude Opus 5.5, started by Sage for MVP T1 row 193 (human users and RBAC, #1691) under mos-0974 and mos-0977.
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own `morgana/*` branches
+through the repository credential helper (mos-0981), never `refactor`, `main` or another seat's branch.
@@ -0,0 +1,10 @@
+# Quackerjack
+
+Builder seat, Claude Haiku 5.5 at high effort, started by Sage under mos-1023 item 1 and Q177 for federation
+rows R5 (`mosaic access list, grant, revoke`) and R2 (the `federation` config key), per Gizmoduck's design
+section 7 (#414).
+
+No launcher in this directory. The seat runs as a T3 thread and works in its own worktree. It has no
+credentials of its own; until the credentials row settles per-agent identity, it pushes only its own
+`quackerjack/*` branches through the repository credential helper (mos-0981), never `refactor`, `main` or
+another seat's branch.
@@ -0,0 +1,8 @@
+#!/bin/bash
+n=0
+for p in /proc/[0-9]*; do
+  c=$(tr '\0' ' ' < $p/cmdline 2>/dev/null) || continue
+  case "$c" in *shell-snapshots*|*chrome-devtools-mcp*|*sage-busy-now*) continue;; esac
+  if echo "$c" | grep -qE 'node --test|gate\.sh|mutant|scripts/test-[a-z-]+\.sh|docker compose'; then echo "BUSY ${p#/proc/}: ${c:0:160}"; n=$((n+1)); fi
+done
+[ $n -eq 0 ] && echo CLEAR
@@ -0,0 +1,24 @@
+#!/bin/bash
+set -o pipefail
+# Landing gate template (2026-10-14): sed the G= and OUT= lines and this comment.
+# Sequential suites, each teed to its own log; stops at the first failure.
+G=/mnt/storage/scratch/SET-ME-wt
+OUT=/mnt/storage/scratch/SET-ME-out
+cd "$G" || exit 9
+mkdir -p "$OUT" || exit 9  # a missing OUT failed the row 142 gate at step 1 (2026-10-15)
+# test-task.sh live cases run `docker compose` from $G, so without a name the project is "wt"
+# and leaves wt_default behind (row 142 gate, 2026-10-15). Name it per gate dir and remove it on exit.
+export COMPOSE_PROJECT_NAME="$(basename "$(dirname "$G")")"
+trap 'docker network rm "${COMPOSE_PROJECT_NAME}_default" >/dev/null 2>&1 && echo "removed network ${COMPOSE_PROJECT_NAME}_default"' EXIT
+# A gate tree without the node_modules link fails cli tests with ENOENT (2026-10-13).
+[ -d "$G/node_modules" ] || { echo "STOP no node_modules in $G"; exit 8; }
+echo "base $(git rev-parse --short HEAD) dirty $(git status --short | grep -vc node_modules) DOCKER_HOST=${DOCKER_HOST:-unset}"
+run() { local name="$1" dir="$2" cmd="$3"
+  (cd "$G/$dir" && bash -c "$cmd") > "$OUT/$name.log" 2>&1; local rc=$?
+  echo "$name rc=$rc $(grep -E '^ℹ (pass|fail) [0-9]+' "$OUT/$name.log" | tr '\n' ' ') | $(tail -n1 "$OUT/$name.log")"
+  [ $rc -eq 0 ] || { echo "STOP $name"; exit $rc; }; }
+# No pkg-queue step: scripts/test-queue.sh runs packages/queue/tests/ itself (same 156 tests; CI debate item 2a, Vikunja #274).
+for d in packages/*/; do p=$(basename "$d"); [ -d "$d/tests" ] || continue; [ "$p" = queue ] && continue
+  run "pkg-$p" "packages/$p" 'node --test tests/*.test.mjs'; done
+for s in scripts/test-*.sh; do n=$(basename "$s" .sh); run "script-${n#test-}" . "bash $s"; done
+echo GATE_PASSED
@@ -0,0 +1,36 @@
+# Row 189 gate timing (for row 197, Herb)
+
+Sage, 2026-10-20T19:25:04Z. Gate on 0c177e9ef (base 0217b71c8), one lane. The slot was mine. Seats may have run single test files at the same time, which the slot rules allow, and I did not record that.
+Start 2026-10-20T19:09:37Z, end 2026-10-20T19:20:36Z. Total wall time: 659 s.
+
+Wall time per suite is the gap between one suite's log mtime and the one before it (the first suite starts at start.txt), so it includes node start-up. node's duration_ms is listed where the suite prints it. Scripts print no duration.
+
+| Suite | Wall s | duration_ms s | Ended (UTC) |
+|---|---|---|---|
+| pkg-bus | 3 | 3.8 | 19:09:40 |
+| pkg-business | 3 | 2.2 | 19:09:43 |
+| pkg-cli | 388 | 388.5 | 19:16:11 |
+| pkg-control-board | 1 | 0.8 | 19:16:12 |
+| pkg-conversation | 35 | 35.4 | 19:16:47 |
+| pkg-discord | 3 | 2.6 | 19:16:50 |
+| pkg-harness | 12 | 11.6 | 19:17:02 |
+| pkg-ledger | 13 | 13.5 | 19:17:15 |
+| pkg-mosaic | 3 | 2.3 | 19:17:18 |
+| pkg-plugins | 0 | 0.3 | 19:17:18 |
+| pkg-project | 1 | 1.2 | 19:17:19 |
+| pkg-runs | 1 | 0.8 | 19:17:20 |
+| pkg-seat | 6 | 6.2 | 19:17:26 |
+| pkg-tasks | 1 | 1.2 | 19:17:27 |
+| pkg-webui | 58 | 57.9 | 19:18:25 |
+| script-auth | 1 | - | 19:18:26 |
+| script-conductor | 5 | - | 19:18:31 |
+| script-config | 2 | - | 19:18:33 |
+| script-discord | 8 | - | 19:18:41 |
+| script-extension-package | 1 | - | 19:18:42 |
+| script-foundation | 40 | - | 19:19:22 |
+| script-land-work | 11 | - | 19:19:33 |
+| script-queue | 21 | - | 19:19:54 |
+| script-release | 11 | - | 19:20:05 |
+| script-task | 31 | - | 19:20:36 |
+
+Source: /mnt/storage/scratch/sage-g189/out/*.log mtimes and gate.log. The cli suite is about 59% of the run, and webui plus conversation add about 14%.
@@ -0,0 +1,35 @@
+{
+ "seq": 22,
+ "id": "3a6c8fb9-a5ab-42f8-9755-902a88375ca2",
+ "at": "2026-10-20T22:41:14.444Z",
+ "business": "mosaic-stack",
+ "project": null,
+ "raised_by_role": "pm",
+ "raised_by_run": "rc9e993da24cf",
+ "class": "gated",
+ "action": "prd.approve",
+ "route_to": "human",
+ "question": "Approve PRD 1.8 exactly as drafted?\n\nFile: agents/honker/work/queue-194/PRD-1.8-DRAFT.md on mosaicstack/stack at commit 762a6711ff7ed049aa73dfde98b75ebf326bdd99 (revision 5), 319 lines, sha256 8eee52470b1d7df139164e3ba5cc128dc469457b2b52f298c12685c3483011a8. Duckworth reviewed it (duckworth-0061, confirmed duckworth-0062) and Mos checked it (mos-1140). The tip of branch honker/row194-b2 holds a later r6 (aba3cbdeb), which is not used here. This approval covers only the r5 commit and sha256 above. The PM copied these values from the request and did not compute or check the sha256.\n\nNotes the approval carries:\n1. Mos's reading: \"the main agent or chief of staff\" in Q10 is one role under two names, the chief of staff. Only the chief raises a grant request; the assistant passes the user's request to the chief. To change it, say so at approval and REQ-GRANT-1 changes first.\n2. Mos's reading: revoke by \"you, Mos or the tester\" means the user, the assistant (\"Mos\", Jason's assistant) for grants in its own organization, and the tester only on a dev instance.\n3. N5: host.sudo keeps the arbiter route version 1.7 set for git.push.remote. A raise for it that cites the spec and isn't within-role goes to the arbiter for its domain, not to the user. In manual mode it comes to the user.\n4. B7 residual: only an Approve creates a grant, but an agent running as the stack's OS user can still write the stack's own store (Q182 on dragon-lin, #423 on .53 and .54). This version doesn't close it.\n5. N6: the broker enforces only that the chief of staff raised a grant request. The rest of the chain of command is the messaging lists and role contracts, not a broker check.\n\nSource: a tester request relayed by the chief (message 6990efb4, tester message d54a190e). It is a test request, not Jason's instruction. It takes the same route as PRD 1.7 (decision d52febb5): non-blocking, no task, uncited, so it goes to the human's Inbox. I recommend yes because two reviewers have passed r5 and the open points are written down above, not hidden.",
+ "options": [
+  {
+   "key": "yes",
+   "text": "Approve PRD 1.8 exactly as drafted: the r5 file at commit 762a6711ff7ed049aa73dfde98b75ebf326bdd99 with the sha256 below, and only that."
+  },
+  {
+   "key": "no",
+   "text": "Don't approve. Say what changes, and a new revision comes back for review."
+  }
+ ],
+ "recommendation": "yes",
+ "task_ref": null,
+ "requirement_ref": null,
+ "blocking": false,
+ "supersedes": null,
+ "spec_path": null,
+ "spec_commit": null,
+ "authorization": {
+  "action": "prd.approve",
+  "target": null,
+  "approvalChoice": "yes"
+ }
+}
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
jason.woltje	e424159350	bus: row 237 one decision, one open publish; checkPublish refuses publish-busy while another ticket holds the decision, since it is spent only at recordPublish after the push; a broker test and a socket race test with exactly one receive-pack; BUILD.md with the option chosen, M1 and three residuals (duckworth-0068 N1, #1743 )	2026-10-20 19:31:48 -05:00
jason.woltje	cb5fdb064f	credentials: a credential store per agent, its own git identity, pushes to a remote (row 199, #1697 ) Squash of Megavolt's 627979a17..86963d281 on origin/megavolt/row199-on-190 (base `00d4cc1f6`, row 190's landing), the 37 manifest paths, build.patch 05383075, manifest 35f900fd (Duckworth approve round 1, comment 29779, rev 2540). Mutant batches 1 and 2 in agents/megavolt/work/queue-199/BUILD.md: batch 2 26 of 28 killed, M17 and M27 equivalent. docs/TOOLS.md is a 3-way merge with row 200 (`9e1085816`): row 199's hunk applies unchanged (patch-id d88379111e2e) and no test reads the file. Gate on `9e1085816` plus the patch: 15 package suites 2735 pass 0 fail, 10 scripts/test-*.sh suites 429 pass 0 fail (plus 156 node tests in the queue suite). Refactor moved to `76134dfde` since, a brief touching no manifest path. No live change: the stack runs from copy `4429a104f` until the 10-24 re-pin window.	2026-10-20 19:23:12 -05:00
jason.woltje	76134dfde1	plans: row 200 follow-up N1 brief (#1744 , Launchpad, Webby): the sso-config hint carries --instance NAME	2026-10-20 19:12:34 -05:00
jason.woltje	9e10858160	stack-release: activate --sso for the Q175 phase 2 window (row 200, #1698 ) Squash of Launchpad's 30e4bb1a3..9df40878f (round 3 on row 190's landing `00d4cc1f6`), the 3 manifest paths: scripts/stack-release.sh, packages/cli/tests/stack-release.test.mjs, docs/TOOLS.md. Manifest b3ead55c8b48 (Webby approve round 3, rev 2539, comment 29772). Patch b2a8f5de18b7. Gate on `9df40878f`: 15 package suites 2675 pass 0 fail, 10 scripts/test-*.sh suites 429 pass 0 fail (plus 156 node tests in the queue suite). Mutants 13 of 14 killed, M12 the ruled equivalent (sage-1446). Refactor moved to `722136772` since the base, touching none of the 3 paths. No live change: the stack runs from copy `4429a104f` until a re-pin.	2026-10-20 19:09:00 -05:00
jason.woltje	7221367728	plans: row 194 item 7 takes the restart route (honker-0044) and item 8 revokes on fire and delete before the business file changes (row 199 D13), with tests and mutants	2026-10-20 18:51:20 -05:00
jason.woltje	a304dad947	plans: C2-03a askpass ruling (megavolt-0060 to -0063, dewey-0765, gosalyn-0068): fixed argv with followRedirects=false and credential.helper reset, LC_ALL=C, exact-prompt helper with row 199's HOST/NAME checks, no userinfo; tests and four mutants	2026-10-20 18:42:52 -05:00
jason.woltje	919a84738b	plans: #436b build brief (#1742 , schema 3j-3k, design r5 `1be535aca`) and row 199 N1 follow-up (#1743 ); row 194 carries 199 N2; 193b2 moves to 3k-3l after #436b	2026-10-20 18:39:24 -05:00
jason.woltje	2d8687bcfd	sessions: pending lines from Darkwing, Rocko, Launchpad, Morgana, Honker, Gander, Herb, Dewey and Sage (2026-10-20 18:45Z to 23:32Z)	2026-10-20 18:32:42 -05:00
jason.woltje	1c46d0abf6	queue: revs 2456-2539. Morgana row 213 in-review rounds 1-2 (2456-2476); Gizmoduck row 210 in-review 1 (2458-2459); Gosalyn row 212 in-review r1 and row 230 start (2464-2470); Duckworth row 210 record (2466); Webby row 213 verdicts r1-r2 and row 200 r3 approve (2469, 2500, 2539); Darkwing row 190 r3 in-progress through row 232 in-progress (2501-2514); Filbert row 190 record and row 66 r3 approve (2504, 2526); Dewey row 66 r3 approve (2529); Megavolt row 199 in-review round 1 (2535-2536); Launchpad row 200 r3 in-progress and in-review (2509-2525); Sage requests, row 190 done, rows 232/233 added and briefed, row 195 after 190 and 233, brief re-pins of 226/230/232/233, row 66 round 3, the row 200 r3 request as jarvis, machine grant rows 234 and 235 added and row 206 after 234 with its 3k brief and piece, the row 199 r1 request as jarvis (2460-2538, 57 revs)	2026-10-20 18:32:06 -05:00
jason.woltje	f519fb1d26	plans: machine grant rows a (#1740 , schema 3i-3j) and b (#1741 ) briefs from design r6 f9039682e; 193b2 moves to schema 3j-3k after row a	2026-10-20 18:24:28 -05:00
jason.woltje	b8236a7e13	sessions: Filbert row 66 round 3 APPROVE	2026-10-20 18:20:31 -05:00
jason.woltje	c7675476b1	sage: P19 catch-up comments 411-413 on 413 (row 189 landed, no-send activate), 424 (row 210 status) and 414 (rows 201 and 204 landed)	2026-10-20 18:19:49 -05:00
jason.woltje	9de7ad8292	sage: row 66 r3 packet, rebase of r2 onto `c40d846cb` (sage/row66-r3 `2369c00e36`, same patch-id, manifest 42e3876ca168)	2026-10-20 18:15:59 -05:00
jason.woltje	c40d846cb8	sage: Vikunja comment scripts and read-backs for row 192 landing (P19 412) and the row 190 W11 comments 406-409	2026-10-20 18:12:18 -05:00
jason.woltje	01b40d3576	plans: C2-13a rulings for gosalyn-0065. G1: default instance only, no --instance, a named instance is a follow-up. G2: library refuses --sso for 10-27, preview set and proof pair stay, --sso waits for Q175 phase 2. Line cites moved to their places after rows 190 and 192 (webui-service.sh, stack-copy.sh, bus-service.sh, serve.mjs), and the Console's WantedBy replaces :41	2026-10-20 18:09:04 -05:00
jason.woltje	ad6f0be7aa	plans: installer I1/I3 brief, the stack user's stack-release.sh runs from its own clone of the release bundle (darkwing question, sage-1561)	2026-10-20 18:05:14 -05:00
jason.woltje	ffc124bf68	plans: installer I2 re-brief of C2-13a (row 230, #1732 ) and C2-13b (row 226, #1727 ) for Vikunja #432 . Q189: both units WantedBy=multi-user.target, root's 2c step enables both and starts the bus then the Console, no hand start at step 9 (gosalyn-0064, mos-1122, mos-1123). Row 190 landed first, so row 230 renders @CONFIG_ENV@ and @SESSION_ENV@	2026-10-20 18:02:39 -05:00
jason.woltje	8a14931fa4	plans: installer briefs I1 (Gitea #1734 ) and I3 (#1735 ) for Vikunja #432 (mos-1118, mos-1122). I1 builds on row 190's landing 00d4cc1f6; I3 carries the root lock finding, duckworth-0055's notes, the per-host enrollment step and the credential slot table	2026-10-20 17:56:07 -05:00
jason.woltje	0272383f58	sessions: Darkwing row 190 landed as `00d4cc1f6`, row 195 r6 approved and held	2026-10-20 17:53:27 -05:00
jason.woltje	00d4cc1f69	stack: several Mosaic Stack instances on one host (row 190, #1688 ) Squash of Darkwing's 176a6bf4b..df65a3d4c on origin/darkwing/row190-r3, the 25 manifest paths, build-r3.patch efe898c2, manifest cc0ea9e8 (Filbert approve round 3, comment 29713). Design revision 3 in agents/darkwing/work/queue-190/DESIGN.md. Gate on base `d0bbc5c1c` with the patch: 15 package suites 2664 pass 0 fail, 10 scripts/test-*.sh suites 429 pass 0 fail (plus 156 node tests in the queue suite). Refactor moved to `99a406ed3` since, a window record touching no manifest path. Mutants 20 of 20 killed (BUILD.md, round 3). No live change: the stack runs from copy `4429a104f` until a re-pin.	2026-10-20 17:49:06 -05:00
jason.woltje	99a406ed3c	sage: re-pin window `490e2771d` to `4429a104f` (row 192) record, STATE.md (sha256 a4d0a7b12f431f15), W.txt (ca9ad4a09059d3b7), S1/S2, matrices, W10 browser check and diagnosis (screenshots not committed), Mos's P3 rehearsal and flags check, W11 reads. Plan corrections after the window: NEW is 103 commits past OLD (not 106), the P3 flags note (mos-1107), and W10's line g and corrected browser checks (mos-1135, mos-1137). PRD 1.8 raise record, decision 3a6c8fb9 (mos-1140) (#1690 ; P19 386, 412)	2026-10-20 17:46:36 -05:00
jason.woltje	d0bbc5c1cb	business: 193a access level check widened to viewer (row 204, #1702 ) Squash of Morgana's 7f07da4aa..f869fd062 on origin/morgana/row193a (diff from R1's candidate `44e36fc4c`), the three manifest paths, manifest d38de8c9 (Duckworth approve, comment 29595). LEVELS gains collaborator and viewer, covers() takes a required least level, and an unknown grant level covers nothing. Gate on base `4385b9ec1` with the patch: packages and scripts/test-*.sh 2789 pass 0 fail. Refactor moved to `c9f374284` since, a SESSIONS line only. Mutants 7 of 7 killed (agents/morgana/work/queue-193a/ mutants.log on the branch). No live change.	2026-10-20 17:25:27 -05:00
jason.woltje	c9f374284b	sessions: Filbert row 190 manifest round 3 APPROVE	2026-10-20 17:16:20 -05:00
jason.woltje	4385b9ec18	plans: Case 2 briefs. C2-13a factory profile from gosalyn-0057 items 1-3 (--pm, --claude under the --node rule, no proxy flags), row 190 tokens to whichever lands second. New C2-01b for row 212's notes N1-N3, N4 to the C2-12 setup sheet, N5 to C2-10b (webby-0041, sage-1517)	2026-10-20 16:52:39 -05:00
jason.woltje	afad4993f6	business: FED R1, access.json loader and validator with covers (row 201, #1699 ) Squash of Gizmoduck's ae3c36f24..44e36fc4c, the three manifest paths, manifest 225597146daf1c0e3ffe2049636095733f40a3395318f8ba07dad1bf08c0c520 (Duckworth approve, comment 29581). Gate on `44e36fc4c`, run by Gizmoduck in Sage's slot: business suite 173 pass 0 fail, scripts/test-*.sh 10 scripts 422 pass 0 fail, mutants 44 of 44 killed. index.mjs gains one additive export line. No live change.	2026-10-20 16:47:42 -05:00
jason.woltje	f41729178e	plans: re-pin plan `490e2771d` to `4429a104f` (row 192, Q175 phase 1), npm ci in the new copy, for Mos's check (mos-1099 item 3)	2026-10-20 16:39:56 -05:00
jason.woltje	305857c8f9	queue: revs 2362-2455. Sage: Case 2 rows re-pinned to design r11 (`5b8def2f1`, row 226 to C2-13b), row 230 C2-13a added and briefed (#1732 ), row 215 (C2-04) assigned to Herb, row 192 landed `4429a104f` with landing note and done, row 228 review request resolved, plus earlier Sage revs. Other seats' revs: Filbert 2362, 2447 (row 190 verdicts); Herb 2395-2396; Webby 2420, 2428 (rows 197/228 verdicts); Morgana 2421 (row 213 claim); Researcher subagent 2422-2424 (row 228); Gosalyn 2426 (row 212 claim); Darkwing 2431, 2433, 2438 (row 190)	2026-10-20 16:35:11 -05:00
jason.woltje	176a6bf4b9	sessions: Filbert row 190 manifest round 2 CHANGES (base drift on row 192)	2026-10-20 16:29:20 -05:00
jason.woltje	5b8def2f14	plans: Case 2 row briefs from Gosalyn's `eac92d956` (design r11, approved webby-0038: C2-13 split into C2-13a unit render and host precheck and C2-13b install script and library precheck, C2-04 owner Herb, Console unit without [Install] per mos-1097)	2026-10-20 16:22:47 -05:00
jason.woltje	4429a104f6	webui: Q175 phase 1, the Console verifies SSO itself under --sso, OIDC RP with oauth4webapi 3.8.8 (row 192, #1690 ) Squash of Launchpad's launchpad/row192 53bb59462..37582e820, manifest round 2 6f8cee147713c53652b58d47c5efd15ed47da1efbef6a126464857269b0b7787 (18 paths). Sage's gate on `088087ac9`: package suites 2758 pass 0 fail, scripts/test-*.sh 429 pass 0 fail; mutants 22 of 23 killed, #23 (second origin check) declared equivalent by Launchpad (sage-1407). New dependency oauth4webapi 3.8.8: the canonical checkout and any stack copy need npm ci. No live change; the live re-pin is a window with Mos (mos-1099 item 3).	2026-10-20 16:21:29 -05:00
jason.woltje	32b54ac3b0	plans: Case 2 row briefs from Gosalyn's `51006710a` (webby-0034 N1/N2 and webby-0035: row A README :711 one line per variable, C2-13 owns README :713 and says the precheck prints only variable names)	2026-10-20 15:57:07 -05:00
jason.woltje	6025ddd9cf	plans: Case 2 row briefs from Gosalyn's `a2d94b2c2` (Webby r9 notes, webby-0032: row A README line on claude-session.env and the dist/providers/data/zai.json path, C2-13 XDG_DATA_HOME precheck and last-assignment-wins key file parse)	2026-10-20 15:55:52 -05:00
jason.woltje	ecbfd6deb6	plans: Case 2 row briefs from Gosalyn's `29e85196b` (design r9 for mos-1090: row A out of scope points at design 10 step 2d, C2-13 precheck checks the hub key file by name and mode, claude marker check only for claude-code harness, EnvironmentFile= fixed in case2-unit.sh)	2026-10-20 15:44:09 -05:00
jason.woltje	0498c0613f	agents: Gosalyn seat dir, README from gosalyn/case2-design, so Case 2 rows can name the seat as owner (#416 )	2026-10-20 15:43:18 -05:00
jason.woltje	49d1f3a231	plans: Case 2 slice row briefs plus rows A and B, from Gosalyn's `f325657c7` on gosalyn/case2-design (#416 , design r8, C2-13 copy id and profile asks for row 195, C2-20 count-only note, row A ZAI_API_KEY per mos-1086/mos-1089, row B #428 after 10-27)	2026-10-20 15:41:39 -05:00
jason.woltje	628e2ca5cd	sessions: Filbert row 190 manifest round 1 CHANGES (base drift on row 189)	2026-10-20 15:40:15 -05:00
jason.woltje	088087ac96	queue: revs 2248-2361+. Sage: rows 210 (#424 host access, Gizmoduck) and 211 (#426 force-push guard, Rocko) added and briefed; row 195 re-briefed to the Case 1 install on .53; review requests for 200 r1/r2 and 202; plus earlier Sage revs. Other seats' revs: Launchpad 2254, 2283-2284, 2286, 2311-2313, 2328-2329, 2344, 2347-2348 (rows 192/200); Honker 2255; Morgana 2257, 2320, 2326-2327 (row 204); Gander 2262; Herb 2265; Dewey 2268; Bushroot 2273; Megavolt 2276; Webby 2303, 2316, 2339, 2355 (row 192/200 verdicts); Gizmoduck 2304, 2318-2319 and the row 210 claim (rows 201/210); Quackerjack 2317, 2341-2342 (row 202); Duckworth 2323, 2335, 2353 (rows 201/204/202 verdicts); Darkwing 2354, 2357 (row 190 in-review)	2026-10-20 15:34:55 -05:00
jason.woltje	a0fbefd48d	plans: pre-push force-push hook and failing busy check brief (Vikunja #426 , mos-1078, mos-1083; owner Rocko, reviewer Dewey)	2026-10-20 15:31:17 -05:00
jason.woltje	f24f2cd40d	plans: row 195 brief becomes the Case 1 install on 10.1.1.53 (Q181 hosts, Q182/Q183 recorded acceptance, Q185 existing account, chained on rows 190 and C2-13; ops-01 root steps under #423 step 1; sage-1439)	2026-10-20 15:24:33 -05:00
jason.woltje	9ba31b5b3f	agents: Honker's PRD 1.7 draft r2 on refactor for the prd.approve raise (`11cb0423b`, sha256 e896746df595d1b5155130ca163fbf63b0dc38a87a8dd154af77f1a6d1328647, Duckworth approved duckworth-0039, Vikunja #420 )	2026-10-20 15:20:37 -05:00
jason.woltje	9db578ff54	plans: agent host access with sudo through the credential store brief (#1707 , Vikunja #424 , Q183/Q184, chained on row 199)	2026-10-20 15:09:59 -05:00
jason.woltje	8eb9ddd12c	plans: FED R8 brief to r4.11 (`b93f098f0`, recorded acceptance, Duckworth N1/N2, #416 date), R5 context source (sage-1419), 193a makes covers level required (duckworth-0033 N1)	2026-10-20 15:06:22 -05:00
jason.woltje	ae3c36f248	agents: Gizmoduck seat dir and roster row (FED R1 owner, #414 )	2026-10-20 14:42:15 -05:00
jason.woltje	a2af7ab495	plans: FED R1, R5, R2 and R8 briefs (#414 , r4.9 `a1daa3c07`) and row 193a-d build briefs (#1691 ); Quackerjack seat dir and roster row	2026-10-20 14:41:03 -05:00
jason.woltje	aa1bd209e3	gate-lane: row 189 gate timing table for row 197 (Herb)	2026-10-20 14:25:17 -05:00
jason.woltje	ace27dc5eb	row 189 (#1687 ): stack-release.sh activate --no-send drops the Console's --send (Sage; Dewey approve 29485; Sage gate passed)	2026-10-20 14:21:56 -05:00
jason.woltje	a4a42dbac2	plans: stack-release --sso brief (#1698 , Launchpad, reviewer Webby, row 192 F3; chained on 192)	2026-10-20 14:18:08 -05:00
jason.woltje	a31f1a0f8b	plans: row 198 brief records Mos's call, in-process board reads behind the Console's auth (mos-1019)	2026-10-20 14:17:03 -05:00
jason.woltje	992650232f	plans: agent credentials and git identity brief (MVP T1 item 6, #1697 , Megavolt, reviewer Duckworth); Megavolt seat dir	2026-10-20 14:14:33 -05:00
jason.woltje	a7661ada06	plans: row 195 acceptance script takes Gizmoduck's gate item list; B8 issuer and TLS front end (mos-1011)	2026-10-20 14:12:19 -05:00
jason.woltje	f871cb3096	plans: retire the control board writer on 7331 brief (#1696 , Bushroot, reviewer Webby, mos-1008 item 2); Bushroot seat dir	2026-10-20 14:11:21 -05:00
jason.woltje	0bbd23c619	plans: row 195 brief adds the identity provider check and flags any new model account for Jason (mos-1008)	2026-10-20 14:10:28 -05:00
jason.woltje	0217b71c8f	plans: row 195 brief rewritten as the hub on its own host, host left to Jason (#1693 , mos-0998, mos-1005)	2026-10-20 14:07:57 -05:00
jason.woltje	c6f528a32f	plans: second gate lane brief (#1695 , Herb, reviewer Webby, mos-0977 item 6); Herb seat dir; gate template and busy check copies for the row	2026-10-20 14:03:36 -05:00
jason.woltje	96f243fafc	plans: human boundary row brief (P19 333, #1694 , Gander, reviewer Duckworth, mos-0989); Gander seat dir; seat READMEs name the credentials row, not row 195 (now 190b)	2026-10-20 14:00:58 -05:00
jason.woltje	c862699352	sessions: Filbert row 190 design review r3, approved	2026-10-20 14:00:05 -05:00
jason.woltje	48ebee0ffe	plans: row 190 brief scopes isolation to addressing on one uid, points to row 190b (Filbert N7, mos-0986)	2026-10-20 13:58:07 -05:00
jason.woltje	66bdd84b8f	sessions: Filbert row 190 design review r2, changes requested	2026-10-20 13:57:10 -05:00
jason.woltje	6966164f0c	plans: row 190b brief, Melanie's hub under its own Linux user (#1693 , Darkwing, reviewer Duckworth), mos-0986	2026-10-20 13:56:34 -05:00
jason.woltje	53bb594621	sage: common start for MVP T1 builder seats (mos-0974, mos-0977, mos-0981)	2026-10-20 13:55:47 -05:00
jason.woltje	5e01c36833	agents: seat dirs and roster rows for Launchpad, Morgana, Honker (Sage's T1 builders) and Webby, Duckworth (Mos's reviewers); row 193 brief takes Mos's B1 starting rule (mos-0985)	2026-10-20 13:52:28 -05:00
jason.woltje	9f56d2098d	plans: rows 192 and 194 review by Webby, not Filbert or Dewey (mos-0981)	2026-10-20 13:51:25 -05:00
jason.woltje	0599b119f4	plans: MVP T1 briefs, SSO phase 1 (#1690 , Launchpad), human users (#1691 , Morgana), agent lifecycle (#1692 , Honker), mos-0974/0977	2026-10-20 13:49:15 -05:00
jason.woltje	b416d2ede9	sage: Q175 SSO design, Mos C1 condition (mos-0977): straggler check before Jason step 4 in the phase 2 window	2026-10-20 13:49:15 -05:00
jason.woltje	5fc73a729c	revs 2237-2247: row 189 added, briefed, started, in-review round 1 (Dewey, comment 29457); rows 190 (Darkwing) and 191 (Rocko) added and briefed for MVP T1 (mos-0974); darkwing-190-start (rev 2245, Darkwing's) and rocko-191-start (rev 2244, made for Rocko)	2026-10-20 13:47:51 -05:00