gizmoduck: T3 federation design r4.10 for #414 (mos-1055): R8 records Jason's acceptance (DECISIONS Q182, Q183) instead of refusing; checks report, agents may run the .54 checks

agents/gizmoduck/work/federation/DESIGN.md

@@ -1,6 +1,6 @@
 # T3 federation design: factory and hub (Vikunja #414, G3, G4, C1.1)
 
-Author Gizmoduck (Opus 5.5), 2026-10-20, r4.9. Design only, no product code. Reviewer Duckworth (Opus 5.5,
+Author Gizmoduck (Opus 5.5), 2026-10-20, r4.10. 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
@@ -40,6 +40,13 @@ PLAN.md T3 (all in jason-master-restart).
   #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.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.
@@ -296,8 +303,9 @@ 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. Only the separate host (R8 gate) keeps other instances' agents from making
-that write. Jason may also edit the file by hand.
+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
 
@@ -330,7 +338,7 @@ any granted user. So can anything that can ptrace or write files as that uid. Th
 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, and R8's gate proves the factory has no login there. The hypervisor path is open (R8, section 8). Federation adds no weaker path than the owner's.
+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:
 
@@ -421,7 +429,7 @@ Jason (mos-1013): dragon-lin is his workstation and won't host the final instanc
 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).
-Whether that is a cluster VM or other hardware waits on Jason (#419, section 8). The federation path
+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
@@ -474,8 +482,8 @@ The only one-host piece is R7, which is scratch on one host by design (row 190).
   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's gate checks (section 7,
-  3.8). A cluster VM or other hardware waits on Jason (#419, section 8).
+- 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,
@@ -526,7 +534,7 @@ gate. Chains follow Q177: a dependent row builds on its parent's candidate.
 | 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 hub host live (Vikunja #418), Jason's #419 answer, #412 phase 2, R7 | Entry gate, host form only for 10-27 (mos-0996): the hub runs on its own host (#418), not on dragon-lin or Melanie's server. R8 refuses to start unless every check passes. 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, #421). #421's plan sets that, so R8 checks it on 10.1.1.54 as root and each must hold: `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). Jason runs these as localadmin with his new key (#421 step 1) and the output goes into the R8 record. No factory uid runs them, because R8 requires every factory root path to .54 to fail (mos-1037). 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 passes 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 each fails (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. R8 refuses to start until each one is either closed, with its check passing, or accepted by Jason in writing with the table's wording, which also goes to Melanie (#419). 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 the hub host runs no other instance or agent. Also: 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. Jason's attestation confirms no factory agent holds a login or key for the hub host, but the failed calls are the gate. 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 |
+| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the hub host live (Vikunja #418), 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 its own host (#418), not on dragon-lin or Melanie's server. 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).
@@ -536,12 +544,12 @@ R6 waits on Sage's phase 1 candidate.
 
 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 hub
-host is live by about 10-25 (Vikunja #418), with Jason's #419 answer. R6 and R7 chain on #412 phase 1. R8 needs all three, plus
+host is live by about 10-25 (Vikunja #418). 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, and the hub host itself. If the host fails the
-gate, R8 doesn't run and Mos takes it to Jason.
+second public origin, a proxy route and a provider client, and the hub host itself. A failed privilege check
+doesn't stop R8. It goes into the record, and Mos takes it to Jason.
 
-Open gate item, the hypervisor path (Vikunja #419, mos-1004, Jason's decision). Factory agents hold root
+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,
@@ -554,7 +562,26 @@ which the node can read, and a node that can change the boot can capture the pas
 - 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.
 
-Mos adds Jason's answer. Until then R8 doesn't start.
+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)
 
@@ -577,8 +604,9 @@ its backups are unencrypted. The LAN is flat (10.1.0.0/16) with dragon-lin on it
 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 gate item. Jason decides each one (#419): closed, when its check passes, or accepted,
-when the accepted wording goes into his attestation and to Melanie. Every check runs from the factory
+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 |
@@ -595,7 +623,7 @@ host, as root through `sudo -n` where the factory has it, and passes only when t
 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 attestation names every path that stays accepted.
+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)
 
@@ -611,8 +639,8 @@ row is closed too, or they sit on hardware outside PVE. The attestation names ev
    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,
-   the host form only (mos-0996, Vikunja #418). The uid form (row 190b) is a later option. The hypervisor
-   path is open with Jason (#419, section 8).
+   the host form only (mos-0996, Vikunja #418). 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
 

docs/SESSIONS.md

@@ -1373,3 +1373,4 @@ are never rewritten or removed; corrections are new entries.
 | 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