chore: CLAUDE.md, PROMPT.md und Planungs-Docs hinzufügen
This commit is contained in:
219
PROMPT.md
Normal file
219
PROMPT.md
Normal file
@@ -0,0 +1,219 @@
|
||||
|
||||
## 1. Neue Kampagnen-Funktion
|
||||
|
||||
```
|
||||
Aufgabe: [Login] für Kampagnen implementieren
|
||||
|
||||
Kontext:
|
||||
- Tenant: [TENANT-SCHEMA oder "allgemein"]
|
||||
- Betroffene Queues: [z.B. email:send / keine]
|
||||
- ClickHouse betroffen: [Ja/Nein]
|
||||
|
||||
Schritt 1: Zeig mir welche Dateien du anlegen oder ändern würdest
|
||||
— Liste nur, kein Code
|
||||
|
||||
Schritt 2: Schreib die Typen und Interfaces
|
||||
|
||||
Schritt 3: Schreib die Business-Logik
|
||||
— mit Suppression-Check als erstem Schritt
|
||||
— mit Tenant-Isolation
|
||||
|
||||
Schritt 4: Schreib Unit-Tests — SMTP gegen Mailhog mocken
|
||||
|
||||
Schritt 5: Zeig mir Queue-Job-Änderungen falls nötig
|
||||
|
||||
Warte nach jedem Schritt auf Freigabe.
|
||||
Kein Versand gegen echte Empfänger. Kein Deploy.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. E-Mail Versand-Job (BullMQ)
|
||||
|
||||
```
|
||||
Aufgabe: BullMQ-Job für Kampagnen-Versand] implementieren
|
||||
|
||||
Schritt 1: Zeig mir die Job-Datenstruktur (Payload-Interface)
|
||||
und den Ablauf als Pseudocode — warte auf Freigabe
|
||||
|
||||
Schritt 2: Implementiere den Job in src/queues/
|
||||
— maxAttempts: 3, exponentielles Backoff
|
||||
— Dead-Letter-Queue bei finalem Fehler
|
||||
— Suppression-Check VOR SMTP-Call
|
||||
|
||||
Schritt 3: Schreib Unit-Tests mit gemocktem Redis und gemocktem SMTP
|
||||
|
||||
Schritt 4: Zeig mir wie der Job in die Queue eingereiht wird
|
||||
|
||||
Kein echter Redis-Eingriff. Kein SMTP gegen Produktion.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Subscriber-Management
|
||||
|
||||
```
|
||||
Aufgabe: [ CSV-Import / Segmentierung / Unsubscribe-Flow] implementieren
|
||||
|
||||
Schritt 1: Erkläre welche Tabellen betroffen sind (PostgreSQL-Schema)
|
||||
— ist Double-Opt-In betroffen? Ja/Nein
|
||||
|
||||
Schritt 2: Zeig mir die Validierungslogik
|
||||
— Pflichtfelder, E-Mail-Format, Duplikat-Check, Suppression-Check
|
||||
|
||||
Schritt 3: Schreib den Code — mit Consent-Timestamp-Speicherung (IP + User-Agent)
|
||||
|
||||
Schritt 4: Schreib die Migration falls Schema-Änderung nötig
|
||||
— nicht ausführen
|
||||
|
||||
Schritt 5: Schreib Unit-Tests
|
||||
|
||||
Keine E-Mail-Adressen im Klartext in ClickHouse speichern — nur SHA256-Hash.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. ClickHouse Analytics
|
||||
|
||||
```
|
||||
Aufgabe: [Open-Rate pro Kampagne] implementieren
|
||||
|
||||
Schritt 1: Zeig mir die ClickHouse-Tabellenstruktur die du nutzen würdest
|
||||
— warte auf Freigabe
|
||||
|
||||
Schritt 2: Schreib die Query
|
||||
— immer mit tenant_id als Filter
|
||||
— keine personenbezogenen Daten selektieren (nur Hashes)
|
||||
|
||||
Schritt 3: Schreib den Query-Layer in src/analytics/
|
||||
|
||||
Schritt 4: Schreib einen Test gegen ClickHouse-Test-Container
|
||||
|
||||
Kein DELETE/UPDATE ohne explizite Freigabe.
|
||||
ClickHouse-Tabellen sind append-only.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Datenbankänderung / Migration
|
||||
|
||||
```
|
||||
Aufgabe: [BESCHREIBUNG DER SCHEMAÄNDERUNG]
|
||||
|
||||
Welche DB: [PostgreSQL / ClickHouse / beide]
|
||||
|
||||
Schritt 1: Erkläre welche Tabellen betroffen sind
|
||||
— additiv oder breaking?
|
||||
|
||||
Schritt 2: Zeig mir das geänderte Schema — warte auf Freigabe
|
||||
|
||||
Schritt 3: Generiere die Migration-SQL
|
||||
— PostgreSQL → migrations/pg/YYYY-MM-DD_beschreibung.sql
|
||||
— ClickHouse → migrations/ch/YYYY-MM-DD_beschreibung.sql
|
||||
— NICHT ausführen
|
||||
|
||||
Schritt 4: Zeig mir welcher Code angepasst werden muss
|
||||
|
||||
Führe zu keinem Zeitpunkt Migrations aus.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Bounce / Unsubscribe Handling
|
||||
|
||||
```
|
||||
Aufgabe: [Bounce-Handler / Unsubscribe-Flow] implementieren oder erweitern
|
||||
|
||||
Schritt 1: Zeig mir den aktuellen Flow als Diagramm (Text reicht)
|
||||
— warte auf Freigabe
|
||||
|
||||
Schritt 2: Implementiere die Änderung
|
||||
— Suppression-Liste wird SOFORT geschrieben
|
||||
— kein async ohne Fehlerbehandlung
|
||||
|
||||
Schritt 3: Stelle sicher dass Bounce-Rate-Monitoring greift
|
||||
— bei >5% Kampagne pausieren
|
||||
|
||||
Schritt 4: One-Click-Unsubscribe Header prüfen (RFC 8058)
|
||||
|
||||
Schritt 5: Schreib Tests
|
||||
|
||||
Kein echter SMTP-Call. Kein Löschen aus Suppression-Liste.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. MTA / SMTP Integration
|
||||
|
||||
```
|
||||
Aufgabe: [SMTP-ÄNDERUNG z.B. neuen Versand-Domain einbinden]
|
||||
|
||||
Schritt 1: Erkläre was sich an der SMTP-Konfiguration ändern muss
|
||||
— zeige mir NUR den Code-Teil, nicht die Postfix-Config
|
||||
|
||||
Schritt 2: Schreib den SMTP-Client-Code
|
||||
— Rate-Limiting via BullMQ, kein direkter SMTP-Call
|
||||
|
||||
Schritt 3: Schreib einen Test gegen Mailhog
|
||||
|
||||
Postfix/iRedMail-Konfiguration ist Infra-Aufgabe — nicht im Code lösen.
|
||||
Kein SMTP gegen echte Empfänger.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Bug fixen
|
||||
|
||||
```
|
||||
Bug: [FEHLERBESCHREIBUNG]
|
||||
Fehler-Output: [Stacktrace oder Fehlermeldung]
|
||||
Kontext: [Queue-Job / API / Analytics / Frontend]
|
||||
|
||||
Schritt 1: Finde die Ursache — erkläre sie bevor du etwas änderst
|
||||
— warte auf Bestätigung
|
||||
|
||||
Schritt 2: Schreib einen Test der den Bug reproduziert (failing)
|
||||
|
||||
Schritt 3: Fix — Test muss grün werden
|
||||
|
||||
Schritt 4: Prüfe Seiteneffekte auf Queue-Jobs und Suppression-Liste
|
||||
|
||||
Kein Eingriff in laufende Queue-Jobs ohne Freigabe.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. DSGVO / Compliance Check
|
||||
|
||||
```
|
||||
Aufgabe: DSGVO-Review für [FEATURE oder DATEI]
|
||||
|
||||
Prüfe auf:
|
||||
- Werden E-Mail-Adressen irgendwo im Klartext geloggt?
|
||||
- Ist Double-Opt-In mit Timestamp, IP und User-Agent gespeichert?
|
||||
- Kann ein Tenant Subscriber-Daten eines anderen Tenants sehen?
|
||||
- Werden Daten außerhalb der EU gespeichert oder übertragen?
|
||||
- Ist die Lösch-Logik vollständig (PostgreSQL + ClickHouse)?
|
||||
|
||||
Ausgabe: Findings mit Schweregrad (kritisch / mittel / niedrig)
|
||||
Keine Änderungen ohne Freigabe.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. Deliverability-Check
|
||||
|
||||
```
|
||||
Aufgabe: Deliverability-Review für [VERSAND-FEATURE oder KAMPAGNEN-CODE]
|
||||
|
||||
Prüfe auf:
|
||||
- Suppression-Check vorhanden und als erster Schritt?
|
||||
- List-Unsubscribe-Header gesetzt (RFC 8058)?
|
||||
- Bounce-Rate-Monitoring aktiv?
|
||||
- Versand-Rate limitiert (kein Burst)?
|
||||
- DKIM/SPF-Kontext korrekt gesetzt?
|
||||
|
||||
Ausgabe: Findings mit konkreten Code-Stellen
|
||||
Keine Änderungen ohne Freigabe.
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user