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.3 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: f04956ce7c008009c284e1a779a359d20cd02f11.
  • PRs #220, #221, #226, #227, #228, and #229 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 plus the composable prerequisite/runtime ACL boundary.
  • The exact-main GCP preflight passed for f04956c: the staging VM and private PostgreSQL 16 Cloud SQL endpoint were reachable, the Artifact Registry repository was immutable, and no public database attachment was present.
  • Manual publication run #2 was bound to f04956c and failed closed before a Docker build, tag, or push. The pinned Hermes archive contains one empty tinker-atropos/ directory; preparation copied it although the file-only artifact manifest cannot bind it, so the exact directory allowlist rejected the context. The current narrow correction removes only unmanifested empty directories from the copied artifact, validates the complete context before requesting GCP identity, and retains the later pre-push revalidation.
  • 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 copied-artifact empty-directory normalization.
  2. Run the merged GCP preflight against the resulting exact main revision, then manually dispatch the publication workflow for that 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 publication correction requires exact-revision package/release-CI review before merge and a separate authorization before the manual workflow rerun. 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.