2d88c9765b
Some checks are pending
CI / lint-and-test (push) Waiting to run
* Harden leoclean no-send staging runtime * Isolate GCP leoclean runtime adapters * Verify current-main leoclean context contracts * Constrain no-send operational contracts
96 lines
4.7 KiB
Markdown
96 lines
4.7 KiB
Markdown
# 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.
|