VOX-3b · In My Head transports — Twilio/Gmail adapters

[4444J99]

Plan: docs/plans/in-my-head-transports.md · https://github.com/organvm/universal-mail--automation/blob/codex/uma-literal-mail-union-154/docs/plans/in-my-head-transports.md
Owner: universal-mail--automation · Priority: medium · Type: code

Concern

The transports — Twilio webhook + Gmail watch — live where accounts already live.

Process

1. Reuse existing gmail_auth.py / auth/onepassword.py (1Password-backed) — no new credential code.
2. Add an adapter that, on received message, POSTs to vox /ingest/email (and /ingest/sms for Twilio).
3. Pull the resolved voice_id + hydrated key from the credential layer; call vox /jobs/{id}/generate; route audio back.
4. Respect the his-hand registry: any new account action is a lever, not a chat task.

Verify against meta/macro

• Uses the established 1Password-backed auth (no secret in repo).
• vox called only as a pure receiver (VOX-3a contract).
• No ElevenLabs account creation here either — key comes from credential organ.

[4444J99]

Remote reconciliation: PR #163 merged the transport plan only. A default-branch code search finds /ingest/email, /ingest/sms, and ElevenLabs references only in that plan, with no VOX_API_URL adapter implementation.

VOX-3b therefore remains open. The next code receipt must use the established UMA auth surfaces, take the VOX endpoint/voice selection from injected runtime state, call the live VOX ingest/job contract, and verify with fixtures or mock services—without adding credentials, account actions, or a fixed provider catalog.

[4444J99]

Implementation custody is on draft PR #164 at exact head 71d3f20acdeb8d0f162472ed63b9e9e19ce1de31.

State: code and exact-head CI are green; live activation is not done. CI run 29128492245 passed all seven required jobs. This issue stays open.

External/human gate:

• credential owner must hydrate VOX_BASE_URL, VOX_RENDER_PROFILE_OP_REF, and optional VOX_ACCESS_TOKEN_OP_REF in the approved runtime (references/secret wall only; never paste values here)
• Gmail/Twilio account owner must register or connect the existing authenticated watch/webhook through the approved account surface
• after Add dynamic VOX transport adapter (VOX-3b) #164 merges, record one authenticated forwarding canary and its redacted VoxForwardReceipt

Receiver-half next command after the references are hydrated (synthetic payload; prints only a redacted receipt and audio byte count):

python3 - <<'PY'
from core.vox_transport import (
    AuthenticatedInbound,
    build_vox_adapter_from_env,
    load_vox_render_profile,
)

adapter = build_vox_adapter_from_env()
message = AuthenticatedInbound.email(
    sender="vox-canary@invalid",
    subject="VOX-3b receiver canary",
    body="VOX-3b receiver canary",
    authentication_receipt="operator-approved-canary",
)
receipt = adapter.forward(
    message,
    render_profile=load_vox_render_profile(),
    audio_sink=lambda job_id, audio, content_type: print(
        {"job_id": job_id, "audio_bytes": len(audio), "content_type": content_type}
    ),
)
print(receipt)
PY

That canary does not register an account transport; the Gmail/Twilio owner must still invoke the adapter once from the real already-authenticated handler and attach the non-secret receipt before VOX-3b can be closed.

[4444J99]

Triage-only pass 2026-07-18 because UMA has active work in flight today: this remains open and still appears anchored to PR #164 plus external transport/credential gates. Next concrete step: once the approved VOX/Gmail/Twilio references are hydrated, run the exact forwarding canary and attach the redacted receipt here.