Working Leo Current State - 2026-07-09

Generated UTC: 2026-07-10T02:12:56Z

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
Open-ended Cory-style Telegram canary passed:
- marker WL-LIVE-TG-CORY-OPEN-20260709
- Leo inferred the likely failure mode from "agents not working / KB same as last night" without exact proposal IDs
- Leo named kb_stage.kb_proposals, gateway/scheduler logs, and canonical public.* graph deltas as first checks
- Leo distinguished proposed, approved, and applied without staging or mutating the KB
Full live-safe open-ended Telegram suite now passes:
- OE-01 vague incident triage, OE-02 approved-vs-applied without exact IDs, OE-03 framework KB change, OE-04 runtime provenance, and OE-05 mixed action authorization all scored pass=True
- retained score shows coverage=full, passes=5, expected_prompt_count=5, and overclaim_detected=False for every prompt
- service stayed active/running after the suite with MainPID=3252143, NRestarts=0
- post-suite DB safety readback showed no marker rows in kb_stage or canonical public.* tables, and no claims/sources/edges/evidence rows created after the OE-02 start timestamp
- claim ceiling: this proves live read-only Telegram behavior, not production application of the prepared DB packets
Full Cory-style outcome/direct-claim sandbox score now passes:
- mixed evidence score is 20/20: retained live Telegram read-only replies for OE-01 through OE-05, sandbox expected-answer fixtures for CS-01 through CS-09, and no-context direct-claim expected-answer/follow-up fixtures for DC-01 through DC-06
- CS-01 through CS-09 cover demo pressure, stuck KB without IDs, July 5 restore framing, reckless-versus-useful DB agency, knowledge object selection, partner demo truth ceiling, DB-first identity rendering, decision-matrix row provenance, and document artifact linking
- DC-01 through DC-06 cover direct Cory-style questions with no supplied context: did the DB change, is Helmer live, did the decision matrix approve it, are document/source pointers the blocker, can Cory demo KB mutation, and whether SOUL.md edits changed canonical identity
- claim ceiling: this makes the broader Cory-style benchmark executable and scored, but it does not prove live Telegram behavior for the CS/DC prompts
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
Live VPS GatewayRunner direct-claim handler suite now passes the strict Cory direct-claim standard after the authorized-session-plan deploy and scorer refresh:
- exact DC-01 through DC-06 direct-claim benchmark prompts returned 6/6 runtime replies from a temporary leoclean profile
- strict retained benchmark score is 6/6
- no Telegram post, no live profile write, no production DB apply
- DB counts were unchanged before/after: public.claims=1837, public.sources=4145, public.claim_edges=4916, public.claim_evidence=4670, kb_stage.kb_proposals=26
- service stayed active/running during the harness with MainPID=1908033, NRestarts=0, ExecMainStartTimestamp=Fri 2026-07-10 01:04:22 UTC
- temp profile cleanup succeeded, and the scorer now recognizes deployed no-overclaim phrasings such as "does NOT show" and "does not touch the DB" while still requiring row-level/canonical proof language
- DC-02 correctly recognizes Helmer proposal a64df080 as approved/staged or packet-ready but not canonical because applied_at is empty and public.* rows are absent
- DC-03 correctly says the decision-matrix path is not shipped because matrix_voters, proposal_votes, and proposal_decisions tables are absent
- DC-04 correctly avoids a single-cause pointer diagnosis and separates Telegram/file refs, document evaluations, proposal source refs, and canonical public.sources
- DC-05 correctly separates a safe staging-write demo from an authorized canonical apply demo
- DC-06 correctly says direct SOUL.md edits are runtime artifact edits, not canonical identity changes, unless DB rows plus render/sync proof exist
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

