## Summary
Reviewed immutable `stage-21-revision.md` (SHA-256 `648a22474462474154ce6a024d167873390d60d5012b05bbfbb7cda8bf87bd0c`, corroborated by the target run index). Revision 21 resolves the prior Gate-D design blockers without widening the manual boundary: it makes authority, delivery uncertainty, callback routing, cutover, preflight, and documentation contracts explicit and testable. The plan is ready for execution planning handoff; no product code or tests were changed/run in this planning review.

## Claims
- **Shared authority transaction/capability:** Revision 21 defines one configured full review triple, an `AdaptiveOperatorCapability` minted only at exact ingress, fixed registry/authority → lifecycle → store lock order, full authority/config pins, append-adjacent validation, and a post-reservation pre-provider validation. Production lifecycle APIs accept capability rather than raw triples.
- **Persisted operator sessions/config:** It defines a gateway-owned service and append-only private sessions with action/customer/revision/pin/message binding, expiry/revocation state, and bounded `an1:<24hex>:<action>` callbacks; handlers no longer discover a customer by probing every coordinator.
- **Schedule cutover:** It replaces bare claims with a receipt-bearing ledger, makes legacy claims terminal unknown by default, preserves legacy files read-only, and prohibits release/retry absent typed proof the provider was not attempted.
- **P2–P6 state machines/barriers:** It gives isolated fixture preconditions, fresh immutable revision lineage per scenario, provider/ledger outcomes, and test-only pre-provider barriers for revoke/owner races; production configuration/API cannot access the barriers.
- **Authoritative docs/preflight:** It defines a pure, bounded preflight receipt and establishes the profile `PILOT_RUNBOOK.md` as the sole executable authority, with guide/HANDOFF/HTML linked by version+digest rather than duplicating direct calls.

## Analysis
### Spec compliance
The revision directly addresses every requested blocker. The capability includes review and canonical-owner address versions plus proposal/config/registry/consent/activation pins; the designated linearization points ensure an authority mutation either rejects before a durable effect or yields a linked terminal unknown with zero provider calls. This is materially stronger than the current raw-owner callback path in `gateway/platforms/telegram.py:5728-5811`, which compares the callback address to the canonical owner and probes coordinators.

The schedule design repairs the current claim-only contract in `checkin_cli/customer_schedule.py:75-112`: it persists immutable prepared/sending intent and provider receipt before audit, fails closed on corrupt/mixed state, and removes the current unrestricted unlink retry documented in `checkin_cli/customer_admin.py:4209-4214`. The conservative legacy-unknown rule correctly refuses to infer unsent delivery from a missing receipt.

P2–P6 now distinguish success, timeout/malformed receipt, audit recovery, revoke-after-reservation, and owner rotation. The plan pins exact provider-count expectations and requires a separate approved/activated child revision for each mutually exclusive outcome. P5/P6 barriers are specifically dependency-injected test seams and explicitly unreachable from production, avoiding a diagnostic bypass.

The preflight is correctly observational: it accepts only user-provisioned resources and reports booleans/counts/digests/epoch. The docs rule cures current conflicting executable material, including direct lifecycle/retry instructions in `듀얼코치_사용설명서.md:267,387,392-394,413-415` and the schedule-release procedure in `PILOT_RUNBOOK.md:7`; it retains the existing real-customer-disabled/manual-Gate-D boundary in `HANDOFF.md:138-139`.

### Architecture and synthesis
The chosen host-owned control plane is the correct boundary because ingress authorization, capability minting, lifecycle mutation, and provider reconciliation are all security-critical and must share one authority view. The global shared lock increases write serialization, and durable menu sessions add I/O; that is an acceptable trade for preventing stale-authority transitions and cross-customer routing. Implementation must apply the fixed lock order to every authority-affecting writer—not just adaptive callers—and retain no raw-triple production entry point.

The receipt ledger and no-resend terminal-unknown policy deliberately prioritize duplicate-send prevention over automatic recovery. This is the correct trade for customer messaging; receipt-backed reconciliation preserves recoverability without a second provider invocation. The plan's typed `provider_not_attempted` exception is narrow, preserves evidence, and is confined to a supported transport boundary.

### Security, correctness, and performance
The plan bounds callback payloads, stores token hashes/nonces rather than raw session tokens, binds actions to their originating message/address, fails closed on stale/mixed/corrupt ledgers, and excludes raw Telegram/customer data from preflight and observable evidence. The exact TOCTOU matrix covers before mint, after mint/before append, and after reservation/before provider for all listed mutators; the final validation under the same lock order closes the cross-process race before provider invocation.

## Root Cause
The existing Gate-D surface splits authority and delivery truth across callback code, lifecycle objects, and bare schedule claims. `telegram.py:5728-5811` authenticates against the canonical owner and scans all customer coordinators, while `customer_schedule.py:75-112` records only an unqualified claim and `customer_admin.py:4209-4214` permits deleting it. Revision 21 replaces those fragmented contracts with a capability/authority transaction, one persisted session router, and receipt-bearing ledgers.

## Findings
No findings. The revision resolves the prior blockers at plan level; execution must implement the named contracts and verification matrix without weakening their fail-closed behavior.

## Recommendations
1. Execute the shared authority/capability and persisted-session work before exposing any new menu action, applying the stated lock order to all authority writers.
2. Cut over scheduled claims atomically before allowing a scheduler retry path; retain legacy evidence and reject ambiguous historical sends.
3. Implement P2–P6 as separate deterministic test cases with the specified barriers and provider-count assertions, then run the full TOCTOU matrix.
4. Ship `audit_gate_d_preflight` and make `PILOT_RUNBOOK.md` authoritative before the manual rehearsal; remove, rather than alias, direct lifecycle/retry instructions in derivative docs.

## Architectural Status
CLEAR

## Code Review Recommendation
APPROVE

## Tradeoffs
- **Shared authority lock + capability (chosen):** serializes authority-affecting writes but gives a single audited linearization point and prevents stale-authority provider calls.
- **Minimal callback/claim patches (rejected):** lower implementation cost but retain split authority, coordinator probing, and ambiguous retry state.
- **Automatic retry after uncertainty (rejected):** can improve apparent availability but violates provider-at-most-once; receipt-backed reconciliation is safer.