Für das Ökosystem mit deinem eigenen Agenten bauen

Erstelle SOIS-Erweiterungen mit dem KI-Agenten, den du bereits nutzt (Claude, ChatGPT, Cursor, Gemini oder jedes MCP-fähige Tool). Du verbindest deinen Agenten mit dem SOIS-MCP-Server, baust die Erweiterung auf deinem eigenen Rechner und lädst sie dann zur Prüfung und Veröffentlichung hoch. Du nutzt deine eigene KI. SOIS berechnet nichts für den Bau.

Das ist der Ökosystem-Pfad. Jeder kann für den Marktplatz bauen und mit seinen Apps verdienen. Du brauchst das Entwicklerportal nicht, um eine eigene Erweiterung zu bauen. Es reicht, deinen Agenten zu verbinden. Im Portal veröffentlichst du im Marktplatz und verwaltest deine Auszahlungen. Siehe Apps monetarisieren für das Erlösmodell.

So funktioniert es

  1. Verbinde deinen Agenten mit dem MCP-Server deines Workspaces (OAuth oder ein Token).
  2. Baue lokal gegen die SOIS-Spezifikation, die dein Agent über MCP liest.
  3. Validiere mit einer kostenlosen statischen Prüfung, bis alles sauber ist.
  4. Lade das Bundle hoch. Es wird gehärtet, geprüft und zur Review in die Warteschlange gestellt.
  5. Prüfen und veröffentlichen. Nach der Freigabe ist deine Erweiterung live im Marktplatz.

Verbinde deinen Agenten

Die Build-Tools liegen auf dem eigenen MCP-Server deines Workspaces, demselben Endpunkt, der in MCP Server beschrieben ist. Es gibt keinen separaten Build-Server einzurichten: du verbindest dich einmal, und weil dein Account bauen darf, erscheinen die Build-Tools automatisch in der Tool-Liste deines Agenten. Sie sind admin-geschützt und werden nur für Accounts mit Builder-Rechten angezeigt.

Server:     https://<your-workspace-host>/api/mcp
Discovery:  https://<your-workspace-host>/.well-known/mcp.json

Verbinden: der empfohlene Weg ist OAuth. Füge die MCP-URL deinem Client hinzu (Claude, ChatGPT, Cursor und andere). Er erkennt die Anmeldung und verbindet sich, ohne dass du etwas einfügen musst. Ein Bearer-Token plus ein X-Api-Key-Header funktioniert ebenfalls für Clients ohne OAuth. Siehe MCP Server für den vollständigen Verbindungsablauf und die Discovery-Details.

Dein Agent hat dann die Build-Tools verfügbar. Starte jedes Build, indem du ihn aufforderst, die Regeln zu lesen.

Die Build-Tools

Tool Was es macht
getExtensionRules Das kanonische Manifest, Migrations-, Berechtigungs-, Toolkit-, i18n-, UI- und Sicherheitsregeln. Rufe das zuerst auf.
getExtensionFrameSpec Der Host-Frame-Vertrag für die lokale Vorschau: die Mount-Signatur, Theme-Tokens, REST-API-Form und Bundle-Format.
createExtensionProject Erstellt ein neues App-Projekt. Gibt eine project_id zurück.
validateExtensionBundle Führt einen kostenlosen statischen Trockenlauf auf deinen Dateien aus und liefert zu behebende Probleme. Führe ihn so oft aus, wie du möchtest.
uploadExtensionBundle Reicht dein Bundle ein. Es wird gehärtet, geprüft und bei Bestehen zur Review in die Warteschlange gestellt.
getExtensionStatus Der Lebenszyklus-Status und der neueste Validierungsbericht für ein Projekt.
listExtensionProjects Deine Projekte und deren Status.

Bundle-Format

Eine Erweiterung ist ein kleines Bundle aus Dateien:

Datei Zweck
manifest.json Die einzige Quelle der Wahrheit: ID, Entitäten, Datenmodell, Berechtigungen, Dateien.
index.js Die UI, geschrieben als Vanilla-JavaScript-IIFE, das über window.AppExtension.mount eingebunden wird. Kein Framework im Bundle.
toolkit.js Optionale Agent-Tools, nach dem Examiner-Muster.
permissions.json Berechtigungsschlüssel, die zu deinen Routennamen passen.
migrations/ Datenbanktabellen mit dem Namen ext_{name}_{table} mit einer id und einer data-JSON-Spalte.
lang/ Locale-Dateien, jeder Schlüssel mit dem Präfix ext_{name}.

Wichtige Regeln, die dein Agent aus getExtensionRules durchsetzt:

  • Geschäftsdaten liegen in der data-JSON-Spalte, nicht als separate Spalten.
  • Keine Fremdschlüssel über Erweiterungen hinweg, kein DROP, TRUNCATE oder dropColumn in einer Migration up(), kein Raw-SQL, kein Shell- oder Dateisystemzugriff.
  • Gestalte die UI mit den --ext-*-Theme-Tokens, damit sie zu SOIS passt. Hartcodierte Farben oder nutzerseitige Texte sind nicht erlaubt.

Vor dem Upload validieren

validateExtensionBundle führt dieselbe kostenlose statische Prüfung aus, die der Server beim Upload durchführt, damit du Probleme zuerst lokal beheben kannst. Sie prüft Dateitypen, Migrationssicherheit, Manifest-Struktur, Namensgebung und i18n. Die serverseitige Prüfung ist immer maßgeblich: lokal bestehen ist eine Erleichterung, keine Garantie.

Hochladen, prüfen, veröffentlichen

Wenn uploadExtensionBundle einen Pass meldet, wird dein Bundle in einem privaten Review-Bereich gespeichert und dein Projekt wechselt in die Prüfung. Ein Reviewer prüft es und genehmigt es entweder, wodurch es im Marktplatz veröffentlicht wird, oder gibt es mit Feedback zurück, damit du es korrigierst und erneut hochlädst.

Nächste Schritte