Developer-Handbuch

1. Developer-Zugang beantragen und Freischaltung abwarten.
2. Die persönliche Sandbox im Portal bereitstellen oder fortsetzen; nur die dort ausgegebenen URLs verwenden.
3. Modul-Key reservieren, das private Repository klonen und die aktuelle SDK-Vorlage übernehmen.
4. Zweck, Zielgruppe, Datenflüsse, Rollen und Testfälle festhalten.
5. Entscheiden: generisches Marktplatzmodul oder exklusive Kundenentwicklung.
6. Mockup, Modul-API und Tests aufbauen. Beschreibung, Handbuch, Preise und Compliance vor der Einreichung vervollständigen.

Code, Manifest, Migrationen und Workflow-Exporte gemeinsam versionieren. Geheimnisse gehören nicht ins Repository.

1. Im Modul-Entwicklungsbereich „Mockup“ öffnen und „Mockup installieren“ ausführen.
2. Die bereitgestellte Vorschau-URL öffnen; eine pausierte Sandbox vorher fortsetzen.
3. App-Hülle, Navigation, Rollen, Tabellen, Formulare und Dialoge aus der Vorlage übernehmen.
4. Nur die vorgesehenen Modulquellen ändern. Die generierte Mockup-index.html nicht manuell umbauen.
5. Kundenadmin- und Mitarbeiteransichten sowie Desktop und Mobilgeräte prüfen.

Die Marketing-CI dieser Website ist nicht die Modul-App-Vorlage. Für Module gelten SDK-Layout und installierte App-Hülle. Rechte werden serverseitig geprüft, nicht nur durch versteckte Buttons. Alle sichtbaren Texte in allen aktiven Sprachen pflegen.

1. Eigene Anbieter-Credentials und ein ausreichendes Budget für Entwicklung und LLM-Tests bereitstellen.
2. Die HUBrobotix-Zugangsdatenverwaltung des Moduls öffnen. Anbieter auswählen und Geheimnisse ausschließlich in maskierte Eingabefelder eintragen.
3. Modell bzw. Modellklasse auswählen und mit synthetischen Daten testen. Kontingente, Anbieterfehler und Kosten kontrollieren.
4. LLM-Aufrufe über die freigegebene Modul-API/Core-Proxy-Kette führen.

Credentials nicht in n8n eingeben: keine Provider-Secrets in n8n-Credentials, Workflow-JSON, Code-Nodes, Git oder Prompts speichern. Die Plattform vermittelt den Zugang über ihr eigenes Interface. Persönliche Sandbox-Zugänge sind davon getrennt. Im Kundenbetrieb gilt der vereinbarte Kunden-/Plattform-LLM-Modus; Testschlüssel nicht ungeprüft übernehmen.

Die eigene Modul-API kapselt Fachlogik und Datenzugriff. Frontend und Workflows erhalten keine Core-Secrets; nur der vorgesehene serverseitige Client spricht mit der Core-API.

api/
  package.json
  Dockerfile
  src/
    index.js
    inboundAuth.js
    coreApiClient.js
    businessLogic.js

• index.js: Dienststart, Routen, Healthcheck und Eingabevalidierung.
• inboundAuth.js: interne Aufrufer authentifizieren; ersetzt keine Nutzer-/Tenant-Prüfung.
• coreApiClient.js: HTTP-Zugriff mit Modul-Token, keine DB-Verbindung.
• n8n orchestriert Workflows. BullMQ/Redis kann längere Hintergrundjobs abarbeiten.
• Developer betreiben keine eigene n8n-Worker-Flotte. Die Plattform verwaltet deklarierte und freigegebene Runtime-Ressourcen. Vorhandene interne n8n-Queue-Instanzen sind davon getrennt; „überhaupt keine n8n-Worker“ wäre für die Infrastruktur eine unzutreffende Pauschalaussage.
• Jobs benötigen begrenzte Wiederholungen, Timeouts, Fortschrittsstatus und Schutz vor Doppelverarbeitung.

