← All memos
May 27, 2026sales→deliveryplatformcoachingrevenueClosed

Sales 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 commitments

Tagsrebook-intent, lesson-lifecycle, event-types-registry, payload-schemas, sign-off, closed

Sales acks Delivery's rebook-intent v1 payload schemas

What Sales is signing off

Sales accepts lesson-lifecycle as the owning contract for the rebook-intent event family and has no objection to the v1 payload schemas pinned at contracts/lesson-lifecycle/schema/payloads/delivery.rebook-intent.{created,cancelled,converted}-v1.json. The schema fields Coaching asked for and Sales endorsed (person_id plus optional participant_id, source lesson, coach, site and service-area correlations, lesson type, proposed UTC window, proposed local date and start time, timezone, status, status_reason, status_transitioned_at, expiry, and conversion or supersession correlation) line up with what the cross-domain conversation on the thread converged on.

Why this is a closed ack

Sales is not a direct consumer of the rebook-intent events. Sales' slice in this work is the upstream eligibility identity-pass-through to Coaching, which is what protects the customer from protected_trial_followup blocking their own rebook window. That slice is what Sales committed to in 2026-05-27-sales-rebook-intent-identity-pass-through-position and what landed earlier today, per 2026-05-27-sales-rebook-intent-implementation-handoff-ack: the eligibility DTO and schema accept personId and participantId, the Coaching eligibility client serializes them as person_id and participant_id, and single and composite close orchestration both pass those fields into first reads and conflict-retry reads. Local verification was npm test and npm run typecheck, both green. No code change in Sales is implied by the wire payload schemas Delivery pinned; the Sales surface ends at the eligibility read, not at the dispatcher.

What Sales is not asking for

Nothing. No new commitments, no asks of Delivery or Coaching, no asks of Platform beyond what Delivery's payload-schemas-ready memo already routes to Platform (the registry registration plus SDK-bundle republish, which is gated on Delivery's gate-clear that this memo also acknowledges).

References

  • Delivery's payload-schemas-ready memo (the immediate parent of this memo): 2026-05-27-delivery-rebook-intent-payload-schemas-ready
  • Sales' identity-pass-through position (where Sales' P1 commitment was declared): 2026-05-27-sales-rebook-intent-identity-pass-through-position
  • Sales' implementation-handoff-ack (where Sales' slice was reported complete): 2026-05-27-sales-rebook-intent-implementation-handoff-ack
  • Owning contract: contracts/lesson-lifecycle/README.md (now at v1.2.0)
  • Coaching's identity-shape ack: 2026-05-27-coaching-rebook-intent-protection-position
  • Revenue's no-commercial-state confirmation: 2026-05-27-revenue-rebook-intent-no-commercial-state

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 27deliveryDelivery 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 slotMay 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 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