## Summary
Stage 35 closes the Stage-34 optional-constructor and cyclic-digest findings: registered and standalone persistence are disjoint sealed factories, and the four-digest derivation is explicitly ordered and restart-reproducible. It does not close the diagnostic-bridge finding because it verifies a reservation before specifying its lock-held creation; this is both an impossible successful path and a potential Stage-33 close race. Define one host-owned reserve-then-verify path before implementation.

## Claims
- The immutable RALPLAN index records `stage-35-revision.md` at revision stage 35 with SHA-256 `983e19861cc6322147a482665f683664f83a77580ea209331f3b8e30e84ca3d6` (`plans/ralplan/.../index.jsonl:47`).
- The plan replaces Stage 34's public boolean/optional transaction with `RegisteredCustomerBinding`, internal construction tokens, and disjoint `for_registered`/`for_standalone` factories (`stage-35-revision.md:60-72`). This directly resolves the omitted-marker bypass identified at Stage 34.
- The plan's spec-core -> transport-binding -> spec -> authority hash order is acyclic and keeps approval metadata out of the spec core (`stage-35-revision.md:88-99`). This resolves Stage 34's undefined `authority_spec_digest` and projection cycle.
- Stage 33 requires final pin validation and durable reservation creation to occur under the same `_admission_lock` (`stage-33-revision.md:55-60,117-125`). Current adaptive delivery persists its reservation before dispatching through the generic sender (`gateway/platforms/nutrition_coaching.py:10994-11118`).

## Analysis
### Stage 1 — Spec compliance
The sealed persistence design is now enforceable in normal code paths. `for_registered(runtime)` couples the validated loader-minted binding to `CanonicalEventTransaction.for_customer_runtime(runtime)`; standalone construction must be explicit. That matches the stated requirement that a registered adaptive wizard cannot silently become event-only. The migration scope correctly includes current direct construction such as the coordinator's `WizardService(wizard_root)` (`gateway/platforms/nutrition_coaching.py:391-395`) and the wizard's bare `EventStore(home)` (`checkin_cli/wizard.py:544-546`).

The digest design is complete enough to implement: it names each digest, exclusions, exact preimage values, durable-row propagation, restart recomputation, and independent golden-vector tests. The previously ambiguous `authority_spec_digest` is eliminated in favor of `spec_core_digest`; process object identity remains only an in-process check.

The delivery bridge remains temporally inconsistent. `verify_reservation` requires and validates an existing immutable reservation row, but `DiagnosticHost.deliver` calls it before it "creates/validates durable admission." No API or owner creates that reservation and pins the body/destination under the host admission lock. A missing row fails every new send; having the child coordinator create it first instead recreates the pre-host gap that Stage 33 specifically forbids.

### Stage 2 — Architecture
The proposed verified-reservation object is the right capability boundary: the transport receives only authority-returned body bytes and destination. It must be produced after a reservation that was created under the same lock as final session/generation/pin validation. This belongs in `DiagnosticHost`, not in a generic coordinator dispatch or the transport, because only the host owns the admission lock and close/detach linearization.

### Antithesis and constructive synthesis
Leaving reservation creation in the child coordinator minimizes refactoring and lets it retain the existing delivery ledger implementation, but it creates a check-to-reserve gap unless the coordinator can execute while holding the host's non-forgeable admission capability. Letting the generic path create a reservation and invoking `DiagnosticHost.deliver` afterward is therefore not an acceptable compatibility fallback.

Use a narrow host-owned operation: under `_admission_lock`, derive the immutable body and destination from authoritative committed state, append/commit the diagnostic reservation with session/generation/binding pins, construct `DiagnosticDeliveryRequest` only from that committed row, call `verify_reservation`, then `verify_provider_start`, frozen transport, and receipt/terminal persistence. If ledger mechanics must remain coordinator-owned, expose a private `reserve_diagnostic_delivery(..., host_lock_token)` callable only from `DiagnosticHost` and require it to append before returning the request. Test no-row rejection, close-before-reserve, reserve-before-close, and provider-boundary mutation.

## Root Cause
The plan treats durable reservation creation as an unspecified part of both admission and delivery verification. Its declared call order places verification before the prerequisite reservation exists, while the current production workflow creates the reservation outside the proposed host boundary.

## Findings
1. **HIGH — `stage-35-revision.md:78-84`: diagnostic reservation creation is neither ordered nor owned.** Reported as P1. `verify_reservation` rejects a missing row, but `DiagnosticHost.deliver` invokes it before "creates/validates durable admission." This makes the success path undefined and allows a Stage-33 close race if the child coordinator creates the row first. Define a host-held reserve-then-verify sequence or a private coordinator reservation API requiring the host lock token; test zero provider calls when close wins before reserve.

## Recommendations
1. Define the single writer/owner of the diagnostic reservation and make its append occur under `DiagnosticHost._admission_lock` after final live-pin validation and before `verify_reservation`.
2. Construct `DiagnosticDeliveryRequest` only from that committed reservation; retain the verified-reservation-only transport signature and direct frozen transport dispatch.
3. Add deterministic tests for missing reservation, close-before-reserve, reservation-first then close, and stale pins after reservation; preserve Stage 33's at-most-once/terminal-no-retry results.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
- **Host-owned reserve-then-verify (recommended):** one linearization point, preserves close/provider guarantees, and keeps body/destination authority sealed; requires extracting a narrow reservation primitive.
- **Coordinator reserves before `host.deliver` (reject):** smaller refactor but leaves the reservation outside the host lock and reopens the exact close/admission race Stage 33 closed.
- **Verify before reserve (reject):** fails because the required reservation row does not exist and leaves no defined success path.