---
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.
