I read this as an advisory compatibility assessment - I’ll trace candidate identity, registry loading, startup scope registration, and preflight behavior, then return one evidence-backed verdict with no edits.


I read this as an advisory compatibility verdict - I traced the exact candidate’s startup path, live failure, registry semantics, and rollback evidence without making changes.

## Verdict: INCOMPATIBLE — do not activate exact candidate `8dd307bf…c07f0`

The candidate cannot safely start with all immutable constraints intact.

### Evidence

- The canonical registry contains both `8527916639` and pilot `7558064272`; both rows are currently `enabled: false`. Its SHA-256 is identically `afdbab9e…42cd0` in live, candidate, and rollback snapshots.
- `telegram.py:_arm_staff_membership_subscription()` constructs `_nutrition_command_customer_chat_ids` from **every** registry row having a nonzero `telegram.chat_id`, without checking `enabled`.
- With `production_preflight` present, `_register_production_nutrition_chat_commands()`:
  1. writes global command scopes;
  2. sequentially writes every customer-specific scope;
  3. then writes staff scopes.
- `telegram_nutrition_menu.py:106` directly awaits `set_my_commands`; there is no optional-row handling.
- Startup invokes this before becoming connected. Any exception propagates and disconnects Telegram.
- Attempt 5 repeatedly failed at exactly this path with `BadRequest: Chat not found`; its receipt identifies `8527916639`, while `getChat` passes for `7558064272` and staff.
- The domain runtime itself correctly excludes disabled customers from active coaching routes. The defect is therefore a projection mismatch: inactive registry rows are excluded from coaching but included in mandatory startup command targets.
- Failure is not atomic: global scopes and the earlier sorted `7558064272` scope are attempted before `8527916639` fails. Rollback protects profile hashes, not Telegram’s persistent command-scope state.

Qualification evidence exercised fake command calls and exact menus, but did not cover an unreachable disabled registry row.

## No-change workaround

There is no safe configuration workaround:

- Removing `production_preflight` violates the constraint.
- Disabling `nutrition_coaching` bypasses the product and candidate-authority activation path.
- An alternate filtered registry is rejected because production resolves and requires the canonical registry.
- Editing/removing the `8527916639` row violates exact preservation.

Having account `8527916639` press Start on `nutricoach_kr_bot` would likely establish the private chat technically, but it is not a safe production workaround: it requires an external interaction from a disabled historical actor, can enqueue an update, and leaves future startup availability coupled to that actor. I would not approve activation on that basis.

## Forward designs

1. **Recommended: remove customer-specific registrations.**
   Customer DMs already receive the identical `start/help` menu through `BotCommandScopeAllPrivateChats`; retain strict per-chat scopes only for staff overrides.
   - Lowest coupling and smallest behavior change.
   - Dead or historical customer chats cannot block startup.
   - Trade-off: no future per-customer menu customization, which is not currently required.

2. **Filter customer-specific targets to `enabled: true`.**
   Keep the existing loop but exclude disabled rows.
   - Preserves the current scoped-menu design.
   - Adds lifecycle coupling and requires policy for pre-activation pilots; the current pilot would inherit the same global private menu until enabled.
   - Active or staff chat failures should remain fatal.

## Recommendation

Keep the currently healthy `0e383539…25f9` predecessor deployed. For forward deployment, build and qualify a successor using design 1, retain `production_preflight` with the successor digest, append the new runtime authority, and re-prove semantic root `27bd8f46…dea2`. The registry and pilot state need no mutation.

No files or external state were changed during this assessment.