The no-context direct-claim behavior Cory is likely to use is now handler-proven for DC-01 through DC-06 on the VPS GatewayRunner path. This was not a Telegram-visible public/group post; it used a temporary profile and left DB counts/service state unchanged.
Old Cory-approved mapped rich proposals are still not fully directly applyable:
- 14fa5ecc-ac7a-41c1-807d-a2e85b936617
- ac036c9d-20a0-4ffe-881f-57d6b7bacf22
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
Helmer 7 Powers approved proposal a64df080-8502-42e2-98f4-9bbdecb8da73 is now full-coverage packet-ready and ledger clone-proven:
- generated row contract is 1 reasoning tool, 5 claims, 13 sources, 7 claim_edges, and 17 claim_evidence rows
- canonical reasoning-tool description is sanitized so Teleo-specific self-positioning/application examples are deferred rather than canonically approved through the framework proposal
- live production preflight confirms the proposal is approved, required existing target claims are present, and generated rows are 0/0/0/0/0
- live production rollback rehearsal inserted the planned rows and proposal-ledger update inside transactions and rolled back cleanly
- disposable clone teleo_helmer_ledger_rehearsal_20260709 committed the packet and read back 1/5/13/7/17
- clone postflight read back proposal a64df080-8502-42e2-98f4-9bbdecb8da73 as applied with applied_by_handle=codex-packet-20260709
- clone delete rollback returned generated rows to 0/0/0/0/0 and restored the proposal ledger to approved
- production generated rows remain 0/0/0/0/0; disposable clone was dropped with final clone count 0
Cross-surface strategy anchor companion packet is now clone-proven:
- first clone attempt exposed a live schema constraint: strategy_node_anchors cannot target both claim_id and source_id
- packet was corrected so the anchor points only to Claim D, while approval provenance remains in Claim D evidence rows
- disposable DB teleo_cross_surface_rehearsal_20260709 applied the mapped base packet first (7 claims, 15 sources, 11 edges, 17 evidence rows)
- companion packet then updated anchor 47f128a0-36c5-4b60-97d4-48c32fa48bc7 from old claim d0000000-0000-0000-0000-000000000005 to Claim D e6ce4e36-15d2-53bc-8b74-dda0efc095c1 at weight 0.85
- cross-surface rollback restored the old anchor, base rollback returned generated rows to 0/0/0/0, production stayed unchanged, temp files were removed, and service remained active with MainPID=3252143, NRestarts=0
Rio strategy-context companion packet is now clone-proven:
- packet creates 2 Rio strategy nodes and 5 strategy anchors after the mapped base packet creates claims A/C/D
- disposable DB teleo_rio_strategy_rehearsal_20260710 applied the mapped base packet first (7 claims)
- Rio packet then inserted Rio capital deployment layer and Rio internet-finance capital product
- anchors connect Claim A to the capital layer, Claim C and Claim D to the product, the product to the capital layer, and the capital layer to the Back shared root
- Rio rollback deleted the 5 anchors and 2 nodes; base rollback returned generated base claims to 0; production stayed unchanged at 0/0/0; temp files and clone were removed; service remained active with MainPID=3252143, NRestarts=0
Governance/concept-map schema companion packet is now clone-proven:
- live schema had public.governance_gates but no claim-to-governance link table, and no first-class concept-map table
- packet creates minimal public.concept_maps, public.claim_concept_map_links, and public.claim_governance_gate_links tables in-transaction
- disposable DB teleo_governance_concept_rehearsal_20260710 applied the mapped base packet first (7 claims)
- governance/concept packet then inserted 1 concept map, 1 claim-concept link, and 2 claim-governance links
- rollback deleted generated rows and dropped the generated tables because they were empty; base rollback returned generated base claims to 0; production stayed unchanged with no generated tables; temp files and clone were removed; service remained active with MainPID=3252143, NRestarts=0
Integrated production-order packet rehearsal is now clone-proven:
- disposable DB teleo_integrated_rehearsal_20260710 applied the full prepared packet set in order: mapped base, cross-surface anchor, Rio strategy context, governance/concept schema, and Helmer 7 Powers
- clone apply footprint matched the integrated manifest: 12 claims, 28 sources, 18 claim edges, 34 claim evidence rows, 1 reasoning tool, 2 Rio strategy nodes, 5 Rio strategy anchors, 1 concept map, 1 concept link, 2 governance links, one Helmer ledger row marked applied, and one cross-surface anchor update
- reverse rollback restored generated base rows to 0/0/0/0, Helmer rows to 0/0/0/0/0, Helmer ledger to approved, cross-surface anchor to old claim d0000000-0000-0000-0000-000000000005 at weight 0.7, Rio rows to 0/0, and generated governance/concept schema to absent
- production readback after the clone proof stayed unchanged: generated base rows 0/0/0/0, Helmer rows 0/0/0/0/0, Helmer ledger approved, generated governance/concept schema absent, service active with MainPID=3252143, NRestarts=0
Authorized-apply readiness verifier now passes:
- ready_for_authorized_production_apply_packet=true
- production_apply_executed=false
- production_apply_authorization_present=false
- verifier checks packet file hashes, manifest apply/rollback order, expected counts, retained clone apply/rollback markers, clone cleanup, and service stability
Authorized apply operator runbook is generated:
- status=ready_not_executed
- ready_for_authorized_operator=true
- command templates cover preflight, apply, postflight, and rollback in manifest dependency order
- pre-apply validation now includes collect_working_leo_production_preflight.py, which statically rejects mutating SQL and wraps each preflight in begin transaction read only
- post-apply regression bundle now requires the non-posting direct-claim handler suite, strict scorer, focused local regression tests, and gateway service readback
- production apply receipt schema now requires explicit authorization record, operator identity, git SHA, preflight/apply/postflight output paths, expected-vs-actual counts, regression paths, service readback, cleanup readback, rollback packet paths, and residual risks
- offline receipt validator is installed and currently reports missing_receipt, as expected before any authorized production apply
- generator does not connect to Postgres or run SQL; production apply still requires explicit authorization
Authorized apply session plan is now retained:
- mode=authorized_apply_session_plan_not_executed
- production_apply_executed=false
- planned output paths exist for pre-apply validation, preflight, apply, postflight, post-apply regression, service readback, cleanup readback, receipt validation, and rollback logs
- all apply steps and all rollback steps require explicit authorization
- non-apply steps are marked non-mutating, so the plan can be used to audit an apply window without itself changing production
Production apply authorization packet is now retained:
- mode=production_apply_authorization_packet_not_executed
- ready_to_request_authorization=true
- production_apply_executed=false
- production_apply_authorization_present=false
- evidence gates pass for runbook readiness, gated session plan, read-only production preflight, direct-claim score, receipt template, and missing-receipt validator status
- the operator authorization template is retained, but it must use a fresh deployed-SHA readback at apply time, and the packet itself does not authorize or execute SQL
Production apply authorization verification is now retained:
- mode=authorization_verification_only
- status=missing_authorization_text
- safe_to_enter_apply_window=false
- production_apply_executed=false
- production_apply_authorization_present=false
- the verifier constructs the exact expected authorization text for deployed SHA 427a9f1a1e114814c750bb3e9e99e3456a6c1539, but refuses because authorization text and operator identity are absent
Live production preflight baseline is now retained:
- the collector ran on the VPS with --transport local-docker, execute_requested=true, mutates_production_db=false, applies_production_packet=false, production_apply_executed=false, and readonly_transaction_wrapper=true
- 5/5 preflight SQL files returned ok=True
- mapped base proposals 14fa5ecc and ac036c9d remain approved, required existing claims are present, and generated rows remain 0/0/0/0
- Helmer proposal a64df080 remains approved, required existing claims are present, and generated rows remain 0/0/0/0/0
- cross-surface/Rio/governance preflights show the expected before-apply baseline: dependent generated base rows are still absent and governance/concept tables are still absent
- this is read-only production preflight evidence, not production apply authorization or proof of canonical mutation
Production apply receipt template is now retained:
- production_apply_executed=false
- valid_production_receipt=false
- pre-filled/baseline fields are current git SHA, preflight output paths, expected counts, current direct-claim score path, rollback packet paths, and known residual risks
- after-apply fields still required are explicit authorization record, operator identity, apply outputs, postflight outputs, actual counts, post-apply regression paths, service readback, and cleanup readback
- this is a template, not a receipt and not a substitute for working-leo-production-apply-receipt-current.json
Production apply receipt assembly is now retained:
- mode=receipt_assembly_offline
- status=not_ready_missing_or_unverified_session_evidence
- receipt_ready=false
- production_apply_executed=false
- current blockers are unverified authorization, missing session logs, and missing actual after-apply counts
- when those artifacts exist, the assembler can emit working-leo-production-apply-receipt-current.json for the existing offline validator
VPS/Hermes/DB identity and document-linking map is now documented:
- the supplied July 9 master/build and database-reference PDFs confirm the intended architecture is DB-first identity: canonical Postgres identity graph rows render to SOUL.md, and evidence depth remains on demand through teleo-kb
- direct SOUL.md edits are profile/runtime artifact edits, not canonical DB updates; they can drift or be overwritten unless represented in canonical rows first
- teleo-kb-apply-worker.service exists but is disabled/inactive and ships inert/report-only unless KB_APPLY_WORKER_ENABLED=1; no active KB_APPLY_RENDER_CMD hook or scheduled 24-hour SOUL renderer was proven
- current VPS schema does not contain the designed decision-matrix tables kb_stage.matrix_voters, kb_stage.proposal_votes, or kb_stage.proposal_decisions; current approval evidence lives in kb_stage.kb_proposals
- live proposal inspection showed pending/approved rows have source_ref pointers, but inspected source refs did not directly match public.sources; document proposals are real staging rows but still need guarded mapping into canonical sources/evidence/edges
GCP parity was rechecked with a repeatable current probe and remains not proven:
- current local config still selects billy@livingip.xyz for project teleo-501523
- the current Codex runner cannot resolve oauth2.googleapis.com, so all token refresh/project readbacks stop at blocked_on_network_dns_before_auth_refresh
- the prior auth-capable July 9 artifact remains useful context: billy@livingip.xyz then failed non-interactive reauth, two other locally cached accounts refreshed but lacked teleo-501523, and contact@attn.markets failed token refresh
- no GCP parity claim is valid until scripts/probe_gcp_db_parity.py reports ready_for_gcp_readonly_parity=true

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
Retained live Telegram benchmark score: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-live-open-ended-benchmark-score-current.md
Full live-safe open-ended Telegram suite: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-current.md
Full live-safe open-ended Telegram suite score: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-score-current.md
Full Cory-style outcome/direct-claim sandbox results: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-cory-outcome-sandbox-results-current.md
Full Cory-style outcome/direct-claim sandbox score: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-cory-outcome-sandbox-score-current.md
Live VPS handler direct-claim suite: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-current.json
Live VPS handler direct-claim suite score: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-score-current.md
Live VPS handler direct-claim suite review: work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-review-current.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
Helmer 7 Powers apply packet: outputs/rich-proposal-creation-plan-20260709/helmer-7powers-20260709/production-apply-packet/production-apply-packet-current.md
Helmer 7 Powers ledger proof log: outputs/rich-proposal-creation-plan-20260709/helmer-7powers-20260709/production-apply-packet/ledger-clone-commit-delete-rollback-current.log
Cross-surface strategy anchor packet: outputs/rich-proposal-creation-plan-20260709/cross-surface-resolution-20260709/cross-surface-packet.json
Cross-surface strategy anchor clone proof log: outputs/rich-proposal-creation-plan-20260709/cross-surface-resolution-20260709/cross-surface-clone-rehearsal-current.log
Rio strategy-context packet: outputs/rich-proposal-creation-plan-20260709/rio-strategy-context-20260710/rio-strategy-packet.json
Rio strategy-context clone proof log: outputs/rich-proposal-creation-plan-20260709/rio-strategy-context-20260710/rio-strategy-clone-rehearsal-current.log
Governance/concept-map packet: outputs/rich-proposal-creation-plan-20260709/governance-concept-20260710/governance-concept-packet.json
Governance/concept-map clone proof log: outputs/rich-proposal-creation-plan-20260709/governance-concept-20260710/governance-concept-clone-rehearsal-current.log
Integrated packet manifest: outputs/rich-proposal-creation-plan-20260709/integrated-20260710/working-leo-integrated-packet.json
Integrated clone proof log: outputs/rich-proposal-creation-plan-20260709/integrated-20260710/working-leo-integrated-clone-rehearsal-current.log
Authorized-apply readiness verifier: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-apply-readiness-current.md
Authorized apply operator runbook: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-authorized-apply-runbook-current.md
Authorized apply session plan: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-authorized-apply-session-plan-current.md
Production apply authorization packet: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-packet-current.md
Production apply authorization verification: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-verification-current.md
Live production preflight baseline: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-preflight-current.md
Production apply receipt template: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-template-current.md
Production apply receipt assembly: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-assembly-current.md
Production apply receipt validation: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-validation-current.md
Cleanup readback: work/teleo-infra-main/docs/reports/leo-working-state-20260709/working-leo-cleanup-readback-current.md
VPS/Hermes/DB mapping: outputs/vps-hermes-db-mapping-20260709.md
Identity render / decision matrix / document artifact image: outputs/leo-db-state-22-identity-render-matrix-artifacts.svg
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
Helmer packet proof image: outputs/leo-db-state-14-helmer-packet.svg
Open-ended Cory-style canary image: outputs/leo-db-state-15-open-ended-canary.svg
Helmer ledger proof image: outputs/leo-db-state-16-helmer-ledger.svg
Cory-style benchmark split image: outputs/leo-db-state-17-cory-outcome-benchmark.svg
Leoclean DB/workspace image: outputs/leo-db-state-18-db-vs-workspace.svg
Claim/body/metadata schema image: outputs/leo-db-state-19-claims-body-metadata.svg
Cross-surface strategy anchor proof image: outputs/leo-db-state-20-cross-surface-anchor.svg
Rio strategy context proof image: outputs/leo-db-state-23-rio-strategy-context.svg
Governance/concept-map schema proof image: outputs/leo-db-state-24-governance-concept-schema.svg
Integrated apply rehearsal proof image: outputs/leo-db-state-25-integrated-apply-rehearsal.svg
Direct-claim handler pass image: work/teleo-infra-main/docs/reports/leo-working-state-20260709/leo-db-state-27-direct-claim-handler-pass.svg
Current GCP parity probe: work/teleo-infra-main/docs/reports/leo-working-state-20260709/gcp-db-parity-current-probe-current.md
Prior GCP parity blocker: outputs/gcp-db-parity-current-blocker-20260709.json

Next Actions

Keep the live Telegram canary as the top-level regression proof for Cory-working memory + KB audit.
Do not auto-apply old freeform approvals.
Do not run production apply without explicit authorization. The mapped base, cross-surface anchor, Rio strategy, governance/concept, and Helmer packets compose in one clone and are ready as a packet set, but are not production-applied.
Use the direct-claim/follow-up benchmark cases as the expectation for Cory-style no-context questions before broadening live tests beyond the safe OE suite.
Keep VPS Leo runtime behavior unchanged while the DB apply path is stabilized.

31 KiB Raw Blame History