# Working Leo: Three-Day Delivery Delta Window: `2026-07-10 00:00` through `2026-07-13` current delivery wave. ## Executive Verdict **No, Leo is not yet working to the full m3taversal standard.** Leo on the VPS is now strong on narrow, proof-grounded operations: it can query the canonical database, distinguish proposal state from canonical state, return structured row/count receipts, survive a gateway restart, stage reviewable changes, and exercise guarded apply/composition lifecycles in disposable clones. The exact GCP database copy and adapter-free model replay are also proven. The remaining product gap is broad unattended judgment. A fresh 12-question blind suite returned every answer without changing the DB or service, but two independent strict judges accepted only `1/12` and `2/12` outright. The failures included invented current schema, invalid edge types, handler proof described as Telegram-visible, temporary memory treated as provenance, and excessive answer length. The latest Telegram conversation also exposed participant-name hallucination and cross-session identity bleed. This delivery wave adds exact `m3taversal` naming, neutral follow-up labels, current-v1 schema guards, and regression tests; post-deploy blind and Telegram-visible proof is still required. ## Starting Point Three days ago the phrase "Leo is broken" had no single operational meaning. We had fragments of evidence, but not a reliable answer to these questions: - Is Leo merely replying, or querying the canonical Postgres KB? - Did reviewer approval create canonical rows, or only update `kb_stage.kb_proposals`? - Can Leo turn a new document/post into linked sources, evidence, claims, and edges rather than a flat answer? - Does a correction survive session and gateway restart boundaries? - Is GCP an exact copy of VPS state, or merely a similar deployment? - Can a broad operator question be answered correctly without supplying IDs and schema hints? The working lane delivered `28` merged PRs from `#72`, `#73`, and `#75` through `#100` (PR `#90` was squash-merged rather than represented by a merge commit). That count is delivery history, not proof that all 28 changes are user-visible features. ## What Changed ### July 10: Make KB Truth Executable - Built open-ended and no-context direct-claim benchmarks from real Telegram questions. - Added fresh VPS preflight, complete DB count/row receipts, overclaim guards, and Telegram capture receipts. - Proved an intentional gateway restart and a post-restart handler smoke. - Added a guarded canonical claim/apply primitive and explicit authorization, preflight, postflight, validation, rollback, and cleanup contracts. - Shipped the first live-truth VPS/GCP/onboarding skill pack. **Movement:** the standard changed from "the bot replies" to "the answer names the actual proposal/canonical state and the one proof-changing next action." ### July 11: Prove Composition And Exact GCP Restore - Ran source composition against a disposable full-data VPS clone: new source bytes were hash-bound, conflicting atomic claims were extracted, evidence and edges were linked, a strict proposal was staged, approval/apply authority was separated, and the new graph was rediscovered after a new handler process. - Captured an exact canonical Postgres snapshot and restored it to GCP staging. - Verified schema, constraints, indexes, functions, types, triggers, views, policies, roles, extensions, row counts, row-content hashes, and bounded performance checks. **Movement:** database composition and cloud restore stopped being architecture claims. They became disposable, repeatable lifecycle proofs with cleanup. ### July 12: Harden Readback, Apply, And GCP Replay - Added Cloud SQL-bound operator and full Working Leo benchmark paths. - Repaired IAP workflow execution and retained sanitized failure receipts. - Grounded direct claims in structured DB readback and required complete, packet-specific receipts. - Proved the composition/approved-apply lifecycle and corrected the false rule that every table count must move on every valid apply. - Hardened GCP replay after a nominal `6/6` falsely printed zero canonical counts; printed counts must now equal the canonical status receipt. - Replayed the real adapter-free GCP GatewayRunner with exact count consistency, unchanged fingerprint/service/profile, no send/write, and cleanup of the temporary profile. **Movement:** a plausible answer can no longer pass merely because its shape looks right. The harness checks the answer against the database receipt. ### July 13: Stabilize Deploy Proof And Expose The Broad Gap - Added a pasteable private-password helper/skill without printing or committing secrets. - Repeated post-deploy VPS direct-claim tests, pinned apply refusal to the exact deployed SHA, hardened replay bootstrap, and removed heredoc deadlocks. - Confirmed VPS deploy SHA `48777fd984dcfc195e6c33a8d3f7d78bd0c2e344`, active gateway PID `1105322`, `NRestarts=0`, and unchanged canonical counts `1837/4145/4916/4670/26`. - Ran a 12-question blind suite and a four-turn targeted schema correction challenge. The correction challenge passed operationally; the blind suite did not meet the semantic bar. - Proved through GitHub runs `29227390073` and `29227520353` that the expected GCP operator/readiness service accounts are absent (`404 Gaia id not found`). Reusing the shared identity provider alone cannot repair durable access. - Added the exact Telegram participant rule: address `@m3taversal` only as `m3taversal`; do not infer or transfer names; keep standard labels neutral. **Movement:** the work now has an honest acceptance frontier. Infrastructure and narrow DB truth are green; broad reasoning and participant identity are red until post-deploy live tests pass. ## Participant-Name Leak Root Cause The unverified personal name came from the instruction and benchmark layer we deployed while encoding expected operator behavior. It was not discovered from a canonical person/profile row: 1. Both active bridge skills explicitly said the compact answer shape existed "so Cory gets the expected follow-up" and required every direct answer to end with `Next Cory-style follow-up:`. 2. The shared skill folder was named `working-leo-cory-outcomes` and repeatedly described broad questions using that label. 3. Active benchmark prompts used the same label, reinforcing it in expected answer fixtures and handler tests. 4. The separate shortened value `m3ta` is a real legacy `reviewed_by_handle`/proposal attribution value. Leo incorrectly generalized that stored row value into a Telegram form of address. 5. There was no explicit rule binding participant identity to the current Telegram update, so a session-derived identity could bleed into another participant's reply. The repair changes the deployed VPS/GCP bridge skills, shared operator skill, benchmark prompts, output labels, and tests. The only permitted address is the exact visible handle `m3taversal`. The stored database value `m3ta` may be quoted only when reporting the exact reviewer row, never as a nickname. Historical artifact filenames and immutable receipts retain their old identifiers so evidence is not rewritten. ## Outcome Matrix | Dimension | Three days ago | Current evidence | Current status | | --- | --- | --- | --- | | Canonical lookup | Mixed memory/file/DB explanations | Complete structured VPS and GCP DB readback | Proven | | State semantics | Approval often conflated with apply | `proposed/pending/approved/applied` plus `applied_at` and canonical rows | Proven for bounded questions | | Restart survival | Inferred from uptime | Intentional restart, new PID, unchanged counts, successful handler smoke | Proven on VPS | | Staging | Vague/manual | Telegram staging and clone staging receipts | Proven at bounded tier | | Canonical apply | Packet/SQL discussion | Strict separated review/apply lifecycle with row-level postflight and rollback | Isolated proven; broad production apply not run | | Source composition | Files and proposals not clearly connected | Full-data clone source/evidence/claim/edge composition and rediscovery | Clone-proven; arbitrary production breadth open | | GCP copy | Similar-looking state | `39` tables, `52,164` rows, zero parity mismatches, private TLS | Proven | | GCP model reasoning | Nominal score could hide false counts | Adapter-free `6/6` with exact count equality and unchanged state | Proven for direct-claim replay | | GCP on-demand operation | Password/firewall/provider friction | Two missing service accounts proven; exact bootstrap gate known | Not durable; cleanup open | | Broad reasoning | Narrow benchmark fixtures | Blind judges: `1/12` strict pass and `2 pass / 4 partial / 6 fail` | Not reliable | | Conversation memory | Marker and restart cases | Same-session recall works, but one blind run misused memory as provenance | Partial | | Telegram identity | No explicit participant rule | Exact `m3taversal` rule and regression tests added | Awaiting post-deploy visible proof | | Identity composition | DB-first direction documented | Current answer contract distinguishes DB rows from rendered `SOUL.md` | Scheduled renderer lifecycle still open | ## Why The Work Felt Endless Several proof tiers were previously summarized together. A passing unit suite, a no-post GatewayRunner reply, a Telegram-visible reply, a clone apply, a production apply, and a GCP parity receipt answer different questions. Repeating tests without naming the tier made progress look circular. The current control rule is: 1. `Runtime`: did a reply return and did the service remain stable? 2. `Truth`: did the reply match current schema and canonical rows? 3. `Delivery`: was it visible in the real Telegram group? 4. `Mutation`: were exact approved payload rows applied with postflight proof? 5. `Persistence`: did the result survive a fresh process/restart/render cycle? 6. `Parity`: does the same path work against the exact GCP copy? A row is green only at the tier named in the outcome matrix. ## Current Repair Order 1. Merge and auto-deploy the exact participant-name, neutral-label, and current schema rules to the VPS. 2. Verify deploy SHA, gateway restart, unchanged DB counts, and no orphan handler/profile resources. 3. Send a concise naming question and broad out-of-sample questions through the authenticated Telegram Chrome session; capture visible replies and check that no alias or cross-user identity appears. 4. Rerun the blind handler suite with schema hallucination and identity scoring. 5. After privileged GCP reauthentication, recreate least-privilege operator identities, prove passwordless status, and delete the retained replay clone and run directory. ## Evidence - `telegram-handler-blind-oos-audit-current.json` - `leo-restart-survival-proof-current.json` - `leo-post-deploy-direct-claim-repeat-current.json` - `telegram-visible-direct-claim-suite-current.json` - `leo-source-composition-clone-checkpoint-current.json` - `approve-claim-clone-canary-current.json` - `gcp-canonical-parity-live-20260712.json` - `gcp-operator-access-blocker-current.json` - Root retained copy proof: `outputs/gcp-staging-canonical-parity-20260712T1905Z/final-receipt.json` - Root retained model replay: `outputs/gcp-cory-model-replay-20260712T1940Z/direct-claim-result-final.json` ## Completion Rule Do not answer "yes" to the whole m3taversal-standard question until the post-deploy Telegram identity test and a fresh broad blind suite pass, with unchanged VPS DB/service state; and the GCP durable operator/cleanup lifecycle is complete. Narrow VPS/GCP capabilities must continue to be reported as proven at their actual tiers rather than being downgraded or rounded up.