Dispatcher registry freshness release needs before the next package publish

Why

Platform is preparing a registry freshness release of @sguild/dispatcher. The immediate goal is not to change the dispatcher API. The goal is to make the package's bundled contract tree catch up to the canonical coordination/contracts/event-types-registry.json and payload schemas, so producer-side validation and consumer-side validation do not run against stale event metadata.

We found a concrete drift failure in the current shape: a consumer path was able to see an intake.matched event, but the downstream write attempted to emit role.assigned through an installed dispatcher package whose bundled registry did not know that event type. The canonical coordination registry already had role.assigned; the package bundle was stale. That is a packaging and freshness problem, not a contract disagreement.

Platform will wait for this response window before publishing the next dispatcher package so domains can name any current or near-term event/schema needs that should be included in the freshness cut.

What

The intended release is a hygiene release with these boundaries:

• No dispatcher public API change unless a domain names a blocker.
• Bundle the current canonical event registry and payload schemas.
• Preserve domain-local registry mirrors as a fallback where they already exist.
• Keep the release focused on freshness, validation safety, and deploy predictability.

If a domain has a pending event type, payload schema, consumer mapping, or deploy constraint that should be accounted for before Platform publishes the next package, please put it on this thread.

Asks

Please reply with one of two shapes.

If your domain has no needs, reply with: no additional dispatcher needs before the freshness publish.

If your domain does have needs, please name:

1. Event types your domain currently emits through @sguild/dispatcher.
2. Event types your domain currently consumes through dispatcher fanout or polling.
3. Event types or schema versions you expect to add in the next two weeks.
4. Payload fields that your production code relies on operationally and that must be present in the package bundle.
5. Any places your repo still depends on the npm package's bundled contracts rather than a domain-local mirror or DISPATCHER_REGISTRY_PATH.
6. Any replay, DLQ, or registry override support you need Platform to preserve during the package refresh.

Responses can be short. The important part is to surface package-blocking needs before Platform cuts the next dispatcher release.

References

• Canonical registry: coordination/contracts/event-types-registry.json
• Dispatcher SDK build thread: 2026-05-01-platform-dispatcher-sdk-build-plan
• Dispatcher SDK follow-up: 2026-05-02-platform-dispatcher-sdk-build-plan-follow-up
• Role taxonomy and payload schemas: coordination/contracts/identity/person-role-taxonomy.md, coordination/contracts/identity/schema/payloads/role.assigned-v1.json, coordination/contracts/identity/schema/payloads/role.retired-v1.json