agents: Honker's PRD 1.7 draft r2 on refactor for the prd.approve raise (11cb0423b, sha256 e896746df595d1b5155130ca163fbf63b0dc38a87a8dd154af77f1a6d1328647, Duckworth approved duckworth-0039, Vikunja #420)

agents/README.md

@@ -23,6 +23,8 @@ not fleet seats. Keep changes in `/mnt/storage/src/mosaic-stack`; do not modify
 | 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` |

agents/gizmoduck/README.md

@@ -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.

agents/honker/work/queue-194/PRD-1.7-DRAFT.md

@@ -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.

agents/quackerjack/README.md

@@ -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.

docs/plans/2026-10-20_federation-r1-r2-r5.md

@@ -0,0 +1,120 @@
+# Federation build rows R1, R2 and R5 (#414)
+
+Sage, 2026-10-20, for Mos's orders mos-1023 item 1, mos-1028 item 2 and mos-1034 item 1. The design is
+Gizmoduck's `agents/gizmoduck/work/federation/DESIGN.md` at a1daa3c07 on `gizmoduck/federation-design` (r4.9,
+sha256 a31cbebd070f9e3a5ca4ccb158b1747c6f5a83c3469855705b0026a581fb5c6a). Duckworth approved r4.5
+(duckworth-0012), r4.6, r4.7 (duckworth-0020) and r4.8 (duckworth-0021, 8a22d0897 on `duckworth/reviews`),
+and acked r4.9 (duckworth-0024). r4.7 applies Jason's Q181 hosts, r4.8 adds N22's R8 checks and r4.9 names who
+runs them. None of them changes R1, R2 or R5. Section 7's table
+sets each row's scope and test gate. Vikunja P19 #414. Seats push only their own `<seat>/*` branches
+(mos-0981).
+
+The other R rows are filed when their parents have candidates: R3 after R1 and row 196, R4 after R3, R5 and
+row 193's viewer level (193a, mos-1019), R6 after #412 phase 1, R1, R2 and R3, R7 after R1-R6 and row 190.
+R8 is a live window, not a code row. Its brief is the last section here.
+
+## Brief: FED R1, the access.json loader and validator
+
+Owner Gizmoduck, reviewer Duckworth, gate owner Sage. Base: refactor at this brief's commit. No parent.
+
+`packages/business/src/access.mjs`: the access.json loader and validator from DESIGN.md section 3.5, and the
+pure `covers`. Providers, peers and businesses come in as arguments. One read plus the file checks. The
+exported interface is what R5 and row 193a build against, so the manifest names it, and any change to it in
+review goes to Sage before it lands. Section 7 names `covers` but not the loader and validator exports or
+the context shape. Morgana's 193a (508ee4d61 on `morgana/row193a`) assumes `checkAccess(doc, {providers,
+peers, businesses})`, with `businesses` mapping an id to `{human, instances}`, throwing a `BusinessError` that
+names the key path. Use those names, or tell Morgana and Quackerjack yours before the manifest goes to
+Duckworth. Row 193a later widens the level check to `viewer` on R1's candidate (mos-1019).
+
+Tests, in `packages/business/tests/`: every rule in 3.5 refuses with the key path named. That covers a
+symlink, a non-regular file, another owner, group or other write, expiry, `*`, a grant disjoint from the given
+subjects, `human` and `tester` ids, any level other than `collaborator`, and a project entry that isn't a
+UUID. For `covers`: `*` and listed ids match, while an unlisted project, instance or business doesn't, an
+expired grant doesn't, and a level filter rejects another level. One mutant per refusal, each killed.
+
+Boundaries: no change to `~/.mosaic-dev`, `~/.config/mosaic-dev`, the live units or any live access.json. Tests
+use scratch roots. Single test files run freely, and suites need Sage's slot.
+
+Gate: Duckworth approves the manifest. The business suite and every `scripts/test-*.sh` are green on Sage's
+gate, and the mutants are killed.
+
+## Brief: FED R5, mosaic access list, grant and revoke
+
+Owner Quackerjack, reviewer Duckworth, gate owner Sage. Chained on R1 (Q177). The build starts now against
+R1's exported interface as the R1 manifest names it, and R5 lands after R1 and rebases onto R1's landing.
+
+`mosaic access list`, `grant` and `revoke`: human proof, atomic write, revision bump, a receipt line. The help
+text states the `instances` limit and the provider-removal order (DESIGN.md section 7, row R5). R4 later makes
+these verbs call `access.reload`, so R5 leaves no other reload path.
+
+Context (sage-1419). `ssoSubjects` is row 192's `console.sso.providers[].subjects` flattened to `{provider,
+sub}` pairs; the design's "`console.sso.subjects`" in 3.5 is shorthand for it. `providers` is the list of
+`providers[].id`, read through `loadSystem` and row 192's `checkConsole`. `peers` is `[]` until R2 lands, so a grant
+naming a peer home refuses. R5 rebases onto row 192's landing as well as R1's.
+
+Tests, in `packages/cli/tests/`: tester and agent callers are refused, a concurrent write refuses on a
+revision conflict, the receipt line is appended, and a bad grant is refused before anything is written. One
+mutant per refusal, each killed.
+
+Boundaries: no change to `~/.mosaic-dev`, `~/.config/mosaic-dev`, the live units or any live access.json. The
+human proof in tests uses the scratch stand-in pattern (a scratch bus verifies its own human-cli path).
+Single test files run freely, and suites need Sage's slot.
+
+Gate: Duckworth approves the manifest. The cli suite and every `scripts/test-*.sh` are green on Sage's gate,
+and the mutants are killed.
+
+## Brief: FED R2, the federation key in the system config
+
+Owner Quackerjack, reviewer Webby, gate owner Sage. Chained on row 192 (#412 phase 1). The build starts when
+row 192 has a candidate, on that candidate.
+
+A `federation` key in `scripts/mosaic-config.mjs` with the shape in DESIGN.md section 3. A config with no
+`federation` key still loads as it does today. This changes the config schema, so the manifest lists every
+reader of the key.
+
+Tests, in `scripts/test-config.sh`: a valid key loads, an unknown sub-key and a bad origin refuse, and a
+config without the key loads. One mutant per refusal, each killed.
+
+Boundaries: `~/.config/mosaic-dev/config.json` is user-authored and is not touched. Tests use scratch config
+dirs only.
+
+Gate: Webby approves the manifest. The cli suite and every `scripts/test-*.sh` are green on Sage's gate, and
+the mutants are killed.
+
+## Brief: FED R8, the hub window on 10.1.1.54
+
+A live window, not a code row (DESIGN.md section 7, row R8). The brief follows r4.11, b93f098f0 on
+`gizmoduck/federation-design` (sha256 1bcee8df0a3a8628a6646535b756c936ca6d9e7bcfa7e1dd2bf1d3f01715c8e6),
+which Duckworth acked with r4.10 (duckworth-0034). Mos closed design rounds there (mos-1072). Run by Jason and
+Mos. Nothing here authorizes a step on any host; each step waits for the window's go.
+
+What changed since r4.9 (DECISIONS Q182, Q183, mos-1055, mos-1063). R8 is a recorded acceptance. It starts
+with Jason's acceptance of the factory paths to .54 on record, quoted in section 8. The privilege and host
+checks still run, and each result goes into the R8 record with the name of whoever ran it. They report and
+don't refuse. The four functional checks named at the end of section 7's R8 row still stop R8 when they fail
+(mos-1066 item 1).
+
+Order (mos-1042 item 2). R8 runs after the Case 2 install on .54 (#416, due by 2026-10-27, Jason's latest-by
+date in Q176, mos-1069), after Bean and Chet are live in Case 2, and after both Hermes gateways on 10.1.1.54
+have stopped. Case 2 go-live doesn't wait on R8. The risk, stated for 10-27: federation between the two
+instances depends on Melanie's switch-over date.
+
+Entry checks, all before anything starts:
+- R7, #412 phase 2 and Jason's #419 answer, as section 7 lists.
+- The four hub user checks on 10.1.1.54 (N22, mos-1035 item 1): `sudo -l -U mosaic` grants nothing, `id
+  mosaic` shows only its own group, `~mosaic/.ssh/authorized_keys` is absent or empty, and no file under
+  `/etc/sudoers.d` names `mosaic`. An agent or Jason runs them as localadmin (mos-1055), and the output goes
+  into the R8 record with who ran them.
+- The factory privilege checks, the key fingerprint comparison and the section 8 privilege path table, each
+  as section 7's R8 row states them.
+
+Build notes:
+- N1 (Duckworth, duckworth-0034, mos-1072). A check that fails on a path Jason didn't name in Q182 or Q183 is
+  marked "not named in Q182 or Q183" in the record, not filed under the acceptance. Examples: a factory mount
+  of hub data, another agent on .54, a provider admin token. Mos takes each one to Jason.
+- N2 (Duckworth, doc-only). The Q183 and Q4 quotes in section 8 are excerpts. When the R8 record quotes them,
+  it marks each omission with "…" and checks the full text at DECISIONS.md:1535-1541 in jason-master-restart
+  (read only).
+
+Done when every entry check has its output recorded, Jason signs in to the hub and sends one message, Melanie
+revokes, and his next request is refused.

docs/plans/2026-10-20_host-credentials.md

@@ -0,0 +1,70 @@
+# Brief: agent host access with sudo through the credential store (#424)
+
+Sage, 2026-10-20, for Jason's rulings Q183 and Q184 relayed by Mos (mos-1056 item 3, mos-1067). Gitea #1707, Vikunja P19
+#424, due 2026-10-27 (Q184: "Q5: by 10.27"). Owner Gizmoduck (design and build), reviewer Duckworth, gate owner
+Sage. Chained on row 199's candidate (Q177): row 199 design r6 (4d3007ec9 on `megavolt/row199`, approved in
+duckworth-0027) is not reopened. This row lands after 199 and rebases onto its landing.
+
+## What Jason asked for
+
+Q183, through Mos: "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... 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." Q183 also says not every agent needs that access.
+
+Mos's requirements (mos-1067 item 1):
+- An agent asks for a host credential by name.
+- The stack checks a grant for that agent and that host, and does the ssh and sudo for it.
+- The agent never sees the key or any secret value.
+- Only agents with a grant can do it.
+
+The PRD text is REQ-CRED-3, drafted by Honker for PRD 1.7 (sage-1422). If it misses 1.7 it goes into 1.8, and
+this row lands only after the version that holds it is approved.
+
+## What row 199 gives and what it doesn't (megavolt-0019)
+
+It builds on 199 as 199 stands: the store layout under `<configDir>/secrets/agents/<business>/<agent>/`, the
+lifecycle verbs and their `changes.jsonl` receipts, `useFor(session, service, fn)` with the D5 allowlist test,
+`assertClean` on every result, and the grant shape of `publish` (a list on the role entry, checked by the
+broker, plus a hard-wait action that isn't routed).
+
+This row's own changes:
+- A host kind in the closed kind set (vocabulary.mjs `SERVICES`, credentials.mjs, the broker's service check,
+  the CLI date flag, the remove regex), with a naming rule for one credential per host or per agent.
+- A per-kind value check. An OpenSSH private key fails today's `TOKEN` pattern.
+- Handing the key to ssh without the agent seeing it: an ssh-agent on a private socket, or a 0600 temp file
+  removed on every path, the way publish's one-shot helper works.
+- Pinned host keys per host, and no trust on first use.
+- The command boundary: what an agent may run under sudo, and how output returns without echoing the secret.
+  This is the main design work.
+- The executor: a ticket and a host op running in the bus child, the same split row 199 uses for publish
+  (Megavolt's deviation in 199's BUILD.md).
+
+## Steps
+
+1. DESIGN.md first, in `agents/gizmoduck/work/queue-ROW/`. It answers each item above, names the grant shape
+   (`roles.<agent>.hosts` and a `host.sudo` action, or a reasoned alternative), says who grants (Jason, through
+   a reviewed role change, unless REQ-CRED-3 says otherwise), and lists tests and mutants. Duckworth approves it
+   before code. Sage reads it too, because it gives agents sudo on hosts.
+2. Build on 199's candidate. Single test files run freely. Suites and mutant batches need Sage's slot.
+3. The live part is not this row. Putting a key in the store and granting a host is a separate window with
+   Jason or Mos, after landing.
+
+## Hosts
+
+The first targets are `localadmin` with NOPASSWD sudo on 10.1.1.53 and 10.1.1.54 (#423 step 1, applied by
+ops-01 at 20:05:47Z), and the servers agents already reach as localadmin (Q172). ops-01 owns the host side.
+Tests use scratch sshd fixtures on 127.0.0.1 or fakes, never a real host.
+
+## Boundaries
+
+- No change to `~/.mosaic-dev`, `~/.config/mosaic-dev`, slot files, the live units or `~/.mosaic`. No key is
+  read, copied or printed. No ssh to any real host from a test or a seat.
+- No widening of row 199's kinds or regex inside row 199. Both rows touch them, so this row rebases after 199
+  lands.
+
+## Gate
+
+Duckworth approves DESIGN.md, then the manifest. The bus, business and cli suites and every
+`scripts/test-*.sh` are green on Sage's gate, and the mutants are killed (one per refusal, plus one that leaks
+the key into the agent's output and one that skips the host key pin).

docs/plans/2026-10-20_human-users-build.md

@@ -0,0 +1,70 @@
+# Row 193 build rows: 193a, 193b1, 193b2, 193c and 193d (#1691)
+
+Sage, 2026-10-20, for Mos's go mos-1034 item 4. Row 193's design is Morgana's
+`agents/morgana/work/queue-193/DESIGN.md` at e2d161e2e on `morgana/row193` (r5, sha256
+dd7fcb419ed8510e9d8d74b569183386d0942af8b68eecc0bbb5e182e677b523), approved by Duckworth (duckworth-0018).
+Section 8 lists the tests and mutants, and section 9 the split. The brief behind them is
+`docs/plans/2026-10-20_human-users.md`. Vikunja P19 #414/#415, Gitea #1691.
+
+Owner Morgana for every row, reviewer Duckworth, gate owner Sage. Each row chains on its parent's candidate
+(Q177) and rebases onto the parent's landing. Seats push only their own `<seat>/*` branches (mos-0981).
+Single test files run freely, and suites and mutant batches need Sage's slot.
+
+Boundaries for every row: no change to `~/.mosaic-dev`, `~/.config/mosaic-dev`, the live units, slot files, any
+live access.json or `~/.mosaic`. No request to the live Console, mosaic.woltje.com or auth.diversecanvas.com.
+No user thread goes live before 193b1's message filter has landed (mos-1021 B2, FED R8).
+
+The owner-visible records are fixed by Mos (mos-1023 item 2) and named in one user sentence, which FED R6
+reuses word for word: "The business owner sees your thread's agent's decisions, inbox entries, claims, tasks
+and project files, but not your messages."
+
+## Brief: 193a, the access level check widened to viewer
+
+Chained on FED R1. Started early on `morgana/row193a` (508ee4d61) against R1's interface as the FED brief
+names it, with Sage's go (sage-1373). R1's level check accepts `viewer` and still refuses any other new
+level. Tests in `packages/business/tests/` (section 8, Business), with the four mutants in Morgana's
+BUILD.md. FED R4 chains on this row.
+
+Duckworth's N1 on R1 (duckworth-0033, sage-1417): with viewer added, `covers` called with no level would let a
+viewer grant cover a collaborator ask. This row makes `level` required in `covers`, with a test and a mutant that
+makes it optional again. R3 and R4 call `covers` with a level.
+
+Gate: Duckworth approves the manifest. The business suite and every `scripts/test-*.sh` are green on Sage's
+gate, and the mutants are killed.
+
+## Brief: 193b1, viewer verbs, board refusals and the message filter
+
+Chained on FED R3, FED R4 and row 196's verifier. The bus gets the viewer verb list, per-grant level
+checks, board reads refused to users, and the section 5.7 `trail` and `replies` filter with `#readable`
+owner-only. No schema change. The governance pin test names each item in the user sentence above. Bus tests
+and mutants 1, 3, 6, 10, 11 and 12 from section 8.
+
+Gate: Duckworth approves the manifest. The bus suite and every `scripts/test-*.sh` are green on Sage's gate,
+and the mutants are killed.
+
+## Brief: 193b2, thread shares (schema 3j)
+
+Chained on 193b1. `thread_shares`, the share verbs, the share rules of `#readable` and `#threadRead`, and the
+section 5.5 share filters. Schema 3i to 3j. The table is append-only, and row 181's restore guard and
+`COUNTED` include it. Bus tests for shares and the migration, and mutants 2, 4, 7, 8 and 9 from section 8.
+Going live needs a `--migrate` window with Jason. Sage takes it to Mos when this row is near.
+
+Gate: Duckworth approves the manifest. The bus suite, the cli suite and every `scripts/test-*.sh` are green on
+Sage's gate, and the mutants are killed.
+
+## Brief: 193c, mosaic access user verbs and --level viewer
+
+Chained on FED R5. `mosaic access user add/remove` and `grant --level viewer`, only where R5 lacks them. They
+refuse tester and agent callers, write a receipt line and call `access.reload` (section 8, CLI). If R5
+already has all of them, this row records that and closes with no code.
+
+Gate: Duckworth approves the manifest. The cli suite and every `scripts/test-*.sh` are green on Sage's gate,
+and the mutants are killed.
+
+## Brief: 193d, the Console's shared list, share controls and viewer read-only
+
+Chained on FED R6, row 192 and 193b2 (for share controls). A viewer has no composer or share control, and
+with each UI check removed the bus still refuses (section 8, Webui).
+
+Gate: Duckworth approves the manifest. The webui suite and every `scripts/test-*.sh` are green on Sage's
+gate, and the mutants are killed.