97 lines
5.3 KiB
Markdown
97 lines
5.3 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: `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.
|