---
name: teleo-leo-onboarding
description: Use when a worker needs fast context on Teleo/Living IP, Leo, the product architecture, current VPS/GCP split, and the July 9 working-state evidence before doing Leo, Teleo, KB, Telegram, VPS, or GCP work.
---

# Teleo / Leo Onboarding

## Job

Orient the worker before action. Build a current, proof-linked understanding of the company/product, Leo's role, the infrastructure surfaces, and the exact claim ceiling.

## Trigger Phrases

- "onboard to Leo"
- "what is Teleo / Living IP"
- "load Leo VPS context"
- "Fable handoff for Leo"
- "before working on Teleo infra"
- "explain the architecture"

## Core Model

- Teleo is the knowledge/agent infrastructure layer behind Leo.
- Leo is the operator-facing agent expected to answer in Telegram, remember operator context, reason from canonical KB state, stage concrete KB changes, and support approved changes becoming canonical DB rows with proof.
- The immediate July 9 issue is not generic bot liveness. It is m3taversal's expectation that approved KB changes move beyond proposal state when appropriate.
- The VPS is the currently proven Telegram-visible Leo surface.
- GCP is a separate lane. The live gateway, private Cloud SQL canonical rows,
  and exact VPS-to-GCP database parity are proven. Direct passwordless SSH was
  proven but is not currently on-demand because its firewall `/32` no longer
  matches this Mac's egress, and the dedicated OIDC/IAP path is not bootstrapped.
  Telegram delivery, GCP canonical mutation, ongoing replication, and cutover
  remain separate proof rows.

## Architecture Boundaries

- VPS canonical KB: Docker Postgres `teleo-pg`, database `teleo`.
- GCP canonical KB: private Cloud SQL database `teleo_canonical`.
- Canonical rows: `public.claims`, `public.sources`,
  `public.claim_evidence`, `public.claim_edges`, and related identity/strategy
  tables; staging/review is `kb_stage.*`.
- Hermes `state.db` and session JSONL files are conversation continuity, not
  canonical collective knowledge. GCP memory-sync success does not prove the
  canonical KB was restored or updated.
- `SOUL.md` is a rendered/runtime artifact. Direct file edits are not canonical
  identity changes without DB row and render/sync proof.

## Read First

From the repo root, read:

1. `docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md`
2. `docs/reports/leo-working-state-20260709/current-truth-index.md`
3. `docs/reports/leo-working-state-20260709/operator-surface-map.md`
4. `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md`
5. `docs/reports/leo-working-state-20260709/cory-expected-working-leo-outcomes-20260709.md`
6. `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
7. `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
8. `docs/reports/leo-working-state-20260709/gcp-canonical-parity-live-20260712.json`
9. `docs/reports/leo-working-state-20260709/gcp-cory-model-replay-current.json`
10. `docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json`

## Required Status Split

Every status answer must split:

- `VPS runtime`
- `Telegram-visible Leo`
- `KB proposal/staging`
- `Canonical DB apply`
- `GCP parity`
- `Runtime/code provenance`

Do not collapse GCP demo readiness into Telegram completion. Do not collapse proposal approval into canonical DB application.

## Hard Boundaries

- Do not do paid route work or introduce paid-route naming.
- Do not change live VPS Leo runtime behavior unless explicitly authorized.
- Do not production-apply DB packets unless explicitly authorized.
- Do not expose secret contents.
- Do not treat an old summary as current if a fresh readback is cheap.
- Try `ssh teleo-gcp-staging` for passwordless GCP VM access, but verify the
  current public egress matches the firewall `/32`. If it does not, follow the
  exact gate in `gcp-operator-access-blocker-current.json`; do not pretend the
  merged OIDC/IAP workflow is bootstrapped. Do not print the Cloud SQL or Google
  password or create IAM/users inside a read-only lane.
- A benchmark score is not sufficient when an answer contradicts the DB receipt.
  Compare every printed count to `teleo-kb status` or the canonical manifest.

## Output Format

For onboarding handoffs, return:

1. Product/architecture summary in 8 bullets or fewer.
2. Current proof split by VPS, Telegram, DB, GCP.
3. Evidence files actually read.
4. Exact claim ceiling.
5. Next runnable non-production action.
