gizmoduck: T3 federation design r4.11 for #414 (mos-1063): hub on .54 VM 1012 as mosaic (Q181), R8 depends on the Case 2 install (#416), #418 dropped

agents/gizmoduck/work/federation/DESIGN.md

@@ -0,0 +1,655 @@
+# T3 federation design: factory and hub (Vikunja #414, G3, G4, C1.1)
+
+Author Gizmoduck (Opus 5.5), 2026-10-20, r4.11. Design only, no product code. Reviewer Duckworth (Opus 5.5,
+mos-0978), r1 verdict changes B1-B5 (duckworth-0001, REVIEW.md at b402197ff), r2 verdict changes B6 (duckworth-0002,
+REVIEW-r2.md at 03a663cd7), r3 verdict changes B7 (duckworth-0003, REVIEW-r3.md at 45cbe5896), r4 verdict changes B8 (duckworth-0005, REVIEW-r4.md at
+4966136d4), r4.1 verdict changes, B8's issuer host (duckworth-0007, REVIEW-r4.1.md at b14f11136), r4.4 verdict changes B9 (duckworth-0010, REVIEW-r4.4.md at 4cf3ce232), r4.5 approved (duckworth-0012, REVIEW-r4.5.md at 912b1d325). R1, R2 and R5 go to Sage's
+queue once Duckworth approves, and Sage assigns owners. Code lines are at origin/refactor 9ae8c73ac. The
+Q175 SSO design is cited at Sage's local commit 817e8f51b (agents/sage/work/q175-sso/DESIGN.md), which was
+not on origin when this was written.
+
+Binding inputs: TARGET.md addendum 2026-10-20, DECISIONS Q175 to Q178, projects/mosaic-mvp/GAP-MAP.md and
+PLAN.md T3 (all in jason-master-restart).
+
+## Changes from r1
+
+- B1. A user principal now comes only from the Console's verified OIDC session. The user CLI takes the
+  human proof's walk, which refuses agent markers and binaries, and its direct parent must be the
+  Console from the bus's own tree. This needs the path-bound human proof (P19 333). Residual risk in 3.6.
+- B2. 3.6 names the ownership changes: `#owner`, `#threadFor`, the `#human` gates and `thread.send`'s
+  sender fields. `message.send` is on no list, and `#threadFor` refuses users as a second wall.
+- B3. One level for 10-27, `collaborator`, with an exact verb list and a filter per read (3.5). Viewer and
+  every board read wait.
+- B4. Revocation has three triggers: the next user request, a 30 s broker timer, and a reload verb that
+  R5 calls. The launcher refuses to start a revoked thread, because the broker reports it on every
+  `threadsState`. It also SIGTERMs a running one (3.7). R4 now depends on R3 and R5.
+- B5. A separate uid per instance is a hard entry gate of R8, with checks (mos-0984 point 2).
+- N1 to N9 are handled where they apply: v1 count (2), `configDir` at business.mjs:25-28 (5), R1 takes
+  providers and peers as arguments (7), "human-only" (3.5), file checks (3.5), `instances` as the real limit
+  (3.5), provider removal needs a Console restart (3.7), Q1 is with Jason (9), client ids in R8 (7).
+- r3 (duckworth-0002): B6, the reply path to a user (3.6 item 7, runner header, R3 test and mutant, R7
+  asserts a reply). C1, the walk doesn't stop an unsandboxed same-uid agent (3.6). N10, `names` gates
+  through `#agent` (3.6 item 4). mos-0991: R8's gate accepts a separate host or a separate uid, and 3.8
+  checks the federation path for one-host assumptions. Q1 holds Jason's answer. morgana-0002 settles Q2.
+- r4 (duckworth-0003, mos-0996): B7, R8's gate now proves there is no privilege path from the factory to
+  the hub. Per mos-0996 (Vikunja #418) the hub runs on its own host, and for 10-27 the gate is the host form
+  only. The uid form (row 190b) is a later option. The checks run as the factory uid with a clean
+  environment and pass only when the call fails: `sudo -n`, `doas -n`, and `ssh -o BatchMode=yes` to the
+  hub host with and without the agent socket. Factory root on the PVE nodes defeats the host form
+  (duckworth-0004, mos-1004), so it is an open R8 gate item with options O1 to O3 for Jason (Vikunja
+  #419, section 8). N11, `#waiting` returns null for `to` `user` (3.6 item 7, R3).
+  N12, R3 assumes nothing about how shares end (section 9 Q2). Row 196 (#1694, Gander) owns the shared
+  principal verifier before R3 (section 5).
+- r4.11 (mos-1063): the hub's host is settled, so the "own host, not dragon-lin or Melanie's server"
+  lines and the #418 dependency are gone. The hub runs on .54, VM 1012, as user `mosaic` (Q181), and R8
+  depends on the Case 2 install on .54 (#416). #418 is closed. #419 carries only the wording for
+  Melanie. Mos ruled the four functional checks stay blocking.
+- r4.10 (mos-1055, DECISIONS Q182 and Q183): R8 is a recorded acceptance. It starts with Jason's
+  acceptance of the factory paths to .54 on record, quoted in section 8. Every privilege and host check
+  still runs, and its result goes into the R8 record with who ran it. They report and don't refuse.
+  Agents may run the .54 checks as localadmin, which replaces r4.9's line. The mos-1042 order is now in
+  the R8 row. The wording still reaches Melanie only through Jason (#419).
+  Two lines that said R8 proves the factory has no login on the hub (sections 3.5 and 3.6) now say
+  factory agents keep ssh to .54 under Q183, recorded as accepted.
+- r4.9 (mos-1037): R8 names who runs the root checks on 10.1.1.54.
+- r4.8 (duckworth-0020 N22): R8 checks the hub user's limits on 10.1.1.54 instead of taking #421's plan
+  as done.
+- r4.7 (mos-1030, DECISIONS Q181): the hosts are settled. Case 1 is W-jarvis, 10.1.1.53 (VM 1008), the
+  same host as the Hermes agents, so section 8 lists them as one factory host. The hub, Case 2, is
+  W-Melanie-OC, 10.1.1.54 (VM 1012). Its OS user is `mosaic`, a system user with no sudo, no groups
+  and no keys (ops-01's tightening plan section 3, Vikunja #421).
+- r4.6 (duckworth-0012 N21, morgana-0011): R6's notice is row 193's final user sentence, word for word
+  (row 193 design r5 section 5.7, morgana/row193 e2d161e2e). The start-order line now matches the
+  section 7 table: R2 waits on #412 phase 1, and R5 lands after R1.
+- r4.5 (duckworth-0010): B9, a user-thread run can't message the owner, but its decisions do reach the
+  owner's inbox, as Sage ruled for row 193 (sage-1368, morgana-0008)
+  and Mos kept (mos-1022). 3.6 item 7 says so, R6 tells
+  the user, and R3 tests both sides. N20, the start-order line waits for row 193's viewer level. R8
+  can't start while any host variable is unresolved.
+- r4.4 (mos-1020, mos-1019): N17, R4 is chained after row 193's viewer level and keeps the level-loss
+  test, which has to kill its mutant before R4 is done.
+- r4.3 (duckworth-0007): B8, an issuer that isn't on the hub host must pass the host-access, hypervisor
+  and backups rows against its own host, and a hosted issuer's admin accounts each pass the failed-call
+  check (section 8, sign-in row). N16, the dependency note covers every secret on a PVE guest. N17, R4's
+  level-loss test moves to row 193's viewer level. N18, 3.6 names `verifyPrincipal`. N19, the TLS check
+  runs through the public route and from the LAN.
+- r4.2 (mos-1013, morgana-0007): "factory" in R8 and section 8 means every principal outside the hub
+  instance, not only the dragon-lin uid: the dragon-lin dev uid, the Case 1 instance's VM and its agents,
+  and Jason's Hermes agents on W-jarvis. Every R8 check runs from each of their hosts. Hosts are variables
+  until Mos confirms them with Jason. The table rows don't change. Q1 is settled by Q180: P2P is
+  person-to-person. Row 193 calls `covers` with no level for share reads and with
+  `level: 'collaborator'` for create, open, send and share, so `covers` needs no other argument
+  (morgana-0007, row 193 DESIGN.md at 19c015741).
+- r4.1 (mos-1006, gander-0007, morgana-0005): R8's gate adds the identity provider path. A factory
+  credential that can administer the issuer the hub trusts gets in without the host (the B8 bullet below
+  has the rule). Mos accepted the sudo deviation (root ssh
+  and the `authorized_keys` check). Row 196's interface is settled: one verify per one-request
+  connection, `s.user` for that request only, and the walk mutants move to row 196. morgana-0005: grants
+  name bus project ids, and one pure `covers` in R1 matches a grant to a thread (3.5). R4's loss
+  predicate counts only collaborator grants, so a downgrade to viewer ends the run.
+- r4.1 (duckworth-0005): B8, the hub's issuer and TLS front end are in its trust base. The hub trusts
+  only an issuer no factory credential can administer, and TLS ends where the factory can't reach
+  (3.4, R8). A brand, tenant or application in the factory's Authentik doesn't count. N13, the key check
+  is a procedure. N14, R3 consumes row 196's verifier and depends on it. N15, DNS control. mos-1009:
+  section 8 has a table of every privilege path (hypervisor, backups, sign-in provider, TLS front end,
+  certificate authority, DNS, network), each closed by a check or accepted by Jason with set wording.
+- r2.1 (mos-0988): the separate uid is row 190b. R8's gate points at 190b, R7 at row 190 (one uid,
+  scratch). P19 333 is on the 10-27 path (section 8).
+- Mos's rulings in mos-0978 and mos-0984 replace the r1 questions (section 9). The push credential note is
+  in section 10.
+
+## 1. Summary
+
+By 10-27, federation means a person from one instance can sign in to the other instance's Console and use
+exactly what its owner granted: one business, some projects and its thread instance, at the collaborator
+level. The receiving instance verifies that person itself through OIDC (Q175) and its broker enforces the
+grant on every request. Revoking a grant refuses the next request and stops that user's thread runs within
+about 30 s, or at once when the grant CLI makes the change.
+
+Instance-to-instance traffic, where an agent on the factory talks to a role on the hub, waits until after
+10-27 unless Jason rules otherwise (mos-0984 point 3). Section 6 sketches it (Ed25519 instance keys and
+signed HTTP requests) so the 10-27 slice doesn't block it.
+
+## 2. What exists today (measured)
+
+- F1. The bus is a local Unix socket per data root: `socketPath` at packages/cli/src/config.mjs:19, opened
+  at packages/bus/src/runtime.mjs:169. Nothing listens on a network port. No live federation code exists.
+  The PRD lists REQ-FED-1 as post-v1 (packages/tasks/requirements.json:61).
+- F2. A business has exactly one human: `human` at packages/business/src/business.mjs:160.
+  `bindHuman` refuses any other name (packages/bus/src/broker.mjs:532-538).
+- F3. The human proof is a cooperative same-uid process check, not a wall. `verifyHuman` compares the
+  caller's uid, start time, nonce and CLI path (packages/bus/src/human.mjs:52-72), then walks the parents
+  and refuses agent markers, launch records and agent binaries (:73-88). The tester proof refuses only
+  managed runs and allows agents by design (packages/bus/src/tester.mjs:5-9, :56-60). The server takes
+  exactly one of `cap`, `human` or `tester` per request (packages/bus/src/server.mjs:52-70).
+- F4. Authority for agents is checked in the broker: `#checkAuthority` and `#authorityFor`
+  (broker.mjs:763-799), with classification at :596-609. Every one of these is about a role run. Humans
+  get no roles. `#human` (broker.mjs:375-378) is the only human check.
+- F5. Threads have a single `owner` column (packages/bus/schema.sql:247). `#thread` refuses a thread whose
+  owner isn't the caller (broker.mjs:356-362). `#owner` returns `tester` or the human (broker.mjs:364-366).
+  `#threadFor` special-cases the human (:326) and checks reply chains for the tester only (`#testerOwns`,
+  :352-355, called at :337 and :342). `#threadHolders(business, instance, owner)` finds the held runs of
+  one owner's threads (broker.mjs:298-306).
+- F6. The Console reaches the bus as the one human by spawning `human-cli.mjs` per call
+  (packages/webui/src/bus.mjs:1-9, 27-31). Its entry is `packages/webui/src/cli.mjs serve`
+  (scripts/webui-service.sh:3). Its sign-in today trusts a proxy header (Sage's design, section "What exists
+  today"). Q175 replaces that with an OIDC relying party that takes a `subjects` list from a `console.sso`
+  key in config.json (Sage's design sections 1 and 4).
+- F7. config.json is read by one loader that refuses unknown top-level keys
+  (scripts/mosaic-config.mjs:112-116). The business file is writable by agents through
+  `organizationWriter` (packages/business/src/organization.mjs:83), which is why Sage put SSO config in
+  config.json and not the business file.
+- F8. Bus, Discord and Console run as `systemctl --user` units (scripts/bus-service.sh:200), so every
+  instance on a host runs under Jason's uid today.
+- F9. Board reads are per business, not per project or instance: `inbox`, `agents`, `tasks`, `trail` at
+  broker.mjs:2143-2146, `decisions` :2174, `credentials` :2195, `messages` :2217 (the Console's set is
+  views.mjs:3-13). `project.list` returns every project in the business (:2318-2322).
+- F10. The launcher restarts a thread that has pending messages and no holder (packages/cli/src/launcher.mjs:533),
+  launched as the business human (:542), every 2 s (:133). Its `startedFor` guard is in memory. A claim end
+  stops a run only at its next bus call (broker.mjs:2273-2275). The idle stop is the one place that
+  SIGTERMs a thread runner (launcher.mjs:527).
+
+### The archived v1 federation (v1/apps/gateway/src/federation)
+
+What it does: mTLS between gateways with certificates from step-ca. The grant id and subject user id sit
+in custom certificate OIDs (ca.service.ts:22-24). A peer enrolls with a single-use, 15-minute bearer
+token. The guard reads the client certificate off the TLS socket (server/federation-auth.guard.ts:93-106)
+and re-checks the grant row on every request. Scopes are zod-validated resource lists
+(scope-schema.ts:15-99). Shared data is read-only list and get queries.
+
+Verdict: none of the code is reusable here.
+
+1. It is about 4,470 lines of NestJS, Drizzle and Postgres code without tests (9,198 with them), plus a
+   step-ca dependency. The new stack has none of those.
+2. Inbound federation never worked. The guard depends on `requestCert: true`, but the server is built as
+   `new FastifyAdapter({ bodyLimit })` with no TLS options (v1/apps/gateway/src/main.ts:50-53). Every
+   inbound call would get 401.
+3. mTLS is the wrong fit for the homelab path. Traefik terminates TLS in front of the Console (Sage's
+   design, public path). A client certificate would reach the app as a forwarded header, which is the
+   header trust Q175 point 1 rules out.
+
+Ideas worth keeping: re-check the grant on every request, never cache it in the credential. Keep
+enrollment short-lived and single-use. Tag every federated result with its source instance.
+
+## 3. The 10-27 slice
+
+### 3.1 What it must do
+
+1. D1. Each instance names itself and its peers in config.json, so the Console can show "you are on the
+   hub" and link to the factory. Peer entries carry no trust in the 10-27 slice. They are labels and URLs.
+2. D2. The owner of an instance grants a person access to one business, with a project list and an
+   instance list. Grants live in a human-authored access file on the receiving instance.
+3. D3. That person signs in to the receiving instance's Console with OIDC. The Console verifies the token
+   itself (Q175) and matches `(provider, sub)` to an access-file user with a live grant.
+4. D4. The broker, not the Console, enforces the grant on every request: which verbs, which projects,
+   which instances, and which threads (own threads only).
+5. D5. Revoking a grant refuses that user's next request on the Console and on the bus, and ends the runs
+   of that user's threads in that business.
+
+### 3.2 What waits
+
+- W1. Agent-to-agent traffic between instances (section 6).
+- W2. Shared threads between several users (C1.4), and a viewer level. Both are T1.3's. A granted user gets
+  private threads only.
+- W3. Remote owners. A grant never gives owner verbs: organization, instances, routes, plugins, limits,
+  decision resolution, launch revoke and the kill switch stay with the local human.
+- W4. A registry, `mosaic comms`, enrollment tokens and key rotation tooling. With two instances,
+  out-of-band setup by Jason is cheaper.
+- W5. Federated reads that merge results from both instances into one view, and any board read for a
+  granted user (F9).
+
+### 3.3 Instance identity in the slice
+
+An instance is its public HTTPS origin plus its own OIDC client at the provider. The factory and the hub
+are two clients, so their ID tokens carry different `aud` values. The Q175 audience check refuses a
+factory token presented at the hub, which makes tokens instance-bound by signature, not by a header. This
+holds only if the two client ids differ, which R8 checks. No instance key is needed until instances talk
+to each other (W1).
+
+### 3.4 Remote user identity
+
+A user is `(provider, sub)` where `provider` is an id from that instance's `console.sso.providers`. Q175
+already verifies signature, issuer, audience, expiry and nonce, and allows several providers. The hub
+trusts only an issuer that no factory credential can administer (B8, duckworth-0005), for example a
+Pocket ID on the hub's side. Jason then has his own account at that issuer, with a `sub` of its own. A
+separate brand, tenant or application in the factory's Authentik doesn't count: factory agents hold an
+Authentik API token, and whoever administers the issuer can impersonate any user, reset a login or
+repoint a redirect. If Jason wants the hub on the factory's Authentik anyway, that is his decision, of
+the same kind as #419 (section 8). Either way the receiving instance checks the token. It never takes the
+home instance's word for who the user is.
+
+The owner path stays as Sage designed it: `console.sso` subjects sign in as the business human. Everyone
+else comes from the access file. The two lists are disjoint, and the loader refuses a subject in both.
+
+### 3.5 The access file and the collaborator level
+
+`<configDir>/access.json`, next to config.json, so it is per instance (`configDir` at business.mjs:25-28
+reads `MOSAIC_CONFIG`). It is not in config.json for two reasons. Revocation has to take effect without a
+restart, and a typo in config.json stops every tool on the instance (Sage's design, section 4). It is not
+in the business file because agents can write that (F7).
+
+```json
+{
+  "accessVersion": 1,
+  "revision": 3,
+  "users": [
+    { "id": "jason", "home": "factory", "subjects": [{ "provider": "authentik", "sub": "<sub>" }] }
+  ],
+  "grants": [
+    {
+      "id": "g-hub-1",
+      "user": "jason",
+      "business": "creative-hub",
+      "projects": ["*"],
+      "instances": ["researcher"],
+      "level": "collaborator",
+      "expires": "2026-12-31T00:00:00Z"
+    }
+  ]
+}
+```
+
+Rules the loader enforces, refusing the whole file on any failure (fail closed). The loader takes the
+provider ids, peer ids and declared businesses as arguments, so it stays pure:
+
+- The file is a regular file, not a symlink, owned by the instance's uid, with no group or other write.
+  These are the checks Sage's loader runs on the secret slot.
+- Unknown keys refuse. `accessVersion` is 1. `revision` is a positive integer.
+- A user id matches the business id rule and is never `human`, `tester`, or any business's `human`.
+- `subjects[].provider` names a given provider. A `(provider, sub)` pair appears once in the file and
+  never in `console.sso.subjects`.
+- `home` names a given peer, or is `local` for a non-federated extra user.
+- A grant names a declared business. `projects` is `["*"]` or bus project ids, the UUIDs
+  `project.create` makes (broker.mjs:2306). `instances` is
+  `["*"]` or declared instances. `level` is `collaborator`, the only level in 10-27. `expires` is optional
+  ISO time.
+- The loader checks a project entry's shape only (a UUID). It can't see the bus, so an id with no bus
+  project covers nothing.
+- A grant past `expires` is treated as absent.
+- A file that fails any rule leaves every user with no grant, which revokes everything. That is the safe
+  direction.
+
+Matching a grant to a thread (morgana-0005). A thread's `project` is a bus project id
+(`threads.project REFERENCES projects(id)`, packages/bus/schema.sql:245), set by `thread.create`
+(broker.mjs:2329-2345). A bus project may have no repo in the business file, so grants can't name
+business-file projects. They name bus project ids, not names. A name could be taken later: the tester,
+which runs from an agent, can call `project.create` (:2300), and nothing renames or deletes a project
+today. R1 exports one pure function, `covers(grant, { business, project, instance }, now, { level })`.
+It is true when the grant is unexpired, the business matches, `projects` is `["*"]` or holds the
+project id, `instances` is `["*"]` or holds the instance, and the grant's level is the one asked for,
+when one is asked for. The broker passes the thread row. `["*"]` also covers projects made after the
+grant, and the R5 help text says so. R5's `grant --project <name>` resolves the name to the id through
+`project.list` at grant time and writes the id. `mosaic access list` shows both. Row 193 uses the same
+`covers`.
+
+The collaborator level is an exact verb list. Every other verb fails `access-refused` before the verb's own
+checks. That covers all owner verbs (W3), every board read (F9), `message.*`, `decision.*`, project files,
+`spec.read`, `assistant.stop`, `launch.*`, `name.set` and `usage.*`.
+
+| Verb | Today | For a user |
+|---|---|---|
+| `project.list` | every project in the business (:2318-2322) | granted projects only |
+| `thread.create` | the business's one thread instance (:2331-2334) | project granted, and that instance in the grant's `instances`, else `access-refused` |
+| `thread.list` | owner filter (:2351-2362) | owner `user:<id>`, and only threads whose project and instance are still granted |
+| `thread.open` | `#thread` owner check (:2365-2371) | same, plus the thread's project and instance still granted |
+| `thread.send` | `#thread`, sender `human`, writes `human.input` (:2374-2398) | same grant check. Sender `from_role` `user`, `from_run` `user:<id>`, no `human.input` |
+| `thread.messages` | `#thread` (:2401-2420) | same grant check |
+| `names` | business-wide (:2288-2295) | granted instances only |
+
+`human.input` events are the owner's authority evidence (the `input` view, broker.mjs:1203-1207). A user's
+message must never write one, the same rule the tester follows at :2398.
+
+`instances` is the real limit of a grant. The thread instance runs with its full role authority and is
+launched as the business human (F10), so a collaborator's message drives that instance with the owner's
+role. A grant gives a user exactly what the granted instance can do. The grant docs and the R5 help text
+say so.
+
+Writes go through `mosaic access grant` and `revoke` (row R5), atomically with a revision bump and one
+receipt line in `<dataRoot>/state/access-log.jsonl` (append-only, as `activation-log.jsonl` is). The
+CLI checks its caller with the human proof, but a direct file write by the instance's uid skips both the
+CLI and the receipt. The separate host keeps other instances' processes from making that write, but
+factory agents keep ssh to .54 (Q183), so one with a login there can make it. R8 records that as
+accepted (section 8). Jason may also edit the file by hand.
+
+### 3.6 The user principal in the broker
+
+The bar (B1, mos-0984 point 1): a bus user principal comes only from something the bus can verify. Here
+that is the Console's verified OIDC session, reached through a proof the bus checks itself. The calling
+process's claim alone isn't enough, and neither is a proof that admits agent ancestry.
+
+The proof. Row 196 (#1694, Gander) builds this check as the `user` kind of its shared `verifyPrincipal`,
+and R3 consumes it (section 5). The checks are the ones below. A new path-bound CLI, `packages/bus/src/user-cli.mjs`, with its own nonce variable
+(`MOSAIC_BUS_USER_NONCE`), so neither of the other CLIs' nonces proves it. The bus checks it with
+the `user` kind of row 196's `verifyPrincipal`, which:
+
+1. Runs `verifyHuman`'s checks with `cliPath` set to the bus's own `user-cli.mjs`: same uid as the bus,
+   start time, nonce, CLI path, and the parent walk that refuses agent markers, launch records and agent
+   binaries (human.mjs:64-96).
+2. Also requires the user CLI's direct parent to be the Console from the bus's own tree: `argv[1]` equals
+   the bus's resolved `packages/webui/src/cli.mjs`, and `argv[2]` is `serve`. This binds the user CLI to
+   the Console's tree, as #225 binds `human-cli` to its literal path.
+3. Takes `user` from the proof and binds it only if the access file gives that user a live grant in the
+   proof's business. Otherwise `access-revoked`.
+
+So the claim "I am user jason" comes from a process the bus has verified as its own Console, outside any
+agent. The Console makes that claim only after Q175 verified the ID token's signature, issuer, audience,
+expiry and nonce and mapped `(provider, sub)` to the user.
+
+This needs the path-bound human proof, P19 333. Residual risk, stated as Sage's design section 8 states it
+for the owner. The proof is a cooperative same-uid check. A non-agent process on the instance's uid, a
+shell Jason opens for example, can start its own copy of the Console's tree from the bus's path and claim
+any granted user. So can anything that can ptrace or write files as that uid. The walk refuses an agent
+in its normal process tree, but an unsandboxed agent on the same uid can get past it by starting the
+Console through `systemd-run --user` or by daemonizing so its parent chain ends at pid 1. That is the same
+hole the owner proof has (P19 333), not a new one. Other instances can't: the 10-27 hub runs on its own host, so its bus
+isn't on their host at all. Factory agents keep ssh to .54 and root on pve (Q183), so the host form doesn't stop them, and R8 records that as accepted (section 8). Federation adds no weaker path than the owner's.
+
+The broker changes, each with an R3 test:
+
+1. `bindUser({ business, user })` makes a session with `s.user` set and `s.human` and `s.tester` unset.
+2. `#owner(s)` (:364-366) returns `user:<id>` for a user session. Today it would return undefined.
+3. `#threadFor` (:318-345) refuses a user session with `thread-required-use-thread-send`, as it refuses
+   the human at :326. `message.send` is also off the verb list. Two walls, so a reply-chain send into
+   another user's thread fails even if one is removed (R3 mutant).
+4. The `if (!s.tester) this.#human(s)` gates on the six project and thread verbs above become a check
+   that admits the human, the tester, or a user with a live grant. `names` gates differently, with
+   `if (!s.human && !s.tester) this.#agent(s)` (:2290), so there the user branch goes before the `#agent`
+   fall-through, or a user session fails `#agent`.
+5. Every other `s.human` and `s.tester` branch (48 and 41 in broker.mjs) gets an audit line in R3's
+   packet: user refused, user treated as human, or not reachable for a user. Since every non-list verb
+   fails first, most are "not reachable", and the audit shows it.
+6. `refuse()` records `action.refused` for every refusal (broker.mjs:526-530), with `by` = `user:<id>`.
+7. The reply path (B6). The runner answers each message with `message.send { to: m.from_role }`
+   (packages/harness/src/runner.mjs:450), and today the broker accepts only `human`, `tester` or a role as
+   `to` (broker.mjs:1862). A user's message has `from_role` `user`, so without this every reply fails
+   `unknown-role`. The broker accepts `to: 'user'` from a run only when all of these hold, else
+   `user-reply-required`:
+   - `in_reply_to` names a message with `from_role` `user` in this business,
+   - that message's `from_run` is `user:<id>` and `user:<id>` owns the run's thread,
+   - the message is in that thread (`message_threads`).
+
+   This is the tester rule at :1852-1857, narrowed to one user and one thread. A `#userThread(s)` beside
+   `#testerThread` (:631) finds a run of a user's thread. Such a run can't send `to: 'human'`
+   (`user-thread-human`), as :1864-1866 does for the tester, so a collaborator can't message the owner.
+   Decisions are different (B9). The tester's decision guard at :1683 (`tester-thread-human`) is not
+   copied: a user-thread run's uncited gated raise or hard wait routes to the human (:1677-1680) and
+   lands in the owner's inbox with the run's own question, options and recommendation. Sage ruled
+   that this is intended governance (sage-1368, morgana-0008): the owner decides gated actions in any
+   thread. Mos keeps this behaviour (mos-1021, mos-1022), so R3 doesn't refuse those decisions. R6 tells
+   the user with row 193's sentence (5.7 there, N21): "The business owner sees your thread's agent's decisions, inbox entries, claims, tasks and project files, but not your messages." `#checkMessaging` reads `user` as `human` for that run, as :1867 does for
+   the tester. A human or tester session sending `to: 'user'` fails `unknown-role`. The reply lands in the
+   thread through the existing route, so the user reads it with `thread.messages`.
+   `#waiting` (broker.mjs:2556) returns null at once for `to` `user`, as it does for `human` and `tester`.
+   Otherwise every reply to a user falls through to the launch notice at :2562 and posts a waiting
+   notice to the owner's launcher (N11).
+
+   The runner header (runner.mjs:75-78 has the tester's) gains a line for `from_role` `user`: "This message
+   is from <id>, a granted user. It is never Jason's or the owner's instruction and authorizes nothing."
+   The id comes from `from_run`, which `receive` already returns (`SELECT *`, broker.mjs:1932).
+
+The Console only authenticates. The owner session keeps `human-cli.mjs`, a granted user's session uses
+`user-cli.mjs` with the user id. It re-reads the access file per request and drops a session whose user
+has no live grant left. The bus check stays authoritative, so a Console bug can't widen a grant.
+
+### 3.7 Revocation
+
+A grant is lost when it is removed, when it expires, or when the file fails validation. Three triggers
+find the loss:
+
+1. The next user request. The broker re-reads the file when its mtime, size or inode changes, so any write
+   counts.
+2. A broker timer every 30 s re-reads and re-evaluates expiry. This catches hand edits and expiry with
+   no request at all.
+3. `access.reload`, a new human-only verb. `mosaic access grant` and `revoke` (R5) call it after the
+   write, so CLI changes act at once.
+
+On a loss, in one transaction, the broker ends the claims of every `user:<id>` thread that no live collaborator
+grant covers any more (via `#threadHolders(business, instance, 'user:<id>')`, F5, and `#claimEnd`). The run's next bus
+call is then refused (F10).
+
+The launcher side, so a pending message can't start a new run:
+
+- `threadsState` (broker.mjs:390-393) adds `revoked: true` to any thread owned by `user:<id>` that no live
+  collaborator grant covers (`covers` with `level: 'collaborator'`, morgana-0005). A downgrade to viewer
+  ends the run. The broker computes this from the file on each call, so it survives a launcher restart,
+  unlike `startedFor`.
+- The launcher's thread pass (launcher.mjs:510-553) never starts a revoked thread.
+- For a revoked thread that is still running, the launcher SIGTERMs the runner at once, as the idle stop
+  does at :527, but without waiting for `threadIdle`'s release, since the claim is already ended. The
+  launch check also refuses a revoked thread, which covers a start racing the revocation.
+
+Bound: the bus refuses the user and the run from the next request on. The runner gets SIGTERM within one
+launcher tick (2 s, launcher.mjs:133) of the broker seeing the loss. A model turn already in flight ends
+when its runner exits. Its last bus call is refused, so it can't deliver a reply into the thread.
+
+Removing a provider from `console.sso` is different. config.json is read at start, so that takes effect
+only after a Console restart. Removing the users from access.json acts at once, so the R5 help text says to
+do that first.
+
+### 3.8 One host or two (mos-0991)
+
+For 10-27 the hub runs on .54, VM 1012, as user `mosaic` (Q181), a host of its own (mos-0996).
+Jason (mos-1013): dragon-lin is his workstation and won't host the final instances, and both cases run
+as VMs on the PVE node. Jason confirmed the hosts (DECISIONS Q181, mos-1030). The Case 1 instance is on W-jarvis,
+10.1.1.53 (VM 1008), and the hub, Case 2, is W-Melanie-OC, 10.1.1.54 (VM 1012). The hub's OS user is
+`mosaic`, a system user with no sudo, no groups and no keys (Vikunja #421).
+It is a PVE VM, and Jason accepted the factory's paths to it (Q182, Q183, section 8). The federation path
+assumes nothing about sharing a host:
+
+- Nothing crosses between the instances' buses or filesystems. Each Console talks only to its own bus
+  through `user-cli` or `human-cli`, spawned on its own host. access.json lives in the receiving
+  instance's config dir. `federation.peers` holds URLs and labels, never a path or a socket. No row reads
+  a peer's file or socket.
+- In the 10-27 slice the two Consoles never call each other. The user's browser reaches each origin, and a
+  peer link is a plain link. Section 6 does need each Console's origin reachable from the other host, so
+  R8 checks that now and the later rows add no infra.
+- Each instance has its own OIDC client with its own redirect URI on its own origin (3.3). Each Console
+  must reach its provider's issuer and JWKS from its own host. The issuer is a privilege path too. Whoever administers it can mint a hub user, so
+  the hub's issuer is one the factory can't administer (3.4, R8). The factory's Console reaches its own
+  Authentik, and the hub's reaches its own issuer.
+- Q175 checks token expiry, and section 6 has a 60 s window on signed requests, so both hosts need a synced
+  clock.
+
+The only one-host piece is R7, which is scratch on one host by design (row 190). The uid form of R8's gate
+(row 190b) is a later option, outside the 10-27 gate.
+
+## 4. Fit with the current code
+
+- The bus stays a local socket. Federation reaches it only through the receiving instance's Console, which
+  is the one network-facing piece. No row opens a bus port.
+- The broker's agent authority path (broker.mjs:763-799) is untouched. User checks are a separate path,
+  next to `#human`, because humans have no role claim and `#agent` would refuse them (broker.mjs:367-374).
+- New ownership code is small but real: `#owner`, `#threadFor`, the seven verb gates, `thread.send`'s
+  sender fields and `threadsState` (3.6, 3.7).
+- The business file keeps one `human`. Granted users sit outside it, which keeps every existing
+  business-file test and the organization writer unchanged.
+- The config loader gains one optional key, `federation`, in the same file Sage's phase 1 changes
+  (mosaic-config.mjs:112-116). Row R2 chains on that candidate and repeats its blast-radius rule: the key
+  goes in only after a copy that accepts it is pinned.
+
+```json
+"federation": {
+  "self": "hub",
+  "peers": [{ "id": "factory", "origin": "https://mosaic.woltje.com", "label": "Software factory" }]
+}
+```
+
+## 5. Dependencies on T1
+
+- T1.1, several instances per host (mos-0988). Row 190 (Darkwing) lands several instances on one uid,
+  for scratch tests. R7 runs on that. Row 190b (Darkwing, Opus, design first, chained on 190) puts the hub
+  under its own Linux user, with no factory process able to touch it (mos-0986). Rows R1 to R7 don't need
+  190b: they use separate `MOSAIC_CONFIG` files and data roots, which the code already honours
+  (business.mjs:25-28). For 10-27, R8's gate is the host form only (mos-0996), so 190b is a later
+  option, not an R8 dependency. With per-uid instances,
+  a factory-uid process can't read or write the hub's access.json or data root, and it can't pass the
+  hub's human or user proof, because `verifyHuman` requires the caller's uid to equal the bus's
+  (human.mjs:67). Inside one instance the proofs stay same-uid cooperative (3.6, P19 333).
+  The design doesn't plan a single-uid live run.
+- A separate host (mos-0991, mos-0996). The hub runs on its own host, which R8 checks and records (section 7,
+  3.8). It is a PVE VM, with the factory paths accepted by Jason (Q182, Q183, section 8).
+  mos-0996 measured why the other hosts fail: on dragon-lin `sudo -n true` succeeds for jwoltje, and
+  Melanie's server takes `ssh -o BatchMode=yes` from here with passwordless sudo behind it.
+- Row 196 (#1694, Gander) owns the bus human boundary before R3 (gander-0006): one shared verifier,
+  `verifyPrincipal(request, connection)` returning `{kind, business, id}`, with `SO_PEERCRED` binding
+  `proof.pid` to the connection. R3 consumes it for the `user` kind instead of writing its own
+  `verifyUser`, with the same checks as 3.6 (human walk, direct parent the bus tree's Console `serve`,
+  own nonce variable). It runs once for each one-request connection, and `s.user` holds for that
+  request only, with no role or grant cached (gander-0007). R3 owns every live grant check, the
+  `(provider, sub)` to user mapping and the user-name policy. Row 196 kills the agent-parent,
+  non-Console-parent and kind-confusion mutants. R3 keeps the reserved user-name mutant.
+- T1.1 live also needs two Consoles, two public origins, two reverse-proxy routes and two provider
+  clients, which are Jason-gated infra.
+- T1.2, #412 SSO. Hard dependency. Row R6 builds on Sage's phase 1 candidate (Q177 merge-chaining) and
+  goes live only after the phase 2 window.
+- T1.3, human users and RBAC. One user and grant model for local and federated humans (mos-0978 Q2).
+  Row 193 (Morgana) confirmed access.json as that store (morgana-0002, section 9 Q2). T1.3 adds `local`
+  users, the viewer level and `thread_shares`, and federation adds `home`. R1 is the shared loader, so row
+  193 builds on R1's candidate.
+
+## 6. After 10-27: instance-to-instance
+
+Sketch only, so the slice doesn't block it. If Jason puts agent-to-agent inside 10-27 (mos-0984 point 3),
+rows for it are added after r2.
+
+- Each instance gets an Ed25519 key in a secrets slot (`~/.config/mosaic-dev/secrets/<instance>/`, 0600,
+  per the Q173 slot rule). Peers pin each other's public keys in `federation.peers[].keys`. Public keys are
+  not secrets.
+- Requests between instances are signed with HTTP Message Signatures (RFC 9421) over method, target URI,
+  authority, content digest, created time and a nonce. The receiving Console verifies the signature
+  itself, so the proof survives Traefik. A created time outside 60 s or a reused nonce refuses. No shared
+  secret, no bearer token.
+- A peer agent becomes a grant subject of kind `peer` (`factory/researcher`), in the same access file, so
+  grant and revoke work the same way. Removing a peer key refuses all of that peer's traffic at once.
+- First use: a factory agent sends a message into a hub thread it was granted, owned by `peer:factory`.
+
+## 7. Rows
+
+Owner model per Q177 and Q178. Opus 5.5 for hard design and builds, Haiku 5.5 at high effort for mid work,
+Codex gpt-6.1-sol for parallel builds. Every row has its own independent review (Filbert or Dewey) and
+gate. Chains follow Q177: a dependent row builds on its parent's candidate.
+
+| Row | Work | Owner model | Depends on | Test gate |
+|---|---|---|---|---|
+| R1 | `packages/business/src/access.mjs`: access.json loader and validator. Providers, peers and businesses come in as arguments. One read plus the file checks | Codex Sol | none | business tests: every rule in 3.5 refuses with the key path named, symlink, non-regular file, other owner, group or other write, expiry, `*`, disjoint from the given subjects, `human`/`tester` ids, a level other than `collaborator`, a project entry that isn't a UUID. `covers`: `*` and listed ids match, an unlisted project, instance or business doesn't, an expired grant doesn't, a level filter rejects another level |
+| R2 | `federation` key in scripts/mosaic-config.mjs | Haiku 5.5 high | Sage #412 phase 1 candidate | test-config.sh: valid key loads, unknown sub-key and bad origin refuse, config without it loads |
+| R5 | `mosaic access list, grant, revoke`: human proof, atomic write, revision bump, receipt line. Help text states the `instances` limit and the provider-removal order | Haiku 5.5 high | R1 | cli tests: tester and agent callers refused, concurrent write refuses on revision conflict, receipt appended, bad grant refused before write |
+| R3 | Broker user principal: consumes row 196's `verifyPrincipal` (`user` kind, `user-cli.mjs`), `bindUser`, the 3.6 changes, the collaborator verb list and its filters, per-request grant read, audit lines for every `s.human`/`s.tester` branch | Opus 5.5 | R1, row 196 | bus tests: each listed verb allowed, every other verb refused, a leak test per listed read (other projects, other instances, other users' threads), a reply-chain `message.send` into another user's thread refused, `thread.send` writes no `human.input`, the run's reply to a user's message reaches that user's `thread.messages`, a reply `to: 'user'` without a matching `in_reply_to` refused, a user-thread run sending `to: 'human'` refused, a reply to a user returns `waiting` null and posts no notice message, a user-thread run's uncited gated raise reaches the owner's inbox and no other inbox or role, while its `message.send` `to: 'human'` is still refused (B9, mos-1022), revoked and expired grant refused on next request, refusals recorded. Mutants (the agent-parent, non-Console-parent and kind-confusion mutants are row 196's): the grant read skipped, a read filter dropped, `#threadFor`'s user refusal removed, the reply-to check dropped (a run answers another user's message or one outside its thread), a user named like the human accepted |
+| R4 | Revocation: 30 s timer, `access.reload` verb, claim end on loss, `threadsState` `revoked`, launcher skip and SIGTERM, launch check refusal, R5 calls `access.reload` | Codex Sol | R3, R5, row 193's viewer level (mos-1019) | bus and launcher tests, each with a mutant: a hand edit removing the grant ends the run within one timer period, an expiry with no request ends it, a pending message followed by a launcher restart starts no run, a running revoked thread gets SIGTERM, a grant downgraded to viewer counts as a loss, another user's runs stay. R4 starts after row 193's viewer level lands, because before it R1 refuses any other level, the whole file fails, and the downgrade test can't kill its mutant (N17, mos-1020) |
+| R6 | Console: granted-user sign-in, `user-cli` transport per session, per-request grant re-read, owner-only controls hidden, a notice on the user's thread page with row 193's sentence word for word (B9, N21): "The business owner sees your thread's agent's decisions, inbox entries, claims, tasks and project files, but not your messages.", peer links | Opus 5.5 | Sage #412 phase 1, R1, R2, R3 | webui tests on Sage's fake OP: granted user signs in, ungranted `sub` refused, revoked mid-session gets 401 on next call, a granted user's owner-verb call refused by the bus even with the UI check removed (mutant), the thread page's notice equals row 193's sentence exactly (N21) |
+| R7 | Scratch two-instance acceptance: two configs, two data roots, two Consoles, one fake OP. The Consoles start outside agent ancestry (a transient user unit), as the user proof requires. They never use the live stack's units or ports | Haiku 5.5 high | R1-R6, row 190 (several instances on one uid) | script test: Jason granted collaborator on one hub project signs in to the hub, makes a thread, sends to the granted instance, gets the instance's reply in the thread, is refused on another project and on board reads, is revoked and gets refused with the run ended. The factory shows nothing of the hub |
+| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the Case 2 install on .54 (#416), Bean and Chet live and both Hermes gateways on .54 stopped (mos-1042), #412 phase 2, R7 | Host form only for 10-27 (mos-0996): the hub runs on .54, VM 1012, as user `mosaic` (Q181). R8 is a recorded acceptance (mos-1055). It starts with Jason's acceptance of the factory paths to .54 on record, DECISIONS Q182 and Q183, quoted in section 8. Every privilege and host check below still runs, and its result goes into the R8 record with the name of whoever ran it. They report and don't refuse. R8 runs after Bean and Chet are live and both Hermes gateways on .54 have stopped (mos-1042). Case 2 go-live doesn't wait on R8. The hub is W-Melanie-OC, 10.1.1.54 (VM 1012), and its OS user is `mosaic`, with no sudo, no groups and no keys (Q181, Q183). R8 checks that on 10.1.1.54 as root and records whether each holds: `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 it (N22). An agent or Jason runs these as localadmin (mos-1055), and the output goes into the R8 record with who ran them. The privilege checks run on every factory host in section 8's list (the dragon-lin dev uid, and W-jarvis at 10.1.1.53, which is the Case 1 VM with its agents and the Hermes agents), as each factory uid there under `env -i`, and each is recorded as passing only when the call fails: `sudo -n true`, `doas -n true`, and `ssh -o BatchMode=yes 10.1.1.54 true` as the hub user `mosaic`, as Jason's user and as root, each with and without the session's `SSH_AUTH_SOCK`. If `sudo -n` succeeds, as it does for jwoltje on dragon-lin (mos-0996 point 1), the factory counts as root on its own host. Then, as root through `sudo -n`: fingerprint every private key under every home and `/root`, and every key loaded in any agent socket found on the host (`ssh-add -l` per socket). Compare them with `ssh-keygen -lf` over every `authorized_keys` on the hub host, root's included, and no fingerprint matches. Run the ssh checks as root, once with no agent socket and once with each socket found, and record each result (N13). Every other privilege path is a named item in section 8's table (mos-1009): hypervisor, backups, sign-in provider, TLS front end, certificate authority, DNS and network. The record marks each one closed, with its check passing, or accepted under Q182 and Q183 with the table's wording. That wording goes to Melanie through Jason (#419), never to her directly. R8 also records whether the hub host's bus socket, data root and config dir don't exist on any factory host, no factory host mounts anything of the hub's, and whether the hub host runs no other instance or agent. These must work, or R8 stops and Mos takes it to Jason, because federation fails without them: the two provider client ids differ, each origin answers over HTTPS from the other host, each Console reaches its issuer's discovery URL, and both clocks are synced. The record holds Jason's acceptance and the check results side by side, so a passing check is a measured fact and an accepted path is named as accepted. The uid form (row 190b) is a later option, outside this gate. Then Jason signs in to the hub from his account and sends one message, Melanie revokes, and his next request is refused |
+
+R1 can start now. R5 can be briefed now against R1's exported interface and lands after R1. R2 starts
+when Sage's #412 phase 1 candidate exists. R3 starts when R1 has a candidate, R4 when R3, R5 and row 193's viewer level do (mos-1019).
+R6 waits on Sage's phase 1 candidate.
+
+## 8. Risk to 10-27
+
+The slice lands only if three things hold. #412 phase 1 has a reviewed candidate by about 10-23. P19 333,
+the path-bound human proof R3 depends on, is settled in time for R3 (Mos told Sage, mos-0988). The Case 2
+install on .54 (#416) is done in time for R8. Jason's answer on the factory paths is Q182 and Q183. R6 and R7 chain on #412 phase 1. R8 needs all three, plus
+two Jason-gated windows (#412 phase 2 and the federation re-pin), plus infra work only Jason does: a
+second public origin, a proxy route and a provider client. A failed privilege check
+doesn't stop R8. It goes into the record, and Mos takes it to Jason.
+
+The hypervisor path (Vikunja #419, mos-1004), accepted by Jason under Q182 and Q183. Factory agents hold root
+ssh to the PVE nodes (Q172). Root on a node can read a running VM's memory and disk, open its console,
+and change its config or boot. So it defeats the host form completely when the hub is a cluster VM
+(duckworth-0004). LUKS inside the VM doesn't close it alone: the key sits in the running VM's memory,
+which the node can read, and a node that can change the boot can capture the passphrase. Options:
+
+- O1. The hub runs on hardware outside the PVE cluster, where the factory has no root.
+- O2. A cluster VM, with factory root ssh removed on every node, no factory PVE token with console,
+  monitor, config, backup or snapshot rights on the VM, VM storage the factory can't read, and PBS
+  backups the factory can't read or that are encrypted with a key it doesn't hold.
+- O3. Jason accepts it as a residual. Then this section and R8 say plainly that the host form doesn't
+  stop a factory agent using PVE root, and Melanie is told.
+
+Jason's answer is O3, accepted (DECISIONS Q183 confirms Q4). His lines, verbatim:
+
+Q182 (DECISIONS.md:1514-1519, jason-master-restart):
+
+> "I am not pursuing a tightening of key and agent security on my workstation. I need my agents to be able to get onto the other workstations and servers."
+
+> "We will eventually have my agents running on my VM on PVE, but currently I accept the risk of agents running on my workstation."
+
+Q183 (DECISIONS.md:1535-1541):
+
+> "Security tightening on .53 and .54 is fine. 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."
+
+> "Q4 appears to properly reflect my statements."
+
+Q4, as Mos asked it and Jason confirmed it:
+
+> "The #421 plan stops. Your key stays, and agents keep root on pve and PBS and ssh to .53 and .54. Each VM still gets a mosaic user without sudo to run its instance. The federation gate records your acceptance instead of refusing to start."
+
+So this section and R8 say it plainly: the host form doesn't stop a factory agent using PVE root, and
+R8 records that as accepted. Melanie is told through Jason (#419).
+
+### R8 privilege paths (mos-1009, duckworth-0005, Vikunja #419)
+
+Here and in R8, "factory" means every principal outside the hub instance (mos-1013), and "factory
+host" means each of their hosts:
+
+- the dragon-lin dev uid, on Jason's workstation
+- W-jarvis, 10.1.1.53 (VM 1008): the Case 1 instance's VM and its agents, and Jason's Hermes agents.
+  ops-01 reports the `jarvis@w-jarvis` key has root on `pve`.
+
+Case 1 and the Hermes agents share W-jarvis, so they are one factory host (Q181, mos-1030). The hub is
+W-Melanie-OC, 10.1.1.54 (VM 1012). Every check in the
+table runs on each factory host, and a path is closed only when it passes on all of them.
+
+ops-01 measured the estate read-only at 19:10Z (relayed in mos-1009). There is one PVE node, `pve`,
+standalone, and its root `authorized_keys` holds the factory's key (dragon-lin's, and per mos-1013
+the `jarvis@w-jarvis` key), so the factory has root on the
+hypervisor without any API token. The only PBS is VM 1021 on that node, the factory has root on it, and
+its backups are unencrypted. The LAN is flat (10.1.0.0/16) with dragon-lin on it and no internal VLAN.
+The factory has used the jarvis Authentik token for admin changes. No hardware outside PVE without
+factory root has been confirmed. So today the factory administers every path below.
+
+Each path is a record item. Its check runs and the result is recorded. A path is closed when its check
+passes. Otherwise it is accepted under Q182 and Q183, and its wording goes into the R8 record and to
+Melanie through Jason (#419). Every check runs from the factory
+host, as root through `sudo -n` where the factory has it, and passes only when the call fails.
+
+| Path | Closed: the check | Accepted: the wording | Hub-local option |
+|---|---|---|---|
+| Host access | The R8 sudo, doas, ssh and key checks (section 7, N13) | "Factory agents can log in to the hub host." | none needed, the checks can pass today |
+| Hypervisor | O1 or O2 above: no factory key in any PVE node's root `authorized_keys`, and a PVE API call on the hub VM fails with each token the factory holds | "Factory agents have root on the machine the hub runs on and can read its memory and disk." | O1, hardware outside PVE |
+| Backups | The hub's backups are encrypted with a key only Jason or Melanie holds: the PBS datastore shows the hub's snapshots encrypted, and the key's fingerprint matches no file on the factory host | "Factory agents can read the hub's backups in full." | client-side encrypted backups, key held by Jason or Melanie |
+| Sign-in provider (B8, mos-1006) | The hub's `console.sso` trusts only an issuer no factory credential administers, never a brand, tenant or application in the factory's Authentik. An admin API call on it fails with each identity provider token found on the factory host, and the issuer's list of admin tokens and service accounts (names only, never values) shows none held on the factory. An issuer that isn't on the hub host passes the host-access, hypervisor and backups rows itself, run against its own host, and a hosted issuer's admin accounts each pass the failed-call check (duckworth-0007) | "Anyone with admin on the factory's sign-in provider can sign in to the hub as any user, Melanie included." | an issuer on the hub host, such as Pocket ID (Q175 supports several providers) |
+| TLS front end (B8) | TLS for the hub's origin ends on the hub host: the certificate the origin serves, fetched both through the public route and from the LAN (N19), matches the key on the hub host, and no factory proxy, tunnel or overlay route names the hub's origin | "The factory's proxy sees every hub sign-in, cookie and message in clear." | TLS ending on the hub host |
+| Certificate authority (mos-1009) | The hub's certificate comes from a public CA through an ACME account whose key is only on the hub host, and the zone's CAA record names only that CA | "The factory can get a valid certificate for the hub's name." | ACME run on the hub host |
+| DNS (N15) | A zone edit for the hub's name fails with each DNS credential found on the factory host, and the zone's owner account is one the factory can't sign in to | "The factory can point the hub's name at a host it runs." | a zone or registrar account only Jason or Melanie holds |
+| Network | From the factory host, the hub host answers only on the ports R8 needs (HTTPS, and ssh where it is used), and nothing else is open to the LAN | "The hub host sits on the same flat LAN as the factory, and only its logins protect it." | a host firewall on the hub, a separate VLAN |
+
+Some paths depend on others. While the hypervisor row is open, every secret on a PVE guest is exposed to
+node root: the TLS key, the ACME account key, an issuer's database and signing key on a guest, and the
+backup key whenever a restore loads it (N16). So closing those rows doesn't help until the hypervisor
+row is closed too, or they sit on hardware outside PVE. The R8 record names every path that stays accepted.
+
+## 9. Rulings (mos-0978, mos-0984, mos-0991, mos-0996, mos-1004, mos-1006, mos-1009, mos-1013)
+
+1. Q1: human cross-access is the 10-27 slice (mos-0978). Duckworth's N8 put agent-to-agent's timing to
+   Jason through Mos. Jason answered "P2P federation is acceptable for 10-27" (mos-0991), and then "P2P is
+   person-to-person in this case" (DECISIONS Q180, mos-1013). The slice is human access only, with no
+   agent-to-agent rows.
+2. Q2, settled by row 193 (morgana-0002, to Sage too): access.json is the one user and grant store for
+   humans. Row 193 adds `home: "local"` users, uses the grant level as the human role, and keeps viewer and
+   collaborator. The owner stays outside the file. Thread shares go in a new append-only bus table,
+   `thread_shares`, not in access.json, and a share counts only while the named user's live grant covers
+   the thread's project and instance. The 10-27 slice ships collaborator only (W2), so when row 193 adds
+   viewer, R1's level check widens with it. `thread_shares` is append-only, so an unshare is an end row in
+   row 193's design. R3 assumes nothing about shares (N12).
+3. Q3 and B5: R8 never runs on a single uid (mos-0984 point 2). For 10-27 its isolation is the hub's own host,
+   .54 (Q181), the host form only (mos-0996). The uid form (row 190b) is a later option. Jason accepted
+   the factory paths, the hypervisor's included (Q182, Q183), so R8 records them (section 8).
+
+## 10. Notes
+
+- The r1 push used the repo-local credential helper `scripts/git-credential-mosaic.mjs` (set in the
+  canonical checkout's .git/config for git.mosaicstack.dev) with its default credential file,
+  `~/secrets/mosaic.gitea.json`, and no `MOSAIC_GITEA_CREDENTIAL_FILE` override. That file's user is
+  jason.woltje. The r2 push uses the same. Gizmoduck has no seat identity until T1 row 195 adds per-agent
+  git identity.

docs/SESSIONS.md

@@ -1357,3 +1357,21 @@ are never rewritten or removed; corrections are new entries.
 2026-10-20T15:26:33Z | Sage (Opus 5.5, 1ef1e4f8) | row 163 (#1660) r2 for Filbert's r1 changes (F1-F3, N1) | in-review r2, Filbert reviewer: candidate 2c090eefd on code 2a5f3a3a0, base 4f02486d5, manifest c6f4f4c12596; tests R14 R15 + R4/R9/R11 cases, read-only Registry #write() returns; gate passed, K34-K41 killed; Mos checked manifest (mos-0967); revs 2230 (Filbert) and 2231-2233 committed 92cc6011c c539995cf; request comment 29446; P19 337 comment 367; packet 7af166574; lands after B7
 2026-10-20T15:40:36Z | Filbert (Opus 5.5, 048f3c63) | row 163 r2 review (D2 rehearse, candidate 2c090eefd, manifest c6f4f4c12596) | approve, comment 29447 rev 2234: 249/249 singles pass; my M1-M6 and N1 mutants all killed (R14, R9, R11, R4, R15, session test)
 2026-10-20T15:42:00Z | Sage (Opus 5.5, 1ef1e4f8) | row 163 (#1660) r2 verdict intake | approved by Filbert (comment 29447, rev 2234 committed cd2b377bb); P19 337 comment 367 -> 368; candidate 2c090eefd manifest c6f4f4c12596 waits to land after B7, fresh gate if the base moves
+2026-10-20T18:44:50Z | Gizmoduck (Opus 5.5) | T3 federation design r1 for Vikunja #414 (G3, G4, C1.1), agents/gizmoduck/work/federation/DESIGN.md, on branch gizmoduck/federation-design off origin/refactor 9ae8c73ac | design committed and pushed; rows R1-R8 wait for Filbert or Dewey review before Sage's queue; Q1-Q3 to Mos
+2026-10-20T18:56:54Z | Gizmoduck (Opus 5.5) | T3 federation design r2 for Vikunja #414, answering Duckworth's B1-B5 and N1-N9 (duckworth-0001) and Mos's mos-0978 and mos-0984 rulings, agents/gizmoduck/work/federation/DESIGN.md | r2 committed and pushed on gizmoduck/federation-design; sent to Duckworth and Mos for re-review; R1, R2, R5 wait for Duckworth's approval before Sage's queue
+2026-10-20T18:58:23Z | Gizmoduck (Opus 5.5) | T3 federation design r2.1 for Vikunja #414, mos-0988: R8 uid gate on row 190b, R7 on row 190, P19 333 in the risk | committed and pushed on gizmoduck/federation-design; Duckworth's r2 verdict pending
+2026-10-20T19:00:18Z | Gizmoduck (Opus 5.5) | T3 federation design r3 for Vikunja #414, answering duckworth-0002 B6 (user reply path), C1 and N10 | committed and pushed on gizmoduck/federation-design; sent to Duckworth for approval on the diff
+2026-10-20T19:01:43Z | Gizmoduck (Opus 5.5) | T3 federation design r3.1 for Vikunja #414, mos-0991 (R8 gate accepts a separate host or uid, one-host audit 3.8, Q1 answer) and morgana-0002 (Q2 settled, access.json is the human store) | committed and pushed on gizmoduck/federation-design; sent to Duckworth with r3
+2026-10-20T19:04:18Z | Gizmoduck (Opus 5.5) | T3 federation design r4 for Vikunja #414, answering duckworth-0003 B7 (privilege paths in R8's gate), N11 (#waiting for user replies), N12 | committed and pushed on gizmoduck/federation-design; sent to Duckworth
+2026-10-20T19:08:20Z | Gizmoduck (Opus 5.5) | Correction to the 19:04:18Z line: commit 04a6112be carried only that SESSIONS line, because the DESIGN.md edit script failed on an anchor and the chain still committed and pushed, and nothing went to Duckworth then. r4 proper: B7 per mos-0996 and mos-1004 (host form only, sudo, doas and ssh checks, hypervisor path an open R8 item with O1 to O3 on Vikunja #419), N11, N12, row 196 verifier noted per gander-0006 | committed and pushed on gizmoduck/federation-design; sent to Duckworth and Mos, reply to Gander
+2026-10-20T19:12:55Z | Gizmoduck (Opus 5.5) | T3 federation design r4.1 for Vikunja #414: B8 (duckworth-0005, issuer and TLS front end), N13 key procedure, N14 R3 on row 196, N15 DNS; mos-1006 (identity provider path, sudo deviation accepted); mos-1009 (privilege path table, each closed or accepted per #419); gander-0007 (verifier interface); morgana-0005 (grants name bus project ids, one covers in R1, R4 counts collaborator grants only) | committed and pushed on gizmoduck/federation-design; sent to Duckworth, copies to Mos, Morgana and Gander
+| 2026-10-20T19:16:08Z | Gizmoduck | T3 federation design r4.2 for #414 (mos-1013, morgana-0007) | factory means every principal outside the hub instance, hosts as variables, Q180 settles Q1 |
+| 2026-10-20T19:16:56Z | Gizmoduck | T3 federation design r4.3 for #414 (duckworth-0007) | B8 issuer host passes host-access, hypervisor and backups rows, N16-N19 |
+| 2026-10-20T19:17:11Z | Gizmoduck | T3 federation design r4.4 for #414 (mos-1020) | R4 chained after row 193's viewer level, keeps the level-loss test (N17) |
+| 2026-10-20T19:20:55Z | Gizmoduck | T3 federation design r4.5 for #414 (duckworth-0010, mos-1022) | B9 user-thread decisions reach the owner's inbox by ruling, R3 tests it, N20 start order, R8 waits on host variables |
+| 2026-10-20T19:28:44Z | Gizmoduck | T3 federation design r4.6 for #414 (duckworth-0012 N21, morgana-0011) | R6 notice is row 193's sentence word for word, start-order line matches the table |
+| 2026-10-20T19:29:44Z | Gizmoduck | T3 federation design r4.7 for #414 (mos-1030, Q181) | hosts settled: Case 1 and Hermes on W-jarvis 10.1.1.53, hub W-Melanie-OC 10.1.1.54 user mosaic |
+| 2026-10-20T19:31:06Z | Gizmoduck | T3 federation design r4.8 for #414 (duckworth-0020 N22) | R8 checks mosaic's sudo, groups, keys and sudoers.d on 10.1.1.54 |
+| 2026-10-20T19:35:32Z | Gizmoduck | T3 federation design r4.9 for #414 (mos-1037) | R8 names Jason as localadmin running the root checks on 10.1.1.54 |
+2026-10-20T19:59:12Z | Gizmoduck (Opus 5.5, 9312a896) | federation design r4.10 (#414, mos-1055): R8 is a recorded acceptance citing DECISIONS Q182 and Q183 verbatim, checks report not refuse, agents may run the .54 checks, mos-1042 order in the R8 row | to Duckworth for ack, cc Mos and Sage
+2026-10-20T20:01:20Z | Gizmoduck (Opus 5.5, 9312a896) | federation design r4.11 (#414, mos-1063): hub on .54 VM 1012 as mosaic (Q181), R8 depends on #416 not #418, functional checks stay blocking | to Duckworth with r4.10, cc Mos and Sage