teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1
teleo-infrastructure/docs/reports/leo-working-state-20260709/working-leo-three-day-outcome-and-forward-path-20260714.md
twentyOne2x 8c4551c687 document Working Leo three-day outcomes
2026-07-14 02:36:27 +02:00

15 KiB
Raw Blame History

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 July 13 VPS dump with 52,165 rows and 27 proposals restored and verified locally, but it has not yet been restored to GCP. The live VPS now has 29 proposals after the V3 document canary, so the latest VPS state is ahead of the last GCP proof.

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:

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 July 13 source dump is retained at:

/private/tmp/working-leo-gcp-refresh-20260713/teleo-canonical.dump

Its SHA-256 is:

3fc686ccc423651e86d1f0ad052fa89877215b634a07267a7e26a28e1c2bebe8

It contains 39 tables and 52,165 rows with 27 proposals. A disposable local restore passed with zero parity mismatches and complete cleanup. Because the V3 lifecycle later moved the VPS to 29 proposals, this dump is useful but is not the newest possible source state.

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. capture a new post-V3 VPS snapshot;
  4. restore it into a disposable GCP staging database;
  5. verify schema, constraints, row counts, hashes, roles, private connectivity, and bounded performance;
  6. deploy the current Leo compute/runtime against that copy;
  7. replay the same 15-question broad suite plus the exact V3 proposal question;
  8. 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:

.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,165 rows, checked structural and row hashes, roles and performance, and removed the container. Total runtime was 12.35 seconds, including 2.97 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:

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
  • ../../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.