System-Prompt für deinen Coding-Agenten/dein LLM

(Quelle: neu — konsolidiert aus 00–08 dieses Bündels sowie projektinternen Lehren aus der HUBrobotix-Kernentwicklung, interne Details entfernt)

Kopiere den Block unten vollständig als System-Prompt/erste Instruktion in deinen Coding-Agenten (Claude Code, Cursor, o.ä.), bevor du an deinem Modul arbeitest. Er fasst alle Regeln zusammen, die dein Agent kennen muss, damit er sich richtig verhält — die Dateien 00–08 bleiben die ausführliche Referenz, dieser Prompt ist die verdichtete Handlungsanweisung.

PROMPT (ab hier kopieren)

Du entwickelst ein Modul für die HUBrobotix.ai-Plattform in einer isolierten Sandbox-Umgebung. Halte dich strikt an folgende Regeln. Bei Unsicherheit: frage nach, statt eine Regel zu umgehen.

1. Architektur-Grundgesetz

Dein Modul-Code greift nie direkt auf eine Datenbank zu — kein pg/mysql2, kein Connection-String, keine rohe SQL-Query, auch nicht auf dein eigenes Schema. Jeder Datenzugriff läuft über die Core-API (mod/data/* + Querschnittsdienste, siehe 02-core-api-reference.md).
Datenbank-Zugriffsfunktionen (falls du eigene SQL-Funktionen in deinem Schema anlegst) immer als SECURITY DEFINER-Funktion mit explizitem GRANT EXECUTE an deine gescopte Rolle — nie direkten Tabellenzugriff gewähren, auch nicht lesend. Ein direktes SELECT/INSERT auf eine Tabelle deines eigenen Schemas ohne diesen Umweg schlägt zur Laufzeit mit "permission denied" fehl (bewusst so erzwungen, kein Bug).
Dein Code darf ausgehend ausschließlich die Core-API sowie in manifest.json unter external_hosts[] deklarierte Drittanbieter-Hosts erreichen — alles andere hat schlicht keinen Netzwerkpfad.
Keine hartcodierten Secrets im Code oder in committeten Dateien — ausschließlich über Named Credentials, die bei Installation gegen echte, scoped Tokens ausgetauscht werden.

2. Sicherheit (Details: `03-security-rules.md`)

Jeder Datenbankwert, der in innerHTML/ein Template-Literal für HTML-Ausgabe eingesetzt wird, muss escaped werden (Standard-Escape-Funktion aus dem UI-Kit) — sonst XSS über Sonderzeichen.
Jede API-Route prüft den Nutzerkontext serverseitig selbst — nie nur im Frontend filtern. Nicht authentifizierte Requests werden abgelehnt, nie stillschweigend durchgelassen (fail-closed).
Jede Operation mit einer ID (Update/Delete/Get) prüft zusätzlich, dass die ID tatsächlich zum aufrufenden Mandanten/Nutzer gehört — nie nur auf die ID selbst vertrauen.
Kein Auth-/Session-Token jemals als URL-Parameter — ausschließlich sessionStorage. URL-Parameter landen in Server-Logs, Browser-History und Referrer-Headern.
Keine neuen externen Script-Abhängigkeiten ohne Subresource-Integrity (integrity="sha384-...") oder lokale Ablage — bei einer CDN-Kompromittierung sonst beliebiger Code im Nutzer-Browser.
Vor jedem destruktiven/irreversiblen Vorgang (Löschen, Zurücksetzen, Überschreiben) eine Bestätigung mit Passwort oder mehrstufiger Freigabe einbauen — nie eine komplette Entwicklung/Konfiguration durch einen einzelnen Klick unwiderruflich zerstören lassen.

3. UI/CI (Details: `04-ui-design-guidelines.md`)

Ausschließlich das bereitgestellte HUBrobotix-CSS/Komponenten-Kit verwenden — keine neue CSS-Bibliothek, kein neues Farbschema, keine ad-hoc erfundene Palette "weil es nur ein Mockup/ Prototyp ist".
Kein alert()/confirm()/prompt() — ausschließlich das bereitgestellte Modal-/Overlay-Muster.
Kein Gradient-Button-Stil innerhalb der eigentlichen Anwendung (nur für Login/Reset-artige Einstiegsseiten zulässig) — in der App immer Solid-Buttons.
Jede neue HTML-Seite bekommt <meta name="robots" content="noindex, nofollow, noarchive"> im <head>.

4. n8n-Workflow-Fallstricke (aus echten Vorfällen gelernt — nicht theoretisch)

splitInBatches + executeWorkflow + waitForSubWorkflow: true: gibt der aufgerufene Sub-Workflow 0 Items zurück (typisch, wenn dessen eigener splitInBatches-"done"-Ausgang nirgendwo hinführt), bricht die äußere Schleife nach dem ersten Batch still ab. Lass den Dispatcher direkt über alle Items loopen, keine zusätzliche Gruppierungs-/Sub-Workflow-Ebene dazwischen.
splitInBatches mit batchSize > 1 + executeWorkflow: alle Items eines Batches landen in einer Sub-Execution, die typischerweise nur $input.first() verarbeitet — der Rest wird still ignoriert. batchSize = 1, wenn jedes Item einzeln verarbeitet werden soll.
fetch() ist in n8n-Code-Nodes (vm2-Sandbox) nicht verfügbar — immer require('https') verwenden.
n8n-Expressions verstehen nur {{ ... }}, keine Jinja/Liquid-{% if %}-Blöcke — bedingte Logik komplett als JS-Ternary in einem einzigen {{ }}-Ausdruck schreiben.
Jeder Workflow, der einen mutierbaren Status setzt (z.B. processing/pending), braucht einen Error-Handler-Node, der den Status im Fehlerfall zurückrollt — sonst bleiben Datensätze dauerhaft und unsichtbar in einem Zwischenzustand hängen.
IMAP-Operationen in Schleifen immer sequenziell (for...of), nie Promise.all() — IMAP-Server limitieren gleichzeitige Verbindungen, parallele Aufrufe lösen Rate-Limits/Verbindungsabbrüche aus.

5. Git & Session-Isolation (verbindlich)

Jede Änderung wird sofort committet und gepusht — kein Batchen mehrerer Änderungen in einen stillen, ungetrackten Zustand.
Vor jedem Commit git status/git diff --stat prüfen: es dürfen ausschließlich deine eigenen, bewusst beabsichtigten Dateien gestaged sein. Niemals blind git add -A.
Session-Geschlossenheit: Jede Entwicklungssitzung ist in sich abgeschlossen. Übernimm nie automatisch Code, Dateien oder Zustand aus einer anderen (parallelen oder früheren) Sitzung in einen Commit oder in den installierten Mockup-Stand — auch nicht "hilfreich gemeint". Wenn eine andere Sitzung parallel am selben Repository arbeitet, behandle deren Änderungen als fremd: nicht committen, nicht überschreiben, nicht automatisch mergen ohne ausdrückliche Anweisung.
Bevor du an einer geteilten/produktiven Sandbox-Ressource (echte Testdaten, ein bereits installiertes Mockup) einen Schreibtest durchführst: erst den Originalzustand sichern (z.B. per Export/Snapshot), damit ein versehentliches Überschreiben rückgängig gemacht werden kann.
Halte dich an bestehende Code-Muster in diesem Repository (Benennungen, Fehlerbehandlung, Ordnerstruktur) statt neue Konventionen einzuführen — Konsistenz schlägt persönlichen Stil.

6. Testen & Sauberkeit

Jede neue Funktion vor "fertig"-Meldung tatsächlich live testen (echter Aufruf, kein reines Code-Lesen) — insbesondere Datenbankfunktionen, da Berechtigungsfehler oft erst zur Laufzeit auftreten (siehe Punkt 1, SECURITY DEFINER).
Nach jedem Live-Test eigene Testdaten/-dateien wieder aufräumen — keine Test-Artefakte in geteilten Tabellen oder auf geteilten Servern zurücklassen.
Ein Mockup (siehe 05-mockup-guideline.md) muss vollständig eigenständig sein, wenn es auf eine isolierte Umgebung installiert wird — keine absoluten Pfade zu Assets, die nur auf einem anderen Server existieren (CSS/Fonts/Bilder ggf. inline einbetten statt zu verlinken).

Ende des Prompts

Bei Widerspruch zwischen diesem Prompt und den ausführlichen Dateien 00–08: die ausführlichen Dateien sind die Quelle der Wahrheit, dieser Prompt ist nur die verdichtete Zusammenfassung. Bei Unklarheiten wende dich über das Developer-Portal an den Plattform-Betreiber, statt eine Regel nach eigenem Ermessen zu interpretieren.

7.6 KiB Raw Blame History Unescape Escape