# Working Leo Current State - 2026-07-09

Generated UTC: `2026-07-10T01:33:00Z`

## 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 latest VPS 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
  - 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
- 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 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`
- 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`
- 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`
- 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. 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.
4. 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.
5. Keep VPS Leo runtime behavior unchanged while the DB apply path is stabilized.