Plugin SDK + Runtime Refactor Plan

Ziel: Jeder Messaging-Connector ist ein Plugin (gebundelt oder extern) das eine stabile API nutzt. Kein Plugin importiert direkt aus src/**. Alle Abhaengigkeiten gehen ueber das SDK oder die Runtime.

Warum jetzt

  • Aktuelle Connectors mischen Muster: direkte Core-Imports, dist-only-Bridges und Custom-Helper.
  • Das macht Upgrades fragil und blockiert eine saubere externe Plugin-Oberflaeche.

Zielarchitektur (zwei Schichten)

1) Plugin SDK (Compile-Time, stabil, veroeffentlichbar)

Scope: Typen, Helper und Config-Utilities. Kein Runtime-Zustand, keine Seiteneffekte. Veroeffentlichen als openclaw/plugin-sdk. Semver mit expliziten Stabilitaetsgarantien.

2) Plugin Runtime (Ausfuehrungsoberflaeche, injiziert)

Scope: Alles was Core-Runtime-Verhalten beruehrt. Zugriff via OpenClawPluginApi.runtime, damit Plugins nie src/** importieren.

Migrationsplan (phasenweise, sicher)

Phase 0: Scaffolding

Phase 1: Bridge-Cleanup (BlueBubbles, Zalo zuerst)

Phase 2: Leichte Direct-Import-Plugins (Matrix)

Phase 3: Schwere Direct-Import-Plugins (MS Teams)

Phase 4: iMessage-Pluginisierung

Phase 5: Durchsetzung (Lint-Regel: keine extensions/** Imports aus src/**)

Erfolgskriterien

  • Alle Channel-Connectors sind Plugins mit SDK + Runtime.
  • Keine extensions/** Imports aus src/**.
  • Neue Connector-Templates haengen nur von SDK + Runtime ab.
  • Externe Plugins koennen ohne Core-Quellzugang entwickelt werden.

Verwandte Docs: Plugins, Channels, Konfiguration.

Weiter
Overview
arrow_forward