101 lines
4.6 KiB
Markdown
101 lines
4.6 KiB
Markdown
---
|
|
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. Direct passwordless SSH and `sudo -n` work as of
|
|
2026-07-14. The newest VPS DB was restored to a disposable private Cloud SQL
|
|
clone with exact parity, and a real ID-free no-send reasoning turn passed.
|
|
The merged helper/skill were deployed, supported KB commands now fail closed
|
|
to Cloud SQL, and the service survived a controlled restart with live
|
|
post-restart status/search receipts. Persistent GCP `teleo_canonical` is still
|
|
an older staging copy; Telegram delivery, GCP canonical mutation, ongoing
|
|
replication, promotion, 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/current-truth-index.md`
|
|
2. `docs/reports/leo-working-state-20260709/gcp-db-first-working-leo-20260714.md`
|
|
3. `docs/reports/leo-working-state-20260709/gcp-db-first-parity-current.json`
|
|
4. `docs/reports/leo-working-state-20260709/gcp-db-first-blind-claim-current.json`
|
|
5. `docs/reports/leo-working-state-20260709/gcp-db-first-cleanup-current.json`
|
|
6. `docs/reports/leo-working-state-20260709/gcp-db-first-live-deploy-restart-current.json`
|
|
7. `docs/reports/leo-working-state-20260709/operator-surface-map.md`
|
|
8. `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md`
|
|
9. `.agents/skills/working-leo-m3taversal-outcomes/SKILL.md`
|
|
10. `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
|
|
11. `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
|
|
|
|
## 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.
|
|
- Use `ssh -o BatchMode=yes teleo-gcp-staging true` to preflight passwordless
|
|
GCP VM access. If the firewall route drifts, rediscover the authenticated
|
|
non-secret route before declaring a blocker. The OIDC/IAP workflow is still
|
|
not 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.
|