# GCP leoclean migration goal

## Objective

Deploy and prove Leo's least-privilege Hermes/leoclean runtime in GCP staging
against canonical Cloud SQL, establish behavioral and database parity, connect
the protected Observatory to canonical/proposal/vector/runtime receipts, then
cut over safely and retire the VPS after soak.

## Architecture baseline

- Hermes with the `leoclean` profile remains Leo's intended runtime.
- Cloud SQL is canonical PostgreSQL authority.
- The protected Observatory is a separate frontend surface.
- The VPS remains untouched until an explicitly approved, parity-proven
  cutover and retirement sequence.

## Current state

- Complete: PR #179 least-privilege PostgreSQL authority is merged on main.
- Complete: the revision-bound, structurally no-send runtime from PR #183 is
  merged into `main` at `2d88c9765bd9b43641d1efb04a1118c5ce0bce39`.
- Rebuilt for human review: PR #182 is a single service-package commit based
  directly on that merged `main` revision.
- PR #193 is source material only. It must not be merged wholesale; only the
  required identity-binding and OCI-lifecycle corrections belong in the narrow
  #182/#183 stack.
- Complete locally: #182's synthetic identity binding now fails closed and the
  package has one disposable, single-build OCI lifecycle with a truthful claim
  ceiling. The focused suite passed 324 tests, the full suite passed 2,305 with
  3 skips, and both independent review lanes accepted the current diff.
- Next gate: create one user-authored local commit, run the release-mode runtime
  and OCI proof against that exact revision, then stop for human publication
  review. No publication, merge, or deployment is implied by local validation.
- Not yet live-proven: staging VM/container engine, IAM/Secret Manager, Cloud
  SQL effective identity, restart behavior, or model/database parity.

## Remaining order

1. Obtain exact-revision human review for the no-send service-package stack.
2. Run the read-only `teleo-staging-1` host/engine/service-account preflight.
3. Provision the scoped Cloud SQL role/secret and deploy the separate staging
   service.
4. Prove effective identity, reads, function-only proposal staging, denied
   writes/escalation, receipts, restart stability, and rollback.
5. Run behavioral and database parity backtesting.
6. Connect the protected Observatory to canonical claims, proposals, pgvector
   projection, and runtime receipts.
7. Cut over, soak, restore-test, revoke VPS credentials, and retire the VPS.

## Current live-action boundary

No merge, Artifact Registry push, GCP/Cloud SQL/Secret Manager mutation,
service deployment/restart, Telegram change, production promotion, canonical
proposal apply, or VPS access is part of the current offline corrective slice.