Revenue dispatcher registry freshness needs before the package publish

Why

Revenue does have dispatcher package freshness needs before Platform cuts the next @sguild/dispatcher publish. The Revenue repo currently depends on @sguild/dispatcher@2.0.0; startup wires the SDK transport through instrumentation.ts, and the package bundle is therefore on the hot path for producer validation and inbox verification.

The installed package bundle is older than the canonical coordination registry. In particular, the installed bundle is missing the canonical order.created, order.updated, delivery.lesson-hold.created, and delivery.lesson-hold.cancelled entries that Revenue now relies on or is preparing to rely on. The package already carries credit.released v2, the reservation.* funding events, payment.*, refund.*, and the core credit.* set.

What

Revenue currently emits through its typed dispatcher wrapper and the SDK-backed transport:

1. customer.handoff@1
2. credit.purchased@1
3. credit.reserved@1
4. credit.funded@1
5. credit.locked@1
6. credit.consumed@1
7. credit.released@2
8. credit.forfeited@1
9. payment.received@1
10. payment.failed@1
11. order.created@1
12. order.updated@1
13. refund.initiated@1
14. refund.completed@1
15. reservation.funded@1
16. reservation.refunding@1
17. reservation.refunded@1

Revenue currently consumes through the dispatcher inbox:

1. lesson.delivered@1
2. delivery.lesson-hold.created@1

The canonical registry also lists Revenue as a consumer for delivery.lesson-hold.cancelled@1. The current handler does not branch on that event yet, but the package refresh should include it so Revenue can add the handler without another package-blocked registry turn.

In the next two weeks, Revenue expects to keep the same event surface rather than propose a new event type. The practical freshness need is for the package bundle to include the canonical registry and schemas already present in coordination, especially:

1. order.created@1
2. order.updated@1
3. delivery.lesson-hold.created@1
4. delivery.lesson-hold.cancelled@1
5. credit.released@2
6. reservation.funded@1
7. reservation.refunding@1
8. reservation.refunded@1

The operationally load-bearing payload fields for Revenue are:

1. payment.received.payment_path, which preserves writeback separation between invoice_paid and active_charge.
2. payment.received.provider_ref and payment.failed.provider_ref, which tie internal writeback to the processor fact without collapsing the two.
3. refund.initiated.provider_ref and refund.completed.provider_ref, which preserve refund reconciliation.
4. credit.released.reason_code on schema version 2, including the auto-release versus explicit-operator partition from the credit-reservation-lock contract.
5. reservation.*.payment_processor_provider and reservation.*.payment_processor_ref, which are required by Revenue's funding-state external-reference rule.
6. order.created.order_id, order.created.person_id, order.updated.status_from, order.updated.status_to, and the paid and total amount fields, which Sales, Delivery, Revenue reconciliation, and the warehouse use to distinguish commercial state transitions.
7. delivery.lesson-hold.created.reservation_id, lesson_id, organization_id, window.start, and window.end, which let Revenue attach Delivery-created lessons to Revenue reservations before consumption.
8. lesson.delivered.lesson_id, optional credit_reservation_id, and delivered_at, which drive the lesson-completion consumption path.

Revenue's installed package still uses the package-bundled contracts/event-types-registry.json; the repo does not currently set DISPATCHER_REGISTRY_PATH as the normal runtime path. Revenue also uses package exports for inbox verification and dedup helpers (verifyInboxRequest, EventEnvelope, and tryInsertOrDetectConflict), so preserving those APIs matters during the refresh.

Asks

Please include the current canonical coordination registry and payload schemas in the package publish. Revenue treats the missing order.* and delivery.lesson-hold.* bundle entries as the package-blocking items for this freshness cut.

Please preserve the package-bundled registry default and any explicit registry path override support the SDK already has. Revenue can use an override for local verification, but production should keep working from the package bundle.

Please preserve existing replay, DLQ, fanout, inbox verification, and dedup support. Revenue has dispatcher tables for events, cursors, dedup, inbox dedup, and dead letters, and the operator UI exposes those surfaces.

References

• revenue/instrumentation.ts
• revenue/lib/dispatcher.ts
• revenue/modules/dispatcher-inbox/service.ts
• revenue/modules/dispatcher-inbox/routes/inbox.routes.ts
• coordination/contracts/event-types-registry.json
• Parent memo: 2026-05-20-platform-dispatcher-registry-refresh-needs