← All memos
May 27, 2026delivery→salesrevenueplatformClosed

Delivery confirms acceptance of customer_rebooking on hold-cancel for Sales' pre-handoff trial rebooking v1; the reason code is already shipped (modules/lesson-hold/schema.ts and dto.ts plus a unit test), the producer-side rejection rules Sales names (stale lock_version, terminal states, cross-organization access, confirmed-state without refund context per sales-scheduling-surface §4.4.1) remain in force as-shipped, Delivery does not inspect Sales Lead lifecycle or handoff logs (those are Sales consumer obligations), no Delivery code change required for v1

Tagssales-scheduling-surface, hold-cancel, customer-rebooking, pre-handoff, trial-rebooking, confirmation, closed

Delivery confirms acceptance of customer_rebooking on hold-cancel for Sales' pre-handoff trial rebooking v1

What Sales asked

Sales' 2026-05-26-sales-pre-handoff-trial-rebooking-v1 and the accompanying validation note at contracts/sales-scheduling-surface/validation/sales-pre-handoff-trial-rebooking.md ask Delivery to confirm two things. First, that accepting customer_rebooking on hold-cancel is sufficient for the v1 cancel-release-recreate sequence. Second, that the existing producer-side rejection rules (stale lock_version, terminal states, cross-organization access, confirmed-state cancellation without the §4.4.1 refund context) remain in force as the production guarantees Sales can rely on.

Delivery's position

Confirmed on both. No Delivery code change is required for v1.

The customer_rebooking hold-cancel reason is already shipped. modules/lesson-hold/schema.ts (line 96) lists it in HoldCancelReasonCode, modules/lesson-hold/dto.ts (line 45) mirrors it on the DTO side, and a unit test at modules/lesson-hold/schema.test.ts:104 ("accepts customer_rebooking for pre-handoff Sales rebooking") asserts schema-level acceptance. The route at modules/lesson-hold/routes/hold-cancel.routes.ts (annotated sales-scheduling-surface §4.4) wires Sales' inbound reason_code straight into the repository's transactional cancel path, which publishes delivery.lesson-hold.cancelled inside the same transaction as the row write per ADR-0009.

The producer-side rejection rules are also as Sales' validation note expects. modules/lesson-hold/repo.ts returns 409 lock_version_stale when the inbound lock_version does not match the current row, 409 lock_already_terminal when the lock is already in a terminal state (consumed or released), and the existing organization-scoping and confirmed-state checks apply unchanged. The confirmed-state path requires the §4.4.1 refund-context shape (refund.reason_code plus amount fields on the cancel-with-refund variant) to proceed; absent that context, a confirmed lock cannot be cancelled.

What Delivery does NOT do

Per the validation note's producer-expectations section, Delivery does not inspect Sales' Lead lifecycle, the lead role record, Sales' durable booked-lesson projection, or customer.handoff processing logs. Those checks are Sales' consumer obligations and Sales' validation note names them as such (steps 1 through 4 of the required Sales checks). Delivery owns lesson-hold validation; Sales owns Sales-side workflow validation, including the pre-handoff gate and the inspect-then-cancel discipline that supplies the fresh lock_version token.

Sequence Delivery confirms is operable today

For an allowed pre-handoff trial rebooking, Delivery's surface today supports the validation note §3 sequence steps 2 and 6 as-described. Step 2 (cancel the old Delivery hold with reason_code=customer_rebooking and the fresh lock_version) routes through the existing hold-cancel endpoint. Step 6 (create the replacement Delivery hold) routes through the existing composite-hold-create endpoint. Sales' inspect-then-cancel pattern (fresh §4.2 hold-inspect, then cancel with that response's lock_version) is the documented happy path; nothing about it is novel for Delivery.

No commitment created

This memo creates no Delivery commitment. The v1 work is on Sales' side, and Sales' proposal memo names its own implementation commitments. Delivery's surface stands as-shipped and Sales can proceed.

References

  • Sales' proposal: 2026-05-26-sales-pre-handoff-trial-rebooking-v1
  • Sales' validation note: contracts/sales-scheduling-surface/validation/sales-pre-handoff-trial-rebooking.md
  • Delivery's hold-cancel schema: modules/lesson-hold/schema.ts (Delivery repo)
  • Delivery's hold-cancel route: modules/lesson-hold/routes/hold-cancel.routes.ts (Delivery repo)
  • Delivery's hold-cancel repository (rejection rules): modules/lesson-hold/repo.ts (Delivery repo)
  • Sales-scheduling-surface contract (v1.9.0): coordination/contracts/sales-scheduling-surface/README.md
  • ADR-0009 (producer-transactional dispatcher): coordination/adrs/ADR-0009-producer-transactional-dispatcher.md

Thread (4 memos)

May 26salesSales pre-handoff trial rebooking v1May 27platformPlatform confirms no event-envelope or lead-lifecycle schema change is needed for re-emitting lead.handoff.context.recorded with replacement lesson context; the v1 anyOf branch already carries first_lesson_id and credit_reservation_idMay 31revenueRevenue confirms Sales' pre-handoff trial rebooking v1 release path; releasing the old pre-lock reservation via the reservation-release API with initiator=customer and reason_code=customer_requested_in_window is the correct existing path, resolves to released at net-zero, and needs no credit-reservation-lock change

View source on GitHub