I read this as an investigation of deployment blockers in the new customer-link flow - I’ll mine the specified worktree, related Hermes repositories, and available Git context without changing files.


I read this as an investigation - I audited the deployed r44 runtime and the customer-link chain without modifying files.

**Result: FAIL — 2 confirmed blockers.**

| Status | Finding |
|---|---|
| PASS | r44 is deployed: authorization is `SUCCEEDED`, phase is `COMMITTED`, and `hermes-gateway-dualcoachtest.service` is active on candidate `62f33e7d...` with no restarts. The running process has an established Telegram TLS connection. |
| PASS | Private customer links are wired in the deployed wheel: operator invite issues a 24-hour, single-use `rc1_...` link; `/start rc1_...` is handled before general commands; claims require a private DM and matching Telegram user/chat ID. |
| PASS | Live profile prerequisites exist: room bootstrap and nutrition onboarding are enabled; the expected bot username is present; capacity is 5 with 1 enabled customer, so capacity is available. |
| PASS / gate | Customer registration is intentionally disabled until consent, onboarding, explicit cutover, fresh staff-membership Bot API evidence, and Task26 authority. This is an operational gate, not a defect. |
| FAIL | **Scheduled delivery is failing now.** The enabled per-minute `NutriCoach schedule dispatcher` recorded `last_status=error`, `last_error=inline-card send failed` at both 08:53 and 08:54 KST. Its output says `Status: inline-card send failed`. This blocks automatic first check-ins and other scheduled customer delivery after activation. |
| FAIL | **Activation-completion notices have no producer.** `ActivationNoticeStore.reserve()` exists, and Telegram drains/sends reserved notices, but the exact r44 source has no production call site that reserves one during activation. Therefore an activation cannot create the notice that tells the customer when their first check-in will arrive. |
| PASS / not applicable | Channel Inbox is absent/disabled in the live profile, matching v1.5's default-OFF release boundary. Private bot-DM customer links are unaffected; Channel-DM onboarding remains intentionally unavailable pending its separate authorization. |

**Source integrity and provenance**
- The six inspected flow modules exactly match the r44 build-1 Hermes wheel: invite, Telegram handler, disabled registration, activation cutover, onboarding runtime, and activation notices.
- Deployment evidence: `authorization-consumed.json`, `phase.json`, sealed target, current systemd `ExecStart`, and current runtime candidate binding.
- Source/tests/evidence: customer-invite CLI and TTL tests; r44 authority verification reports compile/lint/type checks and 185 adjacent tests passing. I did not rerun tests because this was a no-modification audit.
- History mined from sibling `NousResearch/hermes-agent`: `d7425705ee` (v1 baseline), `ae90902686` (claim-window/single-use), `d1c1e56c27` (v1.1 seal), `ccd2eee8a` (release inventory).
- Issue/PR context: unavailable; `gh` is not installed, and the supplied worktrees have no `.git`.

No live customer link was issued or claimed during this audit; there are currently no bootstrap sessions.