# Working Leo Current State - 2026-07-09

Updated UTC: `2026-07-10T15:47:17Z`

## 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

- Fresh VPS gateway readback is stable: `leoclean-gateway.service` is active/running, `MainPID=2999690`, `NRestarts=0`; production counts are `claims=1837`, `sources=4145`, `claim_evidence=4670`, `claim_edges=4916`, `kb_proposals=26`.
- Restart survival is now live-proven as a named Cory-standard proof row, not inferred from passive uptime: `systemctl restart leoclean-gateway.service` returned `0`, service came back active/running with `MainPID=2845730` and `ExecMainStartTimestamp=Fri 2026-07-10 03:24:43 UTC`, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, the temp profile was removed, and the post-restart no-post `DC-01` through `DC-06` handler suite returned six runtime replies. Strict post-restart answer-quality score for that pre-repair retained run was `5/6`, then the VPS/GCP KB bridge skill was tightened for row-level proof, overclaim guardrails, and proposal state semantics. After deploy SHA `090becae1621436467610e529d6328d70964d11f`, the same no-post direct-claim suite strict-scored `6/6`; DB counts stayed unchanged, no Telegram post or production DB apply ran, no live profile changed, and cleanup confirmed no handler process or temp profile left behind.
- 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
- Telegram-visible direct-claim benchmark is now ready to request with exact scope, but not run:
  - target is Telegram group `Leo` (`-5146042086`)
  - exact raw no-context messages are `DC-01` through `DC-06` from the benchmark catalog
  - required proof after authorization is before/after DB counts, Telegram-visible replies, capture receipt, scorer output, final screenshot/accessibility proof, and service readback
  - artifact: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-authorization-packet-current.md`
  - current status remains `telegram_visible_messages_sent=false`
- Telegram-visible direct-claim capture receipt assembler is now retained:
  - artifact: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-capture-receipt-current.md`
  - current status is `awaiting_capture`
  - receipt readiness requires exact operator authorization text, exact `DC-01` through `DC-06` sent texts, nonempty Telegram-visible replies, DB before/after counts, service readback, final screenshot/accessibility proof, and `6/6` direct-claim score
  - the assembler does not send Telegram messages, does not run production apply, and does not prove canonical DB mutation
- Telegram-visible direct-claim pre-send preflight harness is now retained:
  - artifact: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-preflight-current.md`
  - full-access remote readback command: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-remote-readback-command-current.sh`
  - command SHA256: `9bbfbe1de6e3f63e7aa9f73a7f412aa16f8f2f60b3c46f87ee93472290047c89`
  - local authorization-packet checks all pass
  - supplied top-level SSH readback payload passes all remote checks: deploy head matches `.last-deploy-sha` at `63278b6354d3f5f15ed68897be95d484530db59f`, the remote packet is present/nonempty, `leoclean-gateway.service` is active/running, and DB counts are readable
  - service readback: `MainPID=2999690`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 03:47:11 UTC`
  - DB counts before any send: `public.claims=1837`, `public.sources=4145`, `public.claim_edges=4916`, `public.claim_evidence=4670`, `kb_stage.kb_proposals=26`
  - no Telegram message was sent, no production apply ran, and the current preflight status is `pass`
- Argus public KB diagnostics probe is now retained and passing:
  - artifact: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/argus-kb-state-current.md`
  - live `curl` payloads show `3` approved proposals: `14fa5ecc-ac7a-41c1-807d-a2e85b936617`, `ac036c9d-20a0-4ffe-881f-57d6b7bacf22`, and `a64df080-8502-42e2-98f4-9bbdecb8da73`
  - all `3` are `approved_needs_apply_payload`, `worker_applyable_count=0`, and the endpoint is read-only
  - claim ceiling: this proves diagnostics/applyability state only, not Docker row counts, systemd service state, Telegram-visible replies, or production apply
