Social Capability Registry

Single Source of Truth für Social-Funktionen im Cockpit: Was das Center braucht, welches Modul es bedient, welcher Backend-Provider es heute liefert — und wo wir später tauschen können, ohne UI umzubauen.

Code: apps/dashboard/src/lib/integration/social-capability-registry.ts

Nutzer-Doku: Social unter Cockpit
Provisioning-UI: Einstellungen → Social-Kanäle

Leitbild

Center-Capability  →  Cockpit-Modul  →  Backend-Provider (Outstand | Zernio | Cockpit)

• Capabilities = was Redaktion/Betrieb erwarten (Posten, Liken, Meta-Ads-KPIs, …)
• Module = sichtbare Oberflächen (Post, Freigaben, Community, Performance, Hub, Reporting)
• Provider = austauschbare Implementierung — nicht in der Nutzer-UI benennen

Registry-Struktur

Jeder Eintrag in SOCIAL_CAPABILITY_REGISTRY enthält:

Feld	Bedeutung
id	Stabile Capability-ID
userLabel	Deutsch, ohne Vendor-Namen (Hub-Chips, Doku)
module	Zuständiges Cockpit-Modul
primary	Standard-Backend heute
secondary / fallback	Ergänzung oder Fallback
swapNote	Entwickler-Hinweis für Provider-Wechsel

Beispiel — Kommentar liken:

commentLike: {
  primary: 'zernio',
  module: 'social-engage',
  swapNote: 'Wenn Outstand Like liefert: primary auf outstand setzen',
}

Konsumenten im Code

Konsument	Funktion
social-provider.ts	getSocialEngageCapabilities, Publish/Ads — thin re-export
social-channel-status.ts	Hub-Kanal-Status via resolveChannelProvisioning
social-channel-hub.tsx	Feature-Chips via SOCIAL_HUB_ORGANIC_FEATURES
/api/social/engage	engageCapabilities im JSON
MCP / Cron	Sollten Registry importieren (schrittweise)

Organische Kanäle (Hub)

resolveChannelProvisioning() prüft pro Kanal:

• Posten / Community lesen — Outstand verbunden + healthy
• Kanal-Inbox — zernioAccountId auf center_social_accounts
• Kommentar liken — Inbox provisioniert + Zernio env
• Facebook verbergen — Inbox + Netzwerk facebook/instagram

Hub zeigt vier Chips aus der Registry — keine hardcodierten Labels mehr in der Komponente.

Engage-API

resolveEngageCapabilities({ hasOutstandChannels, hasZernioEngageChannels }) liefert die Buttons in Community & Antworten — abgeleitet aus der Registry, nicht dupliziert in der Route.

Werbung

Capability	Provider	Modul
metaAdsMetrics	Zernio	client-reporting (+ Hub)
googleAdsMetrics	Zernio	client-reporting (+ Hub)

Mapping: center_ads_accounts — SSOT map-center-ads-accounts.ts.

Provider wechseln (Checkliste)

1. Eintrag in SOCIAL_CAPABILITY_REGISTRY anpassen (primary / fallback)
2. Implementierung in Engage/Publish/Sync-Job prüfen (Route ruft weiterhin Capability-Namen, nicht Vendor)
3. Hub-Status testen — resolveChannelProvisioning ggf. erweitern
4. Nutzer-Doku + Changelog
5. MCP-Hints nur wenn Agenten die Capability steuern sollen

Bekannte Lücken (Registry vs. Realität)

Capability	Registry	Umsetzung noch schwach
externalPostSync	Zernio	Hub + Cron (zernio-inbox-sync); optional ?syncZernio=1 in Engage
organicPostMetrics (Zernio)	secondary	Fallback wenn Outstand leer + hasAnalyticsAccess
Unified Performance (Paid)	—	includeAds in Social Performance + MCP reporting
commentAlerts	Cockpit+Outstand	Cron alle 30 Min; Outstand comment.*-Webhook vorbereitet
remoteDelete / repost / instagramDms	Outstand	Community: vom Kanal löschen, erneut teilen, Instagram-Nachrichten
MCP Engage write	—	cockpit_social_engage_action + POST AgencyOS engage

Diese Lücken sind kein Reporting-Thema — sie betreffen Community, Alerts und Performance.

Tests

cd apps/dashboard && pnpm exec vitest run src/lib/integration/social-capability-registry.test.ts

Siehe auch

• social-provider-types.ts — JSON-Typen für API
• social-outstand-capabilities.ts — netzwerk-spezifische Outstand-Checks (Hide/Delete)
• map-zernio-inbox-to-center-social.ts / map-center-ads-accounts.ts — Provisioning-SSOT