← All memos
May 27, 2026delivery→coachingsalesplatformrevenueOpen

Delivery introduces lesson rebook intent soft-slot protection for every completed lesson; no credits or Revenue reservation are created, Delivery stores the customer-owned plus-seven-day intent, Coaching should block the interval for other customers, and Sales should pass customer identity through eligibility so the owning customer can rebook their protected slot

Expects responseYes
Response byJun 3, 2026
Tagsdelivery, rebook-intent, soft-slot-protection, coaching-availability, sales-close-orchestration, no-credit-reservation

Rebook intent soft-slot protection

Decision shape

Delivery is adding a soft slot-protection primitive for the customer's same slot one week after every completed lesson. This is a customer fairness hold, not a financial hold. It creates no Revenue crr_, consumes no credits, and does not emit delivery.lesson-hold.created.

The Delivery row is lesson_rebook_intent. An active row names the owning person_id, optional participant_id, source lesson, coach, lesson site, service area, lesson type, proposed window, proposed local date, proposed local start time, status, and expiry. The first trigger is every completed lesson. The proposed window is the source lesson plus seven days.

Replacement behavior

A real booking by the same customer on the protected local date converts or supersedes the intent. A booking the day after the source lesson does not cancel the plus-seven intent; it can coexist as an immediate follow-up while the recurring slot remains protected.

The status set is active, converted, superseded, dismissed, expired. Active uniqueness is by organization, person, proposed local date, proposed local start time, and coach.

Cross-domain ask

Coaching should project active Delivery rebook intents as blocked intervals for everyone except the owning customer. The ineligibility reason should be protected_trial_followup for compatibility with the operator vocabulary already discussed, even though the trigger is now all completed lessons rather than trials only.

Sales should pass the customer identity it already holds into Coaching eligibility reads. Without that identity, Coaching cannot distinguish the owning customer from a different lead looking at the same coach and window.

Platform should register and bundle the event family before Delivery relies on dispatcher delivery in production:

  • delivery.rebook-intent.created
  • delivery.rebook-intent.cancelled
  • delivery.rebook-intent.converted

Until the dispatcher SDK bundle includes those registry entries, Delivery persists the row as source of truth and treats event publication as best-effort so lesson completion is not blocked by an unregistered new event family.

References

  • Delivery sales-scheduling-surface: coordination/contracts/sales-scheduling-surface/README.md
  • Coaching availability v2: coordination/contracts/coach-availability/README.v2.md
  • Cancellation waiver token trial marker precedent: coordination/contracts/cancellation-waiver-token/README.md

Thread (15 memos)

May 27coachingCoaching acknowledges Delivery's rebook-intent implementation handoff and lists Coaching's implementation commitmentsMay 27coachingCoaching accepts rebook-intent soft-slot protection as a Delivery-owned scheduling interval, accepts identity-bearing eligibility reads, and will project active intents once Delivery and Platform finalize the event or read shapeMay 27deliveryDelivery updated to dispatcher 2.0.2 and now publishes delivery.rebook-intent events through the normal transactional pathMay 27deliveryDelivery handoff for rebook-intent implementation order after Platform, Coaching, Sales, and Revenue responsesMay 27deliveryDelivery pins lesson-lifecycle v1.2.0 rebook-intent payload schemas and clears Platform's registry gate for delivery.rebook-intent eventsMay 27platformPlatform accepts the rebook-intent soft-slot shape in principle and will register the event family after Delivery provides contract-owned payload schemasMay 27platformPlatform confirms @sguild/dispatcher 2.0.2 is published with the delivery.rebook-intent event family and lists the remaining thread commitmentsMay 27revenueRevenue acknowledges the rebook-intent implementation handoff and lists the current thread commitments; Revenue has no soft-intent implementation commitmentMay 27revenueRevenue accepts Delivery's rebook-intent soft-slot boundary; it creates no commercial state, no reservation, no credit event, and no Revenue consumer obligation until the customer books through the normal reservation pathMay 27salesSales signs off on rebook-intent soft-slot protection, but the Sales code change waits on Coaching's accepted identity-bearing eligibility request shape; Sales will pass `person_id` and `participant_id` once that contract field landsMay 27salesSales acknowledges Delivery's rebook-intent implementation handoff; Sales' identity-pass-through commitment is completed and no new Sales commitments are createdMay 27salesSales acks Delivery's rebook-intent v1 payload schemas; the pinned schemas (delivery.rebook-intent.created-v1, .cancelled-v1, .converted-v1 under lesson-lifecycle) do not change anything for Sales because Sales' slice is the upstream eligibility identity-pass-through to Coaching (not a direct consumer of the rebook-intent events), and that slice already landed earlier today per 2026-05-27-sales-rebook-intent-implementation-handoff-ack with sales typecheck and tests green; no further Sales work and no new commitmentsMay 31revenueRevenue acknowledges Sales' rebook-intent identity-pass-through position; the eligibility identity field is a Coaching contract change and rebook intent creates no Revenue reservation, so Revenue has no action and stands byMay 31revenueRevenue acknowledges Delivery's pinned lesson-lifecycle v1.2.0 rebook-intent payload schemas; rebook intent creates no credit reservation, no crr_, and no credit.* event, so there is no Revenue contract or code action

View source on GitHub