## Summary
Revision 26 closes the stage-24 admission and isolation blockers without weakening ordinary behavior. The plan is implementation-ready: it specifies authenticated hot attachment, marked-registry exclusion, crash recovery, coherent non-mutating evidence, synthetic-only replay, closed receipt schemas, bounded outcomes, a non-secret promotion allowlist, and corrected test ownership.

## Claims
- The immutable source is `stage-26-revision.md`, SHA-256 `1f30eaf3b39e9d63341ff1bf000e0d116b1037a56bbbf80ee643d480cb190e33`; the local RALPLAN index records that exact revision/SHA.
- `checkin_cli/customer_coaching.py` currently rejects owner/customer/trainer full-triple and address-space collisions for enabled ordinary registries, while `customer_admin.py` loads only the ordinary runtime registry and its writer lock mutates the lock path. Revision 26 explicitly preserves ordinary validation and introduces a typed diagnostic loader plus a pre-existing shared read lock.
- The existing gateway has an enabled-customer-only coordinator (`nutrition_coaching.py`) and a user-ID private trainer-DM bridge (`nutrition_coaching.py`, `telegram.py`). Revision 26 makes diagnostic attachment capability-only and denies the private-DM bridge except for the exact pinned trainer route.
- Existing `GateDPreflightReceipt` v1 has closed maps in `customer_admin.py`; Revision 26 preserves it and defines a distinct closed `diagnostic_preflight_v1` receipt.
- The named profile tests exist at `tests/test_customer_admin.py`, `tests/test_customer_coaching_domain.py`, `tests/test_customer_schedule.py`, and `tests/test_adaptive_nutrition.py`; gateway tests exist at `tests/gateway/test_adaptive_nutrition.py`, `test_nutrition_coaching.py`, `test_telegram_group_gating.py`, and `test_telegram_physique_checkin.py`.

## Analysis
### Spec compliance
Admission is non-ambient: only exact Topic-59 typed actions can mint a short-lived one-use bootstrap capability; configuration, raw tuples, CLI, discovery, natural-language parsing, private DM, and production capabilities cannot select diagnostic execution. The consumed capability is passed in memory to the new diagnostic loader, while the marked registry (`diagnostic_isolated_v1`) is rejected by both ordinary loaders.

The previously missing execution topology is now explicit. The isolated profile can expose one enabled disposable customer only during an active diagnostic session, the ordinary gateway remains the only ingress, and diagnostics hot-attach only after activation. Exact trainer private-DM denial and all-update-kind provider-zero coverage close the former fourth-route bypass.

Recovery is a lock-protected, fsync-backed intent/replace/active/commit protocol with explicit cleanup reversal and a fail-closed state for every ambiguity. Prior-boot sessions cannot attach; they become `restart_unvalidated`, are disabled and require a fresh current-boot revalidation. Pre-provider checks independently fence session, boot, time, and marked registry, so delayed host ticks do not extend authority.

The snapshot design repairs the mutating-lock flaw: `profile_authority_read_lock` requires an existing 0600 authority lock and opens it read-only/shared. Optimistic before/read/after ledger fencing preserves coherent append-only snapshots without claiming an impossible global read lock; instability returns no output. Snapshot inputs are class-specific bounded facts and expected fingerprints, not source texts or addresses.

Replay is restricted to strict snapshots and digest-bound mapping under the isolated root, writes closed `diagnostic_synthetic_v1` provenance, and forces ordinary loaders to reject it. The plan also enumerates the needed source ledgers and proves class-specific fingerprint equivalence. The manifest is read-only, rooted only in the canonical profile workspace and Hermes repository, permits code/schema-source classes and the exact seven schema keys, and rejects runtime values, routes, IDs, secrets, symlinks, traversal, customer data, ledgers, and generated artifacts.

### Architecture synthesis
The selected session-scoped loader is preferable to a persistent diagnostic flag: it localizes exceptional identity visibility at a capability, boot, registry, and route boundary while retaining strict ordinary parsing. The result has a broad but appropriately coupled implementation surface; the named validation matrix covers its cross-boundary failure modes rather than treating this as a config change.

## Root Cause
Stage 24 left diagnostic authority implicit at the ordinary registry loader and user-ID-only private-DM ingress. Revision 26 resolves that root cause by adding explicit bootstrap/capability admission, a marked isolated registry with ordinary-loader rejection, and exact diagnostic route validation.

## Findings
No blocking, high, medium, or low findings. No structured findings reported.

## Recommendations
1. Implement the written transition, receipt, provenance, and loader contracts without broad compatibility fallbacks.
2. Keep the prescribed ordinary-v1 byte-serialization and full-tree non-mutation tests as regression gates.
3. Require the stated integration/red-team matrix before accepting implementation; live Telegram, credentials, manual P2-P6, and deployment remain human-owned.

## Architectural Status
CLEAR

## Code Review Recommendation
APPROVE

## Tradeoffs
- **Chosen hot-attached session-scoped diagnostic runtime:** preserves ordinary gateway ingress and places exceptional access behind expiring, current-boot capability validation; requires broad cross-module tests.
- **Persistent diagnostic config/registry mode:** simpler initially but creates ambient authority and an ordinary-loader bypass; correctly rejected.
- **Separate gateway process:** stronger process separation but duplicates ingress/operational control and does not improve the selected marked-registry/capability contract enough to justify it.