# Telegram Handler Direct-Claim Suite Review

Generated UTC: `2026-07-13T00:42:00Z`

## 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: `6/6` in all three post-deploy trials (`18/18` replies).
- 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 before/after run: `active/running`, `MainPID=2403328`, `NRestarts=0`, `ExecMainStartTimestamp=Sun 2026-07-12 09:14:10 UTC`.

## Core Finding

Leo now returns all six no-context replies and keeps the VPS stable across three
fresh post-deploy runs. The scorer accepts equivalent truthful language while
rejecting the incompatible legacy `add_edge` follow-up.

- `DC-05`: all three post-deploy no-post answers include a complete `DB readback:`
  receipt and propose a safe new or matching strict staging canary. The retained
  Telegram-visible answer predates the repair and still fails this one check.

## Scenario Assessment

- `DC-01`: `pass` - Proposed/approved/applied split is correct; names two applied rows, three approved-but-unapplied rows, 14 pending, and 7 canceled; includes follow-up and authorization boundary.
- `DC-02`: `pass` - Helmer 7 Powers is approved/staged or packet-ready but not canonical; proposal `a64df080` has empty `applied_at`; canonical `public.*` rows are absent.
- `DC-03`: `pass` - Decision-matrix path is not shipped; matrix tables are absent; m3ta reviewer sign-off is not a matrix vote.
- `DC-04`: `pass` - Not a single-cause pointer diagnosis; separates Telegram/local file refs, proposal refs, document evaluations, review status, and canonical `public.sources`.
- `DC-05`: `pass_repeated` - Three consecutive post-deploy no-post answers are correct; the older Telegram-visible capture remains historical failure evidence.
- `DC-06`: `pass` - Direct `SOUL.md` edit is runtime/rendered artifact drift, not canonical identity; canonical change requires DB rows plus render/sync/postflight proof.

## Follow-Up Challenge

- The latest report and score supersede the older `6/6` review for current handler status.

## Next Actions

- Keep the three-trial repeat proof as the clean-session regression gate.
- Retest `DC-05` visibly in Telegram only with separate exact message authorization.
- Reopen immediately if DC-02 stops recognizing `a64df080` as approved/unapplied, DC-03 infers matrix approval while matrix tables are absent, any DC answer omits `Next Cory-style follow-up:`, or the read-only suite mutates DB/service state.
- This pass does not authorize production apply of Helmer, mapped rich packets, Rio strategy, governance/concept schema, or any canonical `public.*` mutation.

## Evidence Files

- 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`
- Repeated post-deploy proof: `docs/reports/leo-working-state-20260709/leo-post-deploy-direct-claim-repeat-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`