- 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 handler-proven for `DC-01` through `DC-06` on the VPS GatewayRunner path, and an exact Telegram-visible authorization packet is ready. It has still not been sent as a public/group post.
- The Telegram-visible direct-claim capture receipt is not ready because no authorized visible DC capture exists yet.
- The Telegram-visible direct-claim pre-send DB/service/deploy readback is now proven in the retained preflight, but the actual six-message Telegram-visible DC run is not authorized/sent/captured/scored yet.
- Old Cory-approved mapped rich proposals are still not fully directly applyable:
  - `14fa5ecc-ac7a-41c1-807d-a2e85b936617`
  - `ac036c9d-20a0-4ffe-881f-57d6b7bacf22`
- `14fa5ecc` still cannot become one direct strict bundle because its many-successor supersession, strategy/context, and concept/governance fragments require the reviewed companion mappings/schema decisions already captured in the integrated packet set. Missing canonical IDs alone are no longer the general apply-engine limitation.
- The repo implementation now adds an atomic `approve_claim` contract to the guarded apply worker. A fully resolved rich graph normalizes fail-closed into one strict bundle; malformed, missing-key, duplicate, or planner-dropped candidates produce no strict child. Type coercions and candidate-to-row accounting remain visible in `normalization_manifest` for review.
- Review and apply authority are separated in the pending migration: `kb_review` can only execute exact-payload approval, `kb_apply` cannot directly update proposal approval/payload or existing evidence, `kb_gate_owner` owns the SECURITY DEFINER gates with a locked `pg_catalog, pg_temp` search path, and one immutable approval snapshot binds the reviewed type/payload/reviewer/timestamp/note to apply.
- Final isolated-container runtime receipts pass `37/37` twice. The generic bundle's exact payload projection and table deltas are `2/2/2/1/1`; the live-derived Helmer bundle's are `5` claims, `13` sources, `17` evidence rows, `7` edges, and `1` reasoning tool after exact seeding of Leo and five referenced production claims. Stale payload execution, direct privilege probes, replay, source-hash conflict, legacy function overloads, role memberships, and stale ACL paths are refused without partial canonical rows. Read-only live endpoint counts stayed `1837/4145/4670/4916/17/26`, gateway stayed PID `2999690`/`NRestarts=0`, all retained source hashes match the current files, and all inner clones, outer containers, temp workdirs, and the remote source bundle were removed. This does not claim a byte-for-byte comparison of every live row.
- The current production VPS deploy SHA `339565585dc417501488a38135998283988482d1` does not include this pending implementation. No production role/function/table migration ran, the worker remains separately gated, and Helmer remains approved/staged rather than canonical.
- 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 committed verifier artifact uses deployed SHA `a717965b4527819e6d06e3a779e4855629058318` and refuses because exact 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 across four visible owner threads plus support/review agents and remains only partially proven:
  - live Chrome control-plane readback confirms project `teleo-501523` and running VM `teleo-prod-1` in `europe-west6-a`
  - the old blanket DNS diagnosis is stale; shell connectivity can reach Google OAuth, while sandboxed gcloud contexts vary
  - authenticated Chrome now proves exactly one Cloud SQL instance: `teleo-pgvector-standby`, available/runnable PostgreSQL `16.14` Enterprise in `europe-west6-c`, private-only on `teleo-staging-net`, with no public IP
  - Cloud SQL Studio is reachable, but its login dialog exposed no enabled existing IAM database principal and selected built-in password authentication; no credential was inspected or submitted and no SQL ran
  - Cloud SQL row/schema parity, VM runtime parity, and GCP `DC-01` through `DC-06` replies remain unproven
  - exact CTA: authenticate Cloud SQL Studio with an already-existing authorized database principal without sharing the credential, then report `GCP Studio authenticated`; otherwise authorize a separate IAM/database-user enablement window

## 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`
- Telegram-visible direct-claim capture receipt: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-capture-receipt-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`
- Current GCP Cloud SQL inventory: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
- Current GCP Cloud SQL Studio parity gate: `work/teleo-infra-main/docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md`
- Prior 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. Review and land the clone-proven `approve_claim` normal path. Do not deploy its production role grants or enable the apply worker without an explicit production permission-migration window.
4. 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.
5. 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.
6. Keep VPS Leo runtime behavior unchanged while the DB apply path is stabilized.
7. Resume GCP DB parity from an already-authenticated Cloud SQL Studio session; do not handle the raw DB password or create IAM/users inside the read-only lane.