# 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

1. Authenticate Telegram Web in the connected Google Chrome profile and run
   visible broad-question, memory, identity, and restart canaries.
2. 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.