# Telegram Gateway Handler Canary

Generated UTC: `2026-07-09T19:14:57.821433+00:00`
Overall: `pass`
Posted to Telegram: `False`
Changed live profile: `False`
Mutated KB by harness: `False`
Temporary profile removed: `True`

## Handler Context

- Authorized: `True`
- Session key: `agent:main:telegram:group:-5146042086:9070919`

## Scores

- `audit_confirms_kb_state`: `True`
- `audit_mentions_applied_or_canonical`: `True`
- `audit_mentions_edge`: `True`
- `audit_mentions_proposal`: `True`
- `turn1_ack`: `True`
- `turn2_recalls_correction`: `True`
- `turn2_recalls_marker`: `True`

## Reply Summaries

- Turn 1: TELEGRAM_HANDLER_TURN1_ACK Marker WL-HANDLER-CORY-20260709 noted: approved ≠ applied, KB stays read-only this session.
- Turn 2: Marker WL-HANDLER-CORY-20260709. Correction: approved is not the same as applied.
- Turn 3: Read-only inspection complete. Here is the audit result for 2026-07-09 UTC: Proposal 00957f6c-9883-4015-95a4-6b09367efb0e Status in kb_stage.kb_proposals: `applied` Type: `add_edge` (relates, d3fb892b -> 9d5281fe) Proposed by: `codex-strict-edge-canary` Edge c167933e-d513-4f43-9335-d5d8aeb259f2 Present in public.claim_edges: YES Type: `relates`, from_claim `d3fb892b` to `9d5281fe` Reading: the proposal status is `applied` and the canonical edge row exists in `public.claim_edges`. In this case the proposal was applied and the canonical state matches. Approval alone is NOT the same as applying a KB change. A proposal can sit at `approved` wh...

## Claim Ceiling

This calls the live VPS GatewayRunner with Telegram-shaped events against a temporary copy of the leoclean profile. It proves handler-level authorization, session continuity, and reply quality without posting to Telegram or writing synthetic sessions to the live profile. It does not prove Bot API network delivery or a human-visible Telegram reply.

JSON proof: `/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/telegram-gateway-handler-canary-20260709/telegram-gateway-handler-canary-current.json`