699a9e7917
Some checks are pending
CI / lint-and-test (push) Waiting to run
- Add reusable Teleo/Leo skills for VPS, GCP, Telegram, KB changes, provenance, and handoff onboarding. - Add guarded KB proposal tooling for approved rich proposals, apply packets, and rollback proof. - Add Cory-style open-ended benchmark prompts and tests alongside the precise regression canaries. `.agents/skills/leo-telegram-canary-ops/SKILL.md` `.agents/skills/teleo-gcp-parity-ops/SKILL.md` `.agents/skills/teleo-infra-provenance/SKILL.md` `.agents/skills/teleo-kb-db-change-workflow/SKILL.md` `.agents/skills/teleo-leo-onboarding/SKILL.md` `.agents/skills/teleo-proof-handoff/SKILL.md` `.agents/skills/teleo-vps-runtime-ops/SKILL.md` `.agents/skills/working-leo-cory-outcomes/SKILL.md` `docs/reports/leo-working-state-20260709/claim-source-contract-preview-current.md` `docs/reports/leo-working-state-20260709/cory-expected-working-leo-outcomes-20260709.md` `docs/reports/leo-working-state-20260709/current-truth-index.md` `docs/reports/leo-working-state-20260709/fable-leo-teleo-onboarding.md` `docs/reports/leo-working-state-20260709/gcp-db-parity-current-blocker-20260709.json` `docs/reports/leo-working-state-20260709/helmer-7powers-creation-plan.json` `docs/reports/leo-working-state-20260709/kb-apply-canary-execute-current.md` `docs/reports/leo-working-state-20260709/kb-apply-canary-plan-current.md` `docs/reports/leo-working-state-20260709/leo-db-state-13-skill-pack.svg` `docs/reports/leo-working-state-20260709/operator-surface-map.md` `docs/reports/leo-working-state-20260709/production-apply-packet-current.md` `docs/reports/leo-working-state-20260709/rich-proposal-creation-plan-mapped-current.md` `docs/reports/leo-working-state-20260709/skill-pack-manifest.json` `docs/reports/leo-working-state-20260709/skill-pack-readme.md` `docs/reports/leo-working-state-20260709/telegram-gateway-handler-canary-current.json` `docs/reports/leo-working-state-20260709/telegram-gateway-handler-canary-current.md` `docs/reports/leo-working-state-20260709/telegram-live-canary-current.json` `docs/reports/leo-working-state-20260709/telegram-live-canary-current.md` `docs/reports/leo-working-state-20260709/telegram-live-db-write-canary-20260709.json` `docs/reports/leo-working-state-20260709/telegram-live-db-write-canary-20260709.md` `docs/reports/leo-working-state-20260709/working-leo-current-state-20260709.md` `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md` `docs/reports/leo-working-state-20260709/working-leo-execution-plan-current.md` `docs/reports/leo-working-state-20260709/working-leo-open-ended-benchmark-spec.json` `scripts/approve_proposal.py` `scripts/kb_claim_source_contract_preview.py` `scripts/kb_rich_proposal_apply_packet.py` `scripts/kb_rich_proposal_creation_plan.py` `scripts/working_leo_open_ended_benchmark.py` `tests/test_approve_proposal.py` `tests/test_kb_claim_source_contract_preview.py` `tests/test_kb_rich_proposal_apply_packet.py` `tests/test_kb_rich_proposal_creation_plan.py` `tests/test_working_leo_open_ended_benchmark.py`
67 lines
2.5 KiB
Markdown
67 lines
2.5 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 Cory/m3taversal's expectation that approved KB changes move beyond proposal state when appropriate.
|
|
- The VPS is the currently proven Telegram-visible Leo surface.
|
|
- GCP parity is a separate lane and is not proven current until the GCP blocker clears.
|
|
|
|
## 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/operator-surface-map.md`
|
|
3. `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md`
|
|
4. `docs/reports/leo-working-state-20260709/cory-expected-working-leo-outcomes-20260709.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.
|
|
|
|
## 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.
|