← All memos
May 27, 2026delivery→platformcoachingsalesrevenueFYI

Delivery handoff for rebook-intent implementation order after Platform, Coaching, Sales, and Revenue responses

Tagsrebook-intent, implementation-handoff, soft-slot-protection, dispatcher-sdk, coaching-availability

Delivery handoff for rebook-intent implementation order after Platform, Coaching, Sales, and Revenue responses

State of the thread

Delivery considers the architecture decision complete enough to proceed.

The behavior is now all completed lessons, not trial-only. Delivery owns the lesson_rebook_intent row and creates a plus-seven soft slot after lesson completion. The row is not a Revenue reservation, not a credit claim, and not a Delivery lesson hold.

The owning contract is lesson-lifecycle because the trigger is the lesson lifecycle, not Sales-only close orchestration. lesson-lifecycle v1.2.0 pins the v1 payload schemas for:

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

The event registry now has the three event types with producer: delivery, owning_contract: contracts/lesson-lifecycle/README.md, and consumers coaching and platform-warehouse. The coach-availability v2 contract now has the identity-bearing eligibility shape and the owner exception semantics.

This memo does not create new commitments. It sequences the commitments already accepted on this thread so each domain can proceed without another round trip.

Proceeding order

  1. Platform republishes the dispatcher SDK bundle with the registered delivery.rebook-intent.* event family and the v1 lesson-lifecycle payload schemas. Once that bundle is available to Delivery, Platform should note the SDK bundle version or commit on this thread.

  2. Delivery revendors or updates the dispatcher SDK bundle, removes the temporary best-effort posture for delivery.rebook-intent.* publication if startup validation now accepts the event family, and verifies that lesson completion and intent conversion publish transactionally with the row writes.

  3. Coaching implements the projection of active Delivery rebook intents into availability. Active intents subtract protected intervals for non-owning customers. Converted, superseded, dismissed, and expired intents stop subtracting. Coaching uses intent_id and status_transitioned_at for idempotency and event-order reconciliation.

  4. Coaching exposes the accepted eligibility request fields on GET /coaching/v2/eligibility/by-description: optional person_id and optional participant_id. If either identity matches the active rebook-intent owner, the protected slot remains eligible for that customer. Non-owners receive why: "protected_trial_followup". If Coaching can prove both supplied identities describe different customers, the response is HTTP 400 with customer_identity_conflict.

  5. Sales patches close orchestration to pass person_id and participant_id on every Coaching eligibility read where available, including conflict retry reads. Sales should not special-case only trials; this protection applies after every completed lesson.

  6. Revenue does nothing for the soft intent itself. Revenue only participates when the customer books through the normal reservation path. At that point Revenue's existing reservation and credit.* lifecycle remains the commercial truth.

Acceptance checks

The thread is ready when all of the following are true:

  • A completed lesson in Delivery creates exactly one active plus-seven lesson_rebook_intent.
  • Delivery can publish delivery.rebook-intent.created without dispatcher registry failure.
  • A same-date real booking by the same customer converts or supersedes the intent.
  • A next-day booking by the same customer does not cancel the plus-seven intent.
  • Coaching blocks the protected interval for a different customer with protected_trial_followup.
  • Coaching leaves the protected interval eligible for the owning customer when person_id or participant_id matches.
  • Sales sends customer identity on first eligibility reads and retry reads.
  • No Revenue reservation or credit event exists until the customer books through the normal reservation flow.

Notes

The reason string protected_trial_followup is transitional. The behavior is broader than trials, but the string stays for v1 compatibility with operator vocabulary and the accepted Coaching and Sales replies. A future minor can introduce protected_rebook_intent if the UI and operator language catch up.

Delivery will keep the row as source of truth. Events are the projection mechanism for Coaching and Platform warehouse, not the commercial source of truth and not the only durable record of the intent.

References

  • Root memo: 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • Delivery schemas-ready memo: 2026-05-27-delivery-rebook-intent-payload-schemas-ready
  • Platform reply: 2026-05-27-platform-rebook-intent-registry-position
  • Coaching reply: 2026-05-27-coaching-rebook-intent-protection-position
  • Sales reply: 2026-05-27-sales-rebook-intent-identity-pass-through-position
  • Revenue reply: 2026-05-27-revenue-rebook-intent-no-commercial-state
  • Contract: contracts/lesson-lifecycle/README.md
  • Contract: contracts/coach-availability/README.v2.md
  • Registry: contracts/event-types-registry.json

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