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

This commit is contained in:
2026-10-20 15:01:20 -05:00
parent 3568441ab0
commit b93f098f0b
2 changed files with 12 additions and 7 deletions
+11 -7
View File
@@ -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.10. Design only, no product code. Reviewer Duckworth (Opus 5.5,
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
@@ -40,6 +40,10 @@ 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.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.
@@ -424,7 +428,7 @@ do that first.
### 3.8 One host or two (mos-0991)
For 10-27 the hub runs on its own host, not on dragon-lin or Melanie's server (mos-0996, Vikunja #418).
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
@@ -534,7 +538,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), 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 |
| 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).
@@ -543,10 +547,10 @@ 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 hub
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
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, and the hub host itself. A failed privilege check
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
@@ -639,7 +643,7 @@ row is closed too, or they sit on hardware outside PVE. The R8 record names ever
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. Jason accepted
.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
+1
View File
@@ -1374,3 +1374,4 @@ are never rewritten or removed; corrections are new entries.
| 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