Plugin Extensions und Events nach dem DevDay

Was sich am DevDay erweitert hat

Plugins gab es schon vor dem 29. September 2026. Neu beschrieben wurden unter anderem Plugin Extensions und MCP Events. Extensions können Sidebar-Apps, Panels neben Unterhaltungen, Dateibetrachter, Editoren und Formulare ergänzen. Das sind Möglichkeiten für passende Plugins, keine Garantie, dass jede installierte App bereits eine solche Oberfläche bietet.

Die speziellen Extension-Composer-Mentions sind Desktop-only; das darf nicht mit gewöhnlichen @-Pluginbezügen gleichgesetzt werden. Für Free-/Go-Web-Extensions nennt die Dokumentation „coming soon“. Ein Termin für jede Oberfläche oder ein pauschaler EU-Start folgt daraus nicht. Nutze nur die tatsächlich angebotene Funktion; die Lernmethode kannst du als Dokument vorbereiten.

Schritt 1: Den Nutzen vor dem Panel benennen

Ein Formular kann strukturierte Workshopdaten sammeln; ein Panel kann eine Ergebnisdatei zur Prüfung zeigen. Frage zuerst, welche Arbeit dadurch einfacher wird. Du brauchst kein eigenes UI für einen einmaligen Quellenvergleich. Für eine wiederkehrende Aufgabe kann ein klares Formular fehlende Eingaben sichtbar machen und ein Panel die Abnahme erleichtern.

Schritt 2: Den Ereignisweg unterscheiden

Die Scheduled-Dokumentation beschreibt bestimmte Gmail-, Slack- und GitHub-Trigger für Web-/Mobilkonten. Die MCP-Events-Dokumentation beschreibt einen anderen Integrationsweg: Work-Web, Desktop-Work mit Cloudausführung und dots, mit MCP 2.0 und webhookfähigem Server. Dieser Weg ist kein Polling oder Streaming. Du kannst deshalb weder sagen „Events gehen nie auf Desktop“ noch „jedes Plugin kann automatisch Events“.

Beispiel 1: Bits & Bolts als dokumentierte Extension ausprobieren

OpenAI nennt in der offiziellen Extension-Dokumentation das Beispielplugin Bits & Bolts Remote. Es demonstriert unter anderem eine CAD-Teilebibliothek in der Sidebar, einen Viewer für STL-Dateien und Bildauswahl in einem Formular. Das ist ein konkret benanntes offizielles Beispiel, keine von uns erfundene App. Die folgenden Schritte stammen aus der dokumentierten Darstellung; wir haben das Plugin für diese Begleitseite nicht in deinem Konto installiert oder einen eigenen Live-Erfolg behauptet.

1. Öffne den offiziell verlinkten Plugin-Eintrag. Prüfe Herausgeber, Inhalt, angebotene Berechtigungen und deine Workspace-Regeln. Installiere es nur in einem ausdrücklich erlaubten Demo-/Testkontext. Eine Installation für die Übungen dieses Buchs ist optional.
2. Öffne die angebotene Sidebar-App. Erwartetes Lehrziel: Die Teilebibliothek kann unabhängig von einer langen Chatantwort als eigene Oberfläche geöffnet werden. Die genaue Beispieldarstellung kann sich ändern.
3. Wenn der installierte Beispielstand den dokumentierten STL-Viewer anbietet, öffne eine freigegebene Beispieldatei mit dieser Endung. Erwartet: der passende Viewer im Seitenpanel, nicht nur eine Textbeschreibung der Datei. Ohne passende Datei oder Viewer wird der Test als nicht ausgeführt festgehalten.
4. Vergleiche Sidebar und Gesprächspanel: Welcher Kontext bleibt bei der Unterhaltung, welcher liegt in der Pluginoberfläche? Prüfe vor Speichern oder Ändern das konkrete Ziel. Eine Oberfläche erteilt nicht automatisch Schreibrechte.
5. Falls ein dokumentiertes Bildauswahlformular erscheint, wähle einen unkritischen Beispielwert und kontrolliere den zurückgemeldeten Wert. Eine hübsche Auswahl ist erst dann nützlich, wenn ihre Daten korrekt bei der Aufgabe ankommen.

Halte Oberfläche, Pluginversion beziehungsweise Prüftag, Datei und erwarteten/erreichten Zustand fest. Fehlende Extension ist eine Rollout-/Pluginfrage und kein Fehler deines Prompts. Bits & Bolts ist hier kein behauptetes MCP-Eventplugin; die neue Oberfläche und der Ereignisweg werden getrennt gelernt.

Beispiel 2: ein Ereignisablauf mit dem bekannten GitHub-Plugin

Die offizielle Scheduled-Anleitung dokumentiert Ereignisse für GitHub. Das folgende konkrete Beispiel gehört zu Scheduled-GitHub-Triggern, nicht automatisch zum neuen MCP-Events-Protokoll. Du brauchst ein genehmigtes Testrepository, ein verbundenes GitHub-Konto mit dessen Leserecht und einen freigeschalteten Web-/Mobilkontext. Lege kein unbekanntes Demo-Plugin zugrunde.

Beschreibe das Testrepository mit seiner tatsächlichen Adresse und einen engen Auslöser, beispielsweise neue Pull Requests mit dem Label „Workshop-Demo“. Lass zuerst angebotene Events und Filter ermitteln. Stimmen diese nicht mit dem Vorhaben überein, wird kein ähnlich klingender Ersatz ungefragt eingerichtet.

