## Summary
Stage 34 correctly replaces the impossible durable-object-in-spec claim with a canonical binding digest and moves initial diagnostic transport construction before any ordinary coordinator exists. It is not yet executable: the registered wizard constructor retains an opt-out event-only path, and the proposed sealed transport has no caller compatible with the existing child coordinator or a bound authority/lock sequence. Revise those two construction boundaries before implementation.

## Claims
- The immutable RALPLAN index records `stage-34-planner.md` at planner stage 34 with SHA-256 `1d5a8c5c9756195dcaa0cdc39c2c072b85916a6f4f56b233f41267d87a1118c5`, matching the assignment (`plans/ralplan/.../index.jsonl:46`).
- The plan's binding preimage is entirely durable and its separate `transport is self._transport` check is correctly process-local (`stage-34-planner.md:36-42`). It corrects the Stage-33 attempt to capture a Python instance in durable state.
- Current registered-coordinator construction creates `WizardService(wizard_root)` without any canonical transaction (`gateway/platforms/nutrition_coaching.py:391-395`), while `WizardService` currently creates its own bare `EventStore(home)` (`checkin_cli/wizard.py:544-546`). `CustomerRuntime` currently has only public `spec` and `data_root` fields (`checkin_cli/customer_coaching.py:363-367`).
- Current delivery dispatch reads `self.customer_transport`, resolves `send_adaptive_customer`, and invokes it as `(customer_key, destination, reservation_id)` after persisting a reservation (`gateway/platforms/nutrition_coaching.py:11068-11088`). Current `TelegramCustomerTransport` itself requires a live `NutritionCoachingCoordinator` (`gateway/platforms/nutrition_coaching.py:11528-11542`).

## Analysis
### Stage 1 — Spec compliance
The canonical path derivation is concrete: `CustomerRuntime` roots lead to `wizard/events.jsonl`, `nutrition-plans/canonical-sequence.jsonl`, and one wizard `.events.lock`; the named factory, exact path tests, paired batch/single operations, and no-nested-flock test preserve the Stage-33 transaction objective. The contract is nevertheless not constructor-enforced: `canonical_transaction=None` plus `adaptive_registered=False` lets any registered-root caller select standalone semantics. The stated factory-only invariant therefore remains a convention, not a fail-closed contract.

The dormant factory is directionally correct. It removes the current hard dependency of `TelegramCustomerTransport.__init__` on `NutritionCoachingCoordinator` and sets the needed startup order: validate spec/bot, create authority and sealed transport, then construct host/control route. The resulting transport cannot be injected into the known delivery call, however, because it deliberately exposes only `send_diagnostic_customer(...)` while that call resolves only `send_adaptive_customer(...)`. The plan also does not state which owner creates the reservation/body/pins, which authority method runs immediately before provider work, or how the host's existing admission lock remains continuously held through those calls and terminal persistence.

The durable-binding design itself is sound. `adapter_kind`, verified test-bot digest, destination digest, timeout, sealed method version, and authority spec digest are canonical durable inputs; the digest is propagated to durable rows and rechecked after reconstruction. Binding is appropriately distinct from object identity, so a new process can make a fresh adapter for the same durable bot while the active process rejects a reference swap. No finding is raised on this portion.

### Stage 2 — Architecture and failure modes
A boolean describing whether a caller intended a registered flow is ambient authority. In this codebase a public path is enough to construct `WizardService` or `EventStore`; the new default would make the precise failure mode—an unpaired canonical append—silent. This violates the plan's explicit rejection of optional production fallbacks and its acceptance criterion that all registered adaptive wizard events are paired by factory construction.

The transport mismatch fails closed today as `transport_unavailable`, but it would make diagnostic delivery unusable rather than safely functional. Adding `send_adaptive_customer` merely to satisfy the legacy lookup is the wrong workaround: it restores the generic compatibility surface that the new diagnostic object deliberately excludes and loses its required session/generation/deadline/destination arguments. A diagnostic-only bridge must be selected explicitly and must own the boundary between reservation and provider call.

### Antithesis and constructive synthesis
Keeping the optional constructor is simpler and minimizes test changes, but it leaves the security invariant at every callsite; that is precisely the split-authority problem the factory is meant to eliminate. Retaining generic `send_adaptive_customer` is similarly cheap, but permits the ordinary mutable/duck-typed branch to consume the dormant transport. Both should be rejected.

Use an opaque `RegisteredCustomerBinding`/`DiagnosticDeliveryContext`, minted only by the committed registry/session loaders and carrying exact roots, transaction, binding digest, session, generation, destination digest, deadline, reservation/body pins, and a host-owned admission capability. Expose separate registered and standalone construction paths rather than caller-chosen booleans. Have a named diagnostic-only coordinator method consume the diagnostic context and invoke `send_diagnostic_customer` directly; its normal counterpart must not inspect or accept that transport.

## Root Cause
Stage 34 selects the correct factories but leaves their critical mode selection and invocation protocol to caller behavior. A default boolean allows the registered transaction factory to be skipped, while the dormant transport's sealed interface is not connected to the existing reservation/provider workflow.

## Findings
1. **HIGH — `stage-34-planner.md:16`: registered wizard construction is bypassable.** Reported as P1: the default `adaptive_registered=False` and optional transaction allow `WizardService(runtime.wizard_root)`/bare `EventStore` to append unpaired canonical events. Replace this with sealed, disjoint registered/standalone construction and enforce root/transaction correspondence in `EventStore`; migrate all registered callsites and test the direct-bare-root rejection before bytes.
2. **HIGH — `stage-34-planner.md:27-33`: no sealed diagnostic delivery bridge or verification order is defined.** Reported as P1: current delivery invokes `send_adaptive_customer`, while the factory returns only `send_diagnostic_customer`. Define one diagnostic-only host/coordinator entry point, the context parameters, authoritative reservation/body lookup, `verify_reservation` then immediate `verify_provider_start` ordering, host admission-lock ownership through provider/terminalization, and cancellation behavior. Test the activated end-to-end route and all stale/close/cancellation races.

## Recommendations
1. Replace `WizardService(..., canonical_transaction=None, adaptive_registered=False)` with explicit standalone and registered constructors, where the registered constructor accepts only a sealed binding built from a committed `CustomerRuntime`; make registered `EventStore` construction require the matching transaction and reject mismatched or omitted bindings before append.
2. Name and implement the diagnostic call chain: `DiagnosticHost` obtains the admission context, the child coordinator creates/validates the committed reservation using it, authority validates the exact reservation/body/destination/binding/session/generation, and the sealed transport immediately performs the exact native Telegram send. Hold the host admission lock through terminal receipt/unknown persistence and reject all legacy generic-sender dispatch in this path.
3. Retain the listed binding preimage and propagation. Add direct tests that reconstruct a same-value binding only after current-boot revalidation, reject every individual durable input mutation, and treat a same-marker object swap only as an in-process identity failure.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
- **Sealed registered binding (recommended):** prevents accidental unpaired canonical events and makes root/transaction correspondence testable; requires explicit migration of registered constructors.
- **Optional transaction plus boolean (reject):** lower migration cost but leaves the registered safety mode caller-selectable.
- **Diagnostic-only context/method (recommended):** preserves coordinator-free dormant construction and carries all durable pins into the native send; adds a narrow internal delivery API.
- **Legacy generic `send_adaptive_customer` alias (reject):** superficially integrates quickly but reopens the generic compatibility/duck-typed path and lacks required diagnostic pins.

Verification was read-only: immutable plan and current-source interfaces were inspected; no product tests apply to a planning-artifact review.