Re: Sales dispatcher freshness inventory before package publish

Why

Sales has no package-blocking SDK API needs before Platform cuts the dispatcher registry freshness publish. The main Sales need is that the package bundle include the current canonical registry and payload schemas from coordination, because several Sales emit and consumer paths were added after the package-era 2026-05-02 registry baseline.

What

Sales currently emits these dispatcher event types at schema_version 1 through @sguild/dispatcher: lead.created, lead.stage.changed, lead.reached, lead.callback.scheduled, lead.attempt.exhausted, lead.qualified, lead.coach.confirmation.requested, lead.handoff.context.recorded, sales.lead.onboarded, role.assigned, role.retired, and the transitional customer.handoff during the close-handler dual-emit window.

Sales currently consumes these event types through the dispatcher webhook inbox: person.updated, intake.captured, intake.amended, intake.matched, customer.handoff, credit.locked, credit.released, and the feature-gated platform.comms.inbound.

Near-term Sales consumer work also expects the package bundle to include the already registered payment.received and coaching.lesson.confirmation_decided schemas. Those handlers exist behind feature flags and still need routing or correlation work before they are fully live, but they are not a reason to hold the freshness publish if the current canonical registry is bundled.

Operationally, Sales relies on these payload fields being present in the bundle:

1. intake.captured@2: submission.new_qualified, submission.student_age_group, submission.timeline, submission.lesson_setting, qualified_at, ingestion_mode, and is_test_data.
2. intake.matched@2: person_id, originating_event_id, form_submission_id, source, campaign_code, landing_url, ingestion_mode, qualified_at, is_test_data, and submission_summary for the rare matched-before-captured path.
3. intake.amended@1: form_submission_id, changed_fields, and the full amended submission snapshot.
4. person.updated@1: person.person_id, person.status, person.is_test_data, changed_fields, and prior_status.
5. credit.locked@1: person_id, lesson_id, credit_reservation_id, and locked_at.
6. credit.released@1 and credit.released@2: credit_reservation_id, initiator, reversal_reason, cancelled_at, and the v2 reason_code.
7. platform.comms.inbound@1: communication_id, person_id, organization_id, channel, received_at, provider, provider_message_id, routing_result, guardian_routed, and body_preview.
8. payment.received@1: order_id, person_id, payment_method, payment_path, amount_cents, currency, provider_ref, and received_at.
9. coaching.lesson.confirmation_decided@1: confirmation_request_id, lead_id, coach_id, decision, denial_reason, lesson_window, service_area_id, lesson_type_id, decided_at, and decided_by.

Sales does not need new replay, DLQ, or registry override behavior preserved beyond the current package behavior. The app already loads registry candidates in this order: DISPATCHER_REGISTRY_PATH, the Sales vendored mirror at lib/dispatcher/contracts/event-types-registry.json, the sibling coordination registry, then the npm package bundle. That fallback order should remain safe after the refresh.

Asks

No additional dispatcher needs before the freshness publish. Please include the current canonical event registry and payload schema tree, including the post-2026-05-02 Sales producer events and the active or feature-gated Sales consumer events named above.

References

• 2026-05-20-platform-dispatcher-registry-refresh-needs
• coordination/contracts/event-types-registry.json
• sales/instrumentation.node.ts
• sales/modules/dispatcher-inboxes/dispatcher-inboxes.service.ts
• sales/modules/leads/leads.service.ts