teleo-infrastructure/docs/gcp-leoclean-nosend-runtime.md

GCP leoclean no-send runtime

Outcome

This slice builds and verifies a reproducible Hermes/leoclean artifact for an isolated GCP staging service that has no messaging authority. It retains the reviewed knowledge-reading and proposal-staging surface while making Telegram or any other outbound transport structurally unavailable.

The artifact is pinned to Hermes commit b2f477a30b3c05d0f383c543af98496ae8a96070, its exact upstream archive and dependency lock, the two LivingIP compatibility patches, the leoclean profile inputs, and the Teleo Git revision that compiled it.

Enforced runtime boundary

• The effective Hermes registry contains exactly skills_list, skill_view, and a restricted terminal tool.
• send_message, process, delegation, cron management, memory mutation, and skill mutation are absent and direct dispatch is rejected.
• Persistent memory, user-profile memory, automatic memory review, and automatic skill review are independently disabled in the exact profile; positive or missing review intervals fail verification.
• Cheap-model routing is disabled rather than claimed through an inert config shape; the release probe verifies the pinned Hermes effective configuration.
• GCP-only Cloud SQL and context adapters live under the runtime tree. The shared VPS bridge and plugin remain unchanged, so merging this slice neither syncs nor restarts the VPS service.
• Automatic context currently supports review-only candidate composition and exact claim/evidence challenges with no extra database queries. Broader database-lifecycle questions fail closed until the parity slice adds a separately analyzed Cloud SQL query surface.
• The terminal handler can execute only the artifact's teleo-kb wrapper and its reviewed read/proposal commands. It invokes an argument vector without a shell, rejects database-identity overrides, bounds time and output, and gives the child a minimal environment.
• The gateway starts with zero platform adapters and zero connected platforms. Its tool registry is checked again after startup and model-tool discovery, then the gateway is stopped.
• The only user plugin is leo-db-context; it contributes the reviewed pre- and post-model hooks and no tools. The only gateway event hook is Hermes's built-in startup hook, while BOOT.md is forbidden from the profile.
• Transport credentials, project plugins, environment injection, extra startup controls, symlinks, and unbound artifact files fail closed.
• The artifact binds its metadata identity check to the non-production sa-teleo-staging-vm service account. The shared helper retains its existing production default only when this root-controlled artifact manifest is absent.
• Leo can stage a proposal only through kb_stage.stage_leoclean_proposal(...); this slice does not grant direct canonical or staging-table writes.

Reproduce the release proof

Run from a clean Git checkout with network access for the exact source archive and locked Python wheels:

python3 -m pip install 'uv==0.9.30'
scripts/run_leoclean_nosend_runtime_canary.sh

The canary:

1. compiles the commit-bound artifact twice, rejects dirty relevant sources, and requires identical manifests and content hashes;
2. creates an exact CPython 3.11.9 environment;
3. installs only dependencies resolved by the pinned Hermes uv.lock;
4. checks that the lock is current;
5. starts and stops the effective no-send gateway with a synthetic provider credential, proving the credential value is absent from captured output and the verification receipt; and
6. writes .crabbox-results/leoclean-nosend-runtime.json only after release verification passes.

GitHub Actions runs this same wrapper and retains the receipt as a CI artifact.

Claim ceiling and next slices

This proof establishes reproducible source and a structurally no-send runtime surface. It does not prove GCP IAM, Secret Manager, Cloud SQL identity, deployment or restart behavior, model behavior, database parity, Telegram delivery, or production readiness.

Those remain separate rollback boundaries:

1. bind a dedicated non-production service account to the scoped Cloud SQL secret and leoclean_kb_runtime database role;
2. package the artifact with its operating-system dependencies and deploy the isolated GCP service;
3. prove the running service's effective identity, allowed reads and proposal staging, denied writes/escalation, receipts, and restart behavior;
4. add an internal no-send prompt ingress and run behavioral/database parity;
5. connect the protected Observatory to canonical claims, proposals, pgvector projection, and runtime receipts; and
6. cut over only after soak and restore testing, then revoke the VPS credentials and retire the VPS.