ADR-049: Plugin-Plattformvertrag
Ein einziges unveränderliches Manifest und ein Capability-Modell regeln Owlats drei Vertrauensstufen für Erweiterungen.
- Status: Angenommen
- Datum: 2026-07-15
Kontext
Owlat verfügte bereits über typisierte Registries für Transports, Agent-Schritte, Automationen, UI-Oberflächen und weitere Erweiterungspunkte. Sie unabhängig voneinander zu öffnen hätte Regeln zu Identität, Berechtigungen, Reihenfolge und Fehlerverhalten dupliziert und es zugleich ermöglicht, dass eine Erweiterung eine zentrale Sicherheitsgrenze umgeht.
Entscheidung
Jedes Plugin exportiert über @owlat/plugin-kit genau ein reines Daten-Manifest. Der Host erfasst und validiert einen einzigen, tief eingefrorenen Snapshot vor Codegen oder Komposition. Manifest-Deklarationen fordern Capabilities an; eine Betreiberfreigabe und das Plugin-Feature-Flag werden bei jeder gehosteten Operation erneut geprüft.
Die Plattform kennt drei Vertrauensstufen:
- Gebündelte Plugins, die zur Build-Zeit komponiert werden.
- Connected Apps, die über gescopte APIs und signierte Hooks erreicht werden.
- Sandboxed Worker-Jobs, die host-registrierte Kommandos ohne ambiente Zugangsdaten ausführen.
Plugins dürfen Arbeit oder Vorsicht anfügen. Sie können keine Kernprüfungen ersetzen, keine Freigabe herbeiführen und keinen Versand erzwingen. Statische Codegen ist der einzige Kompositionspunkt, und veraltete oder ungültige generierte Ausgaben lassen den Build fehlschlagen.
Konsequenzen
Plugin-Identität, Attribution, Berechtigungen, Flags, Budgets und Reihenfolge teilen sich einen einzigen Vertrag. Gebündelter Code bleibt vertrauenswürdiger Deployment-Code und ist keine Sandbox; Betreiber müssen für Code, dem sie nicht vertrauen, Connected Apps oder Worker verwenden. Zum Betriebsmodell siehe Plugin-Plattform.