Delivery dispatcher refresh needs before the package publish
Why
Delivery does have one dispatcher freshness need before Platform cuts the next @sguild/dispatcher package. The package should include the current canonical Delivery event registrations and payload schemas, and Platform should explicitly settle the delivery.lesson-hold.* versus delivery.lesson_hold.* naming drift before publish or preserve a compatibility path for the refresh window.
Delivery's repo currently publishes the hold events through the local vendored registry as delivery.lesson_hold.created and delivery.lesson_hold.cancelled. The canonical coordination registry now names those events delivery.lesson-hold.created and delivery.lesson-hold.cancelled. A package refresh that only bundles the canonical hyphenated names would be correct for the contract, but it will strand the current Delivery producer code until the repo-local constants and vendored slice are renamed.
What Delivery emits
Delivery currently emits these event types through @sguild/dispatcher: lesson.scheduled v1, lesson.rescheduled v1, lesson.cancelled v1, lesson.delivered v1, coach.assigned v1, delivery.lesson_hold.created v1, and delivery.lesson_hold.cancelled v1.
The canonical names Delivery expects the refreshed package to carry are delivery.lesson-hold.created v1 and delivery.lesson-hold.cancelled v1 for the sales-scheduling-surface hold events. If Platform wants the package to reject the underscored spellings immediately, please reply on this thread so Delivery can land the rename before adopting the refreshed package. If Platform can preserve an alias during the freshness cut, Delivery can follow with the repo rename without blocking the publish.
Delivery does not have a package-blocking new schema request for lesson.attended before this publish. The current terminal outcome paths publish lesson.delivered and lesson.cancelled; no lesson.attended producer hook is wired today.
What Delivery consumes
Delivery's webhook inbox currently handles these inbound event types: customer.handoff v1, credit.reserved v1, credit.locked v1, credit.released v1 and v2 payload-compatible shapes, credit.forfeited v1, credit.consumed v1, refund.completed v1, and lead.handoff.context.recorded v1.
The code path is a single inbox route with local idempotency and failed-status tracking, not one worker per subscription. Delivery does not currently handle the registry-listed but unwired Delivery consumer events credit.purchased, credit.funded, order.created, order.updated, or payment.received through the inbox.
Payload fields Delivery relies on
For produced lesson and assignment events, Delivery relies on validation preserving the operational identifiers and windows already present in the canonical schemas: organization_id, lesson_id, reservation_id, reservation_lock_id, participant_id, person_id, coach_id, lesson_site_id, service_area_id, lesson_zip, lesson_type_id, window.start, window.end, previous_window, new_window, previous_coach_id, new_coach_id, assigned_at, delivered_at, cancelled_at, and cancellation_reason.
For produced hold events, Delivery relies on organization_id, lesson_id, reservation_lock_id, reservation_id, participant_id, person_id, coach_id, lesson_site_id, service_area_id, lesson_zip, window, lesson_type_id, originator, idempotency_key, originating_offer_id, and offer_item_id.
For consumed Revenue lock and refund events, Delivery's lock mirror reads tenant_id, credit_reservation_id, lesson_id, credit_account_id, reserved_credits, reserved_at, locked_at, released_at, consumed_at, forfeited_at, refunded_at, occurred_at, resolved_at, reason_code, and funding_substate. For customer.handoff, Delivery reads tenant_id, person_id, first_lesson_id, credit_reservation_id, and handoff_at. For lead.handoff.context.recorded, Delivery reads lead_id, person_id, organization_id, first_lesson_id, credit_reservation_id, originating_offer_id, lead_summary, scheduling_notes, communication_preferences, recorded_by, and recorded_at.
Registry and replay support
Delivery does not depend on the npm package's bundled contracts in production validation today. lib/dispatcher/publisher.ts calls loadRegistry() against lib/dispatcher/contracts/event-types-registry.json, so producer validation uses the repo-local mirror. Delivery does use package runtime APIs for configureDispatcher, dispatcher.publish, verifyInboxRequest, and smoke-test signing.
Please preserve explicit loadRegistry(path) support, Prisma transaction publish support, signed inbox verification, and the current Platform DLQ or replay posture where a failed inbound envelope can be retried against Delivery's /api/dispatcher/inbox with the shared HMAC secret. Delivery does not need new DLQ APIs in this package refresh beyond that behavior.
Asks
Bundle the canonical Delivery event registrations and payload schemas in the refreshed package, including lesson.scheduled, lesson.rescheduled, lesson.cancelled, lesson.delivered, coach.assigned, delivery.lesson-hold.created, and delivery.lesson-hold.cancelled.
Please reply with the naming decision for the hold events before the publish: either package-level compatibility for delivery.lesson_hold.* during the refresh window, or confirmation that Delivery should rename local constants and the vendored registry slice to delivery.lesson-hold.* before adopting the package.
References
- Parent memo:
2026-05-20-platform-dispatcher-registry-refresh-needs - Canonical registry:
coordination/contracts/event-types-registry.json - Delivery vendored registry:
delivery/lib/dispatcher/contracts/event-types-registry.json - Delivery publisher:
delivery/lib/dispatcher/publisher.ts - Delivery inbox:
delivery/modules/dispatcher-inbox/service.ts