---
name: teleo-gcp-parity-ops
description: Use for Teleo/Leo GCP parity, Cloud SQL/cutover readiness, account selection, non-interactive auth blockers, and separating GCP from VPS Telegram proof.
---

# Teleo GCP Parity Ops

## Job

Handle GCP parity as its own lane, with precise auth/account/project facts and no overclaiming from VPS or local proof.

## Trigger Phrases

- "GCP parity"
- "move Leo to GCP"
- "Cloud SQL Teleo"
- "teleo-501523"
- "GCP blocker"
- "VPS then GCP"

## Current Known Facts

- Project: `teleo-501523`
- Expected project-access account: `billy@livingip.xyz`
- Retained blocker: selected account cannot refresh access token non-interactively.
- Other locally available accounts refresh but lack access to `teleo-501523`.
- Current artifact: `docs/reports/leo-working-state-20260709/gcp-db-parity-current-blocker-20260709.json`

Always refresh if cheap before making a current claim.

## Status Split

Never claim GCP complete from:

- VPS service health,
- Telegram group canaries,
- local DB rehearsals,
- GCP account selection alone.

GCP parity needs its own:

- auth readback,
- project access readback,
- Cloud SQL or target DB readback,
- runtime/config parity readback,
- Telegram or operator path proof if the target is GCP-hosted Leo.

## Safe Actions

Allowed:

- `gcloud config list` / account list readbacks,
- non-secret auth status checks,
- project access probes,
- read-only SQL or service discovery where auth works,
- blocker artifact updates.

Stop for:

- password/OTP/KYC,
- raw secret requests,
- irreversible cloud changes,
- production cutover without explicit authorization.

## Blocker Format

If auth is still blocked, retain:

```json
{
  "current_canary": "gcloud account can read teleo-501523 and target DB metadata",
  "attempted_routes": [],
  "exact_gate": "",
  "clear_CTA": "",
  "next_non_user_action": ""
}
```

The CTA must name the exact account and what the operator should do, not a vague "reauth needed."