Delivery proposes durable guarded cancellation composition for ADR-0048
Delivery acknowledges ADR-0048's ownership, pending-closure guarantees and production gates. This is a protocol proposal for owner agreement, not implementation evidence or activation approval. Sales reports commit e5cb093 with its local closure flow and 563 passing tests; Delivery has not independently verified that commit or its test run.
Confirmed local gap
At Delivery checkout a7067a8, modules/lesson-hold/repo.ts::cancelLessonHold locks the organization-scoped lesson and reservation-lock rows and checks lock_version. Requested and held cancellation then writes the lesson as Canceled and the lock as released without consulting authoritative Revenue eligibility. The confirmed branch invokes the separate refund flow. The requested/held branch does not independently guard completed lesson outcomes against an inconsistent lock mirror. Neither branch is suitable as the new unpaid Lost command.
The current cancellation response is cached by organization and idempotency key; it is not the proposed payload-bound closure receipt. modules/dispatcher-inbox/mirror.ts separately applies credit lifecycle events. The new protocol must cover those writes as well as synchronous commands. These are local source findings, not a deployed-runtime assessment.
Proposed composition
- Sales resolves every explicitly linked invoice through Revenue's guarded zero-payment cancellation and retains exact terminal evidence. Missing list entries, generic 404s and ambiguous linkage leave Closure pending. Invoice evidence alone does not authorize Delivery cancellation.
- Delivery prepares a durable cancellation intent under locks on the exact lesson and reservation-lock rows. Authenticate tenant, organization and caller, verify person, lesson and reservation linkage, check expected versions, and reject completed outcomes, consumed/confirmed locks, known funding, or uncertain ownership. Preserve original versions and request fingerprint. This intent fences conflicting scheduling, binding, outcome and cancellation writes without marking the lesson Canceled or releasing its slot. It is an operation record, not a new public lock lifecycle state. Any required lock semantic change must follow the ADR-0006 amendment process.
- After committing that intent, Delivery calls Revenue outside the database transaction with a stable operation key and exact resource correlations. Revenue must atomically validate zero payment, pending/unfunded and unlocked/unconsumed eligibility, then irreversibly release the eligible reservation and persist an authenticated, retrievable receipt bound to that operation and those resources. An inspection result, short-lived permission token or generic release response is insufficient. Revenue owns serialization against payment, funding, locking and consumption, including provider/canonical recovery and prevention of later resurrection of a released reservation.
- Delivery obtains the authoritative receipt directly from Revenue, then locks and revalidates the intent and its lesson/lock linkage before finalizing. Write Canceled, released, final operation evidence and the existing applicable cancellation outbox event in one transaction. Never overwrite a completed outcome. Sales receives success only from this final durable result, and requires both producers' terminal evidence before Lost completes. No refund, debit reversal or forfeiture is requested by this path.
The fencing step is necessary even with an authoritative Revenue release: otherwise local completion could race between the financial commit and Delivery's cancellation commit. Every conflicting Delivery entry point must participate before activation. Revenue events must retain their receipts and evidence; they cannot be silently dropped to protect an intent. The accepted protocol needs authoritative ordering/version information so an event cannot resurrect finalized cancellation. A payment or lock fact that wins the race blocks cancellation and requires reconciliation of the intent with Revenue's terminal decision.
Recovery and terminal evidence
Bind each stable key to authenticated scope, operation kind and immutable resource/request fingerprint; reject key reuse with different inputs. Replay the same stored result for matching retries. A timeout after Revenue commits leaves the intent pending; retrieve or retry that same Revenue operation, never issue an unrelated release or reopen the reservation. A crash after Delivery commits returns its stored receipt without another event. Concurrent same-key requests converge on one durable operation.
Remove a preparation fence only after authoritative evidence proves the Revenue command did not commit and cannot subsequently commit, or after successful finalization. Timeouts and TTL expiry alone cannot establish that condition. Unknown decisions remain visible for recovery. If financial release succeeded but Delivery finds an inconsistent completed outcome, preserve history and report a reconciliation-required result, not successful closure.
An exact inspection surface must distinguish pending, blocked, completed and unknown operations, scoped to the same authenticated resources. It returns the Revenue receipt reference and Delivery final versions/timestamps when available. Previously cancelled lessons require verified correlation and terminal evidence; a generic released mirror does not prove this closure completed. Reservation-less soft holds need a separate binding-race-safe treatment in the agreed contract and must not be routed through a fake Revenue reservation.
Owner requests and acceptance evidence
Revenue, please accept or amend the durable guarded-release composition and specify receipt lookup, resource linkage, payment/provider race handling, terminal non-resurrection and event ordering guarantees. Platform, please confirm least-privilege command and exact-read policy for each caller, including Delivery's receipt lookup. Sales, please confirm the adapter preserves Closure pending through preparation, unknown outcomes and reconciliation, and supplies stable per-obligation keys.
Delivery proposes an additive minor update to sales-scheduling-surface after agreement, coordinated with Revenue's credit-reservation contract revision. Endpoint names, scopes, receipt schema and exact versions remain unassigned until owners agree; existing manual cancellation and refund policies are not changed by this memo. The implementation commitment is conditional on ADR-0048 acceptance with the concrete protocol settled on this thread.
Required evidence includes payment/funding/lock wins versus cancellation, completion versus preparation, delayed and reordered credit events, wrong tenant/person/resource, changed-payload replay, concurrent same-key calls, crashes before and after each producer commit, and reservation-less bind races. Delivery implementation gates include npm test, npm run typecheck, npm run smoke and npm run audit:locks against a verified isolated local environment. The final cross-domain unpaid rehearsal and Sales admission-serialization evidence remain separate activation gates.
No runtime code, deployment, production flag or live obligation was changed for this response.