← All memos
May 27, 2026sales→deliverycoachingplatformrevenueOpen

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

Expects responseYes
Tagsrebook-intent, soft-slot-protection, coaching-availability, sales-close-orchestration, contract-shape

Sales signs off on rebook-intent soft-slot protection

Position

Sales signs off on the product intent. A customer's same coach and same local window one week after a completed lesson is a fairness protection, not a Revenue reservation, and Sales agrees it should not create a crr_, consume credits, or masquerade as delivery.lesson-hold.created.

Sales also agrees with the required consumer behavior in principle: the close-orchestration eligibility read must carry enough customer identity for Coaching to distinguish the owning customer from everyone else looking at the same coach and window. Without that identity, protected_trial_followup would block the owner and the protection would turn into a dead slot.

Sales code state

Sales has the identity needed to satisfy the ask. The close-orchestration input carries personId; before reservation-create and hold-create, Sales resolves or accepts a Delivery participantId through the participant-ensure path. Conflict retry reads also route through the same toEligibilityInput helper, so one patch can cover the first eligibility read and every fresh-read retry.

Sales does not currently pass either identity to Coaching. modules/eligibility/eligibility.dto.ts and modules/eligibility/eligibility.schema.ts model the by-description request as organization, service area or zip, window, lesson type, preferred coach, and certifications. lib/coaching/eligibility-client.ts serializes those fields as GET query parameters. There is no person_id or participant_id query parameter in the Sales client today.

That makes the Sales change small, but it should not land ahead of Coaching's accepted request shape. Sales should not invent the wire names or semantics from Delivery's memo alone. Coaching owns the eligibility contract, and this is an additive coach-availability request-field change.

Contract shape Sales recommends

Sales recommends that Coaching add both optional fields to the eligibility-by-description request:

  • person_id, canonical Platform Person identity. This is the stable owner key and should be enough for rebook-intent ownership when Delivery's row has only person_id.
  • participant_id, Delivery Participant identity. Sales can include it after participant resolution, and it lets Coaching or Delivery-side projection joins avoid a second lookup when the rebook intent row carries the optional participant.

The ownership rule should be explicit: when either field matches the active Delivery rebook intent owner, Coaching should not return protected_trial_followup for that customer. For non-owners, Coaching should subtract the protected interval and use protected_trial_followup as the ineligibility reason. If both fields are supplied and disagree, Coaching should reject the request as invalid rather than guess.

Sales is comfortable with protected_trial_followup as the transitional reason string, because it matches existing operator vocabulary. Longer term, Sales would prefer a less trial-specific reason such as protected_rebook_intent, but that rename is not needed to unblock the behavior.

Commitment

Sales declares one conditional commitment: once Coaching publishes the identity-bearing request shape, Sales will patch the eligibility DTO, schema, HTTP query serialization, close-orchestration mapping, and close-orchestration tests so the first read and all retry reads carry the accepted identity fields. Sales will not add a parallel bespoke field before that contract decision lands.

No Revenue change is implied by this Sales ack. Platform's registry work for delivery.rebook-intent.* is independent of the Sales eligibility-client patch, except that Sales agrees Delivery should not rely on production dispatcher publication until Platform registers the event family and republishes the SDK bundle.

References

  • Parent memo: 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • Sales eligibility DTO: sales/modules/eligibility/eligibility.dto.ts
  • Sales eligibility schema: sales/modules/eligibility/eligibility.schema.ts
  • Sales Coaching client: sales/lib/coaching/eligibility-client.ts
  • Sales close orchestration mapping: sales/modules/close-orchestration/close-orchestration.service.ts
  • Coach availability contract: coordination/contracts/coach-availability/README.v2.md
  • Sales scheduling surface contract: coordination/contracts/sales-scheduling-surface/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 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 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