# Working Leo: Three-Day Outcome And Forward Path Current as of `2026-07-14 00:28 UTC`. This is the current high-level handoff for what the July 10-14 delivery wave achieved, what is working on the VPS, what still has to move to GCP, and how the database can be recovered or rebuilt without repeatedly teaching Leo through chat prompts. ## Executive Verdict **Whole-system answer: not fully complete yet.** **VPS answer: materially working at the database-grounded handler tier.** Leo can answer broad questions without supplied claim IDs, read current canonical and proposal state, distinguish staged/reviewed/applied knowledge, remember a same-session fact, identify `m3taversal` correctly, explain uncertainty, prepare one source document into exact grounded candidates, stage a review proposal, and survive a gateway restart. The current broad no-post suite passes `15/15`. **GCP answer: prior parity is proven, current parity is not.** A July 12 GCP copy matched the VPS across `39` tables and `52,164` rows and passed an adapter-free no-send model replay. A newer post-V3 VPS dump with `52,167` rows and `29` proposals now restores and verifies locally with zero mismatches, but it has not yet been restored to GCP. The prepared input is current; the cloud replay is still pending. **Database rebuild answer: exact recovery works; semantic recompilation is partial.** A verified snapshot can recreate the current Postgres database in seconds. Rebuilding a blank database from every retained document, extraction, review decision, and apply receipt is not yet complete because historical rows predate a complete replay ledger. ## What Working Leo Means The target is not merely that Leo replies fluently. A working Leo must: 1. Query the current Postgres knowledge base before making a database claim. 2. Find relevant claims, sources, evidence, edges, and proposals without being handed row IDs. 3. Separate chat memory, runtime files, staged proposals, reviewer approval, and canonical applied rows. 4. Turn a new source into grounded candidate knowledge with exact provenance, deduplication, contradiction handling, and review boundaries. 5. Apply only an explicitly reviewed and authorized payload, then return exact row IDs, hashes, `applied_at`, and postflight state. 6. Preserve the relevant behavior and knowledge across a fresh process or restart. 7. Produce the same truth-grounded behavior on GCP against a verified copy. The work moved Leo from prompt-shaped answers toward this database-driven lifecycle. ## Three-Day Movement ### 1. Turn vague failure reports into executable tests The initial report was simply that Leo was not working and could not manipulate the knowledge base. We reconstructed expected behavior from the Telegram history, converted it into direct-claim and open-ended questions, and retained separate proof tiers for: - runtime reply; - database truth; - Telegram-visible delivery; - proposal staging; - canonical apply; - restart persistence; - GCP parity. This stopped a passing unit test, a hidden handler reply, and a visible Telegram reply from being treated as the same result. ### 2. Make current database truth automatic The VPS Hermes runtime now injects fresh database contracts for questions that depend on current state. A response validator checks the answer against the same receipt and replaces an unsupported model draft with a deterministic safe answer when necessary. This covers proposal lifecycle, named proposal packets, source/evidence links, decision-matrix claims, identity canonicality, source intake, schema limits, and the distinction between handler execution and Telegram delivery. ### 3. Make source preparation real The shipped VPS path is now: ```text private source artifact -> canonical duplicate retrieval -> bounded extraction of atomic candidates -> exact source-fragment binding -> provenance and uncertainty manifest -> deterministic strict proposal payload -> pending_review proposal ``` The V3 identity architecture document was the real canary. It exposed and led to repairs for three failures: 1. model-copied quotes were not byte exact; 2. physical line IDs could refer to blank lines; 3. exact source wording was incorrectly planned as canonical claim text. After those repairs, the document produced three atomic candidate claims, exact source bindings, canonical duplicate readback, and corrected proposal `10bc0719-1c2b-5f42-a41e-86e6478692cb`. Current state of that proposal: - status: `pending_review`; - `applied_at`: database `NULL`; - source identity: `document:sha256:59d596e70d26fbc491b4de3228251c308eb9c83cb86ea2dccc9b3342801c5be7`; - no V3 candidate was written to canonical `public.*` tables; - the flawed predecessor `a9eb4158-5aa2-5484-b5a7-3d249588b3ec` is canceled. ### 4. Harden broad reasoning instead of only narrow prompts An early blind 12-question run exposed schema invention, wrong edge semantics, memory used as provenance, excessive answer length, and participant-name bleed. Those failures were repaired as runtime contracts and regression tests. The current broad out-of-sample VPS GatewayRunner suite passes `15/15`, covering: - partner-demo pressure without supplied IDs; - multi-surface source ingestion; - identity and restart truth; - source/evidence linkage; - heterogeneous database composition; - same-session memory set and recall; - exact `m3taversal` participant naming; - runtime versus canonical causality; - shared claims versus agent-specific positions; - forecast resolution without rewriting history; - handler versus Telegram delivery; - autonomous source-intake limits; - schema-valid claim supersession. The suite changed no DB counts, posted nothing to Telegram, left the service unchanged, and removed its temporary profile. ### 5. Prove restart and named-proposal readback The deployed VPS is at merge `aa1246c603020bef07a575e4aebf4f2d2ed5db0c`. After the managed restart, `leoclean-gateway.service` was active with PID `366950`, `NRestarts=0`, and start timestamp `2026-07-14 00:25:49 UTC`. The exact post-restart question claimed that the V3 document was already live because a proposal existed. The live handler correctly answered `No` and returned: - claims: `1837`; - sources: `4145`; - claim edges: `4916`; - claim evidence: `4670`; - proposals: `29`; - matching proposal: `10bc0719-1c2b-5f42-a41e-86e6478692cb`; - status: `pending_review`; - `applied_at`: `none`; - required next state: review, explicit guarded-apply authorization, then public row IDs and hashes. The response validator passed, DB counts remained unchanged, no Telegram message was posted, the live profile was unchanged, the service stayed on the same PID, and the temporary profile was removed. ### 6. Deliver the work rather than leave it local There are `49` merge commits in the delivery window beginning July 10. The most recent source-to-answer chain is: | PR | Outcome | | --- | --- | | `#127` | VPS document preparation and pending-review staging | | `#128` | byte-exact source reference restoration | | `#129` | dense nonempty source fragment IDs | | `#130` | atomic canonical claim text separated from exact quote text | | `#131` | retained V3 document lifecycle proof | | `#132` | named/versioned document proposal matching and readback | | `#133` | live response-validator compatibility for that readback | All seven are merged. The VPS managed deploy stamp matches `#133`. ## VPS: What Works Now An operator can now rely on the VPS for these bounded outcomes: - ask a broad database question and receive current counts and state boundaries; - inspect whether a named proposal is pending, approved, applied, or canceled; - distinguish a proposal from live canonical knowledge; - search canonical claims, evidence, sources, and graph edges; - retain a same-session fact without treating it as database provenance; - address `m3taversal` only by the visible handle; - prepare one text-like source artifact and stage a grounded proposal; - run repeatable no-post handler tests without changing the live profile or DB; - restart the gateway and preserve current database-backed behavior. ## VPS: What Is Not Yet Proven - The current broad suite has not yet been repeated as visible messages in the real Telegram group. Any Telegram work must use the authenticated Google Chrome instance only. - The V3 proposal has not been reviewed or canonically applied. - A complete production source-to-apply lifecycle has not been authorized and run on the live database. - Arbitrary Telegram attachments and tweets are not automatically downloaded, extracted, and staged by the shipped path. - A general scheduled DB-to-`SOUL.md` identity renderer is not proven. ## GCP: What Prior Work Proved The earlier GCP vertical slice proved that: - a VPS canonical snapshot could be restored to private Cloud SQL; - all `39` tables and `52,164` rows matched at that proof point; - schema, constraints, indexes, functions, types, triggers, views, policies, extensions, roles, row hashes, and bounded performance checks matched; - the real GCP GatewayRunner could answer the six direct database questions without an adapter and without sending or mutating state; - false printed counts are rejected unless they equal the database receipt. That remains valid historical proof. It does not prove that GCP currently has the July 13-14 source compiler, V3 proposal, named-proposal readback, or the same `29`-proposal database state. ## GCP: Current Forward Path A fresh post-V3 July 14 source dump is retained at: ```text /private/tmp/working-leo-gcp-refresh-post-v3-20260714/teleo-canonical.dump ``` Its SHA-256 is: ```text 8a49bd487175711d3abc295cd09ed2ca5d5f9dd83e8838f06eeae4bb66a3fc23 ``` It contains `39` tables and `52,167` rows with `29` proposals. A disposable local restore passed with zero parity mismatches and complete cleanup. This is the current source state captured after the V3 lifecycle. The next GCP sequence is: 1. complete Google Cloud CLI reauthentication through the existing Google Chrome sign-in tab; 2. bootstrap the least-privilege IAP/operator identities from the merged repo; 3. restore the captured post-V3 snapshot into a disposable GCP staging database; 4. verify schema, constraints, row counts, hashes, roles, private connectivity, and bounded performance; 5. deploy the current Leo compute/runtime against that copy; 6. replay the same 15-question broad suite plus the exact V3 proposal question; 7. prove no send, no canonical write, cleanup, and no orphan resources. Until this sequence runs, current GCP parity must be reported as pending rather than inferred from the earlier green proof. ## Rebuilding The Database On Demand There are two different meanings of rebuild. ### Exact snapshot recovery: working This is the reliable disaster-recovery path today: ```bash .venv/bin/python ops/run_local_canonical_postgres_rebuild.py \ --dump /private/path/teleo-canonical.dump \ --source-manifest /private/path/source-manifest.jsonl \ --output /tmp/teleo-canonical-rebuild-receipt.json ``` The July 13 canary restored a network-isolated Postgres instance, verified all `39` tables and `52,167` rows, checked structural and row hashes, roles and performance, and removed the container. Total runtime was `10.56` seconds, including `2.71` seconds for `pg_restore`. This recreates the database exactly. It does not re-extract knowledge from the source corpus. ### Semantic source recompilation: partial The desired long-term path is: ```text immutable documents/posts/tweets plus hashes -> deterministic extraction and source binding -> duplicate and contradiction checks -> reviewed typed proposals -> append-only accepted apply payloads and receipts -> canonical Postgres -> identity/render sync -> restart and answer benchmark ``` The new `prepare-source` and `propose-source` commands prove this path for one bounded document through `pending_review`. Disposable clone canaries separately prove review, guarded apply, and later rediscovery. They are not yet one complete blank-database corpus runner. Historical reconstruction still lacks explicit replay provenance for: - `30` canonical claims created outside the mapped import; - `284` mapped sources without a retained staged source row; - `416` evidence links requiring source-synthesis or later-change provenance; - `38` edges requiring later-change receipts or explicit replay rules; - historical duplicate multiplicity and old applied proposals that do not identify every row they changed. The practical policy is therefore: 1. keep the verified snapshot as genesis recovery; 2. require every new accepted change to retain a strict replayable payload and row-level postflight receipt; 3. continue reconstructing historical import rules without allowing the gap to grow; 4. combine genesis plus the accepted ledger into one blank-database compiler; 5. compare the result against the canonical manifest and answer benchmark. This is how Leo improves by composing its database rather than by repeatedly training its chat style. ## Current Outcome Matrix | Outcome | Current tier | Verdict | | --- | --- | --- | | Broad VPS database reasoning | live no-post GatewayRunner, `15/15` | Working | | Same-session memory | live no-post GatewayRunner | Working | | Exact `m3taversal` naming | live no-post GatewayRunner | Working | | Restart survival | managed restart plus exact V3 post-restart readback | Working | | Source document preparation | live VPS private files, exact manifest | Working | | Proposal staging | live VPS `pending_review` | Working | | V3 canonical apply | production DB | Not run or authorized | | Telegram-visible broad suite | real group through Google Chrome | Not yet run | | Prior GCP copy and six-question replay | private Cloud SQL and GCP runtime | Proven historically | | Current GCP parity with VPS `29` proposals | fresh staging replay | Not yet run | | Exact snapshot rebuild | disposable local Postgres | Working | | Full source-to-blank-DB recompilation | complete corpus plus ledger | Partial | ## Immediate Execution Order 1. Commit this context, the `15/15` broad report, and the exact V3 post-restart handler receipt. 2. Use only authenticated Google Chrome for visible Telegram tests and capture the actual replies. 3. Complete Google Cloud CLI reauthentication, bootstrap IAP operator access, and capture a new post-V3 snapshot. 4. Restore and replay the current suite on GCP staging, then clean it up. 5. Run one explicitly reviewed source proposal through guarded apply in a disposable clone first; seek production apply authorization only with the exact payload and receipt plan visible. 6. Build the combined genesis-plus-ledger semantic recompiler. ## Evidence Index - `telegram-handler-m3taversal-oos-suite-current.json` - `telegram-handler-m3taversal-oos-suite-score-current.json` - `telegram-handler-m3taversal-oos-suite-score-current.md` - `telegram-handler-v3-proposal-readback-post-restart-current.json` - `leo-v3-document-source-lifecycle-current.json` - `leo-v3-document-source-lifecycle-current.md` - `gcp-refresh-local-rebuild-current.json` - `gcp-refresh-post-v3-snapshot-current.json` - `gcp-refresh-post-v3-local-rebuild-current.json` - `../../kb-rebuild-and-recompile.md` ## Final Claim Ceiling The last three days delivered a stable, testable, database-grounded Leo on the VPS at the handler tier and a real source-to-review proposal path. They did not finish current GCP parity, Telegram-visible broad proof, a production canonical apply, or complete source-derived reconstruction of the entire historical database. Those are the remaining outcome rows, not reasons to repeat the work that is already merged and live.