teleo-infrastructure/docs/reports/leo-working-state-20260709/working-leo-current-state-20260709.md

Working Leo Current State - 2026-07-09

Generated UTC: 2026-07-09T20:32:38Z

Current Working Definition

A working Leo, for Cory/m3taversal's current expectation, is a Telegram-facing agent that remembers the current conversation, grounds KB answers in canonical Teleo Postgres rows, distinguishes proposed / approved / applied / not applied, and moves a specific Cory-approved KB change through a narrow review/apply path into canonical rows with before/after proof. Broad autonomous DB write authority is a feature change, not required for restoration.

What Is Now Proven On VPS

• VPS gateway service is stable: leoclean-gateway.service is active/running, MainPID=3252143, NRestarts=0, WorkingDirectory=/home/teleo, User=teleo.
• Telegram Bot/API readiness is proven for group Leo (-5146042086), and the live adapter accepts the Cory-working canary without posting.
• Live Telegram-visible group canary passed through authenticated Chrome/Telegram Web:
  • turn 1 posted at 21:31 Europe/Zurich and Leo replied LIVE_TG_TURN1_ACK
  • turn 2 posted at 21:32 Europe/Zurich and Leo remembered marker WL-LIVE-TG-CORY-20260709
  • turn 2 reply preserved the correction approved is not the same as applied
  • turn 2 reply reported proposal 00957f6c-9883-4015-95a4-6b09367efb0e as applied
  • turn 2 reply reported edge c167933e-d513-4f43-9335-d5d8aeb259f2 exists in public.claim_edges and the canonical row exists
• Telegram-shaped handler canary passed in the same user/cwd context as the live service:
  • authorized source: agent:main:telegram:group:-5146042086:9070919
  • turn 1 ack passed
  • turn 2 remembered marker and correction
  • turn 3 confirmed proposal 00957f6c-9883-4015-95a4-6b09367efb0e is applied and edge c167933e-d513-4f43-9335-d5d8aeb259f2 exists in public.claim_edges
  • no Telegram post, no live profile synthetic sessions, temp profile removed
• Strict apply canary is proven: one strict add_edge proposal became a canonical public.claim_edges row, and read-only plan verification now passes with after-readback checks.
• Guarded approval helper is installed on VPS at /opt/teleo-eval/workspaces/deploy-infra/scripts/approve_proposal.py, checksum c650b8b24b7a89a9e23859c04d850db441483d407fc81580e250ccad65a61d83, imports successfully, and rejects re-approval of the already-applied canary.
• Chrome/Telegram Web is authenticated and read/write-proven for bot testing in the Leo group through Computer Use.
• Live Telegram-to-DB staging is now proven:
  • turn 3 posted at 22:06 Europe/Zurich and Leo replied LIVE_TG_TURN3_STAGED
  • Leo created proposal 8dfedb3f-3aa4-4200-970f-4c0016f6869f in kb_stage.kb_proposals
  • DB readback shows status=pending_review, proposal_type=add_edge, proposed_by_handle=leo-telegram-live, source_ref=telegram:leo:-5146042086:WL-LIVE-TG-CORY-20260709-T3
  • canonical public tables stayed clean after the T3 timestamp: public.claims=0, public.sources=0, public.claim_edges=0, public.claim_evidence=0 new rows after 2026-07-09 20:06:30 UTC
  • turn 4 posted at 22:08 Europe/Zurich and Leo replied LIVE_TG_TURN4_READBACK, remembered T3, and read back the staged proposal/status/source_ref without staging or applying anything else

What Is Still Not Proven

• Old Cory-approved proposals are still not directly applyable:
  • 14fa5ecc-ac7a-41c1-807d-a2e85b936617
  • ac036c9d-20a0-4ffe-881f-57d6b7bacf22
  • a64df080-8502-42e2-98f4-9bbdecb8da73
• 14fa5ecc normalization is blocked by missing canonical claim/source IDs. The proposal contains approved textual successor candidates, but the exact successor rows A/B/C/D do not already exist as canonical rows.
• Current narrow apply worker supports add_edge, attach_evidence, and revise_strategy; it does not create new public.claims or public.sources rows. Applying 14fa5ecc as Cory likely expects requires either creating/identifying canonical rows first or explicitly widening the guarded apply contract.
• Live approved rich proposal contract preview is now available:
  • 14fa5ecc: 4 claim rows, 5 source rows, 17 edge fragments, 9 evidence fragments; not direct-apply-ready
  • ac036c9d: 3 claim rows, 3 source rows, 6 edge fragments, 5 evidence fragments; not direct-apply-ready
