I read this as an end-to-end implementation task - I’ll recover the binding design and existing activation architecture, add deterministic tests first, implement the smallest complete gate across both shared trees, then run the required focused and combined verification.


I found the completed binding design and confirmed the bypass: the gateway cutover and the profile’s direct `activate` path currently have no membership evidence requirement. I’m now narrowing the increment around those exact seams plus polling-order continuity, while preserving the completed `non1:` dispatch branch untouched.


The implementation boundary is now clear: one new gateway membership module owns canonical inventory, read-only Bot queries, subscription/journal continuity, and evidence verification; cutover consumes it before any profile mutation; the profile independently revalidates the same evidence under its authority lock and persists its three hashes. I’m starting with deterministic fake-Bot and cutover/profile rejection tests so each bypass is RED before product code changes.


The core gate is now wired through both wheels: the gateway performs and refreshes read-only evidence, cutover rejects stale bindings before activation writes and records a post-commit activation-journal binding, and the profile independently validates under lock and emits version-3 prepared/committed receipts. I’m at the verification phase now, including full profile regression coverage and the combined gateway seams; any failures from the stricter signature are being corrected in test fixtures rather than weakening production checks.


I read this as completed implementation reporting - I’ll summarize the production gate, exact files, verification evidence, and remaining deployment assumptions.

Implemented a strict, candidate-bound customer-absence gate across the Hermes and profile wheels.

**Observable stop proof**

Activation now requires all of the following:

1. Mandatory deployment receipt and membership evidence CLI arguments.
2. A newly executed Bot API preflight using only `get_me` and `get_chat_member`.
3. An armed `ChatMemberHandler` epoch predating observation.
4. Canonical inventory coverage with only `left`/`kicked` accepted.
5. Gateway validation before `activate_customer`.
6. Independent profile validation under `profile_authority_lock`, before recovery or activation writes.
7. Version-3 prepared/committed audit fields binding evidence, inventory, and subscription hashes.
8. Runtime validation of those committed fields.
9. Activation-journal binding in the membership hash chain before bootstrap reaches `ACTIVE`.

Missing, stale, tampered, unknown, member/admin/creator/restricted, API-error, identity-overlap, inventory mismatch, or deployment mismatch paths fail closed.

**Changed files**

Hermes:

- `gateway/platforms/telegram_staff_membership_gate.py`
- `gateway/platforms/telegram.py`
- `gateway/platforms/dualcoach_activation_cutover.py`
- `gateway/platforms/dualcoach_admin.py`
- `tests/gateway/test_telegram_staff_membership_gate.py`
- `tests/gateway/test_telegram_staff_membership_polling.py`
- `tests/gateway/test_dualcoach_activation_cutover.py`

Profile package:

- `checkin_cli/staff_membership_evidence.py`
- `checkin_cli/customer_admin.py`
- `tests/test_customer_admin.py`
- `tests/test_staff_membership_activation_gate.py`
- `tests/test_nutrition_readiness.py`
- `tests/test_diagnostic_policy_package.py`

**RED**

```text
pytest -q tests/gateway/test_telegram_staff_membership_gate.py
```

Result: collection RED, `1 error`, because `telegram_staff_membership_gate` did not exist.

No separate pre-implementation RED run was captured for the profile and cutover seams; their deterministic rejection tests were subsequently added and verified.

**GREEN**

```text
uv run pytest -q <membership, cutover, polling, reconnect,
onboarding, admin, controller, and wheel suites>
```

Result: `174 passed, 1 deselected`.

```text
PYTHONPATH=. pytest -q tests -p no:cacheprovider
```

Profile result: `683 passed`.

Additional combined gateway run: `120 passed`; admin/controller run: `44 passed`.

Ruff on every changed Python file: PASS.

Basedpyright on new membership modules, cutover, and focused tests: `0 errors`. Whole `dualcoach_admin.py` retains two pre-existing diagnostics at lines 200 and 407.

Profile wheel reproducibility:

```text
d52ba2794c144e82d689d0b9dad9213364e5c9100d533067888d7a960b8a0463
d52ba2794c144e82d689d0b9dad9213364e5c9100d533067888d7a960b8a0463
```

Hermes reproducible-wheel and packaging suites: `8 passed, 1 deselected`.

The completed `non1:` dispatch rejection remained untouched and the combined onboarding suite passed.

**Remaining integration assumptions**

- The deployed profile must expose its Telegram token through `platforms.telegram.token` or `TELEGRAM_BOT_TOKEN`.
- The exact deployment receipt must contain the five candidate/core/inventory and wheel hash fields.
- Gateway restart must occur before activation so the new subscription epoch is armed.
- The external lifecycle controller must invoke `staff-membership-finalize` and `staff-membership-verify` after disable; no live services, state, network, evidence trees, or configuration were changed here.