Marktplatzmodule bleiben generisch: keine fest eingebauten Kunden-IDs, Domains, Postfächer, Credentials, Preise oder Kunden-Sonderregeln im gemeinsamen Code. Kundenspezifische Werte gehören in Konfiguration, Daten und Rechte.

Für eine exklusive Kundenentwicklung kannst du bei der Einreichung eine Kundenzuordnung anfragen. Die Plattform prüft und setzt diese Zuordnung; sie gibt dir keinen freien Zugriff auf fremde Kunden. Exklusive Module werden nicht allgemein öffentlich angeboten. Sicherheit, Datenisolation, Compliance, Prüfung und Updatepflicht gelten trotzdem. Leistungsumfang, Rechte, Support und Abrechnung vertraglich klären.

Registrierung ist kostenfrei. Sobald ein Kunde sein erstes Modul aktiviert, fällt zusätzlich zum Modulpreis der kundenweite Grundpreis an. Weitere Module lösen nicht jeweils einen zusätzlichen Grundpreis aus. Grundpreis-Stufe, Modulpaket, Zusatzkontingente und externe LLM-Kosten sind getrennte Positionen.

Developer-Testkosten und eigene Anbieter-Kosten sind davon zu unterscheiden. Verbindliche Grundpreis-Beträge kommen aus der zentralen Preisliste im Portal. Die öffentliche Seite hat derzeit keinen anonymen Zugriff auf diesen geschützten Endpunkt; deshalb werden hier keine festen Beträge kopiert. Vor Aktivierung die aktuellen Konditionen im Portal prüfen. Öffentliche Modulpreise stehen in der dynamischen Preisliste.

• Vollständiges Listing einschließlich erforderlicher Medien.
• Vollständige Preisstaffeln bzw. genehmigter Preisstatus.
• Ausgefüllte AI-Act-Risikoselbstauskunft.
• Code-Firewall ohne blockierende Befunde.
• Konsistentes Manifest, Migrationen, Workflows und Modul-API.
• Installations-, Funktions-, Rechte-, Lösch- und Exporttests.
• Modul-Handbuch, Übersetzungen und vollständige Compliance-Angaben.

Die ersten vier Punkte prüft das aktuelle Einreichungs-Gate explizit. Weitere Anforderungen folgen in der Prüfkette. Der eingereichte Stand kann während der Prüfung gesperrt werden. Nicht außerhalb des Prozesses verändern; Befunde beheben und neu einreichen.

1. Konsistenz: Paket, Manifest und Dateien.
2. Stil: UI- und Code-Regeln.
3. Sicherheit: Code-Firewall-/Security-Berichte.
4. Laufzeit: Installation und Tests.
5. KI-Code-Review: Logik und Fehlerbehandlung.
6. Modellklassen-Treue: Abweichungen werden im aktuellen Code als Warnungen geführt.
7. Dependency-Scan: relevante hohe/kritische Befunde blockieren.

Danach folgt die fachliche/menschliche Prüfung. Der Prüfumfang umfasst Sicherheit, DSGVO, EU AI Act und weitere für Zweck, Branche und Datenverarbeitung anwendbare Anforderungen. Risikoeinstufung, Aufsicht, Transparenz, Lizenzen und Nachweise werden kontextbezogen beurteilt. KI-Codeprüfung ist keine automatische rechtliche Zertifizierung. Ein internes Plattform-Zertifikat ersetzt keine gesetzlich erforderlichen Konformitätsverfahren.

„Freigegeben“ bedeutet nicht automatisch „für Kunden verfügbar“. Die Auditentscheidung startet den vorgesehenen Rollout-/Zertifikatsprozess. Ein Startfehler kann einen erneuten Rollout-Start erfordern. Technische Nachweise, Zielumgebung und Preisbestätigung müssen zusammenpassen.

