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)
