coding-starter/PROMPT.md

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