teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1
teleo-infrastructure/docs/workstreams/gcp-leoclean/goals.md

3.8 KiB
Raw Blame History

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.