88 lines
3.8 KiB
Markdown
88 lines
3.8 KiB
Markdown
# 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.
|