Verwende das genehmigte GitHub-Testrepository [tatsächlicher owner/name].
Prüfe die verfügbaren Ereignisse und Filter für neue Pull Requests.
Für passende PRs: erstelle eine interne Notiz mit Titel, Nummer, Quelle,
belegten Änderungen und offenen Prüfpunkten. Keine Kommentare posten,
kein Merge, keine Dateien verändern. Zeige zuerst den genauen Filter,
das verbundene Konto und die Reaktionsanweisung zur Abnahme.

Nach konkreter Abnahme des Testablaufs prüfst du die gespeicherte Ereignisaufgabe. Ein genehmigter Tester erstellt einen kleinen Test-PR im dafür bestimmten Repository; die Anleitung behauptet nicht, dass wir für dich einen PR oder eine Nachricht erzeugt haben. Erwartete Ausgabe: richtige PR-Nummer und Quelle, tatsächliche Änderungen, offene Punkte und keine externe Handlung. Ein PR außerhalb des Filters darf keine passende Reaktion erzeugen. Stoppe anschließend die Testaufgabe im vorgesehenen Scheduled-Weg und prüfe ihren deaktivierten Zustand. Ohne Testrepository oder Triggerfreischaltung bleibt dieses Beispiel ein dokumentierter Entwurf.

Beispiel 3: MCP Events am klar benannten Kommentarentwurf verstehen

Für den neuen MCP-Weg nutzen wir einen ausdrücklich nicht installierten Entwurf „Lindenhof-Kommentare“. Er basiert auf dem offiziellen Beispiel comment.created mit dem Filter document_id. Die Testereignis-Datei enthält fiktive IDs und eine absichtlich nicht aufrufbare example.invalid-Adresse. Sie ist ein Datenbeispiel, kein Callback, Credential oder erreichbarer MCP-Server.

Ein Entwickler würde einen authentifizierten MCP-2.0-Server mit Protokollversion 2026-07-28 und den Methoden events/list, events/subscribe und events/unsubscribe bereitstellen. Die Discovery muss Events tatsächlich anbieten. ChatGPT stellt beim Abonnieren Callback und Signierschlüssel bereit; der Server prüft Callback, speichert Subscription und Filter und liefert passende Ereignisse als signierte Webhooks. Polling und Streaming sind in diesem Integrationsweg nicht unterstützt. Diese technischen Arbeiten werden nicht durch einen Satz auf einer Page erledigt.

Den Reaktionsentwurf mit den gelieferten Daten prüfen

1. Lade die JSON-Testdatei in einen normalen manuellen Work-Test. Sage ausdrücklich, dass keine Subscription eingerichtet werden soll.
2. Prüfe Ereignisname comment.created, document_id lindenhof-workshop-demo und Kommentartext. Die Reaktion soll ausschließlich eine interne Änderungsnotiz erstellen.
3. Erwartete Notiz: „Agenda liegt als Entwurf vor; Abnahme weiter offen. Quelle: Kommentar-001. Nächste Entscheidung: Agenda prüfen.“ Sie darf weder „Agenda freigegeben“ schreiben noch andere Projektdaten ändern.
4. Wiederhole mit identischem eventId. Erwartet im entworfenen Betriebsablauf: kein zweiter externer Vorgang; als bereits verarbeitet erkennen beziehungsweise vorhandene Notiz wiederfinden. Dieser manuelle Test beweist keine serverseitige Idempotenz.
5. Ändere in einer Kopie document_id auf ein anderes Testdokument. Der entworfene Filter soll das Ereignis ausschließen. Schließe im Ergebnis ausdrücklich aus, dass damit eine echte registrierte Subscription getestet wurde.

Abnahme eines später tatsächlich eingerichteten MCP-Tests

In einem genehmigten Entwickler-Testkontext prüfst du nacheinander: Events auf der Pluginseite nach Rescan sichtbar; Work im Web oder Desktop mit Cloud; events/subscribe mit dem richtigen Filter; erfolgreiche Callbackverifikation; gespeicherte Subscription; passender Testwebhook mit 2xx-Empfang; richtige asynchrone Chatreaktion; nicht passender Filter ohne Zustellung; events/unsubscribe nach Stopp. Ein 2xx bestätigt den Empfang, nicht bereits die korrekte fachliche Ausgabe. Wiederholungen, verlorene Rechte und unterbrochene Verbindung brauchen eigene Tests.

Schlüssel bleiben ausschließlich im vorgesehenen Server-/Verbindungsweg. Quellkommentare sind Daten und erhalten keine Befugnis, Empfänger, Konto oder Freigabegrenzen zu ändern. Bei einer getrennten MCP-Subscription ist das Abschalten eines beliebigen Zeitplans kein Stoppnachweis; bestätige unsubscribe und ausgebliebene weitere Zustellung im tatsächlichen System.

Abnahme und Fehlerbehebung

Erkennst du den Unterschied zwischen einer Extension, einem bekannten Scheduled-Trigger und einer MCP-Subscription? Für die Begleitübung reicht ein sauber benannter Entwurf mit erwarteter Ausgabe. Für einen produktiven Ablauf brauchst du nachgewiesene Discovery, Registrierung, Testzustellung, richtige Ausgabe und Abschaltung. Fehlen Zugang oder Eventunterstützung, markiere die Grenze. Eine manuelle Reaktion oder ein Zeitplan ist eine Alternative, kein identischer Ereignismechanismus.