teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1
teleo-infrastructure/.agents/skills/working-leo-cory-outcomes/SKILL.md

7.6 KiB
Raw Blame History

name description
working-leo-cory-outcomes Use when defining, testing, or repairing Leo against Cory/m3taversal's expected outcomes: Telegram memory, critical reasoning, canonical KB truth, proposed-vs-approved-vs-applied state, and guarded DB manipulation.

Working Leo / Cory Outcomes

Job

Keep Leo work anchored to what Cory/m3taversal appears to mean by "working": not just answers, but remembered context, truthful KB state, and approved concrete changes becoming canonical rows through a guarded proof path.

Trigger Phrases

  • "working Leo"
  • "Cory expected outcomes"
  • "m3taversal says Leo is broken"
  • "able to manipulate the knowledge base"
  • "same state as last night"
  • "critical reasoning behavior"

Definition Of Working

A working Leo is a Telegram-facing agent that:

  1. Remembers the current operator conversation.
  2. Grounds KB answers in canonical Teleo Postgres rows when claiming KB truth.
  3. Distinguishes proposed, pending_review, approved, applied, and not applied.
  4. Does not say an approval changed canonical DB state when only kb_stage changed.
  5. Can answer vague, high-level Cory-style incident prompts without being spoon-fed exact proposal IDs.
  6. Can compose the KB from a previously unindexed document, URL, or tweet-like source: retain a byte/hash-bound source locator, extract atomic claims and exact evidence excerpts, preserve useful metadata, and link every claim to its evidence and source.
  7. Detects duplicates, conflicts, updates, and insufficient evidence before staging; uncertainty must remain visible instead of being normalized into a stronger claim.
  8. Can stage those concrete KB changes from Telegram with enough structure for human review, without making staged content canonical.
  9. Can move approved concrete changes through a guarded apply path when authorized.
  10. Retains Cory's caveats and review notes in source/evidence/proposal rows.
  11. Reasons over claims, evidence, sources, edges, and open conflicts as a graph, and can explain which rows support or weaken an answer without being given IDs.
  12. Rebuilds any compiled identity/workspace artifact deterministically from canonical DB rows, reports the source rows and freshness boundary, and does not treat edits to a generated artifact as canonical knowledge.
  13. Produces before/after table-level proof and service stability readback.
  14. Survives an intentional leoclean-gateway.service restart: active before, active after, canonical KB counts unchanged, and a no-post handler smoke still answers.
  15. For a reviewed graph bundle, produces exact payload-controlled row projections, exact table deltas, source-byte binding, and cleanup proof in a disposable runtime before any production permission or apply window.

Current Benchmark Cases

  • Marker memory: WL-LIVE-TG-CORY-20260709.
  • Truth correction: approved != applied.
  • Applied canary: proposal 00957f6c-9883-4015-95a4-6b09367efb0e and edge c167933e-d513-4f43-9335-d5d8aeb259f2.
  • Staged write canary: proposal 8dfedb3f-3aa4-4200-970f-4c0016f6869f, status pending_review, with no new public canonical rows after the test timestamp.
  • Open-ended triage canary: WL-LIVE-TG-CORY-OPEN-20260709, where Leo inferred the likely failure mode from "agents not working / same state as last night" and explained the proposed, approved, and applied split without exact IDs.
  • Old rich proposal packets: 14fa5ecc..., ac036c9d..., and a64df080... are not to be silently production-applied.
  • Guarded apply proof: both generic and real Helmer v3 receipts pass 37/37 in disposable PostgreSQL; production Helmer remains unapplied.
  • Clone-bound handler proof: the real VPS GatewayRunner can inspect the full current-data disposable clone, discover the Helmer proposal, distinguish approved from applied, and produce bound bridge-call evidence without a Telegram post or production change. The proof surface must expose no delivery adapters or send tool, restrict terminal execution to clone-bound read-only KB verbs, kill the handler process group on timeout, and compare production row-content fingerprints before and after. Treat open-ended latency and retries as a separate reliability dimension; a correct answer after a failed tool call is recovered behavior, not a clean pass, and one correct answer does not establish a stable pass rate.
  • Source-composition proof: the real VPS GatewayRunner passed 34/34 in a fresh no-send full-data clone. It searched existing knowledge, extracted two hash-bound conflicting claims from a new document and post, staged a strict proposal, preserved an immutable separated approval, applied exact canonical rows, reopened in a new child process, recalled the prior marker, discovered the new proposal/claims without supplied IDs, read exact evidence/source UUIDs and edges, and explained approved != applied. Production DB fingerprints, service PID/restarts, and live bridge hashes stayed unchanged; all disposable containers, volumes, profiles, credentials, and run directories were removed. This is clone proof, not Telegram delivery or production apply proof.

Cory Direct Questions

For vague or no-context questions, answer directly and then name the one action that would change the proof:

  • "Did the DB change?": split applied rows, approved-but-unapplied proposals, pending rows, and canceled rows. Say Approved is not the same as applied.
  • "Is Helmer in Leo?": say no, not canonical until the exact claims, sources, evidence, edges, reasoning tool, and applied ledger read back from production.
  • "Did the decision matrix approve it?": verify matrix tables first; reviewer approval is not a matrix vote.
  • "Are document pointers the blocker?": answer not just pointer mismatch and separate files, source refs, canonical source rows, review, and apply.
  • "Can I demo KB mutation?": split staging-demo truth from canonical-apply truth.
  • "Did editing SOUL.md change identity?": no canonical identity change without row IDs plus render/sync postflight.

End no-context answers with exactly one Next Cory-style follow-up: line.

Required Answer Discipline

When Leo or a worker answers about KB state, it must say:

  • What source was used: memory, Telegram history, kb_stage, canonical public.*, or filesystem/runtime.
  • Which rows/tables changed.
  • Which proposal IDs are only staged/approved.
  • Which canonical rows exist.
  • What remains pending or deferred.

Not Done

Leo is not working just because:

  • the systemd service is active,
  • Bot API calls work,
  • a local handler canary passed,
  • a proposal was approved,
  • a packet was generated,
  • a clone rehearsal passed.
  • NRestarts=0 was observed without an intentional restart-cycle proof.

Those are evidence. The target is Telegram-visible behavior plus DB-state truth plus a guarded path to canonical rows.

A synthetic one-claim proposal proves only the guarded mutation primitive. It does not prove KB composition. Composition requires a source that was absent at baseline, model-driven extraction into linked source/evidence/claim proposals, dedupe/conflict readback, guarded canonical apply, and an open-ended answer grounded in the new rows after an isolated handler restart.

Proof Files

Use docs/reports/leo-working-state-20260709/current-truth-index.md for current artifact paths. Use docs/reports/leo-working-state-20260709/leo-source-composition-clone-checkpoint-current.md and its JSON companion for the current source-composition claim ceiling. For restart survival, use scripts/collect_leo_restart_survival_proof.py --execute-restart; expected artifacts are docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.json and .md.