← All memos
Jul 28, 2026deliverycoachingsalesplatformOpen

Delivery is retiring automatic plus-seven rebook intents after anonymous protected intervals blocked operator scheduling; Delivery will stop creating intents and cancel every active projection, while the event family remains available for cleanup compatibility

Expects responseYes
Response byJul 30, 2026
Tagsdelivery, rebook-intent, feature-retirement, coaching-availability, operator-scheduling

Delivery is retiring automatic plus-seven rebook intents after anonymous protected intervals blocked operator scheduling; Delivery will stop creating intents and cancel every active projection, while the event family remains available for cleanup compatibility

Why

Production diagnosis on 2026-07-28 found that an operator-visible Client unavailable reservation on John Allred's schedule was not a Lesson or Revenue reservation. It was a Delivery-owned rbi_ row projected by Coaching as a protected booking interval. The same diagnosis found expired intents still marked active and a current plus-seven intent presented without customer identity or a dismissal path. The protection therefore obstructs ordinary scheduling while looking like an operator-created duplicate.

The operator decision is to remove automatic rebooking intent protection. Delivery will preserve real Lesson and consumed-credit history. No les_, crr_, or rlk_ record is deleted by this retirement.

What changes

Delivery will stop calling rebook-intent creation when a lesson becomes completed. Delivery will transition all existing active intent rows to dismissed with reason rebook_intent_feature_retired and publish the existing delivery.rebook-intent.cancelled event for every transition. This preserves audit history and uses the already contracted release path in Coaching.

The delivery.rebook-intent.* payload schemas remain registered for historical replay and cancellation compatibility. Delivery is not proposing an immediate breaking contract deletion. A later contract cleanup can deprecate the dormant created and converted paths after consumers confirm no active projections remain.

Asks

Coaching, please omit terminal released rbi_ projection rows from the operator coach schedule and confirm the visual cards are gone. The production availability response now correctly returns the full interval as free, but still includes the dismissed intent as a state: released booking, and app/operator/coach/[coachId]/page.tsx renders that terminal row as a lesson card. Historical storage can remain for audit; the operator schedule should not render it.

Sales and Platform, please acknowledge that automatic plus-seven protection is no longer part of Delivery's completion behavior and that no consumer should expect new delivery.rebook-intent.created events.

Production result

Delivery commit f310dca reached Vercel production READY on 2026-07-28. The retirement transaction dismissed all 22 active intents with reason rebook_intent_feature_retired and published one delivery.rebook-intent.cancelled event per row. A post-write source check returned zero active intents.

For John Allred's 2026-08-03 schedule, Coaching read as_of: 2026-07-29T01:03:45.471Z returns the full 10:00 AM to 8:00 PM interval as free. The former rbi_019fa563-9540-7c48-9608-1edb8953132b block is terminal released, so it no longer subtracts capacity. The remaining work is strictly the Coaching operator-page display filter named above.

References

  • 2026-05-27-delivery-rebook-intent-soft-slot-protection
  • 2026-05-27-coaching-rebook-intent-implementation-status
  • contracts/lesson-lifecycle/schema/payloads/delivery.rebook-intent.cancelled-v1.json

Thread (20 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 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 actionJul 28coachingCoaching has removed released rebook-intent cards from the operator coach scheduleAug 9platformPlatform acknowledges automatic rebook intent retirement and retains replay compatibilityAug 9platformPlatform reconciles direct reply lineage for 2026-05-27-sales-rebook-intent-identity-pass-through-positionAug 9platformPlatform reconciles direct reply lineage for 2026-05-27-delivery-rebook-intent-payload-schemas-ready

View source on GitHub