teleo-infrastructure/.agents/skills/working-leo-m3taversal-outcomes/SKILL.md

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

Working Leo / m3taversal Outcomes

Job

Keep Leo work anchored to what 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.

Participant Identity Rule

• Address @m3taversal only as m3taversal, exactly.
• Never infer, invent, shorten, or substitute a personal name from a session header, memory, identity document, another chat, or another participant.
• Resolve the speaker from the current Telegram update. Do not transfer identity across users when someone replies, tags an account, or joins the thread.
• The legacy database value m3ta may be reported only as a quoted stored reviewer handle. It is never a form of address.
• Standard response labels are neutral. Use Next proof-changing follow-up:.

Trigger Phrases

• "working Leo"
• "m3taversal 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 m3taversal-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 m3taversal'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

• Historical marker-memory receipt: docs/reports/leo-working-state-20260709/telegram-live-canary-current.json.
• 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 receipt: docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-current.md, 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.

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 proof-changing follow-up: line.

Current Verdict - 2026-07-14

Use not fully yet for the whole m3taversal-standard question until every row below is green at its required tier:

• VPS runtime, database-first direct questions, and intentional restart survival are proven at no-send/runtime tier. The newest captured VPS canonical DB has 39 tables, 52,167 rows, and 29 proposals.
• One natural ID-free VPS claim challenge now passes the complete bounded chain: discover claim, inspect body/evidence/edges, challenge shallow support, propose candidate claims, and preserve review before any write. This does not erase the older broad 12-prompt failure; broad repeated reliability remains a separate benchmark row.
• A fresh VPS snapshot was restored into a disposable private GCP Cloud SQL database with exact 39/39-table and 52,167/52,167-row parity, zero catalog mismatches, and unchanged production service state.
• The same GCP ID-free challenge passed 18/18 runtime checks and 6/6 reasoning outcomes through the real Hermes runner. It used four successful read-only, receipted calls and retrieved the expected claim plus both source rows. No Telegram send or database write occurred.
• The GCP helper now gives deterministic receipts for every read, handles a canonical-only restored DB without the optional audit schema, and returns an honest zero-hit result instead of crashing.
• The reviewed helper/skill are merged and deployed. GCP survived a controlled restart, then live status and search reached persistent Cloud SQL with unchanged counts and stable receipts. Supported commands fail closed instead of falling back to a different local database.
• The disposable GCP database and temporary profiles/processes were removed. Persistent GCP teleo_canonical remains the older staging copy and has not been promoted or cut over.
• Earlier Telegram-visible open-ended behavior and conversation memory are retained proof, but there is no current Telegram-visible run of this full challenge-to-candidate-claims flow.
• Canonical apply primitives are proven in isolation. No proposal from this claim challenge was staged, reviewed, or production-applied, and broad arbitrary document/post reconstruction from original sources remains open.

Do not answer yes merely because all repo tests pass. The final user-facing proof is a visible Telegram conversation plus truthful canonical row readback.

Hard m3taversal Question Bank

Use these without IDs, schema hints, or guardrail-heavy setup. The answer must infer the relevant rows and end with one proof-changing follow-up:

1. I approved Helmer weeks ago. Why isn't it real yet?
2. What can I show a partner in five minutes?
3. This PDF should update Leo. What happens now?
4. What changed in your identity since last week?
5. Make this claim canonical: <claim text>.
6. Are pending proposals stuck because sources are wrong?
7. What does our strategy depend on, and which evidence could overturn it?
8. What's the next KB change I should approve?

Score the answer on directness, fresh canonical lookup, claim/evidence/source reasoning, state semantics, uncertainty, row-level proof, and the usefulness of the next action. Penalize asking m3taversal for IDs that Leo can discover itself.

Also fail the answer when it presents proposed architecture as current v1. The current public.claims table has text and superseded_by, not body, generic metadata, or forecast-resolution fields. Current public.sources has no author/channel/date columns. Current accepted edge types are supports, challenges, requires, relates, contradicts, supersedes, derives_from, cites, causes, constrains, and accelerates.

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

Start with docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md and its JSON companion for the current whole-system verdict and completion rule. 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.