Sales no-Order ownership boundary and prepared cancellation evidence

Sales responds to Revenue's provenance request within the accepted ADR-0048 rule: “Shared or uncertain ownership blocks automation.” A reservation without a canonical Order and without another accepted authoritative lead association is a required negative acceptance case. It must retain Closure pending, pause outreach, prevent new obligations, and produce neither Lost nor a producer mutation. Inspection denial is not cancellation evidence.

This boundary permits proving the supported invoice-correlated cancellation path alongside the unsupported-association negative case. It does not declare every no-Order reservation impossible to cancel. Future positive automation requires accepted authoritative linkage, with an immutable reservation-to-lead/closure association, its owning domain, exact identifiers, authenticated read/admission interface and scope, and absent or contradictory association behavior. No Order, API, capability or new design is invented by this response.

Delivery's local inspection may legitimately return HTTP 200 with matching held-lesson, reservation and account facts. Those facts do not establish canonical Order ownership or financial eligibility. For this unsupported-association case, Revenue's authoritative inspection remains unresolved or denied, so Sales stays pending and paused and sends no Delivery cancellation command. A Delivery inspection failure is not required for this negative case. The coordinator relayed this clarification from Delivery under its /002 assignment; it proposes no API change.

Sales source and evidence

The prepared Sales candidate is f50c89b1e3791613728438176577ea4059ff02f4. Its LeadLessonBooking model stores tenant, lead, organization, person, lesson, reservation and lock identifiers. recordLeadLessonBooking upserts by tenant/lesson and can update the associated lead, person and reservation. This mutable Sales projection identifies candidates; it does not supply immutable Revenue admission provenance.

loadClosureSnapshot selects the lead's explicit booking and order correlations, includes onboarding invoice history, and blocks missing, conflicting or shared ownership. The same module pauses cadence when closure starts and guards new work while pending. Sales identified no existing immutable service interface in this path that resolves the unsupported no-Order association.

The added published-runner unit test supplies a locally known booking and denied Revenue inspection. It requires a blocked item, no Delivery cancellation command, no operation mapping allocation and no invoice command. Repository tests cover paused outreach and pending-closure guards. These are unit assertions, not composed persisted producer proof. The candidate passed 1,783 tests with 20 opt-in database tests skipped, nine offline evidence-wrapper tests and type checking. An initial full-run timeout passed a focused rerun and the complete lower-concurrency rerun.

Four prepared composed cases

The rehearsal specification prepares fresh isolated fixtures for:

1. Invoice-correlated unpaid held cancellation, invoice first, followed by exactly one release, lesson cancellation and Lost transition.
2. Wrong-person preview denial, with immediate persisted before/after database snapshots before a separate valid cancellation. The valid flow's effects must not be attributed to the denial.
3. A completed Delivery response discarded before Sales consumes it, followed by recovery using the identical saved child key and body.
4. Unsupported no-Order association: allow a successful Delivery inspection with valid local held-lesson/reservation/account facts, then require unresolved or denied Revenue ownership evidence to leave Sales pending and paused. Assert no Delivery cancellation command, no reservation release, no invoice mutation and no Lost, including retry. Do not require Delivery to return 404 or interpret its 200 as financial authorization.

The offline wrapper requires root handback, exact source pins, pinned request selectors and complete observer coverage. Owner adapters and composed final-source execution remain pending. All future provider behavior in this rehearsal is restricted to an explicitly isolated local double; no external-provider or production claim follows from it.

The wrong-person preview case's expected 404 is separate from the no-Order case's valid local Delivery inspection. The existing no-Order unit test uses an HTTP 200 Delivery mock and denied Revenue inspection; it proves Sales composition behavior, not the real producer's local-fact response shape. The prepared composed test must use actual owner-provided local facts and authoritative Revenue denial/unresolved evidence. This clarification changes the documented test expectation without relabeling the preserved f50c89b proof as a new composed run.

Release and publication boundary

Preparation reconciled the earlier Sales release f712e191d91bf0b17c8106c1f2012ca910de75fd. The coordinator now reports released Sales source f04b37c87775b03cbf37f3131d8ef15c61ddc15b. Reconciliation against that newer ADR-0049 source is outstanding; f50c89b and its proof remain preserved and are not represented as the final release candidate. No final-source rerun is authorized by this memo. Root must provide final release handback and producer pins before composed work resumes.

Dependency update from the coordinator: Delivery and Revenue have both been explicitly handed back from ADR-0049 and are preparing final lineage candidates. Their final composed source pins and runtime manifests are still pending. No composed execution window has been granted; both final producer manifests and the root's exclusive all-source-pinned authorization remain required. The shared ADR-0049 release coordinator retains its Render/Sales activation sequence; no production authority transfers here.

Prepared under ADR-0050/sales/003, coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. Root is sole publisher. Source links identify the exact local candidate and require that candidate to be available remotely for browser access. This response records Sales' position and the explicitly attributed dependency update, not a new approval or commitment on another domain's behalf. It does not close all ADR-0050 evidence, activate production, or modify the separately owned ADR-0052 work.