From 44600dbcf547b7919cb7a41f7a70a4328d3b6307 Mon Sep 17 00:00:00 2001 From: patrick Date: Sat, 17 Oct 2026 00:33:48 +0200 Subject: [PATCH] mail-kanban: Board nach Gitea main nachliefern mail-kanban/ existierte bislang nicht auf origin/main (gleiches Strukturproblem wie workflow-kanban, siehe #337) -- Board und Tickets lagen nur in der lokalen Baseline. Nur Board-/Ticketdaten, kein Code. Co-Authored-By: Claude Sonnet 5 --- mail-kanban/DEVLOG.md | 90 ++ mail-kanban/README.md | 119 ++ mail-kanban/board.csv | 356 +++++ mail-kanban/board.json | 2681 +++++++++++++++++++++++++++++++++ mail-kanban/kanban.html | 50 + mail-kanban/tickets/ARC-01.md | 76 + mail-kanban/tickets/ARC-02.md | 67 + mail-kanban/tickets/ARC-03.md | 63 + mail-kanban/tickets/ARC-04.md | 59 + mail-kanban/tickets/ARC-05.md | 62 + mail-kanban/tickets/ARC-06.md | 61 + mail-kanban/tickets/ARC-07.md | 60 + mail-kanban/tickets/ARC-08.md | 60 + mail-kanban/tickets/ARC-09.md | 63 + mail-kanban/tickets/ARC-10.md | 69 + mail-kanban/tickets/IMP-01.md | 69 + mail-kanban/tickets/IMP-02.md | 62 + mail-kanban/tickets/IMP-03.md | 62 + mail-kanban/tickets/IMP-04.md | 64 + mail-kanban/tickets/IMP-05.md | 61 + mail-kanban/tickets/IMP-06.md | 61 + mail-kanban/tickets/IMP-07.md | 61 + mail-kanban/tickets/IMP-08.md | 63 + mail-kanban/tickets/IMP-09.md | 64 + mail-kanban/tickets/IMP-10.md | 58 + mail-kanban/tickets/ING-01.md | 68 + mail-kanban/tickets/ING-02.md | 65 + mail-kanban/tickets/ING-03.md | 69 + mail-kanban/tickets/ING-04.md | 66 + mail-kanban/tickets/ING-05.md | 62 + mail-kanban/tickets/ING-06.md | 61 + mail-kanban/tickets/ING-07.md | 61 + mail-kanban/tickets/ING-08.md | 61 + mail-kanban/tickets/ING-09.md | 61 + mail-kanban/tickets/ING-10.md | 64 + mail-kanban/tickets/ING-11.md | 58 + mail-kanban/tickets/INT-01.md | 64 + mail-kanban/tickets/INT-05.md | 61 + mail-kanban/tickets/INT-06.md | 59 + mail-kanban/tickets/INT-07.md | 59 + mail-kanban/tickets/INT-08.md | 63 + mail-kanban/tickets/INT-09.md | 62 + mail-kanban/tickets/INT-10.md | 62 + mail-kanban/tickets/INT-11.md | 60 + mail-kanban/tickets/INT-12.md | 59 + mail-kanban/tickets/INT-18.md | 59 + mail-kanban/tickets/QA-01.md | 64 + mail-kanban/tickets/QA-02.md | 67 + mail-kanban/tickets/QA-03.md | 65 + mail-kanban/tickets/QA-04.md | 62 + mail-kanban/tickets/QA-05.md | 66 + mail-kanban/tickets/QA-06.md | 65 + mail-kanban/tickets/QA-07.md | 60 + mail-kanban/tickets/QA-08.md | 62 + mail-kanban/tickets/QA-09.md | 62 + mail-kanban/tickets/SRC-01.md | 65 + mail-kanban/tickets/SRC-02.md | 62 + mail-kanban/tickets/SRC-03.md | 62 + mail-kanban/tickets/SRC-04.md | 60 + mail-kanban/tickets/SRC-05.md | 59 + mail-kanban/tickets/SRC-06.md | 60 + mail-kanban/tickets/SRC-07.md | 62 + mail-kanban/tickets/SRC-08.md | 59 + mail-kanban/tickets/SRC-09.md | 59 + mail-kanban/tickets/SRC-10.md | 59 + mail-kanban/tickets/SRC-11.md | 53 + mail-kanban/tickets/SRC-12.md | 59 + mail-kanban/tickets/UX-01.md | 66 + mail-kanban/tickets/UX-02.md | 62 + mail-kanban/tickets/UX-03.md | 64 + mail-kanban/tickets/UX-04.md | 61 + mail-kanban/tickets/UX-05.md | 61 + mail-kanban/tickets/UX-06.md | 61 + mail-kanban/tickets/UX-07.md | 65 + mail-kanban/tickets/UX-08.md | 61 + mail-kanban/tickets/UX-09.md | 65 + 76 files changed, 7723 insertions(+) create mode 100644 mail-kanban/DEVLOG.md create mode 100644 mail-kanban/README.md create mode 100644 mail-kanban/board.csv create mode 100644 mail-kanban/board.json create mode 100644 mail-kanban/kanban.html create mode 100644 mail-kanban/tickets/ARC-01.md create mode 100644 mail-kanban/tickets/ARC-02.md create mode 100644 mail-kanban/tickets/ARC-03.md create mode 100644 mail-kanban/tickets/ARC-04.md create mode 100644 mail-kanban/tickets/ARC-05.md create mode 100644 mail-kanban/tickets/ARC-06.md create mode 100644 mail-kanban/tickets/ARC-07.md create mode 100644 mail-kanban/tickets/ARC-08.md create mode 100644 mail-kanban/tickets/ARC-09.md create mode 100644 mail-kanban/tickets/ARC-10.md create mode 100644 mail-kanban/tickets/IMP-01.md create mode 100644 mail-kanban/tickets/IMP-02.md create mode 100644 mail-kanban/tickets/IMP-03.md create mode 100644 mail-kanban/tickets/IMP-04.md create mode 100644 mail-kanban/tickets/IMP-05.md create mode 100644 mail-kanban/tickets/IMP-06.md create mode 100644 mail-kanban/tickets/IMP-07.md create mode 100644 mail-kanban/tickets/IMP-08.md create mode 100644 mail-kanban/tickets/IMP-09.md create mode 100644 mail-kanban/tickets/IMP-10.md create mode 100644 mail-kanban/tickets/ING-01.md create mode 100644 mail-kanban/tickets/ING-02.md create mode 100644 mail-kanban/tickets/ING-03.md create mode 100644 mail-kanban/tickets/ING-04.md create mode 100644 mail-kanban/tickets/ING-05.md create mode 100644 mail-kanban/tickets/ING-06.md create mode 100644 mail-kanban/tickets/ING-07.md create mode 100644 mail-kanban/tickets/ING-08.md create mode 100644 mail-kanban/tickets/ING-09.md create mode 100644 mail-kanban/tickets/ING-10.md create mode 100644 mail-kanban/tickets/ING-11.md create mode 100644 mail-kanban/tickets/INT-01.md create mode 100644 mail-kanban/tickets/INT-05.md create mode 100644 mail-kanban/tickets/INT-06.md create mode 100644 mail-kanban/tickets/INT-07.md create mode 100644 mail-kanban/tickets/INT-08.md create mode 100644 mail-kanban/tickets/INT-09.md create mode 100644 mail-kanban/tickets/INT-10.md create mode 100644 mail-kanban/tickets/INT-11.md create mode 100644 mail-kanban/tickets/INT-12.md create mode 100644 mail-kanban/tickets/INT-18.md create mode 100644 mail-kanban/tickets/QA-01.md create mode 100644 mail-kanban/tickets/QA-02.md create mode 100644 mail-kanban/tickets/QA-03.md create mode 100644 mail-kanban/tickets/QA-04.md create mode 100644 mail-kanban/tickets/QA-05.md create mode 100644 mail-kanban/tickets/QA-06.md create mode 100644 mail-kanban/tickets/QA-07.md create mode 100644 mail-kanban/tickets/QA-08.md create mode 100644 mail-kanban/tickets/QA-09.md create mode 100644 mail-kanban/tickets/SRC-01.md create mode 100644 mail-kanban/tickets/SRC-02.md create mode 100644 mail-kanban/tickets/SRC-03.md create mode 100644 mail-kanban/tickets/SRC-04.md create mode 100644 mail-kanban/tickets/SRC-05.md create mode 100644 mail-kanban/tickets/SRC-06.md create mode 100644 mail-kanban/tickets/SRC-07.md create mode 100644 mail-kanban/tickets/SRC-08.md create mode 100644 mail-kanban/tickets/SRC-09.md create mode 100644 mail-kanban/tickets/SRC-10.md create mode 100644 mail-kanban/tickets/SRC-11.md create mode 100644 mail-kanban/tickets/SRC-12.md create mode 100644 mail-kanban/tickets/UX-01.md create mode 100644 mail-kanban/tickets/UX-02.md create mode 100644 mail-kanban/tickets/UX-03.md create mode 100644 mail-kanban/tickets/UX-04.md create mode 100644 mail-kanban/tickets/UX-05.md create mode 100644 mail-kanban/tickets/UX-06.md create mode 100644 mail-kanban/tickets/UX-07.md create mode 100644 mail-kanban/tickets/UX-08.md create mode 100644 mail-kanban/tickets/UX-09.md diff --git a/mail-kanban/DEVLOG.md b/mail-kanban/DEVLOG.md new file mode 100644 index 00000000..79b5b494 --- /dev/null +++ b/mail-kanban/DEVLOG.md @@ -0,0 +1,90 @@ +# mail-kanban – Dev Log + +## 2026-08-26 12:23 – 12:24 (1m) +**Beschreibung:** Claude Code Session +**Projekt:** core-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:24 – 12:24 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:25 – 12:26 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:26 – 12:26 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:28 – 12:29 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:30 – 12:30 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:33 – 12:33 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:35 – 12:35 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** mail-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- diff --git a/mail-kanban/README.md b/mail-kanban/README.md new file mode 100644 index 00000000..780f4f28 --- /dev/null +++ b/mail-kanban/README.md @@ -0,0 +1,119 @@ +# Mail-Kanban – lokal abarbeiten + +70 Arbeitskacheln · 7 Epics · 171 Personentage · 8 Wellen (inkl. Welle 8: Threat-Model-Nachtrag 2026-09-12 — ING-11, INT-11, INT-12, SRC-12). +Stand: 2026-08-26 + +Hinweis: Aufbewahrung, WORM, Compliance-Berichte und Backup sind ausgelagert in NEXARCH Archive (siehe ../archive-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr. + +Hinweis: REST-API-Grundgerüst, Rate-Limiting, OpenAPI-Tooling und Webhook-Zustellung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/, API-01/03/04/07) — dieses Board definiert nur noch die modul-eigenen Endpunkte. + +Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board. + +NEXARCH Mail ist die Ablösung von archivmail. Code-Wiederverwendung aus archivmail +ist hier – anders als beim DMS-Board – ausdrücklich erlaubt und gewünscht, weil +IMAP-/SMTP-/POP3-Protokolllogik komplex und fehleranfällig ist. Übernommener Code +muss dabei an den in `known-issues-archivmail.md` dokumentierten Stellen korrigiert +werden, nicht 1:1 kopiert – siehe die Hinweise "Konzept aus archivmail als Vorlage +nutzbar" bzw. "kein Vorbild in archivmail" in jeder Kachel sowie +`repos-analyse-mail-reuse.md` für die vollständige Bewertung je Fachbereich. + +IAM/Tenancy/Auth/Lizenzierung/Feature-Flags/Audit-Grundmodell werden in diesem +Board **nicht** behandelt – das liefert bereits `core-kanban/` zentral. Kacheln +dieses Boards referenzieren Core-Board-Kacheln nur als externe Voraussetzung in +der Ausgangslage, nicht als Abhängigkeit innerhalb des eigenen Boards. + +## Weg 1 – Sofort loslegen (empfohlen) + +`kanban.html` per Doppelklick im Browser öffnen. Kein Server, kein Internet, keine Installation. + +- Kacheln per Drag & Drop zwischen Backlog → Bereit → In Arbeit → Prüfung → Fertig ziehen +- Der Stand wird im Browser gespeichert (localStorage) und bleibt nach dem Schließen erhalten +- Filter nach Epic, Rolle, Welle, Volltext sowie „Nur startbare“ (alle Vorgänger auf Fertig) +- Klick auf eine Kachel öffnet Details inkl. vollem Bau-Prompt und „Prompt kopieren“ +- „Stand sichern“ exportiert den aktuellen Status als CSV + +Hinweis: Der Stand hängt an Browser und Profil. Für Teamarbeit Weg 2 oder 3 nutzen. + +## Weg 2 – Import in ein vorhandenes Werkzeug + +`board.csv` (UTF-8 mit BOM, Komma-getrennt) importieren: + +| Werkzeug | Weg | +| --- | --- | +| Trello | Board → Menü → Mehr → CSV importieren (Power-Up) | +| Jira | Einstellungen → System → Externes Importieren → CSV, Spalte „Status“ auf den Workflow mappen | +| GitHub Projects | Projekt → … → Import, oder per `gh` CLI aus `board.json` | +| Notion | Datenbank → … → Merge with CSV | +| Linear / Asana / ClickUp | jeweils CSV-Import, Spalten wie oben zuordnen | + +Spalten: Code, Titel, Epic, Rolle, Komplexitaet, Aufwand_PT, Welle, Status, Technik, +Beschreibung, Haengt_ab_von, Schaltet_frei, Akzeptanzkriterien, Pruefungen. + +## Weg 3 – Dateibasiert in der Entwicklungsumgebung + +Der Ordner `tickets/` enthält für jede Kachel eine Markdown-Datei (`ING-01.md` …). +Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage, +Akzeptanzkriterien, Prüfungen und Abschlussregeln. + +- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren. +- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen. +- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch. + +## Weg 4 – Eigenes Board im Netzwerk (Team) + +Selbst gehostet, jeweils mit CSV-Import: + +```bash +# Focalboard +docker run -d -p 8000:8000 --name focalboard mattermost/focalboard + +# Planka +docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest + +# Vikunja +docker run -d -p 3456:3456 --name vikunja vikunja/vikunja +``` + +Danach `board.csv` importieren. + +## Reihenfolge der Arbeit + +Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar, +sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen. + +- **Welle 1** (5 Kacheln): ING-01, ING-03, ING-04, QA-01, QA-05 +- **Welle 2** (4 Kacheln): ARC-01, ING-02, ING-05, ING-09 +- **Welle 3** (13 Kacheln): ARC-02, ARC-03, ARC-04, ARC-05, ARC-06, ARC-07, IMP-01, ING-06, ING-07, ING-08, ING-10, QA-07, UX-03 +- **Welle 4** (11 Kacheln): ARC-08, IMP-02, IMP-03, IMP-04, IMP-05, IMP-07, INT-05, QA-04, SRC-01, SRC-07, UX-01 +- **Welle 5** (12 Kacheln): ARC-09, IMP-06, IMP-08, IMP-09, SRC-02, SRC-03, SRC-09, SRC-10, UX-02, UX-04, UX-05, UX-06 +- **Welle 6** (9 Kacheln): INT-01, QA-02, QA-03, SRC-04, SRC-05, SRC-08, UX-07, UX-08, UX-09 +- **Welle 7** (6 Kacheln): INT-06, INT-07, QA-06, QA-08, QA-09, SRC-06 + +Kritischer Pfad (21 PT): ING-01 → ING-05 → IMP-01 → UX-01 → UX-02 → UX-07 → QA-08 + +## Produkt-DNA + +### Übernehmen +- **Dovecot**: Referenzarchitektur für robuste IMAP-Server – klare Trennung von Protokoll-Zustandsmaschine, Storage-Backend und Auth-Schicht. +- **Dovecot**: Defensive Behandlung nicht-konformer Clients/Server statt optimistischem Parsing, das bei Abweichungen still falsch weiterläuft. +- **Rspamd**: Mailserver-Härtung und Rate-Limiting als eigenständige, vorgeschaltete und konfigurierbare Schicht. +- **Mailpit/MailHog**: Mailflows sind von Anfang an automatisiert testbar, ohne echten Mailserver oder externe Postfächer. +- **ecoDMS**: Revisionssichere Ablage – einmal archivierte Inhalte sind unveränderlich und lückenlos nachvollziehbar. +- **Alfresco**: Aufbewahrungsfristen und Audit-Trail als Kernfunktion der Content-Verwaltung, nicht als Nachrüstung. + +### Vermeiden +- **archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung im Mailer.**: Ausgabe strikt über `net/mail`-Writer oder harte CRLF-/Steuerzeichen-Validierung. +- **archivmail – ungebremstes `io.ReadAll` beim Anhang-Parsing ohne Größenlimit.**: `io.LimitReader` mit Max-Size und harter Ablehnung bei Überschreitung. +- **archivmail – nur 2 von 18 Modulen mit Tests trotz protokollkritischer Logik.**: Pflichttests für Tenant-Scoping und Protokoll-State-Machines vor jedem Merge. +- **archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.**: Spalten- und Tabellennamen ausschließlich aus statischen Konstanten, zentraler Query-Builder mit Feld-Whitelist. +- **archivmail – Tenant-Filter als Post-Filter statt in der Query bei eDiscovery.**: Tenant-Scoping ausschließlich in Query-/Repository-Schicht. +- **archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung, iframe-PDF-Vorschau.**: serverseitige Magic-Bytes-Erkennung, Canvas-Rendering statt iframe. +- **archivmail – Restore-Datenintegritätsbug bei nicht-leerem Zielverzeichnis.**: atomarer Swap über leeres Temp-Verzeichnis. +- **archivmail – kein zentrales Issue-Tracking, nur `BUG-N`-Kommentare im Code.**: Bugs durchsuchbar und projektweit sichtbar tracken. + +## Arbeitsregeln + +Je Kachel ein eigener Branch, schrittweise committen, Branch pushen, dann anhalten. +Kein Merge und kein Deploy ohne ausdrückliche Freigabe. + +Code-Struktur: Hauptdateien/Entry-Points klein halten, Fachlogik in eigene Module/Dateien auslagern. Vor dem Anlegen einer neuen Funktions-/Modul-Datei prüfen, ob dieselbe Funktionalität nicht schon in einem anderen Modul (auch modulübergreifend, z. B. Core) existiert — keine doppelten Funktionsdateien, ein Modul/Board referenziert das andere extern statt Code zu kopieren (gleiches Prinzip wie bei den Konsolidierungen IAM/Archive/Workflow/AI/API/UI-Shell, siehe nexarch-state.json). diff --git a/mail-kanban/board.csv b/mail-kanban/board.csv new file mode 100644 index 00000000..2aefd8a3 --- /dev/null +++ b/mail-kanban/board.csv @@ -0,0 +1,356 @@ +Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen +ARC-01,Objekt-Speicher-Anbindung für Mails/Anhänge,🗄️ Archivierung & Speicherung,Backend,Mittel,3,2,Fertig,"Go, S3-kompatibles Objektspeicher-API","Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.",ING-04,ARC-02 ARC-03 ARC-04 ARC-05 ARC-06 ARC-07 INT-01 SRC-01 SRC-07 UX-03 ARC-09 ARC-10 INT-08 INT-09 INT-10 INT-12,"Mails und Anhänge werden nach fester, dokumentierter Pfadkonvention abgelegt +Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert +Lesezugriff ist unabhängig vom ursprünglichen Importpfad möglich +Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet","Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt +Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt +Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz +Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe" +ARC-02,Verschlüsselung at rest,🗄️ Archivierung & Speicherung,Backend,Mittel,3,3,Fertig,"Go, AES-256-GCM","Verschlüsselung archivierter Mails/Anhänge at rest einführen. Der Master-Key (KEK) wird über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst.",ARC-01,ARC-08,"Alle archivierten Inhalte sind at rest verschlüsselt abgelegt +Der Master-Key (KEK) wird über Core API-10 bezogen, Schlüsselmaterial ist getrennt vom Datenspeicher verwaltet und nicht im Code +Entschlüsselung ist nur mit gültigem, mandantenbezogenem Schlüssel möglich","Test: Zugriff auf Rohspeicher ohne Schlüssel liefert keine lesbaren Inhalte +Test: falscher Mandantenschlüssel verweigert Entschlüsselung +Performance-Test bestätigt akzeptablen Overhead durch Verschlüsselung" +ARC-03,Dublettenerkennung E-Mail,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, Hashing (SHA-256)","Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.",ARC-01,SRC-01 SRC-02 SRC-07,"Identische Nachrichten werden über Inhalts-Hash zuverlässig als Duplikat erkannt +Duplikate werden referenziert statt redundant gespeichert oder klar markiert +Erkennung funktioniert mandantenübergreifend korrekt getrennt","Test: dieselbe Nachricht aus zwei Quellen wird als Duplikat erkannt +Test: zwei Mandanten mit identischem Mailinhalt werden nicht fälschlich verknüpft +Test mit knapp unterschiedlichen Nachrichten bestätigt korrekte Nicht-Erkennung" +ARC-04,Aufbewahrungsstruktur (Mandant/Postfach/Jahr),🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, Objektspeicher-Pfadkonvention","Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.",ARC-01,QA-05,"Ablagestruktur folgt durchgängig dem Schema Mandant/Postfach/Jahr +Struktur ist Grundlage für spätere Retention-Regeln ohne Migration +Abweichende oder fehlende Metadaten führen zu definiertem Fallback-Pfad, nicht zu Ablagefehler","Test: Import über mehrere Jahre erzeugt korrekt getrennte Jahresordner +Test: fehlendes Postfach-Attribut nutzt dokumentierten Fallback +Stichprobenprüfung der Struktur durch zweite Person" +ARC-05,Papierkorb & Soft-Delete für Mails,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, Postgres (Soft-Delete-Flag)","Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.",ARC-01 RET-03,QA-05,"Gelöschte Mails bleiben innerhalb der Frist wiederherstellbar +Endgültige Löschung nach Fristablauf ist nachvollziehbar protokolliert +Soft-Delete respektiert bestehende Aufbewahrungssperren (Litigation Hold)","Test: Wiederherstellung innerhalb der Frist liefert unveränderten Inhalt +Test: Mail mit aktiver Aufbewahrungssperre kann nicht endgültig gelöscht werden +Test: Fristablauf löst automatische endgültige Löschung aus" +ARC-06,Mandantentrennung im Objekt-Storage,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, ein Bucket/Pfad-Root pro Mandant","Physische Mandantentrennung im Objekt-Storage durchsetzen — jeder Mandant hat einen eigenen Bucket/Pfad-Root (angelegt im selben Provisioning-Schritt wie die Tenant-Datenbank, siehe Core TEN-01), keine gemeinsame Ablage mit Pfad-Präfix mehr.",ARC-01,QA-04,"Jeder Mandant hat einen eigenen, physisch getrennten Bucket/Pfad-Root im Objektspeicher +Ein Zugriffsversuch ohne oder mit falschem Tenant-Kontext kann technisch kein fremdes Bucket erreichen, nicht nur einen falschen Pfad +Bucket-Provisionierung ist Teil desselben automatisierten Schritts wie die Tenant-Datenbank-Anlage (Core TEN-01), keine manuelle Zusatzaktion nötig","Test bestätigt physische Bucket-Trennung zweier Mandanten +Simulierter Zugriffsversuch ohne Tenant-Kontext schlägt fehl, weil kein Bucket referenzierbar ist, nicht weil ein Pfadfilter greift +Provisionierungs-Test legt für einen neuen Mandanten Datenbank UND Bucket in einem Schritt an" +ARC-07,Export/Portabilität (offenes Format),🗄️ Archivierung & Speicherung,Backend,Mittel,3,3,Fertig,"Go, mbox/eml-Export","Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.",ARC-01,QA-05,"Export erzeugt vollständige, standardkonforme mbox- oder eml-Dateien +Anhänge bleiben im Export erhalten und sind referenziell konsistent +Export ist mandantenweise abgrenzbar und nachvollziehbar protokolliert","Test: exportierte Datei lässt sich mit gängigem Mail-Client importieren +Test: Export enthält keine Daten anderer Mandanten +Stichprobenvergleich Original vs. Export bestätigt Inhaltstreue" +ARC-08,Verschlüsselungsschlüssel-Rotation,🗄️ Archivierung & Speicherung,Backend,Mittel,3,4,Fertig,"Go, Envelope-Encryption","Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).",ARC-02,QA-03,"Neue Datenschlüssel werden über einen Hauptschlüssel gewrappt und rotierbar verwaltet +Rotation des Hauptschlüssels erfordert kein Neuverschlüsseln des gesamten Archivbestands +Alte Schlüsselversionen bleiben für Lesezugriff auf Altbestand kontrolliert verfügbar","Test: Rotation des Hauptschlüssels lässt Altbestand weiterhin lesbar +Test: kompromittierter alter Schlüssel kann gezielt gesperrt werden +Dokumentierter Rotationsvorgang wurde einmal vollständig durchgespielt" +IMP-01,IMAP-Postfach-Abruf & Scheduler,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,3,Fertig,"Go, Postgres-Jobqueue, IMAP4rev1","Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.",ING-01 ING-05,IMP-02 IMP-03 IMP-04 IMP-05 IMP-07 IMP-08 IMP-09 INT-05 UX-01,"Scheduler erkennt neue Nachrichten seit letztem Abruf zuverlässig über UID-Vergleich +Zustandsänderungen (gelesen/gelöscht) werden ohne Doppelimport übernommen +Abrufintervall ist je Postfach konfigurierbar und übersteht Neustarts des Dienstes","Test: zwei aufeinanderfolgende Läufe importieren keine Nachricht doppelt +Test: simulierter Dienst-Neustart mitten im Abgleich führt zu konsistentem Endzustand +Test gegen Testpostfach mit realistischem Nachrichtenaufkommen" +IMP-02,Anhangsverarbeitung bei Import,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, mime/multipart","Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.",ING-04 IMP-01,IMP-06 IMP-09,"Anhänge werden mit Originaldateiname, Größe und geprüftem Content-Type extrahiert +Größenlimit pro Anhang und pro Nachricht wird durchgesetzt +Fehlerhafte Anhänge blockieren nicht den Import der restlichen Nachricht","Test mit Nachricht, die einen überdimensionierten Anhang enthält, wird korrekt begrenzt +Test mit mehreren Anhängen unterschiedlichen Typs importiert alle korrekt +Test: ein defekter Anhang lässt Text und übrige Anhänge unangetastet" +IMP-03,E-Mail-Regeln (Zuordnung/Tags/Klassifizierung),🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, Postgres","Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.",IMP-01,IMP-09 INT-06,"Regeln lassen sich nach Absender, Betreff-Muster und Postfach definieren +Mehrere zutreffende Regeln werden nach dokumentierter Priorität angewendet +Regeländerungen wirken nur auf künftige Importe, nicht rückwirkend ohne expliziten Reindex-Auftrag","Test mit widersprüchlichen Regeln bestätigt dokumentierte Priorisierung +Test: neue Regel ändert keine bereits importierten Altbestände automatisch +Regelset mit 20+ Regeln bleibt performant auswertbar" +IMP-04,Fehlerbehandlung nicht-konformer Server,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,4,Fertig,"Go, IMAP4rev1","Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.",IMP-01,IMP-08 QA-02,"Bekannte Abweichungen (u. a. UIDVALIDITY=0) führen zu definiertem Fallback statt Sync-Abbruch +Unerwartete Serverantworten werden geloggt und übersprungen statt den gesamten Lauf zu stoppen +Fallback-Verhalten ist dokumentiert und für Support nachvollziehbar","Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback +Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten +Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs" +IMP-05,Hot-Folder/Scanner-Anbindung,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, fsnotify","Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.",IMP-01,QA-02,"Dateien in konfiguriertem Hot-Folder werden erkannt und dem richtigen Mandanten/Postfach zugeordnet +Bereits verarbeitete Dateien werden nicht doppelt importiert +Fehlerhafte Dateien werden in einen Fehlerordner verschoben statt den Scan-Lauf zu blockieren","Test: gleiche Datei zweimal abgelegt wird nur einmal importiert +Test: fehlerhafte Datei landet nachvollziehbar im Fehlerordner +Dauertest über mehrere Scan-Zyklen ohne Ressourcenleck" +IMP-06,Anhangs-Virenscan-Anbindung,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,5,Fertig,"Go, ClamAV-kompatible Anbindung","Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.",IMP-02,QA-02,"Jeder importierte Anhang wird vor Archivierung durch den Virenscanner geprüft +Positiver Fund führt zu Quarantäne des Anhangs statt automatischer Archivierung +Scanner-Ausfall blockiert den Import nicht unbegrenzt, sondern führt zu definiertem Fehlerzustand","Test mit EICAR-Testdatei bestätigt Quarantäne-Verhalten +Test: Scanner nicht erreichbar führt zu klar sichtbarem Fehlerzustand statt Hänger +Durchsatztest bestätigt akzeptable Verzögerung durch Scan-Schritt" +IMP-07,Mehrfach-Postfach-Verwaltung pro Tenant,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, Postgres, tenant_id","Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.",IMP-01,ARC-09 QA-02,"Ein Mandant kann mehrere Postfächer unabhängig voneinander konfigurieren +Jedes Postfach hat eigene Abrufparameter (Intervall, Zugangsdaten, Ordnerauswahl) +Postfach-Liste ist strikt nach tenant_id gefiltert","Test: zwei Mandanten mit je mehreren Postfächern sehen ausschließlich eigene Postfächer +Test: Löschen eines Postfachs beeinträchtigt andere Postfächer desselben Mandanten nicht +Konfigurationsänderung an einem Postfach wirkt nicht auf andere" +IMP-08,Fehler-Benachrichtigung bei Postfach-Sync-Ausfall,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,5,Fertig,Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher),"Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.",IMP-01 IMP-04,QA-02,"Wiederholte Sync-Fehlschläge über konfigurierbarer Schwelle lösen genau ein Ereignis an Core CFG-02 aus, nicht selbst versendet +Benachrichtigung enthält Postfach, Fehlerursache und Zeitpunkt des letzten erfolgreichen Abrufs +Erfolgreicher Sync nach Ausfall setzt den Alarmzustand zurück","Test: N aufeinanderfolgende Fehlschläge lösen genau eine Benachrichtigung aus, keine Spam-Flut +Test: erfolgreicher Lauf nach Ausfall beendet den Alarmzustand nachvollziehbar +Test mit mehreren betroffenen Postfächern gleichzeitig bleibt übersichtlich" +IMP-09,Import-Testsuite,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,5,Fertig,"Go testing, testify","Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.",IMP-01 IMP-02 IMP-03,QA-02,"Jeder Importpfad hat automatisierte Tests für Normal- und Fehlerfall +Tenant-Scoping ist für Postfach-Abruf und Regelanwendung durch eigene Tests abgedeckt +Testsuite läuft reproduzierbar in CI ohne echte externe Postfächer","Testabdeckungsbericht für Scheduler, Anhangsverarbeitung und Regeln liegt vor +CI-Lauf grün auf frischem Checkout +Stichprobenreview bestätigt sinnvolle Testfälle für nicht-konforme Server-Szenarien" +ING-01,IMAP-Server-Grundgerüst,📥 Ingestion & Protokoll-Server,Backend,Komplex,4,1,Fertig,"Go/net, IMAP4rev1 (RFC 3501)","IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).",,IMP-01 ING-02 ING-05 ING-06 ING-07 ING-08 ING-10 QA-07,"Server nimmt IMAP-Verbindungen an und durchläuft die drei Standard-Zustände korrekt +Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT) sind implementiert und beantwortet +Ungültige Kommandosequenzen werden mit korrektem IMAP-Fehlercode abgelehnt, nicht mit Verbindungsabbruch","Manuelle Session mit Standard-IMAP-Client durchgespielt und protokolliert +Automatisierter Test deckt alle drei Zustandsübergänge und deren verbotene Übergänge ab +Lasttest mit 50 parallelen Sessions ohne Ressourcenleck" +ING-02,POP3-Server,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go/net, POP3 (RFC 1939)","POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.",ING-01,ING-06 ING-07 ING-08 ING-10 QA-07,"Server durchläuft alle drei POP3-Zustände korrekt +RETR liefert vollständige Nachrichten, DELE markiert erst im Update-Zustand endgültig +Fehlerhafte Anmeldeversuche werden ohne Informationspreisgabe abgelehnt","Automatisierter Test für jede Zustandsübergangs-Regel +Test mit Standard-POP3-Client (z. B. via Skript) gegen Test-Postfach +Test: DELE ohne anschließendes QUIT löscht nichts endgültig" +ING-03,SMTP-Server & Mailer,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,1,Fertig,"Go/net/smtp, net/mail, SMTP (RFC 5321)","SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).",,ING-06 ING-08 ING-09 ING-10 QA-04 QA-07 ING-11,"SMTP-Annahme validiert Envelope und Nachrichtengröße vor der Annahme +Mailer erzeugt Header ausschließlich über strukturierte Writer-API, keine freie Stringkonkatenation +Ungültige Empfängerdaten führen zu sauberer SMTP-Fehlermeldung statt Absturz","Test mit Steuerzeichen/CRLF in Betreff und Anzeigenamen schlägt fehl bzw. wird bereinigt, kein Header-Bruch möglich +Automatisierter Test sendet Testmail über Mailpit/MailHog und prüft Header-Integrität +Lasttest mit gleichzeitigen Verbindungen ohne Verbindungsleck" +ING-04,MIME- & Anhang-Parsing,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,1,Fertig,"Go, encoding/mime, mime/multipart","MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.",,ARC-01 IMP-02 ING-10 ARC-10,"Multipart-Nachrichten mit verschachtelten Teilen werden vollständig zerlegt +Anhänge werden mit korrektem Dateinamen, Größe und Content-Type extrahiert +Fehlerhafte/inkonsistente Zeichensatzangaben werden defensiv repariert statt die Verarbeitung abzubrechen","Test mit sehr großem simuliertem Anhang bestätigt harte Ablehnung statt Speicheranstieg +Testkorpus mit realitätsnahen Multipart-/Encoding-Varianten läuft fehlerfrei durch +Fuzz-/Grenzwerttest mit kaputten MIME-Strukturen bricht kontrolliert ab, kein Absturz" +ING-05,Folder-State & UIDVALIDITY-Handling,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go, IMAP4rev1 (RFC 3501 §2.3.1.1)","Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.",ING-01,IMP-01 ING-10,"Jeder Ordner führt UIDVALIDITY und UIDNEXT korrekt gemäß RFC nach +Ordnerwechsel (SELECT/EXAMINE) liefert konsistenten State auch bei parallelem Zugriff +State-Änderungen (neue Mail, Löschung) werden atomar und nachvollziehbar persistiert","Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau +Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz +Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen" +ING-06,TLS/STARTTLS-Absicherung,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,3,Fertig,"Go crypto/tls, STARTTLS","TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.",ING-01 ING-02 ING-03,QA-04,"Anmeldedaten werden ausschließlich über TLS oder nach erfolgreichem STARTTLS akzeptiert +Schwache Cipher-Suiten und veraltete TLS-Versionen sind serverseitig deaktiviert +Zertifikatswechsel ist ohne Verbindungsabriss für bestehende Sessions möglich","Scan mit Standard-TLS-Prüfwerkzeug bestätigt keine schwachen Suiten +Test: Login-Versuch ohne TLS/STARTTLS wird verweigert +Test: Zertifikatsrotation im laufenden Betrieb ohne Dienstunterbrechung" +ING-07,Protokoll-Fehlerbehandlung & Wiederverbindung,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,3,Fertig,"Go, net, context","Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.",ING-01 ING-02,QA-02,"Verbindungsabbrüche räumen serverseitige Session-Ressourcen zuverlässig auf +Timeouts sind pro Protokollphase konfigurierbar und greifen nachweislich +Wiederholte Fehlversuche eines Clients führen zu klar definiertem Backoff statt Dauerschleife","Chaos-Test: Verbindung wird während aktiver Übertragung hart gekappt, kein Ressourcenleck danach +Test für Timeout-Auslösung in jeder Protokollphase +Test für Backoff-Verhalten bei wiederholten Fehlversuchen" +ING-08,Mailserver-Protokoll-Logging & Diagnose,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,3,Fertig,"Go, structured logging (slog)","Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.",ING-01 ING-02 ING-03,QA-02,"Jede Session erzeugt strukturierte Logs mit Korrelations-ID über die gesamte Verbindungsdauer +Zugangsdaten und Nachrichteninhalte erscheinen nie im Klartext im Log +Diagnosewerkzeug kann eine einzelne Session anhand der Korrelations-ID vollständig nachvollziehen","Test bestätigt Redaktion sensibler Felder in allen Log-Pfaden +Stichprobe: eine komplette Session ist über die Korrelations-ID lückenlos rekonstruierbar +Lasttest bestätigt, dass Logging die Durchsatzrate nicht relevant beeinträchtigt" +ING-09,Rate-Limiting auf Protokollebene,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go, Postgres-Jobqueue, Token-Bucket","Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.",ING-03,QA-04,"Login-Versuche pro Quelle/Zeitfenster sind begrenzt und konfigurierbar +SMTP-Annahmerate pro Absender/Quelle ist begrenzt und konfigurierbar +Überschreitung führt zu definierter Ablehnung mit Wartezeit-Hinweis, nicht zu Verbindungsabbruch ohne Erklärung","Lasttest bestätigt greifendes Limit bei Überschreitung +Test: legitime Nutzung unterhalb der Schwelle bleibt unbeeinträchtigt +Test: Limit ist je Mandant getrennt konfigurierbar und wirksam" +ING-10,Ingestion-Testsuite,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,3,Fertig,"Go testing, testify, Mailpit/MailHog","Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.",ING-01 ING-02 ING-03 ING-04 ING-05,QA-02,"Jede Protokoll-Zustandsmaschine hat automatisierte Tests für erlaubte und verbotene Übergänge +Tenant-Scoping ist für jeden Ingestion-Pfad durch einen eigenen Test abgedeckt +Testsuite läuft reproduzierbar in der CI ohne externe Live-Postfächer","Testabdeckungsbericht für alle fünf Ingestion-Module liegt vor +CI-Lauf grün auf frischem Checkout ohne manuelle Nacharbeit +Stichprobenreview durch zweite Person bestätigt sinnvolle Testfälle, nicht nur Zeilenabdeckung" +INT-01,REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung,🔌 Integration & API,Backend,Mittel,3,6,Fertig,"Go net/http, REST, OpenAPI 3",Mail-spezifische API-Endpunkte (Mail-Liste/Mail-Detail/Anhang-Download usw.) auf dem zentralen Core-REST-Grundgerüst definieren und im modul-eigenen OpenAPI-Beitrag dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur.,ARC-01 SRC-03,INT-06 INT-07 QA-06 INT-12,"API bietet Endpunkte für Mail-Liste, Mail-Detail und Anhang-Download +Alle Endpunkte sind strikt mandantengebunden +IAM-nahe Funktionen (Login, Tenant-Verwaltung) sind bewusst nicht Teil dieser API +Modul-eigener OpenAPI-Beitrag deckt alle v1-Endpunkte inklusive Fehlerantworten ab und ist gegen die tatsächliche API geprüft","Test: Zugriff ohne gültigen Tenant-Kontext wird abgelehnt +Vertragstest gegen definierte Endpunkte läuft grün +Codereview bestätigt Abgrenzung zu Core-Board-Zuständigkeiten +Validierungslauf des OpenAPI-Dokuments gegen Standardwerkzeuge ist fehlerfrei" +INT-05,"Benachrichtigungs-Service ""neue Mail""",🔌 Integration & API,Backend,Einfach,2,4,Fertig,Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher),"Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.",IMP-01,QA-06,"Neue Mail im überwachten Postfach löst zeitnah ein Ereignis an Core CFG-02 aus, das den Versand übernimmt +Benutzer kann Benachrichtigungsart und -häufigkeit konfigurieren +Massenimport (viele Mails gleichzeitig) erzeugt gebündelte statt Dutzende Einzelbenachrichtigungen","Test: Import einer Mail löst genau eine Benachrichtigung aus +Test: Massenimport erzeugt eine gebündelte Zusammenfassung statt Flut +Test: deaktivierte Benachrichtigung erzeugt keine Zustellung" +INT-06,E-Mail-Regel-Engine über API steuerbar,🔌 Integration & API,Backend,Mittel,3,7,Fertig,"Go net/http, REST","E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.",IMP-03 INT-01,QA-06,"Regeln lassen sich vollständig über die API anlegen, ändern und löschen +Prioritätsreihenfolge ist über die API einsehbar und änderbar +API-Änderungen wirken identisch zur bisherigen internen Regel-Anwendung","Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab +Test: über API gesetzte Regel wird beim nächsten Import korrekt angewendet +Test: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten" +INT-07,Health-Check-Endpunkt für Mail-Modul,🔌 Integration & API,Backend,Einfach,2,7,Fertig,Go net/http,"Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.",INT-01,QA-06,"Health-Endpunkt meldet Status von Datenbank, Objektspeicher, Suchindex und Jobqueue getrennt +Endpunkt ist ohne Authentifizierung für interne Überwachung erreichbar, aber ohne sensible Details +Ausfall einer Teilkomponente wird klar als „degraded“ statt generischem Fehler gemeldet","Test: simulierter Ausfall einer Abhängigkeit wird korrekt im Health-Status abgebildet +Test: Health-Antwort enthält keine sensiblen Konfigurationsdetails +Integrationstest gegen echten Health-Endpunkt nach Deploy" +QA-01,Teststrategie Mail,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Fertig,"Testkonzept, Go testing, Playwright/Jest","Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.",,,"Teststrategie benennt Testarten (Unit/Integration/E2E) und Mindestabdeckung je Modultyp +Protokoll- und Compliance-kritische Module haben verbindlich höhere Testpflicht als Standard-Module +Vorgehen für Bug-Tracking ist festgelegt und durchsuchbar (kein reines Code-Kommentar-Tracking) +Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Dokument liegt vor und wurde von zweiter Person gegengelesen +Stichprobe: mindestens ein Beispieltest je benannter Testart ist umgesetzt +Bug-Tracking-Vorgehen wurde einmal exemplarisch für einen realen Befund durchgespielt" +QA-02,Prüfgate Ingestion & Import,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,"Testkonzept, CI","Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.",ING-10 IMP-09 IMP-04 IMP-05 IMP-06 IMP-07 IMP-08 ING-07 ING-08,QA-09,"Gate prüft Testabdeckung und Bestehen aller Ingestion-/Import-Testsuiten +Gate prüft, dass bekannte Fehlerpunkte (Header-Injection, Anhang-Limit, UIDVALIDITY) durch Tests abgedeckt sind +Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand von ING-10/IMP-09 dokumentiert +Stichprobe: mindestens ein Regressionstest je bekanntem Fehlerpunkt vorhanden +Zweite Person bestätigt Gate-Ergebnis unabhängig" +QA-03,Prüfgate Archivierung & Suche,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,"Testkonzept, CI","Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.",ARC-08 SRC-10 SRC-02 SRC-04 SRC-05 SRC-08 SRC-09,QA-09,"Gate prüft Bestehen der Archivierungs- und Suchindex-Testsuiten inklusive Schlüsselrotation +Gate prüft Abwesenheit dynamischer SQL-Klauselbildung im Suchpfad +Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand von ARC-08/SRC-10 dokumentiert +Codereview-Stichprobe bestätigt statischen Query-Builder +Zweite Person bestätigt Gate-Ergebnis unabhängig" +QA-04,Sicherheits- & Berechtigungsprüfung,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,4,Fertig,"Sicherheitsprüfung, Threat Modeling","Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.",ING-03 ARC-06 ING-09 ING-06 SRC-11,QA-09,"Prüfung bestätigt wirksame Härtung des SMTP-Pfads gegen bekannte Angriffsmuster +Prüfung bestätigt lückenlose Mandantentrennung im Speicherpfad +Prüfung bestätigt korrekt greifendes API-Token-/Rate-Limiting","Gezielter Testangriff auf Header-Injection schlägt fehl +Stichprobenprüfung mehrerer Speicherpfade auf Mandantentrennung +Test: API-Zugriff mit widerrufenem/fremdem Token wird verweigert" +QA-05,Prüfgate Compliance & eDiscovery,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Fertig,Compliance-Prüfung,"Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.",ARC-05 ARC-07 INT-08 ARC-10 ARC-04 ARC-09,QA-09,"Gate prüft korrekte Kopplung mailrelevanter Ereignisse an das Core-Audit-Log +Gate prüft, dass eDiscovery-Tenant-Scoping in der Query-Schicht verankert ist +Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand der Audit-Trail-Kopplung (CMP-04) dokumentiert +Stichprobe: Audit-Eintrag für Testlöschung ist im Core-Audit-Log auffindbar +Zweite Person bestätigt Gate-Ergebnis unabhängig" +QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Fertig,"Vertragstests, OpenAPI","Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.",INT-01 INT-05 INT-06 INT-07 INT-09 INT-10,QA-09,"Vertragstest deckt alle in der OpenAPI-Beschreibung definierten Endpunkte ab +Abweichungen zwischen Beschreibung und tatsächlichem Verhalten werden automatisch erkannt +Vertragstest läuft als Teil der CI bei jeder Änderung","CI-Lauf des Vertragstests ist grün auf aktuellem Stand +Test: absichtlich eingefügte Abweichung wird vom Vertragstest erkannt +Stichprobenreview durch zweite Person" +QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Fertig,Lasttest-Werkzeug (z. B. k6/vegeta),"Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.",ING-01 ING-02 ING-03,QA-09,"Lasttest simuliert realistische Anzahl paralleler Sessions je Protokoll +Ergebnis zeigt Durchsatz- und Latenzwerte je Protokoll unter Last +Zielwerte für Antwortzeit/Durchsatz sind definiert und werden erreicht","Lasttest-Lauf mit Ergebnisprotokoll liegt vor +Vergleich Ist- vs. Zielwert dokumentiert +Ressourcenverbrauch (CPU/RAM) während des Lasttests bleibt im erwarteten Rahmen" +QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Fertig,Accessibility-Audit-Werkzeug,Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.,UX-07 UX-08 UX-09,QA-09,"Automatisierter Audit-Lauf zeigt keine kritischen Verstöße mehr +Manuelle Stichprobe bestätigt sinnvolle Tastatur- und Screenreader-Bedienung +Ergebnis ist dokumentiert und mit Verantwortlichen für Nachbesserung rückgekoppelt","Audit-Bericht liegt vor mit Vorher/Nachher-Vergleich +Stichprobentest mit Screenreader durch zweite Person +Offene Punkte sind priorisiert und nachverfolgbar dokumentiert" +QA-09,Abnahme- & Compliance-Prüfung Mail,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Fertig,Abnahmeprüfung,"Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.",QA-02 QA-03 QA-04 QA-05 QA-06 QA-07 QA-08 SRC-06,,"Alle vorgelagerten Prüfgates (Ingestion/Import, Archivierung/Suche, Sicherheit, Compliance) sind bestanden +Abnahmebericht fasst Ergebnisse aller Gates nachvollziehbar zusammen +Offene Punkte aus einzelnen Gates sind vollständig aufgelistet oder als geschlossen bestätigt","Abnahmebericht liegt vor und wurde gegengelesen +Stichprobe: mindestens ein Ergebnis je vorgelagertem Gate ist im Bericht nachprüfbar verlinkt +Freigabeentscheidung ist dokumentiert mit Datum und verantwortlicher Person" +SRC-01,Manticore-Suchindex für Mails,🔍 Suche & OCR,Backend,Mittel,3,4,Fertig,"Go, Manticore Search SQL/HTTP-API","Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.",ARC-01 ARC-03,SRC-02 SRC-03 SRC-09,"Index-Schema für Mail-Felder ist definiert und über Migration versioniert +Schreibzugriffe auf den Index verwenden ausschließlich statische, vordefinierte Feldnamen +Index ist mandantengetrennt abfragbar","Codereview bestätigt: keine Sprintf/Join-basierte SQL-Klauselbildung im Index-Zugriff +Test: Abfrage mit manipulierten Eingabewerten verändert keine Spalten-/Tabellennamen +Funktionstest: Volltextsuche liefert erwartete Treffer für Testkorpus" +SRC-02,Indexierungs-Worker & Synchronisierung,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, Postgres-Jobqueue","Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.",SRC-01 ARC-03,QA-03 SRC-12,"Neue Archivobjekte erscheinen innerhalb definierter Zeit im Suchindex +Löschungen und Metadatenänderungen werden im Index nachgezogen +Worker-Ausfall verliert keine Indexierungsaufträge (Wiederaufnahme aus Postgres-Jobqueue)","Test: Worker-Neustart mitten im Lauf verliert keinen offenen Auftrag +Test: Löschung einer Mail entfernt sie zuverlässig aus Suchtreffern +Konsistenztest vergleicht Datenbankbestand mit Indexbestand stichprobenartig" +SRC-03,Such-API mit Ranking,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, Manticore Search","Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).",SRC-01,INT-01 SRC-04 SRC-05 SRC-08,"Suche liefert nach Relevanz sortierte Treffer mit nachvollziehbarem Ranking +Ergebnisse sind strikt auf den anfragenden Mandanten beschränkt +Grundoperatoren (Phrasensuche, Ausschluss) funktionieren korrekt","Test: Suche eines Mandanten liefert keine Treffer eines anderen Mandanten +Test: Phrasensuche und Ausschlussoperator liefern erwartete Teilmengen +Performance-Test mit großem Testkorpus bleibt innerhalb Zielzeit" +SRC-04,Such-Oberfläche mit Hervorhebung,🔍 Suche & OCR,Frontend,Mittel,3,6,Fertig,Next.js/React/TS,Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.,SRC-03 SHL-01,QA-03,"Eingabe liefert Trefferliste mit hervorgehobenen Suchbegriffen im Snippet +Klick auf Treffer öffnet die zugehörige Mail direkt an der Fundstelle +Leere Ergebnisse zeigen verständlichen Hinweis statt leerer Fläche","Manueller Test mit typischen Suchanfragen bestätigt korrekte Hervorhebung +Barrierefreiheits-Kontrastprüfung der Hervorhebung +Test mit Sonderzeichen in der Suchanfrage bricht die Anzeige nicht" +SRC-05,Facetten- & Filter-API,🔍 Suche & OCR,Backend,Einfach,2,6,Fertig,"Go, Manticore Facets","Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).",SRC-03,SRC-06 QA-03,"API liefert Facettenwerte mit Trefferzahl je Filterdimension +Mehrere Filter lassen sich kombinieren (UND-Verknüpfung) +Facetten sind mandantengetrennt berechnet","Test: Facettenzahlen stimmen mit tatsächlicher Treffermenge überein +Test: Kombination von drei Filtern liefert korrekt eingeschränkte Treffer +Test: Facetten eines Mandanten enthalten keine Werte eines anderen" +SRC-06,Facetten-UI & Filter-Chips,🔍 Suche & OCR,Frontend,Einfach,2,7,Fertig,Next.js/React/TS,"Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.",SRC-05 SHL-01,QA-09,"Aktive Filter erscheinen als entfernbare Chips oberhalb der Trefferliste +Trefferzahl je Facettenwert wird live aktualisiert +Zurücksetzen aller Filter ist mit einem Klick möglich","Manueller Test: Filterkombination und Einzelentfernung funktionieren wie erwartet +Tastaturbedienbarkeit der Filter-Chips geprüft +Test mit vielen aktiven Filtern bleibt die Ansicht übersichtlich" +SRC-07,OCR für Anhänge,🔍 Suche & OCR,Backend,Mittel,3,4,Fertig,"Go, OCR-Engine-Anbindung (z. B. Tesseract)","OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.",ARC-01 ARC-03,SRC-10 SRC-12,"Bild- und gescannte PDF-Anhänge werden automatisch per OCR verarbeitet +Erkannter Text wird dem zugehörigen Mail-Suchdokument zugeordnet +Bereits durchsuchbare PDFs (mit Textebene) werden nicht unnötig erneut per OCR verarbeitet","Test: Bildanhang mit bekanntem Text liefert erwartete Texterkennung +Test: PDF mit vorhandener Textebene wird korrekt übersprungen +Durchsatztest bestätigt akzeptable Verarbeitungszeit je Anhang" +SRC-08,Gespeicherte Suchanfragen,🔍 Suche & OCR,Backend,Einfach,2,6,Fertig,"Go, Postgres","Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.",SRC-03,QA-03,"Suchkriterien inklusive aktiver Filter lassen sich unter einem Namen speichern +Gespeicherte Suche liefert bei erneuter Ausführung aktuelle Treffer, keinen eingefrorenen Snapshot +Gespeicherte Suchen sind je Benutzer/Mandant getrennt sichtbar","Test: gespeicherte Suche mit mehreren Filtern wird korrekt reproduziert +Test: Benutzer sieht keine gespeicherten Suchen anderer Mandanten +Test: Löschen einer gespeicherten Suche entfernt nur diese" +SRC-09,Suchindex-Neuaufbau/Reindexierung,🔍 Suche & OCR,Backend,Einfach,2,5,Fertig,"Go, Manticore Search","Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.",SRC-01,QA-03,"Voller Reindex lässt sich ohne Datenverlust im laufenden Betrieb anstoßen +Fortschritt und Abschluss des Reindex sind nachvollziehbar sichtbar +Alter Index bleibt bis zum erfolgreichen Abschluss des neuen Index abfragbar (kein Suchausfall)","Test: Reindex während laufender Suchanfragen unterbricht die Suche nicht +Test: abgebrochener Reindex hinterlässt keinen inkonsistenten Zustand +Stichprobenvergleich Alt-/Neuindex bestätigt gleiche Trefferzahlen" +SRC-10,Spracherkennung & OCR-Qualitätsbewertung,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, OCR-Engine-Anbindung","Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.",SRC-07,QA-03,"Erkannte Sprache wird je OCR-Text gespeichert und für Suche/Anzeige genutzt +Konfidenzwert der Erkennung wird gespeichert und ist auswertbar +Anhänge mit niedriger OCR-Qualität sind gezielt auffindbar (z. B. für manuelle Nachbearbeitung)","Test mit mehrsprachigem Testkorpus bestätigt korrekte Spracherkennung +Test: künstlich verschlechtertes Bild erzeugt niedrigeren Konfidenzwert +Abfrage aller Anhänge unterhalb einer Konfidenzschwelle liefert erwartete Treffer" +UX-01,Postfach- & Ordneransicht,📱 Postfach-Oberfläche,Frontend,Mittel,3,4,Fertig,Next.js/React/TS,"Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.",IMP-01 SHL-01,UX-02 UX-04 UX-05 UX-06 UX-07 UX-08,"Ordnerbaum zeigt alle Postfächer/Ordner des angemeldeten Mandanten korrekt +Nachrichtenliste unterstützt Sortierung nach Datum/Absender/Betreff +Ansicht bleibt bei mehreren tausend Nachrichten performant bedienbar","Manueller Test mit Testpostfach bestätigt korrekte Ordner-/Listendarstellung +Performance-Test mit großer Nachrichtenliste bleibt flüssig +Test: Benutzer sieht ausschließlich Postfächer des eigenen Mandanten" +UX-02,E-Mail-Detailansicht & Thread-Darstellung,📱 Postfach-Oberfläche,Frontend,Mittel,3,5,Fertig,Next.js/React/TS,"E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.",UX-01 SHL-01,UX-07 UX-08 UX-09,"Detailansicht zeigt Nachrichtentext, relevante Header und Anhangsliste vollständig +Zusammengehörige Nachrichten werden als Thread gruppiert dargestellt +Navigation zwischen Thread-Nachrichten funktioniert ohne Kontextverlust","Manueller Test mit mehrteiligem Thread bestätigt korrekte Gruppierung +Test: Anhangsliste stimmt mit tatsächlich archivierten Anhängen überein +Barrierefreiheits-Grundprüfung der Detailansicht" +UX-03,Anhang-Vorschau,📱 Postfach-Oberfläche,Frontend,Mittel,3,3,Fertig,"Next.js/React/TS, Canvas-Rendering","Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.",ARC-01 SHL-01,UX-07,"Vorschau funktioniert für PDF- und Bildanhänge ohne externen Download +Content-Type wird serverseitig über Magic-Bytes bestimmt, nicht über die Dateiendung +PDF-Vorschau nutzt Canvas-Rendering, kein iframe/HTML-Rendering von Anhangsinhalt","Test: Anhang mit falscher Dateiendung, aber echtem PDF-Inhalt wird korrekt als PDF erkannt und angezeigt +Sicherheitsreview bestätigt: keine iframe-Einbindung von Anhangsinhalt +Test: manipulierter Dateiname mit abweichendem Inhalt löst keine Fehlanzeige/-ausführung aus" +UX-04,Responsive Layout & mobile Navigation,📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Fertig,"Next.js/React/TS, CSS Grid/Flexbox","Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).",UX-01 SHL-01,UX-07,"Kernansichten sind auf schmalen Viewports vollständig nutzbar +Navigation zwischen Ordnerliste, Nachrichtenliste und Detail ist auf Mobilgeräten ohne Verlust bedienbar +Keine horizontal abgeschnittenen Inhalte auf gängigen Bildschirmbreiten","Manueller Test auf mindestens drei Viewport-Breiten +Touch-Bedienungstest der Kernnavigation +Automatisierter Layout-Regressionstest für Kernansichten" +UX-05,Dunkles Erscheinungsbild & Theming,📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Fertig,"Next.js/React/TS, CSS Custom Properties","Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.",UX-01 SHL-01,UX-07,"Dunkles und helles Erscheinungsbild sind vollständig nutzbar, keine unlesbaren Kontraste +Einstellung folgt Systempräferenz, ist aber manuell überschreibbar +Theme-Wahl bleibt über Sitzungen hinweg erhalten","Kontrastprüfung für beide Modi nach WCAG-Mindestwerten +Test: manuelle Theme-Wahl übersteht Neuladen der Seite +Visuelle Stichprobe aller Kernansichten in beiden Modi" +UX-06,Mehrsprachigkeit (Deutsch/Englisch),📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Fertig,"Next.js/React/TS, i18n","Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.",UX-01 SHL-01,UX-07,"Alle Oberflächentexte der Kernansichten liegen in Deutsch und Englisch vor +Sprachumschaltung wirkt sofort ohne vollständigen Seiten-Neuladen +Datums-/Zahlenformate folgen der gewählten Sprache","Stichprobenprüfung auf fehlende Übersetzungen (keine Schlüssel sichtbar statt Text) +Test: Sprachumschaltung funktioniert in allen Kernansichten +Test: Datumsformat wechselt korrekt zwischen beiden Sprachen" +UX-07,Barrierefreiheit nach WCAG 2.1 AA,📱 Postfach-Oberfläche,Frontend,Mittel,3,6,Fertig,"Next.js/React/TS, WCAG 2.1 AA","Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).",UX-01 UX-02 UX-03 UX-04 UX-05 UX-06 SHL-01,QA-08,"Alle Kernansichten erreichen WCAG 2.1 AA in automatisierter Prüfung ohne kritische Verstöße +Vollständige Bedienbarkeit ohne Maus ist für alle Kernfunktionen gegeben +Screenreader-Ausgabe ist für zentrale Elemente sinnvoll und vollständig","Automatisierter Accessibility-Scan aller Kernansichten ohne kritische Befunde +Manueller Tastatur-Durchlauf durch alle Kernfunktionen +Stichprobentest mit Screenreader durch zweite Person" +UX-08,Tastatur-Bedienung & Shortcuts,📱 Postfach-Oberfläche,Frontend,Einfach,2,6,Fertig,Next.js/React/TS,"Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).",UX-01 UX-02 SHL-01,QA-08,"Kernaktionen sind über dokumentierte Tastenkombinationen erreichbar +Shortcuts kollidieren nicht mit Standard-Browser-Kürzeln +Aktueller Fokus ist jederzeit visuell erkennbar","Manueller Test aller dokumentierten Shortcuts in den Kernansichten +Test: kein Shortcut überschreibt sicherheitsrelevante Browser-Funktion +Fokus-Sichtbarkeitsprüfung in allen Kernansichten" +UX-09,Akten-/Vorgangsanzeige im Mail-Kontext,📱 Postfach-Oberfläche,Frontend,Einfach,2,6,Fertig,"Next.js/React/TS, externe REST-API","In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.",UX-02 SHL-01,QA-08,"E-Mail-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden +Kein eigenes Akte-Datenmodell in Mail, ausschließlich Anzeige über die externe API +Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Mailanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“","E-Mail mit verknüpfter Akte zeigt Akte-Informationen korrekt an +E-Mail ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler +Simulierter Ausfall der Workflow-API blockiert die übrige Mailanzeige nicht" +ARC-09,Postfach-Quota,🗄️ Archivierung & Speicherung,Backend,Einfach,2,5,Fertig,"Go, Postgres, tenant_id","Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.",ARC-01 IMP-07,QA-05,"Speicherlimit ist je Postfach konfigurierbar, unabhängig von der Tenant-weiten Quota aus Core LIC-05 +Postfach am Limit lehnt neue eingehende Mail mit klarer, protokollgerechter Fehlermeldung ab (SMTP-Rückweisung), verwirft nicht stillschweigend +Ein Postfach am Limit beeinträchtigt keine anderen Postfächer desselben Tenants","Test: Postfach-Quota erreicht, neue eingehende Mail wird mit korrekter SMTP-Fehlermeldung abgelehnt +Test: anderes Postfach desselben Tenants empfängt weiterhin normal, während eines am Limit ist +Verbrauchsanzeige je Postfach im Test korrekt gegen tatsächliche Größe geprüft" +ARC-10,Signatur- und Zeitstempelerhalt (BSI TR-03125),🗄️ Archivierung & Speicherung,Backend,Einfach,3,4,Fertig,"Go (crypto/x509, S/MIME-/PGP-Signaturprüfung), RFC-3161-Zeitstempel-Client oder lokaler Fallback","Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und Prüfergebnis inkl. vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Zertifikatsablauf nachweisbar bleibt (BSI TR-03125).",ING-04 ARC-01,QA-05,"Signierte Mails (S/MIME und PGP/MIME) werden bei Archivierung erkannt, unsignierte Mails durchlaufen KEINE zusätzliche Prüfung +Signaturprüfergebnis (gültig/ungültig/Prüfung nicht möglich, Zertifikatsdaten, Prüfzeitpunkt) wird unveränderlich mitarchiviert +Prüfnachweis ist über die Mail-Detailansicht abrufbar, ohne die Original-Mail zu verändern","Test mit echter S/MIME-signierter Testmail: Prüfergebnis 'gültig' korrekt erkannt und archiviert +Test mit signierter Mail mit manipuliertem Inhalt: Prüfergebnis 'ungültig' korrekt erkannt +Simulierter Zertifikatsablauf nach Archivierung: archivierter Prüfnachweis bleibt unverändert abrufbar" +INT-08,Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage,🔌 Integration & API,Backend,Mittel,3,4,Fertig,"HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping","Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.",ARC-01,QA-05 INT-11,"Mail-/Anhang-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert +Vor Löschung einer archivierten Mail wird eine Sperr-Abfrage an Archive gestellt +Ist die Mail gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt +Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt","Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort +Test: gesperrte Mail kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar +Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung" +INT-09,AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01),🔌 Integration & API,Backend,Mittel,2,4,Fertig,"HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping","Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.",ARC-01,QA-06 INT-11,"Mail-/Thread-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert +Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet Mail unverändert ohne Fehler +Registrierungsfehler blockieren niemals den regulären Mail-Betrieb (fail open bei Registrierung)","Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort +Test: AI-Modul deaktiviert – Mail startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb +Test: AI-Endpunkt nicht erreichbar bei Registrierung – Mail-Start wird dadurch nicht blockiert" +INT-10,Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02),🔌 Integration & API,Backend,Mittel,3,4,Fertig,"HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher","Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.",ARC-01,QA-06 INT-11,"Mail-/Thread-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert +Ereignis 'Mail eingegangen' wird bei Zustellung tatsächlich an Workflow publiziert +Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende Mail-Aktion (asynchron, nicht im Request-Pfad)","Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort +Test: Mail eingegangen – Ereignis kommt nachweislich bei Workflow an +Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Mailzustellung bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)" +SRC-11,Feld-Whitelist-Query-Builder für Suchindex-Zugriff,🔍 Suche & OCR,Backend,Einfach,1,4,Fertig,"Statisches Enum/Switch für Feldnamen, getesteter Query-Builder","Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.",SRC-01,QA-04,"Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau +Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung +Entscheidung dokumentiert: Mail-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren","Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert +Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt" +ARC-11,RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf,🗄️ Archivierung & Speicherung,Backend,Mittel,3,5,Fertig,"HTTP-Client gegen Archive RET-05, Rückruf-Endpunkt, Postgres-Jobqueue für Requeue","Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, empfängt Vernichtungs-Rückrufe und behandelt Registrierungsfehler tolerant statt sie zu verschlucken.",ARC-01 RET-09,,"Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse +Mail empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg +Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue, nicht zu einem Absturz oder stillem Verwerfen","Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert, für Mail UND Anhang getrennt +Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, Mail-Löschung nachweislich erfolgt, 2xx-Antwort gesendet +Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag, kein Absturz" +ING-11,Header-Injection-Schutz für ausgehende Mailer-Komponente,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,8,Fertig,"Go net/mail, RFC 5322, CRLF-Validierung","ING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.",ING-03,,"Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code +Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen +Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben","Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert +Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt +Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern" +INT-11,Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow),🔌 Integration & API,Backend,Mittel,2,8,Fertig,"Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go","INT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.",INT-08 INT-09 INT-10,,"Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter +Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope +Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert","Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten +Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt +Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation" +INT-12,Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit,🔌 Integration & API,Backend,Einfach,1,8,Fertig,"Storage-Adapter, signierte URLs, Go","INT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.",INT-01 ARC-01,,"Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang +Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter +Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff","Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler +Test: abgelaufene URL wird abgelehnt +Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt" +SRC-12,Ressourcenlimits für OCR-/Indexierungs-Jobs,🔍 Suche & OCR,Backend,Mittel,2,8,Fertig,"Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)","SRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.",SRC-02 SRC-07,,"Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl +Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers +Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst","Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen +Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs +Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs" diff --git a/mail-kanban/board.json b/mail-kanban/board.json new file mode 100644 index 00000000..bc8e5e1d --- /dev/null +++ b/mail-kanban/board.json @@ -0,0 +1,2681 @@ +{ + "erzeugtAm": "2026-08-26", + "totalDays": 171, + "epics": [ + { + "key": "ING", + "name": "Ingestion & Protokoll-Server", + "emoji": "📥", + "color": "#0891B2", + "description": "IMAP-, POP3- und SMTP-Server, MIME-Parsing, Protokoll-Absicherung und -Diagnose." + }, + { + "key": "IMP", + "name": "Postfach-Import & Synchronisierung", + "emoji": "🔄", + "color": "#2563EB", + "description": "Abruf, Regeln, Fehlerbehandlung und Verwaltung mehrerer Postfächer je Mandant." + }, + { + "key": "ARC", + "name": "Archivierung & Speicherung", + "emoji": "🗄️", + "color": "#92400E", + "description": "Objektspeicher, Verschlüsselung, Dublettenerkennung, Aufbewahrungsstruktur und Export." + }, + { + "key": "SRC", + "name": "Suche & OCR", + "emoji": "🔍", + "color": "#0E7490", + "description": "Manticore-Suchindex, Indexierung, Facetten, gespeicherte Suchen und OCR für Anhänge." + }, + { + "key": "INT", + "name": "Integration & API", + "emoji": "🔌", + "color": "#14B8A6", + "description": "REST-API, OpenAPI, Token/Rate-Limiting, Webhooks und Benachrichtigungen." + }, + { + "key": "UX", + "name": "Postfach-Oberfläche", + "emoji": "📱", + "color": "#F97316", + "description": "Postfach- und Thread-Ansicht, Anhang-Vorschau, Responsivität, Theming, Sprache, Barrierefreiheit." + }, + { + "key": "QA", + "name": "Prüfungen & Qualitätssicherung", + "emoji": "✅", + "color": "#16A34A", + "description": "Teststrategie und verbindliche Prüfgates für Ingestion, Archivierung, Compliance und Schnittstellen." + } + ], + "waves": [ + { + "welle": 1, + "codes": [ + "ING-01", + "ING-03", + "ING-04", + "QA-01" + ] + }, + { + "welle": 2, + "codes": [ + "ARC-01", + "ING-02", + "ING-05", + "ING-09" + ] + }, + { + "welle": 3, + "codes": [ + "ARC-02", + "ARC-03", + "ARC-04", + "ARC-05", + "ARC-06", + "ARC-07", + "IMP-01", + "ING-06", + "ING-07", + "ING-08", + "ING-10", + "QA-07", + "UX-03" + ] + }, + { + "welle": 4, + "codes": [ + "ARC-08", + "IMP-02", + "IMP-03", + "IMP-04", + "IMP-05", + "IMP-07", + "INT-05", + "QA-04", + "SRC-01", + "SRC-07", + "UX-01", + "ARC-10", + "INT-08", + "INT-09", + "INT-10" + ] + }, + { + "welle": 5, + "codes": [ + "ARC-09", + "IMP-06", + "IMP-08", + "IMP-09", + "SRC-02", + "SRC-03", + "SRC-09", + "SRC-10", + "UX-02", + "UX-04", + "UX-05", + "UX-06", + "QA-05" + ] + }, + { + "welle": 6, + "codes": [ + "INT-01", + "QA-02", + "QA-03", + "SRC-04", + "SRC-05", + "SRC-08", + "UX-07", + "UX-08", + "UX-09" + ] + }, + { + "welle": 7, + "codes": [ + "INT-06", + "INT-07", + "QA-06", + "QA-08", + "QA-09", + "SRC-06" + ] + }, + { + "welle": 8, + "codes": [ + "ING-11", + "INT-11", + "INT-12", + "SRC-12" + ] + } + ], + "kritischerPfad": { + "path": [ + "ING-01", + "ING-05", + "IMP-01", + "UX-01", + "UX-02", + "UX-07", + "QA-08" + ], + "days": 21 + }, + "produktDna": { + "uebernehmen": [ + { + "produkt": "Dovecot", + "staerke": "Referenzarchitektur für robuste IMAP-Server: klare Trennung von Protokoll-State-Machine, Storage-Backend und Auth-Schicht." + }, + { + "produkt": "Dovecot", + "staerke": "Defensive Behandlung nicht-konformer Clients/Server statt Best-Effort-Parsing, das bei Abweichungen stillschweigend falsch weiterläuft." + }, + { + "produkt": "Rspamd", + "staerke": "Mailserver-Härtung und Rate-Limiting als eigenständige, konfigurierbare Schicht vor der eigentlichen Verarbeitung." + }, + { + "produkt": "Mailpit/MailHog", + "staerke": "Mailflows sind von Anfang an automatisiert testbar, ohne echten Mailserver oder externe Postfächer." + }, + { + "produkt": "ecoDMS", + "staerke": "Revisionssichere Ablage: einmal archivierte Inhalte sind unveränderlich und lückenlos nachvollziehbar." + }, + { + "produkt": "Alfresco", + "staerke": "Aufbewahrungsfristen und Audit-Trail als Kernfunktion der Content-Verwaltung, nicht als Nachrüstung." + } + ], + "vermeiden": [ + { + "schwaeche": "archivmail – Header-Injection durch ungeprüfte Stringkonkatenation im Mailer.", + "loesung": "Ausgabe strikt über net/mail-Writer oder harte CRLF-/Steuerzeichen-Validierung." + }, + { + "schwaeche": "archivmail – ungebremstes io.ReadAll beim Anhang-Parsing ohne Größenlimit.", + "loesung": "io.LimitReader mit Max-Size und harter Ablehnung bei Überschreitung." + }, + { + "schwaeche": "archivmail – nur 2 von 18 Modulen mit Tests trotz protokollkritischer Logik.", + "loesung": "Pflichttests für Tenant-Scoping und Protokoll-State-Machines vor jedem Merge." + }, + { + "schwaeche": "archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.", + "loesung": "Spalten- und Tabellennamen ausschließlich aus statischen Konstanten, kein String-Zusammenbau." + } + ] + }, + "epicDna": { + "ING": { + "leitsatz": "Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.", + "uebernehmen": [ + "Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.", + "Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.", + "Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht." + ], + "vermeiden": [ + "archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.", + "archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge." + ] + }, + "IMP": { + "leitsatz": "Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.", + "uebernehmen": [ + "archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.", + "Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.", + "Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen." + ], + "vermeiden": [ + "archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.", + "archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode." + ] + }, + "ARC": { + "leitsatz": "Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.", + "uebernehmen": [ + "archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.", + "ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.", + "Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht." + ], + "vermeiden": [ + "archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap." + ] + }, + "SRC": { + "leitsatz": "Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.", + "uebernehmen": [ + "archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.", + "ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature." + ], + "vermeiden": [ + "archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder." + ] + }, + "INT": { + "leitsatz": "Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.", + "uebernehmen": [ + "archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.", + "Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt." + ], + "vermeiden": [ + "archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board." + ] + }, + "UX": { + "leitsatz": "Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.", + "uebernehmen": [ + "Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.", + "archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md." + ], + "vermeiden": [ + "archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.", + "archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt." + ] + }, + "QA": { + "leitsatz": "Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.", + "uebernehmen": [ + "Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.", + "Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab." + ], + "vermeiden": [ + "archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.", + "archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional." + ] + } + }, + "tickets": [ + { + "code": "ARC-01", + "title": "Objekt-Speicher-Anbindung für Mails/Anhänge", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, S3-kompatibles Objektspeicher-API", + "description": "Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.", + "dependsOn": [ + "ING-04" + ], + "akzeptanz": [ + "Mails und Anhänge werden nach fester, dokumentierter Pfadkonvention abgelegt", + "Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert", + "Lesezugriff ist unabhängig vom ursprünglichen Importpfad möglich", + "Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet" + ], + "pruefungen": [ + "Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt", + "Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt", + "Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz", + "Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 2, + "unlocks": [ + "ARC-02", + "ARC-03", + "ARC-04", + "ARC-05", + "ARC-06", + "ARC-07", + "INT-01", + "SRC-01", + "SRC-07", + "UX-03", + "ARC-09", + "ARC-10", + "INT-08", + "INT-09", + "INT-10", + "INT-12" + ], + "prompt": "# ARC-01 – Objekt-Speicher-Anbindung für Mails/Anhänge\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAnbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.\n\n**Technische Grundlage:** Go, S3-kompatibles Objektspeicher-API\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-04 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.\n\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `LIC-05` Speicherverbrauch-Metrik je Tenant.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Mails und Anhänge werden nach fester, dokumentierter Pfadkonvention abgelegt\n2. Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert\n3. Lesezugriff ist unabhängig vom ursprünglichen Importpfad möglich\n4. Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt\n2. Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt\n3. Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz\n4. Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe\n\n## Bekannte Fehler vermeiden\n- **Verarbeitungsreihenfolge nach Empfang**: Hash-Berechnung & Duplikatsprüfung (ARC-03) zuerst, danach erst Verschlüsselung (ARC-02) für neue/bewusste Duplikate, danach OCR (SRC-07) und Indexierung (SRC-01/SRC-02) — niemals umgekehrt.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ARC-02` Verschlüsselung at rest\n- `ARC-03` Dublettenerkennung E-Mail\n- `ARC-04` Aufbewahrungsstruktur (Mandant/Postfach/Jahr)\n- `ARC-05` Papierkorb & Soft-Delete für Mails\n- `ARC-06` Mandantentrennung im Speicherpfad\n- `ARC-07` Export/Portabilität (offenes Format)\n- `INT-01` REST-API v1 für Mail-Zugriff\n- `SRC-01` Manticore-Suchindex für Mails\n- `SRC-07` OCR für Anhänge\n- `UX-03` Anhang-Vorschau\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-01: objekt-speicher-anbindung-fuer-mails-anhaenge`\n- Branch: `feature/arc-01-objekt-speicher-anbindung-fuer-mails-anhaenge`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-02", + "title": "Verschlüsselung at rest", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, AES-256-GCM", + "description": "Verschlüsselung archivierter Mails/Anhänge at rest einführen. Der Master-Key (KEK) wird über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Alle archivierten Inhalte sind at rest verschlüsselt abgelegt", + "Der Master-Key (KEK) wird über Core API-10 bezogen, Schlüsselmaterial ist getrennt vom Datenspeicher verwaltet und nicht im Code", + "Entschlüsselung ist nur mit gültigem, mandantenbezogenem Schlüssel möglich" + ], + "pruefungen": [ + "Test: Zugriff auf Rohspeicher ohne Schlüssel liefert keine lesbaren Inhalte", + "Test: falscher Mandantenschlüssel verweigert Entschlüsselung", + "Performance-Test bestätigt akzeptablen Overhead durch Verschlüsselung" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "ARC-08" + ], + "prompt": "# ARC-02 – Verschlüsselung at rest\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerschlüsselung archivierter Mails/Anhänge at rest einführen. Der Master-Key (KEK) wird über Core `API-10` (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst.\n\n**Technische Grundlage:** Go, AES-256-GCM\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Verschlüsselung archivierter Mails/Anhänge at rest einführen, mit sicherer Schlüsselverwaltung getrennt von den verschlüsselten Daten.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.\n\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-10` Master-Key-Verwaltung & -Rotation (KMS-Anbindung).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle archivierten Inhalte sind at rest verschlüsselt abgelegt\n2. Der Master-Key (KEK) wird über Core `API-10` bezogen, Schlüsselmaterial ist getrennt vom Datenspeicher verwaltet und nicht im Code\n3. Entschlüsselung ist nur mit gültigem, mandantenbezogenem Schlüssel möglich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Zugriff auf Rohspeicher ohne Schlüssel liefert keine lesbaren Inhalte\n2. Test: falscher Mandantenschlüssel verweigert Entschlüsselung\n3. Performance-Test bestätigt akzeptablen Overhead durch Verschlüsselung\n\n## Bekannte Fehler vermeiden\nReihenfolge beachten: SHA-256-Hash für Dublettenerkennung (ARC-03) wird auf dem Klartext berechnet, bevor diese Verschlüsselung angewendet wird — nicht danach.\n\nMaster-Key-Verwaltung wurde ursprünglich unabhängig in DMS und Mail geplant — Duplikat im sicherheitskritischsten Bereich. Der Master-Key kommt jetzt zentral aus Core API-10, nur die Objekt-Verschlüsselung selbst bleibt hier.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ARC-08` Verschlüsselungsschlüssel-Rotation\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-02: verschluesselung-at-rest`\n- Branch: `feature/arc-02-verschluesselung-at-rest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-03", + "title": "Dublettenerkennung E-Mail", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Hashing (SHA-256)", + "description": "Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Identische Nachrichten werden über Inhalts-Hash zuverlässig als Duplikat erkannt", + "Duplikate werden referenziert statt redundant gespeichert oder klar markiert", + "Erkennung funktioniert mandantenübergreifend korrekt getrennt" + ], + "pruefungen": [ + "Test: dieselbe Nachricht aus zwei Quellen wird als Duplikat erkannt", + "Test: zwei Mandanten mit identischem Mailinhalt werden nicht fälschlich verknüpft", + "Test mit knapp unterschiedlichen Nachrichten bestätigt korrekte Nicht-Erkennung" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "SRC-01", + "SRC-02", + "SRC-07" + ], + "prompt": "# ARC-03 – Dublettenerkennung E-Mail\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nDublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.\n\n**Technische Grundlage:** Go, Hashing (SHA-256)\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Identische Nachrichten werden über Inhalts-Hash zuverlässig als Duplikat erkannt\n2. Duplikate werden referenziert statt redundant gespeichert oder klar markiert\n3. Erkennung funktioniert mandantenübergreifend korrekt getrennt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: dieselbe Nachricht aus zwei Quellen wird als Duplikat erkannt\n2. Test: zwei Mandanten mit identischem Mailinhalt werden nicht fälschlich verknüpft\n3. Test mit knapp unterschiedlichen Nachrichten bestätigt korrekte Nicht-Erkennung\n\n## Bekannte Fehler vermeiden\nHash muss auf dem Klartext berechnet werden, nicht auf dem verschlüsselten Objekt (siehe ARC-02) — sonst erzeugt dieselbe Mail bei jedem Import einen anderen Hash und Dublettenerkennung versagt vollständig. Reihenfolge: Mail/Anhang empfangen → SHA-256 auf Klartext (dieses Ticket) → verschlüsseln (ARC-02) → Chiffretext ablegen.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-03: dublettenerkennung-e-mail`\n- Branch: `feature/arc-03-dublettenerkennung-e-mail`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-04", + "title": "Aufbewahrungsstruktur (Mandant/Postfach/Jahr)", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Objektspeicher-Pfadkonvention", + "description": "Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Ablagestruktur folgt durchgängig dem Schema Mandant/Postfach/Jahr", + "Struktur ist Grundlage für spätere Retention-Regeln ohne Migration", + "Abweichende oder fehlende Metadaten führen zu definiertem Fallback-Pfad, nicht zu Ablagefehler" + ], + "pruefungen": [ + "Test: Import über mehrere Jahre erzeugt korrekt getrennte Jahresordner", + "Test: fehlendes Postfach-Attribut nutzt dokumentierten Fallback", + "Stichprobenprüfung der Struktur durch zweite Person" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# ARC-04 – Aufbewahrungsstruktur (Mandant/Postfach/Jahr)\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.\n\n**Technische Grundlage:** Go, Objektspeicher-Pfadkonvention\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Ablagestruktur folgt durchgängig dem Schema Mandant/Postfach/Jahr\n2. Struktur ist Grundlage für spätere Retention-Regeln ohne Migration\n3. Abweichende oder fehlende Metadaten führen zu definiertem Fallback-Pfad, nicht zu Ablagefehler\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Import über mehrere Jahre erzeugt korrekt getrennte Jahresordner\n2. Test: fehlendes Postfach-Attribut nutzt dokumentierten Fallback\n3. Stichprobenprüfung der Struktur durch zweite Person\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-04: aufbewahrungsstruktur-mandant-postfach-jahr`\n- Branch: `feature/arc-04-aufbewahrungsstruktur-mandant-postfach-jahr`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-05", + "title": "Papierkorb & Soft-Delete für Mails", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Postgres (Soft-Delete-Flag)", + "description": "Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.", + "dependsOn": [ + "ARC-01", + "RET-03" + ], + "akzeptanz": [ + "Gelöschte Mails bleiben innerhalb der Frist wiederherstellbar", + "Endgültige Löschung nach Fristablauf ist nachvollziehbar protokolliert", + "Soft-Delete respektiert bestehende Aufbewahrungssperren (Litigation Hold)" + ], + "pruefungen": [ + "Test: Wiederherstellung innerhalb der Frist liefert unveränderten Inhalt", + "Test: Mail mit aktiver Aufbewahrungssperre kann nicht endgültig gelöscht werden", + "Test: Fristablauf löst automatische endgültige Löschung aus" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# ARC-05 – Papierkorb & Soft-Delete für Mails\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPapierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.\n\n**Technische Grundlage:** Go, Postgres (Soft-Delete-Flag)\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.\n\n## Ausgangslage\nSetzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-03` Löschworkflow & Aufbewahrungssperre (Legal Hold) – gegen diese Sperre wird vor jeder Soft-Delete-/Endlöschung geprüft.\n\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Gelöschte Mails bleiben innerhalb der Frist wiederherstellbar\n2. Endgültige Löschung nach Fristablauf ist nachvollziehbar protokolliert\n3. Soft-Delete respektiert bestehende Aufbewahrungssperren (Litigation Hold)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Wiederherstellung innerhalb der Frist liefert unveränderten Inhalt\n2. Test: Mail mit aktiver Aufbewahrungssperre kann nicht endgültig gelöscht werden\n3. Test: Fristablauf löst automatische endgültige Löschung aus\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-05: papierkorb-soft-delete-fuer-mails`\n- Branch: `feature/arc-05-papierkorb-soft-delete-fuer-mails`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-06", + "title": "Mandantentrennung im Objekt-Storage", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, ein Bucket/Pfad-Root pro Mandant", + "description": "Physische Mandantentrennung im Objekt-Storage durchsetzen — jeder Mandant hat einen eigenen Bucket/Pfad-Root (angelegt im selben Provisioning-Schritt wie die Tenant-Datenbank, siehe Core TEN-01), keine gemeinsame Ablage mit Pfad-Präfix mehr.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Jeder Mandant hat einen eigenen, physisch getrennten Bucket/Pfad-Root im Objektspeicher", + "Ein Zugriffsversuch ohne oder mit falschem Tenant-Kontext kann technisch kein fremdes Bucket erreichen, nicht nur einen falschen Pfad", + "Bucket-Provisionierung ist Teil desselben automatisierten Schritts wie die Tenant-Datenbank-Anlage (Core TEN-01), keine manuelle Zusatzaktion nötig" + ], + "pruefungen": [ + "Test bestätigt physische Bucket-Trennung zweier Mandanten", + "Simulierter Zugriffsversuch ohne Tenant-Kontext schlägt fehl, weil kein Bucket referenzierbar ist, nicht weil ein Pfadfilter greift", + "Provisionierungs-Test legt für einen neuen Mandanten Datenbank UND Bucket in einem Schritt an" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "QA-04" + ], + "prompt": "# ARC-06 – Mandantentrennung im Objekt-Storage\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPhysische Mandantentrennung im Objekt-Storage durchsetzen — jeder Mandant hat einen eigenen Bucket/Pfad-Root (angelegt im selben Provisioning-Schritt wie die Tenant-Datenbank, siehe Core TEN-01), keine gemeinsame Ablage mit Pfad-Präfix mehr.\n\n**Technische Grundlage:** Go, ein Bucket/Pfad-Root pro Mandant\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n- Ein gemeinsamer Bucket mit Pfad-Präfix verlässt sich wie eine gemeinsame Datenbank mit tenant_id-Filter darauf, dass jeder Zugriff korrekt geprüft wird — ein vergessener Filter/Präfix-Check führt zum Cross-Tenant-Leck. Physische Bucket-Trennung macht das strukturell unmöglich, aus demselben Grund wie bei Core TEN-01.\n\n**Für genau diese Kachel:** Physische Mandantentrennung im Objekt-Storage durchsetzen — eigener Bucket/Pfad-Root je Mandant statt gemeinsamer Ablage mit Pfad-Präfix.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md. Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `TEN-01` Tenant-Registry & Datenbank-Provisioning (Bucket-Provisionierung ergänzt denselben Schritt).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Mandant hat einen eigenen, physisch getrennten Bucket/Pfad-Root im Objektspeicher\n2. Ein Zugriffsversuch ohne oder mit falschem Tenant-Kontext kann technisch kein fremdes Bucket erreichen, nicht nur einen falschen Pfad\n3. Bucket-Provisionierung ist Teil desselben automatisierten Schritts wie die Tenant-Datenbank-Anlage (Core TEN-01), keine manuelle Zusatzaktion nötig\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test bestätigt physische Bucket-Trennung zweier Mandanten\n2. Simulierter Zugriffsversuch ohne Tenant-Kontext schlägt fehl, weil kein Bucket referenzierbar ist, nicht weil ein Pfadfilter greift\n3. Provisionierungs-Test legt für einen neuen Mandanten Datenbank UND Bucket in einem Schritt an\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-04` Sicherheits- & Berechtigungsprüfung\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-06: mandantentrennung-im-speicherpfad`\n- Branch: `feature/arc-06-mandantentrennung-im-speicherpfad`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-07", + "title": "Export/Portabilität (offenes Format)", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, mbox/eml-Export", + "description": "Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Export erzeugt vollständige, standardkonforme mbox- oder eml-Dateien", + "Anhänge bleiben im Export erhalten und sind referenziell konsistent", + "Export ist mandantenweise abgrenzbar und nachvollziehbar protokolliert" + ], + "pruefungen": [ + "Test: exportierte Datei lässt sich mit gängigem Mail-Client importieren", + "Test: Export enthält keine Daten anderer Mandanten", + "Stichprobenvergleich Original vs. Export bestätigt Inhaltstreue" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# ARC-07 – Export/Portabilität (offenes Format)\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nExport archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.\n\n**Technische Grundlage:** Go, mbox/eml-Export\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Export erzeugt vollständige, standardkonforme mbox- oder eml-Dateien\n2. Anhänge bleiben im Export erhalten und sind referenziell konsistent\n3. Export ist mandantenweise abgrenzbar und nachvollziehbar protokolliert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: exportierte Datei lässt sich mit gängigem Mail-Client importieren\n2. Test: Export enthält keine Daten anderer Mandanten\n3. Stichprobenvergleich Original vs. Export bestätigt Inhaltstreue\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-07: export-portabilitaet-offenes-format`\n- Branch: `feature/arc-07-export-portabilitaet-offenes-format`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-08", + "title": "Verschlüsselungsschlüssel-Rotation", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Envelope-Encryption", + "description": "Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).", + "dependsOn": [ + "ARC-02" + ], + "akzeptanz": [ + "Neue Datenschlüssel werden über einen Hauptschlüssel gewrappt und rotierbar verwaltet", + "Rotation des Hauptschlüssels erfordert kein Neuverschlüsseln des gesamten Archivbestands", + "Alte Schlüsselversionen bleiben für Lesezugriff auf Altbestand kontrolliert verfügbar" + ], + "pruefungen": [ + "Test: Rotation des Hauptschlüssels lässt Altbestand weiterhin lesbar", + "Test: kompromittierter alter Schlüssel kann gezielt gesperrt werden", + "Dokumentierter Rotationsvorgang wurde einmal vollständig durchgespielt" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 4, + "unlocks": [ + "QA-03" + ], + "prompt": "# ARC-08 – Verschlüsselungsschlüssel-Rotation\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nRotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).\n\n**Technische Grundlage:** Go, Envelope-Encryption\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.\n\n**Bewusst vermeiden:**\n- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.\n\n**Für genau diese Kachel:** Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-02 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Neue Datenschlüssel werden über einen Hauptschlüssel gewrappt und rotierbar verwaltet\n2. Rotation des Hauptschlüssels erfordert kein Neuverschlüsseln des gesamten Archivbestands\n3. Alte Schlüsselversionen bleiben für Lesezugriff auf Altbestand kontrolliert verfügbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Rotation des Hauptschlüssels lässt Altbestand weiterhin lesbar\n2. Test: kompromittierter alter Schlüssel kann gezielt gesperrt werden\n3. Dokumentierter Rotationsvorgang wurde einmal vollständig durchgespielt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate Archivierung & Suche\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-08: verschluesselungsschluessel-rotation`\n- Branch: `feature/arc-08-verschluesselungsschluessel-rotation`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-01", + "title": "IMAP-Postfach-Abruf & Scheduler", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Postgres-Jobqueue, IMAP4rev1", + "description": "Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.", + "dependsOn": [ + "ING-01", + "ING-05" + ], + "akzeptanz": [ + "Scheduler erkennt neue Nachrichten seit letztem Abruf zuverlässig über UID-Vergleich", + "Zustandsänderungen (gelesen/gelöscht) werden ohne Doppelimport übernommen", + "Abrufintervall ist je Postfach konfigurierbar und übersteht Neustarts des Dienstes" + ], + "pruefungen": [ + "Test: zwei aufeinanderfolgende Läufe importieren keine Nachricht doppelt", + "Test: simulierter Dienst-Neustart mitten im Abgleich führt zu konsistentem Endzustand", + "Test gegen Testpostfach mit realistischem Nachrichtenaufkommen" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 3, + "unlocks": [ + "IMP-02", + "IMP-03", + "IMP-04", + "IMP-05", + "IMP-07", + "IMP-08", + "IMP-09", + "INT-05", + "UX-01" + ], + "prompt": "# IMP-01 – IMAP-Postfach-Abruf & Scheduler\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nScheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.\n\n**Technische Grundlage:** Go, Postgres-Jobqueue, IMAP4rev1\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-05 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Scheduler erkennt neue Nachrichten seit letztem Abruf zuverlässig über UID-Vergleich\n2. Zustandsänderungen (gelesen/gelöscht) werden ohne Doppelimport übernommen\n3. Abrufintervall ist je Postfach konfigurierbar und übersteht Neustarts des Dienstes\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: zwei aufeinanderfolgende Läufe importieren keine Nachricht doppelt\n2. Test: simulierter Dienst-Neustart mitten im Abgleich führt zu konsistentem Endzustand\n3. Test gegen Testpostfach mit realistischem Nachrichtenaufkommen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-02` Anhangsverarbeitung bei Import\n- `IMP-03` E-Mail-Regeln (Zuordnung/Tags/Klassifizierung)\n- `IMP-04` Fehlerbehandlung nicht-konformer Server\n- `IMP-05` Hot-Folder/Scanner-Anbindung\n- `IMP-07` Mehrfach-Postfach-Verwaltung pro Tenant\n- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall\n- `IMP-09` Import-Testsuite\n- `INT-05` Benachrichtigungs-Service \"neue Mail\"\n- `UX-01` Postfach- & Ordneransicht\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-01: imap-postfach-abruf-scheduler`\n- Branch: `feature/imp-01-imap-postfach-abruf-scheduler`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-02", + "title": "Anhangsverarbeitung bei Import", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, mime/multipart", + "description": "Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.", + "dependsOn": [ + "ING-04", + "IMP-01" + ], + "akzeptanz": [ + "Anhänge werden mit Originaldateiname, Größe und geprüftem Content-Type extrahiert", + "Größenlimit pro Anhang und pro Nachricht wird durchgesetzt", + "Fehlerhafte Anhänge blockieren nicht den Import der restlichen Nachricht" + ], + "pruefungen": [ + "Test mit Nachricht, die einen überdimensionierten Anhang enthält, wird korrekt begrenzt", + "Test mit mehreren Anhängen unterschiedlichen Typs importiert alle korrekt", + "Test: ein defekter Anhang lässt Text und übrige Anhänge unangetastet" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 4, + "unlocks": [ + "IMP-06", + "IMP-09" + ], + "prompt": "# IMP-02 – Anhangsverarbeitung bei Import\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAnhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.\n\n**Technische Grundlage:** Go, mime/multipart\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-04, IMP-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (MIME-/Charset-Parsing mit Tests), siehe repos-analyse-mail-reuse.md. Speicherbomben-Risiko beim Anhang-Lesen muss vor Übernahme behoben werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Anhänge werden mit Originaldateiname, Größe und geprüftem Content-Type extrahiert\n2. Größenlimit pro Anhang und pro Nachricht wird durchgesetzt\n3. Fehlerhafte Anhänge blockieren nicht den Import der restlichen Nachricht\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit Nachricht, die einen überdimensionierten Anhang enthält, wird korrekt begrenzt\n2. Test mit mehreren Anhängen unterschiedlichen Typs importiert alle korrekt\n3. Test: ein defekter Anhang lässt Text und übrige Anhänge unangetastet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-06` Anhangs-Virenscan-Anbindung\n- `IMP-09` Import-Testsuite\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-02: anhangsverarbeitung-bei-import`\n- Branch: `feature/imp-02-anhangsverarbeitung-bei-import`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-03", + "title": "E-Mail-Regeln (Zuordnung/Tags/Klassifizierung)", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Postgres", + "description": "Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.", + "dependsOn": [ + "IMP-01" + ], + "akzeptanz": [ + "Regeln lassen sich nach Absender, Betreff-Muster und Postfach definieren", + "Mehrere zutreffende Regeln werden nach dokumentierter Priorität angewendet", + "Regeländerungen wirken nur auf künftige Importe, nicht rückwirkend ohne expliziten Reindex-Auftrag" + ], + "pruefungen": [ + "Test mit widersprüchlichen Regeln bestätigt dokumentierte Priorisierung", + "Test: neue Regel ändert keine bereits importierten Altbestände automatisch", + "Regelset mit 20+ Regeln bleibt performant auswertbar" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 4, + "unlocks": [ + "IMP-09", + "INT-06" + ], + "prompt": "# IMP-03 – E-Mail-Regeln (Zuordnung/Tags/Klassifizierung)\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nRegelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.\n\n**Technische Grundlage:** Go, Postgres\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Regeln lassen sich nach Absender, Betreff-Muster und Postfach definieren\n2. Mehrere zutreffende Regeln werden nach dokumentierter Priorität angewendet\n3. Regeländerungen wirken nur auf künftige Importe, nicht rückwirkend ohne expliziten Reindex-Auftrag\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit widersprüchlichen Regeln bestätigt dokumentierte Priorisierung\n2. Test: neue Regel ändert keine bereits importierten Altbestände automatisch\n3. Regelset mit 20+ Regeln bleibt performant auswertbar\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-09` Import-Testsuite\n- `INT-06` E-Mail-Regel-Engine über API steuerbar\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-03: e-mail-regeln-zuordnung-tags-klassifizierung`\n- Branch: `feature/imp-03-e-mail-regeln-zuordnung-tags-klassifizierung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-04", + "title": "Fehlerbehandlung nicht-konformer Server", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, IMAP4rev1", + "description": "Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.", + "dependsOn": [ + "IMP-01" + ], + "akzeptanz": [ + "Bekannte Abweichungen (u. a. UIDVALIDITY=0) führen zu definiertem Fallback statt Sync-Abbruch", + "Unerwartete Serverantworten werden geloggt und übersprungen statt den gesamten Lauf zu stoppen", + "Fallback-Verhalten ist dokumentiert und für Support nachvollziehbar" + ], + "pruefungen": [ + "Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback", + "Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten", + "Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 4, + "unlocks": [ + "IMP-08", + "QA-02" + ], + "prompt": "# IMP-04 – Fehlerbehandlung nicht-konformer Server\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nDefensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.\n\n**Technische Grundlage:** Go, IMAP4rev1\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Bekannte Abweichungen (u. a. UIDVALIDITY=0) führen zu definiertem Fallback statt Sync-Abbruch\n2. Unerwartete Serverantworten werden geloggt und übersprungen statt den gesamten Lauf zu stoppen\n3. Fallback-Verhalten ist dokumentiert und für Support nachvollziehbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback\n2. Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten\n3. Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #5: In einer früheren Implementierung führte `UIDVALIDITY=0` bei nicht-konformen Servern zu einem Resync-Abbruch. Für diese Kachel verbindlich: defensive Validierung von UIDVALIDITY/UIDNEXT mit dokumentiertem Fallback-Pfad, dazu ein Regressionstest, der genau dieses Szenario abdeckt.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-04: fehlerbehandlung-nicht-konformer-server`\n- Branch: `feature/imp-04-fehlerbehandlung-nicht-konformer-server`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-05", + "title": "Hot-Folder/Scanner-Anbindung", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, fsnotify", + "description": "Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.", + "dependsOn": [ + "IMP-01" + ], + "akzeptanz": [ + "Dateien in konfiguriertem Hot-Folder werden erkannt und dem richtigen Mandanten/Postfach zugeordnet", + "Bereits verarbeitete Dateien werden nicht doppelt importiert", + "Fehlerhafte Dateien werden in einen Fehlerordner verschoben statt den Scan-Lauf zu blockieren" + ], + "pruefungen": [ + "Test: gleiche Datei zweimal abgelegt wird nur einmal importiert", + "Test: fehlerhafte Datei landet nachvollziehbar im Fehlerordner", + "Dauertest über mehrere Scan-Zyklen ohne Ressourcenleck" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 4, + "unlocks": [ + "QA-02" + ], + "prompt": "# IMP-05 – Hot-Folder/Scanner-Anbindung\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAnbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.\n\n**Technische Grundlage:** Go, fsnotify\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Dateien in konfiguriertem Hot-Folder werden erkannt und dem richtigen Mandanten/Postfach zugeordnet\n2. Bereits verarbeitete Dateien werden nicht doppelt importiert\n3. Fehlerhafte Dateien werden in einen Fehlerordner verschoben statt den Scan-Lauf zu blockieren\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: gleiche Datei zweimal abgelegt wird nur einmal importiert\n2. Test: fehlerhafte Datei landet nachvollziehbar im Fehlerordner\n3. Dauertest über mehrere Scan-Zyklen ohne Ressourcenleck\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-05: hot-folder-scanner-anbindung`\n- Branch: `feature/imp-05-hot-folder-scanner-anbindung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-06", + "title": "Anhangs-Virenscan-Anbindung", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, ClamAV-kompatible Anbindung", + "description": "Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.", + "dependsOn": [ + "IMP-02" + ], + "akzeptanz": [ + "Jeder importierte Anhang wird vor Archivierung durch den Virenscanner geprüft", + "Positiver Fund führt zu Quarantäne des Anhangs statt automatischer Archivierung", + "Scanner-Ausfall blockiert den Import nicht unbegrenzt, sondern führt zu definiertem Fehlerzustand" + ], + "pruefungen": [ + "Test mit EICAR-Testdatei bestätigt Quarantäne-Verhalten", + "Test: Scanner nicht erreichbar führt zu klar sichtbarem Fehlerzustand statt Hänger", + "Durchsatztest bestätigt akzeptable Verzögerung durch Scan-Schritt" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 5, + "unlocks": [ + "QA-02" + ], + "prompt": "# IMP-06 – Anhangs-Virenscan-Anbindung\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAnbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.\n\n**Technische Grundlage:** Go, ClamAV-kompatible Anbindung\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-02 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder importierte Anhang wird vor Archivierung durch den Virenscanner geprüft\n2. Positiver Fund führt zu Quarantäne des Anhangs statt automatischer Archivierung\n3. Scanner-Ausfall blockiert den Import nicht unbegrenzt, sondern führt zu definiertem Fehlerzustand\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit EICAR-Testdatei bestätigt Quarantäne-Verhalten\n2. Test: Scanner nicht erreichbar führt zu klar sichtbarem Fehlerzustand statt Hänger\n3. Durchsatztest bestätigt akzeptable Verzögerung durch Scan-Schritt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-06: anhangs-virenscan-anbindung`\n- Branch: `feature/imp-06-anhangs-virenscan-anbindung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-07", + "title": "Mehrfach-Postfach-Verwaltung pro Tenant", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Postgres, tenant_id", + "description": "Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.", + "dependsOn": [ + "IMP-01" + ], + "akzeptanz": [ + "Ein Mandant kann mehrere Postfächer unabhängig voneinander konfigurieren", + "Jedes Postfach hat eigene Abrufparameter (Intervall, Zugangsdaten, Ordnerauswahl)", + "Postfach-Liste ist strikt nach tenant_id gefiltert" + ], + "pruefungen": [ + "Test: zwei Mandanten mit je mehreren Postfächern sehen ausschließlich eigene Postfächer", + "Test: Löschen eines Postfachs beeinträchtigt andere Postfächer desselben Mandanten nicht", + "Konfigurationsänderung an einem Postfach wirkt nicht auf andere" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 4, + "unlocks": [ + "ARC-09", + "QA-02" + ], + "prompt": "# IMP-07 – Mehrfach-Postfach-Verwaltung pro Tenant\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.\n\n**Technische Grundlage:** Go, Postgres, tenant_id\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Setzt voraus: NEXARCH-Core TEN-01/TEN-02 (Tenant-Datenmodell & Onboarding) aus core-kanban/ sind verfügbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Ein Mandant kann mehrere Postfächer unabhängig voneinander konfigurieren\n2. Jedes Postfach hat eigene Abrufparameter (Intervall, Zugangsdaten, Ordnerauswahl)\n3. Postfach-Liste ist strikt nach tenant_id gefiltert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: zwei Mandanten mit je mehreren Postfächern sehen ausschließlich eigene Postfächer\n2. Test: Löschen eines Postfachs beeinträchtigt andere Postfächer desselben Mandanten nicht\n3. Konfigurationsänderung an einem Postfach wirkt nicht auf andere\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-07: mehrfach-postfach-verwaltung-pro-tenant`\n- Branch: `feature/imp-07-mehrfach-postfach-verwaltung-pro-tenant`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-08", + "title": "Fehler-Benachrichtigung bei Postfach-Sync-Ausfall", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)", + "description": "Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.", + "dependsOn": [ + "IMP-01", + "IMP-04" + ], + "akzeptanz": [ + "Wiederholte Sync-Fehlschläge über konfigurierbarer Schwelle lösen genau ein Ereignis an Core CFG-02 aus, nicht selbst versendet", + "Benachrichtigung enthält Postfach, Fehlerursache und Zeitpunkt des letzten erfolgreichen Abrufs", + "Erfolgreicher Sync nach Ausfall setzt den Alarmzustand zurück" + ], + "pruefungen": [ + "Test: N aufeinanderfolgende Fehlschläge lösen genau eine Benachrichtigung aus, keine Spam-Flut", + "Test: erfolgreicher Lauf nach Ausfall beendet den Alarmzustand nachvollziehbar", + "Test mit mehreren betroffenen Postfächern gleichzeitig bleibt übersichtlich" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 5, + "unlocks": [ + "QA-02" + ], + "prompt": "# IMP-08 – Fehler-Benachrichtigung bei Postfach-Sync-Ausfall\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nBenachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.\n\n**Technische Grundlage:** Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch.\n\n## Ausgangslage\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher – zentraler Versandweg für alle Module, kein eigener E-Mail-Versand je Modul.\n\nSetzt innerhalb dieses Boards voraus: IMP-01, IMP-04 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Wiederholte Sync-Fehlschläge über konfigurierbarer Schwelle lösen genau ein Ereignis an Core CFG-02 aus, nicht selbst versendet\n2. Benachrichtigung enthält Postfach, Fehlerursache und Zeitpunkt des letzten erfolgreichen Abrufs\n3. Erfolgreicher Sync nach Ausfall setzt den Alarmzustand zurück\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: N aufeinanderfolgende Fehlschläge lösen genau eine Benachrichtigung aus, keine Spam-Flut\n2. Test: erfolgreicher Lauf nach Ausfall beendet den Alarmzustand nachvollziehbar\n3. Test mit mehreren betroffenen Postfächern gleichzeitig bleibt übersichtlich\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-08: fehler-benachrichtigung-bei-postfach-sync-ausfall`\n- Branch: `feature/imp-08-fehler-benachrichtigung-bei-postfach-sync-ausfall`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "IMP-09", + "title": "Import-Testsuite", + "epic": "IMP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go testing, testify", + "description": "Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.", + "dependsOn": [ + "IMP-01", + "IMP-02", + "IMP-03" + ], + "akzeptanz": [ + "Jeder Importpfad hat automatisierte Tests für Normal- und Fehlerfall", + "Tenant-Scoping ist für Postfach-Abruf und Regelanwendung durch eigene Tests abgedeckt", + "Testsuite läuft reproduzierbar in CI ohne echte externe Postfächer" + ], + "pruefungen": [ + "Testabdeckungsbericht für Scheduler, Anhangsverarbeitung und Regeln liegt vor", + "CI-Lauf grün auf frischem Checkout", + "Stichprobenreview bestätigt sinnvolle Testfälle für nicht-konforme Server-Szenarien" + ], + "status": "Fertig", + "epicName": "Postfach-Import & Synchronisierung", + "epicEmoji": "🔄", + "wave": 5, + "unlocks": [ + "QA-02" + ], + "prompt": "# IMP-09 – Import-Testsuite\n\n**Epic:** 🔄 Postfach-Import & Synchronisierung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nTestsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.\n\n**Technische Grundlage:** Go testing, testify\n\n## Produkt-DNA für diesen Bereich\n> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.\n\n**Übernehmen:**\n- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.\n- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.\n\n**Bewusst vermeiden:**\n- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.\n- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.\n\n**Für genau diese Kachel:** Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01, IMP-02, IMP-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Importpfad hat automatisierte Tests für Normal- und Fehlerfall\n2. Tenant-Scoping ist für Postfach-Abruf und Regelanwendung durch eigene Tests abgedeckt\n3. Testsuite läuft reproduzierbar in CI ohne echte externe Postfächer\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testabdeckungsbericht für Scheduler, Anhangsverarbeitung und Regeln liegt vor\n2. CI-Lauf grün auf frischem Checkout\n3. Stichprobenreview bestätigt sinnvolle Testfälle für nicht-konforme Server-Szenarien\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #4: In einer früheren Implementierung waren Import-nahe Module praktisch ungetestet. Für diese Kachel verbindlich: Pflichttests für Tenant-Scoping und Protokoll-/Import-Zustandsmaschinen sind Abnahmevoraussetzung, kein Nachziehen nach Feature-Fertigstellung.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Ingestion & Import\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `IMP-09: import-testsuite`\n- Branch: `feature/imp-09-import-testsuite`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-01", + "title": "IMAP-Server-Grundgerüst", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Komplex", + "estimateDays": 4, + "tech": "Go/net, IMAP4rev1 (RFC 3501)", + "description": "IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).", + "dependsOn": [], + "akzeptanz": [ + "Server nimmt IMAP-Verbindungen an und durchläuft die drei Standard-Zustände korrekt", + "Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT) sind implementiert und beantwortet", + "Ungültige Kommandosequenzen werden mit korrektem IMAP-Fehlercode abgelehnt, nicht mit Verbindungsabbruch" + ], + "pruefungen": [ + "Manuelle Session mit Standard-IMAP-Client durchgespielt und protokolliert", + "Automatisierter Test deckt alle drei Zustandsübergänge und deren verbotene Übergänge ab", + "Lasttest mit 50 parallelen Sessions ohne Ressourcenleck" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 1, + "unlocks": [ + "IMP-01", + "ING-02", + "ING-05", + "ING-06", + "ING-07", + "ING-08", + "ING-10", + "QA-07" + ], + "prompt": "# ING-01 – IMAP-Server-Grundgerüst\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nIMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).\n\n**Technische Grundlage:** Go/net, IMAP4rev1 (RFC 3501)\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).\n\n## Ausgangslage\nDiese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Server nimmt IMAP-Verbindungen an und durchläuft die drei Standard-Zustände korrekt\n2. Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT) sind implementiert und beantwortet\n3. Ungültige Kommandosequenzen werden mit korrektem IMAP-Fehlercode abgelehnt, nicht mit Verbindungsabbruch\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manuelle Session mit Standard-IMAP-Client durchgespielt und protokolliert\n2. Automatisierter Test deckt alle drei Zustandsübergänge und deren verbotene Übergänge ab\n3. Lasttest mit 50 parallelen Sessions ohne Ressourcenleck\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-01` IMAP-Postfach-Abruf & Scheduler\n- `ING-02` POP3-Server\n- `ING-05` Folder-State & UIDVALIDITY-Handling\n- `ING-06` TLS/STARTTLS-Absicherung\n- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung\n- `ING-08` Mailserver-Protokoll-Logging & Diagnose\n- `ING-10` Ingestion-Testsuite\n- `QA-07` Last- & Leistungstest\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-01: imap-server-grundgeruest`\n- Branch: `feature/ing-01-imap-server-grundgeruest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-02", + "title": "POP3-Server", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go/net, POP3 (RFC 1939)", + "description": "POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.", + "dependsOn": [ + "ING-01" + ], + "akzeptanz": [ + "Server durchläuft alle drei POP3-Zustände korrekt", + "RETR liefert vollständige Nachrichten, DELE markiert erst im Update-Zustand endgültig", + "Fehlerhafte Anmeldeversuche werden ohne Informationspreisgabe abgelehnt" + ], + "pruefungen": [ + "Automatisierter Test für jede Zustandsübergangs-Regel", + "Test mit Standard-POP3-Client (z. B. via Skript) gegen Test-Postfach", + "Test: DELE ohne anschließendes QUIT löscht nichts endgültig" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 2, + "unlocks": [ + "ING-06", + "ING-07", + "ING-08", + "ING-10", + "QA-07" + ], + "prompt": "# ING-02 – POP3-Server\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPOP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.\n\n**Technische Grundlage:** Go/net, POP3 (RFC 1939)\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (POP3-Server), siehe repos-analyse-mail-reuse.md. Bislang ungetestet – Testsuite ist Voraussetzung für Übernahme.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Server durchläuft alle drei POP3-Zustände korrekt\n2. RETR liefert vollständige Nachrichten, DELE markiert erst im Update-Zustand endgültig\n3. Fehlerhafte Anmeldeversuche werden ohne Informationspreisgabe abgelehnt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Automatisierter Test für jede Zustandsübergangs-Regel\n2. Test mit Standard-POP3-Client (z. B. via Skript) gegen Test-Postfach\n3. Test: DELE ohne anschließendes QUIT löscht nichts endgültig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ING-06` TLS/STARTTLS-Absicherung\n- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung\n- `ING-08` Mailserver-Protokoll-Logging & Diagnose\n- `ING-10` Ingestion-Testsuite\n- `QA-07` Last- & Leistungstest\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-02: pop3-server`\n- Branch: `feature/ing-02-pop3-server`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-03", + "title": "SMTP-Server & Mailer", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go/net/smtp, net/mail, SMTP (RFC 5321)", + "description": "SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).", + "dependsOn": [], + "akzeptanz": [ + "SMTP-Annahme validiert Envelope und Nachrichtengröße vor der Annahme", + "Mailer erzeugt Header ausschließlich über strukturierte Writer-API, keine freie Stringkonkatenation", + "Ungültige Empfängerdaten führen zu sauberer SMTP-Fehlermeldung statt Absturz" + ], + "pruefungen": [ + "Test mit Steuerzeichen/CRLF in Betreff und Anzeigenamen schlägt fehl bzw. wird bereinigt, kein Header-Bruch möglich", + "Automatisierter Test sendet Testmail über Mailpit/MailHog und prüft Header-Integrität", + "Lasttest mit gleichzeitigen Verbindungen ohne Verbindungsleck" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 1, + "unlocks": [ + "ING-06", + "ING-08", + "ING-09", + "ING-10", + "QA-04", + "QA-07", + "ING-11" + ], + "prompt": "# ING-03 – SMTP-Server & Mailer\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).\n\n**Technische Grundlage:** Go/net/smtp, net/mail, SMTP (RFC 5321)\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).\n\n## Ausgangslage\nDiese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (SMTP-Annahme, Mail-Templates), siehe repos-analyse-mail-reuse.md. Header-Injection-Bug muss vor Übernahme zwingend gefixt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. SMTP-Annahme validiert Envelope und Nachrichtengröße vor der Annahme\n2. Mailer erzeugt Header ausschließlich über strukturierte Writer-API, keine freie Stringkonkatenation\n3. Ungültige Empfängerdaten führen zu sauberer SMTP-Fehlermeldung statt Absturz\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit Steuerzeichen/CRLF in Betreff und Anzeigenamen schlägt fehl bzw. wird bereinigt, kein Header-Bruch möglich\n2. Automatisierter Test sendet Testmail über Mailpit/MailHog und prüft Header-Integrität\n3. Lasttest mit gleichzeitigen Verbindungen ohne Verbindungsleck\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #1: In einer früheren Implementierung wurden From/To/Subject-Header per Stringkonkatenation ohne CRLF-Validierung zusammengebaut – das öffnet Header-Injection. Für diese Kachel verbindlich: Ausgabe ausschließlich über `net/mail`-kompatiblen Writer erzeugen oder jeden Headerwert hart gegen CRLF/Steuerzeichen validieren, bevor er geschrieben wird. Kein Wiederaufgreifen des alten Konkatenationsmusters.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ING-06` TLS/STARTTLS-Absicherung\n- `ING-08` Mailserver-Protokoll-Logging & Diagnose\n- `ING-09` Rate-Limiting auf Protokollebene\n- `ING-10` Ingestion-Testsuite\n- `QA-04` Sicherheits- & Berechtigungsprüfung\n- `QA-07` Last- & Leistungstest\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-03: smtp-server-mailer`\n- Branch: `feature/ing-03-smtp-server-mailer`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-04", + "title": "MIME- & Anhang-Parsing", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, encoding/mime, mime/multipart", + "description": "MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.", + "dependsOn": [], + "akzeptanz": [ + "Multipart-Nachrichten mit verschachtelten Teilen werden vollständig zerlegt", + "Anhänge werden mit korrektem Dateinamen, Größe und Content-Type extrahiert", + "Fehlerhafte/inkonsistente Zeichensatzangaben werden defensiv repariert statt die Verarbeitung abzubrechen" + ], + "pruefungen": [ + "Test mit sehr großem simuliertem Anhang bestätigt harte Ablehnung statt Speicheranstieg", + "Testkorpus mit realitätsnahen Multipart-/Encoding-Varianten läuft fehlerfrei durch", + "Fuzz-/Grenzwerttest mit kaputten MIME-Strukturen bricht kontrolliert ab, kein Absturz" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 1, + "unlocks": [ + "ARC-01", + "IMP-02", + "ING-10", + "ARC-10" + ], + "prompt": "# ING-04 – MIME- & Anhang-Parsing\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.\n\n**Technische Grundlage:** Go, encoding/mime, mime/multipart\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.\n\n## Ausgangslage\nDiese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (MIME-/Charset-Parsing mit Tests), siehe repos-analyse-mail-reuse.md. Speicherbomben-Risiko beim Anhang-Lesen muss vor Übernahme behoben werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Multipart-Nachrichten mit verschachtelten Teilen werden vollständig zerlegt\n2. Anhänge werden mit korrektem Dateinamen, Größe und Content-Type extrahiert\n3. Fehlerhafte/inkonsistente Zeichensatzangaben werden defensiv repariert statt die Verarbeitung abzubrechen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit sehr großem simuliertem Anhang bestätigt harte Ablehnung statt Speicheranstieg\n2. Testkorpus mit realitätsnahen Multipart-/Encoding-Varianten läuft fehlerfrei durch\n3. Fuzz-/Grenzwerttest mit kaputten MIME-Strukturen bricht kontrolliert ab, kein Absturz\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #3: Eine frühere Implementierung las Anhänge über `io.ReadAll` ohne Größenlimit ein, was eine Speicherbombe durch große oder böswillig präparierte Anhänge ermöglicht. Für diese Kachel verbindlich: jeder Anhang-Lesevorgang läuft über `io.LimitReader` mit konfigurierter Max-Size, Überschreitung führt zu harter, sauberer Ablehnung statt stillem Abschneiden.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge\n- `IMP-02` Anhangsverarbeitung bei Import\n- `ING-10` Ingestion-Testsuite\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-04: mime-anhang-parsing`\n- Branch: `feature/ing-04-mime-anhang-parsing`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-05", + "title": "Folder-State & UIDVALIDITY-Handling", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, IMAP4rev1 (RFC 3501 §2.3.1.1)", + "description": "Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.", + "dependsOn": [ + "ING-01" + ], + "akzeptanz": [ + "Jeder Ordner führt UIDVALIDITY und UIDNEXT korrekt gemäß RFC nach", + "Ordnerwechsel (SELECT/EXAMINE) liefert konsistenten State auch bei parallelem Zugriff", + "State-Änderungen (neue Mail, Löschung) werden atomar und nachvollziehbar persistiert" + ], + "pruefungen": [ + "Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau", + "Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz", + "Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 2, + "unlocks": [ + "IMP-01", + "ING-10" + ], + "prompt": "# ING-05 – Folder-State & UIDVALIDITY-Handling\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFolder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.\n\n**Technische Grundlage:** Go, IMAP4rev1 (RFC 3501 §2.3.1.1)\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Ordner führt UIDVALIDITY und UIDNEXT korrekt gemäß RFC nach\n2. Ordnerwechsel (SELECT/EXAMINE) liefert konsistenten State auch bei parallelem Zugriff\n3. State-Änderungen (neue Mail, Löschung) werden atomar und nachvollziehbar persistiert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau\n2. Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz\n3. Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `IMP-01` IMAP-Postfach-Abruf & Scheduler\n- `ING-10` Ingestion-Testsuite\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-05: folder-state-uidvalidity-handling`\n- Branch: `feature/ing-05-folder-state-uidvalidity-handling`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-06", + "title": "TLS/STARTTLS-Absicherung", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go crypto/tls, STARTTLS", + "description": "TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.", + "dependsOn": [ + "ING-01", + "ING-02", + "ING-03" + ], + "akzeptanz": [ + "Anmeldedaten werden ausschließlich über TLS oder nach erfolgreichem STARTTLS akzeptiert", + "Schwache Cipher-Suiten und veraltete TLS-Versionen sind serverseitig deaktiviert", + "Zertifikatswechsel ist ohne Verbindungsabriss für bestehende Sessions möglich" + ], + "pruefungen": [ + "Scan mit Standard-TLS-Prüfwerkzeug bestätigt keine schwachen Suiten", + "Test: Login-Versuch ohne TLS/STARTTLS wird verweigert", + "Test: Zertifikatsrotation im laufenden Betrieb ohne Dienstunterbrechung" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 3, + "unlocks": [ + "QA-04" + ], + "prompt": "# ING-06 – TLS/STARTTLS-Absicherung\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nTLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.\n\n**Technische Grundlage:** Go crypto/tls, STARTTLS\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Setzt voraus: NEXARCH-Core-Zertifikats-/TLS-Konventionen aus core-kanban/ (siehe CFG-Epic) sind verfügbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Anmeldedaten werden ausschließlich über TLS oder nach erfolgreichem STARTTLS akzeptiert\n2. Schwache Cipher-Suiten und veraltete TLS-Versionen sind serverseitig deaktiviert\n3. Zertifikatswechsel ist ohne Verbindungsabriss für bestehende Sessions möglich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Scan mit Standard-TLS-Prüfwerkzeug bestätigt keine schwachen Suiten\n2. Test: Login-Versuch ohne TLS/STARTTLS wird verweigert\n3. Test: Zertifikatsrotation im laufenden Betrieb ohne Dienstunterbrechung\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-06: tls-starttls-absicherung`\n- Branch: `feature/ing-06-tls-starttls-absicherung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-07", + "title": "Protokoll-Fehlerbehandlung & Wiederverbindung", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, net, context", + "description": "Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.", + "dependsOn": [ + "ING-01", + "ING-02" + ], + "akzeptanz": [ + "Verbindungsabbrüche räumen serverseitige Session-Ressourcen zuverlässig auf", + "Timeouts sind pro Protokollphase konfigurierbar und greifen nachweislich", + "Wiederholte Fehlversuche eines Clients führen zu klar definiertem Backoff statt Dauerschleife" + ], + "pruefungen": [ + "Chaos-Test: Verbindung wird während aktiver Übertragung hart gekappt, kein Ressourcenleck danach", + "Test für Timeout-Auslösung in jeder Protokollphase", + "Test für Backoff-Verhalten bei wiederholten Fehlversuchen" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 3, + "unlocks": [ + "QA-02" + ], + "prompt": "# ING-07 – Protokoll-Fehlerbehandlung & Wiederverbindung\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nEinheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.\n\n**Technische Grundlage:** Go, net, context\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-02 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Verbindungsabbrüche räumen serverseitige Session-Ressourcen zuverlässig auf\n2. Timeouts sind pro Protokollphase konfigurierbar und greifen nachweislich\n3. Wiederholte Fehlversuche eines Clients führen zu klar definiertem Backoff statt Dauerschleife\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Chaos-Test: Verbindung wird während aktiver Übertragung hart gekappt, kein Ressourcenleck danach\n2. Test für Timeout-Auslösung in jeder Protokollphase\n3. Test für Backoff-Verhalten bei wiederholten Fehlversuchen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-07: protokoll-fehlerbehandlung-wiederverbindung`\n- Branch: `feature/ing-07-protokoll-fehlerbehandlung-wiederverbindung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-08", + "title": "Mailserver-Protokoll-Logging & Diagnose", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, structured logging (slog)", + "description": "Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.", + "dependsOn": [ + "ING-01", + "ING-02", + "ING-03" + ], + "akzeptanz": [ + "Jede Session erzeugt strukturierte Logs mit Korrelations-ID über die gesamte Verbindungsdauer", + "Zugangsdaten und Nachrichteninhalte erscheinen nie im Klartext im Log", + "Diagnosewerkzeug kann eine einzelne Session anhand der Korrelations-ID vollständig nachvollziehen" + ], + "pruefungen": [ + "Test bestätigt Redaktion sensibler Felder in allen Log-Pfaden", + "Stichprobe: eine komplette Session ist über die Korrelations-ID lückenlos rekonstruierbar", + "Lasttest bestätigt, dass Logging die Durchsatzrate nicht relevant beeinträchtigt" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 3, + "unlocks": [ + "QA-02" + ], + "prompt": "# ING-08 – Mailserver-Protokoll-Logging & Diagnose\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nStrukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.\n\n**Technische Grundlage:** Go, structured logging (slog)\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jede Session erzeugt strukturierte Logs mit Korrelations-ID über die gesamte Verbindungsdauer\n2. Zugangsdaten und Nachrichteninhalte erscheinen nie im Klartext im Log\n3. Diagnosewerkzeug kann eine einzelne Session anhand der Korrelations-ID vollständig nachvollziehen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test bestätigt Redaktion sensibler Felder in allen Log-Pfaden\n2. Stichprobe: eine komplette Session ist über die Korrelations-ID lückenlos rekonstruierbar\n3. Lasttest bestätigt, dass Logging die Durchsatzrate nicht relevant beeinträchtigt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-08: mailserver-protokoll-logging-diagnose`\n- Branch: `feature/ing-08-mailserver-protokoll-logging-diagnose`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-09", + "title": "Rate-Limiting auf Protokollebene", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Postgres-Jobqueue, Token-Bucket", + "description": "Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.", + "dependsOn": [ + "ING-03" + ], + "akzeptanz": [ + "Login-Versuche pro Quelle/Zeitfenster sind begrenzt und konfigurierbar", + "SMTP-Annahmerate pro Absender/Quelle ist begrenzt und konfigurierbar", + "Überschreitung führt zu definierter Ablehnung mit Wartezeit-Hinweis, nicht zu Verbindungsabbruch ohne Erklärung" + ], + "pruefungen": [ + "Lasttest bestätigt greifendes Limit bei Überschreitung", + "Test: legitime Nutzung unterhalb der Schwelle bleibt unbeeinträchtigt", + "Test: Limit ist je Mandant getrennt konfigurierbar und wirksam" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 2, + "unlocks": [ + "QA-04" + ], + "prompt": "# ING-09 – Rate-Limiting auf Protokollebene\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nRate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.\n\n**Technische Grundlage:** Go, Postgres-Jobqueue, Token-Bucket\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Login-Versuche pro Quelle/Zeitfenster sind begrenzt und konfigurierbar\n2. SMTP-Annahmerate pro Absender/Quelle ist begrenzt und konfigurierbar\n3. Überschreitung führt zu definierter Ablehnung mit Wartezeit-Hinweis, nicht zu Verbindungsabbruch ohne Erklärung\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Lasttest bestätigt greifendes Limit bei Überschreitung\n2. Test: legitime Nutzung unterhalb der Schwelle bleibt unbeeinträchtigt\n3. Test: Limit ist je Mandant getrennt konfigurierbar und wirksam\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-09: rate-limiting-auf-protokollebene`\n- Branch: `feature/ing-09-rate-limiting-auf-protokollebene`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-10", + "title": "Ingestion-Testsuite", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go testing, testify, Mailpit/MailHog", + "description": "Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.", + "dependsOn": [ + "ING-01", + "ING-02", + "ING-03", + "ING-04", + "ING-05" + ], + "akzeptanz": [ + "Jede Protokoll-Zustandsmaschine hat automatisierte Tests für erlaubte und verbotene Übergänge", + "Tenant-Scoping ist für jeden Ingestion-Pfad durch einen eigenen Test abgedeckt", + "Testsuite läuft reproduzierbar in der CI ohne externe Live-Postfächer" + ], + "pruefungen": [ + "Testabdeckungsbericht für alle fünf Ingestion-Module liegt vor", + "CI-Lauf grün auf frischem Checkout ohne manuelle Nacharbeit", + "Stichprobenreview durch zweite Person bestätigt sinnvolle Testfälle, nicht nur Zeilenabdeckung" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 3, + "unlocks": [ + "QA-02" + ], + "prompt": "# ING-10 – Ingestion-Testsuite\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nTestsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.\n\n**Technische Grundlage:** Go testing, testify, Mailpit/MailHog\n\n## Produkt-DNA für diesen Bereich\n> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.\n\n**Übernehmen:**\n- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.\n- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.\n- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.\n\n**Bewusst vermeiden:**\n- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.\n- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.\n\n**Für genau diese Kachel:** Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03, ING-04, ING-05 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jede Protokoll-Zustandsmaschine hat automatisierte Tests für erlaubte und verbotene Übergänge\n2. Tenant-Scoping ist für jeden Ingestion-Pfad durch einen eigenen Test abgedeckt\n3. Testsuite läuft reproduzierbar in der CI ohne externe Live-Postfächer\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testabdeckungsbericht für alle fünf Ingestion-Module liegt vor\n2. CI-Lauf grün auf frischem Checkout ohne manuelle Nacharbeit\n3. Stichprobenreview durch zweite Person bestätigt sinnvolle Testfälle, nicht nur Zeilenabdeckung\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #4: In einer früheren Implementierung waren nur 2 von 18 Modulen getestet, obwohl die Protokoll-Server-Logik hochkritisch ist. Für diese Kachel verbindlich: Pflichttests für Tenant-Scoping und für jede Protokoll-Zustandsmaschine sind Voraussetzung für die Abnahme, nicht optional nachgezogen.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Ingestion & Import\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-10: ingestion-testsuite`\n- Branch: `feature/ing-10-ingestion-testsuite`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-01", + "title": "REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go net/http, REST, OpenAPI 3", + "description": "Mail-spezifische API-Endpunkte (Mail-Liste/Mail-Detail/Anhang-Download usw.) auf dem zentralen Core-REST-Grundgerüst definieren und im modul-eigenen OpenAPI-Beitrag dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur.", + "dependsOn": [ + "ARC-01", + "SRC-03" + ], + "akzeptanz": [ + "API bietet Endpunkte für Mail-Liste, Mail-Detail und Anhang-Download", + "Alle Endpunkte sind strikt mandantengebunden", + "IAM-nahe Funktionen (Login, Tenant-Verwaltung) sind bewusst nicht Teil dieser API", + "Modul-eigener OpenAPI-Beitrag deckt alle v1-Endpunkte inklusive Fehlerantworten ab und ist gegen die tatsächliche API geprüft" + ], + "pruefungen": [ + "Test: Zugriff ohne gültigen Tenant-Kontext wird abgelehnt", + "Vertragstest gegen definierte Endpunkte läuft grün", + "Codereview bestätigt Abgrenzung zu Core-Board-Zuständigkeiten", + "Validierungslauf des OpenAPI-Dokuments gegen Standardwerkzeuge ist fehlerfrei" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 6, + "unlocks": [ + "INT-06", + "INT-07", + "QA-06", + "INT-12" + ], + "prompt": "# INT-01 – REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMail-spezifische API-Endpunkte (Mail-Liste/Mail-Detail/Anhang-Download usw.) auf dem zentralen Core-REST-Grundgerüst definieren und im modul-eigenen OpenAPI-Beitrag dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur.\n\n**Technische Grundlage:** Go net/http, REST, OpenAPI 3\n\n## Produkt-DNA für diesen Bereich\n> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.\n\n**Übernehmen:**\n- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.\n\n**Bewusst vermeiden:**\n- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.\n\n**Für genau diese Kachel:** REST-API v1 für lesenden und begrenzt schreibenden Zugriff auf archivierte Mails/Postfächer bereitstellen, entflochten von IAM-Themen des Core-Boards, inklusive eigener OpenAPI-Dokumentation der Mail-Endpunkte.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01, SRC-03 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board. Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-01` REST-API-Grundgerüst & Versionierung, `API-04` OpenAPI-Schnittstellenbeschreibung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. API bietet Endpunkte für Mail-Liste, Mail-Detail und Anhang-Download\n2. Alle Endpunkte sind strikt mandantengebunden\n3. IAM-nahe Funktionen (Login, Tenant-Verwaltung) sind bewusst nicht Teil dieser API\n4. Modul-eigener OpenAPI-Beitrag deckt alle v1-Endpunkte inklusive Fehlerantworten ab und ist gegen die tatsächliche API geprüft\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Zugriff ohne gültigen Tenant-Kontext wird abgelehnt\n2. Vertragstest gegen definierte Endpunkte läuft grün\n3. Codereview bestätigt Abgrenzung zu Core-Board-Zuständigkeiten\n4. Validierungslauf des OpenAPI-Dokuments gegen Standardwerkzeuge ist fehlerfrei\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Setzt voraus (externes Core-Board): `API-03` Zentrales Rate-Limiting & API-Gateway-Schicht\n- Setzt voraus (externes Core-Board): `API-07` Zentrale Webhook-Registry & Zustellung\n- `INT-06` E-Mail-Regel-Engine über API steuerbar\n- `INT-07` Health-Check-Endpunkt für Mail-Modul\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-01: rest-api-v1-fuer-mail-zugriff-schnittstellenbeschreibung`\n- Branch: `feature/int-01-rest-api-v1-fuer-mail-zugriff-schnittstellenbeschreibung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-05", + "title": "Benachrichtigungs-Service \"neue Mail\"", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)", + "description": "Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.", + "dependsOn": [ + "IMP-01" + ], + "akzeptanz": [ + "Neue Mail im überwachten Postfach löst zeitnah ein Ereignis an Core CFG-02 aus, das den Versand übernimmt", + "Benutzer kann Benachrichtigungsart und -häufigkeit konfigurieren", + "Massenimport (viele Mails gleichzeitig) erzeugt gebündelte statt Dutzende Einzelbenachrichtigungen" + ], + "pruefungen": [ + "Test: Import einer Mail löst genau eine Benachrichtigung aus", + "Test: Massenimport erzeugt eine gebündelte Zusammenfassung statt Flut", + "Test: deaktivierte Benachrichtigung erzeugt keine Zustellung" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 4, + "unlocks": [ + "QA-06" + ], + "prompt": "# INT-05 – Benachrichtigungs-Service \"neue Mail\"\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nClient-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.\n\n**Technische Grundlage:** Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)\n\n## Produkt-DNA für diesen Bereich\n> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.\n\n**Übernehmen:**\n- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.\n\n**Bewusst vermeiden:**\n- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.\n\n**Für genau diese Kachel:** Benachrichtigungs-Service, der Benutzer über neu importierte Mails informiert (In-App und optional per Mail), neu konzipiert ohne archivmail-Vorbild.\n\n## Ausgangslage\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher – zentraler Versandweg für alle Module, kein eigener E-Mail-Versand je Modul.\n\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail – Webhook-/Notification-Mechanismus muss komplett neu konzipiert werden, siehe repos-analyse-mail-reuse.md.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Neue Mail im überwachten Postfach löst zeitnah ein Ereignis an Core CFG-02 aus, das den Versand übernimmt\n2. Benutzer kann Benachrichtigungsart und -häufigkeit konfigurieren\n3. Massenimport (viele Mails gleichzeitig) erzeugt gebündelte statt Dutzende Einzelbenachrichtigungen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Import einer Mail löst genau eine Benachrichtigung aus\n2. Test: Massenimport erzeugt eine gebündelte Zusammenfassung statt Flut\n3. Test: deaktivierte Benachrichtigung erzeugt keine Zustellung\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-05: benachrichtigungs-service-neue-mail`\n- Branch: `feature/int-05-benachrichtigungs-service-neue-mail`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-06", + "title": "E-Mail-Regel-Engine über API steuerbar", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go net/http, REST", + "description": "E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.", + "dependsOn": [ + "IMP-03", + "INT-01" + ], + "akzeptanz": [ + "Regeln lassen sich vollständig über die API anlegen, ändern und löschen", + "Prioritätsreihenfolge ist über die API einsehbar und änderbar", + "API-Änderungen wirken identisch zur bisherigen internen Regel-Anwendung" + ], + "pruefungen": [ + "Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab", + "Test: über API gesetzte Regel wird beim nächsten Import korrekt angewendet", + "Test: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 7, + "unlocks": [ + "QA-06" + ], + "prompt": "# INT-06 – E-Mail-Regel-Engine über API steuerbar\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nE-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.\n\n**Technische Grundlage:** Go net/http, REST\n\n## Produkt-DNA für diesen Bereich\n> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.\n\n**Übernehmen:**\n- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.\n\n**Bewusst vermeiden:**\n- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.\n\n**Für genau diese Kachel:** E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-03, INT-01 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Regeln lassen sich vollständig über die API anlegen, ändern und löschen\n2. Prioritätsreihenfolge ist über die API einsehbar und änderbar\n3. API-Änderungen wirken identisch zur bisherigen internen Regel-Anwendung\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab\n2. Test: über API gesetzte Regel wird beim nächsten Import korrekt angewendet\n3. Test: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-06: e-mail-regel-engine-ueber-api-steuerbar`\n- Branch: `feature/int-06-e-mail-regel-engine-ueber-api-steuerbar`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-07", + "title": "Health-Check-Endpunkt für Mail-Modul", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go net/http", + "description": "Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.", + "dependsOn": [ + "INT-01" + ], + "akzeptanz": [ + "Health-Endpunkt meldet Status von Datenbank, Objektspeicher, Suchindex und Jobqueue getrennt", + "Endpunkt ist ohne Authentifizierung für interne Überwachung erreichbar, aber ohne sensible Details", + "Ausfall einer Teilkomponente wird klar als „degraded“ statt generischem Fehler gemeldet" + ], + "pruefungen": [ + "Test: simulierter Ausfall einer Abhängigkeit wird korrekt im Health-Status abgebildet", + "Test: Health-Antwort enthält keine sensiblen Konfigurationsdetails", + "Integrationstest gegen echten Health-Endpunkt nach Deploy" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 7, + "unlocks": [ + "QA-06" + ], + "prompt": "# INT-07 – Health-Check-Endpunkt für Mail-Modul\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nHealth-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.\n\n**Technische Grundlage:** Go net/http\n\n## Produkt-DNA für diesen Bereich\n> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.\n\n**Übernehmen:**\n- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.\n\n**Bewusst vermeiden:**\n- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.\n\n**Für genau diese Kachel:** Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: INT-01 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Health-Endpunkt meldet Status von Datenbank, Objektspeicher, Suchindex und Jobqueue getrennt\n2. Endpunkt ist ohne Authentifizierung für interne Überwachung erreichbar, aber ohne sensible Details\n3. Ausfall einer Teilkomponente wird klar als „degraded“ statt generischem Fehler gemeldet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: simulierter Ausfall einer Abhängigkeit wird korrekt im Health-Status abgebildet\n2. Test: Health-Antwort enthält keine sensiblen Konfigurationsdetails\n3. Integrationstest gegen echten Health-Endpunkt nach Deploy\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-07: health-check-endpunkt-fuer-mail-modul`\n- Branch: `feature/int-07-health-check-endpunkt-fuer-mail-modul`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-01", + "title": "Teststrategie Mail", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Testkonzept, Go testing, Playwright/Jest", + "description": "Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.", + "dependsOn": [], + "akzeptanz": [ + "Teststrategie benennt Testarten (Unit/Integration/E2E) und Mindestabdeckung je Modultyp", + "Protokoll- und Compliance-kritische Module haben verbindlich höhere Testpflicht als Standard-Module", + "Vorgehen für Bug-Tracking ist festgelegt und durchsuchbar (kein reines Code-Kommentar-Tracking)", + "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01" + ], + "pruefungen": [ + "Dokument liegt vor und wurde von zweiter Person gegengelesen", + "Stichprobe: mindestens ein Beispieltest je benannter Testart ist umgesetzt", + "Bug-Tracking-Vorgehen wurde einmal exemplarisch für einen realen Befund durchgespielt" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 1, + "unlocks": [], + "prompt": "# QA-01 – Teststrategie Mail\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nTeststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.\n\n**Technische Grundlage:** Testkonzept, Go testing, Playwright/Jest\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.\n\n## Ausgangslage\nDiese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Teststrategie benennt Testarten (Unit/Integration/E2E) und Mindestabdeckung je Modultyp\n2. Protokoll- und Compliance-kritische Module haben verbindlich höhere Testpflicht als Standard-Module\n3. Vorgehen für Bug-Tracking ist festgelegt und durchsuchbar (kein reines Code-Kommentar-Tracking)\n\n4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Dokument liegt vor und wurde von zweiter Person gegengelesen\n2. Stichprobe: mindestens ein Beispieltest je benannter Testart ist umgesetzt\n3. Bug-Tracking-Vorgehen wurde einmal exemplarisch für einen realen Befund durchgespielt\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #13: In einer früheren Implementierung gab es kein zentrales Issue-Tracking, Bugs wurden nur als `BUG-N`-Kommentare im Code festgehalten. Für diese Kachel verbindlich: Bugs und Fixes werden durchsuchbar getrackt, damit wiederkehrende Muster projektweit sichtbar werden, statt nur im Quelltext verstreut zu sein.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-01: teststrategie-mail`\n- Branch: `feature/qa-01-teststrategie-mail`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-02", + "title": "Prüfgate Ingestion & Import", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Testkonzept, CI", + "description": "Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.", + "dependsOn": [ + "ING-10", + "IMP-09", + "IMP-04", + "IMP-05", + "IMP-06", + "IMP-07", + "IMP-08", + "ING-07", + "ING-08" + ], + "akzeptanz": [ + "Gate prüft Testabdeckung und Bestehen aller Ingestion-/Import-Testsuiten", + "Gate prüft, dass bekannte Fehlerpunkte (Header-Injection, Anhang-Limit, UIDVALIDITY) durch Tests abgedeckt sind", + "Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel" + ], + "pruefungen": [ + "Gate-Lauf gegen aktuellen Stand von ING-10/IMP-09 dokumentiert", + "Stichprobe: mindestens ein Regressionstest je bekanntem Fehlerpunkt vorhanden", + "Zweite Person bestätigt Gate-Ergebnis unabhängig" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-02 – Prüfgate Ingestion & Import\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.\n\n**Technische Grundlage:** Testkonzept, CI\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-10, IMP-09 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- `IMP-04` Fehlerbehandlung nicht-konformer Server – Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.\n- `IMP-05` Hot-Folder/Scanner-Anbindung – Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.\n- `IMP-06` Anhangs-Virenscan-Anbindung – Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.\n- `IMP-07` Mehrfach-Postfach-Verwaltung pro Tenant – Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.\n- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall – Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.\n- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung – Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.\n- `ING-08` Mailserver-Protokoll-Logging & Diagnose – Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Gate prüft Testabdeckung und Bestehen aller Ingestion-/Import-Testsuiten\n2. Gate prüft, dass bekannte Fehlerpunkte (Header-Injection, Anhang-Limit, UIDVALIDITY) durch Tests abgedeckt sind\n3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Gate-Lauf gegen aktuellen Stand von ING-10/IMP-09 dokumentiert\n2. Stichprobe: mindestens ein Regressionstest je bekanntem Fehlerpunkt vorhanden\n3. Zweite Person bestätigt Gate-Ergebnis unabhängig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-09` Abnahme- & Compliance-Prüfung Mail\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-02: pruefgate-ingestion-import`\n- Branch: `feature/qa-02-pruefgate-ingestion-import`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-03", + "title": "Prüfgate Archivierung & Suche", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Testkonzept, CI", + "description": "Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.", + "dependsOn": [ + "ARC-08", + "SRC-10", + "SRC-02", + "SRC-04", + "SRC-05", + "SRC-08", + "SRC-09" + ], + "akzeptanz": [ + "Gate prüft Bestehen der Archivierungs- und Suchindex-Testsuiten inklusive Schlüsselrotation", + "Gate prüft Abwesenheit dynamischer SQL-Klauselbildung im Suchpfad", + "Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel" + ], + "pruefungen": [ + "Gate-Lauf gegen aktuellen Stand von ARC-08/SRC-10 dokumentiert", + "Codereview-Stichprobe bestätigt statischen Query-Builder", + "Zweite Person bestätigt Gate-Ergebnis unabhängig" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-03 – Prüfgate Archivierung & Suche\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.\n\n**Technische Grundlage:** Testkonzept, CI\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-08, SRC-10 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- `SRC-02` Indexierungs-Worker & Synchronisierung – Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.\n- `SRC-04` Such-Oberfläche mit Hervorhebung – Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.\n- `SRC-05` Facetten- & Filter-API – Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).\n- `SRC-08` Gespeicherte Suchanfragen – Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.\n- `SRC-09` Suchindex-Neuaufbau/Reindexierung – Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Gate prüft Bestehen der Archivierungs- und Suchindex-Testsuiten inklusive Schlüsselrotation\n2. Gate prüft Abwesenheit dynamischer SQL-Klauselbildung im Suchpfad\n3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Gate-Lauf gegen aktuellen Stand von ARC-08/SRC-10 dokumentiert\n2. Codereview-Stichprobe bestätigt statischen Query-Builder\n3. Zweite Person bestätigt Gate-Ergebnis unabhängig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-09` Abnahme- & Compliance-Prüfung Mail\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-03: pruefgate-archivierung-suche`\n- Branch: `feature/qa-03-pruefgate-archivierung-suche`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-04", + "title": "Sicherheits- & Berechtigungsprüfung", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Sicherheitsprüfung, Threat Modeling", + "description": "Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.", + "dependsOn": [ + "ING-03", + "ARC-06", + "ING-09", + "ING-06", + "SRC-11" + ], + "akzeptanz": [ + "Prüfung bestätigt wirksame Härtung des SMTP-Pfads gegen bekannte Angriffsmuster", + "Prüfung bestätigt lückenlose Mandantentrennung im Speicherpfad", + "Prüfung bestätigt korrekt greifendes API-Token-/Rate-Limiting" + ], + "pruefungen": [ + "Gezielter Testangriff auf Header-Injection schlägt fehl", + "Stichprobenprüfung mehrerer Speicherpfade auf Mandantentrennung", + "Test: API-Zugriff mit widerrufenem/fremdem Token wird verweigert" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 4, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-04 – Sicherheits- & Berechtigungsprüfung\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.\n\n**Technische Grundlage:** Sicherheitsprüfung, Threat Modeling\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-03, ARC-06, ING-09 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Berührt Login-Tenant-Filter und Privilege-Escalation – dafür ist bereits Core-Board IAM zuständig, hier nur Mail-spezifische Aspekte prüfen.\n- `ING-06` TLS/STARTTLS-Absicherung – TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.\n- `SRC-11` Feld-Whitelist-Query-Builder für Suchindex-Zugriff – Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Prüfung bestätigt wirksame Härtung des SMTP-Pfads gegen bekannte Angriffsmuster\n2. Prüfung bestätigt lückenlose Mandantentrennung im Speicherpfad\n3. Prüfung bestätigt korrekt greifendes API-Token-/Rate-Limiting\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Gezielter Testangriff auf Header-Injection schlägt fehl\n2. Stichprobenprüfung mehrerer Speicherpfade auf Mandantentrennung\n3. Test: API-Zugriff mit widerrufenem/fremdem Token wird verweigert\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-09` Abnahme- & Compliance-Prüfung Mail\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-04: sicherheits-berechtigungspruefung`\n- Branch: `feature/qa-04-sicherheits-berechtigungspruefung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-05", + "title": "Prüfgate Compliance & eDiscovery", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Compliance-Prüfung", + "description": "Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.", + "dependsOn": [ + "ARC-05", + "ARC-07", + "INT-08", + "ARC-10", + "ARC-04", + "ARC-09" + ], + "akzeptanz": [ + "Gate prüft korrekte Kopplung mailrelevanter Ereignisse an das Core-Audit-Log", + "Gate prüft, dass eDiscovery-Tenant-Scoping in der Query-Schicht verankert ist", + "Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel" + ], + "pruefungen": [ + "Gate-Lauf gegen aktuellen Stand der Audit-Trail-Kopplung (CMP-04) dokumentiert", + "Stichprobe: Audit-Eintrag für Testlöschung ist im Core-Audit-Log auffindbar", + "Zweite Person bestätigt Gate-Ergebnis unabhängig" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 5, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-05 – Prüfgate Compliance & eDiscovery\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.\n\n**Technische Grundlage:** Compliance-Prüfung\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.\n\n## Ausgangslage\n- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `CMP-04` Audit-Trail-Kopplung an Core-Audit-Log.\n- `ARC-05` Papierkorb & Soft-Delete für Mails – Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.\n- `ARC-07` Export/Portabilität (offenes Format) – Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.\n- `INT-08` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage – Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.\n- `ARC-10` Signatur- und Zeitstempelerhalt (BSI TR-03125) – Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und Prüfergebnis inkl. vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Zertifikatsablauf nachweisbar bleibt (BSI TR-03125).\n- `ARC-04` Aufbewahrungsstruktur (Mandant/Postfach/Jahr) – Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.\n- `ARC-09` Postfach-Quota – Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Gate prüft korrekte Kopplung mailrelevanter Ereignisse an das Core-Audit-Log\n2. Gate prüft, dass eDiscovery-Tenant-Scoping in der Query-Schicht verankert ist\n3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Gate-Lauf gegen aktuellen Stand der Audit-Trail-Kopplung (CMP-04) dokumentiert\n2. Stichprobe: Audit-Eintrag für Testlöschung ist im Core-Audit-Log auffindbar\n3. Zweite Person bestätigt Gate-Ergebnis unabhängig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-09` Abnahme- & Compliance-Prüfung Mail\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-05: pruefgate-compliance-ediscovery`\n- Branch: `feature/qa-05-pruefgate-compliance-ediscovery`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-06", + "title": "Schnittstellen-Vertragstests", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Vertragstests, OpenAPI", + "description": "Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.", + "dependsOn": [ + "INT-01", + "INT-05", + "INT-06", + "INT-07", + "INT-09", + "INT-10" + ], + "akzeptanz": [ + "Vertragstest deckt alle in der OpenAPI-Beschreibung definierten Endpunkte ab", + "Abweichungen zwischen Beschreibung und tatsächlichem Verhalten werden automatisch erkannt", + "Vertragstest läuft als Teil der CI bei jeder Änderung" + ], + "pruefungen": [ + "CI-Lauf des Vertragstests ist grün auf aktuellem Stand", + "Test: absichtlich eingefügte Abweichung wird vom Vertragstest erkannt", + "Stichprobenreview durch zweite Person" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 7, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-06 – Schnittstellen-Vertragstests\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSchnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.\n\n**Technische Grundlage:** Vertragstests, OpenAPI\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: INT-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- `INT-05` Benachrichtigungs-Service \"neue Mail\" – Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.\n- `INT-06` E-Mail-Regel-Engine über API steuerbar – E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.\n- `INT-07` Health-Check-Endpunkt für Mail-Modul – Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.\n- `INT-09` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01) – Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.\n- `INT-10` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02) – Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vertragstest deckt alle in der OpenAPI-Beschreibung definierten Endpunkte ab\n2. Abweichungen zwischen Beschreibung und tatsächlichem Verhalten werden automatisch erkannt\n3. Vertragstest läuft als Teil der CI bei jeder Änderung\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. CI-Lauf des Vertragstests ist grün auf aktuellem Stand\n2. Test: absichtlich eingefügte Abweichung wird vom Vertragstest erkannt\n3. Stichprobenreview durch zweite Person\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`\n- Branch: `feature/qa-06-schnittstellen-vertragstests`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-07", + "title": "Last- & Leistungstest", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Lasttest-Werkzeug (z. B. k6/vegeta)", + "description": "Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.", + "dependsOn": [ + "ING-01", + "ING-02", + "ING-03" + ], + "akzeptanz": [ + "Lasttest simuliert realistische Anzahl paralleler Sessions je Protokoll", + "Ergebnis zeigt Durchsatz- und Latenzwerte je Protokoll unter Last", + "Zielwerte für Antwortzeit/Durchsatz sind definiert und werden erreicht" + ], + "pruefungen": [ + "Lasttest-Lauf mit Ergebnisprotokoll liegt vor", + "Vergleich Ist- vs. Zielwert dokumentiert", + "Ressourcenverbrauch (CPU/RAM) während des Lasttests bleibt im erwarteten Rahmen" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-07 – Last- & Leistungstest\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nLast- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.\n\n**Technische Grundlage:** Lasttest-Werkzeug (z. B. k6/vegeta)\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Lasttest simuliert realistische Anzahl paralleler Sessions je Protokoll\n2. Ergebnis zeigt Durchsatz- und Latenzwerte je Protokoll unter Last\n3. Zielwerte für Antwortzeit/Durchsatz sind definiert und werden erreicht\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Lasttest-Lauf mit Ergebnisprotokoll liegt vor\n2. Vergleich Ist- vs. Zielwert dokumentiert\n3. Ressourcenverbrauch (CPU/RAM) während des Lasttests bleibt im erwarteten Rahmen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-07: last-leistungstest`\n- Branch: `feature/qa-07-last-leistungstest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-08", + "title": "Barrierefreiheits-Audit", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Accessibility-Audit-Werkzeug", + "description": "Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.", + "dependsOn": [ + "UX-07", + "UX-08", + "UX-09" + ], + "akzeptanz": [ + "Automatisierter Audit-Lauf zeigt keine kritischen Verstöße mehr", + "Manuelle Stichprobe bestätigt sinnvolle Tastatur- und Screenreader-Bedienung", + "Ergebnis ist dokumentiert und mit Verantwortlichen für Nachbesserung rückgekoppelt" + ], + "pruefungen": [ + "Audit-Bericht liegt vor mit Vorher/Nachher-Vergleich", + "Stichprobentest mit Screenreader durch zweite Person", + "Offene Punkte sind priorisiert und nachverfolgbar dokumentiert" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 7, + "unlocks": [ + "QA-09" + ], + "prompt": "# QA-08 – Barrierefreiheits-Audit\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nBarrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.\n\n**Technische Grundlage:** Accessibility-Audit-Werkzeug\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-07 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- `UX-08` Tastatur-Bedienung & Shortcuts – Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).\n- `UX-09` Akten-/Vorgangsanzeige im Mail-Kontext – In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Automatisierter Audit-Lauf zeigt keine kritischen Verstöße mehr\n2. Manuelle Stichprobe bestätigt sinnvolle Tastatur- und Screenreader-Bedienung\n3. Ergebnis ist dokumentiert und mit Verantwortlichen für Nachbesserung rückgekoppelt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Audit-Bericht liegt vor mit Vorher/Nachher-Vergleich\n2. Stichprobentest mit Screenreader durch zweite Person\n3. Offene Punkte sind priorisiert und nachverfolgbar dokumentiert\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-08: barrierefreiheits-audit`\n- Branch: `feature/qa-08-barrierefreiheits-audit`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-09", + "title": "Abnahme- & Compliance-Prüfung Mail", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Abnahmeprüfung", + "description": "Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.", + "dependsOn": [ + "QA-02", + "QA-03", + "QA-04", + "QA-05", + "QA-06", + "QA-07", + "QA-08", + "SRC-06" + ], + "akzeptanz": [ + "Alle vorgelagerten Prüfgates (Ingestion/Import, Archivierung/Suche, Sicherheit, Compliance) sind bestanden", + "Abnahmebericht fasst Ergebnisse aller Gates nachvollziehbar zusammen", + "Offene Punkte aus einzelnen Gates sind vollständig aufgelistet oder als geschlossen bestätigt" + ], + "pruefungen": [ + "Abnahmebericht liegt vor und wurde gegengelesen", + "Stichprobe: mindestens ein Ergebnis je vorgelagertem Gate ist im Bericht nachprüfbar verlinkt", + "Freigabeentscheidung ist dokumentiert mit Datum und verantwortlicher Person" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 7, + "unlocks": [], + "prompt": "# QA-09 – Abnahme- & Compliance-Prüfung Mail\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 9\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAbschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.\n\n**Technische Grundlage:** Abnahmeprüfung\n\n## Produkt-DNA für diesen Bereich\n> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.\n\n**Übernehmen:**\n- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.\n- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.\n\n**Bewusst vermeiden:**\n- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.\n- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.\n\n**Für genau diese Kachel:** Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: QA-02, QA-03, QA-04, QA-05, QA-06, QA-07 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- `QA-08` Barrierefreiheits-Audit – Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.\n- `SRC-06` Facetten-UI & Filter-Chips – Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle vorgelagerten Prüfgates (Ingestion/Import, Archivierung/Suche, Sicherheit, Compliance) sind bestanden\n2. Abnahmebericht fasst Ergebnisse aller Gates nachvollziehbar zusammen\n3. Offene Punkte aus einzelnen Gates sind vollständig aufgelistet oder als geschlossen bestätigt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Abnahmebericht liegt vor und wurde gegengelesen\n2. Stichprobe: mindestens ein Ergebnis je vorgelagertem Gate ist im Bericht nachprüfbar verlinkt\n3. Freigabeentscheidung ist dokumentiert mit Datum und verantwortlicher Person\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-09: abnahme-compliance-pruefung-mail`\n- Branch: `feature/qa-09-abnahme-compliance-pruefung-mail`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-01", + "title": "Manticore-Suchindex für Mails", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Manticore Search SQL/HTTP-API", + "description": "Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.", + "dependsOn": [ + "ARC-01", + "ARC-03" + ], + "akzeptanz": [ + "Index-Schema für Mail-Felder ist definiert und über Migration versioniert", + "Schreibzugriffe auf den Index verwenden ausschließlich statische, vordefinierte Feldnamen", + "Index ist mandantengetrennt abfragbar" + ], + "pruefungen": [ + "Codereview bestätigt: keine Sprintf/Join-basierte SQL-Klauselbildung im Index-Zugriff", + "Test: Abfrage mit manipulierten Eingabewerten verändert keine Spalten-/Tabellennamen", + "Funktionstest: Volltextsuche liefert erwartete Treffer für Testkorpus" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 4, + "unlocks": [ + "SRC-02", + "SRC-03", + "SRC-09" + ], + "prompt": "# SRC-01 – Manticore-Suchindex für Mails\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nManticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.\n\n**Technische Grundlage:** Go, Manticore Search SQL/HTTP-API\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Index-Schema für Mail-Felder ist definiert und über Migration versioniert\n2. Schreibzugriffe auf den Index verwenden ausschließlich statische, vordefinierte Feldnamen\n3. Index ist mandantengetrennt abfragbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Codereview bestätigt: keine Sprintf/Join-basierte SQL-Klauselbildung im Index-Zugriff\n2. Test: Abfrage mit manipulierten Eingabewerten verändert keine Spalten-/Tabellennamen\n3. Funktionstest: Volltextsuche liefert erwartete Treffer für Testkorpus\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #11: In einer früheren Implementierung wurden dynamische SQL-Klauseln über `fmt.Sprintf`/`strings.Join` gebaut, teils mit interpolierten Spalten-/Tabellennamen. Für diese Kachel verbindlich: Spalten- und Tabellennamen ausschließlich aus statischen Go-Konstanten, kein String-Zusammenbau von Bezeichnern zur Laufzeit – ein zentraler, getesteter Query-Builder mit Feld-Whitelist ist Pflicht.\nIndexierung darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird nicht indexiert.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SRC-02` Indexierungs-Worker & Synchronisierung\n- `SRC-03` Such-API mit Ranking\n- `SRC-09` Suchindex-Neuaufbau/Reindexierung\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-01: manticore-suchindex-fuer-mails`\n- Branch: `feature/src-01-manticore-suchindex-fuer-mails`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-02", + "title": "Indexierungs-Worker & Synchronisierung", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Postgres-Jobqueue", + "description": "Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.", + "dependsOn": [ + "SRC-01", + "ARC-03" + ], + "akzeptanz": [ + "Neue Archivobjekte erscheinen innerhalb definierter Zeit im Suchindex", + "Löschungen und Metadatenänderungen werden im Index nachgezogen", + "Worker-Ausfall verliert keine Indexierungsaufträge (Wiederaufnahme aus Postgres-Jobqueue)" + ], + "pruefungen": [ + "Test: Worker-Neustart mitten im Lauf verliert keinen offenen Auftrag", + "Test: Löschung einer Mail entfernt sie zuverlässig aus Suchtreffern", + "Konsistenztest vergleicht Datenbankbestand mit Indexbestand stichprobenartig" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 5, + "unlocks": [ + "QA-03", + "SRC-12" + ], + "prompt": "# SRC-02 – Indexierungs-Worker & Synchronisierung\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nIndexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.\n\n**Technische Grundlage:** Go, Postgres-Jobqueue\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Neue Archivobjekte erscheinen innerhalb definierter Zeit im Suchindex\n2. Löschungen und Metadatenänderungen werden im Index nachgezogen\n3. Worker-Ausfall verliert keine Indexierungsaufträge (Wiederaufnahme aus Postgres-Jobqueue)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Worker-Neustart mitten im Lauf verliert keinen offenen Auftrag\n2. Test: Löschung einer Mail entfernt sie zuverlässig aus Suchtreffern\n3. Konsistenztest vergleicht Datenbankbestand mit Indexbestand stichprobenartig\n\n## Bekannte Fehler vermeiden\nIndexierung darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird nicht indexiert.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-02: indexierungs-worker-synchronisierung`\n- Branch: `feature/src-02-indexierungs-worker-synchronisierung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-03", + "title": "Such-API mit Ranking", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, Manticore Search", + "description": "Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).", + "dependsOn": [ + "SRC-01" + ], + "akzeptanz": [ + "Suche liefert nach Relevanz sortierte Treffer mit nachvollziehbarem Ranking", + "Ergebnisse sind strikt auf den anfragenden Mandanten beschränkt", + "Grundoperatoren (Phrasensuche, Ausschluss) funktionieren korrekt" + ], + "pruefungen": [ + "Test: Suche eines Mandanten liefert keine Treffer eines anderen Mandanten", + "Test: Phrasensuche und Ausschlussoperator liefern erwartete Teilmengen", + "Performance-Test mit großem Testkorpus bleibt innerhalb Zielzeit" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 5, + "unlocks": [ + "INT-01", + "SRC-04", + "SRC-05", + "SRC-08" + ], + "prompt": "# SRC-03 – Such-API mit Ranking\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSuch-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).\n\n**Technische Grundlage:** Go, Manticore Search\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Suche liefert nach Relevanz sortierte Treffer mit nachvollziehbarem Ranking\n2. Ergebnisse sind strikt auf den anfragenden Mandanten beschränkt\n3. Grundoperatoren (Phrasensuche, Ausschluss) funktionieren korrekt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Suche eines Mandanten liefert keine Treffer eines anderen Mandanten\n2. Test: Phrasensuche und Ausschlussoperator liefern erwartete Teilmengen\n3. Performance-Test mit großem Testkorpus bleibt innerhalb Zielzeit\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `INT-01` REST-API v1 für Mail-Zugriff\n- `SRC-04` Such-Oberfläche mit Hervorhebung\n- `SRC-05` Facetten- & Filter-API\n- `SRC-08` Gespeicherte Suchanfragen\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-03: such-api-mit-ranking`\n- Branch: `feature/src-03-such-api-mit-ranking`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-04", + "title": "Such-Oberfläche mit Hervorhebung", + "epic": "SRC", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TS", + "description": "Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.", + "dependsOn": [ + "SRC-03", + "SHL-01" + ], + "akzeptanz": [ + "Eingabe liefert Trefferliste mit hervorgehobenen Suchbegriffen im Snippet", + "Klick auf Treffer öffnet die zugehörige Mail direkt an der Fundstelle", + "Leere Ergebnisse zeigen verständlichen Hinweis statt leerer Fläche" + ], + "pruefungen": [ + "Manueller Test mit typischen Suchanfragen bestätigt korrekte Hervorhebung", + "Barrierefreiheits-Kontrastprüfung der Hervorhebung", + "Test mit Sonderzeichen in der Suchanfrage bricht die Anzeige nicht" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 6, + "unlocks": [ + "QA-03" + ], + "prompt": "# SRC-04 – Such-Oberfläche mit Hervorhebung\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nSuch-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.\n\n**Technische Grundlage:** Next.js/React/TS\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Eingabe liefert Trefferliste mit hervorgehobenen Suchbegriffen im Snippet\n2. Klick auf Treffer öffnet die zugehörige Mail direkt an der Fundstelle\n3. Leere Ergebnisse zeigen verständlichen Hinweis statt leerer Fläche\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test mit typischen Suchanfragen bestätigt korrekte Hervorhebung\n2. Barrierefreiheits-Kontrastprüfung der Hervorhebung\n3. Test mit Sonderzeichen in der Suchanfrage bricht die Anzeige nicht\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-04: such-oberflaeche-mit-hervorhebung`\n- Branch: `feature/src-04-such-oberflaeche-mit-hervorhebung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-05", + "title": "Facetten- & Filter-API", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Manticore Facets", + "description": "Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).", + "dependsOn": [ + "SRC-03" + ], + "akzeptanz": [ + "API liefert Facettenwerte mit Trefferzahl je Filterdimension", + "Mehrere Filter lassen sich kombinieren (UND-Verknüpfung)", + "Facetten sind mandantengetrennt berechnet" + ], + "pruefungen": [ + "Test: Facettenzahlen stimmen mit tatsächlicher Treffermenge überein", + "Test: Kombination von drei Filtern liefert korrekt eingeschränkte Treffer", + "Test: Facetten eines Mandanten enthalten keine Werte eines anderen" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 6, + "unlocks": [ + "SRC-06", + "QA-03" + ], + "prompt": "# SRC-05 – Facetten- & Filter-API\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFacetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).\n\n**Technische Grundlage:** Go, Manticore Facets\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. API liefert Facettenwerte mit Trefferzahl je Filterdimension\n2. Mehrere Filter lassen sich kombinieren (UND-Verknüpfung)\n3. Facetten sind mandantengetrennt berechnet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Facettenzahlen stimmen mit tatsächlicher Treffermenge überein\n2. Test: Kombination von drei Filtern liefert korrekt eingeschränkte Treffer\n3. Test: Facetten eines Mandanten enthalten keine Werte eines anderen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SRC-06` Facetten-UI & Filter-Chips\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-05: facetten-filter-api`\n- Branch: `feature/src-05-facetten-filter-api`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-06", + "title": "Facetten-UI & Filter-Chips", + "epic": "SRC", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS", + "description": "Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.", + "dependsOn": [ + "SRC-05", + "SHL-01" + ], + "akzeptanz": [ + "Aktive Filter erscheinen als entfernbare Chips oberhalb der Trefferliste", + "Trefferzahl je Facettenwert wird live aktualisiert", + "Zurücksetzen aller Filter ist mit einem Klick möglich" + ], + "pruefungen": [ + "Manueller Test: Filterkombination und Einzelentfernung funktionieren wie erwartet", + "Tastaturbedienbarkeit der Filter-Chips geprüft", + "Test mit vielen aktiven Filtern bleibt die Ansicht übersichtlich" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 7, + "unlocks": [ + "QA-09" + ], + "prompt": "# SRC-06 – Facetten-UI & Filter-Chips\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nFacetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.\n\n**Technische Grundlage:** Next.js/React/TS\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-05 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Aktive Filter erscheinen als entfernbare Chips oberhalb der Trefferliste\n2. Trefferzahl je Facettenwert wird live aktualisiert\n3. Zurücksetzen aller Filter ist mit einem Klick möglich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test: Filterkombination und Einzelentfernung funktionieren wie erwartet\n2. Tastaturbedienbarkeit der Filter-Chips geprüft\n3. Test mit vielen aktiven Filtern bleibt die Ansicht übersichtlich\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-06: facetten-ui-filter-chips`\n- Branch: `feature/src-06-facetten-ui-filter-chips`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-07", + "title": "OCR für Anhänge", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, OCR-Engine-Anbindung (z. B. Tesseract)", + "description": "OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.", + "dependsOn": [ + "ARC-01", + "ARC-03" + ], + "akzeptanz": [ + "Bild- und gescannte PDF-Anhänge werden automatisch per OCR verarbeitet", + "Erkannter Text wird dem zugehörigen Mail-Suchdokument zugeordnet", + "Bereits durchsuchbare PDFs (mit Textebene) werden nicht unnötig erneut per OCR verarbeitet" + ], + "pruefungen": [ + "Test: Bildanhang mit bekanntem Text liefert erwartete Texterkennung", + "Test: PDF mit vorhandener Textebene wird korrekt übersprungen", + "Durchsatztest bestätigt akzeptable Verarbeitungszeit je Anhang" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 4, + "unlocks": [ + "SRC-10", + "SRC-12" + ], + "prompt": "# SRC-07 – OCR für Anhänge\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nOCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.\n\n**Technische Grundlage:** Go, OCR-Engine-Anbindung (z. B. Tesseract)\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (eigenständiger Mail-OCR-Pfad), siehe repos-analyse-mail-reuse.md. Dupliziertes Sprintf-WHERE-Muster muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Bild- und gescannte PDF-Anhänge werden automatisch per OCR verarbeitet\n2. Erkannter Text wird dem zugehörigen Mail-Suchdokument zugeordnet\n3. Bereits durchsuchbare PDFs (mit Textebene) werden nicht unnötig erneut per OCR verarbeitet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Bildanhang mit bekanntem Text liefert erwartete Texterkennung\n2. Test: PDF mit vorhandener Textebene wird korrekt übersprungen\n3. Durchsatztest bestätigt akzeptable Verarbeitungszeit je Anhang\n\n## Bekannte Fehler vermeiden\nOCR darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird keine OCR gerechnet.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SRC-10` Spracherkennung & OCR-Qualitätsbewertung\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-07: ocr-fuer-anhaenge`\n- Branch: `feature/src-07-ocr-fuer-anhaenge`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-08", + "title": "Gespeicherte Suchanfragen", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Postgres", + "description": "Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.", + "dependsOn": [ + "SRC-03" + ], + "akzeptanz": [ + "Suchkriterien inklusive aktiver Filter lassen sich unter einem Namen speichern", + "Gespeicherte Suche liefert bei erneuter Ausführung aktuelle Treffer, keinen eingefrorenen Snapshot", + "Gespeicherte Suchen sind je Benutzer/Mandant getrennt sichtbar" + ], + "pruefungen": [ + "Test: gespeicherte Suche mit mehreren Filtern wird korrekt reproduziert", + "Test: Benutzer sieht keine gespeicherten Suchen anderer Mandanten", + "Test: Löschen einer gespeicherten Suche entfernt nur diese" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 6, + "unlocks": [ + "QA-03" + ], + "prompt": "# SRC-08 – Gespeicherte Suchanfragen\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nGespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.\n\n**Technische Grundlage:** Go, Postgres\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Suchkriterien inklusive aktiver Filter lassen sich unter einem Namen speichern\n2. Gespeicherte Suche liefert bei erneuter Ausführung aktuelle Treffer, keinen eingefrorenen Snapshot\n3. Gespeicherte Suchen sind je Benutzer/Mandant getrennt sichtbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: gespeicherte Suche mit mehreren Filtern wird korrekt reproduziert\n2. Test: Benutzer sieht keine gespeicherten Suchen anderer Mandanten\n3. Test: Löschen einer gespeicherten Suche entfernt nur diese\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-08: gespeicherte-suchanfragen`\n- Branch: `feature/src-08-gespeicherte-suchanfragen`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-09", + "title": "Suchindex-Neuaufbau/Reindexierung", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Manticore Search", + "description": "Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.", + "dependsOn": [ + "SRC-01" + ], + "akzeptanz": [ + "Voller Reindex lässt sich ohne Datenverlust im laufenden Betrieb anstoßen", + "Fortschritt und Abschluss des Reindex sind nachvollziehbar sichtbar", + "Alter Index bleibt bis zum erfolgreichen Abschluss des neuen Index abfragbar (kein Suchausfall)" + ], + "pruefungen": [ + "Test: Reindex während laufender Suchanfragen unterbricht die Suche nicht", + "Test: abgebrochener Reindex hinterlässt keinen inkonsistenten Zustand", + "Stichprobenvergleich Alt-/Neuindex bestätigt gleiche Trefferzahlen" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 5, + "unlocks": [ + "QA-03" + ], + "prompt": "# SRC-09 – Suchindex-Neuaufbau/Reindexierung\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nWerkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.\n\n**Technische Grundlage:** Go, Manticore Search\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Voller Reindex lässt sich ohne Datenverlust im laufenden Betrieb anstoßen\n2. Fortschritt und Abschluss des Reindex sind nachvollziehbar sichtbar\n3. Alter Index bleibt bis zum erfolgreichen Abschluss des neuen Index abfragbar (kein Suchausfall)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Reindex während laufender Suchanfragen unterbricht die Suche nicht\n2. Test: abgebrochener Reindex hinterlässt keinen inkonsistenten Zustand\n3. Stichprobenvergleich Alt-/Neuindex bestätigt gleiche Trefferzahlen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-09: suchindex-neuaufbau-reindexierung`\n- Branch: `feature/src-09-suchindex-neuaufbau-reindexierung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-10", + "title": "Spracherkennung & OCR-Qualitätsbewertung", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Go, OCR-Engine-Anbindung", + "description": "Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.", + "dependsOn": [ + "SRC-07" + ], + "akzeptanz": [ + "Erkannte Sprache wird je OCR-Text gespeichert und für Suche/Anzeige genutzt", + "Konfidenzwert der Erkennung wird gespeichert und ist auswertbar", + "Anhänge mit niedriger OCR-Qualität sind gezielt auffindbar (z. B. für manuelle Nachbearbeitung)" + ], + "pruefungen": [ + "Test mit mehrsprachigem Testkorpus bestätigt korrekte Spracherkennung", + "Test: künstlich verschlechtertes Bild erzeugt niedrigeren Konfidenzwert", + "Abfrage aller Anhänge unterhalb einer Konfidenzschwelle liefert erwartete Treffer" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 5, + "unlocks": [ + "QA-03" + ], + "prompt": "# SRC-10 – Spracherkennung & OCR-Qualitätsbewertung\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSpracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.\n\n**Technische Grundlage:** Go, OCR-Engine-Anbindung\n\n## Produkt-DNA für diesen Bereich\n> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.\n\n**Übernehmen:**\n- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.\n\n**Bewusst vermeiden:**\n- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.\n\n**Für genau diese Kachel:** Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: SRC-07 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (eigenständiger Mail-OCR-Pfad), siehe repos-analyse-mail-reuse.md. Dupliziertes Sprintf-WHERE-Muster muss vor Übernahme durch statischen Query-Builder ersetzt werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Erkannte Sprache wird je OCR-Text gespeichert und für Suche/Anzeige genutzt\n2. Konfidenzwert der Erkennung wird gespeichert und ist auswertbar\n3. Anhänge mit niedriger OCR-Qualität sind gezielt auffindbar (z. B. für manuelle Nachbearbeitung)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit mehrsprachigem Testkorpus bestätigt korrekte Spracherkennung\n2. Test: künstlich verschlechtertes Bild erzeugt niedrigeren Konfidenzwert\n3. Abfrage aller Anhänge unterhalb einer Konfidenzschwelle liefert erwartete Treffer\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate Archivierung & Suche\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-10: spracherkennung-ocr-qualitaetsbewertung`\n- Branch: `feature/src-10-spracherkennung-ocr-qualitaetsbewertung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-01", + "title": "Postfach- & Ordneransicht", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TS", + "description": "Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.", + "dependsOn": [ + "IMP-01", + "SHL-01" + ], + "akzeptanz": [ + "Ordnerbaum zeigt alle Postfächer/Ordner des angemeldeten Mandanten korrekt", + "Nachrichtenliste unterstützt Sortierung nach Datum/Absender/Betreff", + "Ansicht bleibt bei mehreren tausend Nachrichten performant bedienbar" + ], + "pruefungen": [ + "Manueller Test mit Testpostfach bestätigt korrekte Ordner-/Listendarstellung", + "Performance-Test mit großer Nachrichtenliste bleibt flüssig", + "Test: Benutzer sieht ausschließlich Postfächer des eigenen Mandanten" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 4, + "unlocks": [ + "UX-02", + "UX-04", + "UX-05", + "UX-06", + "UX-07", + "UX-08" + ], + "prompt": "# UX-01 – Postfach- & Ordneransicht\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nPostfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.\n\n**Technische Grundlage:** Next.js/React/TS\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Ordnerbaum zeigt alle Postfächer/Ordner des angemeldeten Mandanten korrekt\n2. Nachrichtenliste unterstützt Sortierung nach Datum/Absender/Betreff\n3. Ansicht bleibt bei mehreren tausend Nachrichten performant bedienbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test mit Testpostfach bestätigt korrekte Ordner-/Listendarstellung\n2. Performance-Test mit großer Nachrichtenliste bleibt flüssig\n3. Test: Benutzer sieht ausschließlich Postfächer des eigenen Mandanten\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-02` E-Mail-Detailansicht & Thread-Darstellung\n- `UX-04` Responsive Layout & mobile Navigation\n- `UX-05` Dunkles Erscheinungsbild & Theming\n- `UX-06` Mehrsprachigkeit (Deutsch/Englisch)\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n- `UX-08` Tastatur-Bedienung & Shortcuts\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-01: postfach-ordneransicht`\n- Branch: `feature/ux-01-postfach-ordneransicht`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-02", + "title": "E-Mail-Detailansicht & Thread-Darstellung", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TS", + "description": "E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.", + "dependsOn": [ + "UX-01", + "SHL-01" + ], + "akzeptanz": [ + "Detailansicht zeigt Nachrichtentext, relevante Header und Anhangsliste vollständig", + "Zusammengehörige Nachrichten werden als Thread gruppiert dargestellt", + "Navigation zwischen Thread-Nachrichten funktioniert ohne Kontextverlust" + ], + "pruefungen": [ + "Manueller Test mit mehrteiligem Thread bestätigt korrekte Gruppierung", + "Test: Anhangsliste stimmt mit tatsächlich archivierten Anhängen überein", + "Barrierefreiheits-Grundprüfung der Detailansicht" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 5, + "unlocks": [ + "UX-07", + "UX-08", + "UX-09" + ], + "prompt": "# UX-02 – E-Mail-Detailansicht & Thread-Darstellung\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nE-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.\n\n**Technische Grundlage:** Next.js/React/TS\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Detailansicht zeigt Nachrichtentext, relevante Header und Anhangsliste vollständig\n2. Zusammengehörige Nachrichten werden als Thread gruppiert dargestellt\n3. Navigation zwischen Thread-Nachrichten funktioniert ohne Kontextverlust\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test mit mehrteiligem Thread bestätigt korrekte Gruppierung\n2. Test: Anhangsliste stimmt mit tatsächlich archivierten Anhängen überein\n3. Barrierefreiheits-Grundprüfung der Detailansicht\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n- `UX-08` Tastatur-Bedienung & Shortcuts\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-02: e-mail-detailansicht-thread-darstellung`\n- Branch: `feature/ux-02-e-mail-detailansicht-thread-darstellung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-03", + "title": "Anhang-Vorschau", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TS, Canvas-Rendering", + "description": "Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.", + "dependsOn": [ + "ARC-01", + "SHL-01" + ], + "akzeptanz": [ + "Vorschau funktioniert für PDF- und Bildanhänge ohne externen Download", + "Content-Type wird serverseitig über Magic-Bytes bestimmt, nicht über die Dateiendung", + "PDF-Vorschau nutzt Canvas-Rendering, kein iframe/HTML-Rendering von Anhangsinhalt" + ], + "pruefungen": [ + "Test: Anhang mit falscher Dateiendung, aber echtem PDF-Inhalt wird korrekt als PDF erkannt und angezeigt", + "Sicherheitsreview bestätigt: keine iframe-Einbindung von Anhangsinhalt", + "Test: manipulierter Dateiname mit abweichendem Inhalt löst keine Fehlanzeige/-ausführung aus" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 3, + "unlocks": [ + "UX-07" + ], + "prompt": "# UX-03 – Anhang-Vorschau\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nAnhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.\n\n**Technische Grundlage:** Next.js/React/TS, Canvas-Rendering\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. PdfCanvasPreview-Ansatz aus archivmail als positives Vorbild nutzbar (Canvas statt iframe), siehe repos-analyse-mail-reuse.md. Die Content-Type-Erkennung der Anhang-Vorschau muss dagegen neu (serverseitig über Magic-Bytes) gebaut werden.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vorschau funktioniert für PDF- und Bildanhänge ohne externen Download\n2. Content-Type wird serverseitig über Magic-Bytes bestimmt, nicht über die Dateiendung\n3. PDF-Vorschau nutzt Canvas-Rendering, kein iframe/HTML-Rendering von Anhangsinhalt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Anhang mit falscher Dateiendung, aber echtem PDF-Inhalt wird korrekt als PDF erkannt und angezeigt\n2. Sicherheitsreview bestätigt: keine iframe-Einbindung von Anhangsinhalt\n3. Test: manipulierter Dateiname mit abweichendem Inhalt löst keine Fehlanzeige/-ausführung aus\n\n## Bekannte Fehler vermeiden\nAus known-issues-archivmail.md, Punkt #8 und #9: Eine frühere Implementierung erkannte den Content-Type der Anhang-Vorschau nur über die Dateiendung (fragile Guard-Reihenfolge) und rendete PDFs testweise auch über iframe. Für diese Kachel verbindlich: Content-Type-Erkennung serverseitig über Magic-Bytes, PDF-Vorschau ausschließlich über Canvas-Rendering – iframe-Rendering von Fremdinhalt ist nicht zulässig.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-03: anhang-vorschau`\n- Branch: `feature/ux-03-anhang-vorschau`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-04", + "title": "Responsive Layout & mobile Navigation", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS, CSS Grid/Flexbox", + "description": "Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).", + "dependsOn": [ + "UX-01", + "SHL-01" + ], + "akzeptanz": [ + "Kernansichten sind auf schmalen Viewports vollständig nutzbar", + "Navigation zwischen Ordnerliste, Nachrichtenliste und Detail ist auf Mobilgeräten ohne Verlust bedienbar", + "Keine horizontal abgeschnittenen Inhalte auf gängigen Bildschirmbreiten" + ], + "pruefungen": [ + "Manueller Test auf mindestens drei Viewport-Breiten", + "Touch-Bedienungstest der Kernnavigation", + "Automatisierter Layout-Regressionstest für Kernansichten" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 5, + "unlocks": [ + "UX-07" + ], + "prompt": "# UX-04 – Responsive Layout & mobile Navigation\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nResponsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).\n\n**Technische Grundlage:** Next.js/React/TS, CSS Grid/Flexbox\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Kernansichten sind auf schmalen Viewports vollständig nutzbar\n2. Navigation zwischen Ordnerliste, Nachrichtenliste und Detail ist auf Mobilgeräten ohne Verlust bedienbar\n3. Keine horizontal abgeschnittenen Inhalte auf gängigen Bildschirmbreiten\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test auf mindestens drei Viewport-Breiten\n2. Touch-Bedienungstest der Kernnavigation\n3. Automatisierter Layout-Regressionstest für Kernansichten\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-04: responsive-layout-mobile-navigation`\n- Branch: `feature/ux-04-responsive-layout-mobile-navigation`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-05", + "title": "Dunkles Erscheinungsbild & Theming", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS, CSS Custom Properties", + "description": "Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.", + "dependsOn": [ + "UX-01", + "SHL-01" + ], + "akzeptanz": [ + "Dunkles und helles Erscheinungsbild sind vollständig nutzbar, keine unlesbaren Kontraste", + "Einstellung folgt Systempräferenz, ist aber manuell überschreibbar", + "Theme-Wahl bleibt über Sitzungen hinweg erhalten" + ], + "pruefungen": [ + "Kontrastprüfung für beide Modi nach WCAG-Mindestwerten", + "Test: manuelle Theme-Wahl übersteht Neuladen der Seite", + "Visuelle Stichprobe aller Kernansichten in beiden Modi" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 5, + "unlocks": [ + "UX-07" + ], + "prompt": "# UX-05 – Dunkles Erscheinungsbild & Theming\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nDunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.\n\n**Technische Grundlage:** Next.js/React/TS, CSS Custom Properties\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Dunkles und helles Erscheinungsbild sind vollständig nutzbar, keine unlesbaren Kontraste\n2. Einstellung folgt Systempräferenz, ist aber manuell überschreibbar\n3. Theme-Wahl bleibt über Sitzungen hinweg erhalten\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Kontrastprüfung für beide Modi nach WCAG-Mindestwerten\n2. Test: manuelle Theme-Wahl übersteht Neuladen der Seite\n3. Visuelle Stichprobe aller Kernansichten in beiden Modi\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-05: dunkles-erscheinungsbild-theming`\n- Branch: `feature/ux-05-dunkles-erscheinungsbild-theming`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-06", + "title": "Mehrsprachigkeit (Deutsch/Englisch)", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS, i18n", + "description": "Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.", + "dependsOn": [ + "UX-01", + "SHL-01" + ], + "akzeptanz": [ + "Alle Oberflächentexte der Kernansichten liegen in Deutsch und Englisch vor", + "Sprachumschaltung wirkt sofort ohne vollständigen Seiten-Neuladen", + "Datums-/Zahlenformate folgen der gewählten Sprache" + ], + "pruefungen": [ + "Stichprobenprüfung auf fehlende Übersetzungen (keine Schlüssel sichtbar statt Text)", + "Test: Sprachumschaltung funktioniert in allen Kernansichten", + "Test: Datumsformat wechselt korrekt zwischen beiden Sprachen" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 5, + "unlocks": [ + "UX-07" + ], + "prompt": "# UX-06 – Mehrsprachigkeit (Deutsch/Englisch)\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nMehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.\n\n**Technische Grundlage:** Next.js/React/TS, i18n\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Oberflächentexte der Kernansichten liegen in Deutsch und Englisch vor\n2. Sprachumschaltung wirkt sofort ohne vollständigen Seiten-Neuladen\n3. Datums-/Zahlenformate folgen der gewählten Sprache\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Stichprobenprüfung auf fehlende Übersetzungen (keine Schlüssel sichtbar statt Text)\n2. Test: Sprachumschaltung funktioniert in allen Kernansichten\n3. Test: Datumsformat wechselt korrekt zwischen beiden Sprachen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `UX-07` Barrierefreiheit nach WCAG 2.1 AA\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-06: mehrsprachigkeit-deutsch-englisch`\n- Branch: `feature/ux-06-mehrsprachigkeit-deutsch-englisch`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-07", + "title": "Barrierefreiheit nach WCAG 2.1 AA", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TS, WCAG 2.1 AA", + "description": "Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).", + "dependsOn": [ + "UX-01", + "UX-02", + "UX-03", + "UX-04", + "UX-05", + "UX-06", + "SHL-01" + ], + "akzeptanz": [ + "Alle Kernansichten erreichen WCAG 2.1 AA in automatisierter Prüfung ohne kritische Verstöße", + "Vollständige Bedienbarkeit ohne Maus ist für alle Kernfunktionen gegeben", + "Screenreader-Ausgabe ist für zentrale Elemente sinnvoll und vollständig" + ], + "pruefungen": [ + "Automatisierter Accessibility-Scan aller Kernansichten ohne kritische Befunde", + "Manueller Tastatur-Durchlauf durch alle Kernfunktionen", + "Stichprobentest mit Screenreader durch zweite Person" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 6, + "unlocks": [ + "QA-08" + ], + "prompt": "# UX-07 – Barrierefreiheit nach WCAG 2.1 AA\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nBarrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).\n\n**Technische Grundlage:** Next.js/React/TS, WCAG 2.1 AA\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01, UX-02, UX-03, UX-04, UX-05, UX-06 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Kernansichten erreichen WCAG 2.1 AA in automatisierter Prüfung ohne kritische Verstöße\n2. Vollständige Bedienbarkeit ohne Maus ist für alle Kernfunktionen gegeben\n3. Screenreader-Ausgabe ist für zentrale Elemente sinnvoll und vollständig\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Automatisierter Accessibility-Scan aller Kernansichten ohne kritische Befunde\n2. Manueller Tastatur-Durchlauf durch alle Kernfunktionen\n3. Stichprobentest mit Screenreader durch zweite Person\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-08` Barrierefreiheits-Audit\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-07: barrierefreiheit-nach-wcag-2-1-aa`\n- Branch: `feature/ux-07-barrierefreiheit-nach-wcag-2-1-aa`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-08", + "title": "Tastatur-Bedienung & Shortcuts", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS", + "description": "Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).", + "dependsOn": [ + "UX-01", + "UX-02", + "SHL-01" + ], + "akzeptanz": [ + "Kernaktionen sind über dokumentierte Tastenkombinationen erreichbar", + "Shortcuts kollidieren nicht mit Standard-Browser-Kürzeln", + "Aktueller Fokus ist jederzeit visuell erkennbar" + ], + "pruefungen": [ + "Manueller Test aller dokumentierten Shortcuts in den Kernansichten", + "Test: kein Shortcut überschreibt sicherheitsrelevante Browser-Funktion", + "Fokus-Sichtbarkeitsprüfung in allen Kernansichten" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 6, + "unlocks": [ + "QA-08" + ], + "prompt": "# UX-08 – Tastatur-Bedienung & Shortcuts\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nTastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).\n\n**Technische Grundlage:** Next.js/React/TS\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: UX-01, UX-02 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Kernaktionen sind über dokumentierte Tastenkombinationen erreichbar\n2. Shortcuts kollidieren nicht mit Standard-Browser-Kürzeln\n3. Aktueller Fokus ist jederzeit visuell erkennbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manueller Test aller dokumentierten Shortcuts in den Kernansichten\n2. Test: kein Shortcut überschreibt sicherheitsrelevante Browser-Funktion\n3. Fokus-Sichtbarkeitsprüfung in allen Kernansichten\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-08: tastatur-bedienung-shortcuts`\n- Branch: `feature/ux-08-tastatur-bedienung-shortcuts`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "UX-09", + "title": "Akten-/Vorgangsanzeige im Mail-Kontext", + "epic": "UX", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React/TS, externe REST-API", + "description": "In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.", + "dependsOn": [ + "UX-02", + "SHL-01" + ], + "akzeptanz": [ + "E-Mail-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden", + "Kein eigenes Akte-Datenmodell in Mail, ausschließlich Anzeige über die externe API", + "Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Mailanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“" + ], + "pruefungen": [ + "E-Mail mit verknüpfter Akte zeigt Akte-Informationen korrekt an", + "E-Mail ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler", + "Simulierter Ausfall der Workflow-API blockiert die übrige Mailanzeige nicht" + ], + "status": "Fertig", + "epicName": "Postfach-Oberfläche", + "epicEmoji": "📱", + "wave": 6, + "unlocks": [ + "QA-08" + ], + "prompt": "# UX-09 – Akten-/Vorgangsanzeige im Mail-Kontext\n\n**Epic:** 📱 Postfach-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nOberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.\n\n## Auftrag\nIn der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.\n\n**Technische Grundlage:** Next.js/React/TS, externe REST-API\n\n## Produkt-DNA für diesen Bereich\n> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.\n\n**Übernehmen:**\n- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.\n- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.\n\n**Bewusst vermeiden:**\n- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.\n- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.\n\n**Für genau diese Kachel:** In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `UX-02` E-Mail-Detailansicht & Thread-Darstellung – E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.\n- Setzt voraus (externes Workflow-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/): `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. E-Mail-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden\n2. Kein eigenes Akte-Datenmodell in Mail, ausschließlich Anzeige über die externe API\n3. Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Mailanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. E-Mail mit verknüpfter Akte zeigt Akte-Informationen korrekt an\n2. E-Mail ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler\n3. Simulierter Ausfall der Workflow-API blockiert die übrige Mailanzeige nicht\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Akte-Datenmodell (Workflow-Board, siehe `VOR-01`)\n- Vermerke-Erfassung (Workflow-Board, siehe `VOR-02`)\n- Wiedervorlage-Erfassung (Workflow-Board, siehe `VOR-03`)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `UX-09: akten vorgangsanzeige im mail kontext`\n- Branch: `feature/ux-09-akten-vorgangsanzeige-im-mail-kontext`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-09", + "title": "Postfach-Quota", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go, Postgres, tenant_id", + "description": "Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.", + "dependsOn": [ + "ARC-01", + "IMP-07" + ], + "akzeptanz": [ + "Speicherlimit ist je Postfach konfigurierbar, unabhängig von der Tenant-weiten Quota aus Core LIC-05", + "Postfach am Limit lehnt neue eingehende Mail mit klarer, protokollgerechter Fehlermeldung ab (SMTP-Rückweisung), verwirft nicht stillschweigend", + "Ein Postfach am Limit beeinträchtigt keine anderen Postfächer desselben Tenants" + ], + "pruefungen": [ + "Test: Postfach-Quota erreicht, neue eingehende Mail wird mit korrekter SMTP-Fehlermeldung abgelehnt", + "Test: anderes Postfach desselben Tenants empfängt weiterhin normal, während eines am Limit ist", + "Verbrauchsanzeige je Postfach im Test korrekt gegen tatsächliche Größe geprüft" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 5, + "unlocks": [ + "QA-05" + ], + "prompt": "# ARC-09 – Postfach-Quota\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nKonfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.\n\n**Technische Grundlage:** Go, Postgres, tenant_id\n\n## Produkt-DNA für diesen Bereich\n> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.\n\n**Übernehmen:**\n- Dovecot: Quota-Plugin-Konzept, pro Mailbox konfigurierbar.\n\n**Bewusst vermeiden:**\n- Ein einzelnes überfülltes Postfach darf nie andere Postfächer desselben Tenants beeinträchtigen – Quota ist strikt pro Postfach durchgesetzt, nicht als Tenant-weiter Summen-Topf.\n\n**Für genau diese Kachel:** Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.\n\n## Ausgangslage\nSetzt innerhalb dieses Boards voraus: ARC-01, IMP-07 sind auf Fertig.\n\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `LIC-05` Speicherverbrauch-Metrik je Tenant.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Speicherlimit ist je Postfach konfigurierbar, unabhängig von der Tenant-weiten Quota aus Core LIC-05\n2. Postfach am Limit lehnt neue eingehende Mail mit klarer, protokollgerechter Fehlermeldung ab (SMTP-Rückweisung), verwirft nicht stillschweigend\n3. Ein Postfach am Limit beeinträchtigt keine anderen Postfächer desselben Tenants\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Postfach-Quota erreicht, neue eingehende Mail wird mit korrekter SMTP-Fehlermeldung abgelehnt\n2. Test: anderes Postfach desselben Tenants empfängt weiterhin normal, während eines am Limit ist\n3. Verbrauchsanzeige je Postfach im Test korrekt gegen tatsächliche Größe geprüft\n\n## Bekannte Fehler vermeiden\n- **Tenant-weite Speicherquota (Core LIC-05) und Postfach-Quota sind unterschiedliche Ebenen** – ein Tenant kann insgesamt genug Kontingent haben, während ein einzelnes Postfach durch Missbrauch oder Fehlkonfiguration überläuft. Beide Ebenen unabhängig durchsetzen, nicht nur eine.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine nachgelagerten Kacheln innerhalb dieses Boards)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-09: postfach-quota`\n- Branch: `feature/arc-09-postfach-quota`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ARC-10", + "title": "Signatur- und Zeitstempelerhalt (BSI TR-03125)", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 3, + "tech": "Go (crypto/x509, S/MIME-/PGP-Signaturprüfung), RFC-3161-Zeitstempel-Client oder lokaler Fallback", + "description": "Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und Prüfergebnis inkl. vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Zertifikatsablauf nachweisbar bleibt (BSI TR-03125).", + "dependsOn": [ + "ING-04", + "ARC-01" + ], + "akzeptanz": [ + "Signierte Mails (S/MIME und PGP/MIME) werden bei Archivierung erkannt, unsignierte Mails durchlaufen KEINE zusätzliche Prüfung", + "Signaturprüfergebnis (gültig/ungültig/Prüfung nicht möglich, Zertifikatsdaten, Prüfzeitpunkt) wird unveränderlich mitarchiviert", + "Prüfnachweis ist über die Mail-Detailansicht abrufbar, ohne die Original-Mail zu verändern" + ], + "pruefungen": [ + "Test mit echter S/MIME-signierter Testmail: Prüfergebnis 'gültig' korrekt erkannt und archiviert", + "Test mit signierter Mail mit manipuliertem Inhalt: Prüfergebnis 'ungültig' korrekt erkannt", + "Simulierter Zertifikatsablauf nach Archivierung: archivierter Prüfnachweis bleibt unverändert abrufbar" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 4, + "unlocks": [ + "QA-05" + ], + "prompt": "# ARC-10 – Signatur- und Zeitstempelerhalt (BSI TR-03125)\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFür digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und das Prüfergebnis inklusive vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Ablauf des Signaturzertifikats nachweisbar bleibt (BSI TR-03125, Modul B.4 „Übernahme kryptographisch signierter Unterlagen\"). Kein eigenes Langzeitarchivierungs-/ArchiSig-Verfahren mit periodischer Neu-Zeitstempelung – ein EINMALIGER, bei Archivierung erzeugter Prüfnachweis reicht für den Anwendungsfall (KMU-E-Mail-Archivierung, kein qualifiziertes elektronisches Archiv nach eIDAS).\n\n**Technische Grundlage:** Go (`crypto/x509`, S/MIME-/PGP-Signaturprüfung), RFC-3161-Zeitstempel-Client (optional gegen externe TSA) oder lokal vertrauenswürdiger Zeitstempel als Fallback\n\n## Produkt-DNA für diesen Bereich\n> Was signiert ankommt, muss auch signiert nachweisbar bleiben – nicht nur unverändert gespeichert.\n\n**Übernehmen:**\n- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.\n- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.\n- BSI TR-03125: Prüfergebnis + Zeitpunkt der Prüfung werden ARCHIVIERT, nicht nur einmalig zur Laufzeit berechnet und verworfen.\n\n**Bewusst vermeiden:**\n- Ein vollständiges ArchiSig-/Merkle-Baum-Verfahren mit periodischer Neu-Zeitstempelung aller archivierten Signaturen: für den Anwendungsfall (KMU-Mailarchiv, keine gesetzliche Pflicht zum qualifizierten elektronischen Archiv) unverhältnismäßiger Aufwand. Ein einmaliger, bei Ingestion erzeugter Prüfnachweis ist ausreichend und wird durch das ohnehin unveränderliche Audit-Log (Core `AUD-02`) vor nachträglicher Manipulation geschützt.\n- Erzwungene Signaturprüfung für ALLE Mails: die überwiegende Mehrheit unsignierter Mails darf durch diese Kachel nicht verlangsamt werden – Prüfung läuft nur für tatsächlich signierte Nachrichten.\n\n**Für genau diese Kachel:** Bisher zurückgestellte Lücke aus dem Vorgängerprojekt archivmail (siehe `repos/archivmail/docs/GOBD_DSGVO_CHECKLIST.md`, Punkt 12) – jetzt mit einer bewusst schlanken, verhältnismäßigen Lösung geschlossen statt weiter unbearbeitet zu bleiben.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ING-04` MIME- & Anhang-Parsing – liefert die geparste MIME-Struktur, aus der signierte Teile (`multipart/signed`, `application/pkcs7-mime`) erkennbar sind.\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Original-Bytes werden unverändert gespeichert; dieses Ticket ergänzt nur zusätzliche Metadaten, ändert nichts an der Speicherung selbst.\n\nSetzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `AUD-01`/`AUD-02` Zentrales, unveränderliches Audit-Log-Modell – der Prüfnachweis wird dort abgelegt, kein zweites Protokoll.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Signierte Mails (S/MIME und PGP/MIME) werden bei Archivierung erkannt, unsignierte Mails durchlaufen KEINE zusätzliche Prüfung\n2. Signaturprüfergebnis (gültig/ungültig/Prüfung nicht möglich, Zertifikatsdaten, Prüfzeitpunkt) wird unveränderlich mitarchiviert – auch wenn das Signaturzertifikat später abläuft, bleibt nachweisbar, DASS es zum Archivierungszeitpunkt gültig war\n3. Prüfnachweis ist über die Mail-Detailansicht abrufbar, ohne die Original-Mail zu verändern\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit einer echten S/MIME-signierten Testmail: Prüfergebnis \"gültig\" korrekt erkannt und archiviert\n2. Test mit einer signierten Mail mit MANIPULIERTEM Inhalt: Prüfergebnis \"ungültig\" korrekt erkannt\n3. Simulierter Zertifikatsablauf NACH Archivierung: archivierter Prüfnachweis bleibt unverändert abrufbar und zeigt weiterhin \"zum Prüfzeitpunkt gültig\"\n\n## Bekannte Fehler vermeiden\narchivmail hat Zeitstempel-/Signaturerhalt komplett zurückgestellt (siehe `repos/archivmail/docs/GOBD_DSGVO_CHECKLIST.md`, Punkt 12) – dieses Ticket schließt die Lücke bewusst schlank statt sie erneut zu verschieben, ohne dabei ein für den Anwendungsfall unverhältnismäßiges volles Langzeitarchivierungsverfahren zu bauen (siehe \"Bewusst vermeiden\").\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Periodische Neu-Zeitstempelung/ArchiSig-Verfahren für sehr lange Aufbewahrungszeiträume (nicht geplant, siehe \"Bewusst vermeiden\")\n- MIME-Parsing selbst (`ING-04`)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-10: signatur-zeitstempelerhalt-bsi-tr-03125`\n- Branch: `feature/arc-10-signatur-zeitstempelerhalt-bsi-tr-03125`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-08", + "title": "Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping", + "description": "Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Mail-/Anhang-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert", + "Vor Löschung einer archivierten Mail wird eine Sperr-Abfrage an Archive gestellt", + "Ist die Mail gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt", + "Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt" + ], + "pruefungen": [ + "Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort", + "Test: gesperrte Mail kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar", + "Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 4, + "unlocks": [ + "QA-05", + "INT-11" + ], + "prompt": "# INT-08 – Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.\n\n**Technische Grundlage:** HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping\n\n## Produkt-DNA für diesen Bereich\n> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.\n\n**Übernehmen:**\n- Zentrale Aufbewahrungslogik einmal in Archive, nicht doppelt in Mail – vermeidet widersprüchliche Löschregeln.\n\n**Bewusst vermeiden:**\n- Keine eigene Retention-/Legal-Hold-Logik in Mail. Das führt zu Divergenz zwischen den Modulen.\n\n**Für genau diese Kachel:** Ohne diese Anbindung könnte Mail archivierte Nachrichten löschen, die Archive eigentlich sperrt – das ist der Rechtsstreit-Fall (Litigation Hold), den ARC-05 bereits gegen RET-03 prüft.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.\n\nSetzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/):\n- `RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Mail-/Anhang-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert\n2. Vor Löschung einer archivierten Mail wird eine Sperr-Abfrage an Archive gestellt\n3. Ist die Mail gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt\n4. Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort\n2. Test: gesperrte Mail kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar\n3. Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-08: archive anbindung objekttyp registrierung retention abfrage`\n- Branch: `feature/int-08-archive-anbindung-objekttyp-registrierung-retention-abfrage`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-09", + "title": "AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping", + "description": "Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Mail-/Thread-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert", + "Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet Mail unverändert ohne Fehler", + "Registrierungsfehler blockieren niemals den regulären Mail-Betrieb (fail open bei Registrierung)" + ], + "pruefungen": [ + "Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort", + "Test: AI-Modul deaktiviert – Mail startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb", + "Test: AI-Endpunkt nicht erreichbar bei Registrierung – Mail-Start wird dadurch nicht blockiert" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 4, + "unlocks": [ + "QA-06", + "INT-11" + ], + "prompt": "# INT-09 – AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.\n\n**Technische Grundlage:** HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping\n\n## Produkt-DNA für diesen Bereich\n> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.\n\n**Übernehmen:**\n- KI bleibt optional zuschaltbar über Core LIC-02 – kein Zwang, keine harte Kopplung.\n\n**Bewusst vermeiden:**\n- Keine eigene Klassifizierungs- oder Zusammenfassungslogik in Mail. Das dupliziert AI-Funktionalität.\n\n**Für genau diese Kachel:** Ohne diese Registrierung bliebe AI GOV-01 ohne Gegenstelle in Mail – die KI-Funktionen (CLS/SUM/SEM) hätten keine Mails zum Verarbeiten.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.\n\nSetzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/):\n- `GOV-01` Modul-Adapter-Schnittstelle (DMS/Mail registrieren KI-fähige Objekttypen) – Schnittstelle, über die DMS und Mail KI-fähige Objekttypen (Dokument, E-Mail, Thread) und deren Felder registrieren, statt eigene KI-Logik zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Mail-/Thread-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert\n2. Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet Mail unverändert ohne Fehler\n3. Registrierungsfehler blockieren niemals den regulären Mail-Betrieb (fail open bei Registrierung)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort\n2. Test: AI-Modul deaktiviert – Mail startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb\n3. Test: AI-Endpunkt nicht erreichbar bei Registrierung – Mail-Start wird dadurch nicht blockiert\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-09: ai anbindung objekttyp registrierung kopplung ai gov 01`\n- Branch: `feature/int-09-ai-anbindung-objekttyp-registrierung-kopplung-ai-gov-01`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-10", + "title": "Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher", + "description": "Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.", + "dependsOn": [ + "ARC-01" + ], + "akzeptanz": [ + "Mail-/Thread-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert", + "Ereignis 'Mail eingegangen' wird bei Zustellung tatsächlich an Workflow publiziert", + "Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende Mail-Aktion (asynchron, nicht im Request-Pfad)" + ], + "pruefungen": [ + "Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort", + "Test: Mail eingegangen – Ereignis kommt nachweislich bei Workflow an", + "Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Mailzustellung bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 4, + "unlocks": [ + "QA-06", + "INT-11" + ], + "prompt": "# INT-10 – Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.\n\n**Technische Grundlage:** HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher\n\n## Produkt-DNA für diesen Bereich\n> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.\n\n**Übernehmen:**\n- Ereignis-Publikation asynchron und best-effort mit sichtbarem Fehlerzustand, analog zum Core-Webhook-Muster (Postgres-Jobqueue statt Redis).\n\n**Bewusst vermeiden:**\n- Keine eigene Genehmigungs- oder Aufgabenlogik in Mail. Das dupliziert Workflow-Funktionalität.\n\n**Für genau diese Kachel:** Ohne diese Anbindung bliebe Workflow ENG-02 ohne Gegenstelle in Mail – z. B. eine Freigabe-Pflicht vor Massenzustellung könnte nicht am Mail-Lebenszyklus andocken.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.\n\nSetzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/):\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Mail-/Thread-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert\n2. Ereignis 'Mail eingegangen' wird bei Zustellung tatsächlich an Workflow publiziert\n3. Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende Mail-Aktion (asynchron, nicht im Request-Pfad)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort\n2. Test: Mail eingegangen – Ereignis kommt nachweislich bei Workflow an\n3. Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Mailzustellung bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-10: workflow anbindung objekttyp auslöser registrierung kopplung workflow eng 02`\n- Branch: `feature/int-10-workflow-anbindung-objekttyp-auslöser-registrierung-kopplung-workflow-eng-02`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-11", + "title": "Feld-Whitelist-Query-Builder für Suchindex-Zugriff", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 1, + "tech": "Statisches Enum/Switch für Feldnamen, getesteter Query-Builder", + "description": "Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.", + "dependsOn": [ + "SRC-01" + ], + "akzeptanz": [ + "Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau", + "Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung", + "Entscheidung dokumentiert: Mail-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren" + ], + "pruefungen": [ + "Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert", + "Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 4, + "unlocks": [ + "QA-04" + ], + "prompt": "# SRC-11 – Feld-Whitelist-Query-Builder für Suchindex-Zugriff\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (E-Mail-Archivierung: Import, Volltextsuche, Aufbewahrung, eDiscovery), das sich an bewährten Mustern aus archivmail orientiert und dessen bekannte Schwächen bewusst vermeidet.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), Manticore-RT-Index, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nZentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.\n\n**Technische Grundlage:** Statisches Enum/Switch für Feldnamen, getesteter Query-Builder\n\n## Produkt-DNA für diesen Bereich\n> Spalten-/Tabellennamen sind nie Nutzereingabe, auch nicht hinter einer Whitelist-Funktion – dieselbe Lehre aus beiden Altsystemen unabhängig gemacht.\n\n**Übernehmen:**\n- known-issues-archivdms.md Punkt 10 und known-issues-archivmail.md Punkt 12: dynamische Tabellennamen via fmt.Sprintf, nur durch eine fragile Whitelist-Funktion abgesichert – hier durch einen geschlossenen Enum/Switch-Typ ersetzt.\n\n**Bewusst vermeiden:**\n- Keine generische String-Zusammenbau-Funktion für Spalten-/Tabellennamen, auch nicht mit Whitelist-Prüfung davor.\n\n**Für genau diese Kachel:** SICHERHEITSKONZEPT.md Abschnitt 11 Punkt 10 ließ offen, ob DMS und Mail eine gemeinsame Utility teilen oder unabhängig implementieren – Entscheidung: unabhängig, konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren (siehe nexarch-state.json → bewusst_nicht_zentralisiert). Beide Boards folgen derselben Regel, ohne eine dritte, gemeinsame Abhängigkeit zu brauchen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `SRC-01` Suchindex-Grundlage – liefert das Schema, auf dessen dynamische Feldzugriffe dieser Query-Builder angewendet wird.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau\n2. Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung\n3. Entscheidung dokumentiert: Mail-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert\n2. Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Geteilte Utility mit dem DMS-Board – bewusst nicht gebaut, siehe Ausgangslage.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n" + }, + { + "code": "ARC-11", + "title": "RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf", + "epic": "ARC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "HTTP-Client gegen Archive RET-05, Rückruf-Endpunkt, Postgres-Jobqueue für Requeue", + "description": "Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, empfängt Vernichtungs-Rückrufe und behandelt Registrierungsfehler tolerant statt sie zu verschlucken.", + "dependsOn": [ + "ARC-01", + "RET-09" + ], + "akzeptanz": [ + "Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse", + "Mail empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg", + "Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue, nicht zu einem Absturz oder stillem Verwerfen" + ], + "pruefungen": [ + "Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert, für Mail UND Anhang getrennt", + "Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, Mail-Löschung nachweislich erfolgt, 2xx-Antwort gesendet", + "Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag, kein Absturz" + ], + "status": "Fertig", + "epicName": "Archivierung & Speicherung", + "epicEmoji": "🗄️", + "wave": 5, + "unlocks": [], + "prompt": "# ARC-11 – RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf\n\n**Epic:** 🗄️ Archivierung & Speicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (E-Mail-Archivierung, revisionssicher).\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nMail registriert seine Objekttypen (Mail, Anhang) bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, statt eigene Retention-Logik zu bauen. Bei Vernichtung eines Objekts ruft Archive Mail über diesen Rückruf zurück — Mail muss den Rückruf empfangen, die Löschung durchführen und bestätigen, sowie fehlgeschlagene eigene Registrierungsversuche tolerant behandeln.\n\n**Technische Grundlage:** HTTP-Client gegen Archive RET-05 (`POST /register`), HTTP-Endpunkt für Rückruf-Empfang, Postgres-Jobqueue für Requeue bei Nicht-2xx\n\n## Produkt-DNA für diesen Bereich\n> Modul-Adapter statt Modul-eigener Retention-Logik – Mail kennt nur den Vertrag (Objekttyp, Klasse, Rückruf-Adresse), nicht Archives interne Fristenberechnung.\n\n**Übernehmen:**\n- Zentrale Aufbewahrung statt je Modul neu erfundener Retention-Logik.\n\n**Bewusst vermeiden:**\n- Keine eigene Fristenberechnung in Mail – das ist Archive RET-01/RET-02s Aufgabe.\n- Kein stiller Datenverlust bei fehlgeschlagenem Rückruf-Empfang – Requeue statt Verwerfen.\n\n**Für genau diese Kachel:** Mail ist Konsument des RET-05-Vertrags, nicht Implementierer eigener Aufbewahrungslogik – der Vertrag (Register, Rückruf, Fehlerverhalten) ist durch Archive RET-05 bereits feststehend, nicht Gegenstand dieser Kachel. Mail und Anhang können unterschiedliche Aufbewahrungsklassen benötigen (z. B. geschäftliche Korrespondenz vs. große Anhänge) – beide getrennt registrieren, nicht unter einem Objekttyp vermischen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge\n- Archive `RET-05` Modul-Adapter-Schnittstelle (externe Abhängigkeit, anderes Board) – REST-Vertrag: `POST /register` mit `{module_name, object_type, retention_class, callback_url}`, idempotent (ON CONFLICT DO NOTHING); Vernichtungs-Rückruf ist `POST ` mit `{object_type, object_reference, destroyed_at}`, Erfolg = HTTP 2xx.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse\n2. Mail empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg\n3. Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue, nicht zu einem Absturz oder stillem Verwerfen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert, für Mail UND Anhang getrennt\n2. Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, Mail-Löschung nachweislich erfolgt, 2xx-Antwort gesendet\n3. Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag, kein Absturz\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Archive `RET-05` selbst (Interface ist bereits fertig, hier nur konsumiert)\n- Fristenberechnung/-konfiguration (Archive `RET-01`/`RET-02`)\n- Admin-Oberfläche für Aufbewahrungs-Katalog (`RET-06`)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ARC-11: ret-05-client-aufbewahrungsklasse-registrieren-vernichtungs-rueckruf`\n- Branch: `feature/arc-11-ret-05-client-aufbewahrungsklasse-registrieren-vernichtungs-rueckruf`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ING-11", + "title": "Header-Injection-Schutz für ausgehende Mailer-Komponente", + "epic": "ING", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Go net/mail, RFC 5322, CRLF-Validierung", + "description": "ING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.", + "dependsOn": [ + "ING-03" + ], + "akzeptanz": [ + "Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code", + "Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen", + "Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben" + ], + "pruefungen": [ + "Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert", + "Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt", + "Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern" + ], + "status": "Fertig", + "epicName": "Ingestion & Protokoll-Server", + "epicEmoji": "📥", + "wave": 8, + "unlocks": [], + "prompt": "# ING-11 – Header-Injection-Schutz für ausgehende Mailer-Komponente\n\n**Epic:** 📥 Ingestion & Protokoll-Server | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.\n\n**Technische Grundlage:** Go net/mail, RFC 5322, CRLF-Validierung\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Rspamd/Dovecot: strikte RFC-5322-Konformität bei der Header-Erzeugung statt freihändigem String-Bau.\n\n**Bewusst vermeiden:**\n- archivmail – Header per Stringkonkatenation ohne CRLF-Prüfung, konkreter Injection-Bug im Altsystem.: Header-Erzeugung ausschließlich über strukturierten Writer, CRLF-Eingaben werden hart abgelehnt.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ING-03.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code\n2. Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen\n3. Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert\n2. Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt\n3. Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Mail-Board, 2026-09-12), direkter Bezug zu known-issues-archivmail.md Punkt 1: Header-Injection in der Mailer-Komponente ist ein bereits im Altsystem aufgetretener, konkreter Bug und muss beim Übernehmen des Codes zwingend behoben sein, nicht nur vermerkt.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ING-03` SMTP-Server & Mailer\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ING-11: header-injection-schutz-f-r-ausgehende-mailer-komponente`\n- Branch: `feature/ing-11-header-injection-schutz-f-r-ausgehende-mailer-komponente`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-11", + "title": "Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go", + "description": "INT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.", + "dependsOn": [ + "INT-08", + "INT-09", + "INT-10" + ], + "akzeptanz": [ + "Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter", + "Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope", + "Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert" + ], + "pruefungen": [ + "Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten", + "Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt", + "Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 8, + "unlocks": [], + "prompt": "# INT-11 – Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nINT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.\n\n**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Zitadel: Service-Accounts agieren im Namen eines Kontexts, nie mit implizit eigenen, umfassenderen Rechten.\n\n**Bewusst vermeiden:**\n- Keycloak – Service-Client-Aufrufe teilen sich in manchen Integrationen denselben weiten Scope wie der Admin-Client.: Service-Credential trägt nur die Rechte, um im Namen eines übergebenen Tenant-Kontexts zu handeln, nie tenant-übergreifend von sich aus.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: INT-08, INT-09, INT-10.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter\n2. Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope\n3. Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten\n2. Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt\n3. Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `INT-16`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal über Service-Credentials ohne durchgereichten Nutzer-Tenant-Kontext kann diese Isolation modulübergreifend aufweichen.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `INT-08` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage\n- `INT-09` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)\n- `INT-10` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-11: nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`\n- Branch: `feature/int-11-nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "INT-12", + "title": "Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit", + "epic": "INT", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 1, + "tech": "Storage-Adapter, signierte URLs, Go", + "description": "INT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.", + "dependsOn": [ + "INT-01", + "ARC-01" + ], + "akzeptanz": [ + "Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang", + "Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter", + "Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff" + ], + "pruefungen": [ + "Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler", + "Test: abgelaufene URL wird abgelehnt", + "Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt" + ], + "status": "Fertig", + "epicName": "Integration & API", + "epicEmoji": "🔌", + "wave": 8, + "unlocks": [], + "prompt": "# INT-12 – Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit\n\n**Epic:** 🔌 Integration & API | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nINT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.\n\n**Technische Grundlage:** Storage-Adapter, signierte URLs, Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Dovecot/Alfresco: zeitlich begrenzte, objektgebundene Zugriffs-Tokens statt dauerhafter Links.\n\n**Bewusst vermeiden:**\n- Alfresco – in älteren Konfigurationen teils lang gültige Download-Links ohne erzwungene kurze TTL.: Ablaufzeit ist ein hartes, kurzes Limit, keine Empfehlung.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: INT-01, ARC-01.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang\n2. Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter\n3. Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler\n2. Test: abgelaufene URL wird abgelehnt\n3. Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-10`: ohne explizite Scope-/TTL-Vorgabe könnten signierte URLs für Anhang-Downloads versehentlich zu breit oder zu lange gültig ausgestellt werden.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `INT-01` REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung\n- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `INT-12: signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`\n- Branch: `feature/int-12-signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SRC-12", + "title": "Ressourcenlimits für OCR-/Indexierungs-Jobs", + "epic": "SRC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)", + "description": "SRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.", + "dependsOn": [ + "SRC-02", + "SRC-07" + ], + "akzeptanz": [ + "Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl", + "Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers", + "Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst" + ], + "pruefungen": [ + "Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen", + "Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs", + "Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs" + ], + "status": "Fertig", + "epicName": "Suche & OCR", + "epicEmoji": "🔍", + "wave": 8, + "unlocks": [], + "prompt": "# SRC-12 – Ressourcenlimits für OCR-/Indexierungs-Jobs\n\n**Epic:** 🔍 Suche & OCR | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.\n\n**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Rspamd: klare Verarbeitungszeitgrenzen pro Nachricht statt unbegrenzter Best-Effort-Verarbeitung.\n\n**Bewusst vermeiden:**\n- archivmail (bekannte Fehlerklasse) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war eine wiederkehrende Betriebsstörung in Altsystemen.: harte, konfigurierbare Obergrenzen je Job von Anfang an statt nachträglicher Begrenzung nach Vorfall.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: SRC-02, SRC-07.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl\n2. Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers\n3. Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen\n2. Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs\n3. Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-11`: unbegrenzte Einzeljob-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Worker-Pool, auch ohne böswillige Absicht.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SRC-02` Indexierungs-Worker & Synchronisierung\n- `SRC-07` OCR für Anhänge\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SRC-12: ressourcenlimits-f-r-ocr-indexierungs-jobs`\n- Branch: `feature/src-12-ressourcenlimits-f-r-ocr-indexierungs-jobs`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + } + ] +} \ No newline at end of file diff --git a/mail-kanban/kanban.html b/mail-kanban/kanban.html new file mode 100644 index 00000000..fac5cf53 --- /dev/null +++ b/mail-kanban/kanban.html @@ -0,0 +1,50 @@ + + + + + +Mail Kanban – lokal + + + +
+
+

Mail Kanban – lokal, offline, ohne Server

+ + + + + + + +
+
+
+
+ + +
+
+
+
+
+
+
+ + +
+
+
+

+

Baut auf

+

Schaltet frei

+

Akzeptanzkriterien

    +

    Prüfungen vor der Abnahme

      +

      Bau-Prompt

      
+  
      
+      
+
+
+
+
+
diff --git a/mail-kanban/tickets/ARC-01.md b/mail-kanban/tickets/ARC-01.md
new file mode 100644
index 00000000..213b6f61
--- /dev/null
+++ b/mail-kanban/tickets/ARC-01.md
@@ -0,0 +1,76 @@
+# ARC-01 – Objekt-Speicher-Anbindung für Mails/Anhänge
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.
+
+**Technische Grundlage:** Go, S3-kompatibles Objektspeicher-API
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-04 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `LIC-05` Speicherverbrauch-Metrik je Tenant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Mails und Anhänge werden nach fester, dokumentierter Pfadkonvention abgelegt
+2. Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert
+3. Lesezugriff ist unabhängig vom ursprünglichen Importpfad möglich
+4. Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt
+2. Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt
+3. Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz
+4. Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe
+
+## Bekannte Fehler vermeiden
+- **Verarbeitungsreihenfolge nach Empfang**: Hash-Berechnung & Duplikatsprüfung (ARC-03) zuerst, danach erst Verschlüsselung (ARC-02) für neue/bewusste Duplikate, danach OCR (SRC-07) und Indexierung (SRC-01/SRC-02) — niemals umgekehrt.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ARC-02` Verschlüsselung at rest
+- `ARC-03` Dublettenerkennung E-Mail
+- `ARC-04` Aufbewahrungsstruktur (Mandant/Postfach/Jahr)
+- `ARC-05` Papierkorb & Soft-Delete für Mails
+- `ARC-06` Mandantentrennung im Speicherpfad
+- `ARC-07` Export/Portabilität (offenes Format)
+- `INT-01` REST-API v1 für Mail-Zugriff
+- `SRC-01` Manticore-Suchindex für Mails
+- `SRC-07` OCR für Anhänge
+- `UX-03` Anhang-Vorschau
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-01: objekt-speicher-anbindung-fuer-mails-anhaenge`
+- Branch: `feature/arc-01-objekt-speicher-anbindung-fuer-mails-anhaenge`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-02.md b/mail-kanban/tickets/ARC-02.md
new file mode 100644
index 00000000..8578b43c
--- /dev/null
+++ b/mail-kanban/tickets/ARC-02.md
@@ -0,0 +1,67 @@
+# ARC-02 – Verschlüsselung at rest
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Verschlüsselung archivierter Mails/Anhänge at rest einführen. Der Master-Key (KEK) wird über Core `API-10` (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst.
+
+**Technische Grundlage:** Go, AES-256-GCM
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Verschlüsselung archivierter Mails/Anhänge at rest einführen, mit sicherer Schlüsselverwaltung getrennt von den verschlüsselten Daten.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-10` Master-Key-Verwaltung & -Rotation (KMS-Anbindung).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle archivierten Inhalte sind at rest verschlüsselt abgelegt
+2. Der Master-Key (KEK) wird über Core `API-10` bezogen, Schlüsselmaterial ist getrennt vom Datenspeicher verwaltet und nicht im Code
+3. Entschlüsselung ist nur mit gültigem, mandantenbezogenem Schlüssel möglich
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Zugriff auf Rohspeicher ohne Schlüssel liefert keine lesbaren Inhalte
+2. Test: falscher Mandantenschlüssel verweigert Entschlüsselung
+3. Performance-Test bestätigt akzeptablen Overhead durch Verschlüsselung
+
+## Bekannte Fehler vermeiden
+Reihenfolge beachten: SHA-256-Hash für Dublettenerkennung (ARC-03) wird auf dem Klartext berechnet, bevor diese Verschlüsselung angewendet wird — nicht danach.
+
+Master-Key-Verwaltung wurde ursprünglich unabhängig in DMS und Mail geplant — Duplikat im sicherheitskritischsten Bereich. Der Master-Key kommt jetzt zentral aus Core API-10, nur die Objekt-Verschlüsselung selbst bleibt hier.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ARC-08` Verschlüsselungsschlüssel-Rotation
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-02: verschluesselung-at-rest`
+- Branch: `feature/arc-02-verschluesselung-at-rest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-03.md b/mail-kanban/tickets/ARC-03.md
new file mode 100644
index 00000000..c7c6fe81
--- /dev/null
+++ b/mail-kanban/tickets/ARC-03.md
@@ -0,0 +1,63 @@
+# ARC-03 – Dublettenerkennung E-Mail
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.
+
+**Technische Grundlage:** Go, Hashing (SHA-256)
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Identische Nachrichten werden über Inhalts-Hash zuverlässig als Duplikat erkannt
+2. Duplikate werden referenziert statt redundant gespeichert oder klar markiert
+3. Erkennung funktioniert mandantenübergreifend korrekt getrennt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: dieselbe Nachricht aus zwei Quellen wird als Duplikat erkannt
+2. Test: zwei Mandanten mit identischem Mailinhalt werden nicht fälschlich verknüpft
+3. Test mit knapp unterschiedlichen Nachrichten bestätigt korrekte Nicht-Erkennung
+
+## Bekannte Fehler vermeiden
+Hash muss auf dem Klartext berechnet werden, nicht auf dem verschlüsselten Objekt (siehe ARC-02) — sonst erzeugt dieselbe Mail bei jedem Import einen anderen Hash und Dublettenerkennung versagt vollständig. Reihenfolge: Mail/Anhang empfangen → SHA-256 auf Klartext (dieses Ticket) → verschlüsseln (ARC-02) → Chiffretext ablegen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-03: dublettenerkennung-e-mail`
+- Branch: `feature/arc-03-dublettenerkennung-e-mail`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-04.md b/mail-kanban/tickets/ARC-04.md
new file mode 100644
index 00000000..5b74818a
--- /dev/null
+++ b/mail-kanban/tickets/ARC-04.md
@@ -0,0 +1,59 @@
+# ARC-04 – Aufbewahrungsstruktur (Mandant/Postfach/Jahr)
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.
+
+**Technische Grundlage:** Go, Objektspeicher-Pfadkonvention
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ablagestruktur folgt durchgängig dem Schema Mandant/Postfach/Jahr
+2. Struktur ist Grundlage für spätere Retention-Regeln ohne Migration
+3. Abweichende oder fehlende Metadaten führen zu definiertem Fallback-Pfad, nicht zu Ablagefehler
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Import über mehrere Jahre erzeugt korrekt getrennte Jahresordner
+2. Test: fehlendes Postfach-Attribut nutzt dokumentierten Fallback
+3. Stichprobenprüfung der Struktur durch zweite Person
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-04: aufbewahrungsstruktur-mandant-postfach-jahr`
+- Branch: `feature/arc-04-aufbewahrungsstruktur-mandant-postfach-jahr`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-05.md b/mail-kanban/tickets/ARC-05.md
new file mode 100644
index 00000000..a3c9d0f2
--- /dev/null
+++ b/mail-kanban/tickets/ARC-05.md
@@ -0,0 +1,62 @@
+# ARC-05 – Papierkorb & Soft-Delete für Mails
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.
+
+**Technische Grundlage:** Go, Postgres (Soft-Delete-Flag)
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.
+
+## Ausgangslage
+Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-03` Löschworkflow & Aufbewahrungssperre (Legal Hold) – gegen diese Sperre wird vor jeder Soft-Delete-/Endlöschung geprüft.
+
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Gelöschte Mails bleiben innerhalb der Frist wiederherstellbar
+2. Endgültige Löschung nach Fristablauf ist nachvollziehbar protokolliert
+3. Soft-Delete respektiert bestehende Aufbewahrungssperren (Litigation Hold)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Wiederherstellung innerhalb der Frist liefert unveränderten Inhalt
+2. Test: Mail mit aktiver Aufbewahrungssperre kann nicht endgültig gelöscht werden
+3. Test: Fristablauf löst automatische endgültige Löschung aus
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-05: papierkorb-soft-delete-fuer-mails`
+- Branch: `feature/arc-05-papierkorb-soft-delete-fuer-mails`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-06.md b/mail-kanban/tickets/ARC-06.md
new file mode 100644
index 00000000..1c6693e3
--- /dev/null
+++ b/mail-kanban/tickets/ARC-06.md
@@ -0,0 +1,61 @@
+# ARC-06 – Mandantentrennung im Objekt-Storage
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Physische Mandantentrennung im Objekt-Storage durchsetzen — jeder Mandant hat einen eigenen Bucket/Pfad-Root (angelegt im selben Provisioning-Schritt wie die Tenant-Datenbank, siehe Core TEN-01), keine gemeinsame Ablage mit Pfad-Präfix mehr.
+
+**Technische Grundlage:** Go, ein Bucket/Pfad-Root pro Mandant
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+- Ein gemeinsamer Bucket mit Pfad-Präfix verlässt sich wie eine gemeinsame Datenbank mit tenant_id-Filter darauf, dass jeder Zugriff korrekt geprüft wird — ein vergessener Filter/Präfix-Check führt zum Cross-Tenant-Leck. Physische Bucket-Trennung macht das strukturell unmöglich, aus demselben Grund wie bei Core TEN-01.
+
+**Für genau diese Kachel:** Physische Mandantentrennung im Objekt-Storage durchsetzen — eigener Bucket/Pfad-Root je Mandant statt gemeinsamer Ablage mit Pfad-Präfix.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kernspeicherlogik (Kompression, Tenant-Verzeichnisse, Quota) aus archivmail direkt übernehmbar, siehe repos-analyse-mail-reuse.md. Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `TEN-01` Tenant-Registry & Datenbank-Provisioning (Bucket-Provisionierung ergänzt denselben Schritt).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Mandant hat einen eigenen, physisch getrennten Bucket/Pfad-Root im Objektspeicher
+2. Ein Zugriffsversuch ohne oder mit falschem Tenant-Kontext kann technisch kein fremdes Bucket erreichen, nicht nur einen falschen Pfad
+3. Bucket-Provisionierung ist Teil desselben automatisierten Schritts wie die Tenant-Datenbank-Anlage (Core TEN-01), keine manuelle Zusatzaktion nötig
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test bestätigt physische Bucket-Trennung zweier Mandanten
+2. Simulierter Zugriffsversuch ohne Tenant-Kontext schlägt fehl, weil kein Bucket referenzierbar ist, nicht weil ein Pfadfilter greift
+3. Provisionierungs-Test legt für einen neuen Mandanten Datenbank UND Bucket in einem Schritt an
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Berechtigungsprüfung
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-06: mandantentrennung-im-speicherpfad`
+- Branch: `feature/arc-06-mandantentrennung-im-speicherpfad`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-07.md b/mail-kanban/tickets/ARC-07.md
new file mode 100644
index 00000000..c07a753d
--- /dev/null
+++ b/mail-kanban/tickets/ARC-07.md
@@ -0,0 +1,60 @@
+# ARC-07 – Export/Portabilität (offenes Format)
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.
+
+**Technische Grundlage:** Go, mbox/eml-Export
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Export erzeugt vollständige, standardkonforme mbox- oder eml-Dateien
+2. Anhänge bleiben im Export erhalten und sind referenziell konsistent
+3. Export ist mandantenweise abgrenzbar und nachvollziehbar protokolliert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: exportierte Datei lässt sich mit gängigem Mail-Client importieren
+2. Test: Export enthält keine Daten anderer Mandanten
+3. Stichprobenvergleich Original vs. Export bestätigt Inhaltstreue
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-07: export-portabilitaet-offenes-format`
+- Branch: `feature/arc-07-export-portabilitaet-offenes-format`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-08.md b/mail-kanban/tickets/ARC-08.md
new file mode 100644
index 00000000..5b9b1f97
--- /dev/null
+++ b/mail-kanban/tickets/ARC-08.md
@@ -0,0 +1,60 @@
+# ARC-08 – Verschlüsselungsschlüssel-Rotation
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).
+
+**Technische Grundlage:** Go, Envelope-Encryption
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- Alfresco: Aufbewahrungsstruktur und Audit-Anbindung von Beginn an mitgedacht.
+
+**Bewusst vermeiden:**
+- archivmail – Restore-Bug bei nicht-leerem Zielverzeichnis.: Wiederherstellung ausschließlich über leeres Temp-Verzeichnis mit atomarem Swap.
+
+**Für genau diese Kachel:** Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-02 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neue Datenschlüssel werden über einen Hauptschlüssel gewrappt und rotierbar verwaltet
+2. Rotation des Hauptschlüssels erfordert kein Neuverschlüsseln des gesamten Archivbestands
+3. Alte Schlüsselversionen bleiben für Lesezugriff auf Altbestand kontrolliert verfügbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Rotation des Hauptschlüssels lässt Altbestand weiterhin lesbar
+2. Test: kompromittierter alter Schlüssel kann gezielt gesperrt werden
+3. Dokumentierter Rotationsvorgang wurde einmal vollständig durchgespielt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-03` Prüfgate Archivierung & Suche
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-08: verschluesselungsschluessel-rotation`
+- Branch: `feature/arc-08-verschluesselungsschluessel-rotation`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-09.md b/mail-kanban/tickets/ARC-09.md
new file mode 100644
index 00000000..ff53bce9
--- /dev/null
+++ b/mail-kanban/tickets/ARC-09.md
@@ -0,0 +1,63 @@
+# ARC-09 – Postfach-Quota
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.
+
+**Technische Grundlage:** Go, Postgres, tenant_id
+
+## Produkt-DNA für diesen Bereich
+> Einmal archivierte E-Mail ist unveränderlich und jederzeit auffindbar – Revisionssicherheit wie bei ecoDMS, Aufbewahrung wie bei Alfresco.
+
+**Übernehmen:**
+- Dovecot: Quota-Plugin-Konzept, pro Mailbox konfigurierbar.
+
+**Bewusst vermeiden:**
+- Ein einzelnes überfülltes Postfach darf nie andere Postfächer desselben Tenants beeinträchtigen – Quota ist strikt pro Postfach durchgesetzt, nicht als Tenant-weiter Summen-Topf.
+
+**Für genau diese Kachel:** Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01, IMP-07 sind auf Fertig.
+
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `LIC-05` Speicherverbrauch-Metrik je Tenant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Speicherlimit ist je Postfach konfigurierbar, unabhängig von der Tenant-weiten Quota aus Core LIC-05
+2. Postfach am Limit lehnt neue eingehende Mail mit klarer, protokollgerechter Fehlermeldung ab (SMTP-Rückweisung), verwirft nicht stillschweigend
+3. Ein Postfach am Limit beeinträchtigt keine anderen Postfächer desselben Tenants
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Postfach-Quota erreicht, neue eingehende Mail wird mit korrekter SMTP-Fehlermeldung abgelehnt
+2. Test: anderes Postfach desselben Tenants empfängt weiterhin normal, während eines am Limit ist
+3. Verbrauchsanzeige je Postfach im Test korrekt gegen tatsächliche Größe geprüft
+
+## Bekannte Fehler vermeiden
+- **Tenant-weite Speicherquota (Core LIC-05) und Postfach-Quota sind unterschiedliche Ebenen** – ein Tenant kann insgesamt genug Kontingent haben, während ein einzelnes Postfach durch Missbrauch oder Fehlkonfiguration überläuft. Beide Ebenen unabhängig durchsetzen, nicht nur eine.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-09: postfach-quota`
+- Branch: `feature/arc-09-postfach-quota`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ARC-10.md b/mail-kanban/tickets/ARC-10.md
new file mode 100644
index 00000000..9d1533b3
--- /dev/null
+++ b/mail-kanban/tickets/ARC-10.md
@@ -0,0 +1,69 @@
+# ARC-10 – Signatur- und Zeitstempelerhalt (BSI TR-03125)
+
+**Epic:** 🗄️ Archivierung & Speicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und das Prüfergebnis inklusive vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Ablauf des Signaturzertifikats nachweisbar bleibt (BSI TR-03125, Modul B.4 „Übernahme kryptographisch signierter Unterlagen"). Kein eigenes Langzeitarchivierungs-/ArchiSig-Verfahren mit periodischer Neu-Zeitstempelung – ein EINMALIGER, bei Archivierung erzeugter Prüfnachweis reicht für den Anwendungsfall (KMU-E-Mail-Archivierung, kein qualifiziertes elektronisches Archiv nach eIDAS).
+
+**Technische Grundlage:** Go (`crypto/x509`, S/MIME-/PGP-Signaturprüfung), RFC-3161-Zeitstempel-Client (optional gegen externe TSA) oder lokal vertrauenswürdiger Zeitstempel als Fallback
+
+## Produkt-DNA für diesen Bereich
+> Was signiert ankommt, muss auch signiert nachweisbar bleiben – nicht nur unverändert gespeichert.
+
+**Übernehmen:**
+- archivmail-Speicherschicht (Kompression, Tenant-Verzeichnisse, Quota) als Basis, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: Revisionssichere, unveränderliche Ablage als Grundprinzip.
+- BSI TR-03125: Prüfergebnis + Zeitpunkt der Prüfung werden ARCHIVIERT, nicht nur einmalig zur Laufzeit berechnet und verworfen.
+
+**Bewusst vermeiden:**
+- Ein vollständiges ArchiSig-/Merkle-Baum-Verfahren mit periodischer Neu-Zeitstempelung aller archivierten Signaturen: für den Anwendungsfall (KMU-Mailarchiv, keine gesetzliche Pflicht zum qualifizierten elektronischen Archiv) unverhältnismäßiger Aufwand. Ein einmaliger, bei Ingestion erzeugter Prüfnachweis ist ausreichend und wird durch das ohnehin unveränderliche Audit-Log (Core `AUD-02`) vor nachträglicher Manipulation geschützt.
+- Erzwungene Signaturprüfung für ALLE Mails: die überwiegende Mehrheit unsignierter Mails darf durch diese Kachel nicht verlangsamt werden – Prüfung läuft nur für tatsächlich signierte Nachrichten.
+
+**Für genau diese Kachel:** Bisher zurückgestellte Lücke aus dem Vorgängerprojekt archivmail (siehe `repos/archivmail/docs/GOBD_DSGVO_CHECKLIST.md`, Punkt 12) – jetzt mit einer bewusst schlanken, verhältnismäßigen Lösung geschlossen statt weiter unbearbeitet zu bleiben.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ING-04` MIME- & Anhang-Parsing – liefert die geparste MIME-Struktur, aus der signierte Teile (`multipart/signed`, `application/pkcs7-mime`) erkennbar sind.
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Original-Bytes werden unverändert gespeichert; dieses Ticket ergänzt nur zusätzliche Metadaten, ändert nichts an der Speicherung selbst.
+
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `AUD-01`/`AUD-02` Zentrales, unveränderliches Audit-Log-Modell – der Prüfnachweis wird dort abgelegt, kein zweites Protokoll.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Signierte Mails (S/MIME und PGP/MIME) werden bei Archivierung erkannt, unsignierte Mails durchlaufen KEINE zusätzliche Prüfung
+2. Signaturprüfergebnis (gültig/ungültig/Prüfung nicht möglich, Zertifikatsdaten, Prüfzeitpunkt) wird unveränderlich mitarchiviert – auch wenn das Signaturzertifikat später abläuft, bleibt nachweisbar, DASS es zum Archivierungszeitpunkt gültig war
+3. Prüfnachweis ist über die Mail-Detailansicht abrufbar, ohne die Original-Mail zu verändern
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit einer echten S/MIME-signierten Testmail: Prüfergebnis "gültig" korrekt erkannt und archiviert
+2. Test mit einer signierten Mail mit MANIPULIERTEM Inhalt: Prüfergebnis "ungültig" korrekt erkannt
+3. Simulierter Zertifikatsablauf NACH Archivierung: archivierter Prüfnachweis bleibt unverändert abrufbar und zeigt weiterhin "zum Prüfzeitpunkt gültig"
+
+## Bekannte Fehler vermeiden
+archivmail hat Zeitstempel-/Signaturerhalt komplett zurückgestellt (siehe `repos/archivmail/docs/GOBD_DSGVO_CHECKLIST.md`, Punkt 12) – dieses Ticket schließt die Lücke bewusst schlank statt sie erneut zu verschieben, ohne dabei ein für den Anwendungsfall unverhältnismäßiges volles Langzeitarchivierungsverfahren zu bauen (siehe "Bewusst vermeiden").
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Periodische Neu-Zeitstempelung/ArchiSig-Verfahren für sehr lange Aufbewahrungszeiträume (nicht geplant, siehe "Bewusst vermeiden")
+- MIME-Parsing selbst (`ING-04`)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ARC-10: signatur-zeitstempelerhalt-bsi-tr-03125`
+- Branch: `feature/arc-10-signatur-zeitstempelerhalt-bsi-tr-03125`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-01.md b/mail-kanban/tickets/IMP-01.md
new file mode 100644
index 00000000..b4238a69
--- /dev/null
+++ b/mail-kanban/tickets/IMP-01.md
@@ -0,0 +1,69 @@
+# IMP-01 – IMAP-Postfach-Abruf & Scheduler
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.
+
+**Technische Grundlage:** Go, Postgres-Jobqueue, IMAP4rev1
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-05 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Scheduler erkennt neue Nachrichten seit letztem Abruf zuverlässig über UID-Vergleich
+2. Zustandsänderungen (gelesen/gelöscht) werden ohne Doppelimport übernommen
+3. Abrufintervall ist je Postfach konfigurierbar und übersteht Neustarts des Dienstes
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: zwei aufeinanderfolgende Läufe importieren keine Nachricht doppelt
+2. Test: simulierter Dienst-Neustart mitten im Abgleich führt zu konsistentem Endzustand
+3. Test gegen Testpostfach mit realistischem Nachrichtenaufkommen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-02` Anhangsverarbeitung bei Import
+- `IMP-03` E-Mail-Regeln (Zuordnung/Tags/Klassifizierung)
+- `IMP-04` Fehlerbehandlung nicht-konformer Server
+- `IMP-05` Hot-Folder/Scanner-Anbindung
+- `IMP-07` Mehrfach-Postfach-Verwaltung pro Tenant
+- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall
+- `IMP-09` Import-Testsuite
+- `INT-05` Benachrichtigungs-Service "neue Mail"
+- `UX-01` Postfach- & Ordneransicht
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-01: imap-postfach-abruf-scheduler`
+- Branch: `feature/imp-01-imap-postfach-abruf-scheduler`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-02.md b/mail-kanban/tickets/IMP-02.md
new file mode 100644
index 00000000..78566f28
--- /dev/null
+++ b/mail-kanban/tickets/IMP-02.md
@@ -0,0 +1,62 @@
+# IMP-02 – Anhangsverarbeitung bei Import
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.
+
+**Technische Grundlage:** Go, mime/multipart
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-04, IMP-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (MIME-/Charset-Parsing mit Tests), siehe repos-analyse-mail-reuse.md. Speicherbomben-Risiko beim Anhang-Lesen muss vor Übernahme behoben werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Anhänge werden mit Originaldateiname, Größe und geprüftem Content-Type extrahiert
+2. Größenlimit pro Anhang und pro Nachricht wird durchgesetzt
+3. Fehlerhafte Anhänge blockieren nicht den Import der restlichen Nachricht
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit Nachricht, die einen überdimensionierten Anhang enthält, wird korrekt begrenzt
+2. Test mit mehreren Anhängen unterschiedlichen Typs importiert alle korrekt
+3. Test: ein defekter Anhang lässt Text und übrige Anhänge unangetastet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-06` Anhangs-Virenscan-Anbindung
+- `IMP-09` Import-Testsuite
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-02: anhangsverarbeitung-bei-import`
+- Branch: `feature/imp-02-anhangsverarbeitung-bei-import`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-03.md b/mail-kanban/tickets/IMP-03.md
new file mode 100644
index 00000000..339e5029
--- /dev/null
+++ b/mail-kanban/tickets/IMP-03.md
@@ -0,0 +1,62 @@
+# IMP-03 – E-Mail-Regeln (Zuordnung/Tags/Klassifizierung)
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.
+
+**Technische Grundlage:** Go, Postgres
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Regeln lassen sich nach Absender, Betreff-Muster und Postfach definieren
+2. Mehrere zutreffende Regeln werden nach dokumentierter Priorität angewendet
+3. Regeländerungen wirken nur auf künftige Importe, nicht rückwirkend ohne expliziten Reindex-Auftrag
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit widersprüchlichen Regeln bestätigt dokumentierte Priorisierung
+2. Test: neue Regel ändert keine bereits importierten Altbestände automatisch
+3. Regelset mit 20+ Regeln bleibt performant auswertbar
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-09` Import-Testsuite
+- `INT-06` E-Mail-Regel-Engine über API steuerbar
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-03: e-mail-regeln-zuordnung-tags-klassifizierung`
+- Branch: `feature/imp-03-e-mail-regeln-zuordnung-tags-klassifizierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-04.md b/mail-kanban/tickets/IMP-04.md
new file mode 100644
index 00000000..feca0f60
--- /dev/null
+++ b/mail-kanban/tickets/IMP-04.md
@@ -0,0 +1,64 @@
+# IMP-04 – Fehlerbehandlung nicht-konformer Server
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.
+
+**Technische Grundlage:** Go, IMAP4rev1
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Bekannte Abweichungen (u. a. UIDVALIDITY=0) führen zu definiertem Fallback statt Sync-Abbruch
+2. Unerwartete Serverantworten werden geloggt und übersprungen statt den gesamten Lauf zu stoppen
+3. Fallback-Verhalten ist dokumentiert und für Support nachvollziehbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback
+2. Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten
+3. Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #5: In einer früheren Implementierung führte `UIDVALIDITY=0` bei nicht-konformen Servern zu einem Resync-Abbruch. Für diese Kachel verbindlich: defensive Validierung von UIDVALIDITY/UIDNEXT mit dokumentiertem Fallback-Pfad, dazu ein Regressionstest, der genau dieses Szenario abdeckt.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-04: fehlerbehandlung-nicht-konformer-server`
+- Branch: `feature/imp-04-fehlerbehandlung-nicht-konformer-server`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-05.md b/mail-kanban/tickets/IMP-05.md
new file mode 100644
index 00000000..eec1fa7a
--- /dev/null
+++ b/mail-kanban/tickets/IMP-05.md
@@ -0,0 +1,61 @@
+# IMP-05 – Hot-Folder/Scanner-Anbindung
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.
+
+**Technische Grundlage:** Go, fsnotify
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Dateien in konfiguriertem Hot-Folder werden erkannt und dem richtigen Mandanten/Postfach zugeordnet
+2. Bereits verarbeitete Dateien werden nicht doppelt importiert
+3. Fehlerhafte Dateien werden in einen Fehlerordner verschoben statt den Scan-Lauf zu blockieren
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: gleiche Datei zweimal abgelegt wird nur einmal importiert
+2. Test: fehlerhafte Datei landet nachvollziehbar im Fehlerordner
+3. Dauertest über mehrere Scan-Zyklen ohne Ressourcenleck
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-05: hot-folder-scanner-anbindung`
+- Branch: `feature/imp-05-hot-folder-scanner-anbindung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-06.md b/mail-kanban/tickets/IMP-06.md
new file mode 100644
index 00000000..e6d86bb3
--- /dev/null
+++ b/mail-kanban/tickets/IMP-06.md
@@ -0,0 +1,61 @@
+# IMP-06 – Anhangs-Virenscan-Anbindung
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.
+
+**Technische Grundlage:** Go, ClamAV-kompatible Anbindung
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-02 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder importierte Anhang wird vor Archivierung durch den Virenscanner geprüft
+2. Positiver Fund führt zu Quarantäne des Anhangs statt automatischer Archivierung
+3. Scanner-Ausfall blockiert den Import nicht unbegrenzt, sondern führt zu definiertem Fehlerzustand
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit EICAR-Testdatei bestätigt Quarantäne-Verhalten
+2. Test: Scanner nicht erreichbar führt zu klar sichtbarem Fehlerzustand statt Hänger
+3. Durchsatztest bestätigt akzeptable Verzögerung durch Scan-Schritt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-06: anhangs-virenscan-anbindung`
+- Branch: `feature/imp-06-anhangs-virenscan-anbindung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-07.md b/mail-kanban/tickets/IMP-07.md
new file mode 100644
index 00000000..78d0d33a
--- /dev/null
+++ b/mail-kanban/tickets/IMP-07.md
@@ -0,0 +1,61 @@
+# IMP-07 – Mehrfach-Postfach-Verwaltung pro Tenant
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.
+
+**Technische Grundlage:** Go, Postgres, tenant_id
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Setzt voraus: NEXARCH-Core TEN-01/TEN-02 (Tenant-Datenmodell & Onboarding) aus core-kanban/ sind verfügbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ein Mandant kann mehrere Postfächer unabhängig voneinander konfigurieren
+2. Jedes Postfach hat eigene Abrufparameter (Intervall, Zugangsdaten, Ordnerauswahl)
+3. Postfach-Liste ist strikt nach tenant_id gefiltert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: zwei Mandanten mit je mehreren Postfächern sehen ausschließlich eigene Postfächer
+2. Test: Löschen eines Postfachs beeinträchtigt andere Postfächer desselben Mandanten nicht
+3. Konfigurationsänderung an einem Postfach wirkt nicht auf andere
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-07: mehrfach-postfach-verwaltung-pro-tenant`
+- Branch: `feature/imp-07-mehrfach-postfach-verwaltung-pro-tenant`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-08.md b/mail-kanban/tickets/IMP-08.md
new file mode 100644
index 00000000..e888f853
--- /dev/null
+++ b/mail-kanban/tickets/IMP-08.md
@@ -0,0 +1,63 @@
+# IMP-08 – Fehler-Benachrichtigung bei Postfach-Sync-Ausfall
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.
+
+**Technische Grundlage:** Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch.
+
+## Ausgangslage
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher – zentraler Versandweg für alle Module, kein eigener E-Mail-Versand je Modul.
+
+Setzt innerhalb dieses Boards voraus: IMP-01, IMP-04 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Wiederholte Sync-Fehlschläge über konfigurierbarer Schwelle lösen genau ein Ereignis an Core CFG-02 aus, nicht selbst versendet
+2. Benachrichtigung enthält Postfach, Fehlerursache und Zeitpunkt des letzten erfolgreichen Abrufs
+3. Erfolgreicher Sync nach Ausfall setzt den Alarmzustand zurück
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: N aufeinanderfolgende Fehlschläge lösen genau eine Benachrichtigung aus, keine Spam-Flut
+2. Test: erfolgreicher Lauf nach Ausfall beendet den Alarmzustand nachvollziehbar
+3. Test mit mehreren betroffenen Postfächern gleichzeitig bleibt übersichtlich
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-08: fehler-benachrichtigung-bei-postfach-sync-ausfall`
+- Branch: `feature/imp-08-fehler-benachrichtigung-bei-postfach-sync-ausfall`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-09.md b/mail-kanban/tickets/IMP-09.md
new file mode 100644
index 00000000..7bc3d861
--- /dev/null
+++ b/mail-kanban/tickets/IMP-09.md
@@ -0,0 +1,64 @@
+# IMP-09 – Import-Testsuite
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.
+
+**Technische Grundlage:** Go testing, testify
+
+## Produkt-DNA für diesen Bereich
+> Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver – Konzept aus archivmail nutzbar, Testlücken werden geschlossen.
+
+**Übernehmen:**
+- archivmail-Scheduler-Konzept (UID-Sync, Delta-Import) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Mailpit/MailHog: Mailflows automatisiert und reproduzierbar testen statt gegen Live-Postfächer.
+- Dovecot: robuste Behandlung von Protokollabweichungen einzelner Server-Implementierungen.
+
+**Bewusst vermeiden:**
+- archivmail – UIDVALIDITY=0 bricht Resync bei nicht-konformen Servern.: defensive Validierung mit dokumentierten Fallback-Pfaden.
+- archivmail – Import-Pfade praktisch ungetestet.: Pflicht-Testsuite vor Übernahme von Bestandscode.
+
+**Für genau diese Kachel:** Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01, IMP-02, IMP-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Importpfad hat automatisierte Tests für Normal- und Fehlerfall
+2. Tenant-Scoping ist für Postfach-Abruf und Regelanwendung durch eigene Tests abgedeckt
+3. Testsuite läuft reproduzierbar in CI ohne echte externe Postfächer
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testabdeckungsbericht für Scheduler, Anhangsverarbeitung und Regeln liegt vor
+2. CI-Lauf grün auf frischem Checkout
+3. Stichprobenreview bestätigt sinnvolle Testfälle für nicht-konforme Server-Szenarien
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #4: In einer früheren Implementierung waren Import-nahe Module praktisch ungetestet. Für diese Kachel verbindlich: Pflichttests für Tenant-Scoping und Protokoll-/Import-Zustandsmaschinen sind Abnahmevoraussetzung, kein Nachziehen nach Feature-Fertigstellung.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-02` Prüfgate Ingestion & Import
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `IMP-09: import-testsuite`
+- Branch: `feature/imp-09-import-testsuite`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/IMP-10.md b/mail-kanban/tickets/IMP-10.md
new file mode 100644
index 00000000..e4830c63
--- /dev/null
+++ b/mail-kanban/tickets/IMP-10.md
@@ -0,0 +1,58 @@
+# IMP-10 – IMAP-Import: TLS erzwingen und Befehle sicher bauen
+
+**Epic:** 🔄 Postfach-Import & Synchronisierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+`mail/internal/imapimport/client_real.go` verbindet ohne TLS und baut `LOGIN` und `SELECT` durch Verkettung aus Benutzername, Passwort und Postfachname ohne Anführungszeichen oder Prüfung auf Zeilenumbrüche (Befund F-19, heute nicht verdrahtet und damit latent).
+
+**Technische Grundlage:** `mail/internal/imapimport`; Vorbild: DMS `mailimport` mit `go-imap` (INT-03)
+
+## Produkt-DNA für diesen Bereich
+> Zugangsdaten gehen nur verschlüsselt über das Netz und nie in einen Befehl, der sich einschleusen lässt.
+
+**Übernehmen:**
+- Testserver aus INT-03.
+
+**Bewusst vermeiden:**
+- Kein Klartext-IMAP, keine Befehlsverkettung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-15` Sicherheitsprüfung Gesamtprojekt – Befundbericht `docs/SICHERHEITSPRUEFUNG-GESAMTPROJEKT.md`, hier: F-19 (mittel, latent).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die Verbindung erfordert TLS (Implicit oder STARTTLS); Klartext nur mit ausdrücklichem Schalter für Tests
+2. Argumente werden quotiert; Steuerzeichen und Zeilenumbrüche in Benutzername, Passwort und Postfachname werden abgewiesen
+3. Ein Angriffstest mit `\r\n`-Einschleusung erreicht keinen zweiten Befehl
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Tests gegen den In-Process-IMAP-Server
+2. Kein Passwort im Log oder in Fehlern
+3. Verdrahtung des Importmoduls wird erst nach diesem Ticket freigegeben
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Mail-API (eigenes Ticket)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Status: offen – in Phase 2b bewusst nicht umgesetzt: Mail-Import ist nicht verdrahtet; wird kritisch, sobald er angeschlossen wird
+- Commit-Nachricht: `IMP-10: imap-import mit tls und sicheren befehlen`
+- Branch: `feature/imp-10-imap-tls-befehle`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-01.md b/mail-kanban/tickets/ING-01.md
new file mode 100644
index 00000000..860ac25b
--- /dev/null
+++ b/mail-kanban/tickets/ING-01.md
@@ -0,0 +1,68 @@
+# ING-01 – IMAP-Server-Grundgerüst
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).
+
+**Technische Grundlage:** Go/net, IMAP4rev1 (RFC 3501)
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).
+
+## Ausgangslage
+Diese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Server nimmt IMAP-Verbindungen an und durchläuft die drei Standard-Zustände korrekt
+2. Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT) sind implementiert und beantwortet
+3. Ungültige Kommandosequenzen werden mit korrektem IMAP-Fehlercode abgelehnt, nicht mit Verbindungsabbruch
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manuelle Session mit Standard-IMAP-Client durchgespielt und protokolliert
+2. Automatisierter Test deckt alle drei Zustandsübergänge und deren verbotene Übergänge ab
+3. Lasttest mit 50 parallelen Sessions ohne Ressourcenleck
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-01` IMAP-Postfach-Abruf & Scheduler
+- `ING-02` POP3-Server
+- `ING-05` Folder-State & UIDVALIDITY-Handling
+- `ING-06` TLS/STARTTLS-Absicherung
+- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung
+- `ING-08` Mailserver-Protokoll-Logging & Diagnose
+- `ING-10` Ingestion-Testsuite
+- `QA-07` Last- & Leistungstest
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-01: imap-server-grundgeruest`
+- Branch: `feature/ing-01-imap-server-grundgeruest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-02.md b/mail-kanban/tickets/ING-02.md
new file mode 100644
index 00000000..4b5125d7
--- /dev/null
+++ b/mail-kanban/tickets/ING-02.md
@@ -0,0 +1,65 @@
+# ING-02 – POP3-Server
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.
+
+**Technische Grundlage:** Go/net, POP3 (RFC 1939)
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (POP3-Server), siehe repos-analyse-mail-reuse.md. Bislang ungetestet – Testsuite ist Voraussetzung für Übernahme.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Server durchläuft alle drei POP3-Zustände korrekt
+2. RETR liefert vollständige Nachrichten, DELE markiert erst im Update-Zustand endgültig
+3. Fehlerhafte Anmeldeversuche werden ohne Informationspreisgabe abgelehnt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Automatisierter Test für jede Zustandsübergangs-Regel
+2. Test mit Standard-POP3-Client (z. B. via Skript) gegen Test-Postfach
+3. Test: DELE ohne anschließendes QUIT löscht nichts endgültig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ING-06` TLS/STARTTLS-Absicherung
+- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung
+- `ING-08` Mailserver-Protokoll-Logging & Diagnose
+- `ING-10` Ingestion-Testsuite
+- `QA-07` Last- & Leistungstest
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-02: pop3-server`
+- Branch: `feature/ing-02-pop3-server`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-03.md b/mail-kanban/tickets/ING-03.md
new file mode 100644
index 00000000..fb63a0b1
--- /dev/null
+++ b/mail-kanban/tickets/ING-03.md
@@ -0,0 +1,69 @@
+# ING-03 – SMTP-Server & Mailer
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).
+
+**Technische Grundlage:** Go/net/smtp, net/mail, SMTP (RFC 5321)
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).
+
+## Ausgangslage
+Diese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (SMTP-Annahme, Mail-Templates), siehe repos-analyse-mail-reuse.md. Header-Injection-Bug muss vor Übernahme zwingend gefixt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. SMTP-Annahme validiert Envelope und Nachrichtengröße vor der Annahme
+2. Mailer erzeugt Header ausschließlich über strukturierte Writer-API, keine freie Stringkonkatenation
+3. Ungültige Empfängerdaten führen zu sauberer SMTP-Fehlermeldung statt Absturz
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit Steuerzeichen/CRLF in Betreff und Anzeigenamen schlägt fehl bzw. wird bereinigt, kein Header-Bruch möglich
+2. Automatisierter Test sendet Testmail über Mailpit/MailHog und prüft Header-Integrität
+3. Lasttest mit gleichzeitigen Verbindungen ohne Verbindungsleck
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #1: In einer früheren Implementierung wurden From/To/Subject-Header per Stringkonkatenation ohne CRLF-Validierung zusammengebaut – das öffnet Header-Injection. Für diese Kachel verbindlich: Ausgabe ausschließlich über `net/mail`-kompatiblen Writer erzeugen oder jeden Headerwert hart gegen CRLF/Steuerzeichen validieren, bevor er geschrieben wird. Kein Wiederaufgreifen des alten Konkatenationsmusters.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ING-06` TLS/STARTTLS-Absicherung
+- `ING-08` Mailserver-Protokoll-Logging & Diagnose
+- `ING-09` Rate-Limiting auf Protokollebene
+- `ING-10` Ingestion-Testsuite
+- `QA-04` Sicherheits- & Berechtigungsprüfung
+- `QA-07` Last- & Leistungstest
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-03: smtp-server-mailer`
+- Branch: `feature/ing-03-smtp-server-mailer`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-04.md b/mail-kanban/tickets/ING-04.md
new file mode 100644
index 00000000..0a10ce74
--- /dev/null
+++ b/mail-kanban/tickets/ING-04.md
@@ -0,0 +1,66 @@
+# ING-04 – MIME- & Anhang-Parsing
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.
+
+**Technische Grundlage:** Go, encoding/mime, mime/multipart
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.
+
+## Ausgangslage
+Diese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Konzept aus archivmail als Vorlage nutzbar (MIME-/Charset-Parsing mit Tests), siehe repos-analyse-mail-reuse.md. Speicherbomben-Risiko beim Anhang-Lesen muss vor Übernahme behoben werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Multipart-Nachrichten mit verschachtelten Teilen werden vollständig zerlegt
+2. Anhänge werden mit korrektem Dateinamen, Größe und Content-Type extrahiert
+3. Fehlerhafte/inkonsistente Zeichensatzangaben werden defensiv repariert statt die Verarbeitung abzubrechen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit sehr großem simuliertem Anhang bestätigt harte Ablehnung statt Speicheranstieg
+2. Testkorpus mit realitätsnahen Multipart-/Encoding-Varianten läuft fehlerfrei durch
+3. Fuzz-/Grenzwerttest mit kaputten MIME-Strukturen bricht kontrolliert ab, kein Absturz
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #3: Eine frühere Implementierung las Anhänge über `io.ReadAll` ohne Größenlimit ein, was eine Speicherbombe durch große oder böswillig präparierte Anhänge ermöglicht. Für diese Kachel verbindlich: jeder Anhang-Lesevorgang läuft über `io.LimitReader` mit konfigurierter Max-Size, Überschreitung führt zu harter, sauberer Ablehnung statt stillem Abschneiden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge
+- `IMP-02` Anhangsverarbeitung bei Import
+- `ING-10` Ingestion-Testsuite
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-04: mime-anhang-parsing`
+- Branch: `feature/ing-04-mime-anhang-parsing`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-05.md b/mail-kanban/tickets/ING-05.md
new file mode 100644
index 00000000..5561d3ee
--- /dev/null
+++ b/mail-kanban/tickets/ING-05.md
@@ -0,0 +1,62 @@
+# ING-05 – Folder-State & UIDVALIDITY-Handling
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.
+
+**Technische Grundlage:** Go, IMAP4rev1 (RFC 3501 §2.3.1.1)
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Ordner führt UIDVALIDITY und UIDNEXT korrekt gemäß RFC nach
+2. Ordnerwechsel (SELECT/EXAMINE) liefert konsistenten State auch bei parallelem Zugriff
+3. State-Änderungen (neue Mail, Löschung) werden atomar und nachvollziehbar persistiert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau
+2. Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz
+3. Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IMP-01` IMAP-Postfach-Abruf & Scheduler
+- `ING-10` Ingestion-Testsuite
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-05: folder-state-uidvalidity-handling`
+- Branch: `feature/ing-05-folder-state-uidvalidity-handling`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-06.md b/mail-kanban/tickets/ING-06.md
new file mode 100644
index 00000000..246cf9c0
--- /dev/null
+++ b/mail-kanban/tickets/ING-06.md
@@ -0,0 +1,61 @@
+# ING-06 – TLS/STARTTLS-Absicherung
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.
+
+**Technische Grundlage:** Go crypto/tls, STARTTLS
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Setzt voraus: NEXARCH-Core-Zertifikats-/TLS-Konventionen aus core-kanban/ (siehe CFG-Epic) sind verfügbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Anmeldedaten werden ausschließlich über TLS oder nach erfolgreichem STARTTLS akzeptiert
+2. Schwache Cipher-Suiten und veraltete TLS-Versionen sind serverseitig deaktiviert
+3. Zertifikatswechsel ist ohne Verbindungsabriss für bestehende Sessions möglich
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Scan mit Standard-TLS-Prüfwerkzeug bestätigt keine schwachen Suiten
+2. Test: Login-Versuch ohne TLS/STARTTLS wird verweigert
+3. Test: Zertifikatsrotation im laufenden Betrieb ohne Dienstunterbrechung
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-06: tls-starttls-absicherung`
+- Branch: `feature/ing-06-tls-starttls-absicherung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-07.md b/mail-kanban/tickets/ING-07.md
new file mode 100644
index 00000000..6fae492f
--- /dev/null
+++ b/mail-kanban/tickets/ING-07.md
@@ -0,0 +1,61 @@
+# ING-07 – Protokoll-Fehlerbehandlung & Wiederverbindung
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.
+
+**Technische Grundlage:** Go, net, context
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-02 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (IMAP-Protokoll/Folder-State/Scheduler), siehe repos-analyse-mail-reuse.md. Testabdeckung muss vor Übernahme nachgezogen werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Verbindungsabbrüche räumen serverseitige Session-Ressourcen zuverlässig auf
+2. Timeouts sind pro Protokollphase konfigurierbar und greifen nachweislich
+3. Wiederholte Fehlversuche eines Clients führen zu klar definiertem Backoff statt Dauerschleife
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Chaos-Test: Verbindung wird während aktiver Übertragung hart gekappt, kein Ressourcenleck danach
+2. Test für Timeout-Auslösung in jeder Protokollphase
+3. Test für Backoff-Verhalten bei wiederholten Fehlversuchen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-07: protokoll-fehlerbehandlung-wiederverbindung`
+- Branch: `feature/ing-07-protokoll-fehlerbehandlung-wiederverbindung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-08.md b/mail-kanban/tickets/ING-08.md
new file mode 100644
index 00000000..0b604726
--- /dev/null
+++ b/mail-kanban/tickets/ING-08.md
@@ -0,0 +1,61 @@
+# ING-08 – Mailserver-Protokoll-Logging & Diagnose
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.
+
+**Technische Grundlage:** Go, structured logging (slog)
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Session erzeugt strukturierte Logs mit Korrelations-ID über die gesamte Verbindungsdauer
+2. Zugangsdaten und Nachrichteninhalte erscheinen nie im Klartext im Log
+3. Diagnosewerkzeug kann eine einzelne Session anhand der Korrelations-ID vollständig nachvollziehen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test bestätigt Redaktion sensibler Felder in allen Log-Pfaden
+2. Stichprobe: eine komplette Session ist über die Korrelations-ID lückenlos rekonstruierbar
+3. Lasttest bestätigt, dass Logging die Durchsatzrate nicht relevant beeinträchtigt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-08: mailserver-protokoll-logging-diagnose`
+- Branch: `feature/ing-08-mailserver-protokoll-logging-diagnose`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-09.md b/mail-kanban/tickets/ING-09.md
new file mode 100644
index 00000000..8ea673f2
--- /dev/null
+++ b/mail-kanban/tickets/ING-09.md
@@ -0,0 +1,61 @@
+# ING-09 – Rate-Limiting auf Protokollebene
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.
+
+**Technische Grundlage:** Go, Postgres-Jobqueue, Token-Bucket
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Login-Versuche pro Quelle/Zeitfenster sind begrenzt und konfigurierbar
+2. SMTP-Annahmerate pro Absender/Quelle ist begrenzt und konfigurierbar
+3. Überschreitung führt zu definierter Ablehnung mit Wartezeit-Hinweis, nicht zu Verbindungsabbruch ohne Erklärung
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Lasttest bestätigt greifendes Limit bei Überschreitung
+2. Test: legitime Nutzung unterhalb der Schwelle bleibt unbeeinträchtigt
+3. Test: Limit ist je Mandant getrennt konfigurierbar und wirksam
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-09: rate-limiting-auf-protokollebene`
+- Branch: `feature/ing-09-rate-limiting-auf-protokollebene`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-10.md b/mail-kanban/tickets/ING-10.md
new file mode 100644
index 00000000..45aa35e4
--- /dev/null
+++ b/mail-kanban/tickets/ING-10.md
@@ -0,0 +1,64 @@
+# ING-10 – Ingestion-Testsuite
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.
+
+**Technische Grundlage:** Go testing, testify, Mailpit/MailHog
+
+## Produkt-DNA für diesen Bereich
+> Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.
+
+**Übernehmen:**
+- Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.
+- Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.
+- Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht.
+
+**Bewusst vermeiden:**
+- archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.
+- archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge.
+
+**Für genau diese Kachel:** Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03, ING-04, ING-05 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Protokoll-Zustandsmaschine hat automatisierte Tests für erlaubte und verbotene Übergänge
+2. Tenant-Scoping ist für jeden Ingestion-Pfad durch einen eigenen Test abgedeckt
+3. Testsuite läuft reproduzierbar in der CI ohne externe Live-Postfächer
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testabdeckungsbericht für alle fünf Ingestion-Module liegt vor
+2. CI-Lauf grün auf frischem Checkout ohne manuelle Nacharbeit
+3. Stichprobenreview durch zweite Person bestätigt sinnvolle Testfälle, nicht nur Zeilenabdeckung
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #4: In einer früheren Implementierung waren nur 2 von 18 Modulen getestet, obwohl die Protokoll-Server-Logik hochkritisch ist. Für diese Kachel verbindlich: Pflichttests für Tenant-Scoping und für jede Protokoll-Zustandsmaschine sind Voraussetzung für die Abnahme, nicht optional nachgezogen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-02` Prüfgate Ingestion & Import
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-10: ingestion-testsuite`
+- Branch: `feature/ing-10-ingestion-testsuite`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/ING-11.md b/mail-kanban/tickets/ING-11.md
new file mode 100644
index 00000000..dd89e546
--- /dev/null
+++ b/mail-kanban/tickets/ING-11.md
@@ -0,0 +1,58 @@
+# ING-11 – Header-Injection-Schutz für ausgehende Mailer-Komponente
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.
+
+**Technische Grundlage:** Go net/mail, RFC 5322, CRLF-Validierung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Rspamd/Dovecot: strikte RFC-5322-Konformität bei der Header-Erzeugung statt freihändigem String-Bau.
+
+**Bewusst vermeiden:**
+- archivmail – Header per Stringkonkatenation ohne CRLF-Prüfung, konkreter Injection-Bug im Altsystem.: Header-Erzeugung ausschließlich über strukturierten Writer, CRLF-Eingaben werden hart abgelehnt.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ING-03.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code
+2. Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen
+3. Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert
+2. Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt
+3. Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), direkter Bezug zu known-issues-archivmail.md Punkt 1: Header-Injection in der Mailer-Komponente ist ein bereits im Altsystem aufgetretener, konkreter Bug und muss beim Übernehmen des Codes zwingend behoben sein, nicht nur vermerkt.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ING-03` SMTP-Server & Mailer
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-11: header-injection-schutz-f-r-ausgehende-mailer-komponente`
+- Branch: `feature/ing-11-header-injection-schutz-f-r-ausgehende-mailer-komponente`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-01.md b/mail-kanban/tickets/INT-01.md
new file mode 100644
index 00000000..74860b1c
--- /dev/null
+++ b/mail-kanban/tickets/INT-01.md
@@ -0,0 +1,64 @@
+# INT-01 – REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Mail-spezifische API-Endpunkte (Mail-Liste/Mail-Detail/Anhang-Download usw.) auf dem zentralen Core-REST-Grundgerüst definieren und im modul-eigenen OpenAPI-Beitrag dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur.
+
+**Technische Grundlage:** Go net/http, REST, OpenAPI 3
+
+## Produkt-DNA für diesen Bereich
+> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.
+
+**Übernehmen:**
+- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.
+
+**Bewusst vermeiden:**
+- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.
+
+**Für genau diese Kachel:** REST-API v1 für lesenden und begrenzt schreibenden Zugriff auf archivierte Mails/Postfächer bereitstellen, entflochten von IAM-Themen des Core-Boards, inklusive eigener OpenAPI-Dokumentation der Mail-Endpunkte.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01, SRC-03 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board. Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-01` REST-API-Grundgerüst & Versionierung, `API-04` OpenAPI-Schnittstellenbeschreibung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. API bietet Endpunkte für Mail-Liste, Mail-Detail und Anhang-Download
+2. Alle Endpunkte sind strikt mandantengebunden
+3. IAM-nahe Funktionen (Login, Tenant-Verwaltung) sind bewusst nicht Teil dieser API
+4. Modul-eigener OpenAPI-Beitrag deckt alle v1-Endpunkte inklusive Fehlerantworten ab und ist gegen die tatsächliche API geprüft
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Zugriff ohne gültigen Tenant-Kontext wird abgelehnt
+2. Vertragstest gegen definierte Endpunkte läuft grün
+3. Codereview bestätigt Abgrenzung zu Core-Board-Zuständigkeiten
+4. Validierungslauf des OpenAPI-Dokuments gegen Standardwerkzeuge ist fehlerfrei
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Setzt voraus (externes Core-Board): `API-03` Zentrales Rate-Limiting & API-Gateway-Schicht
+- Setzt voraus (externes Core-Board): `API-07` Zentrale Webhook-Registry & Zustellung
+- `INT-06` E-Mail-Regel-Engine über API steuerbar
+- `INT-07` Health-Check-Endpunkt für Mail-Modul
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-01: rest-api-v1-fuer-mail-zugriff-schnittstellenbeschreibung`
+- Branch: `feature/int-01-rest-api-v1-fuer-mail-zugriff-schnittstellenbeschreibung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-05.md b/mail-kanban/tickets/INT-05.md
new file mode 100644
index 00000000..5070ccc5
--- /dev/null
+++ b/mail-kanban/tickets/INT-05.md
@@ -0,0 +1,61 @@
+# INT-05 – Benachrichtigungs-Service "neue Mail"
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.
+
+**Technische Grundlage:** Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher)
+
+## Produkt-DNA für diesen Bereich
+> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.
+
+**Übernehmen:**
+- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.
+
+**Bewusst vermeiden:**
+- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.
+
+**Für genau diese Kachel:** Benachrichtigungs-Service, der Benutzer über neu importierte Mails informiert (In-App und optional per Mail), neu konzipiert ohne archivmail-Vorbild.
+
+## Ausgangslage
+Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher – zentraler Versandweg für alle Module, kein eigener E-Mail-Versand je Modul.
+
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Kein Vorbild in archivmail – Webhook-/Notification-Mechanismus muss komplett neu konzipiert werden, siehe repos-analyse-mail-reuse.md.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neue Mail im überwachten Postfach löst zeitnah ein Ereignis an Core CFG-02 aus, das den Versand übernimmt
+2. Benutzer kann Benachrichtigungsart und -häufigkeit konfigurieren
+3. Massenimport (viele Mails gleichzeitig) erzeugt gebündelte statt Dutzende Einzelbenachrichtigungen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Import einer Mail löst genau eine Benachrichtigung aus
+2. Test: Massenimport erzeugt eine gebündelte Zusammenfassung statt Flut
+3. Test: deaktivierte Benachrichtigung erzeugt keine Zustellung
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-05: benachrichtigungs-service-neue-mail`
+- Branch: `feature/int-05-benachrichtigungs-service-neue-mail`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-06.md b/mail-kanban/tickets/INT-06.md
new file mode 100644
index 00000000..a6531661
--- /dev/null
+++ b/mail-kanban/tickets/INT-06.md
@@ -0,0 +1,59 @@
+# INT-06 – E-Mail-Regel-Engine über API steuerbar
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.
+
+**Technische Grundlage:** Go net/http, REST
+
+## Produkt-DNA für diesen Bereich
+> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.
+
+**Übernehmen:**
+- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.
+
+**Bewusst vermeiden:**
+- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.
+
+**Für genau diese Kachel:** E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-03, INT-01 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Regeln lassen sich vollständig über die API anlegen, ändern und löschen
+2. Prioritätsreihenfolge ist über die API einsehbar und änderbar
+3. API-Änderungen wirken identisch zur bisherigen internen Regel-Anwendung
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab
+2. Test: über API gesetzte Regel wird beim nächsten Import korrekt angewendet
+3. Test: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-06: e-mail-regel-engine-ueber-api-steuerbar`
+- Branch: `feature/int-06-e-mail-regel-engine-ueber-api-steuerbar`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-07.md b/mail-kanban/tickets/INT-07.md
new file mode 100644
index 00000000..2cc44cf2
--- /dev/null
+++ b/mail-kanban/tickets/INT-07.md
@@ -0,0 +1,59 @@
+# INT-07 – Health-Check-Endpunkt für Mail-Modul
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.
+
+**Technische Grundlage:** Go net/http
+
+## Produkt-DNA für diesen Bereich
+> Die API ist der stabile Vertrag nach außen – breite Fläche aus archivmail nutzbar, aber entflochten von IAM-Themen des Core-Boards.
+
+**Übernehmen:**
+- archivmail-API-Fläche (Handler-Struktur, OpenAPI-Doku) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- Rspamd: Rate-Limiting-Konzept auch auf API-Ebene fortgeführt.
+
+**Bewusst vermeiden:**
+- archivmail – IAM-nahe Handler (LDAP, Tenant, Invite, TOTP) sind eng mit der Mail-API verflochten.: strikte Trennung, diese Handler bleiben im Core-Board.
+
+**Für genau diese Kachel:** Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: INT-01 sind auf Fertig. Breite API-Fläche aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md. IAM-nahe Handler (LDAP/Tenant/Invite/TOTP) werden dabei bewusst NICHT übernommen, die liegen im Core-Board.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Health-Endpunkt meldet Status von Datenbank, Objektspeicher, Suchindex und Jobqueue getrennt
+2. Endpunkt ist ohne Authentifizierung für interne Überwachung erreichbar, aber ohne sensible Details
+3. Ausfall einer Teilkomponente wird klar als „degraded“ statt generischem Fehler gemeldet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: simulierter Ausfall einer Abhängigkeit wird korrekt im Health-Status abgebildet
+2. Test: Health-Antwort enthält keine sensiblen Konfigurationsdetails
+3. Integrationstest gegen echten Health-Endpunkt nach Deploy
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-07: health-check-endpunkt-fuer-mail-modul`
+- Branch: `feature/int-07-health-check-endpunkt-fuer-mail-modul`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-08.md b/mail-kanban/tickets/INT-08.md
new file mode 100644
index 00000000..d740a39f
--- /dev/null
+++ b/mail-kanban/tickets/INT-08.md
@@ -0,0 +1,63 @@
+# INT-08 – Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.
+
+**Technische Grundlage:** HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping
+
+## Produkt-DNA für diesen Bereich
+> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.
+
+**Übernehmen:**
+- Zentrale Aufbewahrungslogik einmal in Archive, nicht doppelt in Mail – vermeidet widersprüchliche Löschregeln.
+
+**Bewusst vermeiden:**
+- Keine eigene Retention-/Legal-Hold-Logik in Mail. Das führt zu Divergenz zwischen den Modulen.
+
+**Für genau diese Kachel:** Ohne diese Anbindung könnte Mail archivierte Nachrichten löschen, die Archive eigentlich sperrt – das ist der Rechtsstreit-Fall (Litigation Hold), den ARC-05 bereits gegen RET-03 prüft.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.
+
+Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/):
+- `RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Mail-/Anhang-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert
+2. Vor Löschung einer archivierten Mail wird eine Sperr-Abfrage an Archive gestellt
+3. Ist die Mail gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt
+4. Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort
+2. Test: gesperrte Mail kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar
+3. Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-08: archive anbindung objekttyp registrierung retention abfrage`
+- Branch: `feature/int-08-archive-anbindung-objekttyp-registrierung-retention-abfrage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-09.md b/mail-kanban/tickets/INT-09.md
new file mode 100644
index 00000000..ad5771e0
--- /dev/null
+++ b/mail-kanban/tickets/INT-09.md
@@ -0,0 +1,62 @@
+# INT-09 – AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.
+
+**Technische Grundlage:** HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping
+
+## Produkt-DNA für diesen Bereich
+> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.
+
+**Übernehmen:**
+- KI bleibt optional zuschaltbar über Core LIC-02 – kein Zwang, keine harte Kopplung.
+
+**Bewusst vermeiden:**
+- Keine eigene Klassifizierungs- oder Zusammenfassungslogik in Mail. Das dupliziert AI-Funktionalität.
+
+**Für genau diese Kachel:** Ohne diese Registrierung bliebe AI GOV-01 ohne Gegenstelle in Mail – die KI-Funktionen (CLS/SUM/SEM) hätten keine Mails zum Verarbeiten.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.
+
+Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/):
+- `GOV-01` Modul-Adapter-Schnittstelle (DMS/Mail registrieren KI-fähige Objekttypen) – Schnittstelle, über die DMS und Mail KI-fähige Objekttypen (Dokument, E-Mail, Thread) und deren Felder registrieren, statt eigene KI-Logik zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Mail-/Thread-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert
+2. Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet Mail unverändert ohne Fehler
+3. Registrierungsfehler blockieren niemals den regulären Mail-Betrieb (fail open bei Registrierung)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort
+2. Test: AI-Modul deaktiviert – Mail startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb
+3. Test: AI-Endpunkt nicht erreichbar bei Registrierung – Mail-Start wird dadurch nicht blockiert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-09: ai anbindung objekttyp registrierung kopplung ai gov 01`
+- Branch: `feature/int-09-ai-anbindung-objekttyp-registrierung-kopplung-ai-gov-01`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-10.md b/mail-kanban/tickets/INT-10.md
new file mode 100644
index 00000000..efdad5a1
--- /dev/null
+++ b/mail-kanban/tickets/INT-10.md
@@ -0,0 +1,62 @@
+# INT-10 – Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.
+
+**Technische Grundlage:** HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher
+
+## Produkt-DNA für diesen Bereich
+> Revisionssicherheit ist kein Feature, das man nachträglich anklebt – archivmail hat genau daran gekrankt.
+
+**Übernehmen:**
+- Ereignis-Publikation asynchron und best-effort mit sichtbarem Fehlerzustand, analog zum Core-Webhook-Muster (Postgres-Jobqueue statt Redis).
+
+**Bewusst vermeiden:**
+- Keine eigene Genehmigungs- oder Aufgabenlogik in Mail. Das dupliziert Workflow-Funktionalität.
+
+**Für genau diese Kachel:** Ohne diese Anbindung bliebe Workflow ENG-02 ohne Gegenstelle in Mail – z. B. eine Freigabe-Pflicht vor Massenzustellung könnte nicht am Mail-Lebenszyklus andocken.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge – Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.
+
+Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/):
+- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Mail-/Thread-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert
+2. Ereignis 'Mail eingegangen' wird bei Zustellung tatsächlich an Workflow publiziert
+3. Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende Mail-Aktion (asynchron, nicht im Request-Pfad)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort
+2. Test: Mail eingegangen – Ereignis kommt nachweislich bei Workflow an
+3. Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Mailzustellung bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-10: workflow anbindung objekttyp auslöser registrierung kopplung workflow eng 02`
+- Branch: `feature/int-10-workflow-anbindung-objekttyp-auslöser-registrierung-kopplung-workflow-eng-02`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-11.md b/mail-kanban/tickets/INT-11.md
new file mode 100644
index 00000000..45343667
--- /dev/null
+++ b/mail-kanban/tickets/INT-11.md
@@ -0,0 +1,60 @@
+# INT-11 – Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Service-Accounts agieren im Namen eines Kontexts, nie mit implizit eigenen, umfassenderen Rechten.
+
+**Bewusst vermeiden:**
+- Keycloak – Service-Client-Aufrufe teilen sich in manchen Integrationen denselben weiten Scope wie der Admin-Client.: Service-Credential trägt nur die Rechte, um im Namen eines übergebenen Tenant-Kontexts zu handeln, nie tenant-übergreifend von sich aus.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-08, INT-09, INT-10.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+2. Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
+3. Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
+2. Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
+3. Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `INT-16`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal über Service-Credentials ohne durchgereichten Nutzer-Tenant-Kontext kann diese Isolation modulübergreifend aufweichen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-08` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
+- `INT-09` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
+- `INT-10` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-11: nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Branch: `feature/int-11-nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-12.md b/mail-kanban/tickets/INT-12.md
new file mode 100644
index 00000000..ce1f4431
--- /dev/null
+++ b/mail-kanban/tickets/INT-12.md
@@ -0,0 +1,59 @@
+# INT-12 – Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.
+
+**Technische Grundlage:** Storage-Adapter, signierte URLs, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Dovecot/Alfresco: zeitlich begrenzte, objektgebundene Zugriffs-Tokens statt dauerhafter Links.
+
+**Bewusst vermeiden:**
+- Alfresco – in älteren Konfigurationen teils lang gültige Download-Links ohne erzwungene kurze TTL.: Ablaufzeit ist ein hartes, kurzes Limit, keine Empfehlung.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-01, ARC-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang
+2. Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
+3. Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler
+2. Test: abgelaufene URL wird abgelehnt
+3. Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-10`: ohne explizite Scope-/TTL-Vorgabe könnten signierte URLs für Anhang-Downloads versehentlich zu breit oder zu lange gültig ausgestellt werden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-01` REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-12: signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`
+- Branch: `feature/int-12-signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/INT-18.md b/mail-kanban/tickets/INT-18.md
new file mode 100644
index 00000000..68137f8a
--- /dev/null
+++ b/mail-kanban/tickets/INT-18.md
@@ -0,0 +1,59 @@
+# INT-18 – Mail-API: Authentifizierung und Mandant aus dem Token
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+`mail/internal/mailapi` liest den Mandanten aus `?tenant=` und hat keine Authentifizierung (Befund F-20, heute nicht verdrahtet und damit latent). Vor dem Verdrahten braucht die API den Guard und den Mandanten aus dem Modul-Token, wie im DMS.
+
+**Technische Grundlage:** `mail/internal/mailapi`, `mailrulesapi`; Vorbild: `dms/internal/moduleauth` und `authz.Guard`
+
+## Produkt-DNA für diesen Bereich
+> Der Mandant kommt aus der Identität, nie aus einem Parameter.
+
+**Übernehmen:**
+- Modul-JWT aus API-05/API-15 mit `aud`.
+
+**Bewusst vermeiden:**
+- Kein Mandant aus Abfrageparameter, keine Route ohne Guard.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-15` Sicherheitsprüfung Gesamtprojekt – Befundbericht `docs/SICHERHEITSPRUEFUNG-GESAMTPROJEKT.md`, hier: F-20 (mittel, latent).
+- `API-18` Modul-JWT mit `aud`.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Mail-API-Routen verlangen ein gültiges Modul-Token mit `aud=mail`; der Mandant stammt aus dem Token
+2. Ein `tenant`-Parameter wird ignoriert oder abgewiesen
+3. Ein fremder Mandant sieht keine Nachrichten und Anhänge
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Rollenmatrix und Cross-Tenant-Negativtests
+2. Routenliste je Modul ohne ungeschützte Route
+3. Ende-zu-Ende mit Core-Token
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Neue Suchfunktionen
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Status: erledigt (2026-09-22) — PR gegen `integration/gesamtprojekt`, Branch `feature/int-18-mail-api-authentifizierung-mandant-token`, Protokoll `mail/docs/INT-18-PRUEFPROTOKOLL.md`. Alle drei Prüfungen real auf 204 bestanden, inkl. echtem Ende-zu-Ende-Lauf gegen den Kontodienst. Kein Merge, kein Deploy.
+- Commit-Nachricht: `INT-18: mail-api mit authentifizierung`
+- Branch: `feature/int-18-mail-api-authentifizierung-mandant-token` (umbenannt gegenüber der Ticketvorgabe, da Ticketcode-Kollisionsprüfung vor Branch-Anlage üblich ist)
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-01.md b/mail-kanban/tickets/QA-01.md
new file mode 100644
index 00000000..9a3e3a32
--- /dev/null
+++ b/mail-kanban/tickets/QA-01.md
@@ -0,0 +1,64 @@
+# QA-01 – Teststrategie Mail
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.
+
+**Technische Grundlage:** Testkonzept, Go testing, Playwright/Jest
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.
+
+## Ausgangslage
+Diese Kachel hat innerhalb dieses Boards keine Vorbedingungen und ist sofort startbar. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Teststrategie benennt Testarten (Unit/Integration/E2E) und Mindestabdeckung je Modultyp
+2. Protokoll- und Compliance-kritische Module haben verbindlich höhere Testpflicht als Standard-Module
+3. Vorgehen für Bug-Tracking ist festgelegt und durchsuchbar (kein reines Code-Kommentar-Tracking)
+
+4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Dokument liegt vor und wurde von zweiter Person gegengelesen
+2. Stichprobe: mindestens ein Beispieltest je benannter Testart ist umgesetzt
+3. Bug-Tracking-Vorgehen wurde einmal exemplarisch für einen realen Befund durchgespielt
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #13: In einer früheren Implementierung gab es kein zentrales Issue-Tracking, Bugs wurden nur als `BUG-N`-Kommentare im Code festgehalten. Für diese Kachel verbindlich: Bugs und Fixes werden durchsuchbar getrackt, damit wiederkehrende Muster projektweit sichtbar werden, statt nur im Quelltext verstreut zu sein.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-01: teststrategie-mail`
+- Branch: `feature/qa-01-teststrategie-mail`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-02.md b/mail-kanban/tickets/QA-02.md
new file mode 100644
index 00000000..de481543
--- /dev/null
+++ b/mail-kanban/tickets/QA-02.md
@@ -0,0 +1,67 @@
+# QA-02 – Prüfgate Ingestion & Import
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.
+
+**Technische Grundlage:** Testkonzept, CI
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-10, IMP-09 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- `IMP-04` Fehlerbehandlung nicht-konformer Server – Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.
+- `IMP-05` Hot-Folder/Scanner-Anbindung – Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.
+- `IMP-06` Anhangs-Virenscan-Anbindung – Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.
+- `IMP-07` Mehrfach-Postfach-Verwaltung pro Tenant – Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.
+- `IMP-08` Fehler-Benachrichtigung bei Postfach-Sync-Ausfall – Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.
+- `ING-07` Protokoll-Fehlerbehandlung & Wiederverbindung – Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.
+- `ING-08` Mailserver-Protokoll-Logging & Diagnose – Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Gate prüft Testabdeckung und Bestehen aller Ingestion-/Import-Testsuiten
+2. Gate prüft, dass bekannte Fehlerpunkte (Header-Injection, Anhang-Limit, UIDVALIDITY) durch Tests abgedeckt sind
+3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Gate-Lauf gegen aktuellen Stand von ING-10/IMP-09 dokumentiert
+2. Stichprobe: mindestens ein Regressionstest je bekanntem Fehlerpunkt vorhanden
+3. Zweite Person bestätigt Gate-Ergebnis unabhängig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-09` Abnahme- & Compliance-Prüfung Mail
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-02: pruefgate-ingestion-import`
+- Branch: `feature/qa-02-pruefgate-ingestion-import`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-03.md b/mail-kanban/tickets/QA-03.md
new file mode 100644
index 00000000..d32df05a
--- /dev/null
+++ b/mail-kanban/tickets/QA-03.md
@@ -0,0 +1,65 @@
+# QA-03 – Prüfgate Archivierung & Suche
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.
+
+**Technische Grundlage:** Testkonzept, CI
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-08, SRC-10 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- `SRC-02` Indexierungs-Worker & Synchronisierung – Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.
+- `SRC-04` Such-Oberfläche mit Hervorhebung – Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.
+- `SRC-05` Facetten- & Filter-API – Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).
+- `SRC-08` Gespeicherte Suchanfragen – Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.
+- `SRC-09` Suchindex-Neuaufbau/Reindexierung – Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Gate prüft Bestehen der Archivierungs- und Suchindex-Testsuiten inklusive Schlüsselrotation
+2. Gate prüft Abwesenheit dynamischer SQL-Klauselbildung im Suchpfad
+3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Gate-Lauf gegen aktuellen Stand von ARC-08/SRC-10 dokumentiert
+2. Codereview-Stichprobe bestätigt statischen Query-Builder
+3. Zweite Person bestätigt Gate-Ergebnis unabhängig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-09` Abnahme- & Compliance-Prüfung Mail
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-03: pruefgate-archivierung-suche`
+- Branch: `feature/qa-03-pruefgate-archivierung-suche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-04.md b/mail-kanban/tickets/QA-04.md
new file mode 100644
index 00000000..6aff7a0f
--- /dev/null
+++ b/mail-kanban/tickets/QA-04.md
@@ -0,0 +1,62 @@
+# QA-04 – Sicherheits- & Berechtigungsprüfung
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.
+
+**Technische Grundlage:** Sicherheitsprüfung, Threat Modeling
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-03, ARC-06, ING-09 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack. Berührt Login-Tenant-Filter und Privilege-Escalation – dafür ist bereits Core-Board IAM zuständig, hier nur Mail-spezifische Aspekte prüfen.
+- `ING-06` TLS/STARTTLS-Absicherung – TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.
+- `SRC-11` Feld-Whitelist-Query-Builder für Suchindex-Zugriff – Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Prüfung bestätigt wirksame Härtung des SMTP-Pfads gegen bekannte Angriffsmuster
+2. Prüfung bestätigt lückenlose Mandantentrennung im Speicherpfad
+3. Prüfung bestätigt korrekt greifendes API-Token-/Rate-Limiting
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Gezielter Testangriff auf Header-Injection schlägt fehl
+2. Stichprobenprüfung mehrerer Speicherpfade auf Mandantentrennung
+3. Test: API-Zugriff mit widerrufenem/fremdem Token wird verweigert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-09` Abnahme- & Compliance-Prüfung Mail
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-04: sicherheits-berechtigungspruefung`
+- Branch: `feature/qa-04-sicherheits-berechtigungspruefung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-05.md b/mail-kanban/tickets/QA-05.md
new file mode 100644
index 00000000..9d485d35
--- /dev/null
+++ b/mail-kanban/tickets/QA-05.md
@@ -0,0 +1,66 @@
+# QA-05 – Prüfgate Compliance & eDiscovery
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.
+
+**Technische Grundlage:** Compliance-Prüfung
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.
+
+## Ausgangslage
+- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `CMP-04` Audit-Trail-Kopplung an Core-Audit-Log.
+- `ARC-05` Papierkorb & Soft-Delete für Mails – Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.
+- `ARC-07` Export/Portabilität (offenes Format) – Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.
+- `INT-08` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage – Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.
+- `ARC-10` Signatur- und Zeitstempelerhalt (BSI TR-03125) – Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und Prüfergebnis inkl. vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Zertifikatsablauf nachweisbar bleibt (BSI TR-03125).
+- `ARC-04` Aufbewahrungsstruktur (Mandant/Postfach/Jahr) – Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.
+- `ARC-09` Postfach-Quota – Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Gate prüft korrekte Kopplung mailrelevanter Ereignisse an das Core-Audit-Log
+2. Gate prüft, dass eDiscovery-Tenant-Scoping in der Query-Schicht verankert ist
+3. Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Gate-Lauf gegen aktuellen Stand der Audit-Trail-Kopplung (CMP-04) dokumentiert
+2. Stichprobe: Audit-Eintrag für Testlöschung ist im Core-Audit-Log auffindbar
+3. Zweite Person bestätigt Gate-Ergebnis unabhängig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-09` Abnahme- & Compliance-Prüfung Mail
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-05: pruefgate-compliance-ediscovery`
+- Branch: `feature/qa-05-pruefgate-compliance-ediscovery`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-06.md b/mail-kanban/tickets/QA-06.md
new file mode 100644
index 00000000..3a162c01
--- /dev/null
+++ b/mail-kanban/tickets/QA-06.md
@@ -0,0 +1,65 @@
+# QA-06 – Schnittstellen-Vertragstests
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.
+
+**Technische Grundlage:** Vertragstests, OpenAPI
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: INT-01 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- `INT-05` Benachrichtigungs-Service "neue Mail" – Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.
+- `INT-06` E-Mail-Regel-Engine über API steuerbar – E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.
+- `INT-07` Health-Check-Endpunkt für Mail-Modul – Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.
+- `INT-09` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01) – Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.
+- `INT-10` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02) – Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vertragstest deckt alle in der OpenAPI-Beschreibung definierten Endpunkte ab
+2. Abweichungen zwischen Beschreibung und tatsächlichem Verhalten werden automatisch erkannt
+3. Vertragstest läuft als Teil der CI bei jeder Änderung
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. CI-Lauf des Vertragstests ist grün auf aktuellem Stand
+2. Test: absichtlich eingefügte Abweichung wird vom Vertragstest erkannt
+3. Stichprobenreview durch zweite Person
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`
+- Branch: `feature/qa-06-schnittstellen-vertragstests`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-07.md b/mail-kanban/tickets/QA-07.md
new file mode 100644
index 00000000..13115308
--- /dev/null
+++ b/mail-kanban/tickets/QA-07.md
@@ -0,0 +1,60 @@
+# QA-07 – Last- & Leistungstest
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.
+
+**Technische Grundlage:** Lasttest-Werkzeug (z. B. k6/vegeta)
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ING-01, ING-02, ING-03 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Lasttest simuliert realistische Anzahl paralleler Sessions je Protokoll
+2. Ergebnis zeigt Durchsatz- und Latenzwerte je Protokoll unter Last
+3. Zielwerte für Antwortzeit/Durchsatz sind definiert und werden erreicht
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Lasttest-Lauf mit Ergebnisprotokoll liegt vor
+2. Vergleich Ist- vs. Zielwert dokumentiert
+3. Ressourcenverbrauch (CPU/RAM) während des Lasttests bleibt im erwarteten Rahmen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-07: last-leistungstest`
+- Branch: `feature/qa-07-last-leistungstest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-08.md b/mail-kanban/tickets/QA-08.md
new file mode 100644
index 00000000..6af2fa33
--- /dev/null
+++ b/mail-kanban/tickets/QA-08.md
@@ -0,0 +1,62 @@
+# QA-08 – Barrierefreiheits-Audit
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.
+
+**Technische Grundlage:** Accessibility-Audit-Werkzeug
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-07 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- `UX-08` Tastatur-Bedienung & Shortcuts – Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).
+- `UX-09` Akten-/Vorgangsanzeige im Mail-Kontext – In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Automatisierter Audit-Lauf zeigt keine kritischen Verstöße mehr
+2. Manuelle Stichprobe bestätigt sinnvolle Tastatur- und Screenreader-Bedienung
+3. Ergebnis ist dokumentiert und mit Verantwortlichen für Nachbesserung rückgekoppelt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Audit-Bericht liegt vor mit Vorher/Nachher-Vergleich
+2. Stichprobentest mit Screenreader durch zweite Person
+3. Offene Punkte sind priorisiert und nachverfolgbar dokumentiert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-08: barrierefreiheits-audit`
+- Branch: `feature/qa-08-barrierefreiheits-audit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/QA-09.md b/mail-kanban/tickets/QA-09.md
new file mode 100644
index 00000000..d45b478e
--- /dev/null
+++ b/mail-kanban/tickets/QA-09.md
@@ -0,0 +1,62 @@
+# QA-09 – Abnahme- & Compliance-Prüfung Mail
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.
+
+**Technische Grundlage:** Abnahmeprüfung
+
+## Produkt-DNA für diesen Bereich
+> Protokolllogik und Compliance-Funktionen versagen leise, wenn sie ungetestet bleiben – jedes Gate prüft das, was archivmail nachweislich fehlte.
+
+**Übernehmen:**
+- Mailpit/MailHog: Mailflows reproduzierbar und automatisiert testen.
+- Dovecot: Testabdeckung für Protokoll-Zustandsmaschinen als Maßstab.
+
+**Bewusst vermeiden:**
+- archivmail – kein zentrales Issue-Tracking, Bugs nur als Kommentare im Code.: Bugs durchsuchbar und nachvollziehbar tracken.
+- archivmail – nur 2 von 18 Modulen getestet trotz Kritikalität.: Pflichttests vor jedem Merge, nicht optional.
+
+**Für genau diese Kachel:** Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: QA-02, QA-03, QA-04, QA-05, QA-06, QA-07 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- `QA-08` Barrierefreiheits-Audit – Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.
+- `SRC-06` Facetten-UI & Filter-Chips – Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle vorgelagerten Prüfgates (Ingestion/Import, Archivierung/Suche, Sicherheit, Compliance) sind bestanden
+2. Abnahmebericht fasst Ergebnisse aller Gates nachvollziehbar zusammen
+3. Offene Punkte aus einzelnen Gates sind vollständig aufgelistet oder als geschlossen bestätigt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Abnahmebericht liegt vor und wurde gegengelesen
+2. Stichprobe: mindestens ein Ergebnis je vorgelagertem Gate ist im Bericht nachprüfbar verlinkt
+3. Freigabeentscheidung ist dokumentiert mit Datum und verantwortlicher Person
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-09: abnahme-compliance-pruefung-mail`
+- Branch: `feature/qa-09-abnahme-compliance-pruefung-mail`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-01.md b/mail-kanban/tickets/SRC-01.md
new file mode 100644
index 00000000..4ba7e381
--- /dev/null
+++ b/mail-kanban/tickets/SRC-01.md
@@ -0,0 +1,65 @@
+# SRC-01 – Manticore-Suchindex für Mails
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.
+
+**Technische Grundlage:** Go, Manticore Search SQL/HTTP-API
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Index-Schema für Mail-Felder ist definiert und über Migration versioniert
+2. Schreibzugriffe auf den Index verwenden ausschließlich statische, vordefinierte Feldnamen
+3. Index ist mandantengetrennt abfragbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Codereview bestätigt: keine Sprintf/Join-basierte SQL-Klauselbildung im Index-Zugriff
+2. Test: Abfrage mit manipulierten Eingabewerten verändert keine Spalten-/Tabellennamen
+3. Funktionstest: Volltextsuche liefert erwartete Treffer für Testkorpus
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #11: In einer früheren Implementierung wurden dynamische SQL-Klauseln über `fmt.Sprintf`/`strings.Join` gebaut, teils mit interpolierten Spalten-/Tabellennamen. Für diese Kachel verbindlich: Spalten- und Tabellennamen ausschließlich aus statischen Go-Konstanten, kein String-Zusammenbau von Bezeichnern zur Laufzeit – ein zentraler, getesteter Query-Builder mit Feld-Whitelist ist Pflicht.
+Indexierung darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird nicht indexiert.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SRC-02` Indexierungs-Worker & Synchronisierung
+- `SRC-03` Such-API mit Ranking
+- `SRC-09` Suchindex-Neuaufbau/Reindexierung
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-01: manticore-suchindex-fuer-mails`
+- Branch: `feature/src-01-manticore-suchindex-fuer-mails`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-02.md b/mail-kanban/tickets/SRC-02.md
new file mode 100644
index 00000000..0ae6b765
--- /dev/null
+++ b/mail-kanban/tickets/SRC-02.md
@@ -0,0 +1,62 @@
+# SRC-02 – Indexierungs-Worker & Synchronisierung
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.
+
+**Technische Grundlage:** Go, Postgres-Jobqueue
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neue Archivobjekte erscheinen innerhalb definierter Zeit im Suchindex
+2. Löschungen und Metadatenänderungen werden im Index nachgezogen
+3. Worker-Ausfall verliert keine Indexierungsaufträge (Wiederaufnahme aus Postgres-Jobqueue)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Worker-Neustart mitten im Lauf verliert keinen offenen Auftrag
+2. Test: Löschung einer Mail entfernt sie zuverlässig aus Suchtreffern
+3. Konsistenztest vergleicht Datenbankbestand mit Indexbestand stichprobenartig
+
+## Bekannte Fehler vermeiden
+Indexierung darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird nicht indexiert.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-02: indexierungs-worker-synchronisierung`
+- Branch: `feature/src-02-indexierungs-worker-synchronisierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-03.md b/mail-kanban/tickets/SRC-03.md
new file mode 100644
index 00000000..de5fec40
--- /dev/null
+++ b/mail-kanban/tickets/SRC-03.md
@@ -0,0 +1,62 @@
+# SRC-03 – Such-API mit Ranking
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).
+
+**Technische Grundlage:** Go, Manticore Search
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Suche liefert nach Relevanz sortierte Treffer mit nachvollziehbarem Ranking
+2. Ergebnisse sind strikt auf den anfragenden Mandanten beschränkt
+3. Grundoperatoren (Phrasensuche, Ausschluss) funktionieren korrekt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Suche eines Mandanten liefert keine Treffer eines anderen Mandanten
+2. Test: Phrasensuche und Ausschlussoperator liefern erwartete Teilmengen
+3. Performance-Test mit großem Testkorpus bleibt innerhalb Zielzeit
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-01` REST-API v1 für Mail-Zugriff
+- `SRC-04` Such-Oberfläche mit Hervorhebung
+- `SRC-05` Facetten- & Filter-API
+- `SRC-08` Gespeicherte Suchanfragen
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-03: such-api-mit-ranking`
+- Branch: `feature/src-03-such-api-mit-ranking`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-04.md b/mail-kanban/tickets/SRC-04.md
new file mode 100644
index 00000000..2dacd162
--- /dev/null
+++ b/mail-kanban/tickets/SRC-04.md
@@ -0,0 +1,60 @@
+# SRC-04 – Such-Oberfläche mit Hervorhebung
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.
+
+**Technische Grundlage:** Next.js/React/TS
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Eingabe liefert Trefferliste mit hervorgehobenen Suchbegriffen im Snippet
+2. Klick auf Treffer öffnet die zugehörige Mail direkt an der Fundstelle
+3. Leere Ergebnisse zeigen verständlichen Hinweis statt leerer Fläche
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test mit typischen Suchanfragen bestätigt korrekte Hervorhebung
+2. Barrierefreiheits-Kontrastprüfung der Hervorhebung
+3. Test mit Sonderzeichen in der Suchanfrage bricht die Anzeige nicht
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-04: such-oberflaeche-mit-hervorhebung`
+- Branch: `feature/src-04-such-oberflaeche-mit-hervorhebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-05.md b/mail-kanban/tickets/SRC-05.md
new file mode 100644
index 00000000..221a0c4c
--- /dev/null
+++ b/mail-kanban/tickets/SRC-05.md
@@ -0,0 +1,59 @@
+# SRC-05 – Facetten- & Filter-API
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).
+
+**Technische Grundlage:** Go, Manticore Facets
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. API liefert Facettenwerte mit Trefferzahl je Filterdimension
+2. Mehrere Filter lassen sich kombinieren (UND-Verknüpfung)
+3. Facetten sind mandantengetrennt berechnet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Facettenzahlen stimmen mit tatsächlicher Treffermenge überein
+2. Test: Kombination von drei Filtern liefert korrekt eingeschränkte Treffer
+3. Test: Facetten eines Mandanten enthalten keine Werte eines anderen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SRC-06` Facetten-UI & Filter-Chips
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-05: facetten-filter-api`
+- Branch: `feature/src-05-facetten-filter-api`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-06.md b/mail-kanban/tickets/SRC-06.md
new file mode 100644
index 00000000..d92c6dc3
--- /dev/null
+++ b/mail-kanban/tickets/SRC-06.md
@@ -0,0 +1,60 @@
+# SRC-06 – Facetten-UI & Filter-Chips
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.
+
+**Technische Grundlage:** Next.js/React/TS
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-05 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Aktive Filter erscheinen als entfernbare Chips oberhalb der Trefferliste
+2. Trefferzahl je Facettenwert wird live aktualisiert
+3. Zurücksetzen aller Filter ist mit einem Klick möglich
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test: Filterkombination und Einzelentfernung funktionieren wie erwartet
+2. Tastaturbedienbarkeit der Filter-Chips geprüft
+3. Test mit vielen aktiven Filtern bleibt die Ansicht übersichtlich
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-06: facetten-ui-filter-chips`
+- Branch: `feature/src-06-facetten-ui-filter-chips`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-07.md b/mail-kanban/tickets/SRC-07.md
new file mode 100644
index 00000000..0b1e8b95
--- /dev/null
+++ b/mail-kanban/tickets/SRC-07.md
@@ -0,0 +1,62 @@
+# SRC-07 – OCR für Anhänge
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.
+
+**Technische Grundlage:** Go, OCR-Engine-Anbindung (z. B. Tesseract)
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01, ARC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (eigenständiger Mail-OCR-Pfad), siehe repos-analyse-mail-reuse.md. Dupliziertes Sprintf-WHERE-Muster muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Bild- und gescannte PDF-Anhänge werden automatisch per OCR verarbeitet
+2. Erkannter Text wird dem zugehörigen Mail-Suchdokument zugeordnet
+3. Bereits durchsuchbare PDFs (mit Textebene) werden nicht unnötig erneut per OCR verarbeitet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Bildanhang mit bekanntem Text liefert erwartete Texterkennung
+2. Test: PDF mit vorhandener Textebene wird korrekt übersprungen
+3. Durchsatztest bestätigt akzeptable Verarbeitungszeit je Anhang
+
+## Bekannte Fehler vermeiden
+OCR darf erst nach abgeschlossener Duplikatsprüfung (ARC-03) starten. Bei bestätigter, nicht bewusst gewünschter Dublette wird keine OCR gerechnet.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SRC-10` Spracherkennung & OCR-Qualitätsbewertung
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-07: ocr-fuer-anhaenge`
+- Branch: `feature/src-07-ocr-fuer-anhaenge`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-08.md b/mail-kanban/tickets/SRC-08.md
new file mode 100644
index 00000000..caee7b4c
--- /dev/null
+++ b/mail-kanban/tickets/SRC-08.md
@@ -0,0 +1,59 @@
+# SRC-08 – Gespeicherte Suchanfragen
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.
+
+**Technische Grundlage:** Go, Postgres
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-03 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Suchkriterien inklusive aktiver Filter lassen sich unter einem Namen speichern
+2. Gespeicherte Suche liefert bei erneuter Ausführung aktuelle Treffer, keinen eingefrorenen Snapshot
+3. Gespeicherte Suchen sind je Benutzer/Mandant getrennt sichtbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: gespeicherte Suche mit mehreren Filtern wird korrekt reproduziert
+2. Test: Benutzer sieht keine gespeicherten Suchen anderer Mandanten
+3. Test: Löschen einer gespeicherten Suche entfernt nur diese
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-08: gespeicherte-suchanfragen`
+- Branch: `feature/src-08-gespeicherte-suchanfragen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-09.md b/mail-kanban/tickets/SRC-09.md
new file mode 100644
index 00000000..c37fde85
--- /dev/null
+++ b/mail-kanban/tickets/SRC-09.md
@@ -0,0 +1,59 @@
+# SRC-09 – Suchindex-Neuaufbau/Reindexierung
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.
+
+**Technische Grundlage:** Go, Manticore Search
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-01 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (Manticore RT-Index, Tenant-Worker), siehe repos-analyse-mail-reuse.md. Dynamischer SQL-Klausel-Aufbau muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Voller Reindex lässt sich ohne Datenverlust im laufenden Betrieb anstoßen
+2. Fortschritt und Abschluss des Reindex sind nachvollziehbar sichtbar
+3. Alter Index bleibt bis zum erfolgreichen Abschluss des neuen Index abfragbar (kein Suchausfall)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Reindex während laufender Suchanfragen unterbricht die Suche nicht
+2. Test: abgebrochener Reindex hinterlässt keinen inkonsistenten Zustand
+3. Stichprobenvergleich Alt-/Neuindex bestätigt gleiche Trefferzahlen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-09: suchindex-neuaufbau-reindexierung`
+- Branch: `feature/src-09-suchindex-neuaufbau-reindexierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-10.md b/mail-kanban/tickets/SRC-10.md
new file mode 100644
index 00000000..b1f2aa2e
--- /dev/null
+++ b/mail-kanban/tickets/SRC-10.md
@@ -0,0 +1,59 @@
+# SRC-10 – Spracherkennung & OCR-Qualitätsbewertung
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.
+
+**Technische Grundlage:** Go, OCR-Engine-Anbindung
+
+## Produkt-DNA für diesen Bereich
+> Suche muss über Jahre an E-Mail-Aufkommen tragen – Konzept aus archivmail nutzbar, Query-Aufbau wird ausschließlich statisch gehalten.
+
+**Übernehmen:**
+- archivmail-Manticore-Anbindung (RT-Index, Snippets, Tenant-Worker) als Ausgangspunkt, siehe repos-analyse-mail-reuse.md.
+- ecoDMS: durchsuchbare Archivierung als Compliance-Grundfunktion, nicht als Zusatzfeature.
+
+**Bewusst vermeiden:**
+- archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.: Spalten-/Tabellennamen nur aus statischen Konstanten, zentraler Query-Builder.
+
+**Für genau diese Kachel:** Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: SRC-07 sind auf Fertig. Konzept aus archivmail als Vorlage nutzbar (eigenständiger Mail-OCR-Pfad), siehe repos-analyse-mail-reuse.md. Dupliziertes Sprintf-WHERE-Muster muss vor Übernahme durch statischen Query-Builder ersetzt werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Erkannte Sprache wird je OCR-Text gespeichert und für Suche/Anzeige genutzt
+2. Konfidenzwert der Erkennung wird gespeichert und ist auswertbar
+3. Anhänge mit niedriger OCR-Qualität sind gezielt auffindbar (z. B. für manuelle Nachbearbeitung)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit mehrsprachigem Testkorpus bestätigt korrekte Spracherkennung
+2. Test: künstlich verschlechtertes Bild erzeugt niedrigeren Konfidenzwert
+3. Abfrage aller Anhänge unterhalb einer Konfidenzschwelle liefert erwartete Treffer
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-03` Prüfgate Archivierung & Suche
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-10: spracherkennung-ocr-qualitaetsbewertung`
+- Branch: `feature/src-10-spracherkennung-ocr-qualitaetsbewertung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/SRC-11.md b/mail-kanban/tickets/SRC-11.md
new file mode 100644
index 00000000..0dd2679c
--- /dev/null
+++ b/mail-kanban/tickets/SRC-11.md
@@ -0,0 +1,53 @@
+# SRC-11 – Feld-Whitelist-Query-Builder für Suchindex-Zugriff
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (E-Mail-Archivierung: Import, Volltextsuche, Aufbewahrung, eDiscovery), das sich an bewährten Mustern aus archivmail orientiert und dessen bekannte Schwächen bewusst vermeidet.
+Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), Manticore-RT-Index, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.
+
+**Technische Grundlage:** Statisches Enum/Switch für Feldnamen, getesteter Query-Builder
+
+## Produkt-DNA für diesen Bereich
+> Spalten-/Tabellennamen sind nie Nutzereingabe, auch nicht hinter einer Whitelist-Funktion – dieselbe Lehre aus beiden Altsystemen unabhängig gemacht.
+
+**Übernehmen:**
+- known-issues-archivdms.md Punkt 10 und known-issues-archivmail.md Punkt 12: dynamische Tabellennamen via fmt.Sprintf, nur durch eine fragile Whitelist-Funktion abgesichert – hier durch einen geschlossenen Enum/Switch-Typ ersetzt.
+
+**Bewusst vermeiden:**
+- Keine generische String-Zusammenbau-Funktion für Spalten-/Tabellennamen, auch nicht mit Whitelist-Prüfung davor.
+
+**Für genau diese Kachel:** SICHERHEITSKONZEPT.md Abschnitt 11 Punkt 10 ließ offen, ob DMS und Mail eine gemeinsame Utility teilen oder unabhängig implementieren – Entscheidung: unabhängig, konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren (siehe nexarch-state.json → bewusst_nicht_zentralisiert). Beide Boards folgen derselben Regel, ohne eine dritte, gemeinsame Abhängigkeit zu brauchen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `SRC-01` Suchindex-Grundlage – liefert das Schema, auf dessen dynamische Feldzugriffe dieser Query-Builder angewendet wird.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau
+2. Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung
+3. Entscheidung dokumentiert: Mail-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert
+2. Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Geteilte Utility mit dem DMS-Board – bewusst nicht gebaut, siehe Ausgangslage.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
diff --git a/mail-kanban/tickets/SRC-12.md b/mail-kanban/tickets/SRC-12.md
new file mode 100644
index 00000000..d9c95a46
--- /dev/null
+++ b/mail-kanban/tickets/SRC-12.md
@@ -0,0 +1,59 @@
+# SRC-12 – Ressourcenlimits für OCR-/Indexierungs-Jobs
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+SRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.
+
+**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Rspamd: klare Verarbeitungszeitgrenzen pro Nachricht statt unbegrenzter Best-Effort-Verarbeitung.
+
+**Bewusst vermeiden:**
+- archivmail (bekannte Fehlerklasse) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war eine wiederkehrende Betriebsstörung in Altsystemen.: harte, konfigurierbare Obergrenzen je Job von Anfang an statt nachträglicher Begrenzung nach Vorfall.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: SRC-02, SRC-07.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
+2. Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
+3. Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
+2. Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
+3. Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-11`: unbegrenzte Einzeljob-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Worker-Pool, auch ohne böswillige Absicht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SRC-02` Indexierungs-Worker & Synchronisierung
+- `SRC-07` OCR für Anhänge
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-12: ressourcenlimits-f-r-ocr-indexierungs-jobs`
+- Branch: `feature/src-12-ressourcenlimits-f-r-ocr-indexierungs-jobs`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-01.md b/mail-kanban/tickets/UX-01.md
new file mode 100644
index 00000000..5cb5f728
--- /dev/null
+++ b/mail-kanban/tickets/UX-01.md
@@ -0,0 +1,66 @@
+# UX-01 – Postfach- & Ordneransicht
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.
+
+**Technische Grundlage:** Next.js/React/TS
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: IMP-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ordnerbaum zeigt alle Postfächer/Ordner des angemeldeten Mandanten korrekt
+2. Nachrichtenliste unterstützt Sortierung nach Datum/Absender/Betreff
+3. Ansicht bleibt bei mehreren tausend Nachrichten performant bedienbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test mit Testpostfach bestätigt korrekte Ordner-/Listendarstellung
+2. Performance-Test mit großer Nachrichtenliste bleibt flüssig
+3. Test: Benutzer sieht ausschließlich Postfächer des eigenen Mandanten
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-02` E-Mail-Detailansicht & Thread-Darstellung
+- `UX-04` Responsive Layout & mobile Navigation
+- `UX-05` Dunkles Erscheinungsbild & Theming
+- `UX-06` Mehrsprachigkeit (Deutsch/Englisch)
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+- `UX-08` Tastatur-Bedienung & Shortcuts
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-01: postfach-ordneransicht`
+- Branch: `feature/ux-01-postfach-ordneransicht`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-02.md b/mail-kanban/tickets/UX-02.md
new file mode 100644
index 00000000..f2d4f0f2
--- /dev/null
+++ b/mail-kanban/tickets/UX-02.md
@@ -0,0 +1,62 @@
+# UX-02 – E-Mail-Detailansicht & Thread-Darstellung
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.
+
+**Technische Grundlage:** Next.js/React/TS
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Detailansicht zeigt Nachrichtentext, relevante Header und Anhangsliste vollständig
+2. Zusammengehörige Nachrichten werden als Thread gruppiert dargestellt
+3. Navigation zwischen Thread-Nachrichten funktioniert ohne Kontextverlust
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test mit mehrteiligem Thread bestätigt korrekte Gruppierung
+2. Test: Anhangsliste stimmt mit tatsächlich archivierten Anhängen überein
+3. Barrierefreiheits-Grundprüfung der Detailansicht
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+- `UX-08` Tastatur-Bedienung & Shortcuts
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-02: e-mail-detailansicht-thread-darstellung`
+- Branch: `feature/ux-02-e-mail-detailansicht-thread-darstellung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-03.md b/mail-kanban/tickets/UX-03.md
new file mode 100644
index 00000000..0d7fd8f3
--- /dev/null
+++ b/mail-kanban/tickets/UX-03.md
@@ -0,0 +1,64 @@
+# UX-03 – Anhang-Vorschau
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.
+
+**Technische Grundlage:** Next.js/React/TS, Canvas-Rendering
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: ARC-01 sind auf Fertig. PdfCanvasPreview-Ansatz aus archivmail als positives Vorbild nutzbar (Canvas statt iframe), siehe repos-analyse-mail-reuse.md. Die Content-Type-Erkennung der Anhang-Vorschau muss dagegen neu (serverseitig über Magic-Bytes) gebaut werden.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vorschau funktioniert für PDF- und Bildanhänge ohne externen Download
+2. Content-Type wird serverseitig über Magic-Bytes bestimmt, nicht über die Dateiendung
+3. PDF-Vorschau nutzt Canvas-Rendering, kein iframe/HTML-Rendering von Anhangsinhalt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Anhang mit falscher Dateiendung, aber echtem PDF-Inhalt wird korrekt als PDF erkannt und angezeigt
+2. Sicherheitsreview bestätigt: keine iframe-Einbindung von Anhangsinhalt
+3. Test: manipulierter Dateiname mit abweichendem Inhalt löst keine Fehlanzeige/-ausführung aus
+
+## Bekannte Fehler vermeiden
+Aus known-issues-archivmail.md, Punkt #8 und #9: Eine frühere Implementierung erkannte den Content-Type der Anhang-Vorschau nur über die Dateiendung (fragile Guard-Reihenfolge) und rendete PDFs testweise auch über iframe. Für diese Kachel verbindlich: Content-Type-Erkennung serverseitig über Magic-Bytes, PDF-Vorschau ausschließlich über Canvas-Rendering – iframe-Rendering von Fremdinhalt ist nicht zulässig.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-03: anhang-vorschau`
+- Branch: `feature/ux-03-anhang-vorschau`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-04.md b/mail-kanban/tickets/UX-04.md
new file mode 100644
index 00000000..eeb3f70c
--- /dev/null
+++ b/mail-kanban/tickets/UX-04.md
@@ -0,0 +1,61 @@
+# UX-04 – Responsive Layout & mobile Navigation
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).
+
+**Technische Grundlage:** Next.js/React/TS, CSS Grid/Flexbox
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Kernansichten sind auf schmalen Viewports vollständig nutzbar
+2. Navigation zwischen Ordnerliste, Nachrichtenliste und Detail ist auf Mobilgeräten ohne Verlust bedienbar
+3. Keine horizontal abgeschnittenen Inhalte auf gängigen Bildschirmbreiten
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test auf mindestens drei Viewport-Breiten
+2. Touch-Bedienungstest der Kernnavigation
+3. Automatisierter Layout-Regressionstest für Kernansichten
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-04: responsive-layout-mobile-navigation`
+- Branch: `feature/ux-04-responsive-layout-mobile-navigation`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-05.md b/mail-kanban/tickets/UX-05.md
new file mode 100644
index 00000000..2591c80b
--- /dev/null
+++ b/mail-kanban/tickets/UX-05.md
@@ -0,0 +1,61 @@
+# UX-05 – Dunkles Erscheinungsbild & Theming
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.
+
+**Technische Grundlage:** Next.js/React/TS, CSS Custom Properties
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Dunkles und helles Erscheinungsbild sind vollständig nutzbar, keine unlesbaren Kontraste
+2. Einstellung folgt Systempräferenz, ist aber manuell überschreibbar
+3. Theme-Wahl bleibt über Sitzungen hinweg erhalten
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Kontrastprüfung für beide Modi nach WCAG-Mindestwerten
+2. Test: manuelle Theme-Wahl übersteht Neuladen der Seite
+3. Visuelle Stichprobe aller Kernansichten in beiden Modi
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-05: dunkles-erscheinungsbild-theming`
+- Branch: `feature/ux-05-dunkles-erscheinungsbild-theming`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-06.md b/mail-kanban/tickets/UX-06.md
new file mode 100644
index 00000000..6b1cb463
--- /dev/null
+++ b/mail-kanban/tickets/UX-06.md
@@ -0,0 +1,61 @@
+# UX-06 – Mehrsprachigkeit (Deutsch/Englisch)
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.
+
+**Technische Grundlage:** Next.js/React/TS, i18n
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Oberflächentexte der Kernansichten liegen in Deutsch und Englisch vor
+2. Sprachumschaltung wirkt sofort ohne vollständigen Seiten-Neuladen
+3. Datums-/Zahlenformate folgen der gewählten Sprache
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Stichprobenprüfung auf fehlende Übersetzungen (keine Schlüssel sichtbar statt Text)
+2. Test: Sprachumschaltung funktioniert in allen Kernansichten
+3. Test: Datumsformat wechselt korrekt zwischen beiden Sprachen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `UX-07` Barrierefreiheit nach WCAG 2.1 AA
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-06: mehrsprachigkeit-deutsch-englisch`
+- Branch: `feature/ux-06-mehrsprachigkeit-deutsch-englisch`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-07.md b/mail-kanban/tickets/UX-07.md
new file mode 100644
index 00000000..90d1dc82
--- /dev/null
+++ b/mail-kanban/tickets/UX-07.md
@@ -0,0 +1,65 @@
+# UX-07 – Barrierefreiheit nach WCAG 2.1 AA
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).
+
+**Technische Grundlage:** Next.js/React/TS, WCAG 2.1 AA
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01, UX-02, UX-03, UX-04, UX-05, UX-06 sind auf Fertig. Kein Vorbild in archivmail für diesen Zuschnitt, Neubau nach NEXARCH-Techstack.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Kernansichten erreichen WCAG 2.1 AA in automatisierter Prüfung ohne kritische Verstöße
+2. Vollständige Bedienbarkeit ohne Maus ist für alle Kernfunktionen gegeben
+3. Screenreader-Ausgabe ist für zentrale Elemente sinnvoll und vollständig
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Automatisierter Accessibility-Scan aller Kernansichten ohne kritische Befunde
+2. Manueller Tastatur-Durchlauf durch alle Kernfunktionen
+3. Stichprobentest mit Screenreader durch zweite Person
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-08` Barrierefreiheits-Audit
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-07: barrierefreiheit-nach-wcag-2-1-aa`
+- Branch: `feature/ux-07-barrierefreiheit-nach-wcag-2-1-aa`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
+
+---
+## Status-Notiz (2026-09-23)
+Umgesetzt: PR #141 (feature/ux-07-barrierefreiheit-wcag-mail-search -> integration/gesamtprojekt, kein Merge). Echter Fund: mail-search fehlten focusVisibleStyles/themeInitScript, dadurch Link-Kontrastverstoss im dunklen Schema — behoben. AK1/AK2 erfuellt, AK3 (Screenreader-Stichprobe) offen mangels NVDA/VoiceOver auf dem Testhost, siehe mail/docs/UX-07-PRUEFPROTOKOLL.md.
diff --git a/mail-kanban/tickets/UX-08.md b/mail-kanban/tickets/UX-08.md
new file mode 100644
index 00000000..e8ab1f3d
--- /dev/null
+++ b/mail-kanban/tickets/UX-08.md
@@ -0,0 +1,61 @@
+# UX-08 – Tastatur-Bedienung & Shortcuts
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).
+
+**Technische Grundlage:** Next.js/React/TS
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).
+
+## Ausgangslage
+Setzt innerhalb dieses Boards voraus: UX-01, UX-02 sind auf Fertig. Frontend-Grundstruktur (Suchfilter, Tabellen) aus archivmail als Vorlage nutzbar, siehe repos-analyse-mail-reuse.md.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Kernaktionen sind über dokumentierte Tastenkombinationen erreichbar
+2. Shortcuts kollidieren nicht mit Standard-Browser-Kürzeln
+3. Aktueller Fokus ist jederzeit visuell erkennbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manueller Test aller dokumentierten Shortcuts in den Kernansichten
+2. Test: kein Shortcut überschreibt sicherheitsrelevante Browser-Funktion
+3. Fokus-Sichtbarkeitsprüfung in allen Kernansichten
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine nachgelagerten Kacheln innerhalb dieses Boards)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-08: tastatur-bedienung-shortcuts`
+- Branch: `feature/ux-08-tastatur-bedienung-shortcuts`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/mail-kanban/tickets/UX-09.md b/mail-kanban/tickets/UX-09.md
new file mode 100644
index 00000000..21f97bd4
--- /dev/null
+++ b/mail-kanban/tickets/UX-09.md
@@ -0,0 +1,65 @@
+# UX-09 – Akten-/Vorgangsanzeige im Mail-Kontext
+
+**Epic:** 📱 Postfach-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Mail (Ablösung von archivmail), das sich an Dovecot, Rspamd, Mailpit/MailHog sowie ecoDMS und Alfresco orientiert und deren bekannte Schwächen – u. a. aus archivmail selbst – bewusst vermeidet.
+Oberfläche und Client-seitige Logik. Datenzugriff ausschließlich über die bereitgestellte API.
+
+## Auftrag
+In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.
+
+**Technische Grundlage:** Next.js/React/TS, externe REST-API
+
+## Produkt-DNA für diesen Bereich
+> Die Postfachoberfläche muss so klar lesbar sein wie ein Testwerkzeug wie Mailpit/MailHog, nicht so überladen wie ein natives Mailprogramm.
+
+**Übernehmen:**
+- Mailpit/MailHog: aufgeräumte, sofort verständliche Darstellung von Nachrichten und Anhängen als Vorbild.
+- archivmail-Frontend-Komponenten (Suchfilter, Tabellen) strukturell übernehmbar, siehe repos-analyse-mail-reuse.md.
+
+**Bewusst vermeiden:**
+- archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung.: serverseitige Magic-Bytes-Erkennung.
+- archivmail – iframe-PDF-Vorschau als unsicher verworfen, Canvas-Rendering ist der richtige Weg.: Canvas-Rendering von Anfang an, kein iframe für Fremdinhalt.
+
+**Für genau diese Kachel:** In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `UX-02` E-Mail-Detailansicht & Thread-Darstellung – E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.
+- Setzt voraus (externes Workflow-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/workflow-kanban/): `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. E-Mail-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden
+2. Kein eigenes Akte-Datenmodell in Mail, ausschließlich Anzeige über die externe API
+3. Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Mailanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. E-Mail mit verknüpfter Akte zeigt Akte-Informationen korrekt an
+2. E-Mail ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler
+3. Simulierter Ausfall der Workflow-API blockiert die übrige Mailanzeige nicht
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Akte-Datenmodell (Workflow-Board, siehe `VOR-01`)
+- Vermerke-Erfassung (Workflow-Board, siehe `VOR-02`)
+- Wiedervorlage-Erfassung (Workflow-Board, siehe `VOR-03`)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `UX-09: akten vorgangsanzeige im mail kontext`
+- Branch: `feature/ux-09-akten-vorgangsanzeige-im-mail-kontext`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.