5.6 KiB
5.6 KiB
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.