I read this as an implementation task - I’ll trace the real Telegram delivery boundary and existing evidence conventions, add failing contract tests first, implement the smallest production receipt integration, then run the requested focused and static verification without touching harness scripts.


I found the authoritative boundary: the production draft callback durably consumes `DeliveryDispatchClaim`, performs exactly one `_send_nutrition_topic`, validates Telegram’s message ID, and only then records delivery. I’m adding the red tests against that boundary and a separate private append-only receipt authority; the receipt will remain corroborative and will be written only after the existing provider receipt has made delivery truth durable.


Implementation is complete at the boundary. The authoritative Telegram provider receipt is persisted first; the new private receipt is then appended as corroboration, and any append failure is reported while the existing delivered/sent audit path continues, so it neither retries Telegram nor becomes delivery authority. I’m running the final focused delivery/static checks and an independent fake-log reproduction now.


I read this as completed implementation - reporting the source-ready result and verification.

Implemented production customer-surface receipts at the real Telegram send boundary.

- 3 production files changed, including 1 new receipt store.
- 1 test file added: 6 tests / 8 parametrized cases.
- RED confirmed first via missing-module failure.
- Receipt binds claim/idempotency key, route digest, provider message ID, canonical payload digest, UTF-16 length, redaction metadata/digest, candidate/customer/draft/generation/approval/check-in fields, and transport receipt digest.
- Private append-only JSONL, modes `0700/0600`; symlink, path, mode, duplicate, and conflict cases fail closed.
- Raw customer text is never written to the receipt.
- Provider receipt remains authoritative; surface receipt cannot advance delivery state.
- Receipt failure after confirmed delivery is reported while truthful sent/audited state continues, without retrying Telegram.
- Independent fake transport log reproduced redacted bytes and digest.

Verification:

- Focused/related tests: **49 passed**
- Ruff: clean
- Ty: new source/tests clean; modified regions in the two existing large files introduce no diagnostics. Those files retain unrelated pre-existing project diagnostics.
- Compileall: clean
- Fake Telegram adapter QA: passed
- No harness, profile, service, live, Git, plan, todo, or evidence changes.


I read this as a reporting request - I’ll provide the exact paths and pytest command without edits.

**Production files**
- `/home/cube/projects/richard/hermes-agent/gateway/platforms/telegram_customer_surface_receipts.py`
- `/home/cube/projects/richard/hermes-agent/gateway/platforms/nutrition_coaching.py`
- `/home/cube/projects/richard/hermes-agent/gateway/platforms/telegram.py`

**Test file**
- `/home/cube/projects/richard/hermes-agent/tests/gateway/test_telegram_customer_surface_receipts.py`

**Command that produced `49 passed`**
```bash
cd '/home/cube/projects/richard/hermes-agent' && .venv/bin/pytest -q tests/gateway/test_telegram_customer_surface_receipts.py tests/gateway/test_delivery.py tests/gateway/test_restart_redelivery_dedup.py tests/gateway/test_post_delivery_callback_chaining.py
```