## Summary
Stage-25 revision closes every Stage-24 architectural blocker without weakening ordinary behavior. The immutable artifact is indexed at the supplied SHA-256 and specifies a bounded, session-scoped diagnostic path that cannot become a persistent production bypass.

## Claims
- `index.jsonl` records `stage-25-revision.md` at SHA-256 `61dedc2e522ce2c28807918299b9faa53ac5479c647b964f2f0354b79e9e2b20`.
- The current ordinary registry is strict for enabled owner/customer/trainer full Telegram addresses (`customer_coaching.py:269-416`), ordinary preflight receipt v1 has a closed mapping schema (`customer_admin.py:4190-4410`), the authority write lock mutates its lock path (`customer_admin.py:126-158`), and the existing private trainer path admits a user-keyed DM bridge (`nutrition_coaching.py:850-1043`; `telegram.py:8730-8790`).

## Analysis
The revision selects the needed separate, typed diagnostic runtime loader: it leaves `CustomerSpec`, `RegistryDocument`, and `load_runtime_customer_registry` unchanged, authorizes the disposable enabled customer only through an active current-boot diagnostic capability, and pins its root, bot, customer, and routes. This closes the normal-loader incompatibility while retaining existing same-user/distinct-full-triple ordinary semantics.

The revision closes the private-DM bypass by disabling the legacy bridge in diagnostic mode except for the exact session-pinned trainer destination, with negative text/callback/active-binding and provider-zero coverage. It preserves v1 preflight bytes/maps while defining a separate diagnostic receipt; snapshot export requires a freshly validated owner diagnostic capability and a shared read lock that cannot create/chmod/write; the new incident enum, bounded schema, KST rebase, provenance guard, and outcome fingerprint make replay representative rather than shape-only.

It also provides named prepare/activate/revalidate/revoke/close/load APIs, an append-only digest-validated ledger, exclusive 60-minute TTL, concurrent activation rule, terminal-state irreversibility, and boot-epoch restart suspension. Finally, exact promotion trust roots, repository-relative allowlists, schema-key-only config inclusion, and traversal/symlink/secret/runtime/destination exclusions make promotion manifest-only and non-deploying.

## Root Cause
Stage-24 modeled shared-user diagnostics above the strict runtime parser and left a user-ID-only trainer DM path outside route fencing. Stage-25 moves authority to an explicit current-boot, typed diagnostic loader/capability and fences every ingress and provider boundary.

## Findings
None. All Stage-24 findings are explicitly addressed with implementable APIs, state/TTL/boot semantics, isolation boundaries, and verification obligations.

## Recommendations
Implement the stated validation-coupled slices without adding a compatibility flag or relaxing ordinary loaders. Preserve the specified no-live/manual-action boundary.

## Architectural Status
CLEAR

## Code Review Recommendation
APPROVE

## Tradeoffs
- Chosen typed isolated loader: explicit propagation cost, but preserves strict ordinary parsing and creates a single fail-closed diagnostic admission point.
- Rejected persistent diagnostic flag/shared parser: lower initial effort, but creates a durable bypass and is incompatible with the isolation goal.

No tests run: read-only plan review; gates skipped as required.