98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
# 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.
|