Merge PR #339: mail-kanban: Board nach Gitea main nachliefern
CI / Web-Barrierefreiheitspruefung (axe, Tastatur, Reflow, Textabstaende) (push) Canceled after 0s
CI / Core-Modul (Build/Vet/Test) (push) Canceled after 0s
CI / DMS Security-Test-Gate (AC5, Merge-Gate) (push) Canceled after 0s
CI / Connect Security-Test-Gate (QA-01 AC4, Merge-Gate) (push) Canceled after 0s
CI / DMS-Modul Supply-Chain-Scan (govulncheck) (push) Canceled after 0s
CI / Web (dms-browser) (push) Canceled after 0s
CI / Web (pdf-viewer) (push) Canceled after 0s
CI / Web (shl) (push) Canceled after 0s
CI / DMS-Modul (Lint/Build/Test/Coverage/Artefakt) (push) Canceled after 0s
CI / Web-Barrierefreiheitspruefung (axe, Tastatur, Reflow, Textabstaende) (push) Canceled after 0s
CI / Core-Modul (Build/Vet/Test) (push) Canceled after 0s
CI / DMS Security-Test-Gate (AC5, Merge-Gate) (push) Canceled after 0s
CI / Connect Security-Test-Gate (QA-01 AC4, Merge-Gate) (push) Canceled after 0s
CI / DMS-Modul Supply-Chain-Scan (govulncheck) (push) Canceled after 0s
CI / Web (dms-browser) (push) Canceled after 0s
CI / Web (pdf-viewer) (push) Canceled after 0s
CI / Web (shl) (push) Canceled after 0s
CI / DMS-Modul (Lint/Build/Test/Coverage/Artefakt) (push) Canceled after 0s
This commit is contained in:
patrick committed
commit
5ea7eb4c9b
76 files changed
+7723
No files matched your search
@@ -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.
|
||||
|
||||
---
|
||||
@@ -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).
|
||||
@@ -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"
|
||||
|
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,50 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Mail Kanban – lokal</title>
|
||||
<link rel="stylesheet" href="../_shared/kanban.css">
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="row">
|
||||
<h1>Mail Kanban <span class="sub">– lokal, offline, ohne Server</span></h1>
|
||||
<input id="q" placeholder="Suche: Code, Titel, Technik …" style="min-width:220px" />
|
||||
<select id="fEpic"><option value="">Alle Epics</option></select>
|
||||
<select id="fRole"><option value="">Alle Rollen</option></select>
|
||||
<select id="fWave"><option value="">Alle Wellen</option></select>
|
||||
<button id="onlyReady">Nur startbare</button>
|
||||
<button id="exportBtn">Stand sichern</button>
|
||||
<button id="resetBtn">Zurücksetzen</button>
|
||||
</div>
|
||||
<div class="stats" id="stats"></div>
|
||||
</header>
|
||||
<div class="board" id="board"></div>
|
||||
|
||||
<dialog id="dlg">
|
||||
<div class="dlg-head">
|
||||
<div>
|
||||
<div class="code" id="dCode" style="font-family:ui-monospace,Menlo,monospace;font-size:11px;color:var(--muted)"></div>
|
||||
<div id="dTitle" style="font-size:18px;font-weight:600;margin-top:4px"></div>
|
||||
<div id="dMeta" style="margin-top:8px"></div>
|
||||
</div>
|
||||
<div class="row">
|
||||
<button class="primary" id="copyBtn">Prompt kopieren</button>
|
||||
<button id="closeBtn">Schließen</button>
|
||||
</div>
|
||||
</div>
|
||||
<div class="dlg-body">
|
||||
<p id="dDesc" style="font-size:13px;color:#C7D3E5;line-height:1.6;margin-top:0"></p>
|
||||
<h3>Baut auf</h3><div id="dDeps"></div>
|
||||
<h3>Schaltet frei</h3><div id="dNext"></div>
|
||||
<h3>Akzeptanzkriterien</h3><ul id="dAcc"></ul>
|
||||
<h3>Prüfungen vor der Abnahme</h3><ul id="dChk"></ul>
|
||||
<h3>Bau-Prompt</h3><pre id="dPrompt"></pre>
|
||||
</div>
|
||||
</dialog>
|
||||
|
||||
<script id="data" type="application/json">{"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 Line truncated
|
||||
<script src="../_shared/kanban.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Reference in new issue
Block a user