Working Leo source staging and refresh proof - 2026-07-13

Outcome

Leo now has a deployed VPS command that converts prepared, hash-bound source inputs into one reviewable kb_stage.kb_proposals row. The command does not apply the proposal and has no public.* write path. Broad report-learning questions now state the same capability boundary instead of claiming that a Telegram attachment is automatically extracted and learned.

This proves prepared-input staging and a recoverable current database snapshot. It does not prove Telegram-visible delivery, automatic chat attachment extraction, canonical apply, or the refreshed GCP restore/replay.

Live VPS proof

Deployed source command: teleo-kb propose-source from merged PR #123.
Deployed answer-boundary repair: merge 5dfcd32c34a8be15a064ff0c51d80fb39d3c9732 from PR #124.
First source run created proposal b426019e-7eaa-5a52-be9b-27d771880802 with status pending_review and applied_at = NULL.
Counts moved from 26 to 27 proposals while canonical counts stayed at 1,837 claims, 4,145 sources, 4,670 evidence rows, and 4,916 claim edges.
Exact replay returned the same proposal ID with created = false and proposal delta zero.
Independent proposal readback showed one claim candidate, two source rows in the proposed apply payload, two evidence links, exact source hashes, and no review or apply receipt.
Both private VPS receipts were mode 0600.

Raw receipts:

vps-source-proposal-first-current.json
vps-source-proposal-idempotent-current.json

Broad answer repair

The out-of-sample prompt was:

If I send you a report here, can you learn it into your knowledge base and make it part of what you know? What actually happens right now?

Before the repair, Leo said it would extract and stage the report directly from chat. That was beyond the shipped capability. After deployment, the live VPS GatewayRunner selected the source_intake contract and enforced an answer that says:

sending a report in chat does not itself create a proposal or persistent knowledge;
chat attachment capture/extraction is not connected;
prepared artifact, UTF-8 text, extraction manifest, locator, and hash can be staged to kb_stage.kb_proposals;
no public.* rows are created during staging;
canonical knowledge still requires review, explicit apply authorization, and a postflight receipt.

The handler run made no Telegram post, changed no database count, changed no live profile, preserved the gateway PID/start time, and removed its temporary profile. See telegram-handler-source-intake-oos-current.json.

Current rebuild proof

A fresh repeatable-read snapshot captured all 39 tables and 52,165 rows from the VPS after the staging canary. Its custom-format dump SHA-256 is 3fc686ccc423651e86d1f0ad052fa89877215b634a07267a7e26a28e1c2bebe8.

The dump rebuilt in an isolated Postgres 16 container with network mode none and tmpfs-only storage. The rebuilt target matched:

all 39 table row counts and rowset hashes;
columns, constraints, indexes, functions, views, triggers, types, policies, schemas, and sequences;
required pgcrypto extension and kb_apply role attributes;
bounded performance checks with no reported problems.

The container was removed and proven absent. See gcp-refresh-local-rebuild-current.json. The private dump remains outside Git under /tmp/working-leo-gcp-refresh-20260713/.

Remaining live proof

Authenticate Telegram Web in the connected Google Chrome profile and run visible broad-question, memory, identity, and restart canaries.
Complete GCP operator reauthentication, converge the reviewed least-privilege IAP operator, restore this exact snapshot into a generated Cloud SQL target, verify private/TLS parity, run the no-send model replay, and clean up the generated target.

3.8 KiB Raw Blame History