Delivery requires canonical bind proof and bounded replay before ADR-0052 approval

Assignment ADR-0052/delivery/001; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local; participant 01a0ff07-cd25-7490-9008-a734cad7147e. Delivery supports separate Sales create and Revenue bind workload policies as the architecture direction for durable recovery. Delivery withholds approval of the current proposal because canonical bind evidence, replay bounds and cutover semantics remain undecided. This memo intentionally contains no acknowledges field and creates no implementation commitment.

Source-backed boundary

Reviewed ADR-0052 and its request at canonical coordination HEAD 2ac56cfb4de72b1725bf522d537b5bec16ba0ea6. Reviewed scheduling v1.12.0 sections 4.1a, 4.1b, 7.4, 7.5 and 8.5, service-auth v1.7.0, ADR-0001, and Delivery's canonical domain scope in delivery-coordination at that same HEAD. Platform's supplied session-boundary audit is pinned to 8f877adca494d1fd23cc404cf64423d06a35565d in platform/.cache/adr0050-auth.

Delivery reviewed source pin is 75589fa499b3c62ef94ef5702d5470c4781a1059. Current Delivery HEAD f4d7cde1ec5e6900c2d82ace9e5a1d2661a0c9d2 has no diff from that pin under modules/lesson-hold or lib/auth. The create and bind route handlers validate JSON and keys but call no authentication guard. Bind hardcodes write originator sales; this is neither caller verification nor accurate Revenue workload attribution. Revenue bind client at 5f10755c031897b6598a051f915c6864ee0901e1, modules/workbench/delivery-client.ts:273, sends organization, reservation, lesson and key without session or scheduling bearer. The Platform audit also inventories Sales candidate d31ddf1a4bd233c3d4e2714350452de8b7cbc878; Sales transport conclusions here are audit-derived.

modules/lesson-hold/repo.ts:769 scopes and locks the Lesson by organization and checks live soft-hold state, eligibility and slot. However, its helper at line 1099 creates a requested local lock from the supplied reservation ID if one is absent. It does not verify Revenue reservation existence, Person, order or intended lesson. The bind schema contains only organization, reservation and lesson. Both write functions return cached success before resource checks. resolveParticipantContext accepts a supplied Participant without resolving its organization or matching Person; site locator reads are not organization-scoped. These facts identify required enforcement work, not deployed exposure or runtime proof.

Exact changes required before acceptance

1. Amend scheduling section 8.5 only for POST /api/v1/delivery/v1/lesson-holds/soft and POST /api/v1/delivery/v1/lesson-holds/bind. Pin the contract-relative path mapping too. Sales create requires audience delivery, selector/scope delivery.scheduling.soft-hold.create, and Platform's exact approved Sales output subject; Revenue bind requires selector/scope delivery.scheduling.reservation.bind and its exact approved Revenue output subject. Service-auth must publish both production OIDC subjects, output subjects, exact tnt_sguild tenant, literal Organization allowlists, RS256/JWKS/issuer/time/jti rules and denial codes. Do not infer Revenue's subject spelling. Verify authority before repository calls, cache reads, identity/eligibility calls or writes. Require the requested Organization in signed policy reach, with every resource independently matching that Organization. Reject missing/invalid credentials with 401 and valid but unauthorized caller/scope/Organization with 403. Do not treat body fields, caller headers, bypass headers, actor metadata or singleton fallback as authority.

2. Specify an authoritative Revenue-owned bind proof before Delivery creates any lock. Delivery recommends a narrowly scoped authenticated Revenue lookup whose response binds the exact tuple (tenant_id, organization_id, order_id, reservation_id, intended_lesson_id, person_id) and reservation lifecycle/revision. Revenue must confirm whether such an existing contracted surface is sufficient or propose the exact additive schema/path and auth policy. Delivery must compare that proof to its organization-scoped Lesson and Participant Person, validate permitted reservation lifecycle and absence of a conflicting association, and enforce one reservation-to-lesson binding under concurrency. A caller-supplied order ID or local requested lock is insufficient. If extra request fields are needed, explicitly version the schema and define historical-request compatibility. Define concurrent release/cancel behavior and evidence freshness with Revenue; a lookup followed by an unconstrained write must not create a stale association. This recommendation does not approve a new Revenue interface on Revenue's behalf.

3. State create predicates explicitly: resolve supplied Participant in the exact Organization, match supplied Person when both are present, require canonical active Person tenancy before Participant creation, validate site visibility/private Person linkage and Service Area coverage, organization-active lesson type, and Coaching-owned current eligibility and slot availability. A signed Organization allowlist cannot substitute for these resource checks. Preserve existing lock-state semantics and producer-transactional events. Delivery must record verified workload caller and issuance jti separately from Sales/operator business provenance; historical provenance remains unchanged.

4. Separate authenticated receipt replay from a new transition. Fresh valid workload authority and exact Organization authorization are required even for cache hits; never return another resource's receipt merely because a key collides. Existing contract sections 3/7.5 return the original result despite payload variance and guarantee retention only for 24 hours. Preserve historical bytes and explicitly settle compatibility with any new command binding. Define a maximum recovery horizon with matching retained producer evidence, or a safe reconciliation path after retention; blind resubmission after eviction can create another soft hold. The two proposed policies grant no inspection authority. Returning a proven prior receipt must not re-run mutable eligibility or require the reservation still be reserved; a never-completed bind must pass current mutation predicates. Specify prior-success replay after subsequent confirm/release/expiry and distinguish original receipt from current state. Expired holds do not authorize silently changing the saved command or key.

5. Pin durable admission and rollout decisions. Delivery recommends that an admitted immutable business command may recover after human-session expiry using fresh authorized workload identity, while disabled workload policy/Organization reach stops further sends. Sales must explicitly settle initiating-user revocation, cancellation and prevention of a new admission disguised as recovery. Specify cutover order and treatment of historical pending commands before enforcement; preserve all other section 8.5 routes and existing closure policies. Any admission pause or disabled endpoint needs named owner approval. No permissive fallback or temporary closure-scope expansion is acceptable.

Acceptance evidence

Prove both real routes with exact-resource positive cases and wrong method/path, missing/expired bearer, wrong issuer/audience/subject/scope/tenant/Organization, preview proof and closure-token denials. Denials must return no cached business data and produce no Lesson, Participant, lock, idempotency receipt, event or outbound business call. Add same-Organization wrong Person/order/reservation/lesson, nonexistent reservation, conflicting binding, cross-Organization Participant/site and concurrent release/bind cases.

Prove lost-response retries and process restart with a fresh token but identical saved request/key, exactly one Lesson/lock/event, authenticated cache denial, same-key payload/resource mismatch under the agreed compatibility rules, expiry/revocation/issuance outage, human-session-expired recovery, and replay beyond the declared retention horizon. Include original success followed by hold expiry or later lock advancement, so a historical receipt cannot be mistaken for current booking readiness. Preserve 409 eligibility/slot/expired-hold behavior and 503 unverifiable eligibility. Test actual Coaching separately from labeled deterministic substitutes.

Implementation gates, once accepted and authorized, include Delivery npm test, npm run typecheck, npm run smoke, and npm run audit:locks; page-flow changes additionally require npm run test:e2e. This review ran no runtime tests and grants no activation approval.

Live inbox and ledger were checked at 2026-10-02T23:52:47Z. The ADR-0052 Delivery reply is owed; no implementation commitment was completed by this review. This file is prepared locally for the coordinator's collected publication batch. No independent commit, push, indexer, freshness check, token issuance, database mutation, service restart or deployment was performed. Existing ADR-0050 assignments and release gates remain with their assigned chats.