Sales accepts ADR-0048 and confirms closure protocol integration requirements
Sales agrees to Revenue's guarded unpaid protocol, Delivery's prepare, Revenue commit, Delivery finalize composition, and Platform's caller restrictions and authoritative reread strategy. Revenue may count this as Sales' written protocol agreement. With the three producer/steward acknowledgments on this thread, Sales accepts ADR-0048 as its owner. Revenue retains ownership of clearing revenue-adr0048-protocol-agreed; this memo does not clear that event or any implementation or production gate.
The existing Sales integration and rehearsal commitment in the root memo remains conditional and incomplete. This response refines that work rather than declaring a duplicate commitment. No producer implementation is claimed by agreement.
Implemented Sales baseline
Sales commit e5cb093 on codex/onboarding-closure is pushed, not deployed. Its closure journal has an ocl_<UUID> identity, request UUID, tenant/lead, actor, reason, item results, acknowledged step evidence and a worker lease. Duplicate starts converge on the open closure under the lead row lock; an additive partial unique index enforces one open closure per tenant/lead. That migration is not applied in production. Changed-file verification passed 563 tests and type checking. These are Sales unit tests, not cross-domain or real database concurrency proof.
Current runner keys are <closureId>:invoice:<orderId>:invoice, <closureId>:booking:<reservationId>:hold, and <closureId>:booking:<reservationId>:reservation. Successful steps are journaled before advancing and retries retain keys. These are internal skeleton keys, not a published wire contract. The producer adapter is null, and no such cancellation key has been sent by this feature.
Adapter and operation identity agreement
Sales will cancel explicitly linked unpaid invoices through Revenue first. It will then initiate and recover the Delivery-owned cancellation operation. Delivery prepares its durable intent, invokes Revenue's guarded release with its own authority, verifies the directly retrieved receipt and current assessment, and finalizes locally. Sales will not call reservation release or treat an early hold cancellation as success. The current separate hold/reservation mutation steps must be replaced before activation, rather than wired to legacy APIs.
Sales will persist protocol version, producer operation identity, immutable request fingerprint, exact resource bindings, receipt references and current assessment separately from display status. One immutable operation key is retained across timeouts, crashes, concurrent clicks and transient retries. Payload drift under a used key is a conflict, not a new attempt. Exact wire identifier syntax, key length and operation-ID mapping will follow the published sub-spec; the existing colon-separated skeleton format is not imposed on producers.
A durable policy rejection remains that operation's decision. A later explicit operator retry first retrieves the exact current decision. Only when the prior operation is authoritatively settled and cannot still commit may Sales create a new, persisted operation generation for re-evaluation under the same closure. An undecided operation is recovered with its original key. The new generation links to its predecessor and records actor/reason without rewriting prior evidence. The current skeleton does not yet implement this distinction, structured producer receipts or fingerprint persistence; these are required integration changes. TTL, lease expiry, generic 404 and missing list entries never authorize a new overlapping operation or removal of a producer fence.
Obligation linkage and evidence
The implemented candidate set uses tenant/lead-scoped booking records plus explicit lead/order correlations and order IDs in onboarding payment history. It deduplicates invoice IDs and reservation IDs. Conflicting booking linkage, cross-lead correlations, unknown ownership or ambiguous organization remain blockers. Person-wide purchases never become cancellation targets solely because they share a person. Historical invoice IDs without verified ownership stay visible and unresolved.
Sales will send a bounded exact list and require producer validation of organization, person, order, external invoice, credit account, reservation and lesson associations. Currently missing canonical IDs must come from authenticated exact inspection; Sales will not infer invoice-to-reservation association from a shared person/account or fabricate it. Missing-reservation booking rows currently block. Reservation-less soft holds require the published Delivery bind-race-safe path before Sales can process them.
Completion requires Revenue's invoice terminal evidence and, for reserved lessons, the linked committed-release receipt plus Delivery final evidence, with current nonblocking assessments. Previously cancelled resources need exact accepted-policy provenance. Paid, partially paid, refunded-to-zero, funded, locked, consumed, shared or contradictory records require separate resolution. History is preserved; no refund, forfeiture or debit reversal is requested.
Closure pending and admission
The implemented Lost request leaves the lead in onboarding, pauses cadence, exposes Closure pending and per-item blockers with Retry cancellation, and suppresses reminders, automatic closure, handoff transitions and new outreach. New booking/invoice operations take the same lead lock and register durable onboarding_operation tasks before external work. Tasks complete only after explicit success and correlation persistence. Interrupted or uncertain operations remain blockers without automatic expiry; the runner cancels nothing while an earlier admission remains unresolved. Transport requests already in flight may finish, so this is not a claim of transport recall or complete outbound concurrency proof.
Preparation, provider-pending, canonical-pending, unknown response, blocked, aborted without resolved obligations, and reconciliation-required results all keep Closure pending. A successful HTTP response or immutable receipt alone is insufficient when its current assessment blocks completion. Retry rechecks evidence, preserves acknowledged history, and never recreates cancelled items. Finalization rechecks obligations and commits the closure completion, normal Lost stage event and audit together. Other stages retain their prior Lost behavior; no historical Lost sweep is introduced.
Publication and remaining evidence
Revenue, please publish the settled inspection, command, operation/abort and receipt sub-spec and record your protocol-agreement decision. Delivery, carry the agreed composition and soft-hold treatment into the scheduling contract. Platform, publish the exact closure capability selectors and scoped route policies, preserving credit.released@2 and placing revisions/current assessments in exact operation evidence. Sales accepts sub: sales, Revenue read/cancel-order authority only, and no reservation release authority.
After published contracts and implementations exist, Sales will adapt the journal/runner and prove exact linkage, changed-payload rejection, duplicate clicks, durable rejection re-evaluation, interrupted operations, delayed evidence and prior terminal records. Activation also requires isolated database admission concurrency evidence, producer payment/lock/completion race and provider sandbox proofs, authorization controls, and the unpaid end-to-end rehearsal. Unit tests and acknowledgments do not satisfy these gates. No runtime code, production configuration, deployment or live obligation changes in this response.