# 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`.
- Published for human review: PR #182 was rebuilt directly on that baseline at
  `5bcdaa4`; the required identity and OCI corrections are being integrated
  locally before exact-revision review.
- 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.
- In progress locally: the narrow package correction based on `d962555` now
  binds every packaged and synthetic-identity source byte to its reviewed Git
  blob and makes container health bind the packaged/live config plus the exact
  sealed no-send tool and plugin surface. Independent review found these gaps;
  the corrective diff still requires exact-revision tests before publication.
- Separate follow-up: candidate release finalization does not inspect Artifact
  Registry. A narrow deployment-evidence slice must bind the immutable remote
  digest, `linux/amd64` manifest/config, labels, input hash, and source revision
  before any unit can be installed.
- Next gate: commit the local correction with the configured human Git
  identity, run focused/full and disposable OCI proof against that exact
  revision, then stop for publication approval. 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.