• Rollback-only rich proposal creation plan is now schema-rehearsed against VPS Postgres and left zero generated rows behind:
  • 14fa5ecc: plans 4 claims, 9 sources, 11 claim_evidence rows, 3 supported claim_edges; blocks 14 fragments
  • ac036c9d: plans 3 claims, 6 sources, 6 claim_evidence rows, 1 supported claim_edge; blocks 5 fragments
  • the rehearsal exposed and fixed live constraint mismatches for claims.type and sources.source_type
  • production application remains false until unsupported edge types/context mappings and design decisions are reviewed
• Disposable staging DB commit proof is now complete for the supported subset:
  • created teleo_rich_rehearsal_20260709 from live teleo via dump/restore
  • committed both rich proposal transactions in the disposable DB
  • staging readback showed 7 claims, 15 sources, 17 claim_evidence rows, and 4 claim_edges
  • production generated-row counts stayed zero before and after
  • staging DB and temp SQL/dump files were removed; final DB existence count was 0
• Mapped rich proposal rehearsal is now complete for a larger supported subset:
  • explicit overlay mapped supersedes_component_of -> supersedes, draws_from -> derives_from, revises_or_refines -> supersedes, and one existing capital-allocation target to claim c0000000-0000-0000-0000-00000000000c
  • live rollback rehearsal passed on VPS Postgres and left zero generated rows
  • disposable DB teleo_mapped_rehearsal_20260709 committed 7 claims, 15 sources, 17 evidence rows, and 11 claim_edges
  • production generated-row counts stayed zero before and after
  • clone and temp dump were removed; final DB existence count was 0
• Production apply packet for the mapped supported subset is now generated and clone-proven:
  • packet files live under outputs/rich-proposal-creation-plan-20260709/production-apply-packet-mapped-20260709/
  • live preflight confirms both source proposals are approved, required existing claims are present, and production generated rows are 0/0/0/0
  • live rollback rehearsal inserts the target rows in-transaction and rolls back cleanly; production remains 0/0/0/0
  • disposable clone commit using the packet's authorized commit SQL produced 7 claims, 15 sources, 17 evidence rows, and 11 claim edges
  • clone post-commit readback showed DB-side superseded_by pointers are set by generated supersedes edges for 7da4851c... and d0000000...
  • packet delete rollback now clears those exact superseded_by pointers, deletes generated rows, and returns clone generated-row counts to 0/0/0/0
  • production generated rows remain 0/0/0/0; disposable packet clone and temp dump were removed
• GCP parity was rechecked and remains blocked on account authentication:
  • billy@livingip.xyz is selected for project teleo-501523 but token refresh fails non-interactively
  • billyattnmarket@gmail.com and valentin.meylan68@gmail.com can refresh tokens but do not have access to teleo-501523
  • contact@attn.markets also fails token refresh
  • active gcloud account was restored to billy@livingip.xyz

Current Evidence

• Handler canary: outputs/telegram-gateway-handler-canary-20260709/telegram-gateway-handler-canary-current.md
• Live Telegram canary: outputs/telegram-live-canary-20260709/telegram-live-canary-current.md
• Live Telegram DB write canary: outputs/telegram-live-canary-20260709/telegram-live-db-write-canary-20260709.md
• Gateway adapter canary: outputs/telegram-gateway-canary-20260709/telegram-gateway-canary-current.md
• KB apply plan: outputs/kb-apply-canary-20260709/kb-apply-canary-plan-current.md
• KB apply execute: outputs/kb-apply-canary-20260709/kb-apply-canary-execute-current.md
• 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
• Mapped rich proposal creation plan: outputs/rich-proposal-creation-plan-20260709/rich-proposal-creation-plan-mapped-current.md
• Production apply packet for mapped subset: outputs/rich-proposal-creation-plan-20260709/production-apply-packet-mapped-20260709/production-apply-packet-current.md
• Execution plan: outputs/working-leo-execution-plan-20260709/working-leo-execution-plan-current.md
• Cory expected outcomes: outputs/cory-expected-working-leo-outcomes-20260709.md
• 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
• Live Telegram staging proof image: outputs/leo-db-state-10-telegram-staged-write.svg
• Mapped staging proof image: outputs/leo-db-state-11-mapped-staging.svg
• Production packet proof image: outputs/leo-db-state-12-production-packet.svg
• GCP parity blocker: outputs/gcp-db-parity-current-blocker-20260709.json

Next Actions

1. Keep the live Telegram canary as the top-level regression proof for Cory-working memory + KB audit.
2. Do not auto-apply old freeform approvals.
3. Resolve the remaining non-claim target decisions: telos/shared-root, Rio strategy context, governance gates, and concept-map storage.
4. Keep VPS Leo runtime behavior unchanged while the DB apply path is stabilized.