I read this as an implementation task - I’ll reproduce the authority mismatch with focused regressions, implement descendant-chain binding in the receipt schema/coordinator, then run the requested verification without touching excluded areas.


The existing receipt pins the delivery row’s approval generation as if it were the current generation. I’ve confirmed the authoritative lifecycle is linear (APPROVED 4 -> DELIVERY_PENDING 5 -> DELIVERED 6 -> SENT_AUDITED 7); I’m adding the regression and fail-closed lineage cases before changing production code.


message: Codex error: Our servers are currently overloaded. Please try again later.

stop_reason: error


The focused suite is GREEN: the receipt now treats generation 4 as the pinned approval and generation 7 as the corroborated current tip, with chain recomputation and explicit predecessor traversal. I’m moving through integration verification now, including the send path to ensure receipt persistence remains post-transport corroboration and cannot trigger another provider call.


The integration set is GREEN (465 tests), including a forced receipt-store failure after the one provider send; delivery still reaches SENT_AUDITED and the transport call count remains one. The broad Telegram wildcard additionally exposed five unrelated collection failures from a missing installed `checkin_cli.nutrition_onboarding_clarification_policy`; the directly relevant suites are unaffected.


I read this as a completed repair cycle - I implemented and verified the generation-lineage receipt contract without rebuilding the Golden Path.

Implemented:

- Added receipt schema `telegram-customer-surface-receipt-v2` under `customer-surface-receipts-v2`.
- Separately binds:
  - approved generation and record digest
  - current terminal generation and record digest
- Recomputes generation records, validates authoritative history, and traverses predecessor digests from terminal back to the pinned APPROVED record.
- Validates immutable draft, check-in, customer, approval, candidate, capability, payload, route, and provider-receipt bindings.
- Receipt digest now covers both generation pins and all lineage bindings.
- Receipt remains `corroboration_only`; it does not mutate delivery state.
- Added gateway coverage proving receipt failure does not retry transport.

Files changed:

- `gateway/platforms/telegram_customer_surface_receipts.py`
- `gateway/platforms/nutrition_coaching.py`
- `tests/gateway/test_telegram_customer_surface_receipts.py`
- `tests/gateway/test_nutrition_coaching.py`

RED:

```text
.venv/bin/pytest -q tests/gateway/test_telegram_customer_surface_receipts.py::test_coordinator_binds_receipt_to_consumed_claim_and_exact_transport
1 failed
```

Failure was the exact generation-7 versus delivery-row generation-4 authority mismatch. Output preserved at `/tmp/st_01a01386-red.txt`.

GREEN:

- Focused surface suite: `19 passed`
- Final surface plus gateway failure path: `20 passed`
- Delivery/generation/gateway set: `465 passed`
- Generation hardening: `37 passed`
- Nutrition coaching: `169 passed`
- Surface/polling receipts: `38 passed`
- Ruff: passed
- Scoped ty: passed
- Compileall: passed
- Minimal driver output:

```text
telegram-customer-surface-receipt-v2 approved=4 terminal=7 delivery_rows=1
```

Main verification command:

```text
.venv/bin/pytest -q \
  tests/gateway/test_nutrition_coaching.py \
  tests/gateway/test_task7_generation_hardening.py \
  tests/gateway/test_telegram_customer_surface_receipts.py \
  tests/gateway/test_adaptive_nutrition.py \
  tests/gateway/test_delivery.py \
  tests/gateway/test_delivery_silence_filter.py \
  tests/gateway/test_post_delivery_callback_chaining.py \
  tests/gateway/test_restart_redelivery_dedup.py
```

Remaining pre-existing issues:

- Broad `tests/gateway/test_telegram*.py` collection fails in five onboarding modules because the installed `checkin_cli` lacks `nutrition_onboarding_clarification_policy`.
- Full ty over the already heavily modified nutrition files reports 642 unrelated existing diagnostics; scoped receipt implementation/tests are clean.

No Golden Path rebuild/run was performed.