# Current Truth Index - Leo / Teleo - 2026-07-09

Use this file before making status claims. Prefer fresh VPS/GCP readbacks when cheap; this directory is the retained July 9 evidence snapshot committed to the Teleo infrastructure repo.

## Repository And Skill Routing Addendum - 2026-07-15

- PRs #146 and #147 are merged into canonical `main`. The reconstruction source
  of truth is `docs/kb-rebuild-and-recompile.md`; the merged deterministic paths
  are `ops/run_local_genesis_ledger_rebuild.py`,
  `scripts/leo_turn_execution_manifest.py`, and
  `scripts/verify_leo_unseen_reasoning_chain.py`.
- PR #148 remains open candidate evidence for least-privilege GCP Cloud SQL
  runtime access. Do not use its branch-only runbook, deployment script, role
  migration, or proposed live outcome as canonical `main` until the PR is merged
  and its retained runtime receipt passes.
- The repo-native onboarding entry point is
  `.agents/skills/teleo-leo-onboarding/SKILL.md`. Its standard-library validator
  is `.agents/skills/teleo-leo-onboarding/scripts/validate_skill_pack.py`; run it
  before relying on any skill route from a clean context.
- The deterministic isolated install/routing/cleanup receipt is
  `docs/reports/leo-working-state-20260709/skill-pack-clean-context-canary-current.json`.
- The separate no-history agent onboarding receipt is
  `docs/reports/leo-working-state-20260709/skill-pack-clean-context-agent-review-current.json`.
- Exact snapshot restoration is working. The merged genesis-plus-ledger path is
  an isolated insert-only recovery slice. Full semantic recompilation from every
  original source remains incomplete. None of these local tiers proves a live
  VPS/GCP restore, Telegram delivery, production apply, or GCP promotion.

## GCP Database-First Addendum - 2026-07-14 10:07 UTC

This addendum supersedes the GCP-pending statements in the earlier July 14
section below.

- The current VPS snapshot (`39` tables, `52,167` rows, `29` proposals) was
  restored into a disposable private-TLS GCP Cloud SQL database with exact
  table/row/catalog/role/extension/performance parity.
- A real no-send GCP Hermes turn answered an ID-free challenge to a shallow
  claim. It ran `search`, `show`, `evidence`, and `edges`, retrieved the exact
  claim plus both expected source rows, passed `18/18` runtime checks and `6/6`
  reasoning outcomes, made no DB write, and sent no Telegram message.
- The disposable clone was deleted. The rollback DB remains disabled with zero
  connections. The live GCP gateway stayed PID `148735`, `NRestarts=0` during
  the disposable restore/reasoning/cleanup run.
- PR `#144` then merged the database-first helper and skill. They were deployed
  to GCP and the service survived a controlled restart: active/running at PID
  `304036`, start time `2026-07-14 10:40:17 UTC`.
- Post-restart status and search both routed to persistent Cloud SQL and emitted
  retrieval receipts. The search found the expected claim and both expected
  source IDs/hashes. Canonical counts remained unchanged.
- The post-restart search exposed and repaired a wrapper fallback bug: supported
  GCP KB commands now fail closed on Cloud SQL errors instead of silently using
  a different local database. Full repository tests pass `1240/1240`.
- Persistent GCP `teleo_canonical` is still the older staging copy measured at
  `52,164` rows and `26` proposals. No promotion or production cutover occurred.
- Fast snapshot restore is now proven. Full reconstruction from every original
  document/post/repository artifact remains incomplete.

Newest GCP database-first artifacts:

- `gcp-db-first-working-leo-20260714.md`
- `gcp-db-first-restore-current.json`
- `gcp-db-first-parity-current.json`
- `gcp-db-first-blind-claim-current.json`
- `gcp-db-first-cleanup-current.json`
- `gcp-db-first-live-deploy-restart-current.json`

## Live Addendum - 2026-07-14

The current canonical handoff is
`working-leo-three-day-outcome-and-forward-path-20260714.md`. This section
supersedes the July 13 verdict below.

For the architecture and outcome-level summary, read
`leo-architecture-work-and-outcomes-20260714.md` first.

- VPS gateway behavior was restart-proven at merge
  `aa1246c603020bef07a575e4aebf4f2d2ed5db0c`. Later operator-script and proof
  deliveries through `c7d91b679bd69ee2d1545ee7e169f7c2585d71c2` did not
  restart the gateway: PID `366950`,
  `NRestarts=0`, active/running, start `2026-07-14 00:25:49 UTC`.
- Live counts are claims `1837`, sources `4145`, edges `4916`, evidence `4670`,
  proposals `29`; proposal states are applied `2`, approved `3`, pending review
  `16`, canceled `8`.
- The current broad no-post VPS GatewayRunner suite passes `15/15`, including
  database composition, same-session memory, source intake boundaries, current
  schema, and exact `m3taversal` participant identity. DB and service state were
  unchanged and the temporary profile was removed.
- The real V3 document canary is proposal
  `10bc0719-1c2b-5f42-a41e-86e6478692cb`, `pending_review`, `applied_at: NULL`.
  The deployed post-restart handler finds that exact proposal and correctly
  refuses to call it canonical. No production apply ran.
- Visible Telegram proof for the current broad suite is still pending and must
  use authenticated Google Chrome only.
