Merge PR #342: core-kanban: Board nach Gitea main nachliefern

core-kanban/DEVLOG.md

@@ -0,0 +1,365 @@
+# core-kanban – Dev Log
+
+## 2026-08-26 00:09 – 00:09 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** dms-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:10 – 00:12 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:12 – 00:12 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:13 – 00:13 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:14 – 00:14 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:25 – 00:26 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 00:35 – 00:35 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:04 – 12:04 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** nexarch
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:07 – 12:08 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:10 – 12:11 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:13 – 12:13 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:20 – 12:20 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 12:20 – 12:22 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:39 – 13:40 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** nexarch
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:43 – 13:43 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:45 – 13:45 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:53 – 13:54 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:56 – 13:56 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 13:58 – 14:01 (2m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 14:03 – 14:03 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 14:05 – 14:06 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 15:37 – 15:51 (14m)
+**Beschreibung:** Claude Code Session
+**Projekt:** dms-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-26 15:53 – 15:53 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-27 21:45 – 21:49 (3m)
+**Beschreibung:** Claude Code Session
+**Projekt:** code
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-08-29 17:03 – 17:26 (23m)
+**Beschreibung:** Claude Code Session
+**Projekt:** nexarch
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-09-12 21:10 – 21:15 (4m)
+**Beschreibung:** Claude Code Session
+**Projekt:** tickets
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-09-12 21:15 – 21:17 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-09-12 21:20 – 21:20 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---
+## 2026-10-15 22:19 – 22:27 (7m)
+**Beschreibung:** Claude Code Session
+**Projekt:** e2e
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
+
+---
+## 2026-10-15 22:28 – 22:28 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
+
+---
+## 2026-10-15 22:30 – 22:30 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
+
+---
+## 2026-10-15 22:30 – 22:30 (0m)
+**Beschreibung:** Claude Code Session
+**Projekt:** core-kanban
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
+
+---
+## 2026-10-15 22:36 – 22:37 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** nexarch
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- dms-kanban/tickets/FDN-28.md | 44 ++++++++++++++++++++++++++++++++++++++++++++
+
+---

core-kanban/README.md

@@ -0,0 +1,108 @@
+# Core-Kanban – lokal abarbeiten
+
+88 Arbeitskacheln · 10 Epics · 204 Personentage · 11 Wellen (inkl. Welle 11: IAM-20 Anomalie-Erkennung API-Token, ergänzt 2026-09-14, siehe SICHERHEITSKONZEPT.md Punkt 12).
+Stand: 2026-09-12 (Wellen 9+10 aus Threat-Model-Nachtrag ergänzt, siehe unten)
+
+Sicherheitskonzept siehe /home/sysops/Dokumente/Scripte/nexarch/SICHERHEITSKONZEPT.md — API-08/09/10, OPS-04, QA-06 wurden aus dessen „Offene Punkte" ergänzt.
+
+SHL-01 ist die einzige UI-Shell/Design-System-Quelle für die gesamte Plattform — alle Modul-Frontends (DMS, Mail, Workflow, AI, Connect, Core selbst) bauen darauf auf, keines baut eine eigene Shell.
+
+Multi-Tenancy ist Modell C (Datenbank pro Mandant) statt Modell A — physische statt applikationsseitiger Mandantentrennung, siehe TEN-01/TEN-06/TEN-07.
+
+## 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 (`TEN-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** (3 Kacheln): QA-01, SHL-01, TEN-01
+- **Welle 2** (9 Kacheln): AUD-01, CFG-01, IAM-01, LIC-01, LIC-02, TEN-02, TEN-04, TEN-06, TEN-07
+- **Welle 3** (10 Kacheln): API-02, AUD-02, AUD-03, AUD-05, CFG-02, IAM-02, LIC-03, LIC-05, RBAC-01, TEN-03
+- **Welle 4** (20 Kacheln): API-01, API-05, AUD-04, CFG-03, IAM-03, IAM-04, IAM-05, IAM-06, IAM-07, IAM-09, IAM-10, IAM-11, IAM-12, IAM-14, LIC-04, OPS-01, RBAC-02, RBAC-03, RBAC-04, TEN-05
+- **Welle 5** (16 Kacheln): API-03, API-04, API-06, API-07, API-08, API-09, API-10, CFG-04, IAM-08, IAM-13, OPS-02, OPS-03, OPS-04, QA-07, QA-08, RBAC-05
+- **Welle 6** (4 Kacheln): OPS-05, QA-02, QA-03, QA-04
+- **Welle 7** (1 Kacheln): QA-05
+- **Welle 8** (1 Kacheln): QA-06
+- **Welle 9** (6 Kacheln, Threat-Model-Nachtrag 2026-09-12, kritisch/hoch): TEN-09, API-13, IAM-17, IAM-18, RBAC-08, AUD-07
+- **Welle 10** (5 Kacheln, Threat-Model-Nachtrag 2026-09-12, mittel): TEN-10, TEN-11, IAM-19, LIC-06, OPS-07
+
+Kritischer Pfad (19 PT): TEN-01 → IAM-01 → RBAC-01 → RBAC-02 → RBAC-05 → QA-03 → QA-05
+
+Hinweis: Die Wellen-1..8-Auflistung oben stammt aus dem Ursprungsstand (2026-08-26) und wurde nicht rückwirkend an alle seither ergänzten Einzelkacheln (z. B. IAM-15/16, TEN-08, OPS-06, QA-09) angeglichen — für den verbindlichen, aktuellen Stand gilt `board.json`/`board.csv`, nicht diese Liste.
+
+## Produkt-DNA
+
+### Übernehmen
+- **Zitadel**: Organisation/Projekt/Rollen-Modell mit klarer Mandantenhierarchie und Self-Service-Onboarding.
+- **Zitadel**: Eingebaute Unterstützung für Service-Accounts und maschinelle Benutzer neben menschlichen Identitäten.
+- **Casbin**: Deklaratives Policy-Modell (RBAC/ABAC) getrennt von der Anwendungslogik, zentral durchsetzbar.
+- **Casbin**: Policy-Entscheidungen sind testbar und versionierbar wie Code.
+- **Unleash**: Feature-Flags als eigenständiger Dienst mit Strategien (Prozentsatz, Zielgruppe, Tenant) statt verstreuter if-Abfragen.
+- **Unleash**: Klare Trennung zwischen Flag-Definition und Flag-Auswertung zur Laufzeit.
+- **Prometheus/Grafana**: Metriken als First-Class-Bürger jedes Moduls, offenes Pull-Modell statt proprietärem Push.
+- **Prometheus/Grafana**: Health-Endpunkte und Dashboards von Anfang an, nicht als Nachrüstung.
+
+### Vermeiden
+- **Keycloak – Schwergewichtige Plattform mit hohem Ressourcenbedarf und langer Startzeit.**: Schlanker Go-Dienst statt JVM-Anwendungsserver, startklar in Sekunden.
+- **Keycloak – Komplexe Realm-/Client-Konfiguration mit steiler Lernkurve.**: Sinnvolle Voreinstellungen für Tenant-/App-Registrierung, Komplexität nur wo nachweislich nötig.
+- **Zitadel – mehrschichtiges Organisation/Projekt/Grant-Modell kann für kleine Mandanten überdimensioniert wirken.**: Einfaches, flaches Tenant→Benutzer→Rolle-Modell im ersten Ausbau, Hierarchie-Tiefe optional später.
+
+## 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).

core-kanban/board.csv

@@ -0,0 +1,453 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+TEN-01,Tenant-Registry & Datenbank-Provisioning,🏢 Mandantenverwaltung,Backend,Mittel,4,1,Fertig,"PostgreSQL, SQL-Migrationen, Go/pgx","Schlanke Control-Plane-Registry-Datenbank (Tenant-Liste, Status, Verbindungsinformationen, Superadmin-Konten) plus automatisierte Provisioning-Routine, die für jeden neuen Mandanten eine eigene, vollständig isolierte PostgreSQL-Datenbank anlegt.",,API-01 AUD-01 CFG-01 IAM-01 LIC-01 LIC-02 TEN-02 TEN-04 TEN-06 TEN-07 TEN-09,"Registry-Datenbank enthält Tenant-Metadaten und Verbindungsinformationen, aber keine Geschäftsdaten eines Mandanten
+Provisioning-Routine legt für einen neuen Mandanten eine vollständig isolierte Datenbank an und registriert sie transaktional in der Registry
+Zwei Mandanten-Datenbanken sind auf Infrastrukturebene komplett getrennt – ein Zugriff über eine falsch oder fehlend gefilterte Query in einer Tenant-Datenbank kann technisch keine Zeile eines anderen Mandanten zurückliefern, weil sie nicht in derselben Datenbank existiert","Migration der Registry-Datenbank läuft gegen leere Datenbank durch und ist rückrollbar
+Provisioning-Test legt zwei Mandanten an, prüft dass beide Datenbanken physisch getrennt sind (unterschiedliche Datenbanknamen/-instanzen, kein gemeinsames Schema)
+Simulierter Anwendungs-Bug (Query ohne Tenant-Kontext) gegen eine Tenant-Datenbank liefert nachweislich niemals Daten eines anderen Mandanten, weil keine Verbindung dorthin besteht"
+TEN-02,Tenant-Onboarding-API & Self-Service,🏢 Mandantenverwaltung,Backend,Mittel,3,2,Fertig,"REST-API, Go/net/http, PostgreSQL","Self-Service-API für die Anlage neuer Mandanten inklusive Validierung, Ersteinrichtung des Administrator-Kontos und Bestätigungs-Flow.",TEN-01,TEN-03 TEN-05,"Neuer Mandant lässt sich per API-Aufruf ohne manuellen Admin-Eingriff anlegen
+Erster Administrator-Account wird im selben Vorgang transaktional mit angelegt
+Doppelte Registrierung (gleicher Bezeichner/Domain) wird sauber abgewiesen","Onboarding-Vorgang zweimal parallel ausgelöst, kein Doppel-Tenant entstanden
+Fehleingaben (leere Pflichtfelder, ungültige Domain) werden mit klaren Fehlermeldungen abgewiesen
+Erfolgreicher Durchlauf von einer zweiten Person end-to-end nachvollzogen"
+TEN-03,Tenant-Einstellungen & Branding,🏢 Mandantenverwaltung,Backend,Einfach,2,3,Fertig,"REST-API, PostgreSQL, JSON-Konfiguration","Pro-Tenant-Einstellungen (Anzeigename, Logo, Farbschema, Zeitzone, Sprache) verwalten und über API lesbar/schreibbar machen.",TEN-02,TEN-05,"Einstellungen sind pro Tenant persistiert und über API abrufbar/änderbar
+Nicht gesetzte Werte fallen auf sinnvolle Systemvoreinstellungen zurück
+Änderungen an Einstellungen werden versioniert nachvollziehbar gespeichert","Einstellungsänderung eines Tenants wirkt sich nicht auf einen anderen Tenant aus
+Fehlende Einstellungswerte liefern dokumentierte Defaults statt Fehler
+API-Schema von zweiter Person gegen die Dokumentation geprüft"
+TEN-04,Tenant-Lifecycle: Suspendieren/Reaktivieren/Löschen,🏢 Mandantenverwaltung,Backend,Mittel,3,2,Fertig,"PostgreSQL, Go, Job-Queue","Lebenszyklus-Zustände für Mandanten (aktiv, suspendiert, zur Löschung vorgemerkt, gelöscht) inklusive sicherer Übergänge und verzögerter, wiederrufbarer Löschung.",TEN-01,TEN-08,"Suspendierter Tenant kann sich nicht mehr anmelden, Daten bleiben erhalten
+Reaktivierung stellt den vorherigen Zustand vollständig wieder her
+Löschung erfolgt zweistufig mit Karenzzeit und ist innerhalb der Frist widerrufbar","Zustandsautomat mit allen Übergängen automatisiert getestet, ungültige Übergänge werden abgewiesen
+Suspendierter Tenant erzeugt bei jedem Zugriffsversuch einen klaren, geloggten Fehler
+Löschvorgang nach Ablauf der Karenzzeit durch Job-Queue automatisch ausgelöst und geprüft"
+TEN-05,Tenant-Verwaltungsoberfläche,🏢 Mandantenverwaltung,Frontend,Mittel,3,4,Fertig,Next.js/React/TypeScript,"Administrationsoberfläche zur Übersicht, Anlage, Einstellung und Statusverwaltung von Mandanten für Superadmins.",TEN-02 TEN-03 SHL-01,QA-02,"Liste aller Mandanten mit Status, Suche und Filter ist einsehbar
+Einstellungen und Branding eines Mandanten sind über ein Formular änderbar
+Lifecycle-Aktionen (suspendieren/reaktivieren/löschen) sind mit Bestätigungsdialog auslösbar","Oberfläche zeigt nur Mandanten, für die der Superadmin berechtigt ist
+Formularvalidierung verhindert das Absenden unvollständiger Pflichtfelder
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+IAM-01,Benutzer-Datenmodell & CRUD,👤 Identität & Authentifizierung,Backend,Einfach,2,2,Fertig,"PostgreSQL, Go/pgx","Benutzer-Datenmodell (Kernattribute, Status, Tenant-Zugehörigkeit) sowie CRUD-API zur Verwaltung von Benutzerkonten.",TEN-01,IAM-02 RBAC-01,"Benutzer lassen sich anlegen, lesen, aktualisieren und deaktivieren
+Jeder Benutzer ist eindeutig einem Tenant zugeordnet, Superadmin-ohne-Tenant ist als First-Class-Zustand modelliert
+E-Mail-Eindeutigkeit ist verbindlich geregelt (global oder tenant-scoped, dokumentiert)","CRUD-Operationen automatisiert getestet inklusive Negativfällen (doppelte E-Mail, fehlender Tenant)
+Superadmin-Anlage ohne Tenant-Kontext funktioniert ohne Sonderbehandlung im Code
+Datenmodell von zweiter Person gegen die Dokumentation geprüft"
+IAM-02,Login/Session/JWT-Grundgerüst,👤 Identität & Authentifizierung,Backend,Mittel,3,3,Fertig,"Session/JWT, bcrypt, Go/net/http","Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.",IAM-01,API-01 IAM-03 IAM-04 IAM-05 IAM-06 IAM-07 IAM-08 IAM-09 IAM-10 IAM-11 IAM-12 IAM-14 IAM-17,"Login/Logout funktionieren mit sicherem Session-Cookie bzw. JWT
+Passwörter werden ausschließlich mit bcrypt gehasht, niemals im Klartext gespeichert oder geloggt
+Geschützte Routen sind ohne gültige Session/Token nicht erreichbar
+bcrypt-Kostenfaktor ist explizit festgelegt (nicht Standardwert unreflektiert übernommen) und gegen eine Ziel-Login-Latenz benchmarkt.","Login-Query ist nachweislich auf den korrekten Tenant gescopt (kein Cross-Tenant-Login möglich)
+Session-Fixation- und Token-Manipulationstest bestanden
+Abgelaufene Session/abgelaufenes Token erzwingt Neuanmeldung
+Login-Latenz mit festgelegtem Kostenfaktor gemessen und gegen Zielwert bestätigt."
+IAM-03,Passwort-Reset & Einladungs-Flow,👤 Identität & Authentifizierung,Backend,Einfach,2,4,Fertig,"E-Mail-Versand, Token, PostgreSQL",Einmal-Token-basierter Passwort-Reset sowie Einladungs-Flow für neue Benutzer inklusive Ablaufzeit.,IAM-02,IAM-08,"Reset-Token ist einmalig verwendbar und läuft nach definierter Zeit ab
+Einladungs-Link setzt das Erstpasswort ohne bestehende Session
+Bereits verwendete oder abgelaufene Token werden eindeutig abgewiesen","Wiederverwendung eines bereits eingelösten Tokens automatisiert getestet und abgewiesen
+Ablaufzeit wird serverseitig durchgesetzt, nicht nur im Frontend geprüft
+Token werden nicht im Klartext geloggt (Stichprobe im Log-Ausgang geprüft)"
+IAM-04,Zwei-Faktor-Authentifizierung (TOTP),👤 Identität & Authentifizierung,Backend,Mittel,3,4,Fertig,"TOTP (RFC 6238), QR-Code, PostgreSQL","TOTP-basierte Zwei-Faktor-Authentifizierung inklusive Einrichtung, Wiederherstellungscodes und erzwingbarer Aktivierungspflicht pro Tenant.",IAM-02,IAM-08,"Benutzer kann TOTP per QR-Code einrichten und muss den Code vor Aktivierung einmal bestätigen
+Login mit aktivem 2FA verlangt zwingend den zweiten Faktor
+Wiederherstellungscodes ermöglichen Zugang bei Verlust des Geräts, sind aber nur einmal nutzbar","Login-Versuch ohne zweiten Faktor bei aktivem 2FA wird zuverlässig abgewiesen
+Wiederherstellungscode nach Nutzung automatisiert als verbraucht getestet
+Zeitversatz-Toleranz (Clock-Skew) des TOTP-Algorithmus dokumentiert und getestet"
+IAM-05,LDAP/Active-Directory-Anbindung,👤 Identität & Authentifizierung,Backend,Mittel,3,4,Fertig,"LDAP/AD, Go LDAP-Client, PostgreSQL","Anbindung an LDAP/Active Directory je Tenant für Benutzer-Synchronisation und Login-Delegation, inklusive Rollenzuordnung aus Gruppen.",IAM-02,QA-02 IAM-19,"Tenant kann eine LDAP-Quelle konfigurieren und Benutzer werden synchronisiert
+Login gegen LDAP funktioniert als Alternative zum lokalen Passwort
+Rollenzuordnung aus LDAP-Gruppen erfolgt ausschließlich über eine explizit getestete Erlaubnis-Matrix","Rollen-Erlaubnis-Matrix mit Positiv- und Negativfällen automatisiert getestet (keine Privilege-Escalation über Gruppenmitgliedschaft)
+Synchronisationslauf mit fehlerhafter/nicht erreichbarer LDAP-Quelle bricht kontrolliert ab, ohne bestehende Konten zu beschädigen
+Deaktivierung eines Benutzers in LDAP wird bei nächster Synchronisation korrekt übernommen"
+IAM-06,SSO-Anmeldung über OIDC,👤 Identität & Authentifizierung,Backend,Komplex,4,4,Fertig,"OpenID Connect, OAuth2, JWKS",SSO-Anmeldung über OpenID Connect gegen externe Identity-Provider inklusive Rollen-Mapping aus Claims und Fallback auf lokalen Login.,IAM-02,IAM-13 QA-04 IAM-18,"Anmeldung über mindestens einen externen OIDC-Provider funktioniert end-to-end inklusive Token-Validierung
+Rollen-Mapping aus OIDC-Claims erfolgt über dieselbe getestete Erlaubnis-Matrix wie bei LDAP
+Fehlerhafte oder abgelaufene Tokens des Identity-Providers werden abgewiesen, lokaler Login bleibt als Fallback nutzbar","Rollen-Erlaubnis-Matrix für OIDC-Claims automatisiert getestet (keine Privilege-Escalation über manipulierte Claims)
+Token-Signatur- und Ablaufprüfung gegen JWKS automatisiert getestet
+State/Nonce-Handling gegen CSRF und Replay geprüft"
+IAM-07,Account-Lockout & Login-Rate-Limiting,👤 Identität & Authentifizierung,Backend,Einfach,2,4,Fertig,"PostgreSQL-basierte Rate-Limit-Tabelle, Go","Brute-Force-Schutz durch Account-Lockout nach definierten Fehlversuchen und Rate-Limiting des Login-Endpunkts mit geteiltem, externem State.",IAM-02,QA-04,"Konto wird nach definierter Anzahl Fehlversuchen zeitlich gesperrt
+Rate-Limit-State liegt in Postgres (nicht in-process) und gilt korrekt über mehrere Instanzen hinweg
+Gesperrtes Konto entsperrt sich automatisch nach Ablauf der Sperrzeit oder durch Administratoreingriff","Zwei parallel laufende Dienstinstanzen teilen sich denselben Rate-Limit-Zähler (Mehrinstanz-Test)
+Brute-Force-Sperre greift nach definierten Fehlversuchen zuverlässig
+Zeitversatz zwischen Sperre und Entsperrung automatisiert getestet"
+IAM-08,Benutzerprofil- & Login-Oberfläche,👤 Identität & Authentifizierung,Frontend,Mittel,3,5,Fertig,Next.js/React/TypeScript,"Login-Oberfläche inklusive 2FA-Eingabe, Passwort-Reset-Flow und Profilverwaltung (eigene Daten, Passwort ändern, 2FA einrichten).",IAM-02 IAM-03 IAM-04 SHL-01,QA-02,"Login-Formular führt inklusive optionalem zweitem Faktor zu einer erfolgreichen Anmeldung
+Profilseite erlaubt Passwortänderung und 2FA-Einrichtung mit Klartextanzeige der Wiederherstellungscodes nur einmalig
+Fehleranzeigen bei falschem Passwort/Token sind verständlich, ohne interne Details preiszugeben","Login mit falschem Passwort/Token zeigt generische, keine Konto-Existenz verratende Fehlermeldung
+2FA-Einrichtung end-to-end von zweiter Person nachvollzogen
+Barrierefreiheit der Formulare (Tastaturbedienung, Labels) stichprobenartig geprüft"
+IAM-09,API-Token & Service-Accounts,👤 Identität & Authentifizierung,Backend,Mittel,3,4,Fertig,"PostgreSQL, gehashte API-Schlüssel, Go","Service-Accounts als eigenständige Identitäten sowie persönliche API-Token zur programmatischen Authentifizierung, mit Scopes und Ablaufzeit.",IAM-02,QA-02 IAM-20,"Service-Account lässt sich anlegen und erhält ein eigenes, gehashtes API-Token
+Token sind scope-beschränkt und optional zeitlich befristet
+Widerruf eines Tokens wirkt sofort, keine Cache-Verzögerung","Token werden ausschließlich gehasht gespeichert (Stichprobe in der Datenbank geprüft)
+Widerrufener Token wird bei nächstem Request zuverlässig abgewiesen
+Scope-Verletzung (Token ohne passenden Scope) wird korrekt abgewiesen"
+RBAC-01,Rollenmodell & Grundrechte,🔐 Rollen & Rechte,Backend,Mittel,3,3,Fertig,"PostgreSQL, Go","Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.",IAM-01,RBAC-02 RBAC-03 RBAC-04 RBAC-05 RBAC-08,"Grundrollen sind definiert und einem Benutzer je Tenant zuweisbar
+Rollenhierarchie (z. B. Tenant-Admin erbt Basisrechte) ist im Modell abgebildet
+Rollenzuweisung ist vollständig auditierbar (wer hat wann welche Rolle vergeben)","Zuweisung einer Rolle außerhalb der erlaubten Matrix wird abgewiesen und automatisiert getestet
+Rollenhierarchie liefert im Test die erwartete effektive Rechtemenge
+Datenmodell von zweiter Person gegen die Dokumentation geprüft"
+RBAC-02,Policy-Enforcement-Schicht (zentral),🔐 Rollen & Rechte,Backend,Komplex,4,4,Fertig,"Casbin-Konzept (RBAC/ABAC), Go-Middleware, PostgreSQL","Zentrale Policy-Entscheidungs- und Durchsetzungsschicht, die von jeder Query/Repository-Ebene angesprochen wird – keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern.",RBAC-01,QA-04 RBAC-05,"Jede Datenzugriffs-Query läuft durch eine zentrale Enforcement-Funktion, nicht durch handlerspezifische Ad-hoc-Prüfungen
+Policy-Entscheidungen sind deklarativ als Regeln definiert und unabhängig von der Anwendungslogik testbar
+Tenant-Scoping erfolgt ausschließlich in der Query-/Repository-Schicht, niemals als nachgelagerter Filter","Automatisierter Test belegt: kein Datenzugriffs-Pfad umgeht die zentrale Enforcement-Schicht
+Negativtest: Anfrage ohne passende Policy wird zuverlässig abgewiesen, nicht standardmäßig erlaubt
+Policy-Regelsatz ist versioniert und ein Regelwechsel ist ohne Codeänderung nachvollziehbar"
+RBAC-03,Gruppen & Abteilungen,🔐 Rollen & Rechte,Backend,Einfach,2,4,Fertig,"PostgreSQL, Go","Gruppen/Abteilungen als Bündelung von Benutzern innerhalb eines Tenants, mit Rollenzuweisung auf Gruppenebene.",RBAC-01,RBAC-05,"Gruppen lassen sich pro Tenant anlegen und Benutzer zuordnen
+Rollen können auf Gruppenebene vergeben werden und wirken auf alle Mitglieder
+Löschen einer Gruppe entzieht die gruppenbasierten Rechte sauber, ohne Benutzerkonten zu löschen","Gruppenrolle wirkt im Test korrekt auf alle aktuellen Mitglieder
+Entfernen eines Benutzers aus der Gruppe entzieht die gruppenbasierten Rechte sofort
+Gruppen sind sauber tenant-isoliert (Stichprobe über zwei Tenants)"
+RBAC-04,Modul-scoped Berechtigungen,🔐 Rollen & Rechte,Backend,Mittel,3,4,Fertig,"PostgreSQL, Go, Feature-Flag-Integration","Berechtigungen zusätzlich auf Modul-Ebene scopen, sodass Rechte nur innerhalb freigeschalteter Module wirksam werden.",RBAC-01 LIC-02,QA-03,"Berechtigung für ein nicht lizenziertes/aktiviertes Modul greift nicht, selbst bei sonst passender Rolle
+Aktivierung eines Moduls über Feature-Flags macht die zugehörigen Berechtigungen ohne Neustart wirksam
+Modul-Scoping ist in derselben zentralen Enforcement-Schicht verankert wie das Grundrollenmodell","Zugriff auf deaktiviertes Modul wird trotz passender Rolle automatisiert abgewiesen und getestet
+Reaktivierung eines Moduls macht Berechtigungen im laufenden Betrieb wirksam (kein Neustart nötig)
+Zusammenspiel Modul-Scope + Rollenscope in Kombinationsfällen automatisiert getestet"
+RBAC-05,Rechte-Administrationsoberfläche,🔐 Rollen & Rechte,Frontend,Mittel,3,5,Fertig,Next.js/React/TypeScript,"Oberfläche zur Verwaltung von Rollen, Rechten, Gruppen und Zuweisungen für Tenant-Administratoren.",RBAC-01 RBAC-02 RBAC-03 SHL-01 IAM-16,QA-03,"Rollen und ihre Grundrechte sind einsehbar und für Tenant-Admins innerhalb ihrer Erlaubnis änderbar
+Gruppen lassen sich anlegen, Mitglieder zuordnen und Rollen zuweisen
+Änderungen an Rechten sind über die Oberfläche nachvollziehbar (Verweis auf Audit-Log)","Tenant-Admin kann keine Rechte außerhalb seines Tenants einsehen oder ändern
+Versuch, sich selbst eine höhere Rolle zuzuweisen, wird abgewiesen und automatisiert getestet
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+LIC-01,Lizenzmodell & Lizenzschlüssel-Prüfung,🎫 Lizenzierung & Feature Flags,Backend,Mittel,3,2,Fertig,"PostgreSQL, kryptographische Signaturprüfung, Go","Lizenzmodell je Tenant (Plan, Laufzeit, Modul-Umfang) sowie Prüfung signierter Lizenzschlüssel gegen den Tenant-Datensatz.",TEN-01,LIC-03 LIC-04 LIC-05 LIC-06,"Lizenzschlüssel wird kryptographisch signiert ausgestellt und beim Einspielen validiert
+Abgelaufene oder ungültige Lizenzen werden erkannt und führen zu einem definierten eingeschränkten Zustand
+Lizenzumfang (Plan, Modul-Liste, Laufzeit) ist pro Tenant persistiert und abfragbar","Manipulierter Lizenzschlüssel wird zuverlässig als ungültig erkannt (automatisierter Test)
+Ablauf einer Lizenz löst den dokumentierten eingeschränkten Zustand aus, nicht einen harten Systemausfall
+Signaturprüfung von zweiter Person gegen die Dokumentation nachvollzogen"
+LIC-02,Feature-Flag-Service je Tenant,🎫 Lizenzierung & Feature Flags,Backend,Mittel,3,2,Fertig,"PostgreSQL, In-Prozess-Cache, Go","Feature-Flag-Dienst mit Strategien (global an/aus, Prozentsatz, Tenant-Zielgruppe) und schneller Auswertung ohne externe Infrastruktur.",TEN-01,API-02 LIC-04 RBAC-04 LIC-06,"Feature-Flags lassen sich zentral definieren und pro Tenant oder Zielgruppe unterschiedlich auswerten
+Auswertung eines Flags erfolgt mit geringer Latenz über einen lokalen Cache mit klarer Invalidierung
+Änderung eines Flags wirkt ohne Neustart der abhängigen Dienste
+Deaktivierung eines Moduls sperrt nur den Zugriff, löscht keine Daten des Moduls — Löschung läuft ausschließlich über die Archive-Retention-Engine","Flag-Änderung wird innerhalb der dokumentierten Cache-Invalidierungszeit wirksam (automatisiert gemessen)
+Zielgruppen-Strategie (z. B. bestimmter Tenant) liefert im Test die erwartete Auswertung
+Ausfall des Flag-Dienstes führt zu dokumentiertem Fallback-Verhalten, nicht zum Absturz abhängiger Dienste
+Modul-Deaktivierung im Test gefolgt von Reaktivierung zeigt unveränderte Daten, kein Datenverlust"
+LIC-03,Nutzungszähler & Quotas,🎫 Lizenzierung & Feature Flags,Backend,Mittel,3,3,Fertig,"PostgreSQL, Job-Queue (periodische Aggregation), Go","Nutzungszähler (z. B. Benutzeranzahl, Speicherverbrauch, API-Aufrufe) je Tenant erfassen und gegen lizenzierte Quotas prüfen.",LIC-01,LIC-04,"Nutzungszähler werden zuverlässig je Tenant erfasst und periodisch aggregiert
+Überschreitung einer Quota löst eine definierte Reaktion aus (Warnung, Sperre neuer Ressourcen)
+Zähler sind über API abrufbar für Verwaltungsoberfläche und Benachrichtigungen","Quota-Überschreitung wird automatisiert erkannt und die definierte Reaktion ausgelöst
+Aggregationsjob liefert bei parallelen Schreibzugriffen konsistente Zählerstände
+Zählerstand eines Tenants beeinflusst nachweislich nicht den eines anderen Tenants"
+LIC-04,Lizenz-/Modul-Verwaltungsoberfläche,🎫 Lizenzierung & Feature Flags,Frontend,Mittel,3,4,Fertig,Next.js/React/TypeScript,"Oberfläche zur Übersicht von Lizenzstatus, aktivierten Modulen, Feature-Flags und aktuellem Nutzungsstand je Tenant.",LIC-01 LIC-02 LIC-03 SHL-01,,"Lizenzstatus, Laufzeit und aktivierte Module sind auf einen Blick einsehbar
+Feature-Flags sind für berechtigte Administratoren umschaltbar, soweit die Lizenz dies erlaubt
+Nutzungsstand gegen Quota ist visuell klar dargestellt (z. B. Fortschrittsanzeige)","Umschalten eines nicht lizenzierten Features wird verhindert und verständlich begründet
+Darstellung des Nutzungsstands stimmt mit den Backend-Zählern überein (Stichprobe)
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+AUD-01,Zentrales Audit-Log-Modell,📜 Audit & Compliance,Backend,Mittel,3,2,Fertig,"PostgreSQL, Go","Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.",TEN-01,AUD-02 AUD-03 AUD-05 TEN-09 API-13 AUD-07 IAM-20,"Audit-Ereignisse werden strukturiert (Akteur, Aktion, Zielobjekt, Zeitpunkt, Tenant) persistiert
+Audit-Log ist vom allgemeinen Anwendungs-Log technisch und organisatorisch getrennt
+Schreibpfad für Audit-Einträge ist zentral (eine Schreibfunktion), nicht verstreut über Handler","Automatisierter Test belegt: ein sicherheitsrelevanter Vorgang erzeugt zuverlässig genau einen Audit-Eintrag
+Fehlender Tenant-Bezug in einem Audit-Eintrag wird durch Constraint/Test verhindert
+Datenmodell von zweiter Person gegen die Dokumentation geprüft"
+AUD-02,Unveränderliches Protokoll (Append-only),📜 Audit & Compliance,Backend,Mittel,3,3,Fertig,"PostgreSQL (Trigger/Constraints), Go","Audit-Log technisch gegen nachträgliche Änderung und Löschung absichern (append-only), inklusive Vier-Augen-Prinzip für sicherheitskritische Entscheidungen im Umfeld des Audit-Logs.",AUD-01,QA-05,"UPDATE und DELETE auf Audit-Einträge sind auf Datenbankebene technisch unterbunden
+Sicherheitskritische Entscheidungen (z. B. Löschbestätigung, Rechtevergabe) laufen über ein Vier-Augen-Prinzip mit FOR-UPDATE-Lock
+Vergleich sicherheitsrelevanter Geheimnisse (Token, Bestätigungscodes) erfolgt timing-safe","Direkter UPDATE/DELETE-Versuch auf die Audit-Tabelle wird von der Datenbank abgewiesen (automatisierter Test)
+Vier-Augen-Prinzip mit FOR-UPDATE-Lock unter parallelen Anfragen race-frei getestet
+Timing-safe Vergleich durch Laufzeitmessung stichprobenartig verifiziert"
+AUD-03,Audit-Log-Export & Filter-API,📜 Audit & Compliance,Backend,Einfach,2,3,Fertig,"REST-API, PostgreSQL, CSV/JSON-Export","API zum Filtern (Zeitraum, Akteur, Aktion, Tenant) und Exportieren des Audit-Logs für Compliance-Zwecke.",AUD-01,AUD-04,"Filter nach Zeitraum, Akteur, Aktion und Tenant liefern korrekte Teilmengen
+Export als CSV und JSON ist für berechtigte Rollen verfügbar
+Export ist paginiert/streambar, auch bei großen Datenmengen ohne Speicherüberlauf","Exportgröße im Test mit hoher Eintragszahl ohne übermäßigen Speicherverbrauch verarbeitet
+Filterkombinationen automatisiert gegen erwartete Ergebnismengen getestet
+Zugriff auf Export ohne passende Berechtigung wird abgewiesen"
+AUD-04,Audit-Log-Ansicht,📜 Audit & Compliance,Frontend,Einfach,2,4,Fertig,Next.js/React/TypeScript,"Oberfläche zur Durchsuchung und Darstellung des Audit-Logs für berechtigte Administratoren, inklusive Exportfunktion.",AUD-03 SHL-01,,"Audit-Einträge sind mit Filtern nach Zeitraum, Akteur und Aktion durchsuchbar
+Export-Funktion aus AUD-03 ist über die Oberfläche auslösbar
+Einzelner Audit-Eintrag zeigt alle relevanten Details in einer Detailansicht","Filterkombinationen in der Oberfläche liefern dieselben Ergebnisse wie direkte API-Aufrufe
+Export aus der Oberfläche liefert eine vollständige, ladbare Datei
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+CFG-01,Zentraler Konfigurationsdienst,⚙️ Zentrale Konfiguration & Benachrichtigungen,Backend,Mittel,3,2,Fertig,"PostgreSQL, In-Prozess-Cache, Go","Zentraler Dienst für globale und tenant-spezifische Konfigurationswerte mit Versionierung und Cache-Invalidierung, von allen Modulen wiederverwendbar.",TEN-01,CFG-02,"Konfigurationswerte sind global und pro Tenant überschreibbar mit klarer Vorrangregel
+Änderungen an Konfigurationswerten sind versioniert nachvollziehbar
+Andere Module lesen Konfiguration ausschließlich über die zentrale Schnittstelle, nicht über eigene Tabellen","Vorrangregel (Tenant-Override vor Global-Default) automatisiert getestet
+Cache-Invalidierung nach Konfigurationsänderung innerhalb dokumentierter Zeit gemessen
+Versionierungshistorie eines Werts über mehrere Änderungen hinweg nachvollzogen"
+CFG-02,Benachrichtigungs-Dispatcher (Core-Service für Module),⚙️ Zentrale Konfiguration & Benachrichtigungen,Backend,Mittel,3,3,Fertig,"Postgres-Job-Queue, Go, Worker-Goroutinen","Zentraler Dispatcher, über den beliebige Module Benachrichtigungen auslösen können, mit Warteschlange, Wiederholungslogik und Kanal-Abstraktion.",CFG-01,CFG-03,"Module lösen Benachrichtigungen über eine einheitliche, schmale Schnittstelle aus, ohne eigenen Versandcode
+Fehlgeschlagene Zustellung wird mit begrenzter Anzahl Wiederholungen erneut versucht
+Warteschlange ist Postgres-basiert und übersteht einen Neustart des Dienstes ohne Nachrichtenverlust","Neustart des Dienstes während offener Zustellungen verliert keine Nachricht (automatisierter Test)
+Wiederholungslogik greift bei simuliertem Zustellfehler und bricht nach definierter Anzahl kontrolliert ab
+Zwei Module lösen gleichzeitig Benachrichtigungen aus, beide werden korrekt zugestellt"
+CFG-03,Benachrichtigungs-Kanäle (E-Mail/In-App),⚙️ Zentrale Konfiguration & Benachrichtigungen,Backend,Einfach,2,4,Fertig,"SMTP, PostgreSQL (In-App-Nachrichten), Go","Konkrete Zustellkanäle für den Dispatcher: E-Mail-Versand und In-App-Benachrichtigungen, inklusive Vorlagenverwaltung.",CFG-02,CFG-04,"E-Mail-Versand funktioniert über konfigurierbaren SMTP-Server mit Vorlagen
+In-App-Benachrichtigungen werden persistiert und sind über API abrufbar/als gelesen markierbar
+Vorlagen sind pro Tenant anpassbar (Branding aus TEN-03 nutzbar)","Vorlagenrendering mit fehlenden Platzhaltern bricht kontrolliert ab statt fehlerhafte Mails zu versenden
+In-App-Benachrichtigung nach Markierung als gelesen wird korrekt als gelesen geführt
+E-Mail-Versand bei nicht erreichbarem SMTP-Server löst dokumentiertes Retry-Verhalten über CFG-02 aus"
+CFG-04,Benachrichtigungs-Einstellungen-Oberfläche,⚙️ Zentrale Konfiguration & Benachrichtigungen,Frontend,Einfach,2,5,Fertig,Next.js/React/TypeScript,Oberfläche für Benutzer und Tenant-Admins zur Verwaltung eigener Benachrichtigungspräferenzen je Kanal und Ereignistyp.,CFG-03 SHL-01,,"Benutzer kann Kanäle (E-Mail/In-App) je Ereignistyp an- und abschalten
+Änderungen wirken sich unmittelbar auf künftige Zustellungen aus
+Tenant-Admin sieht eine Übersicht der Benachrichtigungs-Konfiguration seines Tenants","Deaktivierter Kanal erhält im Test nachweislich keine weitere Zustellung
+Einstellungen eines Benutzers wirken sich nicht auf einen anderen Benutzer aus
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+API-01,REST-API-Grundgerüst & Versionierung,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,4,Fertig,"Go/net/http, REST, URL-Versionierung","Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).",TEN-01 IAM-02,API-03 API-04 API-07 API-08 API-09 API-10 QA-07,"API ist unter einem versionierten Pfad (z. B. /api/v1/...) erreichbar
+Einheitliches Fehlerformat für alle Endpunkte etabliert und dokumentiert
+Middleware-Kette setzt Tenant- und Benutzerkontext für nachgelagerte Handler zuverlässig","Fehlerhafte Anfrage liefert über alle Endpunkte hinweg dasselbe Fehlerschema (Stichprobe)
+Middleware-Kette wird durch automatisierten Test nachweislich von jedem Endpunkt durchlaufen
+Versionswechsel (fiktive v2-Route) lässt sich anlegen, ohne v1 zu beeinträchtigen"
+API-02,Modul-Registry & Aktivierungsprüfung,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,3,Fertig,"PostgreSQL, Go","Registry, in der sich Fachmodule (DMS, Mail, weitere) mit Metadaten registrieren, gekoppelt an die Aktivierungsprüfung aus Feature-Flags/Lizenz. Zusätzlich authentifiziert die Registry Modul-Instanzen selbst über ein bei Provisionierung ausgestelltes Service-Credential (Client-ID + Secret oder kurzlebiges Service-Token), nicht nur deren Lizenz-Feature-Flags.",LIC-02,OPS-01 API-06,"Ein Modul kann sich mit Name, Version und benötigten Feature-Flags in der Registry eintragen
+Anfragen an ein nicht aktiviertes Modul werden zentral abgewiesen, bevor sie den Modul-Code erreichen
+Registry ist über API abfragbar (z. B. für Statusseite und Lizenzoberfläche)
+Jede Modul-Instanz besitzt ein bei Provisionierung ausgestelltes Service-Credential, mit dem sie sich bei Core-seitigen Aufrufen (z. B. Audit-Nachlieferung, Nutzungsmeldung) authentifiziert – Aufrufe ohne gültiges Credential werden abgelehnt.","Anfrage an deaktiviertes Modul wird nachweislich vor Erreichen der Modul-Logik abgewiesen
+Registrierung eines Moduls mit fehlenden Pflichtangaben wird abgewiesen
+Registry-Abfrage liefert konsistente Daten nach Aktivierung/Deaktivierung eines Moduls
+Aufruf mit ungültigem/fehlendem Service-Credential wird von Core abgewiesen, mit gültigem Credential angenommen."
+API-03,Zentrales Rate-Limiting & API-Gateway-Schicht,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,5,Fertig,"PostgreSQL-basierter Rate-Limit-State, Go-Middleware","Zentrale Rate-Limiting- und Gateway-Schicht für die gesamte Core-API mit geteiltem, externem Zustand über mehrere Instanzen hinweg.",API-01,QA-04,"Rate-Limits sind pro Tenant und/oder API-Token konfigurierbar
+Rate-Limit-Zustand liegt in Postgres und ist über mehrere Dienstinstanzen hinweg korrekt geteilt
+Überschreitung liefert einen dokumentierten Statuscode mit Retry-Hinweis (z. B. Retry-After-Header)","Zwei parallel laufende Dienstinstanzen setzen dasselbe Rate-Limit korrekt durch (Mehrinstanz-Test)
+Überschreitung des Limits automatisiert getestet inklusive korrektem Statuscode/Header
+Rate-Limit-Konfiguration lässt sich pro Tenant ändern, ohne andere Tenants zu beeinflussen"
+API-04,OpenAPI-Schnittstellenbeschreibung,🔌 Core-API & Modulverwaltung,Backend,Einfach,2,5,Fertig,"OpenAPI 3.x, Go-Codegenerierung/Annotationen","Vollständige OpenAPI-Beschreibung der Core-API, automatisiert aus dem Code generiert oder gegen den Code geprüft, als Vertrag für Frontend und Drittintegrationen.",API-01,QA-05,"OpenAPI-Dokument deckt alle öffentlichen Core-Endpunkte ab
+Dokument wird automatisiert gegen die tatsächlichen Routen geprüft (kein Drift)
+Dokument ist über einen Endpunkt abrufbar und in gängigen Tools (z. B. Swagger UI) darstellbar","Automatisierter Abgleich zwischen Routen und OpenAPI-Dokument schlägt bei Drift fehl (getestet mit absichtlich entfernter Route)
+Beispielaufrufe aus dem Dokument gegen die echte API erfolgreich ausgeführt
+Dokument von zweiter Person auf Verständlichkeit geprüft"
+OPS-01,Health-Check-Endpunkte je Modul,📈 Monitoring & Betrieb,Backend,Einfach,2,4,Fertig,"Go, PostgreSQL-Ping, Job-Queue-Status","Health-/Readiness-Endpunkte für den Core-Dienst und je registriertes Modul, die echte Abhängigkeiten (DB, Queue) statt nur den Prozessstatus prüfen.",API-02,OPS-02 OPS-03 OPS-04,"Health-Endpunkt meldet den tatsächlichen Zustand von Datenbank und Job-Queue, nicht nur ""Prozess läuft""
+Readiness- und Liveness-Zustand sind getrennt abfragbar
+Ausfall einer Abhängigkeit (z. B. Datenbank) wird im Health-Status sichtbar, bevor Nutzeranfragen fehlschlagen","Simulierter Datenbankausfall führt zu einem korrekt gemeldeten ""nicht bereit""-Zustand (automatisierter Test)
+Health-Endpunkt antwortet auch unter Last innerhalb definierter Zeit
+Readiness- und Liveness-Antwort unterscheiden sich nachweislich in mindestens einem Fehlerfall"
+OPS-02,Zentrale Statusseite,📈 Monitoring & Betrieb,Frontend,Mittel,3,5,Fertig,Next.js/React/TypeScript,"Öffentliche/interne Statusseite, die den Health-Zustand aller Module aggregiert darstellt, inklusive Verlauf vergangener Vorfälle.",OPS-01 SHL-01,,"Statusseite zeigt den aktuellen Zustand aller registrierten Module auf einen Blick
+Ausfall eines einzelnen Moduls wird deutlich hervorgehoben, ohne die gesamte Seite unbrauchbar zu machen
+Verlauf vergangener Statusänderungen ist einsehbar","Simulierter Ausfall eines Moduls wird auf der Statusseite innerhalb der dokumentierten Abfragefrequenz sichtbar
+Seite bleibt bedienbar, auch wenn ein Modul nicht antwortet (kein Totalausfall der Seite)
+Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen"
+OPS-03,Metrics-Aggregation über Module hinweg,📈 Monitoring & Betrieb,Backend,Mittel,3,5,Fertig,"Prometheus-Textformat, Go, /metrics-Endpunkt","Zentraler Metrics-Endpunkt im Prometheus-Textformat, der Kennzahlen des Core-Dienstes und aggregierte Kennzahlen der registrierten Module bereitstellt.",OPS-01,OPS-05 QA-05,"Core-Dienst liefert unter /metrics Kennzahlen im Prometheus-Textformat
+Kennzahlen registrierter Module werden eingesammelt und unter klar benannten Metrik-Namen aggregiert
+Metrik-Namenskonvention ist dokumentiert und modulübergreifend konsistent","Metrics-Endpunkt liefert unter Last innerhalb definierter Zeit eine Antwort
+Neu registriertes Modul erscheint ohne Codeänderung des Core-Dienstes in der Metrik-Aggregation
+Metrik-Ausgabe erfolgreich gegen einen echten Prometheus-Scrape-Vorgang geprüft"
+QA-01,Teststrategie Core,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Fertig,"Go testing, Testcontainer/PostgreSQL, CI-Gate","Verbindliche Teststrategie für NEXARCH Core festlegen: Testpyramide, Pflichttests für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, Testdatenbank-Strategie.",,,"Teststrategie ist dokumentiert und definiert verbindliche Testpflichten je Bereich (Auth, Tenant-Scoping, Policy)
+CI-Gate verhindert das Mergen von Code ohne die geforderten Testarten
+Testdatenbank-Strategie (z. B. isolierte Testcontainer je Lauf) ist eingerichtet und dokumentiert","CI-Lauf mit absichtlich fehlendem Pflichttest schlägt kontrolliert fehl (Negativtest des Gates selbst)
+Testdatenbank-Isolation zwischen parallelen Testläufen automatisiert geprüft
+Dokumentation von zweiter Person gegengelesen und für verständlich befunden"
+QA-02,Prüfgate Identität & Mandanten,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,Manuelle und automatisierte Prüfliste,"Prüfgate, das Tenant-Verwaltung und Identitäts-/Login-Flows gemeinsam gegen die Akzeptanzkriterien der zugrundeliegenden Kacheln abnimmt, bevor sie als abgeschlossen gelten.",TEN-05 IAM-08 TEN-06 TEN-07 IAM-05 IAM-09 IAM-10 IAM-11 IAM-12 IAM-13 IAM-14,QA-05,"Alle Akzeptanzkriterien von TEN-01 bis TEN-07 und IAM-01 bis IAM-14 sind gegengeprüft und dokumentiert
+End-to-End-Fluss ""Mandant anlegen → Benutzer einladen → anmelden"" ist einmal vollständig durchgespielt
+Gefundene Abweichungen sind als Tickets/Notizen festgehalten, nicht stillschweigend ignoriert","End-to-End-Fluss von zweiter Person unabhängig nachvollzogen
+Cross-Tenant-Stichprobe (zwei Mandanten, zwei Benutzer) auf Datenlecks geprüft
+Prüfprotokoll mit Ergebnis je Kriterium liegt schriftlich vor"
+QA-03,Prüfgate Rechte & Policy,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,Manuelle und automatisierte Prüfliste,"Prüfgate für das gesamte Rollen-/Rechte-/Policy-Enforcement-Paket (RBAC-01 bis RBAC-05) inklusive gezielter Versuche, die zentrale Durchsetzung zu umgehen.",RBAC-05 RBAC-04,QA-05,"Alle Akzeptanzkriterien von RBAC-01 bis RBAC-05 sind gegengeprüft und dokumentiert
+Gezielte Umgehungsversuche der zentralen Policy-Schicht (z. B. direkter Repository-Zugriff) sind protokolliert erfolglos
+Modul-scoped Berechtigungen (RBAC-04) sind im Zusammenspiel mit Lizenz-/Flag-Zustand geprüft","Umgehungsversuch der zentralen Enforcement-Schicht von zweiter Person unabhängig nachgestellt und protokolliert
+Rollenwechsel-Szenario (Hoch- und Rückstufung) automatisiert und manuell geprüft
+Prüfprotokoll mit Ergebnis je Kriterium liegt schriftlich vor"
+QA-04,Sicherheits- & Penetrationsprüfung Core,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Fertig,"Manuelle Sicherheitsprüfung, ggf. automatisierte Scan-Tools","Gezielte Sicherheitsprüfung der sensibelsten Core-Bereiche: zentrale Policy-Durchsetzung, SSO/OIDC, Account-Lockout/Rate-Limiting und API-Gateway, inklusive expliziter Prüfung der bekannten Fehlerklassen aus den Altsystemen.",RBAC-02 IAM-06 IAM-07 API-03 API-10 API-08 API-09 IAM-10 IAM-11 IAM-13,QA-05,"SSO/OIDC-Flow ist gegen Token-Manipulation, Replay und Claims-Manipulation geprüft
+Rate-Limiting/Account-Lockout ist im Mehrinstanz-Betrieb nachweislich nicht umgehbar
+Zentrale Policy-Durchsetzung ist gegen mindestens einen gezielten Umgehungsversuch je Modul geprüft
+Master-Key- und Tenant-KEK-Verwaltung (API-10) ist gegen Schlüsselkompromittierung und Rotation geprüft","Mehrinstanz-Umgehungsversuch des Rate-Limitings protokolliert erfolglos
+Manipulierter OIDC-Token/Claim wird zuverlässig abgewiesen (protokolliert)
+Ergebnisse sind mit Schweregrad bewertet und mit Verweis auf betroffenes Ticket dokumentiert"
+QA-05,Abnahme- & Compliance-Prüfung Core,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Fertig,"Manuelle Abnahmeprüfung, Compliance-Checkliste","Abschließende Abnahmeprüfung, die die Ergebnisse aller vorangegangenen Gates zusammenführt und die Compliance-Anforderungen (Audit-Log, Nachvollziehbarkeit, Datentrennung) gesamthaft bestätigt.",QA-02 QA-03 QA-04 QA-07 QA-08 QA-09 TEN-08 AUD-02 API-04 OPS-03 API-06 AUD-05 API-07 LIC-05 OPS-04 OPS-05 OPS-06 IAM-15,QA-06,"Ergebnisse aller vorgelagerten Prüfgates (QA-02, QA-03, QA-04, QA-07, QA-08, QA-09) liegen konsolidiert vor und sind widerspruchsfrei
+Audit-Log deckt alle sicherheitsrelevanten Vorgänge aus den geprüften Bereichen nachweislich ab
+Offene Punkte aus den Vorgänger-Gates sind entweder behoben oder bewusst mit Begründung zurückgestellt","Stichprobenartiger Abgleich Audit-Log gegen tatsächlich durchgeführte Testaktionen ohne Lücken
+Konsolidiertes Abnahmeprotokoll von zweiter Person gegengelesen
+Freigabeentscheidung ist schriftlich mit Datum und Verantwortlicher festgehalten"
+API-05,Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,4,Fertig,"JWKS/Public-Key-Distribution, TTL-Cache","Öffentlichen Schlüssel für die JWT-Signaturprüfung modulübergreifend verteilen (JWKS-Endpunkt oder Konfigurationsverteilung) und einen Rechte-/Feature-Flag-Cache-Kontrakt definieren (TTL, Invalidierungs-Ereignis, Verhalten bei abgelaufenem Cache ohne Core-Erreichbarkeit), damit DMS/Mail/Archive/Workflow JWTs lokal verifizieren können, ohne pro Aufruf einen synchronen Request an Core zu stellen.",IAM-02 LIC-02,API-06 QA-07 QA-08,"Andere Module verifizieren die JWT-Signatur lokal ohne Request an Core
+Rechte-/Feature-Flag-Cache hat eine definierte TTL und ein dokumentiertes Verhalten bei abgelaufenem Cache während Core nicht erreichbar ist (fail-open für Lesevorgänge mit letztbekanntem Stand vs. fail-closed für sicherheitskritische Aktionen – beides benennen und begründen)
+Schlüsselrotation ist ohne Ausfallzeit der anderen Module möglich","Core wird simuliert abgeschaltet, andere Module bleiben für bereits authentifizierte Nutzer funktionsfähig bis Cache-TTL abläuft
+Neue Logins schlagen während Core-Ausfall korrekt und mit klarer Fehlermeldung fehl, statt andere Funktionen mitzureißen
+Schlüsselrotation getestet, keine Downtime in einem simulierten zweiten Modul"
+API-06,Wiederanlauf & Nachsynchronisierung nach Core-Ausfall,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,5,Fertig,"Health-Check-Trigger, Postgres-Pufferqueue, Service-Credential-Authentifizierung","Nach Core-Ausfall: sofortiger Cache-Refresh bei erkannter Wiedererreichbarkeit (Health-Check-getriggert, nicht TTL-Ablauf abwarten), lokal gepufferte Audit-Events und Nutzungszähler-Inkremente werden über das in API-02 definierte Service-Credential authentifiziert an Core nachgeliefert (gleiches Postgres-Queue-Muster wie der Rest des Projekts – lokale Pufferung, kein Datenverlust).",API-05 API-02,QA-05,"Cache-Refresh erfolgt innerhalb einer kurzen, definierten Zeitspanne nach erkannter Core-Wiedererreichbarkeit, nicht erst nach Ablauf der regulären TTL
+Während eines simulierten Ausfalls lokal gepufferte Audit-Events sind nach Wiederanlauf vollständig und in korrekter Reihenfolge in Core's zentralem Audit-Log vorhanden
+Nutzungszähler-Differenz aus der Ausfallzeit ist nach Wiederanlauf korrekt nachgebucht, keine Doppelzählung","Core simuliert für definierten Zeitraum abgeschaltet, währenddessen Aktionen in einem zweiten Modul ausgeführt, nach Core-Neustart Audit-Log auf Vollständigkeit und Reihenfolge geprüft
+Nutzungszähler vor Ausfall, während simulierter Aktivität, nach Nachbuchung verglichen – Endstand korrekt
+Cache-Refresh-Latenz nach Wiedererreichbarkeit gemessen und gegen Zielwert geprüft"
+AUD-05,Audit-Log-Registrierung bei Archive-Retention-Engine,📜 Audit & Compliance,Backend,Einfach,2,3,Fertig,"Modul-Adapter-Registrierung, GoBD-Frist","Audit-Log-Eintrag als Objekttyp bei der Archive-Retention-Engine registrieren (über den Modul-Adapter aus Archive RET-05), Default-Aufbewahrungsfrist von 10 Jahren (GoBD-Buchungsbeleg-Frist) für Audit-Log-Einträge konfigurieren. Core implementiert dafür keine eigene Löschlogik – Fristverwaltung und tatsächliche Löschung/Aufbewahrungssperre laufen vollständig über Archive.",AUD-01 RET-01 RET-02 RET-05,QA-05,"Audit-Log-Eintrag ist bei der Archive-Retention-Engine als Objekttyp registriert
+Default-Frist von 10 Jahren ist als Konfiguration hinterlegt, pro Tenant überschreibbar sofern rechtlich zulässig
+Core selbst löscht oder sperrt keine Audit-Einträge eigenständig – jede Löschung/Sperre läuft ausschließlich über die Archive-Engine","Registrierung bei Archive erfolgreich getestet, Objekttyp taucht in Archive's Retention-Konfiguration auf
+Audit-Eintrag mit Frist in der Vergangenheit wird von Archive korrekt als löschfällig markiert, Core greift nicht eigenständig ein
+Löschsperre (Legal Hold) aus Archive verhindert Löschung eines Audit-Eintrags trotz abgelaufener Frist"
+API-07,Zentrale Webhook-Registry & Zustellung,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,5,Fertig,"Go, PostgreSQL-Jobqueue, HTTP-Webhooks, HMAC-Signatur","Modulübergreifende Webhook-Registry: Module (DMS/Mail/Archive/Workflow/AI) registrieren Ereignistypen, externe Abonnenten registrieren Ziel-URLs. Zustellung mit Retry/Backoff über die bestehende Postgres-Jobqueue-Architektur (kein Redis/AMQP). Payloads werden HMAC-signiert, damit der Empfänger die Authentizität prüfen kann.",API-01,QA-05,"Beliebiges Modul kann ein Ereignis zur Zustellung einreichen, ohne selbst eine Zustellungs-Engine zu implementieren
+Fehlgeschlagene Zustellung wird mit exponentiellem Backoff wiederholt, nach konfigurierbarer Obergrenze als endgültig fehlgeschlagen markiert
+Payload ist HMAC-signiert, Empfänger kann Authentizität prüfen","Testereignis wird zuverlässig zugestellt
+Simulierter Zielausfall löst Retry mit Backoff aus, endet nach Obergrenze in „fehlgeschlagen“
+Signaturprüfung beim Empfänger erfolgreich, manipulierte Payload wird erkannt"
+LIC-05,Speicherverbrauch-Metrik je Tenant,🎫 Lizenzierung & Feature Flags,Backend,Einfach,2,3,Fertig,"PostgreSQL, atomare Inkrement-/Dekrement-Operation","Leichtgewichtiger Zähler je Tenant für belegten Speicherplatz. Objekt-Storage-Treiber der Module (DMS FDN-03, Mail ARC-01) melden bei jedem Schreib-/Löschvorgang die Objektgröße; LIC-03 fragt diesen Zähler zur Durchsetzung von Speicherplatz-Quotas ab.",LIC-01,QA-05,"Zähler pro Tenant wird bei jedem Schreib-/Löschvorgang im Objekt-Storage korrekt aktualisiert, unabhängig davon welches Modul den Vorgang auslöst
+Inkrement/Dekrement ist atomar, keine Race-Condition bei parallelen Schreibvorgängen
+LIC-03 kann den aktuellen Verbrauch je Tenant jederzeit abfragen, ohne den Objekt-Storage selbst zu scannen","Paralleler Schreib-Test (viele gleichzeitige Uploads) ergibt korrekten Endstand ohne verlorene Updates
+Löschvorgang dekrementiert korrekt
+Abfrage über LIC-03 liefert konsistenten Wert mit einer unabhängigen Kontrollzählung"
+API-08,Security-Header-Baseline für alle Frontends,🔌 Core-API & Modulverwaltung,Backend,Einfach,2,5,Fertig,"HTTP-Security-Header, CSP, HSTS, gemeinsame Middleware-Bibliothek","Gemeinsame Security-Header-Middleware (CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options) als wiederverwendbare Konfiguration, die jedes Modul-Frontend (DMS, Mail, Workflow, AI, Connect) einbindet, statt sie pro Modul einzeln neu zu definieren.",API-01,QA-04,"CSP ohne unsafe-inline/unsafe-eval als Ausgangspunkt definiert
+HSTS mit angemessener max-age gesetzt
+Konfiguration ist eine gemeinsame Bibliothek/Middleware, kein Copy-Paste pro Modul","Automatisierter Header-Scan gegen alle Modul-Frontends bestätigt vollständige Header-Abdeckung
+CSP-Verstoß (absichtlicher Test mit Inline-Script) wird blockiert
+HSTS-Header bei erneutem Aufruf über HTTP erzwingt HTTPS-Redirect"
+API-09,mTLS zwischen Modul-Instanzen (verteilte Installation),🔌 Core-API & Modulverwaltung,Backend,Mittel,3,5,Fertig,"mTLS, X.509-Zertifikate, Zertifikatsrotation","Gegenseitige TLS-Authentifizierung zwischen Core/DMS/Mail/Archive/Workflow/AI/Connect-Instanzen für Stufe-2/3-Installationen (siehe SKALIERUNGSKONZEPT.md), damit Modul-zu-Modul-Kommunikation nicht nur durch Service-Credentials (API-02) sondern auch transportverschlüsselt und gegenseitig authentifiziert ist. Für Stufe-1-Einzel-LXC optional/nicht zwingend (lokale Kommunikation).",API-01,QA-04 OPS-07,"Zertifikatsverteilung für Modul-Instanzen dokumentiert und automatisierbar
+Verbindung ohne gültiges Client-Zertifikat wird abgelehnt
+Zertifikatsrotation ohne Ausfallzeit möglich","Verbindungsversuch mit ungültigem/fehlendem Zertifikat wird abgelehnt
+Rotation im Testbetrieb ohne Verbindungsabbruch durchgeführt
+Stufe-1-Betrieb funktioniert weiterhin ohne mTLS-Zwang"
+API-10,Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung),🔌 Core-API & Modulverwaltung,Backend,Mittel,4,5,Fertig,"KMS-Anbindung, Umgebungsvariable/Secret-Provider, Envelope-Encryption-Rotationsschnittstelle","Zweistufige Schlüsselhierarchie: EIN Master-Key (Root-KEK) in Core verpackt ausschließlich Tenant-Schlüssel (Tenant-KEK), niemals Objekte direkt. Jeder Tenant bekommt bei Provisionierung (TEN-01) einen eigenen Tenant-KEK. DMS/Mail beziehen für ihre pro-Objekt-DEKs nur den Tenant-KEK ihres Mandanten, authentifiziert über API-02-Service-Credential.",API-01 TEN-01 API-02,QA-04 API-13 IAM-19,"Master-Key ausschließlich über Umgebungsvariable/Secret-Provider, nie im Code oder in der Datenbank im Klartext
+Jeder Tenant erhält bei Provisionierung einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry gespeichert — niemals ein gemeinsamer Schlüssel für mehrere Mandanten
+Rotation ist auf beiden Ebenen unabhängig möglich, ohne Neuverschlüsselung der Objektdaten: Master-Key-Rotation verpackt nur alle Tenant-KEKs neu; Tenant-KEK-Rotation verpackt nur die DEKs dieses einen Mandanten neu und berührt keinen anderen Tenant
+DMS und Mail beziehen den Tenant-KEK über denselben Mechanismus (Service-Credential-authentifizierter Core-Aufruf), keine parallele Implementierung","Master-Key-Rotation getestet: alle Tenant-KEKs weiterhin entschlüsselbar, kein Objekt in DMS/Mail neu verschlüsselt
+Tenant-KEK-Rotation für einen Mandanten getestet: nur dessen DEKs werden neu verpackt, ein zweiter Mandant bleibt davon nachweislich unberührt
+Zugriff auf einen Tenant-KEK ohne gültiges Service-Credential (API-02) oder mit dem Credential eines FREMDEN Mandanten wird abgelehnt"
+OPS-04,Incident-Response-Plan (inkl. DSGVO-Meldefristen),📈 Monitoring & Betrieb,Backend,Einfach,2,5,Fertig,"Betriebsdokument, Eskalationsprozess, Audit-Log-Anknüpfung","Dokumentierter Ablaufplan für Sicherheitsvorfälle – Erkennung, Eskalation, Kommunikation, DSGVO-Meldefrist (72 Stunden an Aufsichtsbehörde bei meldepflichtigem Vorfall), Verantwortlichkeiten, Nachbereitung. Kein neues Software-Feature, sondern ein Betriebsdokument plus die technischen Anknüpfungspunkte (welche Logs/Audit-Daten im Vorfall herangezogen werden, siehe Core AUD-01).",OPS-01,QA-05,"Ablaufplan dokumentiert Erkennung/Eskalation/Meldefristen/Verantwortlichkeiten
+DSGVO-72-Stunden-Meldefrist ist als Prozessschritt mit Verantwortlichem hinterlegt
+Plan verweist konkret auf die Audit-Log-Quellen (Core AUD-01/AUD-05), die im Vorfall herangezogen werden","Simulierte Vorfallsübung (Tabletop) einmal durchgespielt und dokumentiert
+Meldefrist-Prozess auf Vollständigkeit geprüft
+Kontaktliste/Eskalationskette aktuell und erreichbar bestätigt"
+QA-06,Externe Sicherheitsprüfung / Penetrationstest vor Produktivbetrieb,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,8,Backlog,"Externer Penetrationstest, Findings-Nachverfolgung","Projektweiter, externer Penetrationstest über alle sieben Boards (Core/DMS/Mail/Archive/Workflow/AI/Connect) vor dem ersten Produktivbetrieb – ergänzt die internen Sicherheits-Prüfgates der einzelnen Boards (z.B. Core QA-04), die Entwicklerprüfungen sind, kein externer Test.",QA-05 QA-07 QA-08 AUD-06,,"Penetrationstest durch unabhängige externe Partei durchgeführt, nicht durch das Entwicklungsteam selbst
+Kritische/hohe Befunde vor Produktivbetrieb behoben, nicht nur dokumentiert
+Ergebnis und Behebung sind nachvollziehbar dokumentiert (Audit-fähig)","Testbericht liegt vor
+Nachtest bestätigt Behebung kritischer Befunde
+Freigabe für Produktivbetrieb ist an dieses Ergebnis gekoppelt, nicht unabhängig davon erteilt"
+SHL-01,UI-Shell & Design-System (zentral),🎨 UI-Shell,Frontend,Mittel,3,1,Fertig,"Komponentenbibliothek, Tokens, WCAG-2.1-AA-Grundkomponenten, i18n-Framework (de/en), zentrales Theming (Hell/Dunkel)","Layout-Shell mit Navigation, Basis-Komponenten (Tabelle, Dialog, Formularelemente, Toast) und Design-Tokens für Farben, Abstände, Typografie – als gemeinsames Paket für die gesamte NEXARCH-Plattform. WCAG 2.1 AA, ein i18n-Rahmen (mind. Deutsch/Englisch) und Theming (Hell/Dunkel) sind verbindliche Eigenschaften dieses Design-Systems, keine optionalen Erweiterungen – Modul-Frontends erben sie strukturell, statt sie einzeln zu bauen oder zu prüfen.",,,"Shell mit Navigation und Inhaltsbereich steht, modulübergreifend einbindbar
+Basis-Komponenten dokumentiert, versioniert und als gemeinsames Paket von allen Modul-Frontends importierbar, nicht kopiert
+Design-Tokens zentral gepflegt, Modul-Frontends überschreiben sie nicht lokal
+Basis-Komponenten erfüllen WCAG 2.1 AA (Kontrast, Tastaturbedienung, ARIA-Attribute) als Grundeigenschaft, nicht als Nachrüstung je Modul
+i18n-Rahmen (mind. Deutsch/Englisch) ist in der Shell verankert; Modul-Frontends binden Übersetzungen darüber ein statt eigener Lösung
+Theming (Hell/Dunkel) ist zentral über Design-Tokens gesteuert; Modul-Frontends schalten nur um, bauen kein eigenes Theming","Komponenten auf 3 Breakpoints visuell geprüft
+Tastaturbedienung der Basis-Komponenten funktioniert
+Kontrastwerte erfüllen mindestens AA
+Mindestens zwei verschiedene Modul-Frontends (z. B. DMS und Mail) importieren dieselbe Komponentenbibliothek ohne Duplikat
+Sprachumschaltung Deutsch/Englisch an einer Beispielkomponente geprüft
+Umschaltung Hell/Dunkel an einer Beispielkomponente ohne Layoutbruch geprüft"
+TEN-06,Connection-Routing & Pooling pro Mandant,🏢 Mandantenverwaltung,Backend,Komplex,4,2,Fertig,"Go/pgx, PostgreSQL, Connection-Pooling (PgBouncer-artig oder LRU-verwalteter Pool)","Anhand von Tenant-Kontext (JWT-Claim) die richtige Tenant-Datenbank-Verbindung auflösen (Lookup in der Registry) und darüber eine Verbindung/Pool bereitstellen, ohne pro Tenant dauerhaft offene Verbindungen zu halten.",TEN-01,QA-08 QA-02 TEN-11,"Verbindung zur richtigen Tenant-Datenbank wird zuverlässig anhand des Tenant-Kontexts aufgelöst
+Verbindungs-Pooling verhindert, dass die Zahl offener Postgres-Verbindungen linear mit der Mandantenzahl wächst
+Falscher/fehlender Tenant-Kontext führt zu explizitem Fehler, nicht zu einer Verbindung „irgendeiner“ Datenbank","Lasttest mit vielen simulierten Mandanten bleibt unter der Postgres-Verbindungsobergrenze
+Anfrage ohne gültigen Tenant-Kontext wird abgelehnt, nicht stillschweigend geroutet
+Verbindungswiederverwendung nachweislich gemessen (nicht bei jeder Anfrage neu verbunden)"
+TEN-07,Migrations-Orchestrierung über alle Tenant-Datenbanken,🏢 Mandantenverwaltung,Backend,Komplex,4,2,Fertig,"Go/pgx, PostgreSQL, SQL-Migrationen","Automatisiertes, fehlerisoliertes Ausrollen neuer SQL-Migrationen gegen jede registrierte Tenant-Datenbank inklusive nachvollziehbarem Migrationsstand je Mandant.",TEN-01,QA-02 TEN-10,"Eine neue Migration wird automatisiert gegen alle registrierten Tenant-Datenbanken ausgerollt
+Fehlschlag bei einem Mandanten blockiert nicht die Migration der anderen
+Migrationsstand ist pro Tenant-Datenbank einzeln nachvollziehbar (welche Version, wann, Erfolg/Fehler)","Rollout gegen mehrere Test-Tenant-Datenbanken, eine davon absichtlich inkompatibel gemacht – Rest läuft trotzdem durch
+Migrationsstand-Abfrage liefert für jeden Tenant den korrekten, unabhängigen Stand
+Wiederholter Rollout-Versuch für die fehlgeschlagene Migration ist möglich, ohne die bereits erfolgreichen erneut anzuwenden"
+QA-07,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,5,Fertig,"Vertragstests, CI-Pipeline","Vertragstests für die Core-APIs, die von DMS, Mail, Archive, Workflow, AI und Connect konsumiert werden (REST-Grundgerüst, JWKS/Rechte-Cache-Kontrakt, Modul-Registry, Webhook-Registry) – jede Breaking Change wird automatisiert erkannt, bevor sie ein konsumierendes Modul bricht.",API-01 API-05,QA-05 QA-06,"Vertragstests decken alle sechs von Fachmodulen konsumierten Core-Schnittstellen ab
+Ein absichtlich brechender Schema-Wechsel lässt die Vertragstests fehlschlagen
+Vertragstests laufen automatisiert in der CI, nicht nur manuell","Testlauf gegen aktuellen Core-API-Stand grün
+Simulierte Breaking Change (z.B. Feld entfernt) lässt mindestens einen Vertragstest fehlschlagen
+CI-Integration nachgewiesen"
+QA-08,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,5,Fertig,"Lastgenerator, Messprotokoll","Lasttest für Core unter realistischer Last aus sechs gleichzeitig zugreifenden Fachmodulen – insbesondere JWKS-Verifikations-Pfad, Tenant-Connection-Pooling und Rate-Limiting unter Last.",API-05 TEN-06,QA-05 QA-06,"Definierte Ziel-Latenz für JWT-Verifikation unter Last eingehalten
+Connection-Pooling bleibt unter der Postgres-Verbindungsobergrenze bei simulierter Vielzahl an Mandanten
+Rate-Limiting funktioniert korrekt unter Mehrinstanz-Last, nicht nur im Einzelinstanz-Test","Lasttest mit simulierten parallelen Anfragen aus mehreren Modulen durchgeführt, Ergebnis dokumentiert
+Verbindungszahl bei vielen simulierten Mandanten-Datenbanken gemessen
+Rate-Limit-Verhalten bei mehreren Core-Instanzen gleichzeitig geprüft"
+IAM-10,Passwortlose Anmeldung via WebAuthn/Passkey,👤 Identität & Authentifizierung,Backend,Mittel,3,4,Fertig,"WebAuthn, FIDO2/CTAP, PostgreSQL","WebAuthn/Passkey als alternativer Anmeldefaktor zu Passwort+TOTP – Registrierung eines Authenticators (Plattform wie Windows Hello/Touch ID, oder externer Sicherheitsschlüssel) und Anmeldung ohne Passworteingabe.",IAM-02,QA-02 QA-04,"Benutzer kann einen WebAuthn-Authenticator registrieren und sich damit anmelden, ohne Passwort einzugeben
+Mehrere Authenticatoren pro Benutzer sind möglich (Gerätewechsel/-verlust)
+Passwort+TOTP bleibt als Fallback nutzbar, kein Zwang auf WebAuthn","Registrierung und Anmeldung mit simuliertem Authenticator im Test erfolgreich
+Zweiter Authenticator registriert, beide funktionsfähig
+Login mit Passwort+TOTP funktioniert weiterhin unverändert"
+IAM-11,SAML 2.0-Anbindung,👤 Identität & Authentifizierung,Backend,Komplex,4,4,Fertig,"SAML 2.0, XML-Signaturprüfung, PostgreSQL","SAML 2.0 als zusätzlicher Anmeldeweg neben OIDC (IAM-06) – für Kunden, deren Identity Provider nur SAML spricht (viele Enterprise-/Behörden-Umgebungen).",IAM-02,QA-02 QA-04,"SAML-Anmeldung gegen einen Test-Identity-Provider funktioniert
+SAML- und OIDC-Anmeldung können nebeneinander für unterschiedliche Tenants konfiguriert sein
+SAML-Assertion wird korrekt auf das bestehende Benutzer-/Rollenmodell (IAM-01/RBAC) abgebildet","End-to-End-Test gegen simulierten SAML-IdP erfolgreich
+Zwei Tenants mit unterschiedlichem Anmeldeweg (SAML vs. OIDC) im Test parallel funktionsfähig
+Rollenzuordnung aus SAML-Attributen im Test korrekt"
+OPS-05,Alerting bei Schwellwert-Überschreitung,📈 Monitoring & Betrieb,Backend,Mittel,3,6,Fertig,"Schwellwert-Regeln als Konfiguration, CFG-02-Benachrichtigungs-Dispatcher, Drosselung/Debouncing","Schwellwert-basierte Alarmierung auf den aus OPS-03 aggregierten Metriken (z.B. Fehlerrate, Job-Queue-Länge, Speicherverbrauch nahe Quota, Postgres-Verbindungsauslastung) – Benachrichtigung über den Core-Benachrichtigungs-Dispatcher (CFG-02) an Verantwortliche, koppelt direkt an den Incident-Response-Plan (OPS-04): Alerting ist der technische Auslöser, der Plan ist der Ablauf danach.",OPS-03,QA-05,"Schwellwert-Regeln auf beliebigen aggregierten Metriken definierbar
+Überschreitung löst eine Benachrichtigung über CFG-02 aus, mit klarer Zuordnung welche Metrik/welcher Tenant/welches Modul betroffen ist
+Wiederholte Alarmierung für denselben anhaltenden Zustand ist gedrosselt (kein Alarm-Spam bei dauerhaft überschrittenem Wert)
+Alerting nimmt auch Meldungen von Integritäts-Scrub-Jobs (z. B. Archive BAK-08) auf – Regeln wirken generisch auf jede aggregierte Metrik, unabhängig davon, ob sie ein Systemwert (Fehlerrate, Queue-Länge) oder ein diskreter Prüfbefund (z. B. storage_integrity_failures) ist","Test: Metrik überschreitet konfigurierten Schwellwert, Benachrichtigung wird ausgelöst
+Benachrichtigungsinhalt im Test auf Vollständigkeit (Metrik/Tenant/Modul) geprüft
+Test: anhaltende Überschreitung erzeugt nicht bei jeder Messung eine neue Benachrichtigung"
+IAM-12,Aktive-Sitzungen-Verwaltung,👤 Identität & Authentifizierung,Backend,Mittel,3,4,Fertig,"Session/JWT, Go/net/http","Nutzer sieht seine eigenen aktiven Sitzungen (Gerät/Browser, IP, letzter Zugriff) und kann einzelne oder alle widerrufen (z. B. bei verlorenem Gerät).",IAM-02,QA-02,"Nutzer kann eigene aktive Sitzungen mit Geräte-/Zugriffsinformationen einsehen
+Einzelne Sitzung ist gezielt widerrufbar, wird beim nächsten Zugriffsversuch sofort ungültig
+„Alle anderen Sitzungen beenden“ ist als Sammelaktion möglich, aktuelle Sitzung bleibt bestehen","Test: zwei Sitzungen desselben Nutzers angelegt, beide in der Übersicht sichtbar
+Widerruf einer Sitzung im Test macht das zugehörige Token sofort ungültig
+„Alle anderen beenden“ im Test funktioniert korrekt, aktuelle bleibt aktiv"
+IAM-13,OIDC-Provider für Drittanwendungen,👤 Identität & Authentifizierung,Backend,Komplex,4,5,Fertig,"OpenID Connect, OAuth2, JWKS","NEXARCH tritt selbst als OIDC/OAuth2-Identity-Provider auf (nicht nur als Konsument wie IAM-06), damit Drittanwendungen eines Kunden (z. B. eigene interne Tools, Connect-Board-Integrationen) sich gegen NEXARCH-Benutzerkonten authentifizieren können – Client-Registrierung, Authorization-Code-Flow, eigene JWKS-Ausgabe.",IAM-02 IAM-06,QA-02 QA-04,"Drittanwendung kann sich als OAuth2-Client registrieren
+Authorization-Code-Flow gegen NEXARCH-Benutzerkonten funktioniert end-to-end
+Ausgestellte Tokens sind über die bestehende JWKS-Infrastruktur (API-05) verifizierbar, kein zweites Schlüsselsystem","Test-Client registriert, vollständiger Authorization-Code-Flow im Test erfolgreich
+Ausgestelltes Token durch Drittanwendung erfolgreich gegen JWKS verifiziert
+Rollen-/Scope-Einschränkung im Test wirksam (Client sieht nur zugestandene Scopes)"
+IAM-14,Passwort-Richtlinien,👤 Identität & Authentifizierung,Backend,Einfach,2,4,Fertig,"Go/net/http, PostgreSQL","Konfigurierbare Passwort-Komplexitätsanforderungen (Mindestlänge, Zeichenklassen, Sperrliste häufiger Passwörter) pro Tenant durchsetzbar – bisher regelt IAM-02 nur den bcrypt-Hashing-Mechanismus selbst, keine Anforderungen an das Passwort davor.",IAM-02,QA-02,"Mindestanforderungen (Länge, Zeichenklassen) sind pro Tenant konfigurierbar
+Passwort aus einer Sperrliste häufig verwendeter/kompromittierter Passwörter wird abgelehnt
+Bestehende Nutzer mit nicht-konformem Passwort werden beim nächsten Login zur Änderung aufgefordert, nicht rückwirkend zwangsweise ausgesperrt","Test: zu kurzes/zu einfaches Passwort wird bei Registrierung/Änderung abgelehnt
+Test: Passwort aus Sperrliste wird abgelehnt
+Test: bestehender Nutzer mit altem, nicht-konformem Passwort kann sich noch einloggen, wird aber zur Änderung aufgefordert"
+TEN-08,Tenant-Löschung unter Retention-Vorbehalt (GoBD),🏢 Mandantenverwaltung,Backend,Mittel,2,3,Fertig,Prüf-Aufruf gegen Archive RET-03/CMP-06 vor finaler Löschung,"Vor der endgültigen Tenant-Löschung (nach Ablauf der Karenzzeit aus TEN-04) wird geprüft, ob GoBD-relevante Daten des Tenants noch unter Aufbewahrungspflicht (10-Jahres-Frist) oder Legal Hold stehen. Solange eine Sperre besteht, wird die endgültige Löschung verweigert und der Tenant bleibt im Zustand ""zur Löschung vorgemerkt, aber gesperrt"".",TEN-04 RET-03,QA-05,"Endgültige Löschung wird abgewiesen, solange GoBD-relevante Daten des Tenants unter Aufbewahrungspflicht oder Legal Hold stehen
+Grund der Sperre (Aufbewahrungsklasse, Frist, Legal Hold) ist für Admins einsehbar
+Nach Ablauf aller Aufbewahrungsfristen und Aufhebung aller Sperren lässt sich die Löschung erneut anstoßen und wird dann ausgeführt","Löschung eines Tenants mit aktiver Aufbewahrungspflicht wird abgewiesen, Grund wird protokolliert
+Löschung eines Tenants mit Legal Hold wird abgewiesen
+Löschung eines Tenants ohne verbleibende Sperren wird nach Karenzzeit korrekt ausgeführt"
+QA-09,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,6,Fertig,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller Core-Oberflächen (Tenant-Verwaltung, Login/Profil, Rechte-Administration, Lizenz-/Modul-Verwaltung, Audit-Log-Ansicht, Benachrichtigungs-Einstellungen, zentrale Statusseite) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",TEN-05 IAM-08 RBAC-05 LIC-04 AUD-04 CFG-04 OPS-02,QA-05,"Keine kritischen Verstöße offen
+Manueller Bildschirmleser-Durchlauf dokumentiert
+Restbefunde sind mit Frist eingeplant","Automatisierte Prüfung über alle Hauptseiten
+Vollständiger Ablauf ohne Maus durchgeführt
+Auditbericht abgelegt"
+OPS-06,Automatisiertes Schwachstellen-Scanning (Supply-Chain),📈 Monitoring & Betrieb,Backend,Einfach,2,5,Fertig,"govulncheck (Go-Module), npm audit/Dependabot (Frontend-Pakete), CI-Gate","Automatisiertes Schwachstellen-Scanning für Go-Module (govulncheck) und npm-Pakete (npm audit/Dependabot) als wiederkehrender CI-Schritt über alle sieben Boards – ergänzt die reine Lint-/Test-/Build-Pipeline jedes Boards um Supply-Chain-Sicherheit, statt Abhängigkeiten ungeprüft zu vertrauen.",OPS-01,QA-05,"govulncheck läuft als verbindlicher CI-Schritt gegen alle Go-Module aller sieben Boards
+npm audit (oder Dependabot-Äquivalent) läuft als verbindlicher CI-Schritt gegen alle Next.js-Frontends
+Ein Fund mit kritischem/hohem Schweregrad blockiert den Merge, statt nur eine Warnung zu erzeugen","Absichtlich veraltete, verwundbare Testabhängigkeit wird vom CI-Lauf erkannt und blockiert den Merge
+Scan-Ergebnis ist als CI-Artefakt/Log nachvollziehbar abgelegt"
+IAM-15,Timing-safe Vergleich als projektweite Coding-Konvention,👤 Identität & Authentifizierung,Backend,Einfach,1,5,Fertig,"crypto/subtle.ConstantTimeCompare (Go), projektweite Coding-Guideline","Verbindliche, dokumentierte Coding-Konvention: jeder Vergleich, der eine sicherheitsrelevante Zugriffsentscheidung trifft (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nutzt einen timing-safe/constant-time Vergleich – nicht nur an einer Stelle vorgemacht, sondern als projektweite Regel wie das bereits bestehende Sprintf-Verbot für SQL.",IAM-04,QA-05,"Projektweite Coding-Konvention dokumentiert: jeder sicherheitsrelevante Vergleich (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode) nutzt einen timing-safe/constant-time Vergleich, nie den regulären ==-Operator
+Konvention ist in einer projektweiten Coding-Guideline abgelegt, nicht nur an einer Beispielstelle im Code
+Mindestens die bereits bestehenden Vergleichsstellen (IAM-04 2FA-Code, Core-Signaturprüfung) sind auf die Konvention geprüft und ggf. korrigiert","Code-Review-Checkliste/Guideline enthält die Regel mit Beispiel
+Stichprobe bestehender Vergleichsstellen (2FA, Signaturprüfung) zeigt konsequente Anwendung"
+AUD-06,Audit-Log-Verdrahtung in sicherheitsrelevante Core-Handler,📜 Audit & Compliance,Backend,Mittel,3,8,Fertig,internal/audit.Log-Aufrufe in bestehenden Handlern,"Der zentrale, unveränderliche Audit-Log (AUD-01/AUD-02) existiert und ist eigenständig getestet, wird aber von keinem Produktions-Handler tatsächlich befüllt. internal/policy.Store.Grant/Revoke (RBAC-02), Tenant-Lebenszyklus-Übergänge (TEN-04), Login-Fehlversuche/Sperren (IAM-07) und Tenant-KEK-Rotation (API-10) rufen internal/audit.Log.Record nirgends auf — Befund aus QA-05 (Stichprobenabgleich Audit-Log gegen tatsächlich durchgeführte Testaktionen, 0 Treffer).",AUD-01 AUD-02 RBAC-02 TEN-04 IAM-07 API-10,QA-06,"internal/policy.Store.Grant und Revoke schreiben bei jedem Aufruf einen internal/audit.Log-Eintrag
+Tenant-Lebenszyklus-Übergänge (internal/tenant.Registry.transition) schreiben bei jedem Übergang einen internal/audit.Log-Eintrag
+Login-Fehlversuche, Kontosperrung/-entsperrung (internal/lockout.Store) und Tenant-KEK-Rotation (internal/kek.Store.RotateTenantKEK/RotateMasterKey) schreiben jeweils einen internal/audit.Log-Eintrag","Für jeden der vier betroffenen Bereiche (Policy, Tenant-Lifecycle, Lockout, KEK-Rotation) wird eine reale Aktion ausgeführt und per direkter Abfrage der audit_events-Tabelle nachgewiesen, dass ein passender Eintrag entstanden ist (derselbe Nachweisstil wie der QA-05-Stichprobenabgleich)
+Bestehende Tests aller vier betroffenen Pakete bleiben grün (rein additive Verdrahtung, keine Verhaltensänderung der bestehenden Funktionen)
+QA-05-Stichprobenabgleich wird nach dieser Kachel wiederholt und liefert für dieselbe Stichprobe jetzt einen Treffer"
+RBAC-06,Modulübergreifender HTTP-Endpunkt für Policy-Entscheidungen,🔐 Rollen & Rechte,Backend,Mittel,2,5,Fertig,"Go/net/http, wrappt bestehendes internal/policy (RBAC-02)","HTTP-Endpunkt, der RBAC-02s Enforcer.Authorize für andere, physisch getrennte Module (DMS, Mail, Archive) per Service-zu-Service-Aufruf zugänglich macht — schließt die Lücke, die Archive RET-06-API als dokumentiertes Provisorium umgehen musste, wiederverwendbar für alle künftigen Module. Ersetzt das dokumentierte Provisorium aus Archive RET-06-API.",RBAC-02,,"Ein HTTP-Endpunkt nimmt Rolle+Permission (+ Tenant-Kontext) entgegen und liefert dieselbe Entscheidung wie Enforcer.Authorize direkt
+Der Endpunkt ist service-zu-service-authentifiziert (kein offener, unauthentifizierter Zugriff)
+Archive RET-06-API (und künftige Module) können ihren provisorischen Header-Check durch einen echten Aufruf ersetzen, ohne dass sich das Verhalten der Policy-Entscheidung ändert","Endpunkt-Antwort stimmt in 100 Stichproben exakt mit dem direkten Enforcer.Authorize-Ergebnis überein
+Aufruf ohne gültige Service-Credentials wird abgewiesen (401/403), nicht mit einer Policy-Entscheidung beantwortet
+Ein simulierter Fremd-Modul-Testclient fragt real gegen den laufenden Endpunkt ab und erhält korrekte Allow/Deny-Antworten"
+CFG-05,Modulübergreifender HTTP-Endpunkt für Benachrichtigungs-Ereignisse,⚙️ Zentrale Konfiguration & Benachrichtigungen,Backend,Klein,1,5,Fertig,"Go, HTTP","internal/notifyprefs.EnqueueIfAllowed (CFG-04) als HTTP-Endpunkt (POST /notify) fuer andere, physisch getrennte Module (Archive, DMS, Mail) bereitstellen, service-token-authentifiziert. Gleiches Muster wie RBAC-06 fuer internal/policy.Enforcer.Authorize: reiner Wrapper, keine zweite Ereignis-Logik.",CFG-04,,"Ein physisch getrenntes Modul kann ueber HTTP ein Benachrichtigungs-Ereignis auslösen, ohne internal/notifyprefs direkt zu importieren
+Aufruf ohne gueltige Service-Credentials wird abgewiesen, nicht mit einer Zustellung beantwortet
+Endpunkt-Verhalten (Praeferenz-Filter, Dedupe) stimmt exakt mit dem direkten EnqueueIfAllowed-Aufruf ueberein","Endpunkt-Antwort stimmt in mehreren Stichproben mit dem direkten EnqueueIfAllowed-Ergebnis ueberein (aktiviert/deaktiviert)
+Aufruf ohne Service-Token wird abgewiesen (401), Handler nachweislich nie erreicht
+Ein simulierter Fremd-Modul-Testclient loest real ueber den laufenden Endpunkt ein Ereignis aus"
+API-11,Wiederanlauf-Nachsynchronisierungs-Endpunkt starten (API-06 als laufender Dienst),🔌 Core-API & Modulverwaltung,Backend,Klein,1,5,Fertig,"Go, HTTP","internal/resync.Handler.UsageHandler (API-06) existiert als fertiger Go-Handler, laeuft aber nirgends als Dienst - cmd/core/main.go ist minimal (nur /healthz und /internal/tenants aus der TEN-01-Aera) und mountet keine der spaeter gebauten Module. API-11 startet den Handler als eigenstaendigen HTTP-Dienst (main.go + systemd), OHNE neue Logik - reines Wiring, analog RBAC-06/CFG-05/RET-09.",API-06,,"internal/resync.Handler.UsageHandler laeuft als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein externer Modul-Client (z.B. DMS storage.HTTPUsageReporter) kann real POST /internal/resync/usage gegen den laufenden Dienst aufrufen
+Keine neue Logik - reiner Start des bestehenden Handlers","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer POST /internal/resync/usage von einem externen Testclient gegen den laufenden Dienst liefert die erwartete Verarbeitung (wie in API-06 getestet)
+Code-Review: keine Aenderung an internal/resync/ selbst, nur main.go+systemd neu"
+IAM-16,Login/Account-Dienst starten (IAM-08 als laufender Dienst),👤 Identität & Authentifizierung,Backend,Mittel,1,5,Fertig,"Go, HTTP, Session-Cookies, TOTP","internal/auth, internal/authtoken, internal/totp (IAM-08) existieren als fertige Go-Handler, laufen aber nirgends als Dienst - cmd/core/main.go ist minimal (nur /healthz, /internal/tenants aus TEN-01). IAM-16 setzt sie zu einem laufenden Login/Account-HTTP-Dienst zusammen (main.go + systemd), OHNE neue Logik - reines Wiring, analog RBAC-06/CFG-05/RET-09/API-11, aber groesserer Zusammensetzungsaufwand wegen mehrerer sicherheitsrelevanter Pakete (Session, TOTP, Passwort-Reset).",IAM-08,,"Login/Account-Endpunkte (auth/login, auth/password-reset/*, account/change-password, account/me) laufen als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein externer Client (Browser/Testclient) kann real gegen den laufenden Dienst einloggen und ein Profil abrufen
+Keine neue Logik - reiner Zusammenschluss der bestehenden Handler, keine Aenderung an internal/auth, internal/authtoken, internal/totp","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer Login-Versuch (korrektes Passwort) gegen den laufenden Dienst liefert eine gueltige Session, falsches Passwort wird abgelehnt
+Code-Review: keine Aenderung an internal/auth/, internal/authtoken/, internal/totp/ selbst, nur main.go+systemd neu"
+RBAC-07,Rechte-Administrations-Dienst starten (RBAC-05 als laufender Dienst),🔐 Rollen & Rechte,Backend,Klein,1,5,Fertig,"Go, HTTP, Session-Auth (IAM-16)","internal/rbac.Handler (RBAC-05) existiert als fertiger Go-Handler, laeuft aber nirgends als Dienst. RBAC-07 startet ihn als eigenstaendigen HTTP-Dienst (main.go + systemd), hinter derselben Session-Auth wie IAM-16 (gleicher JWT-Secret, damit Sessions cross-service gueltig sind) - reines Wiring, keine neue Logik.",RBAC-05 IAM-16,,"internal/rbac.Handler laeuft als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein mit IAM-16 eingeloggter Nutzer (gueltiges Session-Cookie) kann real gegen den laufenden Dienst Rollen abfragen/zuweisen
+Keine neue Logik - reiner Start des bestehenden Handlers, gleicher JWT-Secret wie account-api (IAM-16)","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer Aufruf mit gueltigem IAM-16-Session-Cookie liefert die erwartete Rollenliste, ohne/mit falschem Cookie 401/403
+Code-Review: keine Aenderung an internal/rbac/ selbst, nur main.go+systemd neu"
+CFG-06,Benachrichtigungs-Einstellungen-Dienst starten (CFG-04 als laufender Dienst),⚙️ Zentrale Konfiguration & Benachrichtigungen,Backend,Klein,1,5,Fertig,"Go, HTTP, Session-Auth (IAM-16)","internal/notifyprefs.Handler (CFG-04) existiert als fertiger Go-Handler, laeuft aber nirgends als Dienst. CFG-06 startet ihn als eigenstaendigen HTTP-Dienst (main.go + systemd), hinter derselben Session-Auth wie IAM-16 (gleicher JWT-Secret) - reines Wiring, keine neue Logik.",CFG-04 IAM-16,,"internal/notifyprefs.Handler laeuft als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein mit IAM-16 eingeloggter Nutzer (gueltiges Session-Cookie) kann real eigene Benachrichtigungspraeferenzen setzen/abrufen
+Keine neue Logik - reiner Start des bestehenden Handlers, gleicher JWT-Secret wie account-api (IAM-16)","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer Aufruf mit gueltigem IAM-16-Session-Cookie setzt/liest eine echte Praeferenz, ohne Cookie 401
+Code-Review: keine Aenderung an internal/notifyprefs/ selbst, nur main.go+systemd neu"
+API-12,KEK-Bezugsdienst starten (API-10 als laufender Dienst),🔌 Core-API & Modulverwaltung,Backend,Klein,1,5,Fertig,"Go, HTTP","internal/kek.Handler.TenantKEKHandler (API-10) existiert als fertiger Go-Handler, laeuft aber nirgends als Dienst. API-12 startet ihn als eigenstaendigen HTTP-Dienst (main.go + systemd) - reines Wiring, keine neue Logik, analog RBAC-06/CFG-05/RET-09/API-11.",API-10,,"internal/kek.Handler.TenantKEKHandler laeuft als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein externer Modul-Client (z.B. Mail ARC-02, DMS FDN-09) kann real den Tenant-KEK ueber den laufenden Dienst beziehen
+Keine neue Logik - reiner Start des bestehenden Handlers","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer Aufruf mit gueltigem Service-Credential liefert den erwarteten Tenant-KEK, ohne/mit falschem Credential wird abgelehnt
+Code-Review: keine Aenderung an internal/kek/ selbst, nur main.go+systemd neu"
+TEN-09,Registry-Härtung & Zugriffsschutz,🏢 Mandantenverwaltung,Backend,Mittel,3,9,Fertig,"PostgreSQL, Netzwerksegmentierung, dedizierte DB-Rollen, AUD-01-Kopplung","Die Control-Plane-Registry (TEN-01) hält Tenant-Liste, Verbindungsinformationen zu allen Tenant-Datenbanken sowie Superadmin-Konten – ihre Kompromittierung gefährdet alle Mandanten gleichzeitig, anders als eine einzelne Tenant-Datenbank. Registry als eigene Schutzzone härten: dedizierter Datenbank-Benutzer mit Minimalrechten für den Core-Prozess (kein Zugriff auf Tenant-Datenbanken selbst über dieselbe Rolle), Netzwerkzugriff auf die Registry-Datenbank auf den Core-Dienst beschränken, sowie ein eigenes Audit-Event für jeden lesenden und schreibenden Zugriff auf Superadmin-Konten und Verbindungsinformationen.",TEN-01 AUD-01,,"Core-Prozess greift über eine Datenbankrolle auf die Registry zu, die keine Rechte auf Tenant-Datenbanken besitzt
+Jeder Zugriff auf Superadmin-Konten oder Verbindungsinformationen in der Registry erzeugt einen eigenen Audit-Event (Kopplung an AUD-01)
+Netzwerkzugriff auf die Registry-Datenbank ist auf den Core-Dienst beschränkt, dokumentiert in der Betriebsanleitung","Testet, dass die Registry-Datenbankrolle keine Tenant-Datenbank lesen/schreiben kann (negativer Zugriffstest)
+Simuliert Lesezugriff auf Superadmin-Konten und prüft, dass ein Audit-Event mit korrektem Akteur/Zeitpunkt entsteht
+Prüft Firewall-/pg_hba.conf-Konfiguration gegen Zugriff von außerhalb des Core-Dienstes"
+API-13,Master-Key-Rotation & Zugriffs-Audit,🔌 Core-API & Modulverwaltung,Backend,Mittel,3,9,Fertig,"KMS-Anbindung, Rotationsschnittstelle, AUD-01-Kopplung","API-10 etabliert die zweistufige Schlüsselhierarchie (Master-KEK → Tenant-KEK → Objekt-DEK), definiert aber keinen erzwungenen Rotationsprozess und kein dediziertes Audit-Ereignis für Zugriffe auf den Master-Key selbst. Eine Kompromittierung des Master-Keys hebelt die gesamte Hierarchie aus. Rotationsschnittstelle für Master-KEK und Tenant-KEKs ergänzen (Re-Envelope bestehender Tenant-KEKs bei Master-Key-Rotation, ohne Objekt-DEKs neu verschlüsseln zu müssen), sowie jeden Zugriff auf den Master-Key (Entschlüsselung eines Tenant-KEK) als eigenen, hochprivilegierten Audit-Event protokollieren.",API-10 AUD-01,,"Master-KEK-Rotation re-verschlüsselt alle Tenant-KEKs auf den neuen Master-Key, ohne Objekt-DEKs anzufassen
+Jede Entschlüsselung eines Tenant-KEK durch den Master-Key erzeugt einen eigenen Audit-Event-Typ, sichtbar von normalen Audit-Events getrennt
+Rotationsintervall ist konfigurierbar und wird bei Überschreitung als Warnung im OPS-Monitoring sichtbar","Rotationstest: Master-Key rotieren, prüfen dass alle Tenant-KEKs weiterhin entschlüsselbar sind und Objekt-DEKs unverändert bleiben
+Prüft, dass jeder Tenant-KEK-Zugriff einen Audit-Event mit Akteur (Service-Credential), Zeitpunkt und betroffenem Tenant erzeugt
+Prüft Alarmierung bei überschrittenem Rotationsintervall"
+IAM-17,Session-/Token-Widerruf bei Logout und Kompromittierung,👤 Identität & Authentifizierung,Backend,Mittel,3,9,Fertig,"Session/JWT, Revocation-Store (PostgreSQL), Go/net/http","IAM-02 definiert Login/Session/JWT-Grundgerüst, aber kein Widerrufsmechanismus: ein ausgestelltes JWT bleibt bis zum regulären Ablauf gültig, auch nach explizitem Logout oder bei erkanntem Diebstahl. Revocation-Store ergänzen (z. B. Session-/Token-Tabelle mit Gültigkeits-Flag), den die Auth-Middleware bei jeder geschützten Anfrage zusätzlich zur Signaturprüfung konsultiert, sowie einen Admin-/Self-Service-Endpunkt zum sofortigen Widerruf einzelner oder aller Sessions eines Benutzers.",IAM-02,,"Nach explizitem Logout ist das zugehörige Token/die Session sofort ungültig, auch vor Ablauf der TTL
+Ein Benutzer oder Admin kann alle aktiven Sessions eines Kontos auf einen Schlag widerrufen (z. B. bei Verdacht auf Kompromittierung)
+Die Auth-Middleware prüft bei jeder Anfrage zusätzlich zur Signatur den Widerrufsstatus, mit vertretbarem Performance-Overhead (In-Prozess-Cache mit kurzer TTL zulässig)","Logout-Test: Token nach Logout gegen geschützten Endpunkt verwenden, erwartet Ablehnung
+Massenwiderruf-Test: alle Sessions eines Benutzers widerrufen, prüfen dass alle zugehörigen Tokens abgelehnt werden, andere Benutzer unberührt bleiben
+Lasttest der Widerrufsprüfung gegen die Auth-Middleware, um Performance-Regression auszuschließen"
+IAM-18,Strikte Claim-Validierung bei OIDC-SSO,👤 Identität & Authentifizierung,Backend,Mittel,2,9,Fertig,"OpenID Connect, JWKS, Issuer-/Audience-Pinning","IAM-06 baut SSO-Anmeldung über OIDC mit Rollen-Mapping aus Claims, ohne explizit zu definieren, wie Issuer, Audience und Signatur geprüft werden. Strikte Validierung ergänzen: Issuer und Audience je Tenant fest hinterlegt statt aus dem Token selbst gelesen, Signatur ausschließlich gegen die JWKS des konfigurierten Issuers geprüft, und eine explizite Sperre, dass aus externen Claims niemals automatisch eine Superadmin-Rolle abgeleitet werden kann – Superadmin bleibt ausschließlich lokal vergebbar.",IAM-06,,"Login wird abgelehnt, wenn Issuer oder Audience des Tokens nicht exakt mit der für den Tenant hinterlegten Konfiguration übereinstimmt
+Signaturprüfung verwendet ausschließlich die JWKS des konfigurierten Issuers, nie einen im Token selbst mitgelieferten Schlüssel/Issuer
+Rollen-Mapping aus externen Claims kann technisch keine Superadmin-Rolle vergeben, unabhängig vom Claim-Inhalt","Negativtest: Token mit falschem Issuer/Audience wird abgelehnt
+Negativtest: manipuliertes Token mit fremdem Signaturschlüssel wird abgelehnt
+Negativtest: externer Claim behauptet Superadmin-Rolle, Login vergibt trotzdem höchstens die höchste zulässige tenant-scoped Rolle"
+RBAC-08,Testfall gegen Tenant-zu-Superadmin-Rechteeskalation,🔐 Rollen & Rechte,QA,Einfach,1,9,Fertig,"Automatisierte Tests, Casbin-Policy-Prüfung","RBAC-01 definiert das Rollenmodell mit Rollenhierarchie, aber kein Ticket prüft explizit, dass ein Tenant-Admin über Rollenvererbung oder Policy-Fehlkonfiguration niemals den Superadmin-Scope erreichen kann. Verbindlichen automatisierten Testfall (Teil der QA-Prüfgates) ergänzen, der jede Rollen-/Policy-Änderung gegen diese Invariante prüft.",RBAC-01,,"Automatisierter Test schlägt fehl, sobald eine Rollen-/Policy-Änderung einem Tenant-Admin (oder abgeleiteten Rollen) Superadmin-Rechte einräumt
+Test läuft als Pflichtgate in der CI bei jeder Änderung an Rollenmodell oder Policy-Definitionen
+Testfall ist dokumentiert und Teil der QA-Prüfgates (Referenz aus QA-03/QA-05)","Test gezielt mit einer absichtlich fehlerhaften Policy (Tenant-Admin erbt Superadmin) ausführen, muss fehlschlagen
+Test gegen die aktuelle, korrekte Policy ausführen, muss erfolgreich durchlaufen"
+AUD-07,Technische Durchsetzung Append-only Audit-Log,📜 Audit & Compliance,Backend,Einfach,2,9,Fertig,"PostgreSQL (REVOKE/Trigger), Go","AUD-01 konzipiert das Audit-Log als append-only, setzt dies aber nur als Konvention um – ein Datenbank-Superuser oder eine kompromittierte Anwendungsrolle könnte Einträge weiterhin ändern oder löschen. Append-only technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE- und DELETE-Rechte auf die Audit-Tabelle vollständig entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch protokolliert und ablehnt.",AUD-01,,"Die vom Core-Prozess verwendete Datenbankrolle kann Audit-Einträge nachweislich weder verändern noch löschen (fehlende Rechte, nicht nur fehlender Code-Pfad)
+Ein Versuch, einen Audit-Eintrag zu ändern oder zu löschen, wird von der Datenbank abgelehnt und selbst protokolliert
+Bestehende AUD-01-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar","Testet UPDATE/DELETE gegen die Audit-Tabelle mit der Anwendungsrolle, erwartet Datenbankfehler (Rechteverweigerung)
+Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+Regressionstest: normales Schreiben/Lesen von Audit-Einträgen funktioniert weiterhin"
+TEN-10,Integritätsprüfung von SQL-Migrationen vor Tenant-Rollout,🏢 Mandantenverwaltung,Backend,Mittel,2,10,Fertig,"PostgreSQL, SQL-Migrationen, Checksummen/Signaturprüfung, Go","TEN-07 rollt Migrationen automatisiert gegen jede Tenant-Datenbank aus und behandelt Fehler pro Tenant, prüft aber nicht die Integrität der Migrationsdatei selbst vor dem Rollout. Eine manipulierte oder versehentlich falsche Migrationsdatei würde sonst automatisch gegen JEDE Tenant-Datenbank angewendet – 1:N-Risiko statt 1:1. Checksummenprüfung (z. B. SHA-256) je Migrationsdatei ergänzen, die vor dem ersten Anwenden gegen eine hinterlegte, versionierte Prüfsumme im Migrations-Manifest abgeglichen wird; bei Abweichung wird der gesamte Rollout abgebrochen, bevor auch nur eine Tenant-Datenbank betroffen ist.",TEN-07,,"Jede Migrationsdatei hat einen Eintrag mit Prüfsumme im Migrations-Manifest, der vor dem Rollout erzeugt/versioniert wird
+Der Rollout gegen alle Tenant-Datenbanken startet nur, wenn die tatsächliche Prüfsumme der Migrationsdatei mit dem Manifest-Eintrag übereinstimmt
+Bei Prüfsummen-Abweichung wird der Rollout vollständig abgebrochen, bevor eine einzige Tenant-Datenbank verändert wurde, und es entsteht ein Audit-Event","Test mit unveränderter Migrationsdatei: Rollout läuft normal durch
+Test mit nachträglich manipulierter Migrationsdatei (Prüfsumme weicht ab): Rollout bricht vor der ersten Tenant-Datenbank ab
+Prüft, dass der Abbruch einen nachvollziehbaren Audit-Event erzeugt (wer/was/wann)"
+TEN-11,Deckelung & Rate-Limit für Tenant-Connection-Pooling,🏢 Mandantenverwaltung,Backend,Mittel,2,10,Fertig,"Go/pgx, LRU-Pool, Rate-Limiting",TEN-06 löst Tenant-Datenbankverbindungen per LRU-verwaltetem Pool auf. Ohne Obergrenze kann ein fehlerhafter oder böswilliger Client durch häufigen Tenant-Wechsel ständiges Verbindungsauf- und -abbauen erzwingen (Pool-Thrashing) und damit die Datenbank-Verbindungslast für alle anderen Mandanten erhöhen. Eine harte Obergrenze für gleichzeitig offene Pools sowie ein Rate-Limit auf die Tenant-Wechsel-Rate pro Client/Service-Credential ergänzen.,TEN-06,,"Die Anzahl gleichzeitig offener Tenant-Connection-Pools ist konfigurierbar gedeckelt
+Ein einzelner Client/Service-Credential kann die Tenant-Wechsel-Rate nicht über ein konfiguriertes Limit hinaus treiben, ohne abgelehnt/gedrosselt zu werden
+Bei Erreichen der Obergrenze wird der am längsten unbenutzte Pool verdrängt (LRU), keine Anfrage schlägt hart fehl, solange das Wechsel-Rate-Limit eingehalten wird","Lasttest mit vielen parallelen Tenant-Wechseln eines einzelnen Clients: Rate-Limit greift, andere Mandanten bleiben unbeeinträchtigt
+Test der LRU-Verdrängung bei Erreichen der Pool-Obergrenze
+Regressionstest: normaler Betrieb mit wenigen Mandanten bleibt unverändert performant"
+IAM-19,Verschlüsselte Ablage von LDAP/AD-Bind-Credentials,👤 Identität & Authentifizierung,Backend,Mittel,2,10,Fertig,"LDAP/AD, Envelope-Encryption (Tenant-KEK aus API-10), PostgreSQL","IAM-05 bindet je Tenant an LDAP/Active Directory an, ohne festzulegen, wie das Bind-Passwort gespeichert wird. Bind-Credentials über den Tenant-KEK aus der Schlüsselhierarchie (API-10) verschlüsseln statt in einer separaten, eigenen Secret-Verwaltung oder gar Klartext in der Tenant-Konfiguration abzulegen.",IAM-05 API-10,,"LDAP-Bind-Passwort ist in der Datenbank ausschließlich verschlüsselt gespeichert, entschlüsselt mit dem Tenant-KEK des jeweiligen Mandanten
+Ein direkter Lesezugriff auf die Konfigurationstabelle liefert keinen verwertbaren Klartext des Bind-Passworts
+Bestehende LDAP-Synchronisation/Login-Delegation aus IAM-05 funktioniert unverändert","Test: LDAP-Bind-Passwort in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist
+Regressionstest: LDAP-Login/Synchronisation funktioniert nach Umstellung auf verschlüsselte Ablage weiterhin korrekt
+Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Bind-Credentials)"
+LIC-06,Fail-Closed-Verhalten der Lizenz-/Feature-Flag-Prüfung bei Registry-Ausfall,🎫 Lizenzierung & Feature Flags,Backend,Einfach,1,10,Fertig,"PostgreSQL, In-Prozess-Cache, Go","LIC-01/LIC-02 prüfen Lizenz und Feature-Flags gegen die Registry mit In-Prozess-Cache, ohne explizit festzulegen, wie sich die Prüfung bei einem Ausfall der Registry-Datenbank oder einem Cache-Invalidierungssturm verhält. Verbindliches Fail-Closed-Verhalten für die Lizenzprüfung festlegen und implementieren: ist weder Cache noch Registry erreichbar, wird der Zugriff verweigert statt stillschweigend erlaubt; für reine Feature-Flags (nicht lizenzrelevant) ist ein definiertes, dokumentiertes Fallback-Verhalten (letzter bekannter Cache-Stand mit Ablaufzeit) zulässig.",LIC-01 LIC-02,,"Ist bei einer Lizenzprüfung weder der In-Prozess-Cache noch die Registry erreichbar, wird der Zugriff verweigert (Fail-Closed), nicht stillschweigend erlaubt
+Für reine Feature-Flag-Abfragen (nicht lizenzrelevant) ist das Fallback-Verhalten dokumentiert und über einen Ablaufzeitpunkt des letzten Cache-Stands begrenzt
+Ein Cache-Invalidierungssturm bei Massenänderung führt nicht zu kurzzeitig falsch erteilten Lizenz-Freigaben","Test: Registry-Datenbank simuliert nicht erreichbar, Cache leer/abgelaufen — Lizenzprüfung verweigert Zugriff
+Test: Massenänderung an Feature-Flags gleichzeitig mit vielen Anfragen — keine falsch-positive Freigabe während der Invalidierung
+Regressionstest: normaler Betrieb mit erreichbarer Registry bleibt unverändert"
+OPS-07,Betriebs-Gate: mTLS-Aktivierungspflicht beim Wechsel auf verteilten Betrieb,📈 Monitoring & Betrieb,Backend,Einfach,1,10,Fertig,"Betriebsdokument, Health-/Readiness-Check, mTLS (API-09)","API-09 macht mTLS zwischen Modul-Instanzen für Stufe-2/3-Installationen (siehe SKALIERUNGSKONZEPT.md) verfügbar, aber für Stufe-1-Einzel-LXC optional. Ohne expliziten Gate-Mechanismus kann beim späteren Wechsel von Stufe 1 auf Stufe 2 (verteilter Betrieb) vergessen werden, mTLS zu aktivieren — Modul-zu-Modul-Aufrufe liefen dann nur mit Service-Credential ohne Transport-Auth. Einen Readiness-Check ergänzen, der bei mehr als einer Instanz/Host erkennt, dass mTLS zwischen Modulen (noch) nicht aktiv ist, und dies als Warnung im Monitoring (OPS) sichtbar macht, sowie einen Eintrag in der Betriebs-Checkliste für den Stufenwechsel.",API-09,,"Wird mehr als eine Modul-Instanz/mehr als ein Host erkannt und ist mTLS zwischen Modulen nicht aktiv, erscheint eine Warnung im Monitoring (OPS)
+Betriebs-Checkliste für den Wechsel Stufe 1 → Stufe 2 (SKALIERUNGSKONZEPT.md) enthält mTLS-Aktivierung als Pflichtschritt
+Bei aktivem mTLS und/oder Einzel-LXC-Betrieb erscheint keine Warnung","Simulierter Mehr-Instanz-Betrieb ohne mTLS: Warnung erscheint im Monitoring
+Simulierter Mehr-Instanz-Betrieb mit aktivem mTLS: keine Warnung
+Prüft, dass die Betriebs-Checkliste den mTLS-Schritt beim Stufenwechsel enthält"
+IAM-20,Anomalie-Erkennung bei API-Token-/Service-Account-Nutzung,👤 Identität & Authentifizierung,Backend,Mittel,2,11,Fertig,"PostgreSQL, IP-/Rate-Heuristik, Core-Audit-Kopplung (AUD-01)","IAM-09 deckt Scopes und Ablaufzeit für API-Token/Service-Accounts ab, aber ein gestohlenes, noch gültiges Token bleibt bis zum Ablauf unauffällig nutzbar. Einfache Anomalie-Erkennung ergänzen: Nutzung eines Tokens aus einer bisher nicht gesehenen IP-Range oder mit einer gegenüber dem bisherigen Muster stark abweichenden Zugriffsrate erzeugt einen Audit-Event mit erhöhtem Schweregrad (Kopplung an AUD-01) und optional eine Benachrichtigung an den Token-Besitzer/Tenant-Admin über den Core-Dispatcher (CFG-02). Keine automatische Sperre – die Erkennung ist ein Hinweissignal, keine eigenständige Durchsetzung, um Fehlalarme nicht zu blockierenden Vorfällen zu machen.",IAM-09 AUD-01,,"Nutzung eines API-Tokens/Service-Accounts aus einer bisher nicht beobachteten IP-Range erzeugt einen Audit-Event mit erhöhtem Schweregrad
+Ein gegenüber dem historischen Muster stark abweichender Zugriffsratenanstieg desselben Tokens erzeugt ebenfalls einen Audit-Event
+Das Token bleibt bei erkannter Anomalie weiterhin gültig (keine automatische Sperre) – die Erkennung dient als Hinweissignal, tatsächliche Sperre erfolgt manuell oder über einen bewussten separaten Prozess","Test: Zugriff mit einem Token aus einer neuen IP-Range erzeugt den erwarteten Audit-Event
+Test: künstlich stark erhöhte Zugriffsrate desselben Tokens erzeugt den erwarteten Audit-Event
+Regressionstest: normale, unauffällige Token-Nutzung erzeugt keine Falsch-Alarme im regulären Betrieb"

core-kanban/kanban.html

@@ -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>Core Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Core 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": 204, "epics": [{"key": "TEN", "name": "Mandantenverwaltung", "emoji": "🏢", "color": "#0EA5E9", "description": "Mandanten-Datenmodell, Onboarding, Einstellungen, Lifecycle und Verwaltungsoberfläche."}, {"key": "IAM", "name": "Identität & Authentifizierung", "emoji": "👤", "color": "#8B5CF6", "description": "Benutzer, Login, Sessions, 2FA, LDAP, OIDC-SSO, Lockout und Service-Accounts."}, {"key": "RBAC", "name": "Rollen & Rechte", "emoji": "🔐", "color": "#F59E0B", "description": "Rollenmodell, zentrale Policy-Durchsetzung, Gruppen, modul-scoped Rechte."}, {"key": "LIC", "name": "Lizenzierung & Feature Flags", "emoji": "🎫", "color": "#EC4899", "description": "Lizenzmodell, Feature-Flags je Tenant, Nutzungszähler/Quotas und Verwaltungsoberfläche."}, {"key": "AUD", "name": "Audit & Compliance", "emoji": "📜", "color": "#EF4444", "description": "Zentrales, unveränderliches Audit-Log mit Export und Ansicht."}, {"key": "CFG", "name": "Zentrale Konfiguration & Benachrichtigungen", "emoji": "⚙️", "color": "#64748B", "description": "Zentrale Konfiguration und modulübergreifender Benachrichtigungs-Dispatcher."}, {"key": "API", "name": "Core-API & Modulverwaltung", "emoji": "🔌", "color": "#14B8A6", "description": "REST-API-Grundgerüst, Modul-Registry, Rate-Limiting und OpenAPI-Beschreibung."}, {"key": "OPS", "name": "Monitoring & Betrieb", "emoji": "📈", "color": "#22C55E", "description": "Health-Checks, Statusseite und Metrics-Aggregation über alle Module."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates für Identität, Rechte, Sicherheit und Compliance."}, {"key": "SHL", "name": "UI-Shell", "emoji": "🎨", "color": "#EC4899", "description": "Gemeinsame Layout-Shell, Komponentenbibliothek und Design-Tokens für alle Modul-Frontends."}], "waves": [{"welle": 1, "codes": ["QA-01", "SHL-01", "TEN-01"]}, {"welle": 2, "codes": ["AUD-01", "CFG-01", "IAM-01", "LIC-01", "LIC-02", "TEN-02", "TEN-04", "TEN-06", "TEN-07"]}, {"welle": 3, "codes": ["API-02", "AUD-02", "AUD-03", "AUD-05", "CFG-02", "IAM-02", "LIC-03", "LIC-05", "RBAC-01", "TEN-03"]}, {"welle": 4, "codes": ["API-01", "API-05", "AUD-04", "CFG-03", "IAM-03", "IAM-04", "IAM-05", "IAM-06", "IAM-07", "IAM-09", "IAM-10", "IAM-11", "IAM-12", "IAM-14", "LIC-04", "OPS-01", "RBAC-02", "RBAC-03", "RBAC-04", "TEN-05"]}, {"welle": 5, "codes": ["API-03", "API-04", "API-06", "API-07", "API-08", "API-09", "API-10", "CFG-04", "IAM-08", "IAM-13", "OPS-02", "OPS-03", "OPS-04", "QA-07", "QA-08", "RBAC-05"]}, {"welle": 6, "codes": ["OPS-05", "QA-02", "QA-03", "QA-04"]}, {"welle": 7, "codes": ["QA-05"]}, {"welle": 8, "codes": ["QA-06"]}, {"welle": 9, "codes": ["TEN-09", "API-13", "IAM-17", "IAM-18", "RBAC-08", "AUD-07"]}, {"welle": 10, "codes": ["TEN-10", "TEN-11", "IAM-19", "LIC-06", "OPS-07"]}, {"welle": 11, "codes": ["IAM-20"]}], "kritischerPfad": {"path": ["TEN-01", "IAM-01", "RBAC-01", "RBAC-02", "RBAC-05", "QA-03", "QA-05"], "days": 20}, "produktDna": {"uebernehmen": [{"produkt": "Zitadel", "staerke": "Organisation/Projekt/Rollen-Modell mit klarer Mandantenhierarchie und Self-Service-Onboarding."}, {"produkt": "Zitadel", "staerke": "Eingebaute Unterstützung für Service-Accounts und maschinelle Benutzer neben menschlichen Identitäten."}, {"produkt": "Casbin", "staerke": "Deklaratives Policy-Modell (RBAC/ABAC) getrennt von der Anwendungslogik, zentral durchsetzbar."}, {"produkt": "Casbin", "staerke": "Policy-Entscheidungen sind testbar und versionierbar wie Code."}, {"produkt": "Unleash", "staerke": "Feature-Flags als eigenständiger Dienst mit Strategien (Prozentsatz, Zielgruppe, Tenant) statt verstreuter if-Abfragen."}, {"produkt": "Unleash", "staerke": "Klare Trennung zwischen Flag-Definition und Flag-Auswertung zur Laufzeit."}, {"produkt": "Prometheus/Grafana", "staerke": "Metriken als First-Class-Bürger jedes Moduls, offenes Pull-Modell statt proprietärem Push."}, {"produkt": "Prometheus/Grafana", "staerke": "Health-Endpunkte und Dashboards von Anfang an, nicht als Nachrüstung."}], "vermeiden": [{"schwaeche": "Keycloak – Schwergewichtige Plattform mit hohem Ressourcenbedarf und langer Startzeit.", "loesung": "Schlanker Go-Dienst statt JVM-Anwendungsserver, startklar in Sekunden."}, {"schwaeche": "Keycloak – Komplexe Realm-/Client-Konfiguration mit steiler Lernkurve.", "loesung": "Sinnvolle Voreinstellungen für Tenant-/App-Registrierung, Komplexität nur wo nachweislich nötig."}, {"schwaeche": "Zitadel – mehrschichtiges Organisation/Projekt/Grant-Modell kann für kleine Mandanten überdimensioniert wirken.", "loesung": "Einfaches, flaches Tenant→Benutzer→Rolle-Modell im ersten Ausbau, Hierarchie-Tiefe optional später."}]}, "epicDna": {"TEN": {"leitsatz": "Mandanten sind das Fundament, auf dem jede andere Kachel aufsetzt – Modell A mit applikatiLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

core-kanban/tickets/API-01.md

@@ -0,0 +1,64 @@
+# API-01 – REST-API-Grundgerüst & Versionierung
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+**Technische Grundlage:** Go/net/http, REST, URL-Versionierung
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Versionierte, dokumentierte API von Anfang an im URL-Pfad – vermeidet die inkonsistente Versionierung wie bei Keycloaks historisch gewachsener Admin-API.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. API ist unter einem versionierten Pfad (z. B. /api/v1/...) erreichbar
+2. Einheitliches Fehlerformat für alle Endpunkte etabliert und dokumentiert
+3. Middleware-Kette setzt Tenant- und Benutzerkontext für nachgelagerte Handler zuverlässig
+
+## 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. Fehlerhafte Anfrage liefert über alle Endpunkte hinweg dasselbe Fehlerschema (Stichprobe)
+2. Middleware-Kette wird durch automatisierten Test nachweislich von jedem Endpunkt durchlaufen
+3. Versionswechsel (fiktive v2-Route) lässt sich anlegen, ohne v1 zu beeinträchtigen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-03` Zentrales Rate-Limiting & API-Gateway-Schicht
+- `API-04` OpenAPI-Schnittstellenbeschreibung
+
+## 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: `API-01: rest-api-grundgeruest-versionierung`
+- Branch: `feature/api-01-rest-api-grundgeruest-versionierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-02.md

@@ -0,0 +1,64 @@
+# API-02 – Modul-Registry & Aktivierungsprüfung
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Registry, in der sich Fachmodule (DMS, Mail, weitere) mit Metadaten registrieren, gekoppelt an die Aktivierungsprüfung aus Feature-Flags/Lizenz. Zusätzlich authentifiziert die Registry Modul-Instanzen selbst über ein bei Provisionierung ausgestelltes Service-Credential (Client-ID + Secret oder kurzlebiges Service-Token), nicht nur deren Lizenz-Feature-Flags.
+
+**Technische Grundlage:** PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Registry-Gedanke nach Unleash-Vorbild – Module registrieren sich und fragen ihren Zustand ab, statt hart verdrahtet zu sein.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `LIC-02` Feature-Flag-Service je Tenant – Feature-Flag-Dienst mit Strategien (global an/aus, Prozentsatz, Tenant-Zielgruppe) und schneller Auswertung ohne externe Infrastruktur.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ein Modul kann sich mit Name, Version und benötigten Feature-Flags in der Registry eintragen
+2. Anfragen an ein nicht aktiviertes Modul werden zentral abgewiesen, bevor sie den Modul-Code erreichen
+3. Registry ist über API abfragbar (z. B. für Statusseite und Lizenzoberfläche)
+4. Jede Modul-Instanz besitzt ein bei Provisionierung ausgestelltes Service-Credential, mit dem sie sich bei Core-seitigen Aufrufen (z. B. Audit-Nachlieferung, Nutzungsmeldung) authentifiziert – Aufrufe ohne gültiges Credential werden 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. Anfrage an deaktiviertes Modul wird nachweislich vor Erreichen der Modul-Logik abgewiesen
+2. Registrierung eines Moduls mit fehlenden Pflichtangaben wird abgewiesen
+3. Registry-Abfrage liefert konsistente Daten nach Aktivierung/Deaktivierung eines Moduls
+4. Aufruf mit ungültigem/fehlendem Service-Credential wird von Core abgewiesen, mit gültigem Credential angenommen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `OPS-01` Health-Check-Endpunkte je 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: `API-02: modul-registry-aktivierungspruefung`
+- Branch: `feature/api-02-modul-registry-aktivierungspruefung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-03.md

@@ -0,0 +1,66 @@
+# API-03 – Zentrales Rate-Limiting & API-Gateway-Schicht
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentrale Rate-Limiting- und Gateway-Schicht für die gesamte Core-API mit geteiltem, externem Zustand über mehrere Instanzen hinweg.
+
+**Technische Grundlage:** PostgreSQL-basierter Rate-Limit-State, Go-Middleware
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Rate-Limiting von Anfang an mit externem, geteiltem Zustand statt In-Process-Zähler.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Rate-Limits sind pro Tenant und/oder API-Token konfigurierbar
+2. Rate-Limit-Zustand liegt in Postgres und ist über mehrere Dienstinstanzen hinweg korrekt geteilt
+3. Überschreitung liefert einen dokumentierten Statuscode mit Retry-Hinweis (z. B. Retry-After-Header)
+
+## 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. Zwei parallel laufende Dienstinstanzen setzen dasselbe Rate-Limit korrekt durch (Mehrinstanz-Test)
+2. Überschreitung des Limits automatisiert getestet inklusive korrektem Statuscode/Header
+3. Rate-Limit-Konfiguration lässt sich pro Tenant ändern, ohne andere Tenants zu beeinflussen
+
+## Bekannte Fehler vermeiden
+
+- **In-Memory Rate-Limiter ohne Shared State**: Dasselbe Risiko wie in IAM-07 gilt für das API-Gateway insgesamt – ein In-Process-Limiter ist bei Mehrinstanz-Deployment aushebelbar (siehe archivdms `internal/auth/ratelimit.go`). → Rate-Limit-State für die gesamte API zentral/extern (Postgres-basiert) auslegen, konsistent mit IAM-07.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Penetrationsprüfung Core
+
+## 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: `API-03: zentrales-rate-limiting-api-gateway-schicht`
+- Branch: `feature/api-03-zentrales-rate-limiting-api-gateway-schicht`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-04.md

@@ -0,0 +1,62 @@
+# API-04 – OpenAPI-Schnittstellenbeschreibung
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vollständige OpenAPI-Beschreibung der Core-API, automatisiert aus dem Code generiert oder gegen den Code geprüft, als Vertrag für Frontend und Drittintegrationen.
+
+**Technische Grundlage:** OpenAPI 3.x, Go-Codegenerierung/Annotationen
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** OpenAPI als verbindlicher Vertrag von Anfang an, nicht nachträgliche Dokumentation eines gewachsenen API-Zustands.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. OpenAPI-Dokument deckt alle öffentlichen Core-Endpunkte ab
+2. Dokument wird automatisiert gegen die tatsächlichen Routen geprüft (kein Drift)
+3. Dokument ist über einen Endpunkt abrufbar und in gängigen Tools (z. B. Swagger UI) darstellbar
+
+## 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 Abgleich zwischen Routen und OpenAPI-Dokument schlägt bei Drift fehl (getestet mit absichtlich entfernter Route)
+2. Beispielaufrufe aus dem Dokument gegen die echte API erfolgreich ausgeführt
+3. Dokument von zweiter Person auf Verständlichkeit geprüft
+
+## 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: `API-04: openapi-schnittstellenbeschreibung`
+- Branch: `feature/api-04-openapi-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.

core-kanban/tickets/API-05.md

@@ -0,0 +1,67 @@
+# API-05 – Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Öffentlichen Schlüssel für die JWT-Signaturprüfung modulübergreifend verteilen (JWKS-Endpunkt oder Konfigurationsverteilung) und einen Rechte-/Feature-Flag-Cache-Kontrakt definieren (TTL, Invalidierungs-Ereignis, Verhalten bei abgelaufenem Cache ohne Core-Erreichbarkeit), damit DMS/Mail/Archive/Workflow JWTs lokal verifizieren können, ohne pro Aufruf einen synchronen Request an Core zu stellen.
+
+**Technische Grundlage:** JWKS/Public-Key-Distribution, TTL-Cache
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Core darf Fundament sein, ohne zum Flaschenhals zu werden – ein Ausfall von Core darf laufenden Betrieb in anderen Modulen nicht sofort stoppen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+- `LIC-02` Feature-Flag-Service je Tenant – Verwaltung und Abfrage von Feature-Flags pro Mandant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Andere Module verifizieren die JWT-Signatur lokal ohne Request an Core
+2. Rechte-/Feature-Flag-Cache hat eine definierte TTL und ein dokumentiertes Verhalten bei abgelaufenem Cache während Core nicht erreichbar ist (fail-open für Lesevorgänge mit letztbekanntem Stand vs. fail-closed für sicherheitskritische Aktionen – beides benennen und begründen)
+3. Schlüsselrotation ist ohne Ausfallzeit der anderen Module 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. Core wird simuliert abgeschaltet, andere Module bleiben für bereits authentifizierte Nutzer funktionsfähig bis Cache-TTL abläuft
+2. Neue Logins schlagen während Core-Ausfall korrekt und mit klarer Fehlermeldung fehl, statt andere Funktionen mitzureißen
+3. Schlüsselrotation getestet, keine Downtime in einem simulierten zweiten Modul
+
+## Bekannte Fehler vermeiden
+Core als synchrone Abhängigkeit pro Request zu behandeln macht Core zum Single Point of Failure für die gesamte Plattform. Jedes Modul muss mit veralteten, aber vorhandenen Rechte-/Flag-Daten weiterarbeiten können, statt bei Core-Nichterreichbarkeit hart zu blockieren.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-02` Login/Session/JWT-Grundgerüst
+- `LIC-02` Feature-Flag-Service je Tenant
+
+## 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: `API-05: verteilte jwt-verifikation & rechte-feature-flag-cache-kontrakt`
+- Branch: `feature/api-05-verteilte-jwt-verifikation-rechte-feature-flag-cache-kontrakt`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-06.md

@@ -0,0 +1,67 @@
+# API-06 – Wiederanlauf & Nachsynchronisierung nach Core-Ausfall
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Nach Core-Ausfall: sofortiger Cache-Refresh bei erkannter Wiedererreichbarkeit (Health-Check-getriggert, nicht TTL-Ablauf abwarten), lokal gepufferte Audit-Events und Nutzungszähler-Inkremente werden über das in API-02 definierte Service-Credential authentifiziert an Core nachgeliefert (gleiches Postgres-Queue-Muster wie der Rest des Projekts – lokale Pufferung, kein Datenverlust).
+
+**Technische Grundlage:** Health-Check-Trigger, Postgres-Pufferqueue, Service-Credential-Authentifizierung
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Ein Ausfall darf keine dauerhafte Lücke in Audit-Trail oder Abrechnung hinterlassen – Nachholen ist Pflicht, nicht Kann.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt – regelt das Verhalten während eines Core-Ausfalls (lokale Verifikation, TTL-Cache).
+- `API-02` Modul-Registry & Aktivierungsprüfung – definiert die Service-Credential-Authentifizierung, mit der sich Modul-Instanzen bei Core-seitigen Aufrufen ausweisen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Cache-Refresh erfolgt innerhalb einer kurzen, definierten Zeitspanne nach erkannter Core-Wiedererreichbarkeit, nicht erst nach Ablauf der regulären TTL
+2. Während eines simulierten Ausfalls lokal gepufferte Audit-Events sind nach Wiederanlauf vollständig und in korrekter Reihenfolge in Core's zentralem Audit-Log vorhanden
+3. Nutzungszähler-Differenz aus der Ausfallzeit ist nach Wiederanlauf korrekt nachgebucht, keine Doppelzählung
+
+## 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. Core simuliert für definierten Zeitraum abgeschaltet, währenddessen Aktionen in einem zweiten Modul ausgeführt, nach Core-Neustart Audit-Log auf Vollständigkeit und Reihenfolge geprüft
+2. Nutzungszähler vor Ausfall, während simulierter Aktivität, nach Nachbuchung verglichen – Endstand korrekt
+3. Cache-Refresh-Latenz nach Wiedererreichbarkeit gemessen und gegen Zielwert geprüft
+
+## Bekannte Fehler vermeiden
+Lokal gepufferte Ereignisse dürfen bei erneutem Ausfall während der Nachlieferung nicht verloren gehen – die Pufferqueue muss selbst persistent sein (Postgres, nicht In-Memory), sonst wird aus einem kurzen Ausfall ein dauerhafter Audit-Verlust.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt
+- `API-02` Modul-Registry & Aktivierungsprü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: `API-06: wiederanlauf & nachsynchronisierung nach core-ausfall`
+- Branch: `feature/api-06-wiederanlauf-nachsynchronisierung-nach-core-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.

core-kanban/tickets/API-07.md

@@ -0,0 +1,63 @@
+# API-07 – Zentrale Webhook-Registry & Zustellung
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Modulübergreifende Webhook-Registry: Module (DMS/Mail/Archive/Workflow/AI) registrieren Ereignistypen, externe Abonnenten registrieren Ziel-URLs. Zustellung mit Retry/Backoff über die bestehende Postgres-Jobqueue-Architektur (kein Redis/AMQP). Payloads werden HMAC-signiert, damit der Empfänger die Authentizität prüfen kann.
+
+**Technische Grundlage:** Go, PostgreSQL-Jobqueue, HTTP-Webhooks, HMAC-Signatur
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+- Allgemein verbreitetes Muster – jedes Modul baut seine eigene Webhook-Zustellungs-Engine.: Eine zentrale Zustellungs-Engine für alle Module, Ereignistypen bleiben modul-eigen.
+
+**Für genau diese Kachel:** Eine zentrale Zustellungs-Engine statt N modul-eigener Nachbauten derselben Retry-/Signatur-Logik.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Beliebiges Modul kann ein Ereignis zur Zustellung einreichen, ohne selbst eine Zustellungs-Engine zu implementieren
+2. Fehlgeschlagene Zustellung wird mit exponentiellem Backoff wiederholt, nach konfigurierbarer Obergrenze als endgültig fehlgeschlagen markiert
+3. Payload ist HMAC-signiert, Empfänger kann Authentizität prüfen
+
+## 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. Testereignis wird zuverlässig zugestellt
+2. Simulierter Zielausfall löst Retry mit Backoff aus, endet nach Obergrenze in „fehlgeschlagen“
+3. Signaturprüfung beim Empfänger erfolgreich, manipulierte Payload wird erkannt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Welche Ereignistypen die einzelnen Module anbieten (das definiert jedes Modul selbst)
+
+## 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: `API-07: zentrale-webhook-registry-zustellung`
+- Branch: `feature/api-07-zentrale-webhook-registry-zustellung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-08.md

@@ -0,0 +1,62 @@
+# API-08 – Security-Header-Baseline für alle Frontends
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Gemeinsame Security-Header-Middleware (CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options) als wiederverwendbare Konfiguration, die jedes Modul-Frontend (DMS, Mail, Workflow, AI, Connect) einbindet, statt sie pro Modul einzeln neu zu definieren.
+
+**Technische Grundlage:** HTTP-Security-Header, CSP, HSTS, gemeinsame Middleware-Bibliothek
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** Eine gemeinsame Bibliothek statt sieben modul-eigener Copy-Paste-Header-Konfigurationen – dieselbe Konsolidierungslogik wie beim zentralen Rate-Limiting (API-03).
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. CSP ohne unsafe-inline/unsafe-eval als Ausgangspunkt definiert
+2. HSTS mit angemessener max-age gesetzt
+3. Konfiguration ist eine gemeinsame Bibliothek/Middleware, kein Copy-Paste pro Modul
+
+## 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 Header-Scan gegen alle Modul-Frontends bestätigt vollständige Header-Abdeckung
+2. CSP-Verstoß (absichtlicher Test mit Inline-Script) wird blockiert
+3. HSTS-Header bei erneutem Aufruf über HTTP erzwingt HTTPS-Redirect
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Die Einbindung der Middleware in jedes einzelne Modul-Frontend (das übernimmt jedes Modul-Board für sein eigenes Frontend).
+
+## 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: `API-08: security-header-baseline-fuer-alle-frontends`
+- Branch: `feature/api-08-security-header-baseline-fuer-alle-frontends`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-09.md

@@ -0,0 +1,63 @@
+# API-09 – mTLS zwischen Modul-Instanzen (verteilte Installation)
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Gegenseitige TLS-Authentifizierung zwischen Core/DMS/Mail/Archive/Workflow/AI/Connect-Instanzen für Stufe-2/3-Installationen (siehe SKALIERUNGSKONZEPT.md), damit Modul-zu-Modul-Kommunikation nicht nur durch Service-Credentials (API-02) sondern auch transportverschlüsselt und gegenseitig authentifiziert ist. Für Stufe-1-Einzel-LXC optional/nicht zwingend (lokale Kommunikation).
+
+**Technische Grundlage:** mTLS, X.509-Zertifikate, Zertifikatsrotation
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+
+**Für genau diese Kachel:** mTLS schützt die Vertraulichkeit des Transportwegs zwischen Modulen, dort wo asymmetrische JWT-Signatur (API-05) und Service-Credential (API-02) nur Authentizität/Integrität, aber nicht Vertraulichkeit absichern – relevant sobald Module bei Stufe 2/3 auf getrennten Hosts laufen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Zertifikatsverteilung für Modul-Instanzen dokumentiert und automatisierbar
+2. Verbindung ohne gültiges Client-Zertifikat wird abgelehnt
+3. Zertifikatsrotation ohne Ausfallzeit 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. Verbindungsversuch mit ungültigem/fehlendem Zertifikat wird abgelehnt
+2. Rotation im Testbetrieb ohne Verbindungsabbruch durchgeführt
+3. Stufe-1-Betrieb funktioniert weiterhin ohne mTLS-Zwang
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Service-Credential-Ausstellung selbst (`API-02`)
+- Skalierungsstufen-Definition (`SKALIERUNGSKONZEPT.md`)
+
+## 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: `API-09: mtls-zwischen-modul-instanzen-verteilte-installation`
+- Branch: `feature/api-09-mtls-zwischen-modul-instanzen-verteilte-installation`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-10.md

@@ -0,0 +1,69 @@
+# API-10 – Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung)
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 4 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zweistufige Schlüsselhierarchie für die Envelope-Encryption, die DMS (FDN-09) und Mail (ARC-02) verwenden: EIN Master-Key (Root-KEK, KMS-fähig) verwaltet in Core, der ausschließlich Tenant-Schlüssel (Tenant-KEK) verpackt – nicht Objekte direkt. Jeder Tenant bekommt bei seiner Provisionierung (`TEN-01`) einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry abgelegt. DMS/Mail beziehen für ihre pro-Objekt-DEKs ausschließlich den entschlüsselten Tenant-KEK ihres jeweiligen Mandanten (nie den Master-Key direkt), authentifiziert über das Service-Credential aus `API-02`.
+
+**Technische Grundlage:** KMS-Anbindung, Umgebungsvariable/Secret-Provider, zweistufiges Envelope-Encryption-Schema (Master-KEK → Tenant-KEK → Objekt-DEK), Rotationsschnittstelle je Ebene
+
+## Produkt-DNA für diesen Bereich
+> Eine schmale, versionierte Kern-API, die Module registriert statt sie hart zu verdrahten.
+
+**Übernehmen:**
+- Zitadel: Klar versionierte, dokumentierte API als primäre Schnittstelle, auf der auch die eigene Oberfläche aufsetzt.
+- Unleash: Registry-Gedanke – Konsumenten registrieren sich und fragen ihren aktuellen Zustand ab.
+- Casbin: Zentrale Durchsetzungsschicht (Middleware) statt Prüfungen verstreut in Handlern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-REST-API historisch gewachsen, inkonsistent versioniert.: API-Versionierung von Anfang an im URL-Pfad, mit OpenAPI-Beschreibung.
+- Allgemein verbreitetes Muster – Rate-Limiting pro Prozess/In-Memory bei Mehrinstanzbetrieb.: Rate-Limit-State von Anfang an extern/shared (z. B. Postgres-basiert) auslegen.
+- Ein einzelner globaler Master-Key für alle Mandanten (ursprüngliche Fassung dieser Kachel).: Kompromittiert ein Tenant-KEK (z. B. durch ein fehlerhaftes Modul-Log oder einen kompromittierten Service-Credential-Aufruf), betrifft das strukturell nur diesen EINEN Mandanten – konsequente Fortsetzung der physischen Modell-C-Isolation (siehe TEN-01) auch auf Schlüsselebene, statt eines gemeinsamen Blast-Radius für alle Mandanten.
+
+**Für genau diese Kachel:** Nur die Schlüssel-HIERARCHIE (Master-KEK, Tenant-KEK) wird zentral verwaltet, die eigentliche Objekt-Verschlüsselung (DEK pro Objekt) bleibt modul-lokal – Core liefert die gemeinsame, tenant-isolierte Vertrauensbasis, ohne DMS/Mail ihre Envelope-Encryption-Logik wegzunehmen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry, in der der verschlüsselte Tenant-KEK bei der Mandanten-Provisionierung abgelegt wird.
+- `API-02` Modul-Registry & Aktivierungsprüfung – liefert das Service-Credential, mit dem DMS/Mail ihren Tenant-KEK bei Core anfragen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Master-Key ausschließlich über Umgebungsvariable/Secret-Provider, nie im Code oder in der Datenbank im Klartext
+2. Jeder Tenant erhält bei Provisionierung einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry gespeichert – niemals ein gemeinsamer Schlüssel für mehrere Mandanten
+3. Rotation ist auf beiden Ebenen unabhängig möglich, ohne Neuverschlüsselung der Objektdaten: Master-Key-Rotation verpackt nur alle Tenant-KEKs neu; Tenant-KEK-Rotation verpackt nur die DEKs dieses einen Mandanten neu und berührt keinen anderen Tenant
+4. DMS und Mail beziehen den Tenant-KEK über denselben Mechanismus (Service-Credential-authentifizierter Core-Aufruf), keine parallele Implementierung
+
+## 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. Master-Key-Rotation getestet: alle Tenant-KEKs weiterhin entschlüsselbar, kein Objekt in DMS/Mail neu verschlüsselt
+2. Tenant-KEK-Rotation für einen Mandanten getestet: nur dessen DEKs werden neu verpackt, ein zweiter Mandant bleibt davon nachweislich unberührt
+3. Zugriff auf einen Tenant-KEK ohne gültiges Service-Credential (API-02) oder mit dem Credential eines FREMDEN Mandanten wird abgelehnt
+
+## Bekannte Fehler vermeiden
+DMS FDN-09 und Mail ARC-02 haben unabhängig voneinander AES-256-GCM-Verschlüsselung geplant, jeweils mit eigener Schlüsselverwaltung – das ist ein Duplikat im sicherheitskritischsten Bereich des Projekts. Diese Kachel liefert die gemeinsame Schlüsselhierarchie, DMS/Mail referenzieren sie extern statt eigene Schlüsselverwaltung zu bauen. Ein einzelner globaler Master-Key (frühere Fassung dieser Kachel) hätte zudem einen gemeinsamen Blast-Radius für alle Mandanten geschaffen – widerspricht der in TEN-01 explizit begründeten physischen Mandantentrennung (Modell C), wenn die Schlüsselebene diese Isolation nicht mitzieht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- DEK-Erzeugung und Envelope-Verschlüsselung pro Objekt (bleibt modul-lokal in DMS `FDN-09` und Mail `ARC-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: `API-10: master-key-verwaltung-tenant-schluesselhierarchie-kms-anbindung`
+- Branch: `feature/api-10-master-key-verwaltung-tenant-schluesselhierarchie-kms-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.

core-kanban/tickets/API-11.md

@@ -0,0 +1,59 @@
+# API-11 – Master-Key-Rotation & Zugriffs-Audit
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+API-10 etabliert die zweistufige Schlüsselhierarchie (Master-KEK → Tenant-KEK → Objekt-DEK), definiert aber keinen erzwungenen Rotationsprozess und kein dediziertes Audit-Ereignis für Zugriffe auf den Master-Key selbst. Eine Kompromittierung des Master-Keys hebelt die gesamte Hierarchie aus. Rotationsschnittstelle für Master-KEK und Tenant-KEKs ergänzen (Re-Envelope bestehender Tenant-KEKs bei Master-Key-Rotation, ohne Objekt-DEKs neu verschlüsseln zu müssen), sowie jeden Zugriff auf den Master-Key (Entschlüsselung eines Tenant-KEK) als eigenen, hochprivilegierten Audit-Event protokollieren.
+
+**Technische Grundlage:** KMS-Anbindung, Rotationsschnittstelle, AUD-01-Kopplung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Vollständiger Event-Trail zu jeder sicherheitskritischen Operation.
+
+**Bewusst vermeiden:**
+- Keycloak – Schlüsselrotation historisch manuell und schlecht dokumentiert.: Rotation als versionierte, automatisierbare API-Operation, nicht als manueller Eingriff.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: API-10, AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Master-KEK-Rotation re-verschlüsselt alle Tenant-KEKs auf den neuen Master-Key, ohne Objekt-DEKs anzufassen
+2. Jede Entschlüsselung eines Tenant-KEK durch den Master-Key erzeugt einen eigenen Audit-Event-Typ, sichtbar von normalen Audit-Events getrennt
+3. Rotationsintervall ist konfigurierbar und wird bei Überschreitung als Warnung im OPS-Monitoring 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. Rotationstest: Master-Key rotieren, prüfen dass alle Tenant-KEKs weiterhin entschlüsselbar sind und Objekt-DEKs unverändert bleiben
+2. Prüft, dass jeder Tenant-KEK-Zugriff einen Audit-Event mit Akteur (Service-Credential), Zeitpunkt und betroffenem Tenant erzeugt
+3. Prüft Alarmierung bei überschrittenem Rotationsintervall
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): API-10 beschreibt das Verschlüsselungsmodell, aber weder Rotationszwang noch separates Alarming bei Master-Key-Zugriff – ohne diese Kachel bleibt eine Master-Key-Kompromittierung unbemerkt und dauerhaft.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-10` Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung)
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `API-11: master-key-rotation-zugriffs-audit`
+- Branch: `feature/api-11-master-key-rotation-zugriffs-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.

core-kanban/tickets/API-13.md

@@ -0,0 +1,59 @@
+# API-13 – Master-Key-Rotation & Zugriffs-Audit
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+API-10 etabliert die zweistufige Schlüsselhierarchie (Master-KEK → Tenant-KEK → Objekt-DEK), definiert aber keinen erzwungenen Rotationsprozess und kein dediziertes Audit-Ereignis für Zugriffe auf den Master-Key selbst. Eine Kompromittierung des Master-Keys hebelt die gesamte Hierarchie aus. Rotationsschnittstelle für Master-KEK und Tenant-KEKs ergänzen (Re-Envelope bestehender Tenant-KEKs bei Master-Key-Rotation, ohne Objekt-DEKs neu verschlüsseln zu müssen), sowie jeden Zugriff auf den Master-Key (Entschlüsselung eines Tenant-KEK) als eigenen, hochprivilegierten Audit-Event protokollieren.
+
+**Technische Grundlage:** KMS-Anbindung, Rotationsschnittstelle, AUD-01-Kopplung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Vollständiger Event-Trail zu jeder sicherheitskritischen Operation.
+
+**Bewusst vermeiden:**
+- Keycloak – Schlüsselrotation historisch manuell und schlecht dokumentiert.: Rotation als versionierte, automatisierbare API-Operation, nicht als manueller Eingriff.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: API-10, AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Master-KEK-Rotation re-verschlüsselt alle Tenant-KEKs auf den neuen Master-Key, ohne Objekt-DEKs anzufassen
+2. Jede Entschlüsselung eines Tenant-KEK durch den Master-Key erzeugt einen eigenen Audit-Event-Typ, sichtbar von normalen Audit-Events getrennt
+3. Rotationsintervall ist konfigurierbar und wird bei Überschreitung als Warnung im OPS-Monitoring 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. Rotationstest: Master-Key rotieren, prüfen dass alle Tenant-KEKs weiterhin entschlüsselbar sind und Objekt-DEKs unverändert bleiben
+2. Prüft, dass jeder Tenant-KEK-Zugriff einen Audit-Event mit Akteur (Service-Credential), Zeitpunkt und betroffenem Tenant erzeugt
+3. Prüft Alarmierung bei überschrittenem Rotationsintervall
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): API-10 beschreibt das Verschlüsselungsmodell, aber weder Rotationszwang noch separates Alarming bei Master-Key-Zugriff – ohne diese Kachel bleibt eine Master-Key-Kompromittierung unbemerkt und dauerhaft.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-10` Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung)
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `API-13: master-key-rotation-zugriffs-audit`
+- Branch: `feature/api-13-master-key-rotation-zugriffs-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.

core-kanban/tickets/API-14.md

@@ -0,0 +1,50 @@
+# API-14 – JWKS-Endpunkt im Core-Kontodienst
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Keycloak orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Den in API-05 gebauten JWKS-Endpunkt (`moduletrust.KeyManager.ServeJWKS`) in einem laufenden Core-Dienst ausliefern, damit Module (DMS, Mail, Archive) Modul-JWTs lokal verifizieren können. Bisher ist er in keinem `cmd/` gemountet, der Vertrag aus API-05 ist damit nur auf dem Papier erfüllt.
+
+**Technische Grundlage:** Kontodienst `cmd/account-api` (hält Nutzer und Sitzungen und stellt später Modul-JWTs aus, API-15) mit `GET /auth/module-jwks`, Schlüsselverwaltung `internal/moduletrust`
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt – Ed25519-Schlüsselverwaltung, JWKS-Format, Verifier mit TTL-Cache.
+- `IAM-02` Login/Session/JWT-Grundgerüst – Kontodienst und Sitzungen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `GET /auth/module-jwks` liefert den öffentlichen Schlüsselsatz ohne Authentifizierung, im Format, das der DMS-Verifier (`moduleauth.HTTPKeyFetcher`) liest
+2. Der Schlüsselsatz stammt aus demselben Prozess, der Tokens signiert (Schlüssel und JWKS können nicht auseinanderlaufen); nach einer Rotation enthält die Antwort alte und neue Schlüssel
+3. Route und Port sind im Register (`deploy/ports.tsv`, `deploy/routes.tsv`) konsistent, das Prüfskript bleibt grün
+
+## 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. Ein zweites Modul (Verifier-Simulation) verifiziert ein vom Kontodienst signiertes Token allein über die per HTTP geholte JWKS-Antwort
+2. Rotation im laufenden Dienst: bereits ausgestellte Tokens bleiben gültig, neue Tokens tragen die neue KID, keine Downtime
+3. Antwort enthält keine privaten Schlüsselanteile (Negativtest)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-15` Token-Austausch mit Rollen-Claim
+- Persistente Schlüsselspeicherung über Neustarts und Mehrinstanzbetrieb (Schlüssel liegen bis dahin im Prozessspeicher, Tokens verlieren beim Neustart ihre Gültigkeit)
+
+## 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: `API-14: jwks-endpunkt im core-kontodienst`
+- Branch: `feature/api-14-jwks-endpunkt-im-core-kontodienst`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-15.md

@@ -0,0 +1,53 @@
+# API-15 – Modul-JWT mit Rollen-Claim und Token-Austausch
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Keycloak orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Angemeldeten Nutzern ein kurzlebiges Modul-JWT ausstellen, das Nutzer, Mandant und Rolle trägt. Ohne Rollen-Claim kann ein Modul die Policy-Entscheidung `POST /authorize` (RBAC-06, verlangt eine Rolle) nicht stellen. Bisher stellt kein Core-Dienst Modul-JWTs aus.
+
+**Technische Grundlage:** `internal/moduletrust` (Claims um `role` erweitern, rückwärtskompatibel), neuer Handler `POST /auth/module-token` im Kontodienst mit Sitzungs-Cookie (IAM-02) und Rollenquelle `rbac.Store` (RBAC-01)
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-05` Verteilte JWT-Verifikation – `moduletrust.Issue`/Verifier.
+- `API-14` JWKS-Endpunkt im Core-Kontodienst – Auslieferung der Schlüssel.
+- `IAM-02` Login/Session/JWT-Grundgerüst – Sitzungs-Cookie und Middleware.
+- `RBAC-01` Rollenmodell & Grundrechte – Rollenzuweisung je Mandant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `POST /auth/module-token` verlangt eine gültige, nicht widerrufene Sitzung und liefert ein Ed25519-Token mit `sub`, `tenant`, `role`, `iat`, `exp` (TTL per Umgebungsvariable, Grenzen 5 s bis 1 h, Standard 10 min)
+2. Die Rolle stammt aus der Rollenzuweisung des Nutzers im Mandanten; ohne Zuweisung gilt die Rolle `user`; der Mandant stammt aus der Sitzung, nie aus dem Request
+3. Bestehende Aufrufer und Tokens ohne `role` bleiben gültig (Claim optional), inaktive oder unbekannte Nutzer erhalten kein Token
+
+## 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. Token wird vom DMS-Verifier (`moduleauth`) mit Rolle gelesen; falscher Mandant, abgelaufen und manipuliert werden abgelehnt
+2. Rollenwechsel (user zu tenant_admin) wirkt im nächsten ausgestellten Token, nicht rückwirkend
+3. Ohne Sitzung, mit widerrufener Sitzung und mit abgelaufenem Cookie gibt es 401 und kein Token
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RBAC-09` Rechtekatalog `dms.*`
+- Widerruf ausgestellter Modul-Tokens vor Ablauf (kurze TTL genügt vorerst; IAM-17-Widerruf gilt für Sitzungen)
+- Passwort-Login-Fluss und TOTP (unverändert)
+
+## 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: `API-15: modul-jwt mit rollen-claim und token-austausch`
+- Branch: `feature/api-15-modul-jwt-mit-rollen-claim-und-token-austausch`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-16.md

@@ -0,0 +1,54 @@
+# API-16 – Persistente Modul-Signaturschlüssel und Rotation
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Keycloak orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Die Ed25519-Signaturschlüssel für Modul-JWTs (`internal/moduletrust.KeyManager`) leben bisher nur im Prozessspeicher des Kontodienstes. Nach einem Neustart sind alle ausgestellten Tokens ungültig, und mehrere Instanzen desselben Mandanten haben verschiedene Schlüssel. Die Schlüssel müssen verschlüsselt persistent liegen, von mehreren Instanzen geteilt werden und mit Überlappung rotierbar sein.
+
+**Technische Grundlage:** `internal/moduletrust` (Persistenzschicht hinter dem bestehenden `KeyManager`, Signaturen unverändert), Ablage in der Mandanten-Datenbank des Kontodienstes (Modell C, wie IAM-19), Verschlüsselung mit dem Muster aus API-10 (`kek.EncryptWithTenantKEK`, Schlüssel aus der Umgebung)
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-05` Verteilte JWT-Verifikation – `KeyManager`, Verifier, `StaleCache`.
+- `API-10` Master-Key-Verwaltung und Tenant-Schlüsselhierarchie – AES-256-GCM-Verpackung, Schlüssel aus der Umgebung.
+- `API-14` JWKS-Endpunkt im Core-Kontodienst und `API-15` Modul-JWT mit Rollen-Claim – Auslieferung und Ausstellung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die Signaturschlüssel liegen persistent in der Mandanten-Datenbank, die privaten Schlüssel ausschließlich verschlüsselt; ein Neustart des Kontodienstes ändert weder die aktive KID noch entwertet er ausgestellte Tokens
+2. Mehrere Instanzen desselben Mandanten teilen dieselben Schlüssel; beim gleichzeitigen Start entsteht genau ein Schlüssel, und eine von einer Instanz ausgelöste Rotation wird von den anderen übernommen
+3. Rotation mit Überlappung: ein neuer Schlüssel signiert erst nach einer Aktivierungsverzögerung (Verifier-Caches kennen ihn dann), der alte bleibt in der JWKS, bis alle mit ihm signierten Tokens (TTL plus Toleranz) abgelaufen sind, und wird danach entfernt
+4. Ist der Schlüsselspeicher nicht lesbar oder nicht entschlüsselbar, wird weder ein Token ausgestellt noch die JWKS geliefert (503, fail closed)
+
+## 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. Neustart-Test am echten Kontodienst: Token vor dem Neustart bleibt gültig, die JWKS liefert dieselbe KID
+2. Rotationstest: Token mit altem KID gültig bis Ablauf, neue Tokens mit neuem KID, danach fehlt der alte Schlüssel in der JWKS
+3. Zwei Kontodienst-Instanzen gegen dieselbe Datenbank: ein Token der einen wird von der JWKS der anderen verifiziert; Ausfall der Datenbank ergibt 503 statt Token
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Widerruf ausgestellter Modul-Tokens vor Ablauf
+- Schlüsselverwaltung über ein KMS oder Hardware-Sicherheitsmodul
+- Rotation des Verschlüsselungsschlüssels der privaten Schlüssel (Neuverpackung)
+- Oberfläche zur Rotation (hier nur automatische Rotation nach Alter und ein Kommandozeilenaufruf)
+
+## 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: `API-16: persistente modul-signaturschlüssel und rotation`
+- Branch: `feature/api-16-persistente-modul-signaturschluessel`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-17.md

@@ -0,0 +1,60 @@
+# API-17 – Gehärtete HTTP-Server: Timeouts und Body-Limits in allen Diensten
+
+**Epic:** 🔌 API & Integration  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Alle Dienste rufen `http.ListenAndServe` ohne Timeouts auf, und Core und Archive begrenzen Request-Bodies nicht (Befund F-05). Ein gemeinsames Hilfspaket setzt Header-, Lese-, Schreib- und Leerlauf-Timeouts sowie ein Body-Limit; Dienste mit großen Uploads und Downloads (dms-app) erhalten nur Header- und Leerlauf-Timeout.
+
+**Technische Grundlage:** `internal/httpharden` (dieselbe Datei in `archive/internal/httpharden` und `dms/internal/httpharden`, weil die Module getrennte go.mod-Dateien haben)
+
+## Produkt-DNA für diesen Bereich
+> Interne Endpunkte sind nie „nur intern“: ohne Authentifizierung, Grenzen und Zeitlimits ist jeder erreichbare Port eine Angriffsfläche.
+
+**Übernehmen:**
+- Konfigurierbarkeit per Umgebung (`NEXARCH_HTTP_*`), Standardwerte sicher.
+
+**Bewusst vermeiden:**
+- Keine globalen Zeitlimits, die Uploads oder Downloads abbrechen.
+- Keine Body-Limits nur an einzelnen Handlern.
+
+## 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-05 (hoch).
+- `API-01` Grundgerüst und `API-03` Rate-Limiting (mandantenbezogen, ergänzt aber keine Verbindungslimits).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Dienste außer Test-Fixtures nutzen `httpharden`; `ReadHeaderTimeout`, `ReadTimeout`, `WriteTimeout`, `IdleTimeout` und `MaxHeaderBytes` sind gesetzt und per Umgebung überschreibbar (ungültige Werte brechen den Start ab)
+2. Ein Body über dem Limit (Standard 1 MiB) wird mit 413 abgewiesen (Content-Length) bzw. beim Lesen abgebrochen (Chunked); `dms-app` ist von der globalen Body-Grenze und den Lese-/Schreib-Gesamtzeiten ausgenommen
+3. Ein Slowloris-artiger Client mit unvollständigen Headern wird nach dem Header-Timeout 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. Tests für Limit, Chunked, Umgebungsüberschreibung und Slowloris
+2. Build und Vet aller Module (Core, Archive mit Go 1.22, DMS) auf dem Entwicklungshost
+3. Ende-zu-Ende Core→DMS und DMS-Gesamtsystem-Smoke bleiben grün (Upload und Download nicht durch Timeouts beeinträchtigt)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Body-Limits je Handler im DMS (bestehen dort)
+- Gemeinsamer HTTP-Client mit Timeout (F-11)
+
+## 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: `API-17: gehaertete http-server in allen diensten`
+- Branch: `feature/qa-15-phase2a-sicherheitsbehebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-18.md

@@ -0,0 +1,61 @@
+# API-18 – Modul-JWT mit Zielmodul und Aussteller
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Das Modul-JWT (API-15) trägt nur `sub`, `tenant`, `role` und `exp`; jedes Modul, das dieselbe JWKS nutzt, akzeptiert das Token eines anderen Moduls (Befund F-07). Der Kontodienst stellt Tokens mit `aud` (Zielmodul) und `iss` (Aussteller) aus, und die Module prüfen beides.
+
+**Technische Grundlage:** `internal/moduletrust` (`IssueScoped`, `VerifyScoped`), `internal/moduletoken` (Parameter `module`, `NEXARCH_ACCOUNT_MODULE_AUDIENCES`, `NEXARCH_ACCOUNT_MODULE_TOKEN_ISSUER`), `dms/internal/moduleauth` (`Expect`, `NEXARCH_DMS_APP_JWT_AUDIENCE`, `_ISSUER`, `_AUDIENCE_ENFORCE`)
+
+## Produkt-DNA für diesen Bereich
+> Ein Token gilt genau für das Modul, für das es ausgestellt wurde.
+
+**Übernehmen:**
+- EdDSA-Modul-JWT mit JWKS aus API-05, API-14 und API-16.
+
+**Bewusst vermeiden:**
+- Kein Token, das in jedem Modul mit derselben JWKS gilt.
+- Kein stilles Ausrollen: Übergangsschalter mit Warnlog, danach streng.
+
+## 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-07 (mittel).
+- `API-15` Modul-Token, `API-16` persistente Schlüssel, `INT-01` DMS-Verifier.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Der Kontodienst stellt Tokens mit `aud` und `iss` aus; ohne `module`-Parameter gilt das einzige konfigurierte Modul, bei mehreren ist der Parameter Pflicht, unbekannte Module ergeben 400
+2. Das DMS weist Tokens mit fremdem oder fehlendem `aud` und fremdem `iss` ab (Standard streng); `aud` als String oder Liste wird gelesen
+3. Ein Übergangsschalter nimmt im Ausrollfenster noch Tokens ohne `aud` an, nie aber Tokens mit fremdem `aud`
+
+## 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. Cross-Modul-Negativtest: ein Token für Modul A wird von Modul B abgelehnt (Kontodienst- und Verifier-Tests)
+2. Ende-zu-Ende Core→DMS (`scripts/e2e-core-dms.sh`) und Token-Modus-Smoke (`scripts/gesamt-token-smoke.sh`) bleiben grün
+3. Reihenfolge beim Ausrollen (Kontodienst zuerst, dann DMS) ist dokumentiert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Archive- und Mail-Verifier (existieren noch nicht)
+- Widerruf ausgestellter Modul-Tokens
+
+## 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: umgesetzt in Branch `feature/qa-15-phase2b-sicherheitsbehebung` (PR gegen `integration/gesamtprojekt`), Protokoll `docs/QA-15-PHASE2B-PRUEFPROTOKOLL.md`
+- Commit-Nachricht: `API-18: aud und iss im modul-jwt`
+- Branch: `feature/qa-15-phase2b-sicherheitsbehebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-19.md

@@ -0,0 +1,59 @@
+# API-19 – Ausgehende HTTP-Aufrufe mit Zeitlimit und ohne Weiterleitung
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentag  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Dienstaufrufe zwischen den Modulen laufen mit `http.DefaultClient` ohne Zeitlimit; ein hängender Nachbardienst blockiert Löschläufe, Schlüsselbezug und Rückrufe, und ein Service-Token würde einer Weiterleitung folgen (Befund F-11). Jedes Modul erhält ein kleines Paket `internal/httpclient` mit Zeitlimit (15 s) und ohne Weiterleitungen, ein Architekturtest verbietet den Standard-Client im Produktivcode.
+
+**Technische Grundlage:** `dms/internal/httpclient`, `archive/internal/httpclient`, `mail/internal/httpclient` (getrennte Module, daher je eine Kopie); Aufrufer: `retentionclient`, `kekprovider`, `usagereport`, `rbacclient`, `tenantregistryclient`, `notifyclient`, `auditclient`, `kekclient`, `syncalert`
+
+## Produkt-DNA für diesen Bereich
+> Kein Dienst wartet unbegrenzt auf einen anderen.
+
+**Übernehmen:**
+- Bestehende Injektion eines eigenen Clients in Konstruktoren bleibt möglich.
+
+**Bewusst vermeiden:**
+- Keine globalen Zeitlimits am Server, die Uploads oder Downloads abbrechen (API-17).
+
+## 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-11 (mittel).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Im Produktivcode von DMS, Archive und Mail gibt es keinen Aufruf über `http.DefaultClient`, `http.Get`, `http.Post`, `http.Head` oder `http.PostForm` (Architekturtest je Modul)
+2. Der gemeinsame Client bricht einen Aufruf nach dem Zeitlimit ab und folgt keiner Weiterleitung (3xx wird zurückgegeben)
+3. Die betroffenen Aufrufer verhalten sich sonst unverändert (bestehende Tests grün)
+
+## 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 hängendem Server (Zeitlimit greift) und mit Weiterleitung (Ziel wird nicht aufgerufen)
+2. Architekturtest je Modul grün, Build, Vet und Tests der betroffenen Pakete auf dem Entwicklungshost
+3. Core-eigene Aufrufer (`internal/*`) sind geprüft und in einem Folgeticket erfasst, falls sie den Standard-Client nutzen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Wiederholungen und Circuit Breaker
+- Core-Root-Modul (eigene Prü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
+- Status: umgesetzt in Branch `feature/qa-15-phase2b-sicherheitsbehebung` (PR gegen `integration/gesamtprojekt`), Protokoll `docs/QA-15-PHASE2B-PRUEFPROTOKOLL.md`
+- Commit-Nachricht: `API-19: http-client mit zeitlimit fuer ausgehende dienstaufrufe`
+- Branch: `feature/qa-15-phase2b-sicherheitsbehebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-20.md

@@ -0,0 +1,59 @@
+# API-20 – Einheitliche Fehlerantworten mit Korrelations-ID
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+116 Antworten in Core (19), DMS (83), Archive (13) und Mail (1) betten `err.Error()` ein, darunter 500er mit Datenbank- und Dateipfad-Texten (Befund F-14). Handler geben eine allgemeine Meldung mit Korrelations-ID zurück, Details gehen ins Log.
+
+**Technische Grundlage:** DMS: `apierror`-Paket (INT-01) als Vorbild; je Modul ein Hilfspaket
+
+## Produkt-DNA für diesen Bereich
+> Der Aufrufer sieht, dass etwas schiefging, aber nicht, wie das System innen aussieht.
+
+**Übernehmen:**
+- Fehlerformat `{"error":{"code","message"}}` aus API-01/INT-01.
+
+**Bewusst vermeiden:**
+- Keine Datenbank- oder Pfadtexte in Antworten.
+
+## 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-14 (mittel).
+- `API-01`, `INT-01`.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle 5xx-Antworten tragen nur eine allgemeine Meldung und eine Korrelations-ID; das Log enthält die Details mit derselben ID
+2. Fachliche 4xx-Meldungen bleiben verständlich, enthalten aber keine Interna
+3. Ein Architekturtest verbietet `err.Error()` in Antworttexten
+
+## 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. Stichproben je Modul und Architekturtest
+2. Bestehende Tests angepasst
+3. Ende-zu-Ende-Smoke grün
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Übersetzung der Meldungen
+
+## 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: 116 Stellen in vier Modulen, große mechanische Änderung; sinnvoll nach Abschluss der parallelen Phase-2a-Änderungen
+- Commit-Nachricht: `API-20: einheitliche fehlerantworten mit korrelations-id`
+- Branch: `feature/api-20-fehlerantworten-korrelations-id`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-21.md

@@ -0,0 +1,59 @@
+# API-21 – Architekturtest gegen Fehlertext-Leck in HTTP-Antworten
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentag  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+API-20 hat das Fehlertext-Leck (Befund F-14) am äußersten Rand geschlossen (`apierror.Normalize` in `httpharden.ListenAndServe`/`ListenAndServeStreaming`), aber bewusst keinen statischen Test gebaut, der garantiert, dass künftiger Code das nicht umgeht — Akzeptanzkriterium 3 aus API-20 blieb offen. Ein Architekturtest soll zwei Dinge dauerhaft erzwingen: kein `err.Error()`-Ergebnis wird direkt in eine HTTP-Antwort geschrieben, und jeder HTTP-Dienst läuft über `httpharden`.
+
+**Technische Grundlage:** `internal/apierror`, `internal/httpharden` (Core und Archive je eigenes Modul)
+
+## Produkt-DNA für diesen Bereich
+> Eine Laufzeit-Absicherung ohne Wächter im Code verfällt beim nächsten Refactor.
+
+**Übernehmen:**
+- Architekturtests wie beim DMS-Guard-Test (INT-15): Code, nicht Dokumentation, erzwingt die Regel.
+
+**Bewusst vermeiden:**
+- Keine Ausnahme ohne begründeten, benannten Eintrag in einer Ausnahmeliste.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-20` Einheitliche Fehlerantworten mit Korrelations-ID – Laufzeit-Normalisierung über `apierror.Normalize`, `docs/QA-15-PHASE2C-PRUEFPROTOKOLL.md`.
+- `QA-15` Sicherheitsprüfung Gesamtprojekt – Befundbericht `docs/SICHERHEITSPRUEFUNG-GESAMTPROJEKT.md`, hier: F-14 (mittel), AC3 aus API-20.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ein automatisierter Test verbietet `err.Error()` (bzw. Ausdrücke, die erkennbar einen Fehlertext liefern) direkt in einer HTTP-Antwort, außer über die zentrale `apierror`-Normalisierung
+2. Ein automatisierter Test verbietet einen neuen `http.Server`/`http.ListenAndServe`-Aufruf außerhalb von `httpharden`
+3. Beide Tests laufen im normalen `go test ./...` mit und scheitern mit einer klaren Fundstelle (Datei:Zeile)
+
+## 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. Absichtlich eingefügter Verstoß bringt den Test nachweislich zum Scheitern, danach entfernt
+2. Bestehender Code (Core und Archive) besteht den Test ohne Änderung außer dokumentierten Ausnahmen
+3. Ende-zu-Ende-Smoke bleibt grün
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Rückwirkende Reparatur weiterer Fehlerantworten (das hat API-20 bereits erledigt)
+- Mail- und DMS-Modul (DMS hat mit INT-01/INT-15 bereits ein eigenes, etabliertes Muster; Mail hatte nur einen unangetasteten Testfixture-Fund ohne Leck)
+
+## 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: `API-21: architekturtest gegen fehlertext-leck in http-antworten`
+- Branch: `feature/api-21-architekturtest-fehlertext-leck`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-22.md

@@ -0,0 +1,37 @@
+# API-22 – Modul-Endpunkt-Discovery
+
+**Epic:** 🔌 API-Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring).
+Serverseitige Logik, Datenzugriff und Schnittstelle.
+
+## Auftrag
+Aus INT-21 (native Android-App) entstand ein echter Bedarf: ein Client, der nur eine Server-Grundadresse kennt, muss die tatsächlichen Endpunkt-Adressen der einzelnen Module (account-api, dms-app, etc.) ermitteln können. Bisher gibt es dafür nichts — `internal/moduleregistry` liefert nur Zugangsdaten, `web/portal` (SHL-02) nutzt eine statische, von Hand gepflegte JSON-Konfiguration. Beides skaliert nicht für native/externe Clients, die keinen Zugriff auf die Server-Konfiguration haben.
+
+**Technische Grundlage:** Core-HTTP-API, wahrscheinlich ein `GET /.well-known/nexarch-modules` oder ähnlicher, unauthentifizierter oder minimal-authentifizierter Discovery-Endpunkt, der eine Liste bekannter Module mit ihrer tatsächlichen Basis-Adresse zurückgibt.
+
+## Ausgangslage
+Setzt auf der bestehenden Modul-Registrierung auf (prüfen, ob `internal/moduleregistry` oder eine andere bestehende Tabelle schon Adressinformationen je Modul hält, oder ob eine neue, kleine Konfigurationsquelle nötig ist — analog zur `web/portal`-JSON-Konfiguration aus SHL-02, aber serverseitig statt clientseitig gepflegt).
+
+## Akzeptanzkriterien
+1. Ein Client kann mit nur der Server-Grundadresse einen Discovery-Aufruf machen und erhält die tatsächlichen Basis-Adressen aller bekannten Module zurück
+2. Neue Module lassen sich über Konfiguration ergänzen, ohne den Discovery-Code selbst zu ändern
+3. Der Endpunkt gibt keine sicherheitsrelevanten Details preis (keine Zugangsdaten, keine internen Pfade, die nicht für Clients gedacht sind)
+
+## Prüfungen vor der Abnahme
+1. Discovery-Aufruf liefert für ein bekanntes Modul die korrekte, tatsächlich erreichbare Adresse
+2. Neues Test-Modul nur über Konfiguration ergänzt, erscheint korrekt im Discovery-Ergebnis
+3. Kein sicherheitsrelevanter Wert im Antwort-Payload (Test gegen eine Positivliste erlaubter Felder)
+
+## Nicht Bestandteil dieser Kachel
+- Änderungen an INT-21 (Android-App) selbst — die App nutzt vorerst weiter zwei manuell eingegebene Felder, dieses Ticket liefert nur die serverseitige Grundlage für eine spätere Umstellung
+- Änderungen an `web/portal` (SHL-02) — bleibt vorerst bei seiner statischen Konfiguration, könnte später auf diesen Discovery-Endpunkt umgestellt werden
+
+## Abschluss
+- Commit-Nachricht: `API-22: modul endpunkt discovery`
+- Branch: `feature/api-22-modul-endpunkt-discovery`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/API-23.md

@@ -0,0 +1,44 @@
+# API-23 – HTTP-Client mit Zeitlimit im Core-Root-Modul (Nachtrag zu F-11/API-19)
+
+**Epic:** 🔌 Core-API & Modulverwaltung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentag  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core.
+
+## Auftrag
+API-19 (QA-15-Befund F-11) hat `dms/internal/httpclient`, `archive/internal/httpclient` und `mail/internal/httpclient` eingeführt (Zeitlimit 15s, keine Weiterleitungen) und alle Aufrufer dieser drei Module umgestellt. Bei der Verifikation wurde festgestellt: das Core-Root-Modul selbst wurde dabei nicht erfasst — `internal/statuspage/statuspage.go` und `internal/moduletrust/fetch.go` nutzen weiterhin `http.DefaultClient`/ein ungebundenes `http.Client{}`. Analoge Lösung im Core-Modul nachziehen.
+
+**Technische Grundlage:** `internal/httpclient` (neu, Core-Modul), gleiche Eigenschaften wie die drei Modul-Kopien: 15s Zeitlimit, keine Weiterleitungen. Architekturtest analog zu `TestNoUnboundedDefaultClientInProductionCode`.
+
+## Ausgangslage
+- `API-19` (fertig, gemergt) — Referenzmuster in `dms/internal/httpclient`, `archive/internal/httpclient`, `mail/internal/httpclient`.
+- Betroffene Aufrufer im Core-Root-Modul: `internal/statuspage/statuspage.go`, `internal/moduletrust/fetch.go` (bei Bedarf weitere prüfen: `grep -rl "http.DefaultClient\|http.Client{}" --include=*.go internal/ cmd/` im Core-Root-Modul, `_test.go` ausgenommen).
+
+## Akzeptanzkriterien
+1. Core-Root-Modul hat ein eigenes `internal/httpclient`-Paket (15s Zeitlimit, keine Weiterleitungen), analog zu den drei bestehenden Modul-Kopien
+2. `internal/statuspage` und `internal/moduletrust/fetch.go` nutzen dieses Paket statt `http.DefaultClient`/ungebundenem `http.Client{}`
+3. Ein Architekturtest verbietet den ungebundenen Standard-Client im Produktivcode des Core-Root-Moduls (analog zu den drei bestehenden Tests)
+
+## Prüfungen vor der Abnahme
+1. Hängender Testserver: Aufruf über `internal/statuspage`/`internal/moduletrust` bricht nach ~15s ab statt unbegrenzt zu warten
+2. Testserver mit Weiterleitung: Aufruf folgt der Weiterleitung nicht
+3. Architekturtest schlägt fehl, wenn `http.DefaultClient`/`http.Client{}` wieder eingeführt wird (echt provoziert, nicht nur behauptet)
+
+## Nicht Bestandteil dieser Kachel
+- Erneute Änderung an dms/archive/mail (dort bereits durch API-19 erledigt)
+
+## Arbeitsweise
+1. Lies zuerst `dms/internal/httpclient` als Referenzmuster.
+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: `API-23: http-client mit zeitlimit im core-root-modul`
+- Branch: `feature/api-23-http-client-zeitlimit-core-root`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-01.md

@@ -0,0 +1,63 @@
+# AUD-01 – Zentrales Audit-Log-Modell
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.
+
+**Technische Grundlage:** PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+> Ein Protokoll, dem man vertraut, weil es sich nicht verändern lässt.
+
+**Übernehmen:**
+- archivdms (positives Muster): Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich bei sicherheitsrelevanten Entscheidungen.
+- Zitadel: Vollständiger Event-Trail zu jeder Identitäts-/Rechteänderung als Vorbild für Nachvollziehbarkeit.
+- Casbin: Jede Policy-Entscheidung ist protokollierbar und im Nachhinein erklärbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/abschaltbar und laufen leicht ins Leere, wenn niemand die Aufbewahrung prüft.: Audit-Log verpflichtend und append-only, nicht optional.
+- Allgemein verbreitetes Muster – Audit-Log als Nebenprodukt allgemeiner Logging-Frameworks statt eigenes Datenmodell.: Eigenes, unveränderliches Audit-Datenmodell getrennt vom allgemeinen Anwendungs-Log.
+
+**Für genau diese Kachel:** Eigenes Audit-Datenmodell als Grundlage für Nachvollziehbarkeit, angelehnt an Zitadels vollständigen Event-Trail.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Audit-Ereignisse werden strukturiert (Akteur, Aktion, Zielobjekt, Zeitpunkt, Tenant) persistiert
+2. Audit-Log ist vom allgemeinen Anwendungs-Log technisch und organisatorisch getrennt
+3. Schreibpfad für Audit-Einträge ist zentral (eine Schreibfunktion), nicht verstreut über Handler
+
+## 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 belegt: ein sicherheitsrelevanter Vorgang erzeugt zuverlässig genau einen Audit-Eintrag
+2. Fehlender Tenant-Bezug in einem Audit-Eintrag wird durch Constraint/Test verhindert
+3. Datenmodell von zweiter Person gegen die Dokumentation geprüft
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `AUD-02` Unveränderliches Protokoll (Append-only)
+- `AUD-03` Audit-Log-Export & Filter-API
+
+## 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: `AUD-01: zentrales-audit-log-modell`
+- Branch: `feature/aud-01-zentrales-audit-log-modell`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-02.md

@@ -0,0 +1,66 @@
+# AUD-02 – Unveränderliches Protokoll (Append-only)
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Audit-Log technisch gegen nachträgliche Änderung und Löschung absichern (append-only), inklusive Vier-Augen-Prinzip für sicherheitskritische Entscheidungen im Umfeld des Audit-Logs.
+
+**Technische Grundlage:** PostgreSQL (Trigger/Constraints), Go
+
+## Produkt-DNA für diesen Bereich
+> Ein Protokoll, dem man vertraut, weil es sich nicht verändern lässt.
+
+**Übernehmen:**
+- archivdms (positives Muster): Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich bei sicherheitsrelevanten Entscheidungen.
+- Zitadel: Vollständiger Event-Trail zu jeder Identitäts-/Rechteänderung als Vorbild für Nachvollziehbarkeit.
+- Casbin: Jede Policy-Entscheidung ist protokollierbar und im Nachhinein erklärbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/abschaltbar und laufen leicht ins Leere, wenn niemand die Aufbewahrung prüft.: Audit-Log verpflichtend und append-only, nicht optional.
+- Allgemein verbreitetes Muster – Audit-Log als Nebenprodukt allgemeiner Logging-Frameworks statt eigenes Datenmodell.: Eigenes, unveränderliches Audit-Datenmodell getrennt vom allgemeinen Anwendungs-Log.
+
+**Für genau diese Kachel:** Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich wird 1:1 aus archivdms übernommen – dort bereits sauber gelöst und soll hier als Vorbild dienen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `AUD-01` Zentrales Audit-Log-Modell – Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. UPDATE und DELETE auf Audit-Einträge sind auf Datenbankebene technisch unterbunden
+2. Sicherheitskritische Entscheidungen (z. B. Löschbestätigung, Rechtevergabe) laufen über ein Vier-Augen-Prinzip mit FOR-UPDATE-Lock
+3. Vergleich sicherheitsrelevanter Geheimnisse (Token, Bestätigungscodes) erfolgt timing-safe
+
+## 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. Direkter UPDATE/DELETE-Versuch auf die Audit-Tabelle wird von der Datenbank abgewiesen (automatisierter Test)
+2. Vier-Augen-Prinzip mit FOR-UPDATE-Lock unter parallelen Anfragen race-frei getestet
+3. Timing-safe Vergleich durch Laufzeitmessung stichprobenartig verifiziert
+
+## Bekannte Fehler vermeiden
+
+- **Positives Muster aus archivdms übernehmen (kein Fehler)**: archivdms hatte das Vier-Augen-Prinzip bei Löschbestätigung mit `FOR UPDATE`-Lock und Timing-safe Passwort-/Token-Vergleich bei sicherheitsrelevanten Entscheidungen bereits sauber gelöst. → Dieses Muster explizit als Vorbild für das Append-only-Audit-Log in NEXARCH Core übernehmen.
+
+## 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: `AUD-02: unveraenderliches-protokoll-append-only`
+- Branch: `feature/aud-02-unveraenderliches-protokoll-append-only`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-03.md

@@ -0,0 +1,62 @@
+# AUD-03 – Audit-Log-Export & Filter-API
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+API zum Filtern (Zeitraum, Akteur, Aktion, Tenant) und Exportieren des Audit-Logs für Compliance-Zwecke.
+
+**Technische Grundlage:** REST-API, PostgreSQL, CSV/JSON-Export
+
+## Produkt-DNA für diesen Bereich
+> Ein Protokoll, dem man vertraut, weil es sich nicht verändern lässt.
+
+**Übernehmen:**
+- archivdms (positives Muster): Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich bei sicherheitsrelevanten Entscheidungen.
+- Zitadel: Vollständiger Event-Trail zu jeder Identitäts-/Rechteänderung als Vorbild für Nachvollziehbarkeit.
+- Casbin: Jede Policy-Entscheidung ist protokollierbar und im Nachhinein erklärbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/abschaltbar und laufen leicht ins Leere, wenn niemand die Aufbewahrung prüft.: Audit-Log verpflichtend und append-only, nicht optional.
+- Allgemein verbreitetes Muster – Audit-Log als Nebenprodukt allgemeiner Logging-Frameworks statt eigenes Datenmodell.: Eigenes, unveränderliches Audit-Datenmodell getrennt vom allgemeinen Anwendungs-Log.
+
+**Für genau diese Kachel:** Export-API als schmale, gut dokumentierte Schnittstelle statt eines schwer zu findenden Admin-Reports.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `AUD-01` Zentrales Audit-Log-Modell – Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Filter nach Zeitraum, Akteur, Aktion und Tenant liefern korrekte Teilmengen
+2. Export als CSV und JSON ist für berechtigte Rollen verfügbar
+3. Export ist paginiert/streambar, auch bei großen Datenmengen ohne Speicherüberlauf
+
+## 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. Exportgröße im Test mit hoher Eintragszahl ohne übermäßigen Speicherverbrauch verarbeitet
+2. Filterkombinationen automatisiert gegen erwartete Ergebnismengen getestet
+3. Zugriff auf Export ohne passende Berechtigung wird abgewiesen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `AUD-04` Audit-Log-Ansicht
+
+## 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: `AUD-03: audit-log-export-filter-api`
+- Branch: `feature/aud-03-audit-log-export-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.

core-kanban/tickets/AUD-04.md

@@ -0,0 +1,62 @@
+# AUD-04 – Audit-Log-Ansicht
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Oberfläche zur Durchsuchung und Darstellung des Audit-Logs für berechtigte Administratoren, inklusive Exportfunktion.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Ein Protokoll, dem man vertraut, weil es sich nicht verändern lässt.
+
+**Übernehmen:**
+- archivdms (positives Muster): Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich bei sicherheitsrelevanten Entscheidungen.
+- Zitadel: Vollständiger Event-Trail zu jeder Identitäts-/Rechteänderung als Vorbild für Nachvollziehbarkeit.
+- Casbin: Jede Policy-Entscheidung ist protokollierbar und im Nachhinein erklärbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/abschaltbar und laufen leicht ins Leere, wenn niemand die Aufbewahrung prüft.: Audit-Log verpflichtend und append-only, nicht optional.
+- Allgemein verbreitetes Muster – Audit-Log als Nebenprodukt allgemeiner Logging-Frameworks statt eigenes Datenmodell.: Eigenes, unveränderliches Audit-Datenmodell getrennt vom allgemeinen Anwendungs-Log.
+
+**Für genau diese Kachel:** Audit-Ansicht als reiner Konsument der Export-API, keine eigene Aggregationslogik im Frontend.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `AUD-03` Audit-Log-Export & Filter-API – API zum Filtern (Zeitraum, Akteur, Aktion, Tenant) und Exportieren des Audit-Logs für Compliance-Zwecke.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Audit-Einträge sind mit Filtern nach Zeitraum, Akteur und Aktion durchsuchbar
+2. Export-Funktion aus AUD-03 ist über die Oberfläche auslösbar
+3. Einzelner Audit-Eintrag zeigt alle relevanten Details in einer Detailansicht
+
+## 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. Filterkombinationen in der Oberfläche liefern dieselben Ergebnisse wie direkte API-Aufrufe
+2. Export aus der Oberfläche liefert eine vollständige, ladbare Datei
+3. Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen
+
+## 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: `AUD-04: audit-log-ansicht`
+- Branch: `feature/aud-04-audit-log-ansicht`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-05.md

@@ -0,0 +1,66 @@
+# AUD-05 – Audit-Log-Registrierung bei Archive-Retention-Engine
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Audit-Log-Eintrag als Objekttyp bei der Archive-Retention-Engine registrieren (über den Modul-Adapter aus Archive `RET-05`), Default-Aufbewahrungsfrist von 10 Jahren (GoBD-Buchungsbeleg-Frist) für Audit-Log-Einträge konfigurieren. Core implementiert dafür keine eigene Löschlogik – Fristverwaltung und tatsächliche Löschung/Aufbewahrungssperre laufen vollständig über Archive.
+
+**Technische Grundlage:** Modul-Adapter-Registrierung, GoBD-Frist
+
+## Produkt-DNA für diesen Bereich
+> Ein Protokoll, dem man vertraut, weil es sich nicht verändern lässt.
+
+**Übernehmen:**
+- archivdms (positives Muster): Vier-Augen-Prinzip mit FOR-UPDATE-Lock und Timing-safe Vergleich bei sicherheitsrelevanten Entscheidungen.
+- Zitadel: Vollständiger Event-Trail zu jeder Identitäts-/Rechteänderung als Vorbild für Nachvollziehbarkeit.
+- Casbin: Jede Policy-Entscheidung ist protokollierbar und im Nachhinein erklärbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/abschaltbar und laufen leicht ins Leere, wenn niemand die Aufbewahrung prüft.: Audit-Log verpflichtend und append-only, nicht optional.
+- Allgemein verbreitetes Muster – Audit-Log als Nebenprodukt allgemeiner Logging-Frameworks statt eigenes Datenmodell.: Eigenes, unveränderliches Audit-Datenmodell getrennt vom allgemeinen Anwendungs-Log.
+
+**Für genau diese Kachel:** Audit-Log-Retention folgt derselben zentralen Regel wie alle anderen Objekte in NEXARCH – kein zweites, paralleles Retention-System nur für Audit-Daten.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `AUD-01` Zentrales Audit-Log-Modell – Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.
+- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-01` Generisches Retention-Objektmodell, `RET-02` Aufbewahrungsfristen-Engine, `RET-05` Modul-Adapter-Schnittstelle.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Audit-Log-Eintrag ist bei der Archive-Retention-Engine als Objekttyp registriert
+2. Default-Frist von 10 Jahren ist als Konfiguration hinterlegt, pro Tenant überschreibbar sofern rechtlich zulässig
+3. Core selbst löscht oder sperrt keine Audit-Einträge eigenständig – jede Löschung/Sperre läuft ausschließlich über die Archive-Engine
+
+## 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 bei Archive erfolgreich getestet, Objekttyp taucht in Archive's Retention-Konfiguration auf
+2. Audit-Eintrag mit Frist in der Vergangenheit wird von Archive korrekt als löschfällig markiert, Core greift nicht eigenständig ein
+3. Löschsperre (Legal Hold) aus Archive verhindert Löschung eines Audit-Eintrags trotz abgelaufener Frist
+
+## Bekannte Fehler vermeiden
+Ein zweites, Core-eigenes Retention-System für das Audit-Log würde genau das Duplikat-Problem wiederholen, das bei IAM/Retention/Workflow bereits bewusst vermieden wurde (siehe Konsolidierung DMS→Core/Archive/Workflow) – Core registriert nur, Archive verwaltet die Frist.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `AUD-05: audit-log-registrierung bei archive-retention-engine`
+- Branch: `feature/aud-05-audit-log-registrierung-bei-archive-retention-engine`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-06.md

@@ -0,0 +1,58 @@
+# AUD-06 – Technische Durchsetzung Append-only Audit-Log
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+AUD-01 konzipiert das Audit-Log als append-only, setzt dies aber nur als Konvention um – ein Datenbank-Superuser oder eine kompromittierte Anwendungsrolle könnte Einträge weiterhin ändern oder löschen. Append-only technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE- und DELETE-Rechte auf die Audit-Tabelle vollständig entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch protokolliert und ablehnt.
+
+**Technische Grundlage:** PostgreSQL (REVOKE/Trigger), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/löschbar.: Append-only ist eine Datenbank-Garantie, keine Anwendungs-Konvention.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die vom Core-Prozess verwendete Datenbankrolle kann Audit-Einträge nachweislich weder verändern noch löschen (fehlende Rechte, nicht nur fehlender Code-Pfad)
+2. Ein Versuch, einen Audit-Eintrag zu ändern oder zu löschen, wird von der Datenbank abgelehnt und selbst protokolliert
+3. Bestehende AUD-01-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar
+
+## 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. Testet UPDATE/DELETE gegen die Audit-Tabelle mit der Anwendungsrolle, erwartet Datenbankfehler (Rechteverweigerung)
+2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+3. Regressionstest: normales Schreiben/Lesen von Audit-Einträgen funktioniert weiterhin
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): 'append-only' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes – ein Repudiation-Risiko, falls ein Akteur mit direktem Datenbankzugriff (Fehlkonfiguration, kompromittierte Rolle) Spuren verwischen kann.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `AUD-06: technische-durchsetzung-append-only-audit-log`
+- Branch: `feature/aud-06-technische-durchsetzung-append-only-audit-log`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-07.md

@@ -0,0 +1,58 @@
+# AUD-07 – Technische Durchsetzung Append-only Audit-Log
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+AUD-01 konzipiert das Audit-Log als append-only, setzt dies aber nur als Konvention um – ein Datenbank-Superuser oder eine kompromittierte Anwendungsrolle könnte Einträge weiterhin ändern oder löschen. Append-only technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE- und DELETE-Rechte auf die Audit-Tabelle vollständig entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch protokolliert und ablehnt.
+
+**Technische Grundlage:** PostgreSQL (REVOKE/Trigger), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/löschbar.: Append-only ist eine Datenbank-Garantie, keine Anwendungs-Konvention.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die vom Core-Prozess verwendete Datenbankrolle kann Audit-Einträge nachweislich weder verändern noch löschen (fehlende Rechte, nicht nur fehlender Code-Pfad)
+2. Ein Versuch, einen Audit-Eintrag zu ändern oder zu löschen, wird von der Datenbank abgelehnt und selbst protokolliert
+3. Bestehende AUD-01-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar
+
+## 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. Testet UPDATE/DELETE gegen die Audit-Tabelle mit der Anwendungsrolle, erwartet Datenbankfehler (Rechteverweigerung)
+2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+3. Regressionstest: normales Schreiben/Lesen von Audit-Einträgen funktioniert weiterhin
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): 'append-only' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes – ein Repudiation-Risiko, falls ein Akteur mit direktem Datenbankzugriff (Fehlkonfiguration, kompromittierte Rolle) Spuren verwischen kann.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `AUD-07: technische-durchsetzung-append-only-audit-log`
+- Branch: `feature/aud-07-technische-durchsetzung-append-only-audit-log`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/AUD-08.md

@@ -0,0 +1,59 @@
+# AUD-08 – Audit-Export ohne Admin-Token in der URL
+
+**Epic:** 📜 Audit & Compliance  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentag  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Der Audit-Export erwartet das geteilte Admin-Token als `caller`-Parameter in der URL (Zugriffsprotokolle, Browserverlauf, Proxys), CORS ist `*` (Befund F-09). Das Token wandert in einen Header, die Berechtigung kommt aus der Sitzung, CORS wird auf feste Herkunft begrenzt.
+
+**Technische Grundlage:** `internal/audit/export_handler.go`, `internal/auditadmin/authorize.go`
+
+## Produkt-DNA für diesen Bereich
+> Zugangsdaten stehen nie in einer URL.
+
+**Übernehmen:**
+- Exportformat und Filter (AUD-03).
+
+**Bewusst vermeiden:**
+- Kein Token in Query-Parametern, kein `Access-Control-Allow-Origin: *` an Administrationsendpunkten.
+
+## 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-09 (mittel).
+- `AUD-03` Export, `IAM-02` Sitzungen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Der Export akzeptiert kein Token im Query; Authentifizierung über Sitzung oder Header
+2. CORS erlaubt nur konfigurierte Herkunft
+3. Ein Aufruf mit altem URL-Token wird mit 401 abgewiesen 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. Tests zu Header, Sitzung, CORS und Ablehnung
+2. Zugriffsprotokolle enthalten kein Token
+3. Oberfläche `audit-log` angepasst
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Neue Exportformate
+
+## 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: Endpunkt liegt im Login-/Devserver-Umfeld der Phase 2a; erst nach deren Merge
+- Commit-Nachricht: `AUD-08: audit-export ohne token in der url`
+- Branch: `feature/aud-08-audit-export-ohne-url-token`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/CFG-01.md

@@ -0,0 +1,62 @@
+# CFG-01 – Zentraler Konfigurationsdienst
+
+**Epic:** ⚙️ Zentrale Konfiguration & Benachrichtigungen  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentraler Dienst für globale und tenant-spezifische Konfigurationswerte mit Versionierung und Cache-Invalidierung, von allen Modulen wiederverwendbar.
+
+**Technische Grundlage:** PostgreSQL, In-Prozess-Cache, Go
+
+## Produkt-DNA für diesen Bereich
+> Ein Ort für Konfiguration und Benachrichtigungen, den jedes Modul wiederverwendet statt neu zu bauen.
+
+**Übernehmen:**
+- Unleash: Zentraler Konfigurationsdienst mit Caching und klarer Versionierung von Werten.
+- Zitadel: Mandantenspezifische Einstellungen (Branding, Policies) zentral verwaltet und an alle Module durchgereicht.
+- Prometheus/Grafana: Konfiguration als Code/Datensatz, der beobachtbar und nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Keycloak – Benachrichtigungs-/E-Mail-Konfiguration tief in Realm-Settings vergraben, schwer zentral zu pflegen.: Benachrichtigungs-Konfiguration als eigener, modulübergreifender Dienst.
+- Allgemein verbreitetes Muster – jedes Modul baut seinen eigenen E-Mail-Versand.: Ein zentraler Dispatcher, den alle Module über eine schmale Schnittstelle ansprechen.
+
+**Für genau diese Kachel:** Zentraler Konfigurationsdienst nach Unleash-Vorbild (Caching, Versionierung), aber für generische Konfiguration statt nur Flags.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Konfigurationswerte sind global und pro Tenant überschreibbar mit klarer Vorrangregel
+2. Änderungen an Konfigurationswerten sind versioniert nachvollziehbar
+3. Andere Module lesen Konfiguration ausschließlich über die zentrale Schnittstelle, nicht über eigene Tabellen
+
+## 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. Vorrangregel (Tenant-Override vor Global-Default) automatisiert getestet
+2. Cache-Invalidierung nach Konfigurationsänderung innerhalb dokumentierter Zeit gemessen
+3. Versionierungshistorie eines Werts über mehrere Änderungen hinweg nachvollzogen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `CFG-02` Benachrichtigungs-Dispatcher (Core-Service für Module)
+
+## 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: `CFG-01: zentraler-konfigurationsdienst`
+- Branch: `feature/cfg-01-zentraler-konfigurationsdienst`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/CFG-02.md

@@ -0,0 +1,62 @@
+# CFG-02 – Benachrichtigungs-Dispatcher (Core-Service für Module)
+
+**Epic:** ⚙️ Zentrale Konfiguration & Benachrichtigungen  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentraler Dispatcher, über den beliebige Module Benachrichtigungen auslösen können, mit Warteschlange, Wiederholungslogik und Kanal-Abstraktion.
+
+**Technische Grundlage:** Postgres-Job-Queue, Go, Worker-Goroutinen
+
+## Produkt-DNA für diesen Bereich
+> Ein Ort für Konfiguration und Benachrichtigungen, den jedes Modul wiederverwendet statt neu zu bauen.
+
+**Übernehmen:**
+- Unleash: Zentraler Konfigurationsdienst mit Caching und klarer Versionierung von Werten.
+- Zitadel: Mandantenspezifische Einstellungen (Branding, Policies) zentral verwaltet und an alle Module durchgereicht.
+- Prometheus/Grafana: Konfiguration als Code/Datensatz, der beobachtbar und nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Keycloak – Benachrichtigungs-/E-Mail-Konfiguration tief in Realm-Settings vergraben, schwer zentral zu pflegen.: Benachrichtigungs-Konfiguration als eigener, modulübergreifender Dienst.
+- Allgemein verbreitetes Muster – jedes Modul baut seinen eigenen E-Mail-Versand.: Ein zentraler Dispatcher, den alle Module über eine schmale Schnittstelle ansprechen.
+
+**Für genau diese Kachel:** Ein zentraler Dispatcher statt eigenem E-Mail-Versand je Modul – jedes Modul spricht dieselbe schmale Schnittstelle an.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `CFG-01` Zentraler Konfigurationsdienst – Zentraler Dienst für globale und tenant-spezifische Konfigurationswerte mit Versionierung und Cache-Invalidierung, von allen Modulen wiederverwendbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Module lösen Benachrichtigungen über eine einheitliche, schmale Schnittstelle aus, ohne eigenen Versandcode
+2. Fehlgeschlagene Zustellung wird mit begrenzter Anzahl Wiederholungen erneut versucht
+3. Warteschlange ist Postgres-basiert und übersteht einen Neustart des Dienstes ohne Nachrichtenverlust
+
+## 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. Neustart des Dienstes während offener Zustellungen verliert keine Nachricht (automatisierter Test)
+2. Wiederholungslogik greift bei simuliertem Zustellfehler und bricht nach definierter Anzahl kontrolliert ab
+3. Zwei Module lösen gleichzeitig Benachrichtigungen aus, beide werden korrekt zugestellt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `CFG-03` Benachrichtigungs-Kanäle (E-Mail/In-App)
+
+## 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: `CFG-02: benachrichtigungs-dispatcher-core-service-fuer-module`
+- Branch: `feature/cfg-02-benachrichtigungs-dispatcher-core-service-fuer-module`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/CFG-03.md

@@ -0,0 +1,62 @@
+# CFG-03 – Benachrichtigungs-Kanäle (E-Mail/In-App)
+
+**Epic:** ⚙️ Zentrale Konfiguration & Benachrichtigungen  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Konkrete Zustellkanäle für den Dispatcher: E-Mail-Versand und In-App-Benachrichtigungen, inklusive Vorlagenverwaltung.
+
+**Technische Grundlage:** SMTP, PostgreSQL (In-App-Nachrichten), Go
+
+## Produkt-DNA für diesen Bereich
+> Ein Ort für Konfiguration und Benachrichtigungen, den jedes Modul wiederverwendet statt neu zu bauen.
+
+**Übernehmen:**
+- Unleash: Zentraler Konfigurationsdienst mit Caching und klarer Versionierung von Werten.
+- Zitadel: Mandantenspezifische Einstellungen (Branding, Policies) zentral verwaltet und an alle Module durchgereicht.
+- Prometheus/Grafana: Konfiguration als Code/Datensatz, der beobachtbar und nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Keycloak – Benachrichtigungs-/E-Mail-Konfiguration tief in Realm-Settings vergraben, schwer zentral zu pflegen.: Benachrichtigungs-Konfiguration als eigener, modulübergreifender Dienst.
+- Allgemein verbreitetes Muster – jedes Modul baut seinen eigenen E-Mail-Versand.: Ein zentraler Dispatcher, den alle Module über eine schmale Schnittstelle ansprechen.
+
+**Für genau diese Kachel:** Kanal-Abstraktion nach Unleash-artigem Strategie-Gedanken – neue Kanäle lassen sich ergänzen, ohne den Dispatcher anzufassen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `CFG-02` Benachrichtigungs-Dispatcher (Core-Service für Module) – Zentraler Dispatcher, über den beliebige Module Benachrichtigungen auslösen können, mit Warteschlange, Wiederholungslogik und Kanal-Abstraktion.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. E-Mail-Versand funktioniert über konfigurierbaren SMTP-Server mit Vorlagen
+2. In-App-Benachrichtigungen werden persistiert und sind über API abrufbar/als gelesen markierbar
+3. Vorlagen sind pro Tenant anpassbar (Branding aus TEN-03 nutzbar)
+
+## 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. Vorlagenrendering mit fehlenden Platzhaltern bricht kontrolliert ab statt fehlerhafte Mails zu versenden
+2. In-App-Benachrichtigung nach Markierung als gelesen wird korrekt als gelesen geführt
+3. E-Mail-Versand bei nicht erreichbarem SMTP-Server löst dokumentiertes Retry-Verhalten über CFG-02 aus
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `CFG-04` Benachrichtigungs-Einstellungen-Oberfläche
+
+## 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: `CFG-03: benachrichtigungs-kanaele-e-mail-in-app`
+- Branch: `feature/cfg-03-benachrichtigungs-kanaele-e-mail-in-app`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/CFG-04.md

@@ -0,0 +1,62 @@
+# CFG-04 – Benachrichtigungs-Einstellungen-Oberfläche
+
+**Epic:** ⚙️ Zentrale Konfiguration & Benachrichtigungen  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Oberfläche für Benutzer und Tenant-Admins zur Verwaltung eigener Benachrichtigungspräferenzen je Kanal und Ereignistyp.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Ein Ort für Konfiguration und Benachrichtigungen, den jedes Modul wiederverwendet statt neu zu bauen.
+
+**Übernehmen:**
+- Unleash: Zentraler Konfigurationsdienst mit Caching und klarer Versionierung von Werten.
+- Zitadel: Mandantenspezifische Einstellungen (Branding, Policies) zentral verwaltet und an alle Module durchgereicht.
+- Prometheus/Grafana: Konfiguration als Code/Datensatz, der beobachtbar und nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Keycloak – Benachrichtigungs-/E-Mail-Konfiguration tief in Realm-Settings vergraben, schwer zentral zu pflegen.: Benachrichtigungs-Konfiguration als eigener, modulübergreifender Dienst.
+- Allgemein verbreitetes Muster – jedes Modul baut seinen eigenen E-Mail-Versand.: Ein zentraler Dispatcher, den alle Module über eine schmale Schnittstelle ansprechen.
+
+**Für genau diese Kachel:** Einstellungsoberfläche als dünner Client der Kanal-Konfiguration, keine eigene Zustelllogik im Frontend.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `CFG-03` Benachrichtigungs-Kanäle (E-Mail/In-App) – Konkrete Zustellkanäle für den Dispatcher: E-Mail-Versand und In-App-Benachrichtigungen, inklusive Vorlagenverwaltung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Benutzer kann Kanäle (E-Mail/In-App) je Ereignistyp an- und abschalten
+2. Änderungen wirken sich unmittelbar auf künftige Zustellungen aus
+3. Tenant-Admin sieht eine Übersicht der Benachrichtigungs-Konfiguration seines 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. Deaktivierter Kanal erhält im Test nachweislich keine weitere Zustellung
+2. Einstellungen eines Benutzers wirken sich nicht auf einen anderen Benutzer aus
+3. Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen
+
+## 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: `CFG-04: benachrichtigungs-einstellungen-oberflaeche`
+- Branch: `feature/cfg-04-benachrichtigungs-einstellungen-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/DEVLOG.md

@@ -0,0 +1,13 @@
+# tickets – Dev Log
+
+## 2026-09-12 21:09 – 21:10 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** nexarch
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+Keine Änderungen ermittelbar.
+
+---

core-kanban/tickets/IAM-01.md

@@ -0,0 +1,67 @@
+# IAM-01 – Benutzer-Datenmodell & CRUD
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Benutzer-Datenmodell (Kernattribute, Status, Tenant-Zugehörigkeit) sowie CRUD-API zur Verwaltung von Benutzerkonten.
+
+**Technische Grundlage:** PostgreSQL, Go/pgx
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Benutzer- und Service-Account-Modell nach Zitadel-Vorbild von Anfang an sauber getrennt von der reinen Login-Logik.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Benutzer lassen sich anlegen, lesen, aktualisieren und deaktivieren
+2. Jeder Benutzer ist eindeutig einem Tenant zugeordnet, Superadmin-ohne-Tenant ist als First-Class-Zustand modelliert
+3. E-Mail-Eindeutigkeit ist verbindlich geregelt (global oder tenant-scoped, dokumentiert)
+
+## 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. CRUD-Operationen automatisiert getestet inklusive Negativfällen (doppelte E-Mail, fehlender Tenant)
+2. Superadmin-Anlage ohne Tenant-Kontext funktioniert ohne Sonderbehandlung im Code
+3. Datenmodell von zweiter Person gegen die Dokumentation geprüft
+
+## Bekannte Fehler vermeiden
+
+- **Superadmin-Sonderfall wiederholt vergessen**: In archivdms wurde der Fall "Superadmin ohne Tenant-Kontext" mehrfach nachträglich gepatcht (403 "tenant context required"), weil er nicht im Datenmodell verankert war. → Superadmin-ohne-Tenant von Anfang an als First-Class-Zustand im Benutzer-/Tenant-Datenmodell modellieren.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-02` Login/Session/JWT-Grundgerüst
+- `RBAC-01` Rollenmodell & Grundrechte
+
+## 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: `IAM-01: benutzer-datenmodell-crud`
+- Branch: `feature/iam-01-benutzer-datenmodell-crud`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-02.md

@@ -0,0 +1,76 @@
+# IAM-02 – Login/Session/JWT-Grundgerüst
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+**Technische Grundlage:** Session/JWT, bcrypt, Go/net/http
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Login schlank halten wie ein reiner Identitäts-Check nach Zitadel-Vorbild – die Rechtetiefe kommt aus RBAC, nicht aus dem Anmeldeverfahren.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-01` Benutzer-Datenmodell & CRUD – Benutzer-Datenmodell (Kernattribute, Status, Tenant-Zugehörigkeit) sowie CRUD-API zur Verwaltung von Benutzerkonten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Login/Logout funktionieren mit sicherem Session-Cookie bzw. JWT
+2. Passwörter werden ausschließlich mit bcrypt gehasht, niemals im Klartext gespeichert oder geloggt
+3. Geschützte Routen sind ohne gültige Session/Token nicht erreichbar
+4. bcrypt-Kostenfaktor ist explizit festgelegt (nicht Standardwert unreflektiert übernommen) und gegen eine Ziel-Login-Latenz benchmarkt.
+
+## 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. Login-Query ist nachweislich auf den korrekten Tenant gescopt (kein Cross-Tenant-Login möglich)
+2. Session-Fixation- und Token-Manipulationstest bestanden
+3. Abgelaufene Session/abgelaufenes Token erzwingt Neuanmeldung
+4. Login-Latenz mit festgelegtem Kostenfaktor gemessen und gegen Zielwert bestätigt.
+
+## Bekannte Fehler vermeiden
+
+- **Login-Query ohne Tenant-Filter**: In archivmail suchte der Login `SELECT ... WHERE email=$1` ohne tenant_id-Filter, was Cross-Tenant-Verwechslungen ermöglichte. → E-Mail global eindeutig erzwingen oder den Login-Lookup zusätzlich auf den Tenant scopen.
+- **Timing-safe Vergleich als projektweite Konvention**: Timing-safe Vergleich gilt als Konvention für JEDEN sicherheitsrelevanten Vergleich im Projekt (Passwort, Token, Signaturen, Freigabelinks), nicht nur für den Login-Pfad hier – an dieser Stelle als Referenzimplementierung, andere Module (z. B. Archive CMP-06 Freigabelinks) übernehmen dasselbe Muster.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-01` REST-API-Grundgerüst & Versionierung
+- `IAM-03` Passwort-Reset & Einladungs-Flow
+- `IAM-04` Zwei-Faktor-Authentifizierung (TOTP)
+- `IAM-05` LDAP/Active-Directory-Anbindung
+- `IAM-06` SSO-Anmeldung über OIDC
+- `IAM-07` Account-Lockout & Login-Rate-Limiting
+- `IAM-08` Benutzerprofil- & Login-Oberfläche
+- `IAM-09` API-Token & Service-Accounts
+
+## 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: `IAM-02: login-session-jwt-grundgeruest`
+- Branch: `feature/iam-02-login-session-jwt-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.

core-kanban/tickets/IAM-03.md

@@ -0,0 +1,62 @@
+# IAM-03 – Passwort-Reset & Einladungs-Flow
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Einmal-Token-basierter Passwort-Reset sowie Einladungs-Flow für neue Benutzer inklusive Ablaufzeit.
+
+**Technische Grundlage:** E-Mail-Versand, Token, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Einladungs-Flow im Stil von Zitadels Self-Service-Registrierung – schnell abgeschlossen, ohne Administrator-Warteschleife.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Reset-Token ist einmalig verwendbar und läuft nach definierter Zeit ab
+2. Einladungs-Link setzt das Erstpasswort ohne bestehende Session
+3. Bereits verwendete oder abgelaufene Token werden eindeutig abgewiesen
+
+## 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. Wiederverwendung eines bereits eingelösten Tokens automatisiert getestet und abgewiesen
+2. Ablaufzeit wird serverseitig durchgesetzt, nicht nur im Frontend geprüft
+3. Token werden nicht im Klartext geloggt (Stichprobe im Log-Ausgang geprüft)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-08` Benutzerprofil- & Login-Oberfläche
+
+## 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: `IAM-03: passwort-reset-einladungs-flow`
+- Branch: `feature/iam-03-passwort-reset-einladungs-flow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-04.md

@@ -0,0 +1,62 @@
+# IAM-04 – Zwei-Faktor-Authentifizierung (TOTP)
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+TOTP-basierte Zwei-Faktor-Authentifizierung inklusive Einrichtung, Wiederherstellungscodes und erzwingbarer Aktivierungspflicht pro Tenant.
+
+**Technische Grundlage:** TOTP (RFC 6238), QR-Code, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** 2FA als Standardweg wie bei Zitadel, nicht als nachträgliches Plug-in – Aktivierungspflicht ist pro Tenant konfigurierbar.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Benutzer kann TOTP per QR-Code einrichten und muss den Code vor Aktivierung einmal bestätigen
+2. Login mit aktivem 2FA verlangt zwingend den zweiten Faktor
+3. Wiederherstellungscodes ermöglichen Zugang bei Verlust des Geräts, sind aber nur einmal nutzbar
+
+## 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. Login-Versuch ohne zweiten Faktor bei aktivem 2FA wird zuverlässig abgewiesen
+2. Wiederherstellungscode nach Nutzung automatisiert als verbraucht getestet
+3. Zeitversatz-Toleranz (Clock-Skew) des TOTP-Algorithmus dokumentiert und getestet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-08` Benutzerprofil- & Login-Oberfläche
+
+## 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: `IAM-04: zwei-faktor-authentifizierung-totp`
+- Branch: `feature/iam-04-zwei-faktor-authentifizierung-totp`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-05.md

@@ -0,0 +1,66 @@
+# IAM-05 – LDAP/Active-Directory-Anbindung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Anbindung an LDAP/Active Directory je Tenant für Benutzer-Synchronisation und Login-Delegation, inklusive Rollenzuordnung aus Gruppen.
+
+**Technische Grundlage:** LDAP/AD, Go LDAP-Client, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** LDAP-Anbindung als eine von mehreren Föderationsquellen, analog zu Zitadels Identitätsanbieter-Konzept.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Tenant kann eine LDAP-Quelle konfigurieren und Benutzer werden synchronisiert
+2. Login gegen LDAP funktioniert als Alternative zum lokalen Passwort
+3. Rollenzuordnung aus LDAP-Gruppen erfolgt ausschließlich über eine explizit getestete Erlaubnis-Matrix
+
+## 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. Rollen-Erlaubnis-Matrix mit Positiv- und Negativfällen automatisiert getestet (keine Privilege-Escalation über Gruppenmitgliedschaft)
+2. Synchronisationslauf mit fehlerhafter/nicht erreichbarer LDAP-Quelle bricht kontrolliert ab, ohne bestehende Konten zu beschädigen
+3. Deaktivierung eines Benutzers in LDAP wird bei nächster Synchronisation korrekt übernommen
+
+## Bekannte Fehler vermeiden
+
+- **Privilege-Escalation-Lücke bei Rollenzuweisung durch externe Quelle**: In archivmail musste eine Lücke, durch die Rollenzuweisungen aus LDAP zu unbeabsichtigt hohen Rechten führen konnten, nachträglich gehärtet werden. → Rollen-Erlaubnis-Matrix von Anfang an testgestützt entwickeln, nicht nachträglich patchen.
+
+## 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: `IAM-05: ldap-active-directory-anbindung`
+- Branch: `feature/iam-05-ldap-active-directory-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.

core-kanban/tickets/IAM-06.md

@@ -0,0 +1,66 @@
+# IAM-06 – SSO-Anmeldung über OIDC
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+SSO-Anmeldung über OpenID Connect gegen externe Identity-Provider inklusive Rollen-Mapping aus Claims und Fallback auf lokalen Login.
+
+**Technische Grundlage:** OpenID Connect, OAuth2, JWKS
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** SSO nach Zitadel-Vorbild (echtes OIDC, kein eigenes Protokoll), aber ohne Keycloaks schwergewichtige Realm-/Client-Konfiguration.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Anmeldung über mindestens einen externen OIDC-Provider funktioniert end-to-end inklusive Token-Validierung
+2. Rollen-Mapping aus OIDC-Claims erfolgt über dieselbe getestete Erlaubnis-Matrix wie bei LDAP
+3. Fehlerhafte oder abgelaufene Tokens des Identity-Providers werden abgewiesen, lokaler Login bleibt als Fallback nutzbar
+
+## 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. Rollen-Erlaubnis-Matrix für OIDC-Claims automatisiert getestet (keine Privilege-Escalation über manipulierte Claims)
+2. Token-Signatur- und Ablaufprüfung gegen JWKS automatisiert getestet
+3. State/Nonce-Handling gegen CSRF und Replay geprüft
+
+## Bekannte Fehler vermeiden
+
+- **Privilege-Escalation bei Rollenzuweisung durch externe Quelle**: siehe IAM-05 – dasselbe Risiko gilt für Claims-basiertes Rollen-Mapping bei OIDC. → Rollen-Erlaubnis-Matrix von Anfang an testgestützt entwickeln, nicht nachträglich patchen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Penetrationsprüfung Core
+
+## 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: `IAM-06: sso-anmeldung-ueber-oidc`
+- Branch: `feature/iam-06-sso-anmeldung-ueber-oidc`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-07.md

@@ -0,0 +1,66 @@
+# IAM-07 – Account-Lockout & Login-Rate-Limiting
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Brute-Force-Schutz durch Account-Lockout nach definierten Fehlversuchen und Rate-Limiting des Login-Endpunkts mit geteiltem, externem State.
+
+**Technische Grundlage:** PostgreSQL-basierte Rate-Limit-Tabelle, Go
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Rate-Limiting als geteilter, externer Zustand von Anfang an – kein In-Process-Zähler, der bei Mehrinstanzbetrieb aushebelbar wäre.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Konto wird nach definierter Anzahl Fehlversuchen zeitlich gesperrt
+2. Rate-Limit-State liegt in Postgres (nicht in-process) und gilt korrekt über mehrere Instanzen hinweg
+3. Gesperrtes Konto entsperrt sich automatisch nach Ablauf der Sperrzeit oder durch Administratoreingriff
+
+## 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. Zwei parallel laufende Dienstinstanzen teilen sich denselben Rate-Limit-Zähler (Mehrinstanz-Test)
+2. Brute-Force-Sperre greift nach definierten Fehlversuchen zuverlässig
+3. Zeitversatz zwischen Sperre und Entsperrung automatisiert getestet
+
+## Bekannte Fehler vermeiden
+
+- **In-Memory Rate-Limiter ohne Shared State**: In archivdms war der Rate-Limiter (`internal/auth/ratelimit.go`) pro Instanz getrennt und bei Mehrinstanz-Deployment aushebelbar. → Rate-Limit-State von Anfang an extern/shared auslegen, hier Postgres-basiert, nicht in-process.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Penetrationsprüfung Core
+
+## 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: `IAM-07: account-lockout-login-rate-limiting`
+- Branch: `feature/iam-07-account-lockout-login-rate-limiting`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-08.md

@@ -0,0 +1,64 @@
+# IAM-08 – Benutzerprofil- & Login-Oberfläche
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Login-Oberfläche inklusive 2FA-Eingabe, Passwort-Reset-Flow und Profilverwaltung (eigene Daten, Passwort ändern, 2FA einrichten).
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Login-Oberfläche direkt im eigenen Frontend statt externer Theming-Engine wie bei Keycloak – volle Kontrolle über Look & Flow.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+- `IAM-03` Passwort-Reset & Einladungs-Flow – Einmal-Token-basierter Passwort-Reset sowie Einladungs-Flow für neue Benutzer inklusive Ablaufzeit.
+- `IAM-04` Zwei-Faktor-Authentifizierung (TOTP) – TOTP-basierte Zwei-Faktor-Authentifizierung inklusive Einrichtung, Wiederherstellungscodes und erzwingbarer Aktivierungspflicht pro Tenant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Login-Formular führt inklusive optionalem zweitem Faktor zu einer erfolgreichen Anmeldung
+2. Profilseite erlaubt Passwortänderung und 2FA-Einrichtung mit Klartextanzeige der Wiederherstellungscodes nur einmalig
+3. Fehleranzeigen bei falschem Passwort/Token sind verständlich, ohne interne Details preiszugeben
+
+## 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. Login mit falschem Passwort/Token zeigt generische, keine Konto-Existenz verratende Fehlermeldung
+2. 2FA-Einrichtung end-to-end von zweiter Person nachvollzogen
+3. Barrierefreiheit der Formulare (Tastaturbedienung, Labels) stichprobenartig geprüft
+
+## 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 Identität & Mandanten
+
+## 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: `IAM-08: benutzerprofil-login-oberflaeche`
+- Branch: `feature/iam-08-benutzerprofil-login-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-09.md

@@ -0,0 +1,62 @@
+# IAM-09 – API-Token & Service-Accounts
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Service-Accounts als eigenständige Identitäten sowie persönliche API-Token zur programmatischen Authentifizierung, mit Scopes und Ablaufzeit.
+
+**Technische Grundlage:** PostgreSQL, gehashte API-Schlüssel, Go
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+
+**Für genau diese Kachel:** Service-Accounts als eigenständige Identitätsklasse neben menschlichen Benutzern, exakt wie bei Zitadel modelliert.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Service-Account lässt sich anlegen und erhält ein eigenes, gehashtes API-Token
+2. Token sind scope-beschränkt und optional zeitlich befristet
+3. Widerruf eines Tokens wirkt sofort, keine Cache-Verzögerung
+
+## 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. Token werden ausschließlich gehasht gespeichert (Stichprobe in der Datenbank geprüft)
+2. Widerrufener Token wird bei nächstem Request zuverlässig abgewiesen
+3. Scope-Verletzung (Token ohne passenden Scope) wird korrekt abgewiesen
+
+## 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: `IAM-09: api-token-service-accounts`
+- Branch: `feature/iam-09-api-token-service-accounts`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-10.md

@@ -0,0 +1,63 @@
+# IAM-10 – Passwortlose Anmeldung via WebAuthn/Passkey
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+WebAuthn/Passkey als alternativer Anmeldefaktor zu Passwort+TOTP – Registrierung eines Authenticators (Plattform wie Windows Hello/Touch ID, oder externer Sicherheitsschlüssel) und Anmeldung ohne Passworteingabe.
+
+**Technische Grundlage:** WebAuthn, FIDO2/CTAP, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Passkey als primärer, moderner Login-Faktor.
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Login-Anpassungen.: Login-Oberfläche direkt im Next.js-Frontend, keine externe Theming-Engine.
+- Zwang zu WebAuthn: bleibt zusätzliche Option neben Passwort+TOTP, kein Ersatz, damit Kunden ohne kompatible Hardware nicht ausgeschlossen werden.
+
+**Für genau diese Kachel:** WebAuthn/Passkey nach Zitadel-Vorbild als moderner Login-Faktor, aber strikt optional – Passwort+TOTP bleibt vollwertiger Anmeldeweg, kein Kunde wird durch fehlende Hardware ausgeschlossen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Benutzer kann einen WebAuthn-Authenticator registrieren und sich damit anmelden, ohne Passwort einzugeben
+2. Mehrere Authenticatoren pro Benutzer sind möglich (Gerätewechsel/-verlust)
+3. Passwort+TOTP bleibt als Fallback nutzbar, kein Zwang auf WebAuthn
+
+## 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 und Anmeldung mit simuliertem Authenticator im Test erfolgreich
+2. Zweiter Authenticator registriert, beide funktionsfähig
+3. Login mit Passwort+TOTP funktioniert weiterhin unverändert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-08` Benutzerprofil- & Login-Oberfläche
+
+## 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: `IAM-10: passwortlose-anmeldung-via-webauthn-passkey`
+- Branch: `feature/iam-10-passwortlose-anmeldung-via-webauthn-passkey`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-11.md

@@ -0,0 +1,66 @@
+# IAM-11 – SAML 2.0-Anbindung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+SAML 2.0 als zusätzlicher Anmeldeweg neben OIDC (IAM-06) – für Kunden, deren Identity Provider nur SAML spricht (viele Enterprise-/Behörden-Umgebungen).
+
+**Technische Grundlage:** SAML 2.0, XML-Signaturprüfung, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Keycloak: Breite Protokollunterstützung als Stärke – SAML als vollwertiger Anmeldeweg neben OIDC.
+- Zitadel: Getrennte Behandlung von menschlichen Benutzern und maschinellen Service-Accounts im selben Identitätsmodell.
+- Casbin: Klare Trennung zwischen Authentifizierung (wer bin ich) und Autorisierung (was darf ich) als Architekturprinzip.
+
+**Bewusst vermeiden:**
+- Keycloak – Schwergewichtiger Java-Anwendungsserver mit hohem RAM-Bedarf allein für Login/SSO.: Schlanker Go-Dienst, Login/JWT als schmale eigene Schicht.
+- Keycloak – Konfigurationskomplexität bei Multi-Realm/Multi-Protokoll-Betrieb.: SAML-Einrichtung kommt mit sinnvollen Defaults aus, setzt kein tiefes SAML-Expertenwissen voraus.
+
+**Für genau diese Kachel:** SAML nach Keycloak-Vorbild als vollwertiger, breiter Protokollanschluss, aber ohne Keycloaks Konfigurationskomplexität – Einrichtung pro Tenant bleibt ein einfacher, defaultbehafteter Vorgang statt Multi-Realm-Expertenwissen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. SAML-Anmeldung gegen einen Test-Identity-Provider funktioniert
+2. SAML- und OIDC-Anmeldung können nebeneinander für unterschiedliche Tenants konfiguriert sein
+3. SAML-Assertion wird korrekt auf das bestehende Benutzer-/Rollenmodell (IAM-01/RBAC) abgebildet
+
+## 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. End-to-End-Test gegen simulierten SAML-IdP erfolgreich
+2. Zwei Tenants mit unterschiedlichem Anmeldeweg (SAML vs. OIDC) im Test parallel funktionsfähig
+3. Rollenzuordnung aus SAML-Attributen im Test korrekt
+
+## Bekannte Fehler vermeiden
+
+- **Privilege-Escalation bei Rollenzuweisung durch externe Quelle**: siehe IAM-06 – dasselbe Risiko gilt für Attribut-basiertes Rollen-Mapping bei SAML-Assertions. → Rollen-Erlaubnis-Matrix von Anfang an testgestützt entwickeln, nicht nachträglich patchen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Penetrationsprüfung Core
+
+## 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: `IAM-11: saml-2-0-anbindung`
+- Branch: `feature/iam-11-saml-2-0-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.

core-kanban/tickets/IAM-12.md

@@ -0,0 +1,59 @@
+# IAM-12 – Aktive-Sitzungen-Verwaltung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Nutzer sieht seine eigenen aktiven Sitzungen (Gerät/Browser, IP, letzter Zugriff) und kann einzelne oder alle widerrufen (z. B. bei verlorenem Gerät).
+
+**Technische Grundlage:** Session/JWT, Go/net/http
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Transparente Sitzungsübersicht als Sicherheitsfeature.
+
+**Bewusst vermeiden:**
+- Keycloak – Unübersichtliche Admin-only-Sitzungsverwaltung.: Nutzer verwaltet seine eigenen Sitzungen selbst, ohne Admin-Umweg.
+
+**Für genau diese Kachel:** Sitzungsübersicht nach Zitadel-Vorbild als Selbstbedienungs-Sicherheitsfeature, nicht als Admin-Werkzeug.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nutzer kann eigene aktive Sitzungen mit Geräte-/Zugriffsinformationen einsehen
+2. Einzelne Sitzung ist gezielt widerrufbar, wird beim nächsten Zugriffsversuch sofort ungültig
+3. „Alle anderen Sitzungen beenden" ist als Sammelaktion möglich, aktuelle Sitzung bleibt bestehen
+
+## 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 Sitzungen desselben Nutzers angelegt, beide in der Übersicht sichtbar
+2. Widerruf einer Sitzung im Test macht das zugehörige Token sofort ungültig
+3. „Alle anderen beenden" im Test funktioniert korrekt, aktuelle bleibt aktiv
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-08` Benutzerprofil- & Login-Oberfläche
+
+## 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: `IAM-12: aktive-sitzungen-verwaltung`
+- Branch: `feature/iam-12-aktive-sitzungen-verwaltung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-13.md

@@ -0,0 +1,64 @@
+# IAM-13 – OIDC-Provider für Drittanwendungen
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+NEXARCH tritt selbst als OIDC/OAuth2-Identity-Provider auf (nicht nur als Konsument wie IAM-06), damit Drittanwendungen eines Kunden (z. B. eigene interne Tools, Connect-Board-Integrationen) sich gegen NEXARCH-Benutzerkonten authentifizieren können – Client-Registrierung, Authorization-Code-Flow, eigene JWKS-Ausgabe.
+
+**Technische Grundlage:** OpenID Connect, OAuth2, JWKS
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Keycloak: Kann sowohl Consumer als auch Provider sein, volle Protokollabdeckung.
+
+**Bewusst vermeiden:**
+- Keycloak – Konfigurationskomplexität bei Client-Registrierung.: Einfache Default-Clients mit sinnvollen Scopes statt umfangreichem Realm-Setup.
+
+**Für genau diese Kachel:** Volle OIDC-Protokollabdeckung nach Keycloak-Vorbild, aber mit einfacher Client-Registrierung statt schwergewichtigem Realm-Setup.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+- `IAM-06` SSO-Anmeldung über OIDC – SSO-Anmeldung über OpenID Connect gegen externe Identity-Provider inklusive Rollen-Mapping aus Claims und Fallback auf lokalen Login.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Drittanwendung kann sich als OAuth2-Client registrieren
+2. Authorization-Code-Flow gegen NEXARCH-Benutzerkonten funktioniert end-to-end
+3. Ausgestellte Tokens sind über die bestehende JWKS-Infrastruktur (API-05) verifizierbar, kein zweites Schlüsselsystem
+
+## 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-Client registriert, vollständiger Authorization-Code-Flow im Test erfolgreich
+2. Ausgestelltes Token durch Drittanwendung erfolgreich gegen JWKS verifiziert
+3. Rollen-/Scope-Einschränkung im Test wirksam (Client sieht nur zugestandene Scopes)
+
+## Bekannte Fehler vermeiden
+
+- **OIDC-Provider und OIDC-Konsument sind unterschiedliche Rollen, keine zweite Implementierung**: OIDC-Provider (diese Kachel) und OIDC-Konsument (IAM-06) sind unterschiedliche Rollen desselben Protokolls, nicht dieselbe Kachel – beide nutzen aber dieselbe zugrundeliegende Token-/Schlüssel-Infrastruktur (API-05), keine zweite Implementierung. → Auf API-05 aufsetzen statt eigenes JWKS/Schlüsselmanagement zu bauen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt
+
+## 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: `IAM-13: oidc-provider-fuer-drittanwendungen`
+- Branch: `feature/iam-13-oidc-provider-fuer-drittanwendungen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-14.md

@@ -0,0 +1,59 @@
+# IAM-14 – Passwort-Richtlinien
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Konfigurierbare Passwort-Komplexitätsanforderungen (Mindestlänge, Zeichenklassen, Sperrliste häufiger Passwörter) pro Tenant durchsetzbar – bisher regelt IAM-02 nur den bcrypt-Hashing-Mechanismus selbst, keine Anforderungen an das Passwort davor.
+
+**Technische Grundlage:** Go/net/http, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Anmeldung, Sitzung und Föderation so schlank wie möglich, so vertrauenswürdig wie nötig.
+
+**Übernehmen:**
+- Zitadel: Eingebaute Zwei-Faktor-Unterstützung als Standardweg, nicht als Add-on – dasselbe Prinzip „Sicherheit als Standard statt Add-on" gilt für Passwort-Komplexitätsanforderungen.
+
+**Bewusst vermeiden:**
+- Keycloak – Komplexe Themes/Flows-Konfiguration für einfache Anpassungen.: Passwort-Richtlinien als schlanke, pro Tenant konfigurierbare Regeln statt aufwendiger Policy-Engine.
+
+**Für genau diese Kachel:** Passwort-Anforderungen als schmale, testbare Regelschicht vor dem bcrypt-Hashing aus IAM-02, nicht als eigenes Policy-Framework.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-02` Login/Session/JWT-Grundgerüst – Anmeldung, Abmeldung, Session-Handling, Passwort-Hashing mit bcrypt und Middleware zum Schutz von Routen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Mindestanforderungen (Länge, Zeichenklassen) sind pro Tenant konfigurierbar
+2. Passwort aus einer Sperrliste häufig verwendeter/kompromittierter Passwörter wird abgelehnt
+3. Bestehende Nutzer mit nicht-konformem Passwort werden beim nächsten Login zur Änderung aufgefordert, nicht rückwirkend zwangsweise ausgesperrt
+
+## 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: zu kurzes/zu einfaches Passwort wird bei Registrierung/Änderung abgelehnt
+2. Test: Passwort aus Sperrliste wird abgelehnt
+3. Test: bestehender Nutzer mit altem, nicht-konformem Passwort kann sich noch einloggen, wird aber zur Änderung aufgefordert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-03` Passwort-Reset & Einladungs-Flow
+
+## 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: `IAM-14: passwort-richtlinien`
+- Branch: `feature/iam-14-passwort-richtlinien`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-15.md

@@ -0,0 +1,49 @@
+# IAM-15 – Timing-safe Vergleich als projektweite Coding-Konvention
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Verbindliche, dokumentierte Coding-Konvention: jeder Vergleich, der eine sicherheitsrelevante Zugriffsentscheidung trifft (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nutzt einen timing-safe/constant-time Vergleich – nicht nur an einer Stelle vorgemacht, sondern als projektweite Regel wie das bereits bestehende Sprintf-Verbot für SQL.
+
+**Technische Grundlage:** crypto/subtle.ConstantTimeCompare (Go), projektweite Coding-Guideline
+
+## Produkt-DNA für diesen Bereich
+> Eine sicherheitsrelevante Coding-Regel, die nur einmal vorgemacht statt projektweit verankert wird, wird beim nächsten neuen Vergleich vergessen – dieselbe Lehre wie beim Sprintf-Verbot für SQL.
+
+**Übernehmen:**
+- archivdms: Share-Link-Passwortvergleich nutzte bereits timing-safe Vergleich (known-issues-archivdms.md, Positiv-Abschnitt) – als Vorbild für die projektweite Regel übernommen, nicht nur für Share-Links.
+
+**Bewusst vermeiden:**
+- Kein Vergleich mit dem regulären ==-Operator bei sicherheitsrelevanten Entscheidungen, auch nicht "nur zum Testen".
+
+**Für genau diese Kachel:** Ohne dieses Ticket bleibt die Regel nur implizit durch ein einzelnes positives Altsystem-Beispiel nahegelegt – SICHERHEITSKONZEPT.md Abschnitt 11 Punkt 9 benennt genau diese Lücke.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-04` Zwei-Faktor-Authentifizierung (TOTP) – enthält die erste konkrete Vergleichsstelle (2FA-Wiederherstellungscode), an der die Konvention demonstriert wird.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Projektweite Coding-Konvention dokumentiert: jeder sicherheitsrelevante Vergleich (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode) nutzt einen timing-safe/constant-time Vergleich, nie den regulären ==-Operator
+2. Konvention ist in einer projektweiten Coding-Guideline abgelegt, nicht nur an einer Beispielstelle im Code
+3. Mindestens die bereits bestehenden Vergleichsstellen (IAM-04 2FA-Code, Core-Signaturprüfung) sind auf die Konvention geprüft und ggf. korrigiert
+
+## 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. Code-Review-Checkliste/Guideline enthält die Regel mit Beispiel
+2. Stichprobe bestehender Vergleichsstellen (2FA, Signaturprüfung) zeigt konsequente Anwendung
+
+## 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.

core-kanban/tickets/IAM-16.md

@@ -0,0 +1,59 @@
+# IAM-16 – Session-/Token-Widerruf bei Logout und Kompromittierung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IAM-02 definiert Login/Session/JWT-Grundgerüst, aber kein Widerrufsmechanismus: ein ausgestelltes JWT bleibt bis zum regulären Ablauf gültig, auch nach explizitem Logout oder bei erkanntem Diebstahl. Revocation-Store ergänzen (z. B. Session-/Token-Tabelle mit Gültigkeits-Flag), den die Auth-Middleware bei jeder geschützten Anfrage zusätzlich zur Signaturprüfung konsultiert, sowie einen Admin-/Self-Service-Endpunkt zum sofortigen Widerruf einzelner oder aller Sessions eines Benutzers.
+
+**Technische Grundlage:** Session/JWT, Revocation-Store (PostgreSQL), Go/net/http
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Sitzungen sind einsehbar und einzeln widerrufbar, nicht nur global abschaltbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Session-Invalidierung erfordert oft Realm-weite Cache-Invalidierung mit Nebenwirkungen.: Widerruf gezielt pro Session/Token, ohne andere Sitzungen zu beeinflussen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: IAM-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nach explizitem Logout ist das zugehörige Token/die Session sofort ungültig, auch vor Ablauf der TTL
+2. Ein Benutzer oder Admin kann alle aktiven Sessions eines Kontos auf einen Schlag widerrufen (z. B. bei Verdacht auf Kompromittierung)
+3. Die Auth-Middleware prüft bei jeder Anfrage zusätzlich zur Signatur den Widerrufsstatus, mit vertretbarem Performance-Overhead (In-Prozess-Cache mit kurzer TTL zulässig)
+
+## 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. Logout-Test: Token nach Logout gegen geschützten Endpunkt verwenden, erwartet Ablehnung
+2. Massenwiderruf-Test: alle Sessions eines Benutzers widerrufen, prüfen dass alle zugehörigen Tokens abgelehnt werden, andere Benutzer unberührt bleiben
+3. Lasttest der Widerrufsprüfung gegen die Auth-Middleware, um Performance-Regression auszuschließen
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): ohne Widerrufsmechanismus bleibt ein gestohlenes JWT bis zum Ablauf nutzbar – Spoofing-Risiko, das durch reine TTL-Verkürzung nur abgemildert, nicht behoben wird.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-02` Login/Session/JWT-Grundgerüst
+- `IAM-09` API-Token & Service-Accounts
+
+## 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: `IAM-16: session-token-widerruf-bei-logout-und-kompromittierung`
+- Branch: `feature/iam-16-session-token-widerruf-bei-logout-und-kompromittierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-17.md

@@ -0,0 +1,59 @@
+# IAM-17 – Session-/Token-Widerruf bei Logout und Kompromittierung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IAM-02 definiert Login/Session/JWT-Grundgerüst, aber kein Widerrufsmechanismus: ein ausgestelltes JWT bleibt bis zum regulären Ablauf gültig, auch nach explizitem Logout oder bei erkanntem Diebstahl. Revocation-Store ergänzen (z. B. Session-/Token-Tabelle mit Gültigkeits-Flag), den die Auth-Middleware bei jeder geschützten Anfrage zusätzlich zur Signaturprüfung konsultiert, sowie einen Admin-/Self-Service-Endpunkt zum sofortigen Widerruf einzelner oder aller Sessions eines Benutzers.
+
+**Technische Grundlage:** Session/JWT, Revocation-Store (PostgreSQL), Go/net/http
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Sitzungen sind einsehbar und einzeln widerrufbar, nicht nur global abschaltbar.
+
+**Bewusst vermeiden:**
+- Keycloak – Session-Invalidierung erfordert oft Realm-weite Cache-Invalidierung mit Nebenwirkungen.: Widerruf gezielt pro Session/Token, ohne andere Sitzungen zu beeinflussen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: IAM-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nach explizitem Logout ist das zugehörige Token/die Session sofort ungültig, auch vor Ablauf der TTL
+2. Ein Benutzer oder Admin kann alle aktiven Sessions eines Kontos auf einen Schlag widerrufen (z. B. bei Verdacht auf Kompromittierung)
+3. Die Auth-Middleware prüft bei jeder Anfrage zusätzlich zur Signatur den Widerrufsstatus, mit vertretbarem Performance-Overhead (In-Prozess-Cache mit kurzer TTL zulässig)
+
+## 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. Logout-Test: Token nach Logout gegen geschützten Endpunkt verwenden, erwartet Ablehnung
+2. Massenwiderruf-Test: alle Sessions eines Benutzers widerrufen, prüfen dass alle zugehörigen Tokens abgelehnt werden, andere Benutzer unberührt bleiben
+3. Lasttest der Widerrufsprüfung gegen die Auth-Middleware, um Performance-Regression auszuschließen
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): ohne Widerrufsmechanismus bleibt ein gestohlenes JWT bis zum Ablauf nutzbar – Spoofing-Risiko, das durch reine TTL-Verkürzung nur abgemildert, nicht behoben wird.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-02` Login/Session/JWT-Grundgerüst
+- `IAM-09` API-Token & Service-Accounts
+
+## 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: `IAM-17: session-token-widerruf-bei-logout-und-kompromittierung`
+- Branch: `feature/iam-17-session-token-widerruf-bei-logout-und-kompromittierung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-18.md

@@ -0,0 +1,59 @@
+# IAM-18 – Strikte Claim-Validierung bei OIDC-SSO
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IAM-06 baut SSO-Anmeldung über OIDC mit Rollen-Mapping aus Claims, ohne explizit zu definieren, wie Issuer, Audience und Signatur geprüft werden. Strikte Validierung ergänzen: Issuer und Audience je Tenant fest hinterlegt statt aus dem Token selbst gelesen, Signatur ausschließlich gegen die JWKS des konfigurierten Issuers geprüft, und eine explizite Sperre, dass aus externen Claims niemals automatisch eine Superadmin-Rolle abgeleitet werden kann – Superadmin bleibt ausschließlich lokal vergebbar.
+
+**Technische Grundlage:** OpenID Connect, JWKS, Issuer-/Audience-Pinning
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der Authentifizierungsquelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Broker-Konfiguration erlaubt in Fehlkonfigurationen weitreichendes Claim-basiertes Rollen-Mapping bis zum Admin.: Rollen-Mapping aus externen Claims ist auf tenant-scoped Rollen begrenzt, Superadmin ausgeschlossen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: IAM-06.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Login wird abgelehnt, wenn Issuer oder Audience des Tokens nicht exakt mit der für den Tenant hinterlegten Konfiguration übereinstimmt
+2. Signaturprüfung verwendet ausschließlich die JWKS des konfigurierten Issuers, nie einen im Token selbst mitgelieferten Schlüssel/Issuer
+3. Rollen-Mapping aus externen Claims kann technisch keine Superadmin-Rolle vergeben, unabhängig vom Claim-Inhalt
+
+## 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. Negativtest: Token mit falschem Issuer/Audience wird abgelehnt
+2. Negativtest: manipuliertes Token mit fremdem Signaturschlüssel wird abgelehnt
+3. Negativtest: externer Claim behauptet Superadmin-Rolle, Login vergibt trotzdem höchstens die höchste zulässige tenant-scoped Rolle
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): ohne strikte Issuer-/Audience-/Signaturprüfung und explizite Superadmin-Sperre ermöglicht ein kompromittierter oder falsch konfigurierter externer IdP eine Rechteausweitung über SSO-Login.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-06` SSO-Anmeldung über OIDC
+- `RBAC-01` Rollenmodell & Grundrechte
+
+## 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: `IAM-18: strikte-claim-validierung-bei-oidc-sso`
+- Branch: `feature/iam-18-strikte-claim-validierung-bei-oidc-sso`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-19.md

@@ -0,0 +1,59 @@
+# IAM-19 – Verschlüsselte Ablage von LDAP/AD-Bind-Credentials
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IAM-05 bindet je Tenant an LDAP/Active Directory an, ohne festzulegen, wie das Bind-Passwort gespeichert wird. Bind-Credentials über den Tenant-KEK aus der Schlüsselhierarchie (API-10) verschlüsseln statt in einer separaten, eigenen Secret-Verwaltung oder gar Klartext in der Tenant-Konfiguration abzulegen.
+
+**Technische Grundlage:** LDAP/AD, Envelope-Encryption (Tenant-KEK aus API-10), PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Föderations-Credentials werden über dieselbe zentrale Schlüsselverwaltung geschützt wie andere sensible Tenant-Daten.
+
+**Bewusst vermeiden:**
+- Keycloak – Föderations-Provider-Konfiguration (u. a. LDAP-Bind-Passwort) historisch teils im Klartext in der Datenbank abgelegt.: LDAP-Bind-Passwort ausschließlich verschlüsselt über den Tenant-KEK abgelegt, nie im Klartext in Konfigurationstabellen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: IAM-05, API-10.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. LDAP-Bind-Passwort ist in der Datenbank ausschließlich verschlüsselt gespeichert, entschlüsselt mit dem Tenant-KEK des jeweiligen Mandanten
+2. Ein direkter Lesezugriff auf die Konfigurationstabelle liefert keinen verwertbaren Klartext des Bind-Passworts
+3. Bestehende LDAP-Synchronisation/Login-Delegation aus IAM-05 funktioniert unverändert
+
+## 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: LDAP-Bind-Passwort in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist
+2. Regressionstest: LDAP-Login/Synchronisation funktioniert nach Umstellung auf verschlüsselte Ablage weiterhin korrekt
+3. Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Bind-Credentials)
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): IAM-05 spezifiziert keine Speicherform für das LDAP-Bind-Passwort – ohne diese Kachel bleibt offen, ob es verschlüsselt oder im Klartext in der Tenant-Konfiguration liegt.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-05` LDAP/Active-Directory-Anbindung
+- `API-10` Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung)
+
+## 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: `IAM-19: verschl-sselte-ablage-von-ldap-ad-bind-credentials`
+- Branch: `feature/iam-19-verschl-sselte-ablage-von-ldap-ad-bind-credentials`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-20.md

@@ -0,0 +1,59 @@
+# IAM-20 – Anomalie-Erkennung bei API-Token-/Service-Account-Nutzung
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 11
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+IAM-09 deckt Scopes und Ablaufzeit für API-Token/Service-Accounts ab, aber ein gestohlenes, noch gültiges Token bleibt bis zum Ablauf unauffällig nutzbar. Einfache Anomalie-Erkennung ergänzen: Nutzung eines Tokens aus einer bisher nicht gesehenen IP-Range oder mit einer gegenüber dem bisherigen Muster stark abweichenden Zugriffsrate erzeugt einen Audit-Event mit erhöhtem Schweregrad (Kopplung an AUD-01) und optional eine Benachrichtigung an den Token-Besitzer/Tenant-Admin über den Core-Dispatcher (CFG-02). Keine automatische Sperre – die Erkennung ist ein Hinweissignal, keine eigenständige Durchsetzung, um Fehlalarme nicht zu blockierenden Vorfällen zu machen.
+
+**Technische Grundlage:** PostgreSQL, IP-/Rate-Heuristik, Core-Audit-Kopplung (AUD-01)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: sichtbare Session-/Token-Aktivität statt reiner Gültigkeitsprüfung ohne Kontext.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events erfassen Login-Anomalien nicht standardmäßig, nur bei manueller Zusatzkonfiguration.: Anomalie-Erkennung ist von Anfang an aktiver Bestandteil der Token-Nutzung, keine optionale Zusatzkomponente.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: IAM-09, AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nutzung eines API-Tokens/Service-Accounts aus einer bisher nicht beobachteten IP-Range erzeugt einen Audit-Event mit erhöhtem Schweregrad
+2. Ein gegenüber dem historischen Muster stark abweichender Zugriffsratenanstieg desselben Tokens erzeugt ebenfalls einen Audit-Event
+3. Das Token bleibt bei erkannter Anomalie weiterhin gültig (keine automatische Sperre) – die Erkennung dient als Hinweissignal, tatsächliche Sperre erfolgt manuell oder über einen bewussten separaten Prozess
+
+## 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 mit einem Token aus einer neuen IP-Range erzeugt den erwarteten Audit-Event
+2. Test: künstlich stark erhöhte Zugriffsrate desselben Tokens erzeugt den erwarteten Audit-Event
+3. Regressionstest: normale, unauffällige Token-Nutzung erzeugt keine Falsch-Alarme im regulären Betrieb
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12, Finding #2): ohne Anomalie-Erkennung bleibt ein gestohlenes, noch gültiges API-Token bis zum regulären Ablauf unauffällig nutzbar – reine Scope-/Ablaufzeit-Prüfung aus IAM-09 erkennt einen Missbrauch aus fremdem Kontext nicht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `IAM-09` API-Token & Service-Accounts
+- `AUD-01` Zentrales Audit-Log-Modell
+
+## 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: `IAM-20: anomalie-erkennung-bei-api-token-service-account-nutzung`
+- Branch: `feature/iam-20-anomalie-erkennung-bei-api-token-service-account-nutzung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-21.md

@@ -0,0 +1,61 @@
+# IAM-21 – Kontosperre und Quelladressen-Limit im Login
+
+**Epic:** 🔐 Identität & Zugang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+`lockout.GuardedLogin` ist definiert, wird aber nie aufgerufen; der Login erlaubt unbegrenzt viele Versuche, und der TOTP-Code wird vor dem Passwort geprüft (Befund F-04, teilweise F-06). Kontosperre (Postgres) und Begrenzung je Quelladresse werden in den Login-Pfad des Kontodienstes eingebunden, das Passwort wird vor dem zweiten Faktor geprüft.
+
+**Technische Grundlage:** `internal/lockout` (Store, neuer `IPLimiter`), `internal/totp` (`LoginWithTOTP`, `Handler.WithLoginGuard`), `cmd/account-api`
+
+## Produkt-DNA für diesen Bereich
+> Interne Endpunkte sind nie „nur intern“: ohne Authentifizierung, Grenzen und Zeitlimits ist jeder erreichbare Port eine Angriffsfläche.
+
+**Übernehmen:**
+- Geteilter Zustand in Postgres für die Kontosperre (mehrere Instanzen).
+
+**Bewusst vermeiden:**
+- Kein Zweitfaktor-Test vor dem Passwort: Ein 6-stelliger Code ist sonst ratbar und der 2FA-Status ist ohne Passwort erkennbar.
+- Keine unterschiedliche Reaktion für bekannte und unbekannte Konten.
+
+## 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-04 (hoch), F-06(a).
+- `IAM-07` Account-Lockout und `IAM-08` Login mit optionalem zweiten Faktor.
+- `IAM-16` Kontodienst.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nach der konfigurierten Zahl falscher Passwörter oder falscher Codes ist das Konto (auch eine unbekannte Adresse) gesperrt und liefert 429 mit `Retry-After`, auch bei richtigem Passwort; nach Ablauf der Sperre funktioniert der Login; Erfolg setzt den Zähler zurück
+2. Login und Passwort-Reset sind je Quelladresse begrenzt (429); `X-Forwarded-For` zählt nur mit `NEXARCH_ACCOUNT_TRUST_FORWARDED_FOR=true`
+3. Das Passwort wird vor dem zweiten Faktor geprüft: falsches Passwort ergibt immer `invalid_credentials`; ein fehlender Code nach richtigem Passwort zählt nicht als Fehlversuch, ein falscher Code schon
+
+## 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 echte Datenbank inklusive Zeitverlauf und Entsperrung
+2. Unbekannte und bekannte Adresse verhalten sich gleich; falsches Passwort verrät den 2FA-Status nicht
+3. Ende-zu-Ende Core→DMS (Login über den Kontodienst) bleibt grün
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Wiederverwendungsschutz für TOTP-Codes und Verschlüsselung der TOTP-Geheimnisse (F-06 b, c)
+- Bereinigung alter `login_attempts`-Zeilen
+
+## 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: `IAM-21: kontosperre und quelladressen-limit im login`
+- Branch: `feature/qa-15-phase2a-sicherheitsbehebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-22.md

@@ -0,0 +1,59 @@
+# IAM-22 – Zweitfaktor: einheitliche Antwort, Replay-Schutz, verschlüsselte Geheimnisse
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Der Zweitfaktor verrät durch `second_factor_required` die Existenz und den 2FA-Status eines Kontos, ein gültiger TOTP-Code lässt sich im Zeitfenster mehrfach verwenden, und `totp_credentials.secret` liegt unverschlüsselt in der Datenbank (Befund F-06).
+
+**Technische Grundlage:** `internal/totp` (`login.go`, `store.go`), KEK-Hierarchie (API-10)
+
+## Produkt-DNA für diesen Bereich
+> Der zweite Faktor schützt nur, wenn er weder Konten verrät noch wiederverwendbar ist.
+
+**Übernehmen:**
+- Login-Endpunkt mit optionalem 2FA (`POST /auth/login`).
+
+**Bewusst vermeiden:**
+- Keine unterschiedlichen Antworten für „Konto unbekannt“, „Passwort falsch“ und „Code fehlt“ vor erfolgreicher Passwortprüfung.
+
+## 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-06 (mittel).
+- `IAM-04` TOTP, `IAM-21` Login-Lockout (Phase 2a).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die Antwort auf einen Login ohne Code ist für Konten mit und ohne 2FA nicht unterscheidbar, solange das Passwort nicht stimmt
+2. Der zuletzt akzeptierte Zeitschritt wird je Konto gespeichert; ein zweiter Versuch mit demselben Code wird abgewiesen
+3. TOTP-Geheimnisse liegen mit dem Mandanten-KEK verschlüsselt; Bestand wird per Migrationsjob nachverschlüsselt
+
+## 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 zu Enumeration, Replay innerhalb des Fensters und Bestandsmigration
+2. Login-Lockout aus IAM-21 bleibt wirksam
+3. Ende-zu-Ende-Login mit 2FA
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- WebAuthn, Wiederherstellungscodes
+
+## 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: berührt den Login-Pfad, den Phase 2a (IAM-21) parallel ändert; erst nach deren Merge sinnvoll
+- Commit-Nachricht: `IAM-22: zweitfaktor haerten`
+- Branch: `feature/iam-22-zweitfaktor-haertung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/IAM-23.md

@@ -0,0 +1,59 @@
+# IAM-23 – Sitzungssignatur asymmetrisch, Mindestlänge für gemeinsame Geheimnisse
+
+**Epic:** 👤 Identität & Authentifizierung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+`NEXARCH_ACCOUNT_JWT_SECRET` (HS256) muss in Kontodienst, RBAC-Administration und weiteren Diensten identisch sein: jeder dieser Dienste kann Sitzungen für beliebige Nutzer ausstellen; es gibt keine Längen- oder Entropieprüfung (Befund F-10).
+
+**Technische Grundlage:** `internal/auth/token.go`, `cmd/rbac-admin-api`, `cmd/account-api`; Vorbild: EdDSA-Modul-JWT (API-05, API-16)
+
+## Produkt-DNA für diesen Bereich
+> Wer nur prüfen muss, soll nicht signieren können.
+
+**Übernehmen:**
+- JWKS-Verteilung aus API-05.
+
+**Bewusst vermeiden:**
+- Kein geteiltes Geheimnis zwischen Diensten.
+
+## 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-10 (mittel).
+- `IAM-02` Login/Session, `API-16` persistente Schlüssel.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Sitzungstokens werden asymmetrisch signiert; Dienste, die nur prüfen, erhalten nur den öffentlichen Schlüssel
+2. Bis zur Umstellung erzwingt die Konfiguration mindestens 32 Byte Länge des HS256-Geheimnisses (Start bricht sonst ab)
+3. Übergang mit beiden Verfahren, danach HS256 entfernt
+
+## 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 zu Signatur, Ablauf, Widerruf und Rotation
+2. Ende-zu-Ende Core→DMS
+3. Rollout-Reihenfolge dokumentiert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Neue Anmeldeverfahren
+
+## 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: Formatwechsel der Sitzungstokens braucht eine Übergangsstrategie und eine Betriebsentscheidung
+- Commit-Nachricht: `IAM-23: sitzungssignatur asymmetrisch`
+- Branch: `feature/iam-23-sitzungssignatur-asymmetrisch`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/LIC-01.md

@@ -0,0 +1,63 @@
+# LIC-01 – Lizenzmodell & Lizenzschlüssel-Prüfung
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Lizenzmodell je Tenant (Plan, Laufzeit, Modul-Umfang) sowie Prüfung signierter Lizenzschlüssel gegen den Tenant-Datensatz.
+
+**Technische Grundlage:** PostgreSQL, kryptographische Signaturprüfung, Go
+
+## Produkt-DNA für diesen Bereich
+> Features werden pro Mandant zentral geschaltet, nicht durch verstreute Konfigurationsflags im Code.
+
+**Übernehmen:**
+- Unleash: Feature-Flag-Service mit Strategien (An/Aus, Prozentsatz, Tenant-Ziel) statt Compile-Time-Flags.
+- Unleash: Klare API-Trennung zwischen Flag-Verwaltung (Admin) und Flag-Auswertung (SDK/Client).
+- Zitadel: Projekt-/Grant-Modell als Vorbild für modulare Lizenz-Freischaltung pro Mandant.
+
+**Bewusst vermeiden:**
+- Unleash – Voller Betrieb erfordert eigene Infrastruktur (Unleash-Server + eigene DB) als weiteren Dienst.: Feature-Flags als Kernfunktion des Core-Dienstes selbst, keine zusätzliche Infrastruktur.
+- Keycloak – kein natives Lizenzmodell, wird in der Praxis oft über zweckentfremdete Client-Scopes nachgebildet.: Lizenz/Feature-Flag als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen.
+
+**Für genau diese Kachel:** Lizenzmodell als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen wie in vielen IAM-only-Systemen üblich.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Lizenzschlüssel wird kryptographisch signiert ausgestellt und beim Einspielen validiert
+2. Abgelaufene oder ungültige Lizenzen werden erkannt und führen zu einem definierten eingeschränkten Zustand
+3. Lizenzumfang (Plan, Modul-Liste, Laufzeit) ist pro Tenant persistiert und 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. Manipulierter Lizenzschlüssel wird zuverlässig als ungültig erkannt (automatisierter Test)
+2. Ablauf einer Lizenz löst den dokumentierten eingeschränkten Zustand aus, nicht einen harten Systemausfall
+3. Signaturprüfung von zweiter Person gegen die Dokumentation nachvollzogen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `LIC-03` Nutzungszähler & Quotas
+- `LIC-04` Lizenz-/Modul-Verwaltungsoberfläche
+
+## 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: `LIC-01: lizenzmodell-lizenzschluessel-pruefung`
+- Branch: `feature/lic-01-lizenzmodell-lizenzschluessel-pruefung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/LIC-02.md

@@ -0,0 +1,66 @@
+# LIC-02 – Feature-Flag-Service je Tenant
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Feature-Flag-Dienst mit Strategien (global an/aus, Prozentsatz, Tenant-Zielgruppe) und schneller Auswertung ohne externe Infrastruktur.
+
+**Technische Grundlage:** PostgreSQL, In-Prozess-Cache, Go
+
+## Produkt-DNA für diesen Bereich
+> Features werden pro Mandant zentral geschaltet, nicht durch verstreute Konfigurationsflags im Code.
+
+**Übernehmen:**
+- Unleash: Feature-Flag-Service mit Strategien (An/Aus, Prozentsatz, Tenant-Ziel) statt Compile-Time-Flags.
+- Unleash: Klare API-Trennung zwischen Flag-Verwaltung (Admin) und Flag-Auswertung (SDK/Client).
+- Zitadel: Projekt-/Grant-Modell als Vorbild für modulare Lizenz-Freischaltung pro Mandant.
+
+**Bewusst vermeiden:**
+- Unleash – Voller Betrieb erfordert eigene Infrastruktur (Unleash-Server + eigene DB) als weiteren Dienst.: Feature-Flags als Kernfunktion des Core-Dienstes selbst, keine zusätzliche Infrastruktur.
+- Keycloak – kein natives Lizenzmodell, wird in der Praxis oft über zweckentfremdete Client-Scopes nachgebildet.: Lizenz/Feature-Flag als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen.
+
+**Für genau diese Kachel:** Feature-Flag-Service nach Unleash-Vorbild, aber als Kernfunktion des Core-Dienstes selbst statt separater Infrastruktur.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning – Control-Plane-Registry für Mandanten-Metadaten und Verbindungsinformationen, automatisierte Provisioning-Routine, die für jeden Mandanten eine eigene, physisch isolierte PostgreSQL-Datenbank anlegt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Feature-Flags lassen sich zentral definieren und pro Tenant oder Zielgruppe unterschiedlich auswerten
+2. Auswertung eines Flags erfolgt mit geringer Latenz über einen lokalen Cache mit klarer Invalidierung
+3. Änderung eines Flags wirkt ohne Neustart der abhängigen Dienste
+4. Deaktivierung eines Moduls sperrt nur den Zugriff, löscht keine Daten des Moduls — Löschung läuft ausschließlich über die Archive-Retention-Engine, nie automatisch durch eine Flag-Ä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. Flag-Änderung wird innerhalb der dokumentierten Cache-Invalidierungszeit wirksam (automatisiert gemessen)
+2. Zielgruppen-Strategie (z. B. bestimmter Tenant) liefert im Test die erwartete Auswertung
+3. Ausfall des Flag-Dienstes führt zu dokumentiertem Fallback-Verhalten, nicht zum Absturz abhängiger Dienste
+4. Modul-Deaktivierung im Test gefolgt von Reaktivierung zeigt unveränderte Daten, kein Datenverlust
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-02` Modul-Registry & Aktivierungsprüfung
+- `LIC-04` Lizenz-/Modul-Verwaltungsoberfläche
+- `RBAC-04` Modul-scoped Berechtigungen
+
+## 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: `LIC-02: feature-flag-service-je-tenant`
+- Branch: `feature/lic-02-feature-flag-service-je-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.

core-kanban/tickets/LIC-03.md

@@ -0,0 +1,62 @@
+# LIC-03 – Nutzungszähler & Quotas
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Nutzungszähler (z. B. Benutzeranzahl, Speicherverbrauch, API-Aufrufe) je Tenant erfassen und gegen lizenzierte Quotas prüfen.
+
+**Technische Grundlage:** PostgreSQL, Job-Queue (periodische Aggregation), Go
+
+## Produkt-DNA für diesen Bereich
+> Features werden pro Mandant zentral geschaltet, nicht durch verstreute Konfigurationsflags im Code.
+
+**Übernehmen:**
+- Unleash: Feature-Flag-Service mit Strategien (An/Aus, Prozentsatz, Tenant-Ziel) statt Compile-Time-Flags.
+- Unleash: Klare API-Trennung zwischen Flag-Verwaltung (Admin) und Flag-Auswertung (SDK/Client).
+- Zitadel: Projekt-/Grant-Modell als Vorbild für modulare Lizenz-Freischaltung pro Mandant.
+
+**Bewusst vermeiden:**
+- Unleash – Voller Betrieb erfordert eigene Infrastruktur (Unleash-Server + eigene DB) als weiteren Dienst.: Feature-Flags als Kernfunktion des Core-Dienstes selbst, keine zusätzliche Infrastruktur.
+- Keycloak – kein natives Lizenzmodell, wird in der Praxis oft über zweckentfremdete Client-Scopes nachgebildet.: Lizenz/Feature-Flag als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen.
+
+**Für genau diese Kachel:** Quota-Konzept im Sinne konfigurierbarer Grenzen wie bei Zitadel/Unleash-Umgebungen – Grenzen sind Konfiguration, nicht Hardcode.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `LIC-01` Lizenzmodell & Lizenzschlüssel-Prüfung – Lizenzmodell je Tenant (Plan, Laufzeit, Modul-Umfang) sowie Prüfung signierter Lizenzschlüssel gegen den Tenant-Datensatz.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nutzungszähler werden zuverlässig je Tenant erfasst und periodisch aggregiert
+2. Überschreitung einer Quota löst eine definierte Reaktion aus (Warnung, Sperre neuer Ressourcen)
+3. Zähler sind über API abrufbar für Verwaltungsoberfläche und Benachrichtigungen
+
+## 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. Quota-Überschreitung wird automatisiert erkannt und die definierte Reaktion ausgelöst
+2. Aggregationsjob liefert bei parallelen Schreibzugriffen konsistente Zählerstände
+3. Zählerstand eines Tenants beeinflusst nachweislich nicht den eines anderen Tenants
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `LIC-04` Lizenz-/Modul-Verwaltungsoberfläche
+
+## 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: `LIC-03: nutzungszaehler-quotas`
+- Branch: `feature/lic-03-nutzungszaehler-quotas`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/LIC-04.md

@@ -0,0 +1,64 @@
+# LIC-04 – Lizenz-/Modul-Verwaltungsoberfläche
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Oberfläche zur Übersicht von Lizenzstatus, aktivierten Modulen, Feature-Flags und aktuellem Nutzungsstand je Tenant.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Features werden pro Mandant zentral geschaltet, nicht durch verstreute Konfigurationsflags im Code.
+
+**Übernehmen:**
+- Unleash: Feature-Flag-Service mit Strategien (An/Aus, Prozentsatz, Tenant-Ziel) statt Compile-Time-Flags.
+- Unleash: Klare API-Trennung zwischen Flag-Verwaltung (Admin) und Flag-Auswertung (SDK/Client).
+- Zitadel: Projekt-/Grant-Modell als Vorbild für modulare Lizenz-Freischaltung pro Mandant.
+
+**Bewusst vermeiden:**
+- Unleash – Voller Betrieb erfordert eigene Infrastruktur (Unleash-Server + eigene DB) als weiteren Dienst.: Feature-Flags als Kernfunktion des Core-Dienstes selbst, keine zusätzliche Infrastruktur.
+- Keycloak – kein natives Lizenzmodell, wird in der Praxis oft über zweckentfremdete Client-Scopes nachgebildet.: Lizenz/Feature-Flag als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen.
+
+**Für genau diese Kachel:** Verwaltungsoberfläche als dünner Client von Lizenz- und Flag-Service, ohne eigene Lizenzlogik im Frontend.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `LIC-01` Lizenzmodell & Lizenzschlüssel-Prüfung – Lizenzmodell je Tenant (Plan, Laufzeit, Modul-Umfang) sowie Prüfung signierter Lizenzschlüssel gegen den Tenant-Datensatz.
+- `LIC-02` Feature-Flag-Service je Tenant – Feature-Flag-Dienst mit Strategien (global an/aus, Prozentsatz, Tenant-Zielgruppe) und schneller Auswertung ohne externe Infrastruktur.
+- `LIC-03` Nutzungszähler & Quotas – Nutzungszähler (z. B. Benutzeranzahl, Speicherverbrauch, API-Aufrufe) je Tenant erfassen und gegen lizenzierte Quotas prüfen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Lizenzstatus, Laufzeit und aktivierte Module sind auf einen Blick einsehbar
+2. Feature-Flags sind für berechtigte Administratoren umschaltbar, soweit die Lizenz dies erlaubt
+3. Nutzungsstand gegen Quota ist visuell klar dargestellt (z. B. Fortschrittsanzeige)
+
+## 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. Umschalten eines nicht lizenzierten Features wird verhindert und verständlich begründet
+2. Darstellung des Nutzungsstands stimmt mit den Backend-Zählern überein (Stichprobe)
+3. Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen
+
+## 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: `LIC-04: lizenz-modul-verwaltungsoberflaeche`
+- Branch: `feature/lic-04-lizenz-modul-verwaltungsoberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/LIC-05.md

@@ -0,0 +1,68 @@
+# LIC-05 – Speicherverbrauch-Metrik je Tenant
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Leichtgewichtiger Zähler je Tenant für belegten Speicherplatz. Die Objekt-Storage-Treiber der Module (DMS `FDN-03`, Mail `ARC-01`) melden bei jedem Schreib- und Löschvorgang die Objektgröße; dieser Zähler wird entsprechend inkrementiert oder dekrementiert. `LIC-03` (Nutzungszähler & Quotas) fragt diesen Zähler ab, um Speicherplatz-Quotas durchzusetzen.
+
+**Technische Grundlage:** PostgreSQL, atomare Inkrement-/Dekrement-Operation
+
+## Produkt-DNA für diesen Bereich
+> Features werden pro Mandant zentral geschaltet, nicht durch verstreute Konfigurationsflags im Code.
+
+**Übernehmen:**
+- Unleash: Feature-Flag-Service mit Strategien (An/Aus, Prozentsatz, Tenant-Ziel) statt Compile-Time-Flags.
+- Unleash: Klare API-Trennung zwischen Flag-Verwaltung (Admin) und Flag-Auswertung (SDK/Client).
+- Zitadel: Projekt-/Grant-Modell als Vorbild für modulare Lizenz-Freischaltung pro Mandant.
+
+**Bewusst vermeiden:**
+- Unleash – Voller Betrieb erfordert eigene Infrastruktur (Unleash-Server + eigene DB) als weiteren Dienst.: Zähler als schlanke Funktion des Core-Dienstes selbst, keine zusätzliche Infrastruktur.
+- Keycloak – kein natives Lizenzmodell, wird in der Praxis oft über zweckentfremdete Client-Scopes nachgebildet.: Lizenz/Feature-Flag als eigenständiges, sauber modelliertes Konzept statt Zweckentfremdung von Rollen.
+
+**Für genau diese Kachel:** Eine Quota ohne Messgrundlage ist nur eine Konfigurationsoption ohne Wirkung – der Zähler macht Speicher-Limits erst durchsetzbar.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `LIC-01` Lizenzmodell & Lizenzschlüssel-Prüfung – Lizenzmodell je Tenant (Plan, Laufzeit, Modul-Umfang) sowie Prüfung signierter Lizenzschlüssel gegen den Tenant-Datensatz.
+
+Setzt voraus (externe Meldung durch DMS-Board `FDN-03` Objekt-Storage-Abstraktion und Mail-Board `ARC-01` Objekt-Speicher-Anbindung, siehe /home/sysops/Dokumente/Scripte/nexarch/dms-kanban/ bzw. /home/sysops/Dokumente/Scripte/nexarch/mail-kanban/).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Zähler pro Tenant wird bei jedem Schreib-/Löschvorgang im Objekt-Storage korrekt aktualisiert, unabhängig davon welches Modul den Vorgang auslöst
+2. Inkrement/Dekrement ist atomar, keine Race-Condition bei parallelen Schreibvorgängen
+3. LIC-03 kann den aktuellen Verbrauch je Tenant jederzeit abfragen, ohne den Objekt-Storage selbst zu scannen
+
+## 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. Paralleler Schreib-Test (viele gleichzeitige Uploads) ergibt korrekten Endstand ohne verlorene Updates
+2. Löschvorgang dekrementiert korrekt
+3. Abfrage über LIC-03 liefert konsistenten Wert mit einer unabhängigen Kontrollzählung
+
+## Bekannte Fehler vermeiden
+Ohne diesen Zähler bleibt eine Speicherplatz-Quota in LIC-03 nur eine Konfigurationsoption ohne Datengrundlage – das wurde erst nachträglich beim Zusammenführen des Storage-Konzepts bemerkt, nicht von Anfang an mitgeplant. Größenmeldung muss von Anfang an Teil jedes Storage-Schreibpfads sein, nicht nachträglich in bestehenden Code eingefügt werden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `LIC-01` Lizenzmodell & Lizenzschlüssel-Prüfung
+- `LIC-03` Nutzungszähler & Quotas
+
+## 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: `LIC-05: speicherverbrauch-metrik-je-tenant`
+- Branch: `feature/lic-05-speicherverbrauch-metrik-je-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.

core-kanban/tickets/LIC-06.md

@@ -0,0 +1,59 @@
+# LIC-06 – Fail-Closed-Verhalten der Lizenz-/Feature-Flag-Prüfung bei Registry-Ausfall
+
+**Epic:** 🎫 Lizenzierung & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+LIC-01/LIC-02 prüfen Lizenz und Feature-Flags gegen die Registry mit In-Prozess-Cache, ohne explizit festzulegen, wie sich die Prüfung bei einem Ausfall der Registry-Datenbank oder einem Cache-Invalidierungssturm verhält. Verbindliches Fail-Closed-Verhalten für die Lizenzprüfung festlegen und implementieren: ist weder Cache noch Registry erreichbar, wird der Zugriff verweigert statt stillschweigend erlaubt; für reine Feature-Flags (nicht lizenzrelevant) ist ein definiertes, dokumentiertes Fallback-Verhalten (letzter bekannter Cache-Stand mit Ablaufzeit) zulässig.
+
+**Technische Grundlage:** PostgreSQL, In-Prozess-Cache, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Unleash: klare, dokumentierte Fallback-Strategie bei Nichterreichbarkeit des Flag-Dienstes.
+
+**Bewusst vermeiden:**
+- Unleash – bei manchen Client-SDKs unklares Verhalten bei Verbindungsverlust (teils Fail-Open).: für lizenzrelevante Prüfungen ausdrücklich Fail-Closed, nicht implizit Fail-Open.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: LIC-01, LIC-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ist bei einer Lizenzprüfung weder der In-Prozess-Cache noch die Registry erreichbar, wird der Zugriff verweigert (Fail-Closed), nicht stillschweigend erlaubt
+2. Für reine Feature-Flag-Abfragen (nicht lizenzrelevant) ist das Fallback-Verhalten dokumentiert und über einen Ablaufzeitpunkt des letzten Cache-Stands begrenzt
+3. Ein Cache-Invalidierungssturm bei Massenänderung führt nicht zu kurzzeitig falsch erteilten Lizenz-Freigaben
+
+## 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: Registry-Datenbank simuliert nicht erreichbar, Cache leer/abgelaufen — Lizenzprüfung verweigert Zugriff
+2. Test: Massenänderung an Feature-Flags gleichzeitig mit vielen Anfragen — keine falsch-positive Freigabe während der Invalidierung
+3. Regressionstest: normaler Betrieb mit erreichbarer Registry bleibt unverändert
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): ohne festgelegtes Fail-Closed-Verhalten könnte ein Registry-Ausfall oder Cache-Sturm zu impliziten Fail-Open-Zuständen führen und Lizenzprüfungen wirkungslos machen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `LIC-01` Lizenzmodell & Lizenzschlüssel-Prüfung
+- `LIC-02` Feature-Flag-Service je Tenant
+
+## 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: `LIC-06: fail-closed-verhalten-der-lizenz-feature-flag-pr-fung-bei-registry-ausfall`
+- Branch: `feature/lic-06-fail-closed-verhalten-der-lizenz-feature-flag-pr-fung-bei-registry-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.

core-kanban/tickets/LIC-07.md

@@ -0,0 +1,61 @@
+# LIC-07 – Absicherung der Verwaltungs-Devserver (Lizenz, Feature-Flags, Mandanten)
+
+**Epic:** 🔑 Lizenz & Feature Flags  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+`licadmin-devserver` schaltet Feature-Flags und listet Lizenzen ohne Authentifizierung, `tenantadmin-devserver` bestimmt den Superadmin über einen Parameter; beide lassen CORS `*` zu (Befunde F-02, F-03). Sie erhalten Dienst-Token, Loopback-Standard und eine explizite CORS-Ursprungsliste. Die Verwaltungsoberflächen greifen über einen serverseitigen Proxy zu, damit kein Token im Browser liegt.
+
+**Technische Grundlage:** `internal/svcauth` (Require, CORS, Protect), `cmd/licadmin-devserver`, `cmd/tenantadmin-devserver`, `web/lic-admin`, `web/tenant-admin` (Route `app/api/proxy`)
+
+## Produkt-DNA für diesen Bereich
+> Interne Endpunkte sind nie „nur intern“: ohne Authentifizierung, Grenzen und Zeitlimits ist jeder erreichbare Port eine Angriffsfläche.
+
+**Übernehmen:**
+- Das Modul-Aktivierungs-Flag ist seit RBAC-10 sicherheitsrelevant; nur berechtigte Aufrufer dürfen es umschalten.
+
+**Bewusst vermeiden:**
+- Kein CORS-Platzhalter `*` und kein Token im Browser.
+- Keine Identität aus einem frei wählbaren Parameter.
+
+## 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-02 und F-03 (kritisch).
+- `LIC-04`/`TEN-05` Verwaltungs-APIs und Oberflächen.
+- `RBAC-10` Modulaktivierung über das Flag `dms`.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Admin-Pfade beider Dienste verlangen das Dienst-Token; ohne Token 401 (auch wenn eine bekannte `superadmin`-Kennung übergeben wird)
+2. CORS nur für explizit konfigurierte Ursprünge (`NEXARCH_LICADMIN_CORS_ORIGINS`, `NEXARCH_TENANTADMIN_CORS_ORIGINS`), nie `*`; Preflight funktioniert ohne Token; Standard-Bind Loopback; Start nur mit Token
+3. Die Oberflächen `web/lic-admin` und `web/tenant-admin` erreichen das Backend über den serverseitigen Proxy (nur `/admin/*`, Token aus der Server-Umgebung); Typprüfung und Build sind grün
+
+## 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 je Pfad: ohne Token, mit `superadmin`-Parameter ohne Token, mit Token; fremder Ursprung erhält keine CORS-Freigabe
+2. Start ohne Token bricht ab; `*` in der Ursprungsliste bricht ab
+3. `tsc --noEmit` und `next build` in beiden Oberflächen grün; Proxy weist andere Pfade als `/admin/*` und Pfadsprünge ab
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Sitzungsbasierte Superadmin-Anmeldung in den Oberflächen (bis dahin nur für Berechtigte erreichbar: Loopback oder Reverse Proxy mit Anmeldung)
+- `auditlog-devserver` (Token in der URL, Befund F-09)
+
+## 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: `LIC-07: absicherung der verwaltungs-devserver`
+- Branch: `feature/qa-15-phase2a-sicherheitsbehebung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-01.md

@@ -0,0 +1,63 @@
+# OPS-01 – Health-Check-Endpunkte je Modul
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Health-/Readiness-Endpunkte für den Core-Dienst und je registriertes Modul, die echte Abhängigkeiten (DB, Queue) statt nur den Prozessstatus prüfen.
+
+**Technische Grundlage:** Go, PostgreSQL-Ping, Job-Queue-Status
+
+## Produkt-DNA für diesen Bereich
+> Sichtbarkeit ist Pflicht, nicht Kür – jedes Modul liefert Status und Kennzahlen.
+
+**Übernehmen:**
+- Prometheus/Grafana: Offenes Pull-Modell für Metriken, ein `/metrics`-Endpunkt je Modul.
+- Prometheus/Grafana: Dashboards und Health-Checks als deklarative Konfiguration, nicht als Handarbeit.
+- Zitadel: Eingebaute Health-/Readiness-Endpunkte als Vorbild für Betriebsreife ab Tag eins.
+
+**Bewusst vermeiden:**
+- Keycloak – Monitoring erfordert zusätzliche Exporter/Agenten, die separat gepflegt werden müssen.: Metriken-Endpunkt direkt im Core-Dienst, kein Zusatz-Agent nötig.
+- Allgemein verbreitetes Muster – Health-Checks prüfen nur „Prozess läuft“ statt echte Abhängigkeiten (DB, Queue).: Health-Checks prüfen echte Abhängigkeiten je Modul.
+
+**Für genau diese Kachel:** Health-Checks prüfen echte Abhängigkeiten wie bei Prometheus-Exportern üblich, nicht nur den nackten Prozessstatus.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-02` Modul-Registry & Aktivierungsprüfung – Registry, in der sich Fachmodule (DMS, Mail, weitere) mit Metadaten registrieren, gekoppelt an die Aktivierungsprüfung aus Feature-Flags/Lizenz.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Health-Endpunkt meldet den tatsächlichen Zustand von Datenbank und Job-Queue, nicht nur "Prozess läuft"
+2. Readiness- und Liveness-Zustand sind getrennt abfragbar
+3. Ausfall einer Abhängigkeit (z. B. Datenbank) wird im Health-Status sichtbar, bevor Nutzeranfragen fehlschlagen
+
+## 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. Simulierter Datenbankausfall führt zu einem korrekt gemeldeten "nicht bereit"-Zustand (automatisierter Test)
+2. Health-Endpunkt antwortet auch unter Last innerhalb definierter Zeit
+3. Readiness- und Liveness-Antwort unterscheiden sich nachweislich in mindestens einem Fehlerfall
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `OPS-02` Zentrale Statusseite
+- `OPS-03` Metrics-Aggregation über Module hinweg
+
+## 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: `OPS-01: health-check-endpunkte-je-modul`
+- Branch: `feature/ops-01-health-check-endpunkte-je-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.

core-kanban/tickets/OPS-02.md

@@ -0,0 +1,62 @@
+# OPS-02 – Zentrale Statusseite
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Öffentliche/interne Statusseite, die den Health-Zustand aller Module aggregiert darstellt, inklusive Verlauf vergangener Vorfälle.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Sichtbarkeit ist Pflicht, nicht Kür – jedes Modul liefert Status und Kennzahlen.
+
+**Übernehmen:**
+- Prometheus/Grafana: Offenes Pull-Modell für Metriken, ein `/metrics`-Endpunkt je Modul.
+- Prometheus/Grafana: Dashboards und Health-Checks als deklarative Konfiguration, nicht als Handarbeit.
+- Zitadel: Eingebaute Health-/Readiness-Endpunkte als Vorbild für Betriebsreife ab Tag eins.
+
+**Bewusst vermeiden:**
+- Keycloak – Monitoring erfordert zusätzliche Exporter/Agenten, die separat gepflegt werden müssen.: Metriken-Endpunkt direkt im Core-Dienst, kein Zusatz-Agent nötig.
+- Allgemein verbreitetes Muster – Health-Checks prüfen nur „Prozess läuft“ statt echte Abhängigkeiten (DB, Queue).: Health-Checks prüfen echte Abhängigkeiten je Modul.
+
+**Für genau diese Kachel:** Statusseite im Geiste von Grafana-Dashboards – klare Aggregation vieler Health-Quellen an einem Ort.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `OPS-01` Health-Check-Endpunkte je Modul – Health-/Readiness-Endpunkte für den Core-Dienst und je registriertes Modul, die echte Abhängigkeiten (DB, Queue) statt nur den Prozessstatus prüfen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Statusseite zeigt den aktuellen Zustand aller registrierten Module auf einen Blick
+2. Ausfall eines einzelnen Moduls wird deutlich hervorgehoben, ohne die gesamte Seite unbrauchbar zu machen
+3. Verlauf vergangener Statusänderungen ist einsehbar
+
+## 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. Simulierter Ausfall eines Moduls wird auf der Statusseite innerhalb der dokumentierten Abfragefrequenz sichtbar
+2. Seite bleibt bedienbar, auch wenn ein Modul nicht antwortet (kein Totalausfall der Seite)
+3. Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen
+
+## 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: `OPS-02: zentrale-statusseite`
+- Branch: `feature/ops-02-zentrale-statusseite`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-03.md

@@ -0,0 +1,62 @@
+# OPS-03 – Metrics-Aggregation über Module hinweg
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentraler Metrics-Endpunkt im Prometheus-Textformat, der Kennzahlen des Core-Dienstes und aggregierte Kennzahlen der registrierten Module bereitstellt.
+
+**Technische Grundlage:** Prometheus-Textformat, Go, /metrics-Endpunkt
+
+## Produkt-DNA für diesen Bereich
+> Sichtbarkeit ist Pflicht, nicht Kür – jedes Modul liefert Status und Kennzahlen.
+
+**Übernehmen:**
+- Prometheus/Grafana: Offenes Pull-Modell für Metriken, ein `/metrics`-Endpunkt je Modul.
+- Prometheus/Grafana: Dashboards und Health-Checks als deklarative Konfiguration, nicht als Handarbeit.
+- Zitadel: Eingebaute Health-/Readiness-Endpunkte als Vorbild für Betriebsreife ab Tag eins.
+
+**Bewusst vermeiden:**
+- Keycloak – Monitoring erfordert zusätzliche Exporter/Agenten, die separat gepflegt werden müssen.: Metriken-Endpunkt direkt im Core-Dienst, kein Zusatz-Agent nötig.
+- Allgemein verbreitetes Muster – Health-Checks prüfen nur „Prozess läuft“ statt echte Abhängigkeiten (DB, Queue).: Health-Checks prüfen echte Abhängigkeiten je Modul.
+
+**Für genau diese Kachel:** Offenes Pull-Modell exakt nach Prometheus-Vorbild – ein Endpunkt, keine proprietäre Push-Integration.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `OPS-01` Health-Check-Endpunkte je Modul – Health-/Readiness-Endpunkte für den Core-Dienst und je registriertes Modul, die echte Abhängigkeiten (DB, Queue) statt nur den Prozessstatus prüfen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Core-Dienst liefert unter /metrics Kennzahlen im Prometheus-Textformat
+2. Kennzahlen registrierter Module werden eingesammelt und unter klar benannten Metrik-Namen aggregiert
+3. Metrik-Namenskonvention ist dokumentiert und modulübergreifend konsistent
+
+## 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. Metrics-Endpunkt liefert unter Last innerhalb definierter Zeit eine Antwort
+2. Neu registriertes Modul erscheint ohne Codeänderung des Core-Dienstes in der Metrik-Aggregation
+3. Metrik-Ausgabe erfolgreich gegen einen echten Prometheus-Scrape-Vorgang geprüft
+
+## 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: `OPS-03: metrics-aggregation-ueber-module-hinweg`
+- Branch: `feature/ops-03-metrics-aggregation-ueber-module-hinweg`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-04.md

@@ -0,0 +1,63 @@
+# OPS-04 – Incident-Response-Plan (inkl. DSGVO-Meldefristen)
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Dokumentierter Ablaufplan für Sicherheitsvorfälle – Erkennung, Eskalation, Kommunikation, DSGVO-Meldefrist (72 Stunden an Aufsichtsbehörde bei meldepflichtigem Vorfall), Verantwortlichkeiten, Nachbereitung. Kein neues Software-Feature, sondern ein Betriebsdokument plus die technischen Anknüpfungspunkte (welche Logs/Audit-Daten im Vorfall herangezogen werden, siehe Core AUD-01).
+
+**Technische Grundlage:** Betriebsdokument, Eskalationsprozess, Audit-Log-Anknüpfung
+
+## Produkt-DNA für diesen Bereich
+> Sichtbarkeit ist Pflicht, nicht Kür – jedes Modul liefert Status und Kennzahlen.
+
+**Übernehmen:**
+- Prometheus/Grafana: Offenes Pull-Modell für Metriken, ein `/metrics`-Endpunkt je Modul.
+- Prometheus/Grafana: Dashboards und Health-Checks als deklarative Konfiguration, nicht als Handarbeit.
+- Zitadel: Eingebaute Health-/Readiness-Endpunkte als Vorbild für Betriebsreife ab Tag eins.
+
+**Bewusst vermeiden:**
+- Keycloak – Monitoring erfordert zusätzliche Exporter/Agenten, die separat gepflegt werden müssen.: Metriken-Endpunkt direkt im Core-Dienst, kein Zusatz-Agent nötig.
+- Allgemein verbreitetes Muster – Health-Checks prüfen nur „Prozess läuft“ statt echte Abhängigkeiten (DB, Queue).: Health-Checks prüfen echte Abhängigkeiten je Modul.
+
+**Für genau diese Kachel:** Sichtbarkeit im Betrieb (Health-Checks, Statusseite, Metrics) ist die eine Hälfte von Betriebsreife – die andere Hälfte ist ein Plan für den Ernstfall, wenn Sichtbarkeit allein nicht reicht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `OPS-01` Health-Check-Endpunkte je Modul – Health-/Readiness-Endpunkte für den Core-Dienst und je registriertes Modul, die echte Abhängigkeiten (DB, Queue) statt nur den Prozessstatus prüfen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ablaufplan dokumentiert Erkennung/Eskalation/Meldefristen/Verantwortlichkeiten
+2. DSGVO-72-Stunden-Meldefrist ist als Prozessschritt mit Verantwortlichem hinterlegt
+3. Plan verweist konkret auf die Audit-Log-Quellen (Core AUD-01/AUD-05), die im Vorfall herangezogen werden
+
+## 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. Simulierte Vorfallsübung (Tabletop) einmal durchgespielt und dokumentiert
+2. Meldefrist-Prozess auf Vollständigkeit geprüft
+3. Kontaktliste/Eskalationskette aktuell und erreichbar bestätigt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Audit-Log-Aufbewahrung selbst (`AUD-01`/`AUD-05`)
+- Externer Penetrationstest (`QA-06`)
+
+## 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: `OPS-04: incident-response-plan-inkl-dsgvo-meldefristen`
+- Branch: `feature/ops-04-incident-response-plan-inkl-dsgvo-meldefristen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-05.md

@@ -0,0 +1,65 @@
+# OPS-05 – Alerting bei Schwellwert-Überschreitung
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Schwellwert-basierte Alarmierung auf den aus OPS-03 aggregierten Metriken (z.B. Fehlerrate, Job-Queue-Länge, Speicherverbrauch nahe Quota, Postgres-Verbindungsauslastung) – Benachrichtigung über den Core-Benachrichtigungs-Dispatcher (CFG-02) an Verantwortliche, koppelt direkt an den Incident-Response-Plan (OPS-04): Alerting ist der technische Auslöser, der Plan ist der Ablauf danach.
+
+**Technische Grundlage:** Schwellwert-Regeln als Konfiguration, CFG-02-Benachrichtigungs-Dispatcher, Drosselung/Debouncing
+
+## Produkt-DNA für diesen Bereich
+> Sichtbarkeit ist Pflicht, nicht Kür – jedes Modul liefert Status und Kennzahlen.
+
+**Übernehmen:**
+- Prometheus/Grafana: Alertmanager-Konzept – Schwellwert-Regeln, Eskalationsgruppen, Stummschaltung.
+
+**Bewusst vermeiden:**
+- Grafanas volle Alerting-UI-Komplexität – Regeln als einfache Konfiguration, nicht als eigenes Regelsprachen-Subsystem.
+
+**Für genau diese Kachel:** Der Alertmanager-Gedanke von Prometheus/Grafana, aber auf das Nötigste reduziert – Schwellwert, Ziel, Drosselung, keine eigene Ausdruckssprache.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `OPS-03` Metrics-Aggregation über Module hinweg – Zentraler Metrics-Endpunkt im Prometheus-Textformat, der Kennzahlen des Core-Dienstes und aggregierte Kennzahlen der registrierten Module bereitstellt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Schwellwert-Regeln auf beliebigen aggregierten Metriken definierbar
+2. Überschreitung löst eine Benachrichtigung über CFG-02 aus, mit klarer Zuordnung welche Metrik/welcher Tenant/welches Modul betroffen ist
+3. Wiederholte Alarmierung für denselben anhaltenden Zustand ist gedrosselt (kein Alarm-Spam bei dauerhaft überschrittenem Wert)
+
+## 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: Metrik überschreitet konfigurierten Schwellwert, Benachrichtigung wird ausgelöst
+2. Benachrichtigungsinhalt im Test auf Vollständigkeit (Metrik/Tenant/Modul) geprüft
+3. Test: anhaltende Überschreitung erzeugt nicht bei jeder Messung eine neue Benachrichtigung
+
+## Bekannte Fehler vermeiden
+
+- Metriken sammeln und anzeigen ohne aktives Alerting bedeutet: ein Problem wird erst bemerkt, wenn jemand zufällig hinschaut. Der Incident-Response-Plan (OPS-04) braucht einen technischen Auslöser, sonst bleibt er Theorie.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `OPS-04` Incident-Response-Plan – der Ablauf nach ausgelöstem Alarm
+- `CFG-02` Benachrichtigungs-Dispatcher selbst
+- `OPS-03` Metrics-Aggregation selbst
+
+## 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: `OPS-05: alerting-bei-schwellwert-ueberschreitung`
+- Branch: `feature/ops-05-alerting-bei-schwellwert-ueberschreitung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-06.md

@@ -0,0 +1,52 @@
+# OPS-06 – Automatisiertes Schwachstellen-Scanning (Supply-Chain)
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Automatisiertes Schwachstellen-Scanning für Go-Module (govulncheck) und npm-Pakete (npm audit/Dependabot) als wiederkehrender CI-Schritt über alle sieben Boards – ergänzt die reine Lint-/Test-/Build-Pipeline jedes Boards um Supply-Chain-Sicherheit, statt Abhängigkeiten ungeprüft zu vertrauen.
+
+**Technische Grundlage:** govulncheck (Go-Module), npm audit/Dependabot (Frontend-Pakete), CI-Gate
+
+## Produkt-DNA für diesen Bereich
+> Abhängigkeiten sind eine Angriffsfläche wie eigener Code – ungeprüfte Third-Party-Pakete sind keine Ausnahme von der Sicherheitsprüfung, nur weil sie nicht selbst geschrieben wurden.
+
+**Übernehmen:**
+- known-issues-archivdms.md Punkt 1 zeigt ein reales Problem in diesem Bereich (fehlendes go.sum) – die Lehre daraus wird hier zur verbindlichen Regel.
+
+**Bewusst vermeiden:**
+- Keine manuelle, unregelmäßige Prüfung – automatisiert bei jedem CI-Lauf, nicht nur gelegentlich.
+
+**Für genau diese Kachel:** Ohne dieses Ticket bleibt Supply-Chain-Sicherheit eine gute Absicht ohne technische Durchsetzung – SICHERHEITSKONZEPT.md Abschnitt 11 Punkt 2 benennt genau diese Lücke.
+
+## Ausgangslage
+Diese Kachel hat keine internen Vorbedingungen außer der bereits fertigen Monitoring-Grundlage (OPS-01) und ist sofort startbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. govulncheck läuft als verbindlicher CI-Schritt gegen alle Go-Module aller sieben Boards
+2. npm audit (oder Dependabot-Äquivalent) läuft als verbindlicher CI-Schritt gegen alle Next.js-Frontends
+3. Ein Fund mit kritischem/hohem Schweregrad blockiert den Merge, statt nur eine Warnung zu erzeugen
+
+## 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. Absichtlich veraltete, verwundbare Testabhängigkeit wird vom CI-Lauf erkannt und blockiert den Merge
+2. Scan-Ergebnis ist als CI-Artefakt/Log nachvollziehbar abgelegt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Die eigentlichen CI-Pipelines je Board (Lint/Test/Build) – diese Kachel ergänzt sie nur um den Scan-Schritt, ersetzt sie nicht.
+
+## 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.

core-kanban/tickets/OPS-07.md

@@ -0,0 +1,58 @@
+# OPS-07 – Betriebs-Gate: mTLS-Aktivierungspflicht beim Wechsel auf verteilten Betrieb
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+API-09 macht mTLS zwischen Modul-Instanzen für Stufe-2/3-Installationen (siehe SKALIERUNGSKONZEPT.md) verfügbar, aber für Stufe-1-Einzel-LXC optional. Ohne expliziten Gate-Mechanismus kann beim späteren Wechsel von Stufe 1 auf Stufe 2 (verteilter Betrieb) vergessen werden, mTLS zu aktivieren — Modul-zu-Modul-Aufrufe liefen dann nur mit Service-Credential ohne Transport-Auth. Einen Readiness-Check ergänzen, der bei mehr als einer Instanz/Host erkennt, dass mTLS zwischen Modulen (noch) nicht aktiv ist, und dies als Warnung im Monitoring (OPS) sichtbar macht, sowie einen Eintrag in der Betriebs-Checkliste für den Stufenwechsel.
+
+**Technische Grundlage:** Betriebsdokument, Health-/Readiness-Check, mTLS (API-09)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Prometheus/Grafana: Health-/Readiness-Checks als deklarative, beobachtbare Konfiguration statt Handarbeit.
+
+**Bewusst vermeiden:**
+- Keycloak – produktionsrelevante Sicherheitseinstellungen bleiben ohne aktive Warnung leicht unbemerkt deaktiviert.: fehlendes mTLS bei verteiltem Betrieb erzeugt eine aktive, sichtbare Warnung statt stillschweigend zu bleiben.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: API-09.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Wird mehr als eine Modul-Instanz/mehr als ein Host erkannt und ist mTLS zwischen Modulen nicht aktiv, erscheint eine Warnung im Monitoring (OPS)
+2. Betriebs-Checkliste für den Wechsel Stufe 1 → Stufe 2 (SKALIERUNGSKONZEPT.md) enthält mTLS-Aktivierung als Pflichtschritt
+3. Bei aktivem mTLS und/oder Einzel-LXC-Betrieb erscheint keine Warnung
+
+## 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. Simulierter Mehr-Instanz-Betrieb ohne mTLS: Warnung erscheint im Monitoring
+2. Simulierter Mehr-Instanz-Betrieb mit aktivem mTLS: keine Warnung
+3. Prüft, dass die Betriebs-Checkliste den mTLS-Schritt beim Stufenwechsel enthält
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): mTLS ist für Stufe 1 bewusst optional — ohne Gate-Mechanismus besteht das Risiko, die Aktivierung beim späteren Wechsel auf verteilten Betrieb schlicht zu vergessen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-09` mTLS zwischen Modul-Instanzen (verteilte Installation)
+
+## 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: `OPS-07: betriebs-gate-mtls-aktivierungspflicht-beim-wechsel-auf-verteilten-betrieb`
+- Branch: `feature/ops-07-betriebs-gate-mtls-aktivierungspflicht-beim-wechsel-auf-verteilten-betrieb`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-08.md

@@ -0,0 +1,59 @@
+# OPS-08 – Systemd-Härtung und getrennte Datenbankrollen je Dienst
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Betrieb  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Betrieb und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Betrieb, Bereitstellung und Härtung. Änderungen bleiben nachvollziehbar und rückbaubar.
+
+## Auftrag
+Von 40 Systemd-Vorlagen enthält eine Sandbox-Direktiven, und `deploy/install.sh` verwendet eine Rolle mit `CREATEDB` als Mandanten-DSN aller Dienste (Befund F-15); `soffice` und `pdftoppm` laufen ohne Sandbox (Befund F-13, zweiter Teil). Alle Vorlagen erhalten `NoNewPrivileges`, `ProtectSystem`, `PrivateTmp`, `ProtectHome` u. a., Dienste nutzen getrennte Rollen ohne `CREATEDB`.
+
+**Technische Grundlage:** `deploy/` (Systemd-Vorlagen, `install.sh`), Datenbankrollen je Dienst und Mandant
+
+## Produkt-DNA für diesen Bereich
+> Ein kompromittierter Dienst erreicht nur, was er braucht.
+
+**Übernehmen:**
+- Vorlage `nexarch-archive-restoretest` als Muster.
+
+**Bewusst vermeiden:**
+- Keine Rolle mit `CREATEDB` im Betrieb der Dienste.
+
+## 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-15 (mittel), F-13 Sandbox.
+- `FDN-12` Port-Register, `DEPLOYMENT-131-CHECKLISTE.md`.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Vorlagen tragen die vereinbarten Sandbox-Direktiven; ein Prüfskript belegt es
+2. Dienste laufen mit getrennten Datenbankrollen; Anlegen von Mandanten-Datenbanken geschieht nur durch die Verwaltungsrolle
+3. Externe Prozesse (`soffice`, `pdftoppm`, `tesseract`) laufen mit Ressourcen- und Dateisystemgrenzen
+
+## 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. Start aller Dienste auf dem Entwicklungshost mit Härtung
+2. Gesamtsystem-Smoke (FDN-19) grün
+3. Rückbau- und Rollout-Beschreibung
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Container-Betrieb
+
+## 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: teilweise umgesetzt (Phase 2d, PR gegen `integration/gesamtprojekt`, Branch `feature/ops-08-09-10-haertungsbuendel-betrieb`): 18 von 40 Vorlagen (reine Netzwerkdienste) gehärtet und auf 204 echt unter Sandbox gestartet, `scripts/check-systemd-hardening.sh` belegt es. Offen: die übrigen 22 `Type=oneshot`-Vorlagen (Backup/Restore/Objectbackup/Reconcile/Scrub/Tenantbackup, brauchen je Dienst korrekte `ReadWritePaths`), F-15 (getrennte DB-Rollen, `install.sh`-Umbau) und die Sandbox der externen Prozesse (`soffice`/`pdftoppm`/`tesseract`) — alle drei bleiben aus denselben Gründen offen wie ursprünglich vermerkt (Betrieb auf 131, Freigabe für Diensteänderungen nötig). Details: `docs/QA-15-PHASE2D-PRUEFPROTOKOLL.md`.
+- Commit-Nachricht: `OPS-08: systemd-haertung und getrennte datenbankrollen`
+- Branch: `feature/ops-08-systemd-haertung-rollen` (umgesetzter Teil liegt auf `feature/ops-08-09-10-haertungsbuendel-betrieb`)
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-09.md

@@ -0,0 +1,59 @@
+# OPS-09 – Abhängigkeiten und Go-Toolchains angleichen
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Betrieb  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Betrieb und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Betrieb, Bereitstellung und Härtung. Änderungen bleiben nachvollziehbar und rückbaubar.
+
+## Auftrag
+Core und Mail nutzen `pgx v5.6.0` (DMS v5.9.2), Core `golang.org/x/crypto v0.17.0`, Mail `golang.org/x/text v0.14.0`, Archive `go 1.22` (Ende der Unterstützung), Mail `go 1.24`; der Host 131 baut mit Go 1.24.4 (Befund F-18). Versionen werden angehoben, eine einheitliche Go-Version festgelegt und die Build-Toolchain gepinnt.
+
+**Technische Grundlage:** `go.mod` je Modul, `GOTOOLCHAIN`, Bau auf 131/204
+
+## Produkt-DNA für diesen Bereich
+> Bekannte Fehler in Abhängigkeiten werden nicht mitgeschleppt.
+
+**Übernehmen:**
+- DMS-Versionsstand als Ausgangspunkt.
+
+**Bewusst vermeiden:**
+- Kein unbedachtes Anheben, das andere Branches mit Konflikten überzieht.
+
+## 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-18 (mittel).
+- `QA-02` Abhängigkeits-Update im DMS.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Module bauen mit derselben Go-Hauptversion; `pgx`, `x/crypto` und `x/text` liegen auf gepatchten Ständen
+2. Die Toolchain ist per `toolchain`-Direktive gepinnt und auf 131 und 204 verfügbar
+3. `govulncheck` (Binärmodus) meldet keine betroffene Schwachstelle
+
+## 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. Build, Vet und Tests aller Module
+2. Gesamtsystem-Smoke
+3. Rollout auf 131 dokumentiert (Go-Version dort ist 1.24.4)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Next.js-Migration (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: umgesetzt (Phase 2d, PR gegen `integration/gesamtprojekt`, Branch `feature/ops-08-09-10-haertungsbuendel-betrieb`): Core, Mail und Archive auf go1.25.0/toolchain go1.25.13, `pgx` v5.9.2, `x/crypto` v0.54.0, `x/text` v0.41.0 angehoben (DMS-Stand als Zielversion, DMS selbst unverändert). Build/Vet/Tests aller vier Module auf 204 grün geprüft, dabei ein echter Testreihenfolge-Fehler in `internal/e2e` gefunden und behoben (siehe Protokoll). `govulncheck` weiterhin nicht auf 204 verfügbar (nicht installiert). Offen bleibt nur AC2/Prüfung 3: das eigentliche Rollout auf Host 131 (dort läuft noch Go 1.24.4) — das ist ein separater Betriebsschritt, hier nur dokumentiert. Details: `docs/QA-15-PHASE2D-PRUEFPROTOKOLL.md`.
+- Commit-Nachricht: `OPS-09: abhaengigkeiten und go-toolchains angleichen`
+- Branch: `feature/ops-09-abhaengigkeiten-toolchains` (umgesetzter Teil liegt auf `feature/ops-08-09-10-haertungsbuendel-betrieb`)
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-10.md

@@ -0,0 +1,59 @@
+# OPS-10 – Härtungsbündel: AAD bei AES-GCM, Webhook-Ziele, Standardadressen, Schlüsselhierarchie
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Betrieb  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Betrieb und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Betrieb, Bereitstellung und Härtung. Änderungen bleiben nachvollziehbar und rückbaubar.
+
+## Auftrag
+Bündel der niedrigen Befunde: (F-21) AES-GCM ohne Additional Authenticated Data in DMS, Archive, Mail und Core-KEK; (F-22) `internal/webhook` prüft die Ziel-URL nicht und speichert das Signaturgeheimnis im Klartext; (F-24) uneinheitliche Standardadressen (`:8600`, `:8080`, `:8081`, `:8082` gegenüber `127.0.0.1`); (F-25) Modul-Signaturschlüssel mit einem einzelnen statischen Schlüssel ohne Hierarchie und Neuverpackung.
+
+**Technische Grundlage:** `*/internal/crypto/envelope.go`, `internal/kek/master.go`, `internal/webhook`, `cmd/*`, `internal/moduletrust/persist.go`
+
+## Produkt-DNA für diesen Bereich
+> Kleine Schwächen summieren sich; sie werden gebündelt und mit Migrationsplan behoben.
+
+**Übernehmen:**
+- Envelope-Verschlüsselung aus FDN-09.
+
+**Bewusst vermeiden:**
+- Kein Formatwechsel ohne Migration bestehender Daten.
+
+## 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-21, F-22, F-24, F-25 (niedrig).
+- `API-10` Master-Key-Verwaltung, `API-16`.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neue Verpackungen binden Datensatzkennung als AAD; Bestand wird lesbar migriert (Versionsmarker)
+2. Webhook-Ziele werden wie Archive-Rückrufe geprüft (RET-14), Signaturgeheimnisse verschlüsselt
+3. Alle Dienste binden standardmäßig an `127.0.0.1`; Abweichungen sind dokumentiert; Modul-Schlüsselverschlüsselung erlaubt Neuverpackung bei Schlüsselwechsel
+
+## 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. Migrationstest mit Bestandsdaten (alt und neu lesbar)
+2. Tests zu Ziel-URLs und Geheimnissen
+3. Portregister und Adress-Skripte grün
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Neue Kryptoverfahren
+
+## 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: teilweise umgesetzt (Phase 2d, PR gegen `integration/gesamtprojekt`, Branch `feature/ops-08-09-10-haertungsbuendel-betrieb`): F-22 (SSRF-Prüfung Webhook-Ziele + verschlüsseltes Signaturgeheimnis) und F-25 (Neuverpackung der Modul-Signaturschlüssel, `-rewrap-module-keys`) vollständig umgesetzt und real auf 204 verifiziert, F-24 (einheitliche Lauschadressen `127.0.0.1`) vollständig umgesetzt. F-21 (AAD bei AES-GCM) bewusst zurückgestellt — Begründung und Folgeticket-Empfehlung im Protokoll: zu großer, riskanter Eingriff (~26 Aufrufstellen allein im DMS) für „niedrig" eingestuften Befund in dieser Zeitbox. Details: `docs/QA-15-PHASE2D-PRUEFPROTOKOLL.md`.
+- Commit-Nachricht: `OPS-10: haertungsbuendel niedrige befunde`
+- Branch: `feature/ops-10-haertungsbuendel` (umgesetzter Teil liegt auf `feature/ops-08-09-10-haertungsbuendel-betrieb`)
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-11.md

@@ -0,0 +1,59 @@
+# OPS-11 – Next.js-Migration auf 16.x (alle Web-Apps)
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Betrieb, Bereitstellung und Härtung. Änderungen bleiben nachvollziehbar und rückbaubar.
+
+## Auftrag
+Alle 13 Web-Apps (`web/account`, `web/audit-log`, `web/dms-browser`, `web/dms-upload`, `web/kennzahlen-dashboard`, `web/lic-admin`, `web/mail-search`, `web/notifications`, `web/pdf-viewer`, `web/rbac-admin`, `web/retention-admin`, `web/status-page`, `web/tenant-admin`) nutzen `next@14.2.35` ohne aktuelle Sicherheitsupdates (Befund F-17). Anhebung auf `next@16.x` (Nutzerentscheidung 2026-09-22, statt 15.5.x).
+
+**Technische Grundlage:** `web/*/package.json`, React 19, Next.js 16 Upgrade-Anleitung
+
+## Produkt-DNA für diesen Bereich
+> Bekannte Fehler in Abhängigkeiten werden nicht mitgeschleppt.
+
+**Übernehmen:**
+- Offizielle Next.js-Upgrade-Anleitung und Codemods statt manueller Rateversuche.
+
+**Bewusst vermeiden:**
+- Keine funktionalen Änderungen über das Upgrade hinaus.
+
+## 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-17 (mittel).
+- `UX-10` Anmeldung und Bearer-Token in den Oberflächen (Sitzungsmodul in `@nexarch/shl`).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle 13 Web-Apps bauen mit `next@16.x` und React 19
+2. Keine funktionale Regression: bestehende Testsuiten je App bestehen unverändert
+3. Bekannte Next.js-16-Breaking-Changes sind berücksichtigt (asynchrone Request-APIs, Config-Schema, Middleware)
+
+## 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. `tsc` und `next build` je App
+2. Vitest-Suiten je App
+3. Browserlauf/Barrierefreiheitsprüfung im Token-Modus (falls Chrome verfügbar, sonst als offen ausweisen)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Go-Abhängigkeiten/Toolchains (OPS-09)
+- Neue Frontend-Funktionalität
+
+## 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: `OPS-11: next.js-migration auf 16.x`
+- Branch: `feature/qa-15-f17-nextjs-16-upgrade`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-12.md

@@ -0,0 +1,36 @@
+# OPS-12 – Systemd-Härtung und Datenbank-Rollentrennung (F-15)
+
+**Epic:** ⚙️ Betrieb & Deployment  |  **Rolle:** DevOps  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene DevOps-Ingenieurin und härtest den NEXARCH-Betrieb (Deployment, systemd, Datenbankrollen) gemäß den Befunden der Sicherheitsprüfung QA-15.
+
+## Auftrag
+QA-15-Befund F-15: Von 40 systemd-Vorlagen (`deploy/systemd/`) enthält nur eine (`nexarch-archive-restoretest`) Sandbox-Direktiven (`NoNewPrivileges`, `ProtectSystem`, `PrivateTmp`, `ProtectHome`). `deploy/install.sh` (Zeilen 59-73, 124-126) verwendet für den Mandanten-DSN-Template aller Dienste eine Rolle mit `CREATEDB`-Recht: ein kompromittierter Dienst erreicht potenziell alle Mandantendatenbanken. Fix: Sandbox-Direktiven auf alle relevanten Vorlagen ausweiten, getrennte, minimal-privilegierte Datenbankrollen je Dienst/Mandant statt einer gemeinsamen `CREATEDB`-Rolle.
+
+**Technische Grundlage:** systemd Unit-Direktiven (`NoNewPrivileges`, `ProtectSystem=strict`, `PrivateTmp`, `ProtectHome`, `ReadOnlyPaths`/`ReadWritePaths` wo zutreffend), Postgres-Rollen mit minimalen Rechten statt einer geteilten `CREATEDB`-Rolle.
+
+## Ausgangslage
+Alle `deploy/systemd/*.service.tmpl`-Vorlagen dieser Session (inkl. der neu in dieser Session entstandenen: `nexarch-connect-app`, `nexarch-dms-app`, `nexarch-dms-worker`). `deploy/install.sh` für die Rollenvergabe.
+
+## Akzeptanzkriterien
+1. Alle systemd-Vorlagen (nicht nur `nexarch-archive-restoretest`) enthalten die etablierten Sandbox-Direktiven, soweit der jeweilige Dienst dadurch nicht in seiner Funktion eingeschränkt wird (Ausnahmen einzeln begründet dokumentieren, nicht stillschweigend auslassen)
+2. Die für `CREATE DATABASE` genutzte Rolle ist von den Rollen getrennt, mit denen Dienste zur Laufzeit auf ihre eigene Mandanten-DB zugreifen — kein Dienst hat zur Laufzeit `CREATEDB`-Recht
+3. Bestehende Dienste starten nach der Härtung unverändert erfolgreich (keine Regression durch zu restriktive Sandbox)
+
+## Prüfungen vor der Abnahme
+1. Für jede gehärtete Vorlage: Dienst startet real erfolgreich auf Host 204 mit den neuen Direktiven
+2. Ein Testdienst mit der eingeschränkten Laufzeit-Rolle versucht real `CREATE DATABASE` auszuführen und wird abgelehnt
+3. Bestehende Gesamtsystem-Smoke-Tests (`gesamt-token-smoke.sh`) laufen nach der Härtung unverändert grün
+
+## Nicht Bestandteil dieser Kachel
+- F-16 bis F-25 (eigene Befunde, teils andere Tickets)
+- Rollout der gehärteten Konfiguration auf Host 131 (separater, späterer Schritt nach Freigabe)
+
+## Abschluss
+- Commit-Nachricht: `OPS-12: systemd haertung und db rollentrennung (F-15)`
+- Branch: `feature/ops-12-systemd-haertung-db-rollentrennung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/OPS-13.md

@@ -0,0 +1,36 @@
+# OPS-13 – Additional Authenticated Data bei AES-GCM-Verschlüsselung (F-21)
+
+**Epic:** ⚙️ Betrieb & Deployment  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Backend-Entwicklerin und härtest die bestehende Envelope-Verschlüsselung (KEK/DEK, AES-256-GCM) gemäß QA-15-Befund F-21.
+
+## Auftrag
+QA-15-Befund F-21: Kein Additional Authenticated Data (AAD) bei AES-GCM in `dms/internal/crypto/envelope.go` (Zeilen 52-56), `archive/internal/backupcrypto/envelope.go` (44-48), `mail/internal/crypto/envelope.go` (50-54), `internal/kek/master.go` (81-85). Ein Austausch verpackter Schlüssel zwischen Datensätzen wird dadurch nicht erkannt (setzt Schreibzugriff auf die Datenbank voraus, daher moderates Risiko). Fix: AAD ergänzen, das den verschlüsselten Wert an seinen Kontext bindet (z. B. Datensatz-ID/Mandant/Tabellenname), sodass ein Schlüsseltausch zwischen zwei Datensätzen beim Entschlüsseln auffällt statt still zu funktionieren.
+
+**Technische Grundlage:** AES-256-GCM mit AAD (`cipher.AEAD.Seal`/`Open` mit zusätzlichem `additionalData`-Parameter, in Go bereits Teil der Standard-API, keine neue Abhängigkeit).
+
+## Ausgangslage
+Vier betroffene Stellen in drei Modulen (DMS, Archive, Mail) plus Core `internal/kek/master.go`. Jede Stelle hat ihre eigene, unabhängige Kopie der Envelope-Verschlüsselung (etabliertes Muster dieser Session: keine geteilten `internal/`-Pakete über Modulgrenzen).
+
+## Akzeptanzkriterien
+1. Alle vier betroffenen Verschlüsselungsstellen binden ein AAD an den verschlüsselten Wert, das dessen Kontext eindeutig identifiziert
+2. Ein simulierter Schlüssel-/Chiffretext-Austausch zwischen zwei Datensätzen wird beim Entschlüsseln erkannt und abgelehnt (nicht mehr wie vorher: stillschweigend erfolgreich)
+3. Bestehende, bereits verschlüsselte Datensätze bleiben lesbar (Migration/Rückwärtskompatibilität berücksichtigt, kein Datenverlust)
+
+## Prüfungen vor der Abnahme
+1. Für jede der vier Stellen: ein echter Test, der Chiffretext/Schlüssel zwischen zwei Datensätzen vertauscht und beweist, dass die Entschlüsselung jetzt fehlschlägt (vorher: stillschweigend erfolgreich)
+2. Ein bereits vor dieser Änderung verschlüsselter Testdatensatz (ohne AAD) lässt sich weiterhin korrekt entschlüsseln, sofern das Kompatibilitätskonzept das vorsieht — sonst explizit dokumentieren, dass ein Neuverschlüsseln nötig ist
+3. Bestehende Verschlüsselungs-/Entschlüsselungstests aller vier Module laufen unverändert grün (keine Regression)
+
+## Nicht Bestandteil dieser Kachel
+- F-15, F-16 bis F-25 außer F-21 selbst (eigene Befunde, teils andere Tickets)
+- Grundlegender Wechsel des Verschlüsselungsschemas (AES-256-GCM bleibt, nur AAD ergänzt)
+
+## Abschluss
+- Commit-Nachricht: `OPS-13: additional authenticated data bei aes-gcm (F-21)`
+- Branch: `feature/ops-13-aad-aes-gcm`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-01.md

@@ -0,0 +1,65 @@
+# QA-01 – Teststrategie Core
+
+**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 Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Verbindliche Teststrategie für NEXARCH Core festlegen: Testpyramide, Pflichttests für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, Testdatenbank-Strategie.
+
+**Technische Grundlage:** Go testing, Testcontainer/PostgreSQL, CI-Gate
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Testpflicht als Grundsatz, der so in archivdms/archivmail fehlte – hier von der ersten Kachel an verbindlich.
+
+## Ausgangslage
+Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Teststrategie ist dokumentiert und definiert verbindliche Testpflichten je Bereich (Auth, Tenant-Scoping, Policy)
+2. CI-Gate verhindert das Mergen von Code ohne die geforderten Testarten
+3. Testdatenbank-Strategie (z. B. isolierte Testcontainer je Lauf) ist eingerichtet und dokumentiert
+
+## 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 mit absichtlich fehlendem Pflichttest schlägt kontrolliert fehl (Negativtest des Gates selbst)
+2. Testdatenbank-Isolation zwischen parallelen Testläufen automatisiert geprüft
+3. Dokumentation von zweiter Person gegengelesen und für verständlich befunden
+
+## Bekannte Fehler vermeiden
+
+- **Faktisch keine Tests für Auth/Tenant-Isolation in den Altsystemen**: archivdms hatte nur 2 `_test.go`-Dateien in ganz `internal/`, 0 für `auth`/`storage`/`permissions.go`; archivmail testete nur 2 von 18 Modulen. → In NEXARCH Core müssen Pflichttests für Login, Tenant-Scoping und Policy-Enforcement von Anfang an als Merge-Gate gelten, nicht als Nachrüstung.
+
+## 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: `QA-01: teststrategie-core`
+- Branch: `feature/qa-01-teststrategie-core`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-02.md

@@ -0,0 +1,72 @@
+# QA-02 – Prüfgate Identität & Mandanten
+
+**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 Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate, das Tenant-Verwaltung und Identitäts-/Login-Flows gemeinsam gegen die Akzeptanzkriterien der zugrundeliegenden Kacheln abnimmt, bevor sie als abgeschlossen gelten.
+
+**Technische Grundlage:** Manuelle und automatisierte Prüfliste
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Ein Gate schließt einen Ausbauabschnitt ab, statt Mängel unbemerkt weiterzureichen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-05` Tenant-Verwaltungsoberfläche – Administrationsoberfläche zur Übersicht, Anlage, Einstellung und Statusverwaltung von Mandanten für Superadmins.
+- `IAM-08` Benutzerprofil- & Login-Oberfläche – Login-Oberfläche inklusive 2FA-Eingabe, Passwort-Reset-Flow und Profilverwaltung (eigene Daten, Passwort ändern, 2FA einrichten).
+- `TEN-06` Connection-Routing & Pooling pro Mandant – Anhand von Tenant-Kontext (JWT-Claim) die richtige Tenant-Datenbank-Verbindung auflösen (Lookup in der Registry) und darüber eine Verbindung/Pool bereitstellen, ohne pro Tenant dauerhaft offene Verbindungen zu halten.
+- `TEN-07` Migrations-Orchestrierung über alle Tenant-Datenbanken – Automatisiertes, fehlerisoliertes Ausrollen neuer SQL-Migrationen gegen jede registrierte Tenant-Datenbank inklusive nachvollziehbarem Migrationsstand je Mandant.
+- `IAM-05` LDAP/Active-Directory-Anbindung – Anbindung an LDAP/Active Directory je Tenant für Benutzer-Synchronisation und Login-Delegation, inklusive Rollenzuordnung aus Gruppen.
+- `IAM-09` API-Token & Service-Accounts – Service-Accounts als eigenständige Identitäten sowie persönliche API-Token zur programmatischen Authentifizierung, mit Scopes und Ablaufzeit.
+- `IAM-10` Passwortlose Anmeldung via WebAuthn/Passkey – WebAuthn/Passkey als alternativer Anmeldefaktor zu Passwort+TOTP – Registrierung eines Authenticators (Plattform wie Windows Hello/Touch ID, oder externer Sicherheitsschlüssel) und Anmeldung ohne Passworteingabe.
+- `IAM-11` SAML 2.0-Anbindung – SAML 2.0 als zusätzlicher Anmeldeweg neben OIDC (IAM-06) – für Kunden, deren Identity Provider nur SAML spricht (viele Enterprise-/Behörden-Umgebungen).
+- `IAM-12` Aktive-Sitzungen-Verwaltung – Nutzer sieht seine eigenen aktiven Sitzungen (Gerät/Browser, IP, letzter Zugriff) und kann einzelne oder alle widerrufen (z. B. bei verlorenem Gerät).
+- `IAM-13` OIDC-Provider für Drittanwendungen – NEXARCH tritt selbst als OIDC/OAuth2-Identity-Provider auf (nicht nur als Konsument wie IAM-06), damit Drittanwendungen eines Kunden (z. B. eigene interne Tools, Connect-Board-Integrationen) sich gegen NEXARCH-Benutzerkonten authentifizieren können – Client-Registrierung, Authorization-Code-Flow, eigene JWKS-Ausgabe.
+- `IAM-14` Passwort-Richtlinien – Konfigurierbare Passwort-Komplexitätsanforderungen (Mindestlänge, Zeichenklassen, Sperrliste häufiger Passwörter) pro Tenant durchsetzbar – bisher regelt IAM-02 nur den bcrypt-Hashing-Mechanismus selbst, keine Anforderungen an das Passwort davor.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Akzeptanzkriterien von TEN-01 bis TEN-07 und IAM-01 bis IAM-14 sind gegengeprüft und dokumentiert
+2. End-to-End-Fluss "Mandant anlegen → Benutzer einladen → anmelden" ist einmal vollständig durchgespielt
+3. Gefundene Abweichungen sind als Tickets/Notizen festgehalten, nicht stillschweigend ignoriert
+
+## 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. End-to-End-Fluss von zweiter Person unabhängig nachvollzogen
+2. Cross-Tenant-Stichprobe (zwei Mandanten, zwei Benutzer) auf Datenlecks geprüft
+3. Prüfprotokoll mit Ergebnis je Kriterium liegt schriftlich vor
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Core
+
+## 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-identitaet-mandanten`
+- Branch: `feature/qa-02-pruefgate-identitaet-mandanten`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-03.md

@@ -0,0 +1,63 @@
+# QA-03 – Prüfgate Rechte & Policy
+
+**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 Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für das gesamte Rollen-/Rechte-/Policy-Enforcement-Paket (RBAC-01 bis RBAC-05) inklusive gezielter Versuche, die zentrale Durchsetzung zu umgehen.
+
+**Technische Grundlage:** Manuelle und automatisierte Prüfliste
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Gate stellt sicher, dass Casbin-artige zentrale Durchsetzung tatsächlich zentral bleibt und nicht umgangen wurde.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-05` Rechte-Administrationsoberfläche – Oberfläche zur Verwaltung von Rollen, Rechten, Gruppen und Zuweisungen für Tenant-Administratoren.
+- `RBAC-04` Modul-scoped Berechtigungen – Berechtigungen zusätzlich auf Modul-Ebene scopen, sodass Rechte nur innerhalb freigeschalteter Module wirksam werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Akzeptanzkriterien von RBAC-01 bis RBAC-05 sind gegengeprüft und dokumentiert
+2. Gezielte Umgehungsversuche der zentralen Policy-Schicht (z. B. direkter Repository-Zugriff) sind protokolliert erfolglos
+3. Modul-scoped Berechtigungen (RBAC-04) sind im Zusammenspiel mit Lizenz-/Flag-Zustand 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. Umgehungsversuch der zentralen Enforcement-Schicht von zweiter Person unabhängig nachgestellt und protokolliert
+2. Rollenwechsel-Szenario (Hoch- und Rückstufung) automatisiert und manuell geprüft
+3. Prüfprotokoll mit Ergebnis je Kriterium liegt schriftlich vor
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Core
+
+## 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-rechte-policy`
+- Branch: `feature/qa-03-pruefgate-rechte-policy`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-04.md

@@ -0,0 +1,72 @@
+# QA-04 – Sicherheits- & Penetrationsprüfung Core
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Gezielte Sicherheitsprüfung der sensibelsten Core-Bereiche: zentrale Policy-Durchsetzung, SSO/OIDC, Account-Lockout/Rate-Limiting und API-Gateway, inklusive expliziter Prüfung der bekannten Fehlerklassen aus den Altsystemen.
+
+**Technische Grundlage:** Manuelle Sicherheitsprüfung, ggf. automatisierte Scan-Tools
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Sicherheitsprüfung mit explizitem Fokus auf die aus archivdms/archivmail bekannten Fehlerklassen (Rate-Limiting, Rollenzuweisung, Tenant-Scoping).
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-02` Policy-Enforcement-Schicht (zentral) – Zentrale Policy-Entscheidungs- und Durchsetzungsschicht, die von jeder Query/Repository-Ebene angesprochen wird – keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern.
+- `IAM-06` SSO-Anmeldung über OIDC – SSO-Anmeldung über OpenID Connect gegen externe Identity-Provider inklusive Rollen-Mapping aus Claims und Fallback auf lokalen Login.
+- `IAM-07` Account-Lockout & Login-Rate-Limiting – Brute-Force-Schutz durch Account-Lockout nach definierten Fehlversuchen und Rate-Limiting des Login-Endpunkts mit geteiltem, externem State.
+- `API-03` Zentrales Rate-Limiting & API-Gateway-Schicht – Zentrale Rate-Limiting- und Gateway-Schicht für die gesamte Core-API mit geteiltem, externem Zustand über mehrere Instanzen hinweg.
+- `API-10` Master-Key-Verwaltung & Tenant-Schlüsselhierarchie (KMS-Anbindung) – Zweistufige Schlüsselhierarchie: EIN Master-Key (Root-KEK) in Core verpackt ausschließlich Tenant-Schlüssel (Tenant-KEK), niemals Objekte direkt. Jeder Tenant bekommt bei Provisionierung (TEN-01) einen eigenen Tenant-KEK. DMS/Mail beziehen für ihre pro-Objekt-DEKs nur den Tenant-KEK ihres Mandanten, authentifiziert über API-02-Service-Credential.
+- `API-08` Security-Header-Baseline für alle Frontends – Gemeinsame Security-Header-Middleware (CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options) als wiederverwendbare Konfiguration, die jedes Modul-Frontend (DMS, Mail, Workflow, AI, Connect) einbindet, statt sie pro Modul einzeln neu zu definieren.
+- `API-09` mTLS zwischen Modul-Instanzen (verteilte Installation) – Gegenseitige TLS-Authentifizierung zwischen Core/DMS/Mail/Archive/Workflow/AI/Connect-Instanzen für Stufe-2/3-Installationen (siehe SKALIERUNGSKONZEPT.md), damit Modul-zu-Modul-Kommunikation nicht nur durch Service-Credentials (API-02) sondern auch transportverschlüsselt und gegenseitig authentifiziert ist. Für Stufe-1-Einzel-LXC optional/nicht zwingend (lokale Kommunikation).
+- `IAM-10` Passwortlose Anmeldung via WebAuthn/Passkey – WebAuthn/Passkey als alternativer Anmeldefaktor zu Passwort+TOTP – Registrierung eines Authenticators (Plattform wie Windows Hello/Touch ID, oder externer Sicherheitsschlüssel) und Anmeldung ohne Passworteingabe.
+- `IAM-11` SAML 2.0-Anbindung – SAML 2.0 als zusätzlicher Anmeldeweg neben OIDC (IAM-06) – für Kunden, deren Identity Provider nur SAML spricht (viele Enterprise-/Behörden-Umgebungen).
+- `IAM-13` OIDC-Provider für Drittanwendungen – NEXARCH tritt selbst als OIDC/OAuth2-Identity-Provider auf (nicht nur als Konsument wie IAM-06), damit Drittanwendungen eines Kunden (z. B. eigene interne Tools, Connect-Board-Integrationen) sich gegen NEXARCH-Benutzerkonten authentifizieren können – Client-Registrierung, Authorization-Code-Flow, eigene JWKS-Ausgabe.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. SSO/OIDC-Flow ist gegen Token-Manipulation, Replay und Claims-Manipulation geprüft
+2. Rate-Limiting/Account-Lockout ist im Mehrinstanz-Betrieb nachweislich nicht umgehbar
+3. Zentrale Policy-Durchsetzung ist gegen mindestens einen gezielten Umgehungsversuch je Modul geprüft
+4. Master-Key- und Tenant-KEK-Verwaltung (API-10) ist gegen Schlüsselkompromittierung und Rotation 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. Mehrinstanz-Umgehungsversuch des Rate-Limitings protokolliert erfolglos
+2. Manipulierter OIDC-Token/Claim wird zuverlässig abgewiesen (protokolliert)
+3. Ergebnisse sind mit Schweregrad bewertet und mit Verweis auf betroffenes Ticket dokumentiert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Core
+
+## 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-penetrationspruefung-core`
+- Branch: `feature/qa-04-sicherheits-penetrationspruefung-core`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-05.md

@@ -0,0 +1,79 @@
+# QA-05 – Abnahme- & Compliance-Prüfung Core
+
+**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 Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Abschließende Abnahmeprüfung, die die Ergebnisse aller vorangegangenen Gates zusammenführt und die Compliance-Anforderungen (Audit-Log, Nachvollziehbarkeit, Datentrennung) gesamthaft bestätigt.
+
+**Technische Grundlage:** Manuelle Abnahmeprüfung, Compliance-Checkliste
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Abschließendes Gate im Sinne einer echten Compliance-Abnahme, nicht nur formaler Haken.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-02` Prüfgate Identität & Mandanten – Prüfgate, das Tenant-Verwaltung und Identitäts-/Login-Flows gemeinsam gegen die Akzeptanzkriterien der zugrundeliegenden Kacheln abnimmt, bevor sie als abgeschlossen gelten.
+- `QA-03` Prüfgate Rechte & Policy – Prüfgate für das gesamte Rollen-/Rechte-/Policy-Enforcement-Paket (RBAC-01 bis RBAC-05) inklusive gezielter Versuche, die zentrale Durchsetzung zu umgehen.
+- `QA-04` Sicherheits- & Penetrationsprüfung Core – Gezielte Sicherheitsprüfung der sensibelsten Core-Bereiche: zentrale Policy-Durchsetzung, SSO/OIDC, Account-Lockout/Rate-Limiting und API-Gateway, inklusive expliziter Prüfung der bekannten Fehlerklassen aus den Altsystemen.
+- `QA-07` Schnittstellen-Vertragstests – Vertragstests für die Core-APIs, die von DMS, Mail, Archive, Workflow, AI und Connect konsumiert werden (REST-Grundgerüst, JWKS/Rechte-Cache-Kontrakt, Modul-Registry, Webhook-Registry) – jede Breaking Change wird automatisiert erkannt, bevor sie ein konsumierendes Modul bricht.
+- `QA-08` Last- & Leistungstest – Lasttest für Core unter realistischer Last aus sechs gleichzeitig zugreifenden Fachmodulen – insbesondere JWKS-Verifikations-Pfad, Tenant-Connection-Pooling und Rate-Limiting unter Last.
+- `QA-09` Barrierefreiheits-Audit – Unabhängige Prüfung aller Core-Oberflächen (Tenant-Verwaltung, Login/Profil, Rechte-Administration, Lizenz-/Modul-Verwaltung, Audit-Log-Ansicht, Benachrichtigungs-Einstellungen, zentrale Statusseite) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.
+- `TEN-08` Tenant-Löschung unter Retention-Vorbehalt (GoBD) – Vor der endgültigen Tenant-Löschung (nach Ablauf der Karenzzeit aus TEN-04) wird geprüft, ob GoBD-relevante Daten des Tenants noch unter Aufbewahrungspflicht (10-Jahres-Frist) oder Legal Hold stehen. Solange eine Sperre besteht, wird die endgültige Löschung verweigert und der Tenant bleibt im Zustand "zur Löschung vorgemerkt, aber gesperrt".
+- `AUD-02` Unveränderliches Protokoll (Append-only) – Audit-Log technisch gegen nachträgliche Änderung und Löschung absichern (append-only), inklusive Vier-Augen-Prinzip für sicherheitskritische Entscheidungen im Umfeld des Audit-Logs.
+- `API-04` OpenAPI-Schnittstellenbeschreibung – Vollständige OpenAPI-Beschreibung der Core-API, automatisiert aus dem Code generiert oder gegen den Code geprüft, als Vertrag für Frontend und Drittintegrationen.
+- `OPS-03` Metrics-Aggregation über Module hinweg – Zentraler Metrics-Endpunkt im Prometheus-Textformat, der Kennzahlen des Core-Dienstes und aggregierte Kennzahlen der registrierten Module bereitstellt.
+- `API-06` Wiederanlauf & Nachsynchronisierung nach Core-Ausfall – Nach Core-Ausfall: sofortiger Cache-Refresh bei erkannter Wiedererreichbarkeit (Health-Check-getriggert, nicht TTL-Ablauf abwarten), lokal gepufferte Audit-Events und Nutzungszähler-Inkremente werden über das in API-02 definierte Service-Credential authentifiziert an Core nachgeliefert (gleiches Postgres-Queue-Muster wie der Rest des Projekts – lokale Pufferung, kein Datenverlust).
+- `AUD-05` Audit-Log-Registrierung bei Archive-Retention-Engine – Audit-Log-Eintrag als Objekttyp bei der Archive-Retention-Engine registrieren (über den Modul-Adapter aus Archive RET-05), Default-Aufbewahrungsfrist von 10 Jahren (GoBD-Buchungsbeleg-Frist) für Audit-Log-Einträge konfigurieren. Core implementiert dafür keine eigene Löschlogik – Fristverwaltung und tatsächliche Löschung/Aufbewahrungssperre laufen vollständig über Archive.
+- `API-07` Zentrale Webhook-Registry & Zustellung – Modulübergreifende Webhook-Registry: Module (DMS/Mail/Archive/Workflow/AI) registrieren Ereignistypen, externe Abonnenten registrieren Ziel-URLs. Zustellung mit Retry/Backoff über die bestehende Postgres-Jobqueue-Architektur (kein Redis/AMQP). Payloads werden HMAC-signiert, damit der Empfänger die Authentizität prüfen kann.
+- `LIC-05` Speicherverbrauch-Metrik je Tenant – Leichtgewichtiger Zähler je Tenant für belegten Speicherplatz. Objekt-Storage-Treiber der Module (DMS FDN-03, Mail ARC-01) melden bei jedem Schreib-/Löschvorgang die Objektgröße; LIC-03 fragt diesen Zähler zur Durchsetzung von Speicherplatz-Quotas ab.
+- `OPS-04` Incident-Response-Plan (inkl. DSGVO-Meldefristen) – Dokumentierter Ablaufplan für Sicherheitsvorfälle – Erkennung, Eskalation, Kommunikation, DSGVO-Meldefrist (72 Stunden an Aufsichtsbehörde bei meldepflichtigem Vorfall), Verantwortlichkeiten, Nachbereitung. Kein neues Software-Feature, sondern ein Betriebsdokument plus die technischen Anknüpfungspunkte (welche Logs/Audit-Daten im Vorfall herangezogen werden, siehe Core AUD-01).
+- `OPS-05` Alerting bei Schwellwert-Überschreitung – Schwellwert-basierte Alarmierung auf den aus OPS-03 aggregierten Metriken (z.B. Fehlerrate, Job-Queue-Länge, Speicherverbrauch nahe Quota, Postgres-Verbindungsauslastung) – Benachrichtigung über den Core-Benachrichtigungs-Dispatcher (CFG-02) an Verantwortliche, koppelt direkt an den Incident-Response-Plan (OPS-04): Alerting ist der technische Auslöser, der Plan ist der Ablauf danach.
+- `OPS-06` Automatisiertes Schwachstellen-Scanning (Supply-Chain) – Automatisiertes Schwachstellen-Scanning für Go-Module (govulncheck) und npm-Pakete (npm audit/Dependabot) als wiederkehrender CI-Schritt über alle sieben Boards – ergänzt die reine Lint-/Test-/Build-Pipeline jedes Boards um Supply-Chain-Sicherheit, statt Abhängigkeiten ungeprüft zu vertrauen.
+- `IAM-15` Timing-safe Vergleich als projektweite Coding-Konvention – Verbindliche, dokumentierte Coding-Konvention: jeder Vergleich, der eine sicherheitsrelevante Zugriffsentscheidung trifft (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nutzt einen timing-safe/constant-time Vergleich – nicht nur an einer Stelle vorgemacht, sondern als projektweite Regel wie das bereits bestehende Sprintf-Verbot für SQL.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Ergebnisse aller vorgelagerten Prüfgates (QA-02, QA-03, QA-04, QA-07, QA-08, QA-09) liegen konsolidiert vor und sind widerspruchsfrei
+2. Audit-Log deckt alle sicherheitsrelevanten Vorgänge aus den geprüften Bereichen nachweislich ab
+3. Offene Punkte aus den Vorgänger-Gates sind entweder behoben oder bewusst mit Begründung zurückgestellt
+
+## 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. Stichprobenartiger Abgleich Audit-Log gegen tatsächlich durchgeführte Testaktionen ohne Lücken
+2. Konsolidiertes Abnahmeprotokoll von zweiter Person gegengelesen
+3. Freigabeentscheidung ist schriftlich mit Datum und Verantwortlicher festgehalten
+
+## 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: `QA-05: abnahme-compliance-pruefung-core`
+- Branch: `feature/qa-05-abnahme-compliance-pruefung-core`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-06.md

@@ -0,0 +1,64 @@
+# QA-06 – Externe Sicherheitsprüfung / Penetrationstest vor Produktivbetrieb
+
+**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 Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Projektweiter, externer Penetrationstest über alle sieben Boards (Core/DMS/Mail/Archive/Workflow/AI/Connect) vor dem ersten Produktivbetrieb – ergänzt die internen Sicherheits-Prüfgates der einzelnen Boards (z.B. Core QA-04), die Entwicklerprüfungen sind, kein externer Test.
+
+**Technische Grundlage:** Externer Penetrationstest, Findings-Nachverfolgung
+
+## Produkt-DNA für diesen Bereich
+> Tests für Auth, Tenant-Isolation und Policy-Enforcement sind Pflicht, nicht Kür – das war in den Altsystemen der größte Schwachpunkt.
+
+**Übernehmen:**
+- archivdms/archivmail (Lehre daraus): Testpflicht für Auth/Tenant-Scoping/Policy-Enforcement als Merge-Gate, weil genau das in beiden Altsystemen fehlte.
+- Casbin: Policy-Entscheidungen sind isoliert testbar (Modell + Regeln + Testfälle).
+- Zitadel: Umfangreiche Integrationstests für Identitäts-/Rechteflüsse als Vorbild für Testtiefe.
+
+**Bewusst vermeiden:**
+- archivdms/archivmail – faktisch keine Tests für Auth/Tenant-Isolation, Lücken erst im Betrieb entdeckt.: Pflichttests für Login, Tenant-Scoping, Policy-Enforcement vor jedem Merge.
+- Keycloak – Testabdeckung der Public-API teils dünn, Verhalten nur durch Ausprobieren ermittelbar.: Jede Kern-API-Änderung mit automatisiertem Vertragstest.
+
+**Für genau diese Kachel:** Das letzte Gate vor Produktivbetrieb, unabhängig von den internen Prüfgates der einzelnen Boards – eine externe Partei findet, was das eigene Team im eigenen Blindfleck übersieht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-05` Abnahme- & Compliance-Prüfung Core – Abschließende Abnahmeprüfung, die die Ergebnisse aller vorangegangenen Gates zusammenführt und die Compliance-Anforderungen (Audit-Log, Nachvollziehbarkeit, Datentrennung) gesamthaft bestätigt.
+- `QA-07` Schnittstellen-Vertragstests – Vertragstests für die Core-APIs, die von DMS, Mail, Archive, Workflow, AI und Connect konsumiert werden (REST-Grundgerüst, JWKS/Rechte-Cache-Kontrakt, Modul-Registry, Webhook-Registry) – jede Breaking Change wird automatisiert erkannt, bevor sie ein konsumierendes Modul bricht.
+- `QA-08` Last- & Leistungstest – Lasttest für Core unter realistischer Last aus sechs gleichzeitig zugreifenden Fachmodulen – insbesondere JWKS-Verifikations-Pfad, Tenant-Connection-Pooling und Rate-Limiting unter Last.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Penetrationstest durch unabhängige externe Partei durchgeführt, nicht durch das Entwicklungsteam selbst
+2. Kritische/hohe Befunde vor Produktivbetrieb behoben, nicht nur dokumentiert
+3. Ergebnis und Behebung sind nachvollziehbar dokumentiert (Audit-fähig)
+
+## 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. Testbericht liegt vor
+2. Nachtest bestätigt Behebung kritischer Befunde
+3. Freigabe für Produktivbetrieb ist an dieses Ergebnis gekoppelt, nicht unabhängig davon erteilt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Interne Sicherheits-Prüfgates der einzelnen Boards (z. B. Core `QA-04`) – die bleiben Entwicklerprüfungen
+
+## 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: externe-sicherheitspruefung-penetrationstest-vor-produktivbetrieb`
+- Branch: `feature/qa-06-externe-sicherheitspruefung-penetrationstest-vor-produktivbetrieb`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/QA-07.md

@@ -0,0 +1,65 @@
+# QA-07 – Schnittstellen-Vertragstests
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vertragstests für die Core-APIs, die von DMS, Mail, Archive, Workflow, AI und Connect konsumiert werden (REST-Grundgerüst API-01, JWKS/Rechte-Cache-Kontrakt API-05, Modul-Registry API-02, Webhook-Registry API-07) – jede Breaking Change an diesen Schnittstellen muss automatisiert erkannt werden, bevor sie ein konsumierendes Modul bricht.
+
+**Technische Grundlage:** Vertragstests, CI-Pipeline
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Referenzkorpus, an dem Erkennungs- und Extraktionsgüte wiederholbar gemessen werden.
+- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+
+**Für genau diese Kachel:** Core ist das Fundament, auf dem sechs andere Boards aufbauen – hier wird jede der sechs konsumierten Schnittstellen gegen ihre eigene Beschreibung geprüft.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-01` REST-API-Grundgerüst & Versionierung – Grundgerüst der Core-REST-API mit einheitlicher Fehlerbehandlung, Versionierung im URL-Pfad und Middleware-Kette (Auth, Tenant-Kontext, Logging).
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt – Öffentlichen Schlüssel für die JWT-Signaturprüfung modulübergreifend verteilen (JWKS-Endpunkt) und einen Rechte-/Feature-Flag-Cache-Kontrakt definieren, damit DMS/Mail/Archive/Workflow JWTs lokal verifizieren können, ohne pro Aufruf einen synchronen Request an Core zu stellen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vertragstests decken alle sechs von Fachmodulen konsumierten Core-Schnittstellen ab
+2. Ein absichtlich brechender Schema-Wechsel lässt die Vertragstests fehlschlagen
+3. Vertragstests laufen automatisiert in der CI, nicht nur manuell
+
+## 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. Testlauf gegen aktuellen Core-API-Stand grün
+2. Simulierte Breaking Change (z.B. Feld entfernt) lässt mindestens einen Vertragstest fehlschlagen
+3. CI-Integration nachgewiesen
+
+## Bekannte Fehler vermeiden
+
+Core ist das Fundament, auf dem sechs andere Boards aufbauen – ohne Vertragstests würde eine Core-API-Änderung erst beim jeweils konsumierenden Modul auffallen, nicht an der Quelle.
+
+## 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: `QA-07: schnittstellen-vertragstests`
+- Branch: `feature/qa-07-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.

core-kanban/tickets/QA-08.md

@@ -0,0 +1,61 @@
+# QA-08 – Last- & Leistungstest
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Lasttest für Core unter realistischer Last aus sechs gleichzeitig zugreifenden Fachmodulen – insbesondere JWKS-Verifikations-Pfad (API-05), Tenant-Connection-Pooling (TEN-06) und Rate-Limiting (API-03) unter Last.
+
+**Technische Grundlage:** Lastgenerator, Messprotokoll
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Referenzkorpus, an dem Erkennungs- und Extraktionsgüte wiederholbar gemessen werden.
+- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+
+**Für genau diese Kachel:** Realistische Mehrmodul-Last simulieren, nicht nur eine einzelne Instanz im Leerlauf messen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-05` Verteilte JWT-Verifikation & Rechte-/Feature-Flag-Cache-Kontrakt – Öffentlichen Schlüssel für die JWT-Signaturprüfung modulübergreifend verteilen (JWKS-Endpunkt) und einen Rechte-/Feature-Flag-Cache-Kontrakt definieren, damit DMS/Mail/Archive/Workflow JWTs lokal verifizieren können, ohne pro Aufruf einen synchronen Request an Core zu stellen.
+- `TEN-06` Connection-Routing & Pooling pro Mandant – Anhand von Tenant-Kontext (JWT-Claim) die richtige Tenant-Datenbank-Verbindung auflösen und darüber eine Verbindung/Pool bereitstellen, ohne pro Tenant dauerhaft offene Verbindungen zu halten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Definierte Ziel-Latenz für JWT-Verifikation unter Last eingehalten
+2. Connection-Pooling bleibt unter der Postgres-Verbindungsobergrenze bei simulierter Vielzahl an Mandanten
+3. Rate-Limiting funktioniert korrekt unter Mehrinstanz-Last, nicht nur im Einzelinstanz-Test
+
+## 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 mit simulierten parallelen Anfragen aus mehreren Modulen durchgeführt, Ergebnis dokumentiert
+2. Verbindungszahl bei vielen simulierten Mandanten-Datenbanken gemessen
+3. Rate-Limit-Verhalten bei mehreren Core-Instanzen gleichzeitig geprüft
+
+## 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: `QA-08: last-leistungstest`
+- Branch: `feature/qa-08-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.

core-kanban/tickets/QA-09.md

@@ -0,0 +1,64 @@
+# QA-09 – Barrierefreiheits-Audit
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** QA  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Unabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.
+
+## Auftrag
+Unabhängige Prüfung aller Core-Oberflächen (Tenant-Verwaltung, Login/Profil, Rechte-Administration, Lizenz-/Modul-Verwaltung, Audit-Log-Ansicht, Benachrichtigungs-Einstellungen, zentrale Statusseite) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.
+
+**Technische Grundlage:** Prüfwerkzeuge, Bildschirmleser
+
+## Produkt-DNA für diesen Bereich
+> Barrierefreiheit ist Grundeigenschaft der Core-SHL-01-Basis, keine Nachrüstung je Modul – dieses Audit prüft, ob Core sie tatsächlich geerbt statt umgangen hat.
+
+**Übernehmen:**
+- Core SHL-01: WCAG 2.1 AA als verbindliche Eigenschaft der Basis-Komponenten.
+
+**Bewusst vermeiden:**
+- Kein eigenes, modulspezifisches Barrierefreiheits-Konzept parallel zu SHL-01.
+
+**Für genau diese Kachel:** Ohne dieses Audit bleibt offen, ob Core-Oberflächen die von SHL-01 geerbten WCAG-Eigenschaften tatsächlich nutzen oder lokal umgehen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TEN-05` Tenant-Verwaltungsoberfläche – Administrationsoberfläche zur Übersicht, Anlage, Einstellung und Statusverwaltung von Mandanten für Superadmins.
+- `IAM-08` Benutzerprofil- & Login-Oberfläche – Login-Oberfläche inklusive 2FA-Eingabe, Passwort-Reset-Flow und Profilverwaltung (eigene Daten, Passwort ändern, 2FA einrichten).
+- `RBAC-05` Rechte-Administrationsoberfläche – Oberfläche zur Verwaltung von Rollen, Rechten, Gruppen und Zuweisungen für Tenant-Administratoren.
+- `LIC-04` Lizenz-/Modul-Verwaltungsoberfläche – Oberfläche zur Übersicht von Lizenzstatus, aktivierten Modulen, Feature-Flags und aktuellem Nutzungsstand je Tenant.
+- `AUD-04` Audit-Log-Ansicht – Oberfläche zur Durchsuchung und Darstellung des Audit-Logs für berechtigte Administratoren, inklusive Exportfunktion.
+- `CFG-04` Benachrichtigungs-Einstellungen-Oberfläche – Oberfläche für Benutzer und Tenant-Admins zur Verwaltung eigener Benachrichtigungspräferenzen je Kanal und Ereignistyp.
+- `OPS-02` Zentrale Statusseite – Öffentliche/interne Statusseite, die den Health-Zustand aller Module aggregiert darstellt, inklusive Verlauf vergangener Vorfälle.
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System – liefert die WCAG-2.1-AA-Basis-Komponenten, gegen die alle oben genannten Oberflächen geprüft werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Keine kritischen Verstöße offen
+2. Manueller Bildschirmleser-Durchlauf dokumentiert
+3. Restbefunde sind mit Frist eingeplant
+
+## 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. Automatisierte Prüfung über alle Hauptseiten
+2. Vollständiger Ablauf ohne Maus durchgeführt
+3. Auditbericht abgelegt
+
+## Bekannte Fehler vermeiden
+WCAG war ursprünglich nur in DMS und Mail als eigene Kachel geplant – Core hätte ungeprüft geblieben, obwohl die Oberflächen dieselbe Core-SHL-01-Basis nutzen. Audit deshalb als eigene Kachel je Board, analog DMS QA-11 und Mail QA-08.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Core `SHL-01` WCAG-Basis-Komponenten selbst (diese Kachel prüft nur die Nutzung).
+- Behebung gefundener Verstöße in den jeweiligen Frontend-Kacheln.
+
+## 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.

core-kanban/tickets/QA-14.md

@@ -0,0 +1,71 @@
+# QA-14 – Testisolation Core und Mail
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** QA  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich QA und baust NEXARCH Core und die angebundenen Module (Mail, Archive, DMS), die sich auf einer gemeinsamen Testinfrastruktur prüfen lassen müssen.
+Prüfung und Nachweis. Ergebnis sind stabile, parallel lauffähige Integrationstests und ein abgelegtes Messprotokoll.
+
+## Auftrag
+Integrationstests in Core und Mail so isolieren, dass `go test ./...` ohne `-p 1` stabil läuft: eigenes Schema je Test statt geteilter Tabellen im `public`-Schema, eindeutige Datenbanknamen, Lastmessungen nur im seriellen Lauf. Analog zu FDN-16 im DMS.
+
+**Technische Grundlage:** je Modul ein Testhilfspaket `internal/testdb` (Schema je Test, `search_path = Schema, public`), Umgebungsvariablen `TEST_ADMIN_DSN` (Core) und `TEST_TENANT_DSN` (Mail).
+
+## Produkt-DNA für diesen Bereich
+> Ein Test, der nur seriell besteht, prüft nicht das Produkt, sondern die Reihenfolge der Testläufe.
+
+**Übernehmen:**
+- FDN-16 (DMS): Schema je Test, `search_path = Schema, public`, Aufräumen per `t.Cleanup`.
+- QA-01: Isolation zwischen parallelen Testläufen automatisiert nachweisen.
+
+**Bewusst vermeiden:**
+- Handgeschriebene `CREATE TABLE IF NOT EXISTS`-Schemas in einer gemeinsamen Datenbank: sie veralten unbemerkt und beeinflussen andere Pakete.
+- Ein `-p 1`, das Zufallsfehler nur verdeckt statt ihre Ursache zu beseitigen.
+- Lockern von Zielwerten, um Lastmessungen im parallelen Lauf zu bestehen.
+
+**Für genau diese Kachel:** Die Ursache jedes Fehlers im Gesamtlauf klären und beheben, nicht maskieren.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden:
+- `QA-01` Teststrategie Core – Testdatenbank-Strategie und Reset-Skripte.
+- `FDN-16` (DMS-Board) – Vorbild für die Schema-Isolation je Test.
+- Befunde aus `docs/GESAMTPROJEKT-PRUEFPROTOKOLL.md`: Core-Tests beeinflussen sich über gemeinsame Registry-Tabellen, Mail `indexworker` scheitert im Gesamtlauf mit veralteter `mail_index_jobs`-Tabelle, Lastmessungen scheitern im parallelen Lauf.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Integrationstests in Core und Mail nutzen je Test ein eigenes Schema (Mehrinstanz-Tests ein gemeinsames Schema über mehrere Pools) und eindeutig benannte Datenbanken; keine geteilten Tabellen im `public`-Schema
+2. `go test ./...` ohne `-p 1` besteht in Core und Mail mehrfach hintereinander sowie mit `-shuffle=on`, ohne Ausfall
+3. Latenz- und Lastmessungen laufen nur im seriellen Lauf (`TEST_PERF=1 go test -p 1`), die Zielwerte bleiben unverändert; bekannte Wettläufe in Tests sind an der Ursache behoben
+
+## 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. Core und Mail je dreimal `go test -count=1 ./...` ohne `-p 1` auf frischer Testdatenbank ohne Ausfall
+2. Je ein Lauf mit `-shuffle=on` ohne Ausfall
+3. Serieller Lastlauf (`TEST_PERF=1 -p 1`) besteht mit unveränderten Zielwerten; automatisierter Isolationstest der Hilfspakete (zwei Pools, gleicher Tabellenname, kein gegenseitiges Sehen; Aufräumen entfernt das Schema)
+
+## Bekannte Fehler vermeiden
+
+- **Geteilter Zustand über `public`**: Der `search_path`-Fallback auf `public` lässt ein `TRUNCATE`/`DROP` im Test fremde Tabellen treffen. → Schema je Test, Tabellen dort anlegen.
+- **Zwei Pools, ein Schema**: Tests, die zwei Dienstinstanzen simulieren, brauchen beide Pools auf demselben Schema. → `testdb.Sibling`/`testdb.Open`.
+- **Feste Namen**: Feste Datenbank- und Rollennamen kollidieren zwischen parallelen Paketen. → eindeutiger Suffix.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Isolation der Archive-Tests (gleiches Muster, eigenes Ticket)
+- Umbau der CI-Pipeline auf paralleles `go test ./...`
+
+## 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-14: testisolation core und mail`
+- Branch: `feature/qa-14-testisolation-core-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.

core-kanban/tickets/QA-15.md

@@ -0,0 +1,57 @@
+# QA-15 – Sicherheitsprüfung Gesamtprojekt
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** QA  |  **Komplexität:** Komplex  |  **Aufwand:** 5 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich QA und Anwendungssicherheit und prüfst NEXARCH als Gesamtprojekt (Core, DMS, Archive, Mail), das Stärken von paperless-ngx, Alfresco, Docspell und ecoDMS vereinen und deren Schwächen vermeiden soll.
+Prüfung und Nachweis. Ergebnis ist ein abgelegtes Protokoll mit Befunden, Schweregrad, Ausnutzbarkeit und konkretem Fix-Vorschlag.
+
+## Auftrag
+Systematische, modulübergreifende Sicherheitsprüfung des Integrationsstands `integration/gesamtprojekt` nach OWASP Top 10, OWASP ASVS und CWE. Phase 1 (dieses Ticket): Analyse und Befundbericht. Phase 2 (Behebung) wird je Befund als eigenes Ticket geschnitten.
+
+**Technische Grundlage:** statische Code-Analyse, Routeninventur je Modul, Abhängigkeits- und Toolchain-Abgleich gegen Primärquellen, Konfigurations- und Betriebsprüfung.
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Beleg gelten nicht als erledigt.
+
+**Übernehmen:**
+- Jede Route je Modul ist erfasst und einem Schutzstatus zugeordnet.
+- Jeder Befund nennt Datei und Zeile, CWE, Schweregrad, Ausnutzbarkeit und Fix.
+
+**Bewusst vermeiden:**
+- Keine Meldung ohne Gegenlesen des Kontexts. Nicht ausnutzbare Muster werden als Information geführt, nicht als Befund aufgebläht.
+- Keine Angriffe auf laufende Dienste, kein Zugriff auf `archivdms`-Daten oder den Host 131.
+
+## Ausgangslage
+- `QA-06` Sicherheits- und Berechtigungsprüfung DMS (Guard, Upload, XSS, signierte URLs).
+- `RBAC-09`, `RBAC-10`, `API-14`, `API-15`, `API-16` Vertrag Core zu DMS.
+- `SICHERHEITSKONZEPT.md`, STRIDE-Sweep vom 2026-09-12.
+
+## Akzeptanzkriterien
+1. Routenliste je Modul mit Schutzstatus liegt vor; jede ungeschützte oder unklare Route ist als Befund geführt
+2. Befundtabelle mit Datei:Zeile, CWE, Schweregrad, Ausnutzbarkeit und Fix-Vorschlag; jeder Befund wurde gegengelesen
+3. Ein Review-Paket für eine unabhängige externe Prüfung (andere KI oder Prüfer) liegt vor und enthält Geltungsbereich, Bauanleitung, Threat-Model-Kurzfassung und das gewünschte Antwortformat
+
+## Prüfungen vor der Abnahme
+1. Alle HTTP-Registrierungen (`HandleFunc`/`Handle`) aller Module sind in der Routenliste enthalten
+2. Abhängigkeiten und Go-Toolchains je Modul sind gegen Primärquellen abgeglichen, mit Quelle und Abrufdatum
+3. Repository und Historie sind auf Geheimnisse geprüft; im Bericht stehen nur Fundstellen, keine Werte
+
+## Nicht Bestandteil dieser Kachel
+- Behebung der Befunde (Phase 2, je Befund ein Ticket)
+- Dynamische Tests gegen laufende Systeme und Penetrationstests
+- Rechtsberatung zur DSGVO; es werden nur technische Datenschutzaspekte aufgezeigt
+
+## Arbeitsweise
+1. Lies zuerst SICHERHEITSKONZEPT.md, den STRIDE-Sweep und das QA-06-Protokoll und prüfe nichts doppelt.
+2. Keine Installation auf Hosts, keine Angriffe, keine Änderung an Code oder Konfiguration.
+3. Keine Zugangsdaten, Schlüssel oder Werte in Bericht oder Prompts; nur Fundstellen.
+4. Unsicheres und nicht Prüfbares wird ausdrücklich als solches ausgewiesen.
+
+## Abschluss
+- Commit-Nachricht: `QA-15: sicherheitspruefung gesamtprojekt`
+- Branch: `feature/qa-15-sicherheitspruefung-gesamtprojekt`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die Zahl der Befunde je Schweregrad und die wichtigsten Befunde auflisten.

core-kanban/tickets/RBAC-01.md

@@ -0,0 +1,65 @@
+# RBAC-01 – Rollenmodell & Grundrechte
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.
+
+**Technische Grundlage:** PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+> Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden.
+
+**Übernehmen:**
+- Casbin: Policy als Modell + Regeln getrennt von Code, zentrale Entscheidungsfunktion „erlaubt/verboten“.
+- Casbin: Unterstützung für RBAC mit Rollenhierarchie und ABAC-Erweiterung (Attribute wie Abteilung, Modul).
+- Zitadel: Granulare Projekt-Rollen, die Module/Features gezielt freischalten.
+
+**Bewusst vermeiden:**
+- Keycloak – Rollenzuordnung verteilt über Realm-Rollen, Client-Rollen und Composite-Rollen, schwer nachvollziehbar.: Ein einziges, dokumentiertes Rollenmodell mit klarer Vererbung.
+- Casbin – Policy-Dateien werden in der Praxis oft direkt im Dateisystem ohne Versionierung/Audit-Spur gepflegt.: Policies in der Datenbank versioniert und auditierbar ablegen.
+
+**Für genau diese Kachel:** Ein dokumentiertes Rollenmodell mit klarer Vererbung nach Casbin-Prinzip statt verteilter Realm-/Client-/Composite-Rollen wie bei Keycloak.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `IAM-01` Benutzer-Datenmodell & CRUD – Benutzer-Datenmodell (Kernattribute, Status, Tenant-Zugehörigkeit) sowie CRUD-API zur Verwaltung von Benutzerkonten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Grundrollen sind definiert und einem Benutzer je Tenant zuweisbar
+2. Rollenhierarchie (z. B. Tenant-Admin erbt Basisrechte) ist im Modell abgebildet
+3. Rollenzuweisung ist vollständig auditierbar (wer hat wann welche Rolle vergeben)
+
+## 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. Zuweisung einer Rolle außerhalb der erlaubten Matrix wird abgewiesen und automatisiert getestet
+2. Rollenhierarchie liefert im Test die erwartete effektive Rechtemenge
+3. Datenmodell von zweiter Person gegen die Dokumentation geprüft
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RBAC-02` Policy-Enforcement-Schicht (zentral)
+- `RBAC-03` Gruppen & Abteilungen
+- `RBAC-04` Modul-scoped Berechtigungen
+- `RBAC-05` Rechte-Administrationsoberfläche
+
+## 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: `RBAC-01: rollenmodell-grundrechte`
+- Branch: `feature/rbac-01-rollenmodell-grundrechte`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/RBAC-02.md

@@ -0,0 +1,67 @@
+# RBAC-02 – Policy-Enforcement-Schicht (zentral)
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zentrale Policy-Entscheidungs- und Durchsetzungsschicht, die von jeder Query/Repository-Ebene angesprochen wird – keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern.
+
+**Technische Grundlage:** Casbin-Konzept (RBAC/ABAC), Go-Middleware, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden.
+
+**Übernehmen:**
+- Casbin: Policy als Modell + Regeln getrennt von Code, zentrale Entscheidungsfunktion „erlaubt/verboten“.
+- Casbin: Unterstützung für RBAC mit Rollenhierarchie und ABAC-Erweiterung (Attribute wie Abteilung, Modul).
+- Zitadel: Granulare Projekt-Rollen, die Module/Features gezielt freischalten.
+
+**Bewusst vermeiden:**
+- Keycloak – Rollenzuordnung verteilt über Realm-Rollen, Client-Rollen und Composite-Rollen, schwer nachvollziehbar.: Ein einziges, dokumentiertes Rollenmodell mit klarer Vererbung.
+- Casbin – Policy-Dateien werden in der Praxis oft direkt im Dateisystem ohne Versionierung/Audit-Spur gepflegt.: Policies in der Datenbank versioniert und auditierbar ablegen.
+
+**Für genau diese Kachel:** Zentrale Durchsetzungsschicht nach Casbin-Vorbild – Entscheidung und Durchsetzung sind eine Schicht, kein verteiltes Muster.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-01` Rollenmodell & Grundrechte – Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Datenzugriffs-Query läuft durch eine zentrale Enforcement-Funktion, nicht durch handlerspezifische Ad-hoc-Prüfungen
+2. Policy-Entscheidungen sind deklarativ als Regeln definiert und unabhängig von der Anwendungslogik testbar
+3. Tenant-Scoping erfolgt ausschließlich in der Query-/Repository-Schicht, niemals als nachgelagerter Filter
+
+## 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 belegt: kein Datenzugriffs-Pfad umgeht die zentrale Enforcement-Schicht
+2. Negativtest: Anfrage ohne passende Policy wird zuverlässig abgewiesen, nicht standardmäßig erlaubt
+3. Policy-Regelsatz ist versioniert und ein Regelwechsel ist ohne Codeänderung nachvollziehbar
+
+## Bekannte Fehler vermeiden
+
+- **Tenant-Filter als Post-Filter statt in der Query**: In archivmail (`internal/api/ediscovery.go`) wurde der Tenant-Filter nach der Datenbankabfrage angewendet statt in der Query selbst – fehleranfällig bei neuen Codepfaden. → Tenant-Scoping ausschließlich in Query-/Repository-Schicht durchsetzen, nicht pro Handler.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheits- & Penetrationsprüfung Core
+- `RBAC-05` Rechte-Administrationsoberfläche
+
+## 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: `RBAC-02: policy-enforcement-schicht-zentral`
+- Branch: `feature/rbac-02-policy-enforcement-schicht-zentral`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/RBAC-03.md

@@ -0,0 +1,62 @@
+# RBAC-03 – Gruppen & Abteilungen
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Gruppen/Abteilungen als Bündelung von Benutzern innerhalb eines Tenants, mit Rollenzuweisung auf Gruppenebene.
+
+**Technische Grundlage:** PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+> Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden.
+
+**Übernehmen:**
+- Casbin: Policy als Modell + Regeln getrennt von Code, zentrale Entscheidungsfunktion „erlaubt/verboten“.
+- Casbin: Unterstützung für RBAC mit Rollenhierarchie und ABAC-Erweiterung (Attribute wie Abteilung, Modul).
+- Zitadel: Granulare Projekt-Rollen, die Module/Features gezielt freischalten.
+
+**Bewusst vermeiden:**
+- Keycloak – Rollenzuordnung verteilt über Realm-Rollen, Client-Rollen und Composite-Rollen, schwer nachvollziehbar.: Ein einziges, dokumentiertes Rollenmodell mit klarer Vererbung.
+- Casbin – Policy-Dateien werden in der Praxis oft direkt im Dateisystem ohne Versionierung/Audit-Spur gepflegt.: Policies in der Datenbank versioniert und auditierbar ablegen.
+
+**Für genau diese Kachel:** Gruppenmodell als Vorstufe zur ABAC-Erweiterung von Casbin – Attribute wie "Abteilung" später direkt nutzbar.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-01` Rollenmodell & Grundrechte – Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Gruppen lassen sich pro Tenant anlegen und Benutzer zuordnen
+2. Rollen können auf Gruppenebene vergeben werden und wirken auf alle Mitglieder
+3. Löschen einer Gruppe entzieht die gruppenbasierten Rechte sauber, ohne Benutzerkonten zu löschen
+
+## 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. Gruppenrolle wirkt im Test korrekt auf alle aktuellen Mitglieder
+2. Entfernen eines Benutzers aus der Gruppe entzieht die gruppenbasierten Rechte sofort
+3. Gruppen sind sauber tenant-isoliert (Stichprobe über zwei Tenants)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RBAC-05` Rechte-Administrationsoberfläche
+
+## 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: `RBAC-03: gruppen-abteilungen`
+- Branch: `feature/rbac-03-gruppen-abteilungen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/RBAC-04.md

@@ -0,0 +1,63 @@
+# RBAC-04 – Modul-scoped Berechtigungen
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Berechtigungen zusätzlich auf Modul-Ebene scopen, sodass Rechte nur innerhalb freigeschalteter Module wirksam werden.
+
+**Technische Grundlage:** PostgreSQL, Go, Feature-Flag-Integration
+
+## Produkt-DNA für diesen Bereich
+> Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden.
+
+**Übernehmen:**
+- Casbin: Policy als Modell + Regeln getrennt von Code, zentrale Entscheidungsfunktion „erlaubt/verboten“.
+- Casbin: Unterstützung für RBAC mit Rollenhierarchie und ABAC-Erweiterung (Attribute wie Abteilung, Modul).
+- Zitadel: Granulare Projekt-Rollen, die Module/Features gezielt freischalten.
+
+**Bewusst vermeiden:**
+- Keycloak – Rollenzuordnung verteilt über Realm-Rollen, Client-Rollen und Composite-Rollen, schwer nachvollziehbar.: Ein einziges, dokumentiertes Rollenmodell mit klarer Vererbung.
+- Casbin – Policy-Dateien werden in der Praxis oft direkt im Dateisystem ohne Versionierung/Audit-Spur gepflegt.: Policies in der Datenbank versioniert und auditierbar ablegen.
+
+**Für genau diese Kachel:** Modul-Scoping verbindet Casbins ABAC-Gedanken mit Unleashs Feature-Flag-Strategien – Rechte folgen der Lizenz, nicht umgekehrt.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-01` Rollenmodell & Grundrechte – Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.
+- `LIC-02` Feature-Flag-Service je Tenant – Feature-Flag-Dienst mit Strategien (global an/aus, Prozentsatz, Tenant-Zielgruppe) und schneller Auswertung ohne externe Infrastruktur.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Berechtigung für ein nicht lizenziertes/aktiviertes Modul greift nicht, selbst bei sonst passender Rolle
+2. Aktivierung eines Moduls über Feature-Flags macht die zugehörigen Berechtigungen ohne Neustart wirksam
+3. Modul-Scoping ist in derselben zentralen Enforcement-Schicht verankert wie das Grundrollenmodell
+
+## 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. Zugriff auf deaktiviertes Modul wird trotz passender Rolle automatisiert abgewiesen und getestet
+2. Reaktivierung eines Moduls macht Berechtigungen im laufenden Betrieb wirksam (kein Neustart nötig)
+3. Zusammenspiel Modul-Scope + Rollenscope in Kombinationsfällen automatisiert getestet
+
+## 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: `RBAC-04: modul-scoped-berechtigungen`
+- Branch: `feature/rbac-04-modul-scoped-berechtigungen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/RBAC-05.md

@@ -0,0 +1,64 @@
+# RBAC-05 – Rechte-Administrationsoberfläche
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Bedienoberfläche und Nutzerführung. Geschäftslogik bleibt im Backend.
+
+## Auftrag
+Oberfläche zur Verwaltung von Rollen, Rechten, Gruppen und Zuweisungen für Tenant-Administratoren.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Rechte werden zentral entschieden, nicht in jedem Handler neu erfunden.
+
+**Übernehmen:**
+- Casbin: Policy als Modell + Regeln getrennt von Code, zentrale Entscheidungsfunktion „erlaubt/verboten“.
+- Casbin: Unterstützung für RBAC mit Rollenhierarchie und ABAC-Erweiterung (Attribute wie Abteilung, Modul).
+- Zitadel: Granulare Projekt-Rollen, die Module/Features gezielt freischalten.
+
+**Bewusst vermeiden:**
+- Keycloak – Rollenzuordnung verteilt über Realm-Rollen, Client-Rollen und Composite-Rollen, schwer nachvollziehbar.: Ein einziges, dokumentiertes Rollenmodell mit klarer Vererbung.
+- Casbin – Policy-Dateien werden in der Praxis oft direkt im Dateisystem ohne Versionierung/Audit-Spur gepflegt.: Policies in der Datenbank versioniert und auditierbar ablegen.
+
+**Für genau diese Kachel:** Rechte-Oberfläche als dünner Client der zentralen Policy-Schicht – keine eigene Rechtelogik im Frontend.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RBAC-01` Rollenmodell & Grundrechte – Rollenmodell mit Grundrollen (z. B. Superadmin, Tenant-Admin, Benutzer) und Grundrechten definieren, inklusive Rollenzuweisung pro Benutzer und Tenant.
+- `RBAC-02` Policy-Enforcement-Schicht (zentral) – Zentrale Policy-Entscheidungs- und Durchsetzungsschicht, die von jeder Query/Repository-Ebene angesprochen wird – keine Tenant- oder Rechteprüfung verstreut in einzelnen Handlern.
+- `RBAC-03` Gruppen & Abteilungen – Gruppen/Abteilungen als Bündelung von Benutzern innerhalb eines Tenants, mit Rollenzuweisung auf Gruppenebene.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Rollen und ihre Grundrechte sind einsehbar und für Tenant-Admins innerhalb ihrer Erlaubnis änderbar
+2. Gruppen lassen sich anlegen, Mitglieder zuordnen und Rollen zuweisen
+3. Änderungen an Rechten sind über die Oberfläche nachvollziehbar (Verweis auf Audit-Log)
+
+## 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. Tenant-Admin kann keine Rechte außerhalb seines Tenants einsehen oder ändern
+2. Versuch, sich selbst eine höhere Rolle zuzuweisen, wird abgewiesen und automatisiert getestet
+3. Bedienung von zweiter Person ohne Vorwissen erfolgreich nachvollzogen
+
+## 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 Rechte & Policy
+
+## 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: `RBAC-05: rechte-administrationsoberflaeche`
+- Branch: `feature/rbac-05-rechte-administrationsoberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/tickets/RBAC-06.md

@@ -0,0 +1,59 @@
+# RBAC-06 – Testfall gegen Tenant-zu-Superadmin-Rechteeskalation
+
+**Epic:** 🔐 Rollen & Rechte  |  **Rolle:** QA  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Testerin im Bereich QA und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an Zitadel, Casbin, Unleash und Prometheus/Grafana orientiert und deren bekannte Schwächen – u. a. von Keycloak – bewusst vermeidet.
+Unabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.
+
+## Auftrag
+RBAC-01 definiert das Rollenmodell mit Rollenhierarchie, aber kein Ticket prüft explizit, dass ein Tenant-Admin über Rollenvererbung oder Policy-Fehlkonfiguration niemals den Superadmin-Scope erreichen kann. Verbindlichen automatisierten Testfall (Teil der QA-Prüfgates) ergänzen, der jede Rollen-/Policy-Änderung gegen diese Invariante prüft.
+
+**Technische Grundlage:** Automatisierte Tests, Casbin-Policy-Prüfung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Policy-Entscheidungen sind testbar und versionierbar wie Code.
+
+**Bewusst vermeiden:**
+- Keycloak – Composite-Rollen können unbeabsichtigt Rechte über Realm-Grenzen vererben.: Rollenhierarchie ist explizit begrenzt, Vererbung über die Tenant-/Superadmin-Grenze hinweg ist testtechnisch ausgeschlossen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: RBAC-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Automatisierter Test schlägt fehl, sobald eine Rollen-/Policy-Änderung einem Tenant-Admin (oder abgeleiteten Rollen) Superadmin-Rechte einräumt
+2. Test läuft als Pflichtgate in der CI bei jeder Änderung an Rollenmodell oder Policy-Definitionen
+3. Testfall ist dokumentiert und Teil der QA-Prüfgates (Referenz aus QA-03/QA-05)
+
+## 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 gezielt mit einer absichtlich fehlerhaften Policy (Tenant-Admin erbt Superadmin) ausführen, muss fehlschlagen
+2. Test gegen die aktuelle, korrekte Policy ausführen, muss erfolgreich durchlaufen
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): Rollenhierarchie ohne expliziten Gegentest kann bei künftigen Policy-Änderungen unbemerkt eine Tenant-zu-Superadmin-Eskalation zulassen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RBAC-01` Rollenmodell & Grundrechte
+- `QA-03` Prüfgate Rechte & Policy
+- `QA-05` Abnahme- & Compliance-Prüfung Core
+
+## 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: `RBAC-06: testfall-gegen-tenant-zu-superadmin-rechteeskalation`
+- Branch: `feature/rbac-06-testfall-gegen-tenant-zu-superadmin-rechteeskalation`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.