Telegram Handler Direct-Claim Suite Review

Generated UTC: 2026-07-10T00:06:52.570155+00:00

Result

Runtime path: pass_runtime=True; all six direct-claim prompts returned replies from live VPS GatewayRunner using a temporary leoclean profile.
Strict benchmark score: 0/6; this is not a Cory-direct-claim pass yet.
Telegram post: false.
Live profile changed: false.
Production DB apply executed: false.
DB counts before and after: 1837,4145,4916,4670,26 -> 1837,4145,4916,4670,26.
Service after run: active/running, MainPID=3252143, NRestarts=0.

Leo is useful on handler-level direct claims, but not yet reliable enough for the strict Cory no-context bar. The two hard failures are:

DC-03: Leo inferred decision-matrix approval from proposal/staging rationale. Direct SQL showed no matrix_voters, proposal_votes, or proposal_decisions tables in public or kb_stage.
DC-02: Leo missed approved Helmer staging row a64df080-8502-42e2-98f4-9bbdecb8da73. Direct SQL and teleo-kb show-proposal see it as approved with applied_at=false, while broad teleo-kb list-proposals showed pending rows only.

DC-01: useful but strict fail - Fresh counts and proposal states were good, but answer did not explicitly ask for proposal/time-window row-level before/after proof or use the expected no-overclaim wording.
DC-02: fail - Answer said no staged Helmer proposal, contradicted by direct SQL and show-proposal for approved row a64df080; correct answer is approved staging/packet-ready, not canonical.
DC-03: fail - Answer inferred decision-matrix approval from staging rationale; direct SQL shows matrix_voters/proposal_votes/proposal_decisions tables absent.
DC-04: near-pass but strict fail - Correctly separated files/local paths/source rows and named apply-tool gap, but did not explicitly frame source_ref-to-public.sources row-link audit in the benchmark vocabulary.
DC-05: partial - Correctly split staging from canonical apply, but opening with yes/works risks demo overclaim; expected answer should ask demo tier and require authorization for any live staging/apply.
DC-06: near-pass but strict fail - Correctly said SOUL.md direct edits are runtime drift, not canonical identity, but omitted row-level identity table/render/sync proof and explicit follow-up options.

FUP-DC03: recovered - Leo corrected itself and said the earlier decision-matrix answer was unearned without proposal ID, matrix tables, and proposal_decisions proof.
FUP-DC02: still failing - Leo still said zero staged Helmer proposals because the broad KB/list/search path missed approved row a64df080.

Keep the DC handler suite as a failing regression until live Leo answers DC-02/DC-03 correctly without context.
Patch only repo-side harness/docs now; do not deploy a leoclean skill/profile behavior change without explicit review.
Candidate future fix: direct-claim answers that mention canonical/staging truth must query approved/pending/applied kb_stage rows directly, not only list-proposals/search.
Candidate future fix: decision-matrix answers must check schema tables before inferring matrix approval from proposal rationale.

Direct-claim handler report: docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-current.json
Strict score: docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-suite-score-current.md
Follow-up challenge report: docs/reports/leo-working-state-20260709/telegram-handler-direct-claim-followup-current.json
State image: docs/reports/leo-working-state-20260709/leo-db-state-26-direct-claim-handler.svg