teleo-infrastructure/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-targeted-post-readiness-repair-20260713.md

36 lines
1.5 KiB
Markdown

# Targeted Working Leo Handler Check
## Result
After PR #108 deployed at merge `6eb5777124515304a1c1d1901a9177064f1ed175`,
five high-risk m3taversal-style prompts ran through the live VPS GatewayRunner
with a temporary leoclean profile.
- Strict result: `2/5`.
- Passed: proposal readiness (`OOS-04`) and shared claims versus agent-owned
positions (`OOS-11`).
- Failed: restart/runtime proof tiers (`OOS-10`), bounded source intake
(`OOS-14`), and heterogeneous packet composition (`OOS-06`).
## Concrete Gaps
- The restart answer omitted the exact handler, Telegram-delivery, and canonical
mutation proof tiers and did not name `state.db` / session JSONL continuity.
- The intake answer invented `author`, `title`, `publisher`, and publication-date
fields on the current canonical source row and omitted the build-only compiler
boundary.
- The composition answer proposed a claim edge on a belief row, assigned
`applied_at` to each step instead of the proposal receipt, included unsupported
policy/belief writes in the apply sequence, and used `321` words.
## Safety Readback
- Canonical counts stayed `1837/4145/4670/4916/26`.
- `leoclean-gateway.service` stayed active/running on PID `3166667` with zero
restarts and the same start timestamp.
- The temporary profile was removed.
- No Telegram message or production DB apply ran.
The accompanying repair tightens current source fields, source identity,
belief-edge constraints, unsupported apply surfaces, proposal-level receipts,
restart proof tiers, and semantic scoring before another live run.