docs: row 209 brief as the .54 window with its own proxy (mos-1615, Q253)

docs/plans/2026-10-24_row209-hub-54-window.md

@@ -0,0 +1,109 @@
+# Brief: row 209, the .54 window with its own proxy
+
+Written 2026-10-24 by Sage for Mos's mos-1615, which carries Jason's "Q54: yes" (DECISIONS Q253). Q253:
+.54 waits for its own model proxy. Bean's Z.ai key and Chet's ChatGPT/Codex login both go in through the P4
+Console proxy page. Chet runs GPT through his Codex login for 10-27, not GLM, which replaces Q186.
+
+This brief replaces row 209's old brief (`docs/plans/2026-10-20_federation-r1-r2-r5.md`, "Brief: FED R8, the
+hub window on 10.1.1.54"). That section isn't edited. Phase D below runs it unchanged. Read the model-proxy
+design (`docs/plans/2026-10-24_stack-model-proxy.md`, sections 1, 5, 9 and 10), the rows doc
+(`docs/plans/2026-10-24_model-proxy-rows.md`) and the P4 brief (`docs/plans/2026-10-24_proxy-page-brief.md`)
+first. Line numbers are at origin/refactor 95d4991d2. Check them before you rely on them.
+
+## Brief: row 209, the .54 window: proxy, Bean's and Chet's accounts, then FED R8
+
+**What this row is.** A live window on 10.1.1.54, not a code row. Jason and Mos run it. Nothing here
+authorizes a step on any host. Each step waits for the window's go, and Console start and restart stay
+with Jason or Mos (Q173).
+
+**Secrets.** The rows doc's rules apply on .54 too. No agent reads `<configDir>/secrets/proxy-management.key`
+or anything under .54's `<dataRoot>/proxy/` (`config.yaml`, `auth/`, `logs/`), and no agent reads Hermes's
+auth files or Chet's login in any form (D6, mos-1600 ruling 2). Agents read only what a command prints:
+hashes, unit state, refusal codes and the proxy page's allowlisted fields.
+
+### Entry checks, all before phase A
+
+1. P1 (row 329), P2 (331), P3 (332) and P4 (330) have landed and passed Sage's landing gate. P3 carries the
+   amendment for pi's GLM and GPT routes that Mos rules on (sage-4285). Without it P3 proves only the
+   Anthropic route.
+2. **Gap to close first.** `.54` installs through `scripts/case2-install.sh` and `scripts/case2-unit.sh`.
+   P1 adds `mosaic-proxy.service` to `scripts/instance.sh` only (rows doc P1 item 7). `case2-unit.sh` writes
+   no model-proxy unit today, and its bus unit has no `Wants=` or `After=` on one. A code row has to add the
+   proxy unit to the Case 2 install, with the same sha256 refusal, before phase A. Sage files it once Mos
+   rules (sage-4285).
+3. The .54 stack copy is re-pinned to a commit that holds rows 329 to 332 and the item 2 row.
+4. .54's Console signs Jason in through Authentik (Q218). The proxy page's writes need a signed-in owner
+   (P4 item 8).
+5. Phase B has a recorded result, or Chet's login waits for phase C as phase B says.
+
+### Phase A: the proxy on .54
+
+Design section 9, for .54 as the `mosaic` user under `/srv/mosaic` (D1).
+
+1. **Fetch.** P1's pinned fetch runs on .54. Sage compares the printed sha256 values with PIN.
+2. **Config and key.** Jason adds the `proxy` section to .54's `config.json` in an editor (J2), runs
+   `mosaic proxy init` in his own terminal (J3) and starts the proxy unit.
+3. **Bean's key.** Jason pastes Bean's Z.ai API key into .54's proxy page (J4, P4 item 4) and sets its
+   priority. The page never shows it again.
+4. **Chet's login.** Only after phase B passes. Jason signs the proxy in to Chet's ChatGPT/Codex account
+   through the page's own OAuth flow (P4 item 3). The proxy holds a sign-in of its own. Nobody copies
+   Hermes's auth file.
+5. **Business settings.** Bean's and Chet's `launch.models` name provider `proxy` (P3 item 5): Bean on his
+   GLM model, Chet on his GPT model, with the model ids the proxy's `/v1/models` lists. The edit goes in
+   through the human path that P3's BUILD.md names.
+6. **Restart.** Jason or Mos restarts the bus and Console. The bus reconciles, issues a key for each agent
+   (P2) and runs D17's preflight for each one. Any refusal stops phase A. The fix is to remove the section
+   and restart.
+7. **One real turn per route.** The tester actor launches one pi session for Bean (GLM through the Z.ai key)
+   and one for Chet (GPT through the Codex login). Each makes one real turn through the proxy. Jason
+   watches the proxy page's usage section and confirms each request landed on the account he expects (J5).
+   The result goes into the row's record with who ran it.
+8. **Unit cleanup.** Once both turns pass, the bus unit drops the provider env file per design section 9
+   step 7. The file stays for the 7-day rollback window.
+
+Rollback at any point: remove the `proxy` section and restart.
+
+### Phase B: two clients on one ChatGPT login
+
+Hermes holds Chet's ChatGPT login until #423 step 5. Before that login goes into the .54 proxy (phase A
+step 4), a check has to show that two clients on one ChatGPT login don't revoke each other's refresh tokens
+(mos-1615 item 3). Row 229's brief named the same risk for a copied token.
+
+- Two separate sign-ins, never a copied file: Hermes keeps its own, and the proxy gets its own through the
+  page.
+- Pass: each client goes through at least one token refresh, and afterwards Hermes still answers on Chet's
+  login and the proxy page still lists the account as active. Fail: either one drops out or needs a new
+  sign-in.
+- The check is Jason's. It uses the real account, and no agent reads either client's token or auth file.
+  Agents record what Jason reports and what the page lists.
+- **Open before the window.** I don't know how to make each client refresh on demand without someone reading
+  a token, or how long ChatGPT's access tokens last. Researcher answers from the pinned 8.0.42 docs and
+  Hermes's docs: how each side refreshes, whether either can be made to refresh, and how long the check has
+  to run. The answer goes in this row's record.
+- If the check fails, or there's no safe way to run it, Chet's login goes in after #423 step 5, when Hermes
+  has let go of it. Phase A step 7's GPT turn waits for that, and Chet doesn't go live on GPT until it passes.
+
+### Phase C: Case 2 go-live, then Hermes stops
+
+Bean and Chet go live in Case 2 on the proxy (#416). Hermes stops after that (#423 step 5, mos-1615), and
+that stays Melanie's choice (`docs/plans/2026-10-20_case2-rows.md`:1231). If phase B didn't pass, Chet's login goes into the proxy here and phase A step 7's GPT turn
+runs before Chet goes live.
+
+### Phase D: FED R8
+
+The old brief, unchanged: entry checks, build notes N1 and N2, and its done condition
+(`docs/plans/2026-10-20_federation-r1-r2-r5.md`, "Brief: FED R8, the hub window on 10.1.1.54").
+
+### Done when
+
+Phase A's two real turns are recorded, each on the account Jason expected. Phase B's result is recorded
+along with who ran it. Bean and Chet are live on the proxy. FED R8's own done condition holds.
+
+### Out of scope
+
+- Any code change. The item 2 gap and the P3 amendment are code rows of their own.
+- The dragon-lin default instance and .53. Their cutovers are P7 and row 246.
+- Hermes's server and profiles, beyond Jason's phase B check.
+- The 8317 host proxy and `~/.local/opt/EasyCLIProxyAPI`.
+- Row 229 (Vikunja 428). The proxy route supersedes it, and the queue parks it with that reason. Its live
+  check is phase B.