Overlay-Architektur

Bausteine

Ein installierbares Extension-Paket kann Overlay-Typen und freie Module über contributes bereitstellen. Aus einem Overlay-Typ entstehen beliebig viele Instanzen mit eigenem Namen, eigener Config, eigener Modulliste und stabiler OBS-URL.

Connectoren -> AppEvent -> globale Backend-FIFO -> registrierte Overlay-Listener
                                             -> Ack / Timeout / Disconnect
Admin-API -> Config-Revision -> Control-Frame -> updateConfig / Module-Sync

Eine Instanz speichert:

source und typeId
Host-config
geordnete modules[] mit id, enabled, layer und config
monotone configRevision
Aktivierungszustand und Browser-Source-URL

Runtime-Lifecycle

Overlay-Typen und Module sind ES-Module. Neue Beiträge exportieren:

export async function mount(context) {
  return {
    updateConfig(nextConfig) {},
    dispose() {}
  };
}

Der Host erhält #root; jedes freie Modul erhält einen eigenen absoluten, transparenten Layer. Module benötigen keine benannten Slots. Sie teilen den zugelassenen Browser-Kontext und kommunizieren über Runtime-Events.

Config-Änderungen sind Control-Nachrichten außerhalb der Event-FIFO. Die Runtime lädt den revisionierten Stand, ruft updateConfig auf und mountet bzw. entsorgt hinzugefügte oder entfernte Module ohne Seitenreload.

Kompatibilität und Sicherheit

Ein Manifest ohne contributes.overlays wird über das bisherige Top-Level-entry als einzelner Overlay-Typ interpretiert.
Alte einargumentige Eventhandler werden zur Kompatibilität sofort bestätigt.
Extension-Trust, Signaturprüfung, CSP, sichere Asset-Pfade und events:read bleiben aktiv.
Deaktivierte oder manipulierte Extensions werden nicht ausgeliefert.
Metadaten werden als nicht ausführbares application/json eingebettet; die CSP benötigt kein Inline-JavaScript.