I read this as a focused security audit - I’ll trace the successor delta, authorization and consent paths, then validate the candidate binding and wheel evidence without modifying anything.


The candidate is an uncommitted worktree delta rather than a reachable Git commit, so I’m treating the binding hash as an evidence identity and checking the live diff, scope publication, runtime gates, and artifact seals directly.


The runtime authority trace is clean: command-menu publication is presentation-only, while customer routing uses exact registry address keys plus live consent checks and staff paths use exact configured identities. The release evidence, however, contains a material artifact-binding inconsistency that I’m validating against the predecessor wheel and manifest before issuing the verdict.


I read this as a focused security audit - I traced menu publication, runtime authority gates, and candidate/wheel provenance without edits.

## Verdict: FAIL

**Severity: HIGH, release-blocking evidence-integrity failure.**

The Telegram authority delta itself **PASSes** security review. The candidate and wheel evidence do not reliably bind that delta to one tested artifact set.

### Authority findings: PASS

- `gateway/platforms/telegram.py:2801-2822` ignores customer chat IDs and publishes:
  - customer `start/help` globally, including `BotCommandScopeAllPrivateChats`;
  - staff `help/status/approve/deny` only through per-staff `BotCommandScopeChat`.
- Comparison with predecessor wheel shows the exact behavioral delta is deletion of only the six-line per-customer registration loop. The staff loop is byte-equivalent and unchanged.
- Telegram menus are presentation-only. `set_my_commands` output is never consulted by routing or authorization.
- Customer routing uses exact live registry addresses:
  - `nutrition_coaching.py:3209` resolves `_routes[address.key]`;
  - `telegram.py:14440-14503` routes customer and trainer traffic through `resolve`, `resolve_trainer`, and `trainer_private_active`.
- Consent remains independently enforced:
  - `nutrition_coaching.py:6993-7006` requires granted consent, recording date, and current consent version;
  - `coaching_processing_allowed` and `customer_transport_allowed` revalidate live registry, enabled state, consent, safety holds, plan window, and exact destination.
- Staff authority is unchanged and menu-independent:
  - `telegram.py:5925-5947` authenticates the exact configured operator tuple;
  - `telegram.py:7469+` rejects draft callbacks unless `_nutrition_operator_actor` succeeds;
  - trainer group and private-DM paths require exact registered assignments and active bindings.

The broad Default/AllGroup customer menu publication remains, but this only exposes UI hints and grants no authority.

### Evidence-integrity failure

Candidate binding cryptography is internally consistent:

- Derivation inputs hash to
  `e55ac326eab1fa81a56c8798efc14d3bcc7956d08761af095168e7ec8573b9ae`.
- Canonical binding hashes to the claimed
  `3bb8d4d70ac4319c0dfe2633f92713f15eb14ed202bb0e33ad5f294d72acac1a`.
- Hermes wheel A/B both match the bound hash
  `738d5d8cc0abdddb28e305c6cccbd9fa2098052d359535b106e3aed4a237b820`.

However:

1. The binding and manifest claim profile wheel hash:

   `27f7427199d4a0a2e8a08aba26431552655f615544be0f13741e88b4b7f2250a`

2. Both successor build directories actually contain:

   `eb2a67a4b709c47b9982a5ae87187596350eda7cf2b7d064a82af51112a40072`

3. The claimed `27f742...` artifact is instead the predecessor stability wheel.

4. The unbound successor profile wheel differs in five members:
   - `checkin_cli/customer_coaching.py`
   - `checkin_cli/models.py`
   - `checkin_cli/wizard.py`
   - `checkin_cli/wizard_models.py`
   - `RECORD`

5. Install A/B explicitly point to the predecessor stability profile wheel, not the profile wheels under the successor evidence directory.

6. The cited disposable E2E evidence is not bound to candidate `e55ac326...`; it records synthetic candidate `1477699a...` with unrelated Hermes/profile wheel hashes.

The wheels' internal RECORD hashes are valid and A/B are reproducible. This indicates **unbound artifact substitution/evidence pollution**, not a malformed ZIP, but intent cannot be established from the evidence.

### Blockers

- Remove or explain the unbound successor profile wheels, then regenerate the manifest against the exact shipped artifacts.
- Run disposable E2E against candidate `e55ac326...` and its declared wheel hashes.
- Regenerate installed provenance from that same artifact set.
- Bind or exclude the four changed profile modules so no source/build changes sit outside the successor delta.

Verification performed: focused command-scope tests passed (`3 passed`); selected consent/operator routing tests passed (`2 passed`). No files were edited.


I read this as a final release-gate re-review - I’ll verify the corrected menu authority behavior and independently recompute every candidate, wheel, provenance, E2E, and manifest binding without edits.


I read this as a final release-gate re-review - I verified code authority and corrected evidence bindings.

**PASS**

**Blockers:** None.