109 lines
6 KiB
Markdown
109 lines
6 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: `3f09bb2b6c8ac3113fc1743529a03c0e9b6ea587`.
|
|
- PRs #220, #221, #226, #227, #228, #229, and #230 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 and normalized
|
|
copied-artifact directory contract.
|
|
- The exact-main GCP preflight passed for `3f09bb2`: 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 #3 passed for that exact revision. Artifact Registry
|
|
independently reports immutable manifest digest
|
|
`sha256:c326154acd0b9ae468449abe1c5fd398b6757f375a1a86fdb40e982c515a19a4`
|
|
and config digest
|
|
`sha256:5c4d5e1bcfc8cd112e5c999217fce064b5be718409708a154e9d58f007a521ad`,
|
|
with the expected revision and package labels. This is a valid intermediate
|
|
candidate, not an approved deployment candidate.
|
|
- The original run artifact still needs to be retained and checked for its
|
|
non-reconstructible publication-outcome journal. Final registry state alone
|
|
cannot prove whether the run freshly pushed, reused, or reconciled a candidate.
|
|
- The published image cannot yet perform a container-bound database proof. A
|
|
narrow follow-up is adding a hash-bound `verify-database` command that uses the
|
|
attached staging service-account metadata identity, the scoped secret, and the
|
|
existing least-privilege SQL verifier from inside the running container. The
|
|
next deployable image must be published from the merge revision containing
|
|
that verifier.
|
|
- The GCP VM, private Cloud SQL instance, and scoped Secret Manager secret are
|
|
known to exist, but the scoped VM secret binding and runtime role have not been
|
|
activated for this service.
|
|
- 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 container-bound database verifier. Run its disposable
|
|
PostgreSQL and OCI fail-closed tests, then publish one exact-main replacement
|
|
candidate and retain the complete publication artifact.
|
|
2. Add the narrow IAP transfer/install/restart/rollback runner that consumes the
|
|
finalized release bundle, pulls only its immutable digest, invokes the existing
|
|
installer, and binds the live container proof to systemd/container identity.
|
|
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 container verifier and deployment runner each require exact-revision human
|
|
review before merge. Publication, GCP role/IAM mutation, live no-send service
|
|
installation, 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.
|