design: consolidate Connector and NotificationChannel into single outbound delivery SPI

[mdproctor]

Problem

Two parallel outbound delivery SPIs exist with overlapping Slack and Teams implementations:

casehub-connectors — Connector SPI (id() + send(ConnectorMessage)):

• Implementations: Slack, Teams, Twilio SMS, WhatsApp, Email
• Consumers: none yet (no code in any repo calls Connector.send())
• Trigger: not wired to any event

quarkus-work-notifications — NotificationChannel SPI (channelType() + send(NotificationPayload)):

• Implementations: Slack, Teams, HTTP webhook
• Consumer: NotificationDispatcher (wired to WorkItemLifecycleEvent)
• Trigger: WorkItem lifecycle events only

Slack and Teams are implemented twice. As features grow — case fault notifications, stalled commitment alerts, escalation notifications — a third and fourth parallel implementation becomes likely.

Proposed resolution

casehub-connectors is the canonical outbound delivery primitive. It is lower-level (no WorkItem coupling), more complete (adds SMS, WhatsApp, Email), and correctly named.

quarkus-work-notifications's NotificationChannel implementations for Slack and Teams should be removed. NotificationDispatcher should delegate to a Connector instance (found via CDI @Any Instance<Connector>).

The NotificationChannel SPI can remain as the quarkus-work-level abstraction for rule matching and dispatch — but its implementations must delegate to Connector rather than calling outbound APIs directly.

This also unblocks: stalled Qhorus commitment alerts, case fault notifications, and escalation notifications — all of which need outbound delivery but currently have no wired path.

Affected repos

• casehub-connectors — authoritative SPI (no changes needed)
• quarkus-work-notifications — SlackNotificationChannel, TeamsNotificationChannel replaced with Connector-delegating wrappers
• quarkus-qhorus — future WatchdogAlertSink SPI implementation would use Connector
• casehub-engine — future case fault/timeout notifications would use Connector

Part of

#4 (platform coherence audit — finding #7)

[mdproctor]

Link to signal bridge work: resolving this issue unblocks casehubio/qhorus#200 (WatchdogAlertEvent + ConnectorAlertBridge — audit finding #8 from parent#53). The watchdog alert path requires a consolidated Connector SPI as the delivery target before a bridge can be wired. Do not implement qhorus#200 until parent#5 is resolved.

[mdproctor]

The original problem — Slack and Teams implemented twice — is resolved. SlackNotificationChannel and TeamsNotificationChannel in casehub-work-notifications already delegate to SlackConnector/TeamsConnector from casehub-connectors. No duplicate outbound API calls exist.

HttpWebhookChannel stays as-is — this is the right design. The Connector SPI is for named external services with their own protocol/auth conventions. HttpWebhookChannel builds a WorkItem-specific JSON schema and signs payloads with a rule-level HMAC secret — both are inherently work-layer concerns that don't belong in a generic connector. It uses HttpHelper from casehub-connectors as a transport utility, which is the correct boundary.

Documented in casehubio/work@3d431de — comment on HttpWebhookChannel explains the intentional boundary so it isn't 'fixed' in the future.

Pattern going forward: any new named-service notification type (SMS, WhatsApp, Email) adds a NotificationChannel implementation that delegates to the corresponding Connector. HTTP webhooks stay as a separate work-layer concern.