--- name: working-leo-cory-outcomes description: 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 stage concrete KB changes from Telegram with enough structure for review. 7. Can move approved concrete changes through a guarded apply path when authorized. 8. Retains Cory's caveats and review notes in source/evidence/proposal rows. 9. Produces before/after table-level proof and service stability readback. ## 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. ## 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. Those are evidence. The target is Telegram-visible behavior plus DB-state truth plus a guarded path to canonical rows. ## Proof Files Use `docs/reports/leo-working-state-20260709/current-truth-index.md` for current artifact paths.