---
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 membership, ownership, ACL, extension, performance, and
private-connectivity parity, then run the
real GCP Leo read/reasoning path without Telegram sends or DB mutation.

The required tier is T3: a live private GCP staging restore, readback,
reasoning, compute attestation, and cleanup receipt. Local restore proof or an
access-gate report does not satisfy this tier.

## Operator Paths

The direct alias was passwordless and live-verified on 2026-07-14:

```bash
ssh teleo-gcp-staging
```

It uses `~/.ssh/google_compute_engine` for the configured operator,
disables password and keyboard-interactive authentication, and does not store a
Google password. That is historical proof, not current reachability. The route
remains firewall-source-dependent. On
2026-07-15, both direct SSH and the private TCP route timed out; verify
`ssh -o BatchMode=yes teleo-gcp-staging true` before a long run and fail closed
if it does not return successfully.

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: the current 2026-07-15 check still lacks the
reviewed operator WIF/IAP authority. Provider `teleo-iap-operator` is absent,
disabled, or deleted (`invalid_target`), and the available artifact identity is intentionally not
a Cloud SQL/Compute operator. Do not call this path working until a live `status` run passes
with the intended operator identity.

Historically verified and intended target; reverify before any new lifecycle:

- 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;
- restore identity `sa-teleo-restore-drill@teleo-501523.iam.gserviceaccount.com`;
- service `leoclean-gcp-prod-parallel.service`.

Direct libpq connections must use `sslmode=verify-full`, a reviewed DNS name
covered by the server certificate, and a private regular CA file. The private
IP is `hostaddr`, not the certificate identity. Never downgrade to
`sslmode=require` or accept an arbitrary `*.iam.gserviceaccount.com` identity.

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 remains VPS PostgreSQL database `teleo`, with
  `public.*` and `kb_stage.*` tables. Persistent Cloud SQL database
  `teleo_canonical` is a staging copy and has not been promoted.
- 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.

## Retained Historical Proof - 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.

That historical clone predates the expanded ownership/ACL and independently
authenticated receipt contract. It remains useful historical row/schema proof,
but it is not current T3 proof under this skill.

## Open Least-Privilege Candidates

PR #148, `Scope GCP Leo runtime to least-privilege Cloud SQL access`, is open as
of the 2026-07-15 skill-pack reconciliation. Draft PR #162, `Harden GCP Leo
runtime least-privilege proof`, is its current hardening successor. They propose
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
gh pr view 162 --json state,mergedAt,mergeCommit,headRefName,url
```

Until a successor 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, exact role attributes, connection limits,
   `default_transaction_read_only` settings and memberships, owners,
   normalized schema/relation/column/function/type ACLs, 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, with a required retained `--authorization-ref` and v2 provenance
  receipt binding the exported snapshot identity plus dump/manifest hashes; it
  requires identical healthy structured source-service states before/after
  (`active/running`, positive PID, nonnegative restart count);
- `ops/restore_gcp_generated_postgres_snapshot.py restore --execute` for a
  receipt-bound private-TLS restore into a bounded `teleo_clone_*` database;
  pass the exact capture `--source-receipt`, and require its live Cloud SQL
  control-plane check to prove public IP disabled before clone creation; it
  requires the exact restore service account plus `--ssl-server-name` and
  `--ssl-root-cert` for certificate-authenticated `verify-full` TLS; it
  writes `target-manifest.jsonl`, `restore-receipt.json`, and the generated
  `gcp-private-connectivity.json` under
  `/var/lib/teleo-gcp-restore-runs/<restore-run-id>/`;
- `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,
  always retaining the canonical output name `gcp-parity.json`;
- `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.
- `ops/attest_gcp_reasoning_compute.py` on the replay VM after blind reasoning
  and before cleanup, binding the reasoning receipt SHA-256 to live GCE metadata
  in `reasoning-compute-attestation.json`;
- a second authorized source capture after cleanup, followed by
  `ops/verify_vps_canonical_snapshot_delta.py`, to retain the explicit
  post-snapshot VPS delta in `source-delta-receipt.json`;
