teleo-infrastructure/.agents/skills/teleo-gcp-parity-ops/SKILL.md

name	description
teleo-gcp-parity-ops	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:

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:

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:

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