teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1
teleo-infrastructure/.agents/skills/teleo-leo-onboarding/SKILL.md
twentyOne2x a5a4163a2b docs: record GCP deploy and restart proof
2026-07-14 12:54:30 +02:00

4.6 KiB
Raw Blame History

name description
teleo-leo-onboarding 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.