# Working Leo: Three-Day Outcome And Forward Path

Current as of `2026-07-14 01:08 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. New strict applies now emit a recoverable private row-level replay
receipt so the provenance gap stops growing. 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 gateway behavior was restart-proven at merge
`aa1246c603020bef07a575e4aebf4f2d2ed5db0c`. The deploy-infra workspace is now
at script-and-document merge `7634fc9208f1b43a0037d6c2e246112e18c841fd`;
that operator-only delivery did not restart the gateway. `leoclean-gateway.service`
remains 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 |
| `#134` | canonical three-day VPS/GCP/rebuild outcome handoff |
| `#135` | current post-V3 snapshot and exact local rebuild proof |
| `#136` | private row-level replay receipts for guarded applies |

All ten are merged. The VPS gateway restart proof matches `#133`; the current
deploy-infra operator workspace matches `#136` without a gateway restart.

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

The first implementation step is now live-proven in read-only recovery mode.
The guarded apply CLI captures the immutable strict payload plus exact canonical
rows, generated UUIDs, timestamps, and the exact executed apply-SQL hash into a
private mode-`0600` receipt. `--receipt-only` can regenerate that receipt after
a committed apply, while the payload-controlled rows still match, without
reapplying or mutating the database; recovered engine hashes are explicitly
labeled as reconstructed rather than original execution proof. The VPS canary recovered strict
applied proposal `00957f6c-9883-4015-95a4-6b09367efb0e`, found exactly one
canonical edge, left all counts and the gateway unchanged, and removed the
private temporary file. This prevents future strict applies from becoming
unreplayable; it does not fill the pre-genesis historical gaps or run the final
blank-database compiler.

## 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 |
| New strict-apply replay receipt | live VPS read-only recovery plus tests | Working for receipt capture; full replay runner pending |
| 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-apply-replay-receipt-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.