1. Prüfbericht lesen und Rückfragen erledigen.
2. Vereinbarte Preise bestätigen.
3. Rolloutstatus und erforderliche Freigaben abwarten.
4. Listing oder exklusive Zuordnung kontrollieren.
5. Erst den tatsächlich veröffentlichten Stand bewerben.

Die dokumentierte fehlende Gesamt-LIVE-Freigabe bleibt davon getrennt.

Kunden wählen ein freigegebenes Modul und Paket. Die Plattform rechnet zentral ab; deine Vergütung richtet sich nach vereinbarter Beteiligung und Abrechnungsbasis. Grundpreis und Modulumsatz bleiben getrennt. Vereinbarte Reseller-, Zahlungs- und KI-Kosten können die verteilbare Basis mindern. Kundenpreis ist nicht automatisch Auszahlungsbasis.

Umsätze, Korrekturen, Gutschriften und Auszahlungen im Developer-Portal prüfen. Keine festen Beteiligungswerte in Modul-Code schreiben. Exklusive Entwicklungen folgen ihren vereinbarten Konditionen. Paketumfang, Nutzungseinheit, Limits, Zusatzkontingente und Verhalten bei ausgeschöpftem Kontingent verständlich dokumentieren.

Kundenbewertungen gehören zum jeweiligen Modul. Entwicklerantworten müssen sachlich bleiben und dürfen keine Kundendaten oder Supportdetails offenlegen. Den im Portal verfügbaren Antwortkanal nutzen; die Antwortfunktion wurde in dieser Dokumentationsprüfung nicht als Laufzeitfunktion abgenommen.

Du bist verpflichtet, Fehler und Sicherheitslücken zu beheben, Kompatibilität zu erhalten und erforderliche Updates/Upgrades bereitzustellen. Code-, Datenmodell-, Prompt-, Abhängigkeits- und Verarbeitungsänderungen versionieren, im Changelog erklären und erneut zur Modul-Prüfung einreichen. Veröffentlichte Artefakte nicht still überschreiben.

• Migrationen, Kundendaten und Rücknahmeplan vor Updates prüfen.
• Supportkanal und Reaktionswege im Handbuch nennen.
• Sicherheits-/Datenschutzvorfälle unverzüglich an die Plattform melden.
• Bei Aufgabe des Moduls Übergang, Export und Abkündigung abstimmen.

Aktueller Stand: Die geprüfte Developer-Feedbackseite verwendet Demo-Daten; Antworten werden nicht dauerhaft gespeichert oder versendet. Die zentrale Antwortfunktion ist deshalb noch fertigzustellen. Öffentliche Modulbewertungen und Developer-Antworten sind getrennte Funktionen.

• Keine Core-Änderungen durch Module; zugeordnetes Schema und versioniertes Paket.
• Kein SQL-/DB-Direktzugriff im Laufzeitcode und keine privilegierten geteilten Credentials.
• Nutzer, Tenant, Modulfreischaltung und Objektzugehörigkeit serverseitig prüfen.
• Minimale Scopes, deklarierte externe Hosts und verwalteter LLM-Zugang.
• Eingaben validieren, HTML escapen, keine Secrets oder personenbezogenen Inhalte in Logs.
• SDK-Komponenten und Rollenstruktur statt eigener Core-Menüs.
• Synthetische Testdaten; Export, Löschung, Aufbewahrung und menschliche Korrektur testen.
• Bibliotheks-, Modell- und Inhaltslizenzen sowie Kundenrechte klären.
• Generische Konfiguration; Exklusivität nur über geprüfte Zuordnung.
• Tests, Handbuch und aktive Sprachen gemeinsam pflegen.
• Sandbox-Pausen, Ressourcenlimits und Freigabesperren nicht umgehen.
• Updates/Upgrades erneut prüfen lassen; Support- und Vorfallprozesse einhalten.

Vertrag, aktuelles SDK und modulspezifische Auflagen ergänzen diese Liste.