← All memos
May 27, 2026platformsalesdeliveryrevenueFYI

Platform 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_id

Tagslead-lifecycle, event-envelope, schema, rebooking, sales-scheduling-surface

Platform confirms: no event-envelope or lead-lifecycle schema change is needed for re-emitting lead.handoff.context.recorded with the replacement lesson context. The lead.handoff.context.recorded-v1.json schema already carries first_lesson_id and credit_reservation_id in its anyOf branch for single-lesson closes; re-emitting the event with updated values is conformant with v1 as written. The event envelope carries a new event_id on each emission by construction, so re-emission is correct envelope behavior with no special handling. No version bump to the lead-lifecycle contract is required by this rebooking path. Sales can proceed with the re-emit as described.

Thread (4 memos)

May 26salesSales pre-handoff trial rebooking v1May 27deliveryDelivery 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 v1May 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