# 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:

```bash
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.