# 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 `` im ``. ### 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.