- Prior GCP parity remains valid at its historical proof point (`39` tables,
  `52,164` rows), but current parity is pending. A post-V3 `52,167`-row,
  `29`-proposal VPS dump restored locally with zero mismatches and complete
  cleanup; it has not yet been restored to GCP.
- Exact snapshot recovery works. Full source-to-blank-database recompilation is
  partial. The guarded apply path now emits or recovers private row-level replay
  receipts for strict applied proposals; the live recovery canary changed no DB
  or service state. See `../../kb-rebuild-and-recompile.md`.

Newest artifacts:

- `leo-architecture-work-and-outcomes-20260714.md`
- `working-leo-three-day-outcome-and-forward-path-20260714.md`
- `telegram-handler-m3taversal-oos-suite-score-current.md`
- `telegram-handler-v3-proposal-readback-post-restart-current.json`
- `leo-v3-document-source-lifecycle-current.md`
- `gcp-refresh-post-v3-snapshot-current.json`
- `gcp-refresh-post-v3-local-rebuild-current.json`
- `kb-apply-replay-receipt-current.json`

## Live Addendum - 2026-07-13

The whole-system m3taversal-standard verdict remains **not fully yet**. This
section supersedes the July 12 status paragraph below.

- VPS deploy before the current identity/schema repair: SHA
  `48777fd984dcfc195e6c33a8d3f7d78bd0c2e344`, gateway PID `1105322`,
  `NRestarts=0`, start `2026-07-13 04:26:31 UTC`.
- VPS canonical counts remain claims `1837`, sources `4145`, edges `4916`,
  evidence `4670`, proposals `26`.
- Narrow direct-claim behavior and restart survival are proven at the no-post
  handler tier. Earlier Telegram-visible direct answers are retained, but the
  latest group transcript exposed a participant naming failure.
- Broad blind behavior is **not reliable**: a clean 12-reply no-post run left DB
  and service state unchanged and removed its temporary profile, but independent
  strict judges accepted only `1/12` and `2/12` outright. See
  `telegram-handler-blind-oos-audit-current.json`.
- The current repair adds exact `m3taversal` naming, neutral follow-up labels,
  current-v1 schema/edge guards, a participant-identity benchmark case, and
  regression tests. Post-deploy Telegram-visible and blind reruns are required.
- GCP exact canonical parity is proven across `39` tables and `52,164` rows.
  The adapter-free real model replay is also accepted at `6/6` with exact count
  consistency and unchanged fingerprint/service/profile.
- GCP durable operation and cleanup remain open. GitHub runs `29227390073` and
  `29227520353` prove the intended target service accounts are absent (`404 Gaia
  id not found`); privileged password/MFA reauthentication is needed to recreate
  least-privilege operator identities. The retained replay clone and run
  directory must then be removed.

Newest decision artifacts:

- `docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md`
- `docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json`
- `docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json`

Some retained filenames and immutable test markers below contain legacy labels.
They are evidence identifiers, not valid forms of address.

## Live Addendum - 2026-07-12

The whole-system m3taversal-standard verdict is **not fully yet**. Do not let older
sections below override this newer status.

- VPS runtime: active and restart-survival proven. Latest gateway readback is
  PID `2403328`, `NRestarts=0`, start `2026-07-12 09:14:10 UTC`.
- VPS canonical KB: claims `1837`, sources `4145`, evidence `4670`, edges
  `4916`, proposals `26`; proposal states are applied `2`, approved `3`,
  pending review `14`, canceled `7`.
- VPS direct m3taversal-standard answers: no-send `DC-01` through `DC-06` strict-score `6/6`.
- Telegram direct m3taversal-standard answers: partial. `DC-01` was visibly sent and its live
  gateway reply strict-passed server-side, but the reply itself is not yet
  captured in Telegram. `DC-02` through `DC-06` are not yet sent.
- DB composition/application: deterministic source-to-proposal, full-data clone
  composition/reasoning, and guarded approved-bundle application are
  isolated-proven. Arbitrary production ingestion and broad production apply
  are not proven or authorized.
- GCP canonical DB: exact VPS parity is proven across `39` tables and `52,164`
  rows over private TLS, with zero row/catalog/role/extension/performance
  mismatches. Gateway PID `148735`, `NRestarts=0` stayed unchanged.
- GCP m3taversal-standard replay: six DB-read routes pass. One real no-send model replay
  nominally scored `6/6`, but it was rejected because two replies printed false
  zero canonical counts. The harness now enables the required `status` read and
  rejects any printed count that differs from the canonical status receipt. A
  hardened rerun is required before this row is green.
- GCP on-demand access: not yet durable. Direct passwordless SSH was proven, but
  this Mac's current egress `99.35.221.133` does not match the allowed
  `176.108.138.1/32`. The merged IAP workflow is not bootstrapped; run
  `29208215340` failed with `invalid_target` for the missing/disabled WIF
  provider. The exact Google password CTA is retained in
  `gcp-operator-access-blocker-current.json`.
- GCP rollback/cleanup: generated parity candidates and temporary tooling were
  removed; disabled rollback database `teleo_canonical_pre_20260712t1905z` has
  zero connections. The current hardened-replay clone must be deleted after the
  rerun.

Newest artifacts:

