step.27.txt -- b3ubot U5.5: THE TRINITY GATE -- one full Adaptive
               Programming arc on the trinity: intent -> propose ->
               validate (real cppcc verdicts over HTTP) -> repair ->
               converge -> close -> deliver; egress witnessed. Phase
               A (the scripted leg) EXECUTED ALL-PASS this session;
               Phase B (the HUMAN-ADAPTER live leg) is the operator
               ceremony, made turnkey -- the gate, and P5, close when
               the ceremony's check passes.

Step:     27
Parent:   end_to_end.md §7 P5 U5.5 row ("THE TRINITY GATE: one full
          AP arc (intent -> propose -> validate -> repair -> converge
          -> deliver) on the trinity, mock AND live; egress
          witnessed"). Under the (p1) re-scope (b3u step.51 header),
          the LIVE leg = the HUMAN ADAPTER (the operator relaying to
          Claude Code) -- the accepted live path; the M1 keyed leg
          stays set aside. design §2.9 (the trinity), §2.5/§2.8 (the
          tiers + arcs this gate composes), Q-25-A (delivery
          placement -- RESOLVED HERE).
UoW:      U5.5 -- the LAST P5 UoW; closing it completes P5 and the
          b3ubot half of (p1). The two-phase shape is the b3u
          step.49 Phase A/B precedent: build+prove the machine
          halves now, the human half runs on the human's clock.
Date:     2026-07-22
Origin:   User directive 2026-07-22: "go with U5.5, step file and
          its execution" (the (p1) sequence).

## (0) Status

PHASE A EXECUTED ALL-PASS; PHASE B PREPARED AND HANDED TO THE
OPERATOR (ledger row stays `active` until the ceremony's check
passes -- the honest state: a gate whose live leg is a human cannot
be closed by a machine alone).

Phase A (scripts/trinity_gate.sh, first invocation ALL PASS): a
launcher-booted b3u; the FULL arc in a trinity workspace -- the
scripted provider proposes a BROKEN grammar, the real plane answers
FAIL with the genuine path-scrubbed cppcc tail, the repair re-entry
carries that tail in the provider context (witnessed AT the
adapter), the repaired spec converges to PASS, closure lands real
commits, and the converged spec is DELIVERED (Q-25-A). The egress
witness: exactly as many runs/ records as provider calls, the
repair record carrying the diagnostics that left; the plane
loopback-only by construction. Honest-skip twin + B-4 grep green.

Phase B (scripts/trinity_ceremony.sh): `prepare` seeds a ceremony
project (git ws + ledger + T3-gated skeleton at SKELETON, workspace-
stamped -- rehearsed in an isolated $B3UBOT_HOME); the ceremony is
`b3ubot run <dir> UC.1 --provider human` (ratify -> relay -> live T3
-> close) + `ccs generate` (deliver) + `check` -- the machine oracle
that closes the gate (rehearsed against the un-run ceremony: refuses
with 6 named FAILs, exit 1 -- never a fake pass).

Suite 637 passed + 28 skipped = 665 collected (the 3 gate legs are
env-gated live tests; measured after the last edit).

PHASE B LIVE-FIRE FINDING (2026-07-22, the ceremony's FIRST real
prompt -- Q-27-D): the relay's default reader was a bare one-line
`input()`, while a real proposal is MULTI-line -- the operator's
paste would have delivered its first line to b3ubot and spilled the
rest into the shell. The operator stopped at the prompt (Ctrl-C;
resumable by design); FIXED same-session: the adapter's DEFAULT
input is now a sentinel-terminated multi-line reader (paste, then a
line containing only EOF); injected input_fns -- every test -- keep
the single-call contract unchanged. The ceremony grammar was then
PRE-VALIDATED against the operator's own live plane (verdict PASS)
before the relay resumed.

PHASE B COMPLETE (2026-07-22, the operator at the relay): the
ceremony ran end to end -- ratify (human decision), the relayed
proposal (ceremony.sgr, a key/value SGDL grammar; 2 human-provider
egress runs recorded), the live T3 PASS from the operator's own b3u
instance, closure by the ENGINE'S OWN 2-commit shape in the ceremony
repo (e270a81 work + ee71886 gdiff, hash backfilled by closing.py),
and delivery (`ccs generate`, generated/ceremony/). The check oracle
surfaced ONE more live-fire finding on its first real pass --
Q-27-E: its bare clean-tree leg contradicted Q-25-A (post-close
delivery is necessarily untracked); fixed to "clean modulo the
delivered bundle"; re-run: 8/8 PASS, independently re-verified by
the engine side. THE GATE IS CLOSED: the trinity ran the Adaptive
Programming loop with the human as the relay. U5.5 -> done; P5
COMPLETE; the b3ubot half of (p1) COMPLETE.

## (1) Ground truth probed at drafting (outputs -> named writers)

    CONFIRMED every gate ingredient existed before this step -- the
              tiers (U5.2/U5.3), the arcs (U5.4), the foreign shape
              + guard (U5.4a), the repair loop with full-tail
              oracle_feedback (U5.2), real closure (U3.7) -- U5.5
              COMPOSES them; its own new machinery is exactly two
              scripts + one oracle file.
    CONFIRMED the egress record carries `provider` (app/egress.py)
              -- the ceremony check can positively identify HUMAN-
              relay runs (B-5's "to whom", queryable).
    CONFIRMED `b3ubot run` resumes from any state (M1), so a
              ceremony prepared at SKELETON starts at the RATIFY
              human gate -- the first thing the operator does is a
              DECISION, which is the right first beat for a ceremony
              about human gates.
    CONFIRMED the real ~/.b3ubot data home must stay clean for the
              real ceremony (start_state refuses duplicate UC.1) --
              every rehearsal ran under an isolated $B3UBOT_HOME.

## (2) What U5.5 delivers

  2.1 **Q-25-A RESOLVED: delivery is an EXPLICIT post-close arc.**
      Convergence = gates green = close; delivery = the operator's
      act of consuming the converged spec (`b3ubot ccs generate`),
      idempotent and re-runnable (regenerate), AFTER the evidence is
      frozen. NOT wired into closing.py: the close commit freezes
      evidence, and coupling a network delivery into it would make
      closure hostage to the plane's availability; pay-per-use
      delivery semantics belong to the operator (recorded in design
      §2.8-chain; the gate's own scripted leg and the ceremony both
      practice it).
  2.2 **tests/test_trinity_gate.py** (3 live legs, Phase A's
      oracle): the full repair-converge-close-deliver arc with the
      verdict history [fail, pass] and the real tail witnessed at
      the adapter AND in the egress record; the egress-accounting
      witness (runs == provider calls; loopback plane); delivery
      re-runnable after CLOSED with the engine state untouched.
  2.3 **scripts/trinity_gate.sh** -- Phase A's battery: boot,
      provision, the 3 gate legs, the honest-skip twin, B-4; prints
      the Phase B ceremony instructions when green.
  2.4 **scripts/trinity_ceremony.sh** -- Phase B, turnkey:
      `prepare <dir>` (fresh git project, T3-gated skeleton, UC.1 at
      SKELETON, workspace-stamped; never clobbers; refuses a
      duplicate UC.1) and `check <dir>` (the 8-leg machine oracle:
      CLOSED, stamp, T3 rows + final PASS, clean tree, closure
      commits, HUMAN-provider egress runs, delivered bundle --
      PASS closes the gate).
  2.5 **Docs**: design Q-25-A resolution + trinity delivered-state
      note; end_to_end U5.5 -> active via the engine's own
      `ledger transition` (the amendment path again); testing.md
      re-measured same-commit.

EXPLICITLY OUT OF SCOPE (each named, never silent):
  - running Phase B FOR the operator (a simulated relay would fake
    the exact thing the gate witnesses)                     -> the ceremony
  - relay-DRAFTING in the ceremony (V1 seeds the skeleton; the
    human-relayed draft stage is the named future ceremony
    variant -- the V0 template validation makes first-ceremony
    friction likely, so the first beat stays the ratify gate) -> later
  - the P6 agnosticism gate (a second AI provider)           -> P6 (parked)
  - (p2)'s xml project (the trinity's first real workload)   -> (p2)

## (3) Verification gates

    G1  PHASE A, THE ARC: propose(BROKEN) -> real cppcc FAIL over
        HTTP -> repair context carries the genuine tail (adapter-
        witnessed) -> converge(PASS) -> CLOSED with real commits,
        clean tree -> delivered bundle in the workspace. Verdict
        history [fail, pass] in verifications.jsonl.
    G2  PHASE A, THE EGRESS WITNESS: len(runs/) == provider calls;
        the repair record carries the diagnostics that left; the
        plane's base URL is loopback (B-2); "what left this machine,
        when, to whom" fully answerable from the trail (B-5).
    G3  PHASE A, HYGIENE: honest-skip twin (3 SKIPPED keyless); B-4
        grep clean; trinity_gate.sh ALL PASS first invocation.
    G4  PHASE B, READINESS: prepare seeds correctly (stamp verified
        in rehearsal); check REFUSES an un-run ceremony with named
        FAILs (exit 1); both rehearsed under an isolated
        $B3UBOT_HOME -- the real data home untouched.
    G5  PHASE B, THE GATE ITSELF (OPERATOR): the ceremony run ends
        with `trinity_ceremony.sh check` printing PASS -- UC.1
        CLOSED, final T3 PASS from the real plane, closure commits,
        HUMAN-provider egress runs, delivered bundle. THEN the
        ledger row flips done and P5 closes.
    G6  NO REGRESSION: full suite 634 passed + 28 skipped = 662
        collected, 0 failed (measured after the last edit).
    G7  Hygiene: porcelain after the WORK commit; testing.md moved
        with the tests; ledger + design current; gdiff via
        ../scripts/step_gdiff.

## (4) LOCKs

    C-27-A  b3ubot porcelain clean after each commit.
    C-27-B  THE GATE CLOSES ON THE CEREMONY, NOT ON PHASE A: the
            ledger row stays `active` until check passes -- a
            machine may not declare a human-witnessed gate green.
    C-27-C  DELIVERY NEVER COUPLES INTO CLOSURE (Q-25-A): closing
            freezes evidence offline; delivery is the operator's
            explicit, re-runnable act. No silent generate on close,
            ever, without a design amendment.
    C-27-D  THE CEREMONY NEVER CLOBBERS: prepare refuses an existing
            dir and a duplicate UC.1; rehearsals use isolated homes.
    C-27-E  standing locks inherited: C-26-B/C/D (id-space, guard-
            never-guesses, foreign-means-foreign), C-25-B/C/D,
            C-24-B, B-1/B-2/B-3/B-4/B-5.

## (5) Open questions

    Q-27-A  Phase-B closure mechanics (DECIDED: when the operator's
            check passes, the closure session flips U5.5 -> done via
            `ledger close U5.5 <commit>` + a §(0) addendum here
            naming the ceremony date -- the same backfill discipline
            as every hash).
    Q-27-B  Relay-drafting (DEFERRED, named): ceremony V1 starts at
            the ratify gate over a seeded skeleton; a future variant
            lets the relay draft the skeleton itself (the V0
            template validation + 2-attempt budget make that a
            friction risk unfit for a first ceremony).
    Q-27-C  Ceremony spec target (DECIDED: the proposal names its
            own file -- first line of the paste-back; the check only
            requires SOME delivered bundle under generated/, so the
            operator may converge any grammar, not a scripted one --
            it is THEIR loop now).
    Q-27-D  Multi-line paste mechanics (FOUND LIVE at the first real
            relay prompt, FIXED same-session): bare input() reads
            one line; _parse_proposal requires path + content lines.
            DECIDED: the DEFAULT reader collects lines until a lone
            EOF sentinel (prompt says so); injected input_fns keep
            single-call semantics, so the whole contract suite is
            untouched. The first-ever interactive relay could not
            have been exercised by any test that injects I/O -- this
            is precisely the class of finding Phase B exists for.
    Q-27-E  The check's clean-tree leg vs Q-25-A (FOUND by the FIRST
            real ceremony's own check, FIXED same-session): delivery
            is post-close by design, so the delivered generated/
            tree is necessarily untracked after the closure commit
            -- the oracle demanded a contradiction. DECIDED: clean
            modulo the delivered bundle (anything ELSE dirty still
            fails). Two live-fire findings in one ceremony -- the
            gate earned its Phase B.

## (6) Acceptance

    - [x] Q-25-A resolved + recorded (2.1).
    - [x] Phase A oracle (3 legs) + trinity_gate.sh ALL PASS first
          invocation (2.2, 2.3, G1-G3).
    - [x] Ceremony prepare/check built + rehearsed isolated (2.4,
          G4); real data home untouched.
    - [x] U5.5 -> active via the engine's own ledger CLI; docs moved
          (2.5, G7); suite 634+28=662 (G6).
    - [x] PHASE B: the operator ceremony -- check PASS (8/8,
          2026-07-22, independently re-verified) + the §(0) addendum;
          U5.5 closed via `ledger close` (G5, Q-27-A). THE GATE, AND
          P5, CLOSED HERE.

## (7) Hash backfill

    WORK commit (Phase A + ceremony + this file):  (this commit)
    GDIFF commit (step.27.gdiff.txt):              (HEAD)
    CEREMONY closure (Phase B, operator):          (this commit)

End of step.