- `ops/verify_gcp_canonical_lifecycle.py` after cleanup to bind the exact source,
  current source, source delta, restore, `gcp_staging` parity, ID-free reasoning,
  reasoning-compute attestation, and cleanup receipts into one fail-closed
  preparation verdict. Caller-writable JSON can never emit T3 from this API;
  even an internally valid bundle returns
  `prepared_external_attestation_required`, `current_tier=T2`, and
  `accepted_by_this_api=false`. Pass `--max-postflight-age-seconds 900` and
  `--max-lifecycle-age-seconds 3600`; the latter bounds both cleanup-to-verdict
  age and restore-to-postflight span.

With `TARGET_DB`, `RESTORE_RUN_ID`, and `PRIVATE_RUN_DIR` set as shown in the
runbook, run the replay-host attestation after the blind receipt passes and
before the receipt-bound cleanup:

```bash
sudo python3 ops/attest_gcp_reasoning_compute.py \
  --reasoning-receipt "${PRIVATE_RUN_DIR}/blind-reasoning-receipt.json" \
  --restore-run-id "$RESTORE_RUN_ID" \
  --target-db "$TARGET_DB" \
  --project teleo-501523 \
  --expected-compute-instance teleo-prod-1 \
  --expected-compute-zone europe-west6-a \
  --expected-private-network projects/teleo-501523/global/networks/teleo-staging-net \
  --expected-restore-service-account sa-teleo-restore-drill@teleo-501523.iam.gserviceaccount.com \
  --output "${PRIVATE_RUN_DIR}/reasoning-compute-attestation.json"
```

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 lifecycle is not complete until the generated clone, temporary profile,
children, transient upload/bundle directories, and any temporary client are
absent. Preserve the private receipt run directory and every useful lifecycle
input, supporting receipt, and verifier output; do not treat that evidence as
transient cleanup. The canonical restore streams through `pg_restore` and
creates no GCS import object.

The source snapshot retains ACL commands while omitting owner commands. The
networkless local preflight can therefore replay captured ACLs after creating
only the exact allowlisted application roles, plus the bounded database-level
grants that `pg_restore` does not apply to an already-created database. The
shared-Cloud-SQL restore still uses `--no-owner` and `--no-privileges`, so GCP
parity must fail until a separately reviewed Cloud-SQL-compatible authorization
replay restores the captured owner/grant semantics. Do not bypass this by
dropping manifest rows or by running the Docker/superuser role bootstrap
blindly on shared Cloud SQL.

Static inspection or a dry run is insufficient for these helpers: verify a new
capture against the live VPS and run the focused tests. A current T3 claim also
requires a separate independently authenticated provider/platform receipt that
the bundle author cannot mint.

## 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 claim emitted by the repository lifecycle verifier is T2
structural consistency. Exact DB parity plus real no-send model replies with
truthful counts and cleanup still requires independent T3 attestation. Neither proves Telegram
delivery, GCP canonical mutation, ongoing replication, or production cutover.

## Current Access And Next Action

As of 2026-07-15, direct SSH and private TCP timed out, local `gcloud` for
`billy@livingip.xyz` requires reauthentication, and the intended operator
WIF/IAP authority is unavailable. The artifact-builder WIF identity must not be
expanded or mistaken for database-operator access. Current retained T2/source
and local restore proof does not satisfy the required T3 lifecycle.

The next action after an authorized operator route is restored is: newest
authorized VPS capture -> disposable private `teleo_clone_*` restore ->
generated private-connectivity receipt -> `gcp-parity.json` -> no-send
m3taversal blind reasoning -> live GCE reasoning attestation -> receipt-bound
clone cleanup -> postflight VPS capture/delta -> eight-receipt lifecycle verdict
within the 900/3600-second freshness bounds. Do not promote
`teleo_canonical`, expose Cloud SQL publicly, send Telegram, or mutate canonical
knowledge.
