# GCP-native Leo goal

## Outcome

Run Leo's Hermes `leoclean` runtime as a fresh GCP service, backed by the V3
LivingIP knowledge base in canonical Cloud SQL, and route Telegram directly to
that verified GCP service.

This is not a VPS lift-and-shift. The existing VPS is never copied into or run
inside GCP. It remains untouched as a temporary comparison and rollback source
until the GCP service has passed soak and restore testing.

## Target architecture

- An immutable `leoclean` image is pulled from Artifact Registry by digest.
- A dedicated GCP service runs Hermes with the `leoclean` profile.
- Cloud SQL PostgreSQL 16 is the canonical V3 knowledge authority.
- Secret Manager supplies only the scoped `leoclean_kb_runtime` credential.
- Leo reads canonical knowledge and stages proposals only through
  `kb_stage.stage_leoclean_proposal(...)`.
- Telegram delivery terminates at the verified GCP service.
- The protected Observatory remains a separate follow-up surface over
  canonical, proposal, vector, and runtime receipts.

## Current state

- Current main/base: `832f0c3f47abe3eded61f4be585fde3c4f00b91a`.
- The GCP VM, private Cloud SQL instance, immutable image, and scoped Secret
  Manager secret exist.
- The Cloud SQL-compatible least-privilege correction is implemented on
  `fix/cloudsql-large-object-boundary` and is awaiting publication and human
  review.
- Exact local evidence: 2,601 repository tests passed with 2 expected skips;
  the digest-pinned, network-disabled PostgreSQL 16.14 lifecycle canary passed
  2 tests; Ruff, Bash syntax, and `git diff --check` passed.
- The `leoclean_kb_runtime` role has not yet been successfully provisioned in
  Cloud SQL.
- The VM service account has not yet been granted access to the scoped secret.
- The no-send GCP service is not installed or running.
- V3 knowledge reconstruction and promotion have not yet been reconciled from
  PR #220 into canonical Cloud SQL.
- Telegram still does not route to GCP.

## Execution order

1. Publish and review the Cloud SQL authority correction.
2. Provision `leoclean_kb_runtime`, grant scoped-secret access, install the
   immutable no-send service, and prove identity, permissions, restart, and
   rollback.
3. Extract the required V3 reconstruction changes from PR #220, rebuild or
   migrate into a separately identified canonical candidate database, and
   prove row/hash/source receipts before promotion.
4. Bind the GCP runtime to the verified V3 canonical database and run database
   and behavioral parity checks without Telegram sends.
5. Switch Telegram delivery to the GCP service, prove real response receipts,
   soak, restart, and restore behavior, and retain an immediate rollback path.
6. Revoke obsolete runtime credentials after soak. VPS destruction remains a
   separate explicit decision.

## Authority and rollback boundaries

- Database role provisioning can be rolled back independently by refencing
  the runtime role and removing its scoped secret access.
- Service deployment can be rolled back independently to the prior immutable
  image or stopped without changing canonical data.
- V3 database promotion requires a pre-promotion backup and exact reconciliation
  receipt; it does not imply Telegram cutover.
- Telegram routing is the final reversible switch and happens only after the
  no-send service, V3 data, restart, and rollback proofs pass.
- Canonical proposal approval, Observatory deployment, vector-backend choice,
  and irreversible VPS deletion are not part of the current deployment slice.

## Human gates

Database/security review, GCP role and IAM mutation, V3 canonical promotion,
and Telegram cutover are distinct critical gates. Evidence from tests or agent
review is advisory; the exact revision and live receipts must be presented to
the human development lead at each gate.