I read this as a read-only production-state incident reproduction - I’ll trace the live handler and state, form competing hypotheses, then build and run an isolated offline driver only under `.omo/evidence/task26`.


The incident route is now narrowed to the registered-customer branch: plain `checkin` is not a launcher alias, so it reaches `NutritionCoachingCoordinator.handle_text(...)` and then `_render_nutrition_text(...)`. I’m moving to an instrumented reproduction with live-state mutation guards and a fake Telegram send surface.


The offline driver reproduces the live failure exactly: route resolution and coordinator handling succeed, then DM rendering passes synthetic topic `"1"` into strict-topic delivery and raises before the fake bot is called. I’m sealing hashes and source-line evidence now.


I read this as a read-only production incident reproduction - I traced and reproduced the exact failure offline.

**Confirmed exception**

```text
RuntimeError: strict topic delivery requires message_thread_id
```

Raised at `gateway/platforms/telegram.py:5690`.

Call path:

```text
_handle_text_message:13638
_render_nutrition_text:6128
_send_nutrition_topic:5690
```

**Root cause**

- `_nutrition_address()` correctly normalizes private DMs to topic `"0"` at lines 5249-5251.
- Plain `checkin` is not a launcher alias, so customer resolution and `handle_text()` succeed.
- `_render_nutrition_text()` discards that normalized address and recomputes the topic using `_physique_thread_id()`.
- For a DM with no `message_thread_id`, `_physique_thread_id()` returns general-topic sentinel `"1"` at line 7441.
- `_send_nutrition_topic()` consequently enters strict forum-topic delivery. No `message_thread_id` can be generated for this private DM, so line 5690 raises before Telegram is called.

Hypothesis H3 was confirmed. Address mismatch, registry reload failure, and bridge-state failure were falsified.

**Evidence**

Root:

```text
/home/cube/projects/richard/traning coach/.omo/evidence/task26/st_01a00cfa-checkin-repro
```

Files and SHA-256:

```text
reproduce_checkin.py
c2d48a522d6e7dfb37e32cec05f3f7bbf7c344bda638b3d059e35171ae59736a

output.json
e3ad468aab72973b1e335b9c5de8414024f9aef703b9da5dcd446871cba66bca
```

`output.json` contains the full traceback and method-level trace. It confirms:

- Exact route `('8527916639', '8527916639', '0')` resolved.
- Activated customer was enabled.
- `handle_text("checkin")` returned normally.
- Render attempted `topic_id="1"`.
- Fake bot calls: `[]`.
- 32 live authority files remained byte-identical.
- No network/provider access occurred.

**Suggested minimal seam**

Pass the already-authoritative `IncomingAddress` into `_render_nutrition_text()` and use `address.chat_id/address.topic_id` for both send branches. This preserves DM topic `"0"` instead of recomputing it through the physique/forum helper.

Verification: final driver exited `0`, reproduction assertions passed, Python compilation passed, LSP reported no errors, and gateway PID/start time remained unchanged (`343199`, `141963015`).