teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1
teleo-infrastructure/.agents/skills/teleo-gcp-parity-ops/SKILL.md
twentyOne2x c6c8a5eb31 Enforce m3taversal identity and schema truth
2026-07-13 08:55:46 +02:00

7 KiB
Raw Blame History

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 but firewall-source-dependent:

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:

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