# Cory Expected Working-Leo Outcomes - 2026-07-09

This is the current working target for restoring Leo. It intentionally scopes out non-Leo route work and keeps the focus on Cory/m3taversal's expected Leo behavior: Telegram-visible reasoning, memory, truthful KB state, and approved KB changes becoming canonical DB state with proof.

## Working Target

A working Leo is a Telegram-reachable agent that:

1. Remembers the ongoing conversation and can use prior turns in the same operator context.
2. Grounds KB answers in canonical Teleo Postgres state, not only in memory or proposal text.
3. Clearly distinguishes `proposed`, `approved`, `applied`, and `not applied`.
4. Does not overclaim that an approval changed the DB when only a proposal ledger changed.
5. When Cory/m3taversal approves a specific concrete KB change, moves that change through a narrow guarded review/apply path into canonical `public.*` rows.
6. Retains Cory's caveats verbatim when an approved change is applied.
7. Produces row-level before/after proof and leaves the live Leo runtime stable.

## What Cory Most Likely Means By "Working"

The best-supported reading is:

- "Able to manipulate the knowledge base" means approved, concrete KB changes can land as real canonical rows, not just text in staging tables.
- "Same state as last night" means Leo is stuck in proposal/approval state and the canonical DB is not moving forward.
- Partner-demo pressure means the path must be visible and reliable through Telegram, not only through local operator scripts.
- Cory may tolerate a more direct write posture than we would design from scratch, but the restored safe behavior should still be auditable: propose, review, apply, read back rows.

## Current Truth

Live behavior is now Cory-working for the restored VPS Telegram memory/KB-audit path, with a clear remaining DB-contract gap:

- The live hosted HTTP Leo chat route still fails the KB-state and memory benchmark.
- The live VPS Telegram-shaped GatewayRunner handler now passes same-session memory and canonical KB audit when launched in the same user/cwd context as the service.
- The handler confirmed proposal `00957f6c-9883-4015-95a4-6b09367efb0e` is `applied` and edge `c167933e-d513-4f43-9335-d5d8aeb259f2` exists in `public.claim_edges`.
- The authenticated Chrome/Telegram Web live group canary now proves the same behavior in the real `Leo` Telegram group: Leo remembered marker `WL-LIVE-TG-CORY-20260709`, preserved `approved is not the same as applied`, and read back the applied proposal plus canonical edge row.
- Old approved/freeform proposals are not safely applyable as-is because they lack strict `payload.apply_payload` and, for `14fa5ecc`, the approved successor claim/source rows do not already exist as canonical IDs.
- Telegram bot/group readiness is proven, and Chrome/Telegram Web is authenticated/read/write-proven through Computer Use for bot testing in the `Leo` group.

Validated lower-tier behavior:

- The VPS service is alive and stable under the live harness.
- Hermes CLI session memory passed a two-turn canary, but that is not the same as Telegram-visible proof.
- One strict KB apply canary mutated canonical DB state without changing Leo runtime.
- The live GatewayRunner handler canary proves Telegram-shaped authorization, same-session memory, and canonical KB audit without posting to Telegram or writing synthetic live-profile sessions.
- A guarded approval helper is installed on VPS and rejects re-approval of an already-applied proposal.
- Approved-proposal normalization confirmed that old freeform approvals need canonical IDs or strict rewrites before apply.
- Claim/source contract preview now converts live approved rich proposals into row-level requirements:
  - `14fa5ecc`: 4 claim rows, 5 source rows, 17 edge fragments, 9 evidence fragments
  - `ac036c9d`: 3 claim rows, 3 source rows, 6 edge fragments, 5 evidence fragments
- Rollback-only rich proposal creation plan now validates the supported subset against live VPS schema without permanent production mutation:
  - `14fa5ecc`: 4 claims, 9 sources, 11 evidence rows, 3 supported edges; 14 blocked fragments remain
  - `ac036c9d`: 3 claims, 6 sources, 6 evidence rows, 1 supported edge; 5 blocked fragments remain
  - before/after generated-row counts remained zero for claims, sources, claim_evidence, and claim_edges
- Disposable staging DB commit proof now shows the supported subset can commit outside production:
  - staging DB after commit: 7 claims, 15 sources, 17 claim_evidence rows, 4 claim_edges
  - production after staging commit: 0 generated claims, 0 generated sources, 0 generated claim_evidence rows, 0 generated claim_edges
  - staging DB was dropped and temp files were cleaned up
- An isolated local Leo chat candidate passes the KB-state and memory benchmark, but it is not deployed.

## Evidence Index

