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

5.2 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: 3569f4f2fb016e36f5ebeb27f01f3af91e1c360f.
  • PRs #220, #221, #226, #227, and #228 are merged. Main therefore contains the source-first V3 rebuild foundation, the PostgreSQL large-object boundary, bounded Observatory prerequisite preservation, Cloud SQL provider-database residual handling, and the manual exact-revision no-send publication workflow.
  • A narrow current-main correction is in progress so rerunning scripts/kb_apply_prereqs.sql preserves only the exact scoped runtime and proposal-owner ACLs created by ops/gcp_leoclean_runtime_role.sql on the prerequisite's protected table/column surface. Broader grants on that surface and direct role membership continue to fail closed; the runtime provisioner and verifier remain authoritative for role attributes, schema privileges, routines, and the complete least-privilege posture.
  • Local evidence for that correction: 230 focused tests passed; the digest-pinned, network-disabled PostgreSQL 16.14 lifecycle canary passed; two prerequisite reruns were stable; injected ACL and membership drift failed closed; Ruff and git diff --check passed.
  • The GCP VM, private Cloud SQL instance, and scoped Secret Manager secret are known to exist, but no new current-main no-send image has yet been published by the merged #228 workflow.
  • Live Cloud SQL provisioning of leoclean_kb_runtime, VM access to the scoped secret, installation of the no-send service, effective running-process identity, restart behavior, and rollback remain unproven.
  • The source-first V3 reconstruction code is on main, but no canonical GCP promotion is implied by that merge.
  • Telegram still does not route to GCP. The VPS, production traffic, and canonical proposal approvals remain untouched.

Execution order

  1. Review and merge the narrow PostgreSQL migration-order/composability correction from current main.
  2. Run the merged GCP preflight against that exact main revision, then manually dispatch #228's publication workflow for the same revision. Verify the resulting immutable image/config digests and publication receipt.
  3. Provision leoclean_kb_runtime, grant only the staging VM access to the scoped secret, and prove the Cloud SQL role's allowed reads and function-only proposal staging plus denied writes and escalation.
  4. Install the exact immutable image as a separate no-send GCP service. Prove the running process uses the scoped identity without administrator fallback, then prove restart and rollback.
  5. Reconstruct or reconcile the V3 knowledge database into a separately identified canonical candidate and prove row/hash/source receipts before any promotion.
  6. Bind the GCP runtime to the verified V3 canonical database and run database and behavioral parity checks without Telegram sends.
  7. Switch Telegram delivery to the GCP service only after a separate human authorization, prove real response receipts, soak, restart, and restore behavior, and retain an immediate rollback path.
  8. 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

The composability correction requires exact-revision database/security review before merge. GCP role/IAM mutation, V3 canonical promotion, and Telegram cutover remain 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.