118 lines
7.6 KiB
Markdown
118 lines
7.6 KiB
Markdown
# 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.
|