- Working definition and chat excerpts: `outputs/working-leo-definition-20260709.md`, `outputs/working-leo-chat-excerpts-20260709.md`
- Reviewer convergence: `outputs/fable-working-leo-convergence-20260709/fable-working-leo-convergence-report.md`
- VPS live harness: `outputs/leo-vps-live-harness-20260709/leo-vps-live-harness-current-20260709.md`
- Canonical apply canary: `outputs/kb-apply-canary-20260709/kb-apply-canary-execute-current.md`
- Telegram handler canary: `outputs/telegram-gateway-handler-canary-20260709/telegram-gateway-handler-canary-current.md`
- Live Telegram group canary: `outputs/telegram-live-canary-20260709/telegram-live-canary-current.md`
- Old approval normalization: `outputs/approved-proposal-normalization-20260709/approved-proposal-normalization-current.md`
- Claim/source contract preview: `outputs/claim-source-contract-preview-20260709/claim-source-contract-preview-current.md`
- Rich proposal creation plan: `outputs/rich-proposal-creation-plan-20260709/rich-proposal-creation-plan-current.md`
- Execution plan: `outputs/working-leo-execution-plan-20260709/working-leo-execution-plan-current.md`
- Live chat benchmark failure: `outputs/leo-http-chat-benchmark-20260709/leo-http-chat-benchmark-current.md`
- Local candidate chat benchmark pass: `outputs/leo-http-chat-benchmark-20260709/leo-http-chat-benchmark-http-localhost-3129-api-agents-leo-chat.md`
- Telegram readiness proof: `outputs/telegram-visible-readiness-20260709/telegram-visible-readiness-current.md`
- Telegram access supersession: `outputs/telegram-visible-readiness-20260709/telegram-access-supersession-20260709.md`
- Current state report: `outputs/working-leo-current-state-20260709.md`
- Current state image: `outputs/leo-db-state-06-current-proof.svg`
- Current live proof image: `outputs/leo-db-state-07-live-proof.svg`
- Rich proposal plan image: `outputs/leo-db-state-08-rich-plan.svg`
- Staging commit proof image: `outputs/leo-db-state-09-staging-commit.svg`
- Outcome image: `outputs/working-leo-cory-expected-outcomes.png`

## Benchmark Bar

The benchmark for Cory-working Leo should pass these checks:

1. Telegram visibility: passed in the live `Leo` group.
2. Memory: passed with marker `WL-LIVE-TG-CORY-20260709` and the correction from the prior turn.
3. KB audit: passed for proposal `00957f6c-9883-4015-95a4-6b09367efb0e` and edge `c167933e-d513-4f43-9335-d5d8aeb259f2`.
4. Truthfulness: passed for the tested applied canary and prior approved-vs-applied context.
5. Strict apply: passed for one approved concrete `add_edge` change with before/after row proof.
6. Caveat retention: passed for the strict canary approval note; old freeform caveat retention remains part of the claim/source creation contract.
7. Old approval handling: partially passed; old freeform approvals are now normalized into row-level requirements and explicitly not silently applied.
8. Runtime stability: passed; service stayed active/running with `NRestarts=0`. The latest direct-claim suite ran after the expected skill-change restart and stayed on `MainPID=1908033` throughout the harness.
9. Broad Cory-style outcomes and no-context direct claims: specified in the open-ended benchmark as nine disposable-clone/sandbox-first outcome scenarios plus six direct-claim/follow-up scenarios. The mixed-evidence sandbox score passes `20/20` using retained live Telegram evidence for `OE-01` through `OE-05`, fixture answers for `CS-01` through `CS-09`, and direct-claim expected-answer/follow-up fixtures for `DC-01` through `DC-06`; the CS rows are not live Telegram proof. A live VPS GatewayRunner handler run of exact `DC-01` through `DC-06` now returns replies with no DB/service side effects and strict-scores `6/6`, so no-context direct-claim behavior is handler-proven on VPS.

## Scope Boundaries

- Do not broaden this into parked route work before Leo meets the Cory-working bar.
- Do not introduce new naming tied to the parked lane in new artifacts or harnesses.
- Do not deploy the isolated local candidate until the Leo/Kb/memory behavior is reviewed and the Telegram-visible test path is ready.
- Keep the local chat-route candidate as evidence only for now; do not promote it as the Cory fix while its surrounding route surface is outside the current scope.
- Do not auto-apply old freeform approvals without canonical IDs, strict payloads, and explicit review.
- Do not give Leo broad autonomous DB write authority as part of "restoration"; that would be a feature change.

## Next Actions

1. Keep the live Telegram group canary as the top-level user-visible proof and the handler direct-claim suite as the non-posting regression harness.
2. Keep the direct-claim handler suite green: `DC-02` must recognize approved Helmer staging row `a64df080-8502-42e2-98f4-9bbdecb8da73` as approved/unapplied, and `DC-03` must not infer decision-matrix approval while decision-matrix tables are absent.
3. Do not auto-apply old freeform approvals.
4. For `14fa5ecc`, identify or create canonical claim/source rows before producing strict child proposals; otherwise treat claim/source creation support as a separate guarded contract expansion, preferably in a clone first.
5. Re-review and apply only strict proposals with row-level proof and runtime stability readback.