- `docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md`
- `docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.json`
- `docs/reports/leo-working-state-20260709/leo-post-deploy-direct-claim-repeat-current.json`
- `docs/reports/leo-working-state-20260709/gcp-canonical-parity-live-20260712.json`
- `docs/reports/leo-working-state-20260709/teleo_clone_cory_20260712t1940z-canonical-parity-receipt.json`
- `docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-dc01-partial-current.json`
- `docs/reports/leo-working-state-20260709/gcp-db-first-blind-claim-current.json`
- `docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json`

## Definition And Outcomes

- Working Leo definition: `docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md`
- Legacy-named expected-outcomes evidence: `docs/reports/leo-working-state-20260709/cory-expected-working-leo-outcomes-20260709.md`
- Current state: `docs/reports/leo-working-state-20260709/working-leo-current-state-20260709.md`
- Execution plan: `docs/reports/leo-working-state-20260709/working-leo-execution-plan-current.md`
- Open-ended benchmark spec: `docs/reports/leo-working-state-20260709/working-leo-open-ended-benchmark-spec.json` (5 live-safe open prompts, 9 broader m3taversal-standard outcome scenarios, and 6 no-context direct-claim follow-up prompts for disposable clone/sandbox first)
- Open-ended live Telegram canary: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-cory-style-20260709.md`
- Open-ended live Telegram canary JSON: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-cory-style-20260709.json`
- Retained Telegram benchmark score for the open-ended canary: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-benchmark-score-current.md`
- Retained Telegram benchmark score JSON: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-benchmark-score-current.json`
- Full live-safe open-ended Telegram suite report: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-current.md`
- Full live-safe open-ended Telegram suite score: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-score-current.md`
- Full live-safe open-ended Telegram suite score JSON: `docs/reports/leo-working-state-20260709/telegram-live-open-ended-suite-score-current.json`
- Full m3taversal-standard outcome/direct-claim sandbox results: `docs/reports/leo-working-state-20260709/working-leo-cory-outcome-sandbox-results-current.md`
- Full m3taversal-standard outcome/direct-claim sandbox score: `docs/reports/leo-working-state-20260709/working-leo-cory-outcome-sandbox-score-current.md`
- Full m3taversal-standard outcome sandbox score JSON: `docs/reports/leo-working-state-20260709/working-leo-cory-outcome-sandbox-score-current.json`
- Live VPS handler direct-claim suite report: `docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-current.json`
- Live VPS handler direct-claim suite score: `docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-score-current.md`
- Live VPS handler direct-claim suite review: `docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-review-current.md`
- Telegram-visible direct-claim suite receipt, captured with six prompts/replies and unchanged DB/service state: `docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-suite-current.json`
- Telegram-visible direct-claim retained results: `docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-capture-results-current.json`
- Telegram-visible direct-claim pre-send preflight, passed from supplied top-level SSH readback payload: `docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-preflight-current.md`
- Telegram-visible direct-claim full-access remote readback command: `docs/reports/leo-working-state-20260709/telegram-visible-direct-claim-remote-readback-command-current.sh`
- Argus public KB state probe, read-only HTTP diagnostics: `docs/reports/leo-working-state-20260709/argus-kb-state-current.md`
- Live VPS handler direct-claim follow-up challenge report: `docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-followup-current.json`
- Fable onboarding prompt: `docs/reports/leo-working-state-20260709/fable-leo-teleo-onboarding.md`
- Operator surface map: `docs/reports/leo-working-state-20260709/operator-surface-map.md`
- VPS/Hermes/DB mapping: `docs/reports/leo-working-state-20260709/vps-hermes-db-mapping-20260709.md`
- DB provenance/load-path report: `docs/reports/leo-working-state-20260709/leo-db-provenance-report-20260709T214741Z.md`
- Restart-survival harness: `scripts/collect_leo_restart_survival_proof.py`
- Restart-survival proof output, passed after live execution: `docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.md`
- Restart-survival proof JSON, passed after live execution: `docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.json`
- Restart-survival no-post handler report: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-current.json`
- Restart-survival no-post handler score for the pre-repair restart run, `5/6`: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-score-current.md`
- Final post-repair no-post direct-claim score, `6/6`: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-score-current.md`
- Final post-repair no-post direct-claim summary: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.md`
- Final post-repair no-post direct-claim summary JSON: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.json`

## Telegram And Live Leo Proof

- Live Telegram canary: `docs/reports/leo-working-state-20260709/telegram-live-canary-current.md`
- Live Telegram canary JSON: `docs/reports/leo-working-state-20260709/telegram-live-canary-current.json`
- Live Telegram DB-write canary: `docs/reports/leo-working-state-20260709/telegram-live-db-write-canary-20260709.md`
- Live Telegram DB-write canary JSON: `docs/reports/leo-working-state-20260709/telegram-live-db-write-canary-20260709.json`
- Handler canary: `docs/reports/leo-working-state-20260709/telegram-gateway-handler-canary-current.md`
- Handler canary JSON: `docs/reports/leo-working-state-20260709/telegram-gateway-handler-canary-current.json`
- Handler direct-claim suite: `docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-review-current.md`

## KB DB Apply Proof

- Strict apply plan: `docs/reports/leo-working-state-20260709/kb-apply-canary-plan-current.md`
- Strict apply execute: `docs/reports/leo-working-state-20260709/kb-apply-canary-execute-current.md`
- Approved claim-bundle isolation canary: `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
- Generic approved claim-bundle isolation receipt: `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.json`
- Helmer approved claim-bundle isolation receipt: `docs/reports/leo-working-state-20260709/helmer-approve-claim-clone-canary-current.json`
- Lossless Helmer strict normalization: `docs/reports/leo-working-state-20260709/helmer-approve-claim-normalization-current.json`
- Approved claim-bundle lifecycle harness: `scripts/run_approve_claim_clone_canary.py`
- Approved claim-bundle isolated-container wrapper: `scripts/run_approve_claim_isolated_container_canary.sh`
- Live VPS source-composition clone checkpoint summary: `docs/reports/leo-working-state-20260709/leo-source-composition-clone-checkpoint-current.md`
- Live VPS source-composition clone checkpoint full JSON: `docs/reports/leo-working-state-20260709/leo-source-composition-clone-checkpoint-current.json`
- Claim/source preview: `docs/reports/leo-working-state-20260709/claim-source-contract-preview-current.md`
- Mapped rich proposal plan: `docs/reports/leo-working-state-20260709/rich-proposal-creation-plan-mapped-current.md`
- Mapped production apply packet, not executed in production: `docs/reports/leo-working-state-20260709/production-apply-packet-current.md`
- Mapped production apply packet JSON: `docs/reports/leo-working-state-20260709/production-apply-packet.json`
- Mapped production apply authorized commit SQL, not executed in production: `docs/reports/leo-working-state-20260709/production-apply-authorized-commit.sql`
- Mapped production apply delete rollback SQL: `docs/reports/leo-working-state-20260709/production-delete-rollback.sql`
- Cross-surface strategy anchor companion packet, not executed in production: `docs/reports/leo-working-state-20260709/cross-surface-resolution-current.md`
- Cross-surface packet JSON: `docs/reports/leo-working-state-20260709/cross-surface-packet.json`
- Cross-surface authorized commit SQL, not executed in production: `docs/reports/leo-working-state-20260709/cross-surface-apply-authorized-commit.sql`
- Cross-surface delete rollback SQL: `docs/reports/leo-working-state-20260709/cross-surface-delete-rollback.sql`
- Cross-surface clone commit/delete rollback log: `docs/reports/leo-working-state-20260709/cross-surface-clone-rehearsal-current.log`
- Rio strategy-context companion packet, not executed in production: `docs/reports/leo-working-state-20260709/rio-strategy-context-current.md`
- Rio strategy-context packet JSON: `docs/reports/leo-working-state-20260709/rio-strategy-packet.json`
- Rio strategy-context authorized commit SQL, not executed in production: `docs/reports/leo-working-state-20260709/rio-strategy-apply-authorized-commit.sql`
- Rio strategy-context delete rollback SQL: `docs/reports/leo-working-state-20260709/rio-strategy-delete-rollback.sql`
- Rio strategy-context clone commit/delete rollback log: `docs/reports/leo-working-state-20260709/rio-strategy-clone-rehearsal-current.log`
- Governance/concept-map schema companion packet, not executed in production: `docs/reports/leo-working-state-20260709/governance-concept-current.md`
- Governance/concept-map packet JSON: `docs/reports/leo-working-state-20260709/governance-concept-packet.json`
- Governance/concept-map authorized commit SQL, not executed in production: `docs/reports/leo-working-state-20260709/governance-concept-apply-authorized-commit.sql`
- Governance/concept-map delete rollback SQL: `docs/reports/leo-working-state-20260709/governance-concept-delete-rollback.sql`
- Governance/concept-map clone commit/delete rollback log: `docs/reports/leo-working-state-20260709/governance-concept-clone-rehearsal-current.log`
- Helmer 7 Powers proposal plan: `docs/reports/leo-working-state-20260709/helmer-7powers-creation-plan.json`
- Helmer 7 Powers apply packet, not executed in production: `docs/reports/leo-working-state-20260709/helmer-7powers-production-apply-packet-current.md`
- Helmer 7 Powers apply packet JSON: `docs/reports/leo-working-state-20260709/helmer-7powers-production-apply-packet.json`
- Helmer 7 Powers authorized commit SQL, not executed in production: `docs/reports/leo-working-state-20260709/helmer-7powers-production-apply-authorized-commit.sql`
- Helmer 7 Powers delete rollback SQL: `docs/reports/leo-working-state-20260709/helmer-7powers-production-delete-rollback.sql`
- Working Leo integrated packet manifest, not executed in production: `docs/reports/leo-working-state-20260709/working-leo-integrated-packet.md`
- Working Leo integrated packet JSON: `docs/reports/leo-working-state-20260709/working-leo-integrated-packet.json`
- Working Leo integrated clone rehearsal report: `docs/reports/leo-working-state-20260709/working-leo-integrated-packet-current.md`
- Working Leo integrated clone rehearsal log: `docs/reports/leo-working-state-20260709/working-leo-integrated-clone-rehearsal-current.log`
- Working Leo authorized-apply readiness verifier: `docs/reports/leo-working-state-20260709/working-leo-apply-readiness-current.md`
- Working Leo authorized-apply readiness verifier JSON: `docs/reports/leo-working-state-20260709/working-leo-apply-readiness-current.json`
- Working Leo authorized apply operator runbook, not executed: `docs/reports/leo-working-state-20260709/working-leo-authorized-apply-runbook-current.md`
- Working Leo authorized apply operator runbook JSON: `docs/reports/leo-working-state-20260709/working-leo-authorized-apply-runbook-current.json`
- Working Leo authorized apply session plan, not executed: `docs/reports/leo-working-state-20260709/working-leo-authorized-apply-session-plan-current.md`
- Working Leo authorized apply session plan JSON: `docs/reports/leo-working-state-20260709/working-leo-authorized-apply-session-plan-current.json`
- Working Leo production apply authorization packet, not executed: `docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-packet-current.md`
- Working Leo production apply authorization packet JSON: `docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-packet-current.json`
- Working Leo production apply authorization verification, currently refused/missing text: `docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-verification-current.md`
- Working Leo production apply authorization verification JSON: `docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-verification-current.json`
- Working Leo live production preflight baseline, read-only: `docs/reports/leo-working-state-20260709/working-leo-production-preflight-current.md`
- Working Leo live production preflight baseline JSON: `docs/reports/leo-working-state-20260709/working-leo-production-preflight-current.json`
- Working Leo production apply receipt template, not executed: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-template-current.md`
- Working Leo production apply receipt template JSON: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-template-current.json`
- Working Leo production apply receipt assembly, currently not ready: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-assembly-current.md`
- Working Leo production apply receipt assembly JSON: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-assembly-current.json`
- Working Leo production apply receipt validation, currently missing receipt: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-validation-current.md`
- Working Leo production apply receipt validation JSON: `docs/reports/leo-working-state-20260709/working-leo-production-apply-receipt-validation-current.json`
- Working Leo cleanup readback: `docs/reports/leo-working-state-20260709/working-leo-cleanup-readback-current.md`
- Working Leo cleanup readback JSON: `docs/reports/leo-working-state-20260709/working-leo-cleanup-readback-current.json`
- Helmer live rollback log: `docs/reports/leo-working-state-20260709/helmer-7powers-live-preflight-rollback-current.log`
- Helmer clone commit/delete rollback log: `docs/reports/leo-working-state-20260709/helmer-7powers-clone-commit-delete-rollback-current.log`
- Helmer ledger clone commit/delete rollback log: `docs/reports/leo-working-state-20260709/helmer-7powers-ledger-clone-commit-delete-rollback-current.log`

## GCP

- Current GCP parity probe: `docs/reports/leo-working-state-20260709/gcp-db-parity-current-probe-current.md`
- Current GCP parity probe JSON: `docs/reports/leo-working-state-20260709/gcp-db-parity-current-probe-current.json`
- Current GCP Cloud SQL live inventory: `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
- Current GCP Cloud SQL live inventory JSON: `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.json`
- Canonical Postgres exported-snapshot/local-restore preflight: `docs/reports/leo-working-state-20260709/gcp-canonical-postgres-restore-preflight-current.md`
- Canonical Postgres exported-snapshot/local-restore preflight JSON: `docs/reports/leo-working-state-20260709/gcp-canonical-postgres-restore-preflight-current.json`
- Current GCP Cloud SQL Studio parity gate: `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md`
- Current GCP Cloud SQL Studio parity gate JSON: `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.json`
- Current GCP Leo runtime observability: `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
- Current GCP Leo runtime observability JSON: `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json`
- Prior auth-capable GCP blocker: `docs/reports/leo-working-state-20260709/gcp-db-parity-current-blocker-20260709.json`
- PR #77 VPS auto-deploy/runtime non-change readback: `docs/reports/leo-working-state-20260709/pr77-vps-auto-deploy-runtime-nonchange-current.md`
- Independent VPS source baseline for the GCP working-Leo suite: `docs/reports/leo-working-state-20260709/gcp-working-leo-source-baseline-20260712.json`
- Disposable GCP clone canonical-parity receipt: `docs/reports/leo-working-state-20260709/teleo_clone_20260711t1816z-canonical-parity-receipt.json`
- Passwordless GCP operator bootstrap plan: `ops/plan_gcp_iap_operator_access.py`
- Passwordless fixed-operation GCP workflow: `.github/workflows/gcp-iap-operator.yml`

## Images

- Skill-pack map: `docs/reports/leo-working-state-20260709/leo-db-state-13-skill-pack.svg`
- Helmer packet proof: `docs/reports/leo-working-state-20260709/leo-db-state-14-helmer-packet.svg`
- Open-ended m3taversal-standard canary map: `docs/reports/leo-working-state-20260709/leo-db-state-15-open-ended-canary.svg`
- Helmer ledger packet proof: `docs/reports/leo-working-state-20260709/leo-db-state-16-helmer-ledger.svg`
- m3taversal-standard outcome benchmark map: `docs/reports/leo-working-state-20260709/leo-db-state-17-cory-outcome-benchmark.svg`
- Leoclean DB versus workspace map: `docs/reports/leo-working-state-20260709/leo-db-state-18-db-vs-workspace.svg`
- Claim/body/metadata schema map: `docs/reports/leo-working-state-20260709/leo-db-state-19-claims-body-metadata.svg`
- Cross-surface strategy anchor proof: `docs/reports/leo-working-state-20260709/leo-db-state-20-cross-surface-anchor.svg`
- Forgejo/load/agent update loop map: `docs/reports/leo-working-state-20260709/leo-db-state-21-forgejo-load-agent-loop.svg`
- Identity render / decision matrix / document artifact map: `docs/reports/leo-working-state-20260709/leo-db-state-22-identity-render-matrix-artifacts.svg`
- Rio strategy context packet proof: `docs/reports/leo-working-state-20260709/leo-db-state-23-rio-strategy-context.svg`
- Governance/concept-map schema packet proof: `docs/reports/leo-working-state-20260709/leo-db-state-24-governance-concept-schema.svg`
- Integrated apply rehearsal proof: `docs/reports/leo-working-state-20260709/leo-db-state-25-integrated-apply-rehearsal.svg`
- Direct-claim handler state: `docs/reports/leo-working-state-20260709/leo-db-state-26-direct-claim-handler.svg`
- Direct-claim handler pass state: `docs/reports/leo-working-state-20260709/leo-db-state-27-direct-claim-handler-pass.svg`
- DB loading diagram SVG: `docs/reports/leo-working-state-20260709/leo-db-loading-diagram-20260709T214741Z.svg`
- DB loading diagram Mermaid source: `docs/reports/leo-working-state-20260709/leo-db-loading-diagram-20260709T214741Z.mmd`

## Current Claim Ceiling

- VPS Leo Telegram memory, KB audit, and staged-write canaries are live-proven.
- VPS Leo live-safe open-ended Telegram suite is live-proven and retained-benchmark-scored for `OE-01` through `OE-05`: full selected coverage, `5/5` scored prompts passing, no overclaim, and no marker/staging/canonical KB rows created by the suite.
- The broader sandbox-first m3taversal-standard benchmark has a full-catalog mixed-evidence score: real retained live Telegram evidence for `OE-01` through `OE-05`, sandbox fixture replies for `CS-01` through `CS-09`, and no-context direct-claim expected-answer/follow-up fixtures for `DC-01` through `DC-06`, `20/20` passing. This is not a live Telegram run for the CS/DC prompts.
- After deploy commit `0183a5c805fa3b51d638267afd20f67a1bc3777f`, three fresh VPS GatewayRunner clean-session trials strict-scored `6/6` (`18/18` replies). Every trial posted nothing, made no live profile or production DB change, preserved counts (`1837/4145/4916/4670/26`), removed its temp profile, and left `leoclean-gateway.service` active/running with PID `2403328`, zero restarts, and the same start timestamp. Final cleanup found no matching temp directories.
- Intentional restart survival is now live-proven as a separate required proof row, not implied by `NRestarts=0`: `systemctl restart leoclean-gateway.service` returned `0`, service moved from `MainPID=1908033` to `MainPID=2845730`, stayed active/running after restart and after the no-post handler smoke, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, no live profile change was recorded, temp profile cleanup succeeded, and the post-restart no-post `DC-01` through `DC-06` handler smoke returned six runtime replies. The retained pre-repair post-restart strict score was `5/6`; after deploying repair SHA `090becae1621436467610e529d6328d70964d11f`, the same no-post direct-claim suite strict-scored `6/6` with `DC-01` through `DC-06` all passing, DB counts unchanged, no Telegram post, no production DB apply, no live profile change, and cleanup confirmed. The raw handler JSON is retained on the VPS at `/tmp/leo-post-skill-repair-direct-claim-current.json` with SHA256 `6fffdbafc18913c4fc62feb00906988dee2e696d279f22dd284951a79451f39c`.
- The Telegram-visible direct-claim benchmark was run in group `Leo` (`-5146042086`): all six prompts and replies are visible, and DB/service state is unchanged. The hardened semantic scorer gives `5/6`; `DC-05` incorrectly suggests applying the strict canary `add_edge` path to one of three legacy approved proposals whose payload types do not all match.
- The Telegram-visible direct-claim pre-send preflight now passes from supplied top-level SSH readback payload: deploy head and `.last-deploy-sha` both equal `63278b6354d3f5f15ed68897be95d484530db59f`, the remote packet is present/nonempty, `leoclean-gateway.service` is active/running with `MainPID=2999690`, `NRestarts=0`, and `ExecMainStartTimestamp=Fri 2026-07-10 03:47:11 UTC`, and DB counts read as `public.claims=1837`, `public.sources=4145`, `public.claim_edges=4916`, `public.claim_evidence=4670`, `kb_stage.kb_proposals=26`. The retained remote readback command SHA256 is `9bbfbe1de6e3f63e7aa9f73a7f412aa16f8f2f60b3c46f87ee93472290047c89`; no Telegram messages were sent and no DB apply ran.
- The public Argus KB diagnostics HTTP probe passes from live `curl` payloads captured at `2026-07-10T02:47:53Z`: `3` approved proposals are visible (`14fa5ecc`, `ac036c9d`, `a64df080`), all are `approved_needs_apply_payload`, `worker_applyable_count=0`, and the endpoint is read-only. This supports Leo's expected answer that the approved KB work is not yet directly applyable/canonical, but it is not Docker/Postgres row-count or gateway-service proof.
- Five of six highest-risk direct-claim cases are green. `DC-02` recognizes approved Helmer staging row `a64df080-8502-42e2-98f4-9bbdecb8da73` as approved/unapplied, `DC-03` says the decision-matrix path is not shipped while matrix tables are absent, `DC-04` avoids a single-cause document pointer diagnosis, and `DC-06` separates `SOUL.md` runtime edits from canonical DB identity. `DC-05` remains open for one bounded response-contract repair.
- A strict canonical `add_edge` apply canary is live-proven.
- The repo-owned normal apply path now supports an atomic, insert-only `approve_claim` bundle behind separate `kb_review` and `kb_apply` credentials, a DB-role-to-reviewer principal mapping, and an immutable approval snapshot. Final source-bound isolated-container receipts pass `37/37` for both the generic bundle (`2` claims, `2` sources, `2` evidence rows, `1` edge, `1` reasoning tool) and the real losslessly normalized Helmer bundle (`5/13/17/7/1`). They prove exact payload-controlled projections and table deltas, reviewer/apply separation, denied direct proposal/evidence mutation, stale-payload refusal before canonical writes, replay refusal, source-hash rollback, exact agent/external-claim seeding, hardened role/function/ACL state, and independent inner/outer cleanup. PR #72 source later auto-synchronized to the VPS checkout and deploy stamp at merge commit `771679061f0a0b6463fb7d9cf530eb9d2d4e5440`; the timer journal says no Python changes and no service restart, the commit had no delta under the Leo profile source paths, the gateway stayed PID `2999690`/`NRestarts=0`, the apply worker stayed disabled/inactive, and read-only count endpoints remained `1837/4145/4670/4916/17/26`. This is a source checkout sync, not proof that the production permission migration ran, the worker was enabled, canonical rows changed, or byte-for-byte live content stayed equal. Helmer remains unapplied on production. See `pr72-vps-auto-deploy-runtime-nonchange-current.md`.
- The live VPS source-composition checkpoint now passes `34/34` with zero errors on a fresh no-send full-data clone: Leo searched the current KB, extracted two atomic conflicting claims from a new hash-bound document and post, retained exact evidence/source links, staged a strict proposal, passed separated review and guarded apply, then reopened in a new handler process and discovered/reasoned over the exact canonical proposal, claims, source UUIDs, and conflict edge without supplied IDs while recalling the prior conversation marker. Production counts and row-content fingerprints, gate schema, gateway PID/restarts, and live bridge hashes stayed unchanged. All three experiment containers, anonymous volumes, private credentials, run directories, temporary profiles, and child processes were removed. This proves current-data clone composition and restarted reasoning, not Telegram-visible delivery, production apply, scheduled DB-to-identity recomposition, arbitrary-source breadth, or GCP parity. See `leo-source-composition-clone-checkpoint-current.md`.
- Helmer 7 Powers is full-coverage packet and ledger clone-proven, not production-applied.
- Mapped rich approved proposal packet is clone/rehearsal-proven for the supported subset, not production-applied.
- The strategy-anchor companion write for mapped rich proposal `14fa5ecc` is clone-proven and reversible, not production-applied.
- The Rio strategy-context companion write for mapped rich proposal `14fa5ecc` is clone-proven and reversible: after the mapped base packet exists, it creates `2` Rio strategy nodes and `5` strategy anchors in a disposable clone; production stayed unchanged.
- The governance/concept-map schema companion write is clone-proven and reversible: after the mapped base packet exists, it creates minimal concept-map and claim-to-governance link tables, then inserts `1` concept map, `1` concept link, and `2` governance links in a disposable clone; production stayed unchanged.
- The full integrated packet set is now clone-proven in production dependency order: mapped base, cross-surface anchor, Rio strategy context, governance/concept schema, and Helmer 7 Powers applied together in `teleo_integrated_rehearsal_20260710`, then rolled back in reverse order; production stayed unchanged and the disposable clone/temp files were removed.
- The authorized-apply readiness verifier now passes: packet files exist and hash, apply/rollback order matches the manifest, expected counts match, clone apply/rollback markers are ordered, clone cleanup is proven, service stayed stable, and `production_apply_executed=false`.
- The authorized apply operator runbook is generated and ready-not-executed: it gives preflight/apply/postflight/rollback command templates in manifest order, requires `TELEO_DATABASE_URL`, and now also includes a post-apply regression command bundle plus required production-apply receipt fields and an offline receipt validator. It still does not authorize or execute production SQL.
- The authorized apply session plan is generated and ready-not-executed: it maps concrete output log paths for pre-apply validation, preflight, apply, postflight, post-apply regression, service readback, cleanup readback, receipt validation, and rollback. Apply and rollback steps require explicit authorization; non-apply steps are marked non-mutating.
- The production apply authorization packet is generated and ready-to-request, not authorized/executed: all evidence gates pass, it names the exact integrated packet order and the operator authorization template, requires a fresh deployed-SHA readback at apply time, and keeps `production_apply_executed=false` plus `production_apply_authorization_present=false`.
- The production apply authorization verifier currently refuses the apply window in the committed artifact with fresh deployed SHA `a717965b4527819e6d06e3a779e4855629058318`: `deployed_sha_shape=true`, `fresh_deployed_sha_required=false`, `authorization_text_present=false`, `operator_identity_present=false`, `authorization_text_matches_expected=false`, `safe_to_enter_apply_window=false`, and `production_apply_executed=false`. It now fails only on missing exact authorization text/operator identity, not stale deploy ambiguity.
- The live production preflight baseline now passes through the read-only collector: `5/5` preflight files executed on the VPS with `begin transaction read only`, `mutates_production_db=false`, `applies_production_packet=false`, and `production_apply_executed=false`. Current production still has generated base rows `0/0/0/0`, Helmer rows `0/0/0/0/0`, no generated governance/concept tables, and dependent Rio/cross-surface/governance base rows absent before any apply, as expected.
- The production apply receipt template is generated but intentionally invalid as a final receipt: `production_apply_executed=false`, `valid_production_receipt=false`, and it names the fields that must only be filled after authorized apply execution (`explicit_authorization_record`, `operator_identity`, `apply_output_paths`, `postflight_output_paths`, `actual_after_apply_counts`, `telegram_or_handler_regression_paths`, `service_readback`, `cleanup_readback`).
- The production apply receipt assembler currently refuses final receipt emission: `receipt_ready=false`, `authorization_verified=false`, `all_session_artifacts_exist=false`, `actual_counts_match_expected=false`, no apply/postflight/regression/service/cleanup logs exist, and `production_apply_executed=false`.
- The production-apply receipt validator currently reports `missing_receipt`, which is correct because no production apply has been authorized or executed.
- DB-first identity rendering is now documented from the July 9 PDFs plus VPS readback: canonical identity rows feed rendered `SOUL.md`, direct SOUL edits are not canonical DB updates, and no active renderer/timer/hook is proven in the current VPS readback.
- The decision-matrix approval schema is still a target design on the current VPS: `kb_stage.matrix_voters`, `kb_stage.proposal_votes`, and `kb_stage.proposal_decisions` were not present in live schema readback.
- Pending/approved document proposals are real `kb_stage.kb_proposals` rows with `source_ref`s, but inspected `source_ref`s did not directly match `public.sources`; they still need review/apply mapping into canonical sources/evidence/edges.
- Governance-gate and concept-map targets are now schema-packet-proven, but not production-applied; the live VPS production schema still has no generated governance/concept tables.
- The live VPS runtime behavior should not be changed while the DB apply path is stabilized.
- Latest cleanup readback found no leftover rehearsal/clone/staging database names on the VPS Postgres container and did not mutate production DB or post to Telegram.
- A live Telegram regression canary should be rerun after any production apply; no production apply has been authorized or executed.
- GCP control-plane Chrome readback now proves project `teleo-501523`, running VM `teleo-prod-1` in `europe-west6-a`, and one available private-only PostgreSQL `16.14` Cloud SQL instance, `teleo-pgvector-standby`, in `europe-west6-c`. Cloud SQL Studio is reachable but exposes no enabled existing IAM database principal and requires built-in password authentication; no credential was submitted and no SQL ran. Database-row/runtime/DC-01-through-DC-06 parity therefore remains unproven. The exact next gate is an already-existing authenticated Studio principal or a separately authorized IAM/database-user enablement window.
- GCP Console observability now separately proves `teleo-prod-1` is running and that serial output through `2026-07-10T15:57:54Z` contains recurring successful `leoclean-cloudsql-memory-sync.service` cycles. The latest exact `leoclean-gcp-prod-parallel.service` lifecycle event in the retained serial buffer is a Hermes start on July 9 with no later exact stop/failure. Cloud Logging has `92` guest/platform records over seven days but zero matches for `leoclean`, `hermes`, `gateway`, `postgres`, or `teleo-kb`, and Ops Agent is absent. This is bounded unit-activity evidence, not current PID/restart/SHA/profile/model/auth/Telegram/DB-row parity; no-post m3taversal-standard execution remains unsafe and was not attempted. The agent-created Console tab was closed and no GCP/DB/service/IAM/deploy/credential/Telegram mutation occurred.
- PR #77 auto-deployed to the VPS checkout at merge `1a0abd882d00c1b58fe203f42de42d4eeea61cbf` without restarting Leo: the deploy journal says `No Python changes - services not restarted`, the gateway remained PID `2999690` with `NRestarts=0`, and the apply worker/timer remained disabled and inactive. This proves source synchronization and runtime non-change, not a GCP replay.
- A passwordless GCP operator is implemented and locally validated but is not yet bootstrapped in project `teleo-501523`. It uses GitHub OIDC/Workload Identity Federation, separate status and clone-operation service accounts, IAP TCP forwarding, OS Login, five-minute SSH keys, and a root-owned dispatcher limited to `status`, `direct-claim-replay`, and `cleanup-clone`. It stores no Google password, local refresh token, service-account JSON key, or API key. One final authenticated GCP admin session is still required to install and verify the IAM/IAP/OS Login/dispatcher path; the old public `/32` rule must remain enabled until the workflow status artifact passes.
- The broader GCP working-Leo runner now has a complete `20`-prompt catalog and requires `32` GCP-executable non-tautological composition checks plus lifecycle, role-separation, immutable-source, and secret-redaction gates. Local tests and validation-only execution pass, and an independent VPS source baseline is retained with counts `1837/4145/4670/4916/17/26`; live GCP execution remains unproven because the SHA-bound target-identity receipt, four separated database roles/credentials, and passwordless operator bootstrap are not yet present. This does not inherit or claim the VPS-only `34/34` result.
