step.28.txt -- b3ubot U5.6: THE REMOTE TRINITY -- the same AP arc that passed the (p1) trinity gate, now with the CLOUD plane (https://staging.b3u.dev, behind the Cloudflare Access wall) as the CCS oracle: B3uDevClient gains CF Access service-token headers (one session-level seam), the egress-witness oracle is parameterized to assert the DECLARED plane instead of hard-coding loopback, and scripts/remote_gates.sh runs the full scripted arc against the operator's real staging account. Phase B = the operator's remote relay ceremony. (p1.1.2) of the user's (p1.1) plan. Step: 28 Parent: end_to_end.md §7 P5 -- U5.6, ADDED BY AMENDMENT (the (p1.1) plan, ratified 2026-07-23; b3u UB.4/step.53 is the cross-repo prerequisite: the staging plane is fresh and holds exactly ONE real entitled account). design §2.8/§2.9 ("the hosted b3u.dev later is this same class pointed at a different base URL -- the API is the seam") -- this step cashes that sentence. UoW: U5.6 -- sixth P5 UoW (by amendment; P5's local-trinity completion stands -- this extends the SAME arc to the remote plane). Row enters the ledger via the engine's own `ledger add-row` (the U5.4a dogfood precedent). Date: 2026-07-23 Origin: User directive 2026-07-23: "go with (p1.1.2)" -- "repeat (p1) test ... this time server side activities would be executed on b3u.dev web site being as a server for b3ubot application." ## (0) Status **ADDENDUM AT CLOSE (2026-07-23): U5.6 CLOSED — Phase B COMPLETE.** The operator ran the remote relay ceremony under the fresh ~/.b3ubot.1 home against https://staging.b3u.dev: prepare → ratify → relay (the proposal = the ceremony key/value grammar, PRE-VALIDATED PASS on staging before handover) → human gate approve → T3 verdict PASS from the remote plane → close (real commits e4ef27f + 3704dc1 in ~/trinity_remote) → deliver (22-file 4-language bundle, revision 1) → check 8/8 PASS, independently re-verified (exit 0). Three relay attempts total, all honestly recorded in the B-5 egress trail (3 human-provider runs); the two failed attempts produced the Q-28-E findings below. Operator word: the pasted ALL-PASS check transcript. DRAFTED for same-session execution. Phase A (scripted remote arc) is machine work ONCE the operator provides staging credentials in the sanctioned env-file shape (Q-28-A); Phase B is the operator's remote relay ceremony (C-27-B/C-53-C lineage: the machine may not declare it green). ## (1) Ground truth probed at drafting (outputs -> named writers) EXISTS (the seam): B3uDevClient (app/ccs/client.py) -- ALL HTTP rides self._session (login, _authed, health, package); base URL = $B3U_BASE_URL > config `b3u_base_url` > loopback default (resolve_base_url). Session-level default headers therefore cover every operation with ONE change site. EXISTS (the wall): staging.b3u.dev behind Cloudflare Access; non-browser clients pass with CF-Access-Client-Id/ -Client-Secret headers (the b3u staging_smoke.sh precedent); the service token lives on this dev box in ~/.b3u_cf_smoke.env (0600, outside all repos). EXISTS (the plane state): b3u UB.4 closed 2026-07-23 -- staging holds exactly one account (operator@example.com, client betthreetesting, sub active level1). Its password is the OPERATOR's -- b3ubot never stores it (B-4). EXISTS (the oracle): tests/test_trinity_gate.py -- 3 legs (repair-converge-close-deliver / egress witness / re-deliverable), hermetic per-test $B3UBOT_HOME (conftest autouse), skip-gated on B3uDevClient. is_available(). ONE loopback assumption: the egress witness asserts client.base_url.startswith ("http://127.0.0.1") -- correct for the LOCAL trinity (B-2), wrong by design for the remote leg. EXISTS (ceremony tooling): scripts/trinity_ceremony.sh is env-transparent (zero B3U_BASE_URL/B3UBOT_HOME/port references -- the client and engine resolve both from env), so the remote ceremony is an ENV change, not a script change. BUT: UC.1 is CLOSED in the real ~/.b3ubot (step.27 Phase B) -- start_state's duplicate refusal means the remote ceremony needs its own data home (Q-28-B; prefigures (p1.1.4) multi-home). EXISTS (hermetic client tests): tests/test_ccs_port.py -- repr-carries-no-credentials, env-only credentials, base-URL resolution; the CF header tests belong beside them. ABSENT: any CF Access support in the client (a bare client gets 302'd to the Access login by the edge); any remote gate script; any staging-creds env-file convention on this box (the Stripe key and CF token files exist -- the b3u account creds file is new, Q-28-A). ## (2) What U5.6 delivers A. B3uDevClient CF Access support (app/ccs/client.py): at __init__, if $CF_ACCESS_CLIENT_ID and $CF_ACCESS_CLIENT_SECRET are BOTH set, install them as session default headers (CF-Access-Client-Id / CF-Access-Client-Secret). One seam, all five operations. Values are credentials (C-28-B, the B-4 family): env-only, never config.txt, never logged, never in repr. Absent env == exactly today's client, byte-for-byte behavior (the local trinity is untouched). B. Egress-witness oracle parameterized (test_trinity_gate.py): the hard loopback assert becomes "client.base_url == the RESOLVED declared base"; when that base is loopback, the B-2 loopback claim is still asserted verbatim; when remote, the base must be https and equal $B3U_BASE_URL exactly (C-28-A: CCS bytes go ONLY to the operator-declared plane -- the witness names WHERE they went either way). C. scripts/remote_gates.sh -- the (p1.1.2) Phase A leg. Boots and provisions NOTHING (C-28-C -- plane mutations beyond the account's own unit ops belong to b3u's scripts): requires $B3U_EMAIL/$B3U_PASSWORD + the CF token pair in env; legs: W the wall: an anonymous (headerless) edge /health is NOT 200 (the staging_smoke W1 twin -- proves the token is doing the admitting); H client health THROUGH the wall (B3uDevClient.health()); ARC the full trinity pytest (3 legs) with B3U_BASE_URL= https://staging.b3u.dev -- the same oracle that gated (p1), now over the internet against the real account; SKIP the honest-skip twin (creds stripped -> 3 skips); B4 the credential-leak grep over the work dir. D. Hermetic tests (tests/test_ccs_port.py): CF pair present -> both session headers set; either absent -> neither set; repr still credential-free with the pair set. E. Ledger: U5.6 row via `b3ubot ledger add-row` (U5.4a dogfood precedent) + §7 P5 table row; testing.md refreshed; suite measured AFTER the last edit (docs are data). F. Phase B -- the operator's REMOTE relay ceremony: env B3UBOT_HOME=~/.b3ubot.1 (fresh home; Q-28-B) B3U_BASE_URL=https://staging.b3u.dev + creds + CF pair; trinity_ceremony.sh prepare / b3ubot run UC.1 --provider human / ccs generate / trinity_ceremony.sh check -- the unchanged ceremony, remote plane. Close on check-PASS + operator word. ## (3) Verification gates G-A (hermetic): full suite green after the last edit; the new CF tests pass with no network. G-B (Phase A, machine, needs operator creds file): remote_gates .sh ALL PASS against staging -- recorded in §(7). G-C (Phase B, operator): the remote relay ceremony; check legs + operator word (C-27-B lineage). G-D (no-regression): the LOCAL trinity gate story untouched -- proven by the unchanged hermetic suite + the parameterized witness still asserting loopback for loopback bases. ## (4) LOCKs C-28-A CCS egress is sanctioned ONLY to the operator-declared $B3U_BASE_URL (the operator's own infrastructure). The egress witness asserts the client base EQUALS the declared base -- loopback or remote, "where CCS bytes went" is asserted, never assumed. C-28-B CF Access service-token values are credentials (B-4 family): environment-only, never in config.txt, logs, repr, or committed files. C-28-C Remote gates never boot, provision, reset, or otherwise mutate the plane beyond the account's own unit operations. Plane lifecycle belongs to the b3u repo's scripts (b3u_local.sh, b3u_reset.sh). (inherited) B-1 no CCS code here; B-3 never push; B-4 creds env-only; C-22-D contract-v1-only (CF headers are TRANSPORT, not contract -- the 7 frozen paths are untouched). ## (5) Open questions Q-28-A How do the operator's staging credentials reach Phase A without entering the conversation/logs? LEAN (the ~/.b3u_stripe_test.env + ~/.b3u_cf_smoke.env precedent): operator creates ~/.b3u_staging_creds.env (0600, outside all repos) with export B3U_EMAIL=... / B3U_PASSWORD=...; gate invocations source it. The file is the operator's, never committed, never read into any artifact. Q-28-B Remote ceremony data home: UC.1 is closed in ~/.b3ubot, so prepare would hit start_state's duplicate refusal. DECIDED: the remote ceremony runs under B3UBOT_HOME=~/.b3ubot.1 -- the alex-account home from the user's own (p1.1.4) naming plan, created here, formalized there. Q-28-C WAN + 1-vCPU droplet vs JOB_TIMEOUT_SECONDS=120: LEAN keep 120s and MEASURE at Phase A; raise only on evidence. MEASURED: the whole 3-leg arc (validates, generates, deliveries included) completed in ~65s wall total -- 120s per-call stands with wide margin. Q-28-D (LIVE-FIRE FINDING, first Phase A run) ARC failed with `CCSUnavailableError: unexpected 404` on validate: the staging droplet was still running PRE-UB.1 code (last deploy 2026-07-18, steps 45-48; the validate op landed step.51, 2026-07-22, and had only ever run against LOCAL instances). Two things went right: the verifier's verdict-less-defect taxonomy REFUSED to treat it as a red gate ("a provider cannot fix the engine") -- the exact designed behavior; and the fix was the standard update path (b3u_deploy.sh re-run, state untouched -- the fresh account survived). LESSON: a frozen contract doc does not deploy itself -- after contract-surface changes, staging redeploy belongs on the checklist (recorded for the (p1.1.3) Test Plan's environment preconditions). Q-28-E (LIVE-FIRE FINDINGS, Phase B ceremony -- the relay's paste channel is the fragile link, three lessons): (i) a chat-copied paste arrived with a leading blank line + 2-space indentation -> the V0 shape law refused it, run halted RESUMABLE (the guard doing its job); (ii) the retry's clipboard was OVERWRITTEN between wl-copy and paste (copying the next command from chat replaces the clipboard) -> a shape-VALID nonsense proposal (line 1 = the command text) was accepted by the relay and cached as a DONE provider_run node -- decline then LOOPS on resume, because only failed/ declined nodes re-run and the bad node is done. Way out = the engine's own remedy text: REPAIR THE ENGINE RECORD (EXECUTING -> RATIFIED history pop; fresh instance, ratification stamp preserved). Also hit the human provider's TTY guard (stdin-redirect refused -- correct by design, the relay must be witnessed); (iii) the fix that worked: a one-shot helper that wl-copies the proposal file and EXECs the run in the same motion -- no window for clipboard clobber. LESSON for a future ceremony variant: an optional --proposal-file flag on the human adapter (still TTY-gated for the approve step) would remove the paste channel's fragility without weakening the witness. Cosmetic: trinity_ceremony.sh's PASS banner says "U5.5 closes" (hardcoded from step.27) -- generalized in this step's close commit. ## (6) Acceptance [x] CF header seam in B3uDevClient; hermetic tests green; local behavior byte-identical without the env (A,D,G-A) [x] Egress witness parameterized; loopback claim intact (B,G-D -- proven LIVE: trinity_gate.sh local re-run ALL PASS) [x] remote_gates.sh exists; refuses without creds/token (C) [x] Phase A ALL PASS against staging (2nd run, after the Q-28-D redeploy) (G-B) [x] Phase B remote ceremony closed by check + operator (8/8, independently re-verified) (G-C) [x] U5.6 row via engine add-row; docs + testing.md; suite measured after last edit (E) ## (7) Hash backfill WORK commit: 01a09f6 Phase A run: 2026-07-23. Refusal leg first (no env -> REFUSED, exit 2, names the missing vars). Local no-regression: trinity_gate.sh ALL PASS (the parameterized witness still asserts loopback for the local plane). FIRST remote run: W/H PASS, ARC 3-leg FAIL -- the Q-28-D 404 (staging on pre-UB.1 code); fixed by the standard b3u_deploy.sh re-run (state untouched). SECOND run: ALL PASS -- W wall 302 / H health through the wall / ARC 3/3 vs https://staging.b3u.dev (~65s) / SKIP honest 3-skip twin / B4 no credential in any artifact. Phase A hashes: Phase A record commit 9984a33. Phase B close: 2026-07-23, operator at the relay + browser account. Ceremony workspace ~/trinity_remote (home ~/.b3ubot.1): UC.1 INTENT->CLOSED, T3 verdict PASS from staging, closure commits e4ef27f + 3704dc1, delivery rev 1 (22 files, 4 languages) from the remote plane; check 8/8 PASS independently re-verified. Two failed relay attempts (Q-28-E i/ii) honestly in the egress trail; engine-record repair (EXECUTING -> RATIFIED) used once, per the engine's own remedy text. Operator word: the pasted ALL-PASS transcript. RETRO commit: (retro pair -- see step.28.diff.txt)