15c30f1fbe
Some checks are pending
CI / lint-and-test (push) Waiting to run
* make Leo skill onboarding clean-context reproducible * harden Leo clean-context skill acceptance
174 lines
8.2 KiB
Markdown
174 lines
8.2 KiB
Markdown
---
|
|
name: teleo-gcp-parity-ops
|
|
description: Use for passwordless Teleo GCP VM access, private Cloud SQL canonical parity, GCP Leo runtime readback, m3taversal no-send replay, rollback, and cleanup without collapsing VPS proof into GCP proof.
|
|
---
|
|
|
|
# Teleo GCP Parity Ops
|
|
|
|
## Working Target
|
|
|
|
Restore a copy of the VPS canonical Leo database to GCP, prove exact schema,
|
|
row, role, extension, performance, and private-connectivity parity, then run the
|
|
real GCP Leo read/reasoning path without Telegram sends or DB mutation.
|
|
|
|
## Operator Paths
|
|
|
|
The direct alias is passwordless and was live-verified on 2026-07-14:
|
|
|
|
```bash
|
|
ssh teleo-gcp-staging
|
|
```
|
|
|
|
It uses `/Users/user/.ssh/google_compute_engine` for the configured operator,
|
|
disables password and keyboard-interactive authentication, and does not store a
|
|
Google password. `sudo -n` also works. The route remains
|
|
firewall-source-dependent, so verify `ssh -o BatchMode=yes teleo-gcp-staging true` before a
|
|
long run instead of assuming retained access is current.
|
|
|
|
The intended secondary path is `.github/workflows/gcp-iap-operator.yml`, using
|
|
short-lived GitHub OIDC, IAP, OS Login, and fixed reviewed operations. It is
|
|
merged but not bootstrapped: workflow run `29208215340` failed at auth with
|
|
`invalid_target` because provider `teleo-iap-operator` is absent, disabled, or
|
|
deleted. Do not call this path working until a live `status` run passes.
|
|
|
|
Verified target:
|
|
|
|
- project `teleo-501523`;
|
|
- VM `teleo-prod-1` in `europe-west6-a`;
|
|
- Cloud SQL `teleo-pgvector-standby`, PostgreSQL 16.14;
|
|
- private endpoint `10.61.0.3:5432`, public IP disabled, TLS required;
|
|
- service `leoclean-gcp-prod-parallel.service`.
|
|
|
|
Never print the Cloud SQL or Google password. On the VM, use the attached service account
|
|
and Secret Manager through reviewed wrappers or a short-lived environment
|
|
variable, then unset it.
|
|
|
|
## Two Different Databases
|
|
|
|
- Canonical collective knowledge is Cloud SQL database `teleo_canonical`, with
|
|
`public.*` and `kb_stage.*` tables.
|
|
- Hermes conversation continuity is `state.db` plus session JSONL files. The
|
|
`leoclean-cloudsql-memory-sync.service` snapshot path copies this runtime
|
|
memory; it does not populate or prove canonical claims, sources, evidence,
|
|
edges, or proposals.
|
|
|
|
Do not describe a passing Hermes memory sync as canonical KB parity.
|
|
|
|
## Current Verified State - 2026-07-14
|
|
|
|
- The newest captured VPS database has `39` tables and `52,167` rows, including
|
|
claims `1837`, sources `4145`, claim evidence `4670`, claim edges `4916`, and
|
|
proposals `29`.
|
|
- A disposable private-TLS GCP clone restored that snapshot with exact
|
|
`39/39`-table and `52,167/52,167`-row parity. Rowsets, schema objects, roles,
|
|
extensions, constraints, and performance checks had zero mismatches.
|
|
- A real no-send GCP Hermes turn received an ID-free claim challenge, performed
|
|
`search`, `show`, `evidence`, and `edges`, retrieved the expected claim and
|
|
both source rows, and passed `18/18` runtime checks plus `6/6` reasoning
|
|
outcomes. It did not send Telegram or write the DB.
|
|
- `status` and zero-hit search work on a canonical-only clone without the
|
|
optional `teleo_restore` audit schema. All read commands emit deterministic
|
|
retrieval receipts.
|
|
- The generated clone was deleted. The retained rollback database remains
|
|
connection-disabled with zero sessions. The GCP gateway remained PID
|
|
`148735`, `NRestarts=0`, active/running throughout that bounded experiment.
|
|
- PR `#144` merged the reviewed helper/skill. After deployment, the service
|
|
survived a controlled restart and is active/running at PID `304036`, start
|
|
time `2026-07-14 10:40:17 UTC`. Live post-restart `status` and `search`
|
|
returned Cloud SQL retrieval receipts with unchanged canonical counts.
|
|
- A live regression showed the old wrapper could time out its stronger status
|
|
probe and fall through to a different local tool. Supported GCP KB commands
|
|
now route directly to Cloud SQL and fail closed on errors; two behavioral
|
|
tests enforce that invariant.
|
|
- Persistent GCP `teleo_canonical` remains the older staging copy measured at
|
|
`52,164` rows and `26` proposals. It has not been promoted or cut over.
|
|
|
|
## Open Least-Privilege Candidate
|
|
|
|
PR #148, `Scope GCP Leo runtime to least-privilege Cloud SQL access`, is open as
|
|
of the 2026-07-15 skill-pack reconciliation. It proposes scoped runtime roles,
|
|
secret access, fail-closed Cloud SQL behavior, deployment rollback, and positive
|
|
plus negative permission checks. Those branch files and proposed live outcomes
|
|
are candidate evidence only. Before using them, run:
|
|
|
|
```bash
|
|
gh pr view 148 --json state,mergedAt,mergeCommit,headRefName,url
|
|
```
|
|
|
|
Until the PR is merged and its runtime receipt passes, use only paths present on
|
|
canonical `main`, keep persistent GCP classified as staging, do not promote it,
|
|
and do not infer least-privilege cutover from a branch or dry run.
|
|
|
|
Primary retained proof:
|
|
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-working-leo-20260714.md`
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-restore-current.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-parity-current.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-blind-claim-current.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-cleanup-current.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-db-first-live-deploy-restart-current.json`
|
|
|
|
## Required Parity Rows
|
|
|
|
Track these independently:
|
|
|
|
1. control-plane project, VM, Cloud SQL, private-IP, and TLS identity;
|
|
2. canonical database schema, counts, row hashes, constraints, indexes,
|
|
functions, extensions, roles, and performance;
|
|
3. GCP service PID/restarts plus live profile and tool hashes;
|
|
4. `DC-01` through `DC-06` DB-read readiness;
|
|
5. real no-send model replies, strict score, and exact count consistency;
|
|
6. no-mutation fingerprints, child/profile cleanup, clone deletion, and rollback
|
|
disposition.
|
|
|
|
## Canonical Restore And Replay
|
|
|
|
Use:
|
|
|
|
- `ops/capture_vps_canonical_postgres_snapshot.py` for a single source dump and
|
|
manifest;
|
|
- `ops/restore_gcp_generated_postgres_snapshot.py restore --execute` for a
|
|
receipt-bound private-TLS restore into a bounded `teleo_clone_*` database;
|
|
- `ops/restore_gcp_generated_postgres_snapshot.py cleanup --execute` for exact
|
|
clone cleanup with live-service and rollback readback;
|
|
- `ops/postgres_parity_manifest.sql` for row/catalog/role/performance readback;
|
|
- `ops/verify_postgres_parity_manifest.py --scope gcp_staging` for exact parity;
|
|
- `scripts/run_gcp_generated_db_direct_claim_suite.py` for the adapter-free,
|
|
read-only, no-send six-response replay against a generated `teleo_clone_*`.
|
|
- `scripts/run_gcp_generated_db_blind_claim_canary.py` for the bounded ID-free
|
|
claim challenge, source receipt, reasoning, no-write, and cleanup proof.
|
|
|
|
The replay must use the Hermes virtualenv, not system Python:
|
|
|
|
```bash
|
|
/home/teleo/.hermes/hermes-agent/venv/bin/python \
|
|
scripts/run_gcp_generated_db_direct_claim_suite.py ...
|
|
```
|
|
|
|
The replay is not complete until the generated clone, temporary profile,
|
|
children, upload/run directories, and any temporary client are absent.
|
|
|
|
## Safety And Claim Ceiling
|
|
|
|
- Do not send Telegram messages from the GCP parity lane.
|
|
- Do not apply, approve, or stage KB changes during read/reasoning replay.
|
|
- Do not restart the live GCP gateway for tool-file synchronization unless a
|
|
separate restart window is explicitly requested.
|
|
- Do not call control-plane inventory, memory sync, route readiness, or a
|
|
nominal scorer pass full m3taversal parity.
|
|
|
|
The strongest accepted claim requires exact DB parity plus real no-send model
|
|
replies with truthful counts and cleanup. It still does not prove Telegram
|
|
delivery, GCP canonical mutation, ongoing replication, or production cutover.
|
|
|
|
## Current Access And Next Action
|
|
|
|
Direct SSH and passwordless sudo are currently working. Local `gcloud` still
|
|
requires account reauthentication for control-plane metadata, so the current
|
|
private-IP/TLS proof comes from a live database connection while the public-IP-
|
|
disabled control-plane receipt remains dated 2026-07-12.
|
|
|
|
The next production decision is not another restore drill. It is whether to
|
|
promote a newly verified snapshot into persistent GCP `teleo_canonical` and
|
|
repoint the production read adapter. Until that decision is explicit, keep GCP
|
|
classified as staging and do not expose Cloud SQL publicly.
|