155 lines
7 KiB
Markdown
155 lines
7 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 but firewall-source-dependent:
|
|
|
|
```bash
|
|
ssh teleo-gcp-staging
|
|
```
|
|
|
|
It uses `/Users/user/.ssh/google_compute_engine` for
|
|
`billy_livingip_xyz@34.65.143.148`, disables password and keyboard-interactive
|
|
authentication, and does not store a Google password. It works only while the
|
|
Mac's public egress matches `teleo-prod-allow-ssh-current-ip`. On 2026-07-12 the
|
|
Mac returned to `99.35.221.133` while the rule still allowed
|
|
`176.108.138.1/32`, so TCP/22 timed out before authentication.
|
|
|
|
The intended durable 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-12
|
|
|
|
- GCP `teleo_canonical` matches the captured VPS canonical database across
|
|
`39/39` tables and `52,164/52,164` rows.
|
|
- Exact high-signal counts are claims `1837`, sources `4145`, claim evidence
|
|
`4670`, claim edges `4916`, and proposals `26`.
|
|
- Rowsets, schemas, columns, constraints, indexes, functions, types, triggers,
|
|
views, policies, required roles, extensions, and performance checks have zero
|
|
mismatches. `pgcrypto` and `kb_apply` are present.
|
|
- The GCP gateway remained active/running at PID `148735`, `NRestarts=0`, with
|
|
start time `2026-07-09 07:00:04 UTC` throughout restore, swap, and read tests.
|
|
- The reviewed GCP `teleo-kb` wrapper, Cloud SQL tool, and bridge skill were
|
|
synchronized without a service restart. All six `DC-01` through `DC-06`
|
|
database-read routes pass.
|
|
- Generated candidate databases and temporary client/operation directories were
|
|
removed. `teleo_canonical_pre_20260712t1905z` is retained disabled, with zero
|
|
connections, as the verified pre-swap rollback point.
|
|
- A real no-send model replay returned six replies and nominally scored `6/6`,
|
|
but it is rejected as m3taversal-standard proof because `DC-03` and `DC-05`
|
|
printed zero canonical counts. The real database has
|
|
`1837/4145/4916/4670/26`.
|
|
- The harness now enables clone-bound, default-read-only `teleo-kb status`, runs
|
|
under the Hermes virtualenv, and rejects any printed count that differs from
|
|
the canonical status receipt. The hardened rerun and clone cleanup wait on
|
|
the exact operator-access gate below.
|
|
|
|
Primary retained proof:
|
|
|
|
- `docs/reports/leo-working-state-20260709/gcp-canonical-parity-live-20260712.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-cory-model-replay-current.json`
|
|
- `docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json`
|
|
- root task output `outputs/gcp-staging-canonical-parity-20260712T1905Z/`
|
|
- root task output `outputs/gcp-cory-model-replay-20260712T1940Z/`
|
|
|
|
## 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/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_*`.
|
|
|
|
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.
|
|
|
|
## Exact Current Gate
|
|
|
|
All autonomous alternatives have been exhausted: privileged local `gcloud`
|
|
requires Google password reauthentication; direct SSH misses the firewall
|
|
`/32`; the dedicated WIF provider is not bootstrapped; the existing
|
|
`living-ip-github` provider can authenticate only an artifact service account
|
|
that lacks Compute/IAM/Secret Manager/Cloud SQL permissions; no Mullvad or
|
|
Tailscale route exposes the allowed office ISP address.
|
|
|
|
CTA: in Chrome, open the existing tab titled `Google Cloud Platform` for
|
|
`billy@livingip.xyz`, enter the current Google password, click `Next`, then tell
|
|
Codex exactly `GCP reauthenticated`. Do not send the password.
|
|
|
|
After that, rotate only the SSH `/32`, bootstrap and live-test the IAP operator,
|
|
run the hardened replay, delete `teleo_clone_cory_20260712t1940z`, remove its
|
|
run directory, and verify the disabled rollback database still has zero
|
|
connections.
|