feat: STRIDE-Bedrohungsanalyse aller 7 Boards + 33 Sicherheits-Tickets

security-threat-model-Skill gegen Core, DMS, Mail, Archive, Workflow, AI
und Connect durchlaufen. SICHERHEITSKONZEPT.md um Abschnitte 13-19
erweitert (ein Threat Model je Board), 33 neue Tickets in je einer neuen
Welle pro Board angelegt.

Wiederkehrende Lücken: modulübergreifende Rückkanäle/Registrierungen
vertrauten dem Tenant-Kontext des aufrufenden Moduls ohne unabhängige
Core-Registry-Prüfung; "unveränderlich"/"append-only" war teils nur
Anwendungskonvention statt technischer DB-Durchsetzung.

nexarch-state.json gesamtsumme neu berechnet (390 Tickets, 997 PT).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP

.gitignore

@@ -0,0 +1 @@
+repos/

SICHERHEITSKONZEPT.md

@@ -0,0 +1,420 @@
+# NEXARCH 2.0 – Sicherheitskonzept
+
+Stand: 2026-08-26, alle 10 Punkte in Abschnitt 11 zwischen 2026-08-28 geklärt oder durch neue Tickets adressiert (Core OPS-06, Core IAM-15, DMS SRC-11, Mail SRC-11). Grundlage: `nexarch-state.json`, `SKALIERUNGSKONZEPT.md`, `STORAGE-KONZEPT.md`, `core-kanban/`, `dms-kanban/`, `mail-kanban/`, `archive-kanban/`, `workflow-kanban/`, `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md`.
+
+Dieses Dokument führt keine neue Architektur ein. Es fasst die bereits in den sieben Boards getroffenen sicherheitsrelevanten Einzelentscheidungen zu einem Gesamtbild zusammen und prüft dabei — nach demselben Muster wie `STORAGE-KONZEPT.md` — auf Lücken und Widersprüche. Prüfraster: OWASP Top 10, angewendet auf den tatsächlichen NEXARCH-Techstack (Go, PostgreSQL, JWT, S3-kompatibler Storage, Manticore), nicht generisch abgehandelt.
+
+## 1. Authentifizierung
+
+| Baustein | Entscheidung | Ticket |
+|---|---|---|
+| Passwort-Hashing | bcrypt (bewusst nicht Argon2) | `nexarch-state.json` Techstack |
+| Token | JWT, zustandslos, lokale Signaturverifikation via JWKS-ähnlichem Mechanismus mit `kid`-Rotation | Core `API-05` |
+| Zweiter Faktor | TOTP (RFC 6238), Einrichtung, Wiederherstellungscodes, pro Tenant erzwingbar | Core `IAM-04` |
+| Verzeichnisanbindung | LDAP-Abgleich | Core `IAM-05` |
+| Föderation | SSO/OIDC | Core `IAM-06` |
+| Brute-Force-Schutz | Account-Lockout / Rate-Limiting am Login | Core `IAM-07` |
+
+Die Wahl bcrypt statt Argon2 ist im Entscheidungsverlauf nicht mit einer eigenen Begründung hinterlegt (`nexarch-state.json` Techstack-Feld nennt es nur als Faktum). Das ist keine Sicherheitslücke — bcrypt gilt weiterhin als solide, solange Kostenfaktor aktuell gehalten wird — aber eine unbegründete Abweichung vom heute üblichen Argon2id-Standard sollte im Core-Board mindestens als bewusste Entscheidung mit Kostenfaktor-Wert dokumentiert werden, nicht nur als Faktenzeile in der State-Datei.
+
+**Korrektur gegenüber archivdms:** `known-issues-archivdms.md` Punkt 9 beschreibt einen In-Memory-Rate-Limiter ohne Shared State (`internal/auth/ratelimit.go`) — bei Mehrinstanz-Deployment pro Instanz getrennt und damit aushebelbar. `SKALIERUNGSKONZEPT.md` Abschnitt 1 hält fest, dass Core `IAM-07`/`API-03` Rate-Limiting mit **shared state statt in-process** umsetzt. Damit ist der konkrete archivdms-Fehler für den Login-Pfad explizit adressiert.
+
+2FA-Aktivierungspflicht ist laut `IAM-04` pro Tenant konfigurierbar, nicht global erzwungen — das ist eine bewusste Flexibilitätsentscheidung (SaaS-Betrieb mit unterschiedlichen Kundenanforderungen), sollte aber im Betriebshandbuch als Empfehlung ("2FA-Pflicht für Admin-Rollen mindestens") festgehalten werden, sobald ein Betriebshandbuch existiert (siehe `fehlende_konzeptdokumente`).
+
+## 2. Autorisierung / Zugriffskontrolle
+
+RBAC ist vollständig in Core zentralisiert (`RBAC-01`..`RBAC-05`) — kein Modul implementiert eigene Rechteprüfung, das ist direkte Konsequenz der IAM-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf "Konsolidierung IAM").
+
+**Korrektur gegenüber archivmail:** `known-issues-archivmail.md` Punkt 7 beschreibt Tenant-Filterung als **Post-Filter statt in der Query** (`internal/api/ediscovery.go:90`) — fehleranfällig, weil jeder neue Codepfad das Filtern erneut korrekt implementieren muss. Die Notiz im selben Dokument ordnet das explizit auch DMS `IAM-03` ("Policy-Enforcement — zentral, nicht pro Handler") zu. Das Prinzip "Tenant-/Rechte-Scoping ausschließlich in der Query-/Repository-Schicht, nie als Post-Filter im Handler" ist damit als Korrektur benannt, aber es lohnt sich, es hier noch einmal projektweit festzuhalten: Diese Regel gilt für **jedes** Modul, das gegen die zentrale Core-RBAC-Prüfung arbeitet (DMS, Mail, Archive, Workflow, AI, Connect gleichermaßen), nicht nur für die ursprünglich betroffene eDiscovery-Funktion.
+
+**Tenant-Isolation — bewusst akzeptiertes Risiko:** Multi-Tenancy läuft nach Modell A (eine Datenbank, `tenant_id`-Spalte, applikationsseitige Filterung). Row-Level-Security ist **bewusst nicht** im ersten Ausbau vorgesehen (`nexarch-state.json` `multi_tenancy.row_level_security`). Das ist derselbe Ansatz wie in archivdms, dort ausdrücklich als bekannter Schwachpunkt vermerkt (`known-issues-archivdms.md` Punkte 9/10 zu Tenant-Scoping-Fragilität, sowie `risiko_notiz` in `nexarch-state.json`). Diese Entscheidung wird hier nicht neu bewertet, sondern nur explizit als das benannt, was sie ist: ein akzeptiertes Restrisiko, kein übersehenes. Die einzige technische Kompensation ist die harte Regel aus dem vorigen Absatz (Scoping zentral in der Repository-Schicht, mit Testpflicht — `known-issues-archivdms.md` Punkt 2 fordert Testpflicht für Tenant-Scoping als Merge-Gate, was für NEXARCH übernommen werden sollte, ist aber bisher in keinem QA-Ticket als projektweite CI-Regel verankert, siehe Abschnitt 10).
+
+**Superadmin-Sonderfall:** `known-issues-archivdms.md` Punkt 4 beschreibt einen wiederholt vergessenen Superadmin-ohne-Tenant-Zustand (403 "tenant context required", mehrfach nachträglich gepatcht). Kein Core-Ticket in der gelesenen Auswahl adressiert das explizit als First-Class-Datenmodell-Zustand — siehe Offene Punkte (Abschnitt 11).
+
+## 3. Injection-Schutz
+
+Dynamische SQL-Klauseln/Tabellennamen via `fmt.Sprintf` bzw. String-Konkatenation waren ein wiederkehrendes Antipattern in beiden Altsystemen:
+
+- archivdms: `known-issues-archivdms.md` Punkt 10 — dynamische Tabellennamen via `fmt.Sprintf` (`taxonomy.go`, `workflows.go`, `classification_templates_title.go`, `internal/index/manticore.go`), zur Tatzeit nur durch eine Whitelist-Funktion abgesichert, als "fragiles Muster" bewertet.
+- archivmail: `known-issues-archivmail.md` Punkte 11/12 — dynamische SQL-Klauseln via Sprintf/Join (`internal/index/manticore.go:268,323`, `internal/storage/ocr.go:159`), gleiches Muster zweimal dupliziert.
+
+Beide Fundstellen betreffen denselben Bereich: Suchindex-/Query-Aufbau gegen Manticore bzw. Postgres mit dynamischen Feldlisten. Die Korrektur ist in den entsprechenden Suchindex-Tickets verankert: DMS `SRC-01`, Mail `SRC-01` (Suchindex/Such-API-Grundlage der jeweiligen Module). Die verbindliche Regel aus beiden Known-Issues-Dokumenten lautet übereinstimmend: **Spalten-/Tabellennamen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau, auch nicht hinter einer Whitelist-Funktion.** Ein zentraler, getesteter Query-Builder mit Feld-Whitelist (`known-issues-archivmail.md` Punkt 12) ist der empfohlene Ansatz — ob dieser als gemeinsame Utility zwischen DMS `SRC-01` und Mail `SRC-01` geteilt wird oder je Modul separat entsteht, ist in keinem der beiden Tickets festgelegt (siehe Offene Punkte).
+
+## 4. Sensible Daten / Verschlüsselung
+
+| Baustein | Entscheidung | Ticket |
+|---|---|---|
+| Verschlüsselung at rest | AES-256-GCM, Envelope Encryption | DMS `FDN-09`, Mail `ARC-02` |
+| Reihenfolge Hash/Verschlüsseln | SHA-256-Hash auf Klartext **vor** Verschlüsselung (sonst funktioniert Dublettenerkennung nie) | DMS `FDN-09`/`DOC-02`, Mail `ARC-02`/`ARC-03` |
+| Secrets | ausschließlich über Umgebungsvariablen, nie im Code | durchgängige Ticket-Regel (Abschlussabschnitt jedes Tickets, u.a. explizit in `IAM-04`..`IAM-07`, `RBAC-01`..`RBAC-05`, `API-02`..`API-06`, `AUD-05`) |
+| Audit-Log-Aufbewahrung | append-only (`AUD-02`), Retention über Archive-Engine statt eigener Löschlogik, Default 10 Jahre (GoBD-Buchungsbeleg-Frist) | Core `AUD-05`, Archive `RET-01`/`RET-02`/`RET-05` |
+
+Die Hash-vor-Verschlüsseln-Reihenfolge ist ein gutes Beispiel für eine bereits im Projekt selbst aufgedeckte und behobene Lücke: laut Entscheidungsverlauf fehlte sie zunächst im Mail-Board (`ARC-02`/`ARC-03`), obwohl DMS (`FDN-09`) sie schon hatte, und wurde nachgezogen — dokumentiert in `nexarch-state.json` unter "Duplikatserkennung vor Weiterverarbeitung".
+
+**Schlüsselverwaltung/-rotation — geklärt (2026-08-27):** Zweistufige Schlüsselhierarchie statt eines einzelnen globalen Master-Key. Core hält EINEN Master-Key (Root-KEK, über Umgebungsvariable/Secret-Provider, austauschbar gegen echten KMS-Dienst), der ausschließlich **Tenant-Schlüssel** (Tenant-KEK) verpackt — niemals Objekte direkt. Jeder Mandant erhält bei seiner Provisionierung (`TEN-01`) einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry abgelegt. DMS (`FDN-09`) und Mail (`ARC-02`) 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`. Rotation ist auf beiden Ebenen unabhängig möglich, ohne Objektdaten neu zu verschlüsseln: Master-Key-Rotation verpackt nur alle Tenant-KEKs neu (klein, schnell), Tenant-KEK-Rotation verpackt nur die DEKs dieses einen Mandanten neu und berührt keinen anderen Tenant. Umgesetzt in Core `API-10`.
+
+**Begründung für die Tenant-Ebene:** Ein einzelner globaler Master-Key hätte einen gemeinsamen Blast-Radius für alle Mandanten geschaffen — ein kompromittierter Tenant-KEK (z. B. durch ein fehlerhaftes Modul-Log oder einen kompromittierten Service-Credential-Aufruf) betrifft mit der zweistufigen Hierarchie strukturell nur diesen EINEN Mandanten. Das ist die konsequente Fortsetzung der physischen Modell-C-Isolation (siehe TEN-01, Entscheidungsverlauf "Multi-Tenancy: Modell A -> Modell C") auch auf Schlüsselebene, statt einer Isolationslücke, die die sonstige Trennung wieder aufheben würde.
+
+Die JWT-Schlüsselrotation (Core-Public-Key, `kid`-Rotation) ist dagegen bereits ausformuliert (`SKALIERUNGSKONZEPT.md` Abschnitt 11 letzter Punkt, Core `API-05`): muss ohne Ausfallzeit anderer Module möglich sein. Das ist ein anderer Schlüssel als der Storage-Verschlüsselungs-Master-Key und löst dessen Rotationsfrage nicht mit.
+
+## 5. Eingabevalidierung / bekannte Angriffsvektoren aus den Altsystemen
+
+| Altsystem-Fund | Fundstelle | NEXARCH-Korrektur |
+|---|---|---|
+| Header-Injection bei E-Mail-Versand (From/To/Subject per Stringkonkatenation ohne CRLF-Prüfung) | `known-issues-archivmail.md` #1, `internal/mailer/mailer.go:144-146` | Mail `ING-03` — `net/mail`-Writer bzw. harte CRLF-/Steuerzeichen-Prüfung |
+| Ungebremstes Lesen von Anhängen (`io.ReadAll` ohne Größenlimit → Speicherbombe) | `known-issues-archivmail.md` #3, `pkg/mailparser/parser.go` | Mail `ING-04` (Ingestion) und DMS `DOC-01` (Upload-API) — `io.LimitReader` mit Max-Size, harte Ablehnung; explizit auch für DMS-Uploads übernommen, nicht nur Mail |
+| XSS-Risiko bei Anhang-/Dokument-Vorschau über iframe-Rendering von Fremdinhalt | `known-issues-archivmail.md` #9, positiv gelöst via `PdfCanvasPreview.tsx` (Canvas statt iframe) | DMS `DOC-05` (PDF-Viewer) und Mail `UX-03` — Canvas-Rendering von Anfang an, kein iframe/HTML-Rendering von Fremdinhalt |
+| Content-Type-Erkennung über Dateiendung statt Inhalt | `known-issues-archivmail.md` #8, `AttachmentPreviewDialog.tsx` | betrifft ebenfalls DOC-05 — serverseitige Magic-Bytes-Erkennung statt Dateiendung, im Ticket-Titel nicht explizit als Akzeptanzkriterium sichtbar (siehe Offene Punkte) |
+
+Die Speicherbomben-Korrektur (`DOC-01`/`ING-04`) ist im Entscheidungsverlauf nicht als eigener Eintrag sichtbar, aber laut Known-Issues-Dokument bereits als "betrifft auch DMS" annotiert — das Konzept übernimmt diese Zuordnung, prüft aber nicht, ob `DOC-01` das Größenlimit tatsächlich als Akzeptanzkriterium enthält oder nur als Empfehlung im Known-Issues-Dokument steht. Diese Prüfung sollte bei nächster Gelegenheit nachgeholt werden.
+
+## 6. Vertrauensstellung zwischen Modulen
+
+NEXARCH ist modular mit sieben eigenständigen Boards — Vertrauen zwischen Modul und Core (und indirekt zwischen Modulen) ist eine eigene Angriffsfläche, die in einem Monolithen nicht existieren würde.
+
+- **Modul vertraut Core:** asymmetrische JWT-Signatur, Core signiert mit privatem Schlüssel, Module verifizieren lokal mit öffentlichem Schlüssel über JWKS-ähnliche Verteilung mit `kid`-Rotation (Core `API-05`).
+- **Core vertraut Modul:** Service-Credential je Modul-Instanz, ausgestellt bei Provisionierung (Core `API-02`, erweitert). Notwendig, weil einseitiges Vertrauen (nur Module prüfen Core-Signatur) nicht ausreicht — Core muss bei Nachlieferung/Registrierung wissen, welche Modul-Instanz tatsächlich anfragt, sonst könnte sich ein fremder Absender als Modul ausgeben (`nexarch-state.json` Entscheidungsverlauf "Vertrauensstellung Core↔Module").
+- **Wiederanlauf nach Ausfall:** sofortiger Cache-Refresh per Health-Check-Trigger, gepufferte Audit-Events/Nutzungszähler werden über das Service-Credential authentifiziert nachgeliefert, Pufferqueue muss persistent sein (Core `API-06`).
+- **Rückkanal-API-Berechtigungsprüfung:** Workflow `VOR-04` (Pull-Rückkanal, damit DMS/Mail Akte/Vermerke/Wiedervorlage im eigenen Kontext anzeigen können) ist explizit als "read-only, berechtigungsgeprüft" spezifiziert — das ist der einzige Rückkanal (Pull), der zusätzlich zum bereits bestehenden Push-Kanal (Workflow `ENG-02`) existiert und daher eine eigene Berechtigungsprüfung braucht, nicht nur das Push-seitige Modul-Vertrauen wiederverwenden darf.
+
+Dieses wechselseitige Vertrauensmodell (asymmetrische Signatur + Service-Credential) ist die Antwort auf ein OWASP-Broken-Access-Control-Szenario, das speziell durch die Modul-Architektur entsteht und in einem monolithischen Altsystem (archivdms/archivmail) so nicht vorkam — beide Known-Issues-Dokumente enthalten dazu folgerichtig keinen Eintrag.
+
+## 7. Ausfallsicherheit als Sicherheitsthema
+
+Verfügbarkeit ist hier aufgeführt, weil ein unkontrollierter Core-Ausfall entweder zu Totalausfall der Plattform (worst case für Verfügbarkeit) oder — schlimmer — zu unkontrolliertem Fail-open bei Rechteprüfungen führen könnte, wenn nicht bewusst entschieden wird.
+
+- **Fail-open vs. fail-closed** ist explizit pro Aktionsklasse festgelegt (Core `API-05`/`API-06`, ausformuliert in `SKALIERUNGSKONZEPT.md` Abschnitt 11): Lesevorgänge mit abgelaufenem Rechte-Cache eher fail-open (letzter bekannter Stand gilt weiter), sicherheitskritische Aktionen (Rechteänderung, Löschung, Freigabe) eher fail-closed (lieber verweigern als mit veralteten Rechten ausführen). Das ist eine bewusste, dokumentierte Abwägung — kein Automatismus in eine Richtung.
+- **Core-Hochverfügbarkeit** selbst (`SKALIERUNGSKONZEPT.md` Abschnitt 10): Anwendungsschicht ist zustandslos, echter Single Point of Failure ist die Postgres-Instanz. Stufe 1 kein Live-Failover (Backup/Restore, Archive `BAK-03`), Stufe 2/3 Streaming-Replikation mit pg_auto_failover (LXC-tauglich) oder Patroni (Multi-Standort), Verbindungsindirektion via PgBouncer/HAProxy, Fencing gegen Split-Brain.
+- Wichtiger Nebeneffekt, im Skalierungskonzept explizit benannt: der JWKS-Mechanismus aus `API-05` bleibt während eines kurzen Core-DB-Failover-Fensters funktionsfähig, weil Signaturprüfung keine Core-DB-Verbindung braucht — Core-DB-Failover und die Resilienz der anderen Module sind zwei getrennte, sich gegenseitig entlastende Probleme.
+
+## 8. Sicherheitsrelevante Betriebsaspekte
+
+- **Transportverschlüsselung E-Mail:** TLS/STARTTLS für IMAP/POP3/SMTP (Mail `ING-06`).
+- **Kein direkter Storage-Zugriff:** Up-/Downloads laufen ausschließlich über zeitlich begrenzte signierte URLs, die das Backend ausstellt — Storage-Zugangsdaten erreichen nie den Browser (`STORAGE-KONZEPT.md` Abschnitt 5, DMS `FDN-03` Akzeptanzkriterium 2). Presigned-URL-Gültigkeit soll kurz und konfigurierbar gehalten werden (Minuten, nicht Stunden).
+- **Zentrales Rate-Limiting:** Core `API-03` mit Shared State statt in-process — korrigiert denselben archivdms-Mehrinstanz-Bug wie in Abschnitt 1 beschrieben, hier aber als API-weite (nicht nur Login-spezifische) Infrastruktur, seit der API/Token/Rate-Limiting-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf) alleinige Quelle für alle Module — DMS/Mail betreiben kein eigenes Rate-Limiting mehr.
+
+## 9. Bewährte Muster, die bewusst übernommen werden
+
+Nicht jeder Fund in den Altsystemen ist ein Fehler. Beide Known-Issues-Dokumente benennen positiv zu übernehmende Muster ausdrücklich:
+
+- **Vier-Augen-Prinzip mit `FOR UPDATE`-Lock** bei Löschbestätigung (`known-issues-archivdms.md`, Abschnitt "Positiv zu übernehmende Muster") — im NEXARCH-Kontext die passende Entsprechung für Compliance-kritische Freigaben in Archive `CMP-06` (Vier-Augen-Prinzip), wo derselbe Lock-Mechanismus gegen doppelte/konkurrierende Freigabe schützen sollte.
+- **Timing-safe Vergleich** bei sicherheitsrelevanten Entscheidungen — in archivdms bei Share-Link-Passwortvergleich eingesetzt (`known-issues-archivdms.md`, Positiv-Abschnitt). Gilt als generelles Prinzip für jeden Vergleich, der eine Zugriffsentscheidung trifft (Passwort, Token, Signatur, Wiederherstellungscode aus `IAM-04`), nicht nur für Share-Links — sollte als projektweite Coding-Konvention (analog zur Sprintf-Verbots-Regel aus Abschnitt 3) festgehalten werden, ist aber in keinem Ticket als Konvention formuliert, nur implizit durch das positive Altsystem-Beispiel nahegelegt.
+- **Tenant-Filter in der Query, IDOR-Guards bei Shares** — ebenfalls aus archivdms als positiv übernommenes Muster gelistet; deckt sich mit der in Abschnitt 2 verlangten Regel (Scoping in der Repository-Schicht).
+
+## 10. CI/Merge-Gates für sicherheitsrelevanten Code
+
+`known-issues-archivdms.md` Punkt 2 fordert explizit Testpflicht für Auth/Tenant-Scoping/Retention als Merge-Gate; `known-issues-archivmail.md` Punkt 4 fordert dasselbe für Tenant-Scoping/Protokoll-State-Machines. Beide Forderungen sind in den Known-Issues-Dokumenten als Lehre formuliert, aber in keinem gelesenen QA-Ticket (Core `QA-01`..`QA-05`, DMS `QA-01`, Mail `QA-07`) als projektweite, verbindliche CI-Regel ("kein Merge auf sicherheitsrelevanten Code ohne Test") wiedergefunden. Das ist keine fehlende Einzelentscheidung, sondern eine fehlende Verallgemeinerung einer bereits zweimal unabhängig gemachten Erfahrung — siehe Offene Punkte.
+
+## 11. Offene Punkte
+
+Die folgenden Themen sind entweder in keinem Board bisher behandelt oder nur am Rand erwähnt, ohne dass ein Ticket sie abdeckt. Sie werden hier bewusst nur benannt, nicht mit erfundenen Tickets vorweggenommen — das entscheidet der Nutzer:
+
+1. ~~Security-Header für das Next.js-Frontend~~ — **geklärt (2026-08-28)**: Core `API-08` "Security-Header-Baseline für alle Frontends" deckt CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options als gemeinsame, wiederverwendbare Middleware ab, die jedes Modul-Frontend einbindet statt eigener Definition.
+
+2. ~~Dependency-/Supply-Chain-Sicherheit~~ — **geklärt (2026-08-28)**: neues Ticket Core `OPS-06` "Automatisiertes Schwachstellen-Scanning (Supply-Chain)" verankert `govulncheck` (Go-Module) und `npm audit`/Dependabot (Frontend-Pakete) als verbindlichen, blockierenden CI-Schritt über alle sieben Boards. Hängt im Core-Abschluss-Gate `QA-05`.
+
+3. ~~Schlüsselverwaltung/-rotation für den Storage-Verschlüsselungs-Master-Key~~ — **geklärt (2026-08-27), siehe Abschnitt 4**: zweistufige Hierarchie Master-KEK → Tenant-KEK → Objekt-DEK, umgesetzt in Core `API-10`.
+
+4. ~~Verschlüsselung in Transit zwischen Modulen~~ — **geklärt (2026-08-28)**: Core `API-09` "mTLS zwischen Modul-Instanzen (verteilte Installation)" deckt genau das ab — gegenseitige TLS-Authentifizierung zwischen allen sieben Modul-Instanzen für Stufe 2/3, optional für Stufe-1-Einzel-LXC. Hängt im Core-Abschluss-Gate `QA-04`. `PROXMOX-DEPLOYMENT.md` Abschnitt 3 referenziert es bereits korrekt als ab Stufe 2 verpflichtend.
+
+5. ~~Penetrationstest-Verfahren vor Produktivbetrieb~~ — **geklärt (2026-08-28)**: Core `QA-06` "Externe Sicherheitsprüfung / Penetrationstest vor Produktivbetrieb" deckt genau das ab, projektweit über alle sieben Boards, als externe Ergänzung zu den internen Sicherheits-Prüfgates. `QA-06` ist selbst das letzte, allem nachgelagerte Gate (hängt von `QA-05`, `QA-07`, `QA-08` ab) — der Pentest läuft also erst, wenn alles andere bereits abgenommen ist.
+
+6. ~~Incident-Response-Plan~~ — **geklärt (2026-08-28)**: Core `OPS-04` deckt genau das ab (Erkennung, Eskalation, DSGVO-72h-Meldefrist, Verweis auf Core `AUD-01`/`AUD-05` als Vorfall-Datenquelle) und ist im `code`-Repository bereits als tatsächliches Betriebsdokument umgesetzt (`docs/INCIDENT-RESPONSE-PLAN.md`). Offen bleibt nur die Schlüssel-Notfallrotation im Vorfallsfall — die behandelt `OPS-04` nicht explizit, sollte als Ergänzung im Dokument nachgezogen werden.
+
+7. ~~Superadmin-ohne-Tenant als First-Class-Zustand~~ — **geklärt (2026-08-28)**: Core `IAM-01` Akzeptanzkriterium 2 lautet explizit "Superadmin-ohne-Tenant ist als First-Class-Zustand modelliert" — war bei der ersten Lektüre offenbar übersehen worden, ist aber bereits vorhanden.
+
+8. ~~Verbindliche CI-Testpflicht für sicherheitsrelevanten Code als projektweite Regel~~ — **geklärt (2026-08-28)**: Akzeptanzkriterium "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) als verbindliches Merge-Gate" in allen 6 übrigen `QA-01`-Tickets (DMS, Mail, Archive, Workflow, AI, Connect) nachgezogen, analog zu Core `QA-01`. Jetzt projektweit einheitlich.
+
+9. ~~Timing-safe Vergleich als projektweite Coding-Konvention~~ — **geklärt (2026-08-28)**: neues Ticket Core `IAM-15` verankert die Regel projektweit (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nicht mehr nur implizit über das archivdms-Beispiel. Hängt im Core-Abschluss-Gate `QA-05`.
+
+10. ~~Gemeinsamer Query-Builder für Injection-Schutz~~ — **geklärt (2026-08-28)**: Entscheidung getroffen — getrennte Implementierung je Board, keine gemeinsame Utility, konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren (siehe `nexarch-state.json` → `bewusst_nicht_zentralisiert`). Neue Tickets DMS `SRC-11` und Mail `SRC-11` verankern dieselbe Whitelist-Regel unabhängig in beiden Boards, hängen in DMS `QA-06` bzw. Mail `QA-04`.
+
+11. **bcrypt-Kostenfaktor nicht dokumentiert.** Die Wahl bcrypt statt Argon2 ist als Faktum in `nexarch-state.json` festgehalten, aber ohne Begründung und ohne festgelegten Kostenfaktor.
+
+12. **Anomalie-Erkennung bei API-Token-Nutzung (Core `IAM-09`)** — offen. `IAM-09` deckt Scopes und Ablaufzeit für API-Token/Service-Accounts ab, aber kein Ticket adressiert Erkennung von Token-Nutzung aus ungewöhnlichem Kontext (z. B. fremde IP, ungewöhnliche Zugriffsrate) als Ergänzung zur reinen Ablaufzeit. Siehe Threat-Model-Finding #2 in Abschnitt 13. Kein Ticket erstellt, da Nutzer noch nicht gefragt wurde, ob dafür eine eigene Kachel gewünscht ist.
+
+## 13. Threat Model: NEXARCH Core (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Core-Kanban (Identity, Tenancy, Auth, RBAC, Lizenzierung/Feature-Flags, Audit, zentrale Konfiguration/Benachrichtigung, Core-API/Modulverwaltung, Monitoring), analysiert anhand der Ticket-Inhalte (TEN/IAM/RBAC/AUD/LIC/CFG/API/OPS), nicht anhand des tatsächlichen Codes. Alle Findings mit Schweregrad Kritisch/Hoch/Mittel sind inzwischen als Tickets in Welle 9 und 10 des Core-Boards umgesetzt (siehe `core-kanban/README.md`); Finding #2 (Niedrig-Mittel) ist offen, siehe Punkt 11 oben.
+
+### Systemüberblick
+
+```
+Client/Browser --HTTPS--> Modul-Frontend (Next.js) --> Core-API (Go/net/http)
+                                                          |
+                                          JWT-Middleware (IAM-02) --tenant claim--
+                                                          |
+                                    Connection-Router (TEN-06) --lookup--> Registry-DB
+                                                          |
+                                          Tenant-DB (Modell C, 1 pro Mandant)
+                                                          |
+                        Modul-zu-Modul (DMS/Mail/Archive/Workflow/AI/Connect) via Service-Credential (API-02) [+ optional mTLS API-09]
+                                                          |
+                                    Master-KEK (API-10) --wraps--> Tenant-KEK --wraps--> Objekt-DEK (in DMS/Mail)
+```
+
+Trust-Boundaries: (1) Internet/Client → Modul-Frontend, (2) Frontend/externe Aufrufer → Core-API, (3) Core-API → Registry-DB, (4) Core-API → Tenant-DB, (5) Core ↔ andere Module (Service-Credentials), (6) Core → LDAP/OIDC-Provider (extern), (7) Master-KEK-Speicherort (KMS/Secret-Provider) → Registry.
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Spoofing | IAM-02 Login/JWT | Kein Widerrufsmechanismus — gestohlenes JWT bleibt bis Ablauf gültig, kein Logout-Invalidierung serverseitig | Hoch | `IAM-17` |
+| 2 | Spoofing | IAM-09 API-Token/Service-Accounts | Token-Diebstahl bei Leak — keine Anomalie-Erkennung bei Nutzung aus fremdem Kontext | Mittel | offen (Punkt 12) |
+| 3 | Tampering | TEN-07 Migrations-Orchestrierung | Migrationsdatei ohne Integritätsprüfung würde 1:N gegen alle Tenant-DBs laufen | Mittel | `TEN-10` |
+| 4 | Tampering | API-10 Master-Key-Verwaltung | Master-KEK-Kompromittierung hebelt zweistufige Hierarchie komplett aus — kein Rotationszwang/Alarming | Kritisch | `API-13` |
+| 5 | Repudiation | AUD-01 Audit-Log | „Append-only" nur konventionell, nicht technisch durchgesetzt (DB-Admin-Zugriff könnte ändern/löschen) | Mittel | `AUD-07` |
+| 6 | Information Disclosure | API-08 Security-Header-Baseline | Gut abgedeckt (CSP/HSTS/X-Frame etc. zentral) | Niedrig | abgedeckt |
+| 7 | Information Disclosure | TEN-01 Control-Plane-Registry | Höchstwertiges Einzelziel (Verbindungsinfo zu allen Tenant-DBs + Superadmin-Konten) — kein eigenes Härtungs-Ticket | Kritisch | `TEN-09` |
+| 8 | Information Disclosure | IAM-05 LDAP/AD-Anbindung | LDAP-Bind-Credentials je Tenant — Speicherform (Klartext vs. verschlüsselt) nicht spezifiziert | Mittel | `IAM-19` |
+| 9 | Denial of Service | TEN-06 Connection-Pooling | Ungedeckeltes LRU-Pooling ohne Rate-Limit auf Tenant-Wechsel — Pool-Thrashing-Risiko | Mittel | `TEN-11` |
+| 10 | Denial of Service | LIC-02 Feature-Flag-Service | Kein definiertes Fail-Open/Fail-Closed-Verhalten bei Registry-Ausfall oder Cache-Invalidierungssturm | Mittel | `LIC-06` |
+| 11 | Elevation of Privilege | RBAC-01 Rollenmodell | Keine Prüfung gegen zirkuläre/fehlerhafte Rollenvererbung Tenant-Admin → Superadmin | Hoch | `RBAC-08` |
+| 12 | Elevation of Privilege | API-09 mTLS Modul-zu-Modul | Für Stufe-1 optional — Aktivierung beim Wechsel auf Stufe 2 könnte vergessen werden | Mittel | `OPS-07` |
+| 13 | Elevation of Privilege | IAM-06 SSO/OIDC | Claim-Validierung (Issuer/Audience/Signatur) nicht spezifiziert — Risiko automatischer Superadmin-Ableitung aus externem Claim | Hoch | `IAM-18` |
+
+### Bereits abgedeckt (ohne Nachbesserung nötig)
+
+- **Tenant-Isolation strukturell** (Modell C, physisch getrennte DB) — macht klassisches "vergessener tenant_id-Filter"-Leck strukturell unmöglich (siehe `nexarch-state.json`). Kein Finding dafür.
+- **Security-Header-Baseline** (`API-08`) zentral statt pro Modul.
+- **Envelope-Encryption-Konzept** (`API-10`) zweistufig — richtiger Ansatz, Finding #4 betraf nur Betrieb/Rotation, nicht das Modell selbst.
+- **Audit-Log als eigenständiges Modell** (`AUD-01`), DSGVO-Meldeprozess vorhanden (`OPS-04`, 72h-Frist).
+- **bcrypt statt schwächerem Hashing**, Trennung Auth/Autorisierung (Casbin-Prinzip).
+
+## 14. Threat Model: NEXARCH DMS (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: DMS-Kanban (Dokumentenkern/Upload/Storage/Verschlüsselung, Suche & OCR, Metadaten, Versionierung, Integration/API, Hot-Folder/Scanner, UX), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert und dort bereits in Abschnitt 13 analysiert — hier nicht erneut. Alle Findings sind als Tickets in Welle 12 des DMS-Boards umgesetzt (siehe `dms-kanban/README.md`).
+
+### Systemüberblick
+
+```
+Client --> DMS-Frontend --> DMS-API (auf Core-API-Grundgerüst, INT-01)
+                               |
+              Upload (DOC-01) --checksum DOC-02--> Storage-Adapter (FDN-03, S3/lokal)
+                               |                         |
+                     Envelope-Encryption (FDN-09, DEK<-Tenant-KEK aus Core API-10)
+                               |
+              Async-Worker (FDN-04: OCR/Konvertierung/Index) --> Manticore-Index (SRC-01)
+                               |
+        Externe Eingänge: Hot-Folder (INT-08), Netzwerkscanner (INT-06), CMIS (INT-09)
+                               |
+        Externe Ausgänge: Archive (INT-11 Retention), AI (INT-12), Workflow (INT-13)
+```
+
+Trust-Boundaries: (1) Client→API, (2) API→Storage, (3) API→Async-Worker-Queue, (4) Dateisystem-Hot-Folder (lokal, kein API-Auth)→DMS, (5) DMS↔Archive/AI/Workflow (Modul-Registrierung), (6) CMIS-Schnittstelle→Drittwerkzeuge.
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Tampering | DOC-01 Upload | Kein Malware-Scan vor Ablage (nur MIME/Größe geprüft) | Mittel | `DOC-17` |
+| 2 | Tampering | INT-08 Hot-Folder | Dateisystem-Import ohne Auth-Kontext, keine explizite Tenant-Zuordnung des Verzeichnisses | Hoch | `INT-14` |
+| 3 | Tampering | INT-06 Netzwerkscanner-Ordner | Gleiches Muster wie INT-08 | Hoch | `INT-14` |
+| 4 | Information Disclosure | FDN-03 Storage-Adapter | Signierte URLs ohne festgelegten Scope/kurze TTL | Mittel | `FDN-10` |
+| 5 | Information Disclosure | DOC-05 Inline-Betrachter | "Ohne Download-Zwang" ist UI-Ziel, keine technische Zugriffskontrolle — Hinweis, kein eigenständiges Risiko | Niedrig | Hinweis |
+| 6 | Information Disclosure | INT-09 CMIS-Schnittstelle | Keine festgelegte Auth-/Tenant-Scoping-Parität zur REST-API | Hoch | `INT-15` |
+| 7 | Repudiation | VER-05 Unveränderliches Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5) | Mittel | `VER-08` |
+| 8 | Denial of Service | FDN-04 Async-Worker | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl) | Mittel | `FDN-11` |
+| 9 | Denial of Service | DOC-08 Archiv-Bündelung | Kein Limit für Gesamtgröße/Anzahl je Bündelungs-Anfrage | Niedrig | offen (nicht ticketiert) |
+| 10 | Elevation of Privilege | INT-11/12/13 Modul-Registrierung | Rückkanäle (z. B. Workflow VOR-04) könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden | Hoch | `INT-16` |
+| 11 | Elevation of Privilege | DOC-02 Duplikat-Prüfung | Falls Hash-Abgleich global statt tenant-scoped implementiert wird: Seitenkanal-Leck über Duplikat-Treffer | Niedrig | Hinweis, Implementierungsdetail bei Umsetzung von DOC-02 explizit tenant-scoped halten |
+
+### Bereits abgedeckt
+
+- **Envelope-Encryption pro Objekt** (`FDN-09`) korrekt an Core-Schlüsselhierarchie (`API-10`) gekoppelt, keine eigene Master-Key-Logik im DMS.
+- **Tenant-Isolation strukturell** über Core Modell C — gilt auch hier.
+- **Duplikat-Erkennung/Checksum** (`DOC-02`) als bewusste Nutzerentscheidung statt automatischem Verwerfen.
+- **known-issues-archivdms.md** bereits als Vermeidungs-Checkliste im Board berücksichtigt (Rechte-Bug Ersteller-Sichtbarkeit, Superadmin-Sonderfall, Sprintf-in-SQL) — deshalb hier nicht erneut als Findings gelistet.
+
+## 15. Threat Model: NEXARCH Mail (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Mail-Kanban (Ingestion & Protokoll-Server IMAP/POP3/SMTP, Postfach-Import, Archivierung, Suche & OCR, Integration/API), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert (Abschnitt 13). Code-Wiederverwendung aus archivmail ist hier – anders als bei DMS – ausdrücklich erlaubt, daher liegt ein Schwerpunkt auf bekannten Altsystem-Bugs aus `known-issues-archivmail.md`. Alle Findings sind als Tickets in Welle 8 des Mail-Boards umgesetzt (siehe `mail-kanban/README.md`).
+
+### Systemüberblick
+
+```
+Externe Mailserver --IMAP/POP3/SMTP--> Ingestion-Server (ING-01..03, TLS/STARTTLS ING-06)
+                                              |
+                          Import-Scheduler (IMP-01) --Anhänge--> Virenscan (IMP-06)
+                                              |
+                          Archivierung (ARC-01, Objekt-Storage je Tenant-Bucket ARC-06)
+                                              |
+                    Envelope-Encryption (ARC-02, DEK<-Tenant-KEK aus Core API-10)
+                                              |
+                    Indexierung/OCR (SRC-02/SRC-07) --> Manticore-Index
+                                              |
+        Ausgehend: Mailer (ING-03) für Benachrichtigungen --> Core-Dispatcher (CFG-02)
+                                              |
+        Externe Ausgänge: Archive (INT-08 Retention), AI (INT-09), Workflow (INT-10)
+```
+
+Trust-Boundaries: (1) Externer Mailserver→Ingestion-Server, (2) Ingestion→Import-Pipeline, (3) Import→Objekt-Storage, (4) Mail-API→Client, (5) Mail↔Archive/AI/Workflow (Modul-Registrierung), (6) Mailer→externe Empfänger (ausgehend).
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Tampering | ING-03 Mailer (ausgehend) | Header-Injection bei Stringkonkatenation von From/To/Subject — konkreter, bereits im archivmail-Altsystem aufgetretener Bug (known-issues Punkt 1) | Hoch | `ING-11` |
+| 2 | Elevation of Privilege | INT-08/09/10 Modul-Registrierung | Rückkanäle könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden (analog DMS-Finding) | Hoch | `INT-11` |
+| 3 | Information Disclosure | INT-01/ARC-01 Anhang-Download | Signierte URLs ohne festgelegten Scope/kurze TTL (analog DMS-Finding) | Mittel | `INT-12` |
+| 4 | Denial of Service | SRC-02/SRC-07 Indexierung/OCR | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl), analog DMS-Finding | Mittel | `SRC-12` |
+| 5 | Denial of Service | ING-09 Rate-Limiting | Bereits abgedeckt — SMTP-Annahme und Login-Versuche rate-limitiert | Niedrig | abgedeckt |
+| 6 | Tampering | IMP-02/IMP-06 Anhang-Verarbeitung | Bereits abgedeckt — Virenscan mit Quarantäne vorgesehen (IMP-06), Größenlimit als Lehre aus archivmail (known-issues Punkt 3) im Board verankert | Niedrig | abgedeckt |
+| 7 | Information Disclosure | ARC-06 Objekt-Storage | Bereits abgedeckt — physische Mandantentrennung je Bucket/Pfad-Root statt Präfix-Konvention | Niedrig | abgedeckt |
+
+### Bereits abgedeckt
+
+- **Virenscan mit Quarantäne** (`IMP-06`) bereits im Board vorgesehen, nicht erst nachträglich als Finding nötig (anders als beim DMS-Board, wo dies fehlte).
+- **Physische Mandantentrennung im Objekt-Storage** (`ARC-06`) korrigiert das archivmail-Muster einer gemeinsamen Ablage mit Pfad-Präfix.
+- **Rate-Limiting auf Protokollebene** (`ING-09`) für SMTP-Annahme/Login bereits vorgesehen.
+- **TLS/STARTTLS verpflichtend** (`ING-06`) für alle drei Protokollserver.
+- **Signatur-Prüfung bei Archivierung mit Zeitstempel** (`ARC-10`) für S/MIME/PGP-signierte Mails nach BSI TR-03125.
+
+## 16. Threat Model: NEXARCH Archive (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Archive-Kanban (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen) — die zentrale, alleinige Quelle für Aufbewahrung/WORM/Compliance/Backup für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Archive-Boards umgesetzt (siehe `archive-kanban/README.md`).
+
+### Systemüberblick
+
+```
+DMS/Mail --Registrierung (RET-05)--> Archive Retention-Engine (RET-01..03)
+                                              |
+                          WORM-Speicherpfad (RET-04) --> Objekt-Storage
+                                              |
+                     Löschworkflow mit Vier-Augen-Prinzip (CMP-06) / DSGVO-Löschantrag (CMP-07)
+                                              |
+                          Compliance/eDiscovery-Export (CMP-01..03) --> Audit (Core AUD-01, CMP-04)
+                                              |
+                     Backup: DB (BAK-01), Objekt-Storage (BAK-02) --> Restore-Test (BAK-06)
+```
+
+Trust-Boundaries: (1) DMS/Mail→Archive (Registrierung, Service-Credentials), (2) Archive→Objekt-Storage (WORM), (3) Archive→Core-Audit-Log, (4) Backup-Ziel (extern/separates Speichersystem), (5) Restore-Testumgebung.
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Tampering | RET-04 WORM-Speicherpfad | "Kein Überschreiben" ggf. nur anwendungsseitig, nicht als Storage-Garantie (Object Lock) durchgesetzt | Hoch | `RET-11` |
+| 2 | Spoofing | RET-05 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen | Hoch | `RET-12` |
+| 3 | Information Disclosure | BAK-01/BAK-02 Backup | Kein festgelegter Verschlüsselungsschutz für Backup-Snapshots — schwächeres Abbild derselben Daten als das Live-System | Mittel | `BAK-09` |
+| 4 | Information Disclosure | BAK-06 Restore-Testumgebung | Enthält echte wiederhergestellte Mandantendaten, Schutzniveau nicht festgelegt | Mittel | `BAK-10` |
+| 5 | Repudiation | RET-03/CMP-06 Löschworkflow | Bereits abgedeckt — Vier-Augen-Prinzip und Protokolleintrag vorgesehen, Legal Hold hat Vorrang | Niedrig | abgedeckt |
+| 6 | Tampering | CMP-03 eDiscovery-Export | Bereits abgedeckt — prüfsummengesicherter Export vorgesehen | Niedrig | abgedeckt |
+
+### Bereits abgedeckt
+
+- **Vier-Augen-Prinzip bei Löschung** (`CMP-06`) — positives Muster aus archivdms übernommen.
+- **Legal Hold hat Vorrang vor Fristablauf** (`RET-03`) — verhindert versehentliche Löschung bei laufendem Rechtsverfahren.
+- **DSGVO-Löschantrag mit Aufbewahrungs-Vorrangprüfung** (`CMP-07`) korrekt gegen `RET-03` abgegrenzt, keine zweite Lösch-Implementierung.
+- **Prüfsummengesicherter eDiscovery-Export** (`CMP-03`).
+- **Eigene, von Dokument-Retention unabhängige Backup-Prune-Policy** (`BAK-07`) — Backups laufen nicht unbegrenzt oder zu früh ab.
+
+## 17. Threat Model: NEXARCH Workflow (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Workflow-Kanban (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang) — alleinige Quelle für Genehmigungsprozesse, Aufgaben/Fristen und Routing für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 8 des Workflow-Boards umgesetzt (siehe `workflow-kanban/README.md`).
+
+### Systemüberblick
+
+```
+DMS/Mail --Push-Registrierung (ENG-02)--> Workflow-Engine (ENG-01, Zustandsautomat)
+                                              |
+                     Genehmigungen (APR-01..04) / Aufgaben & Fristen (TSK-01..05)
+                                              |
+                     Instanzschritt-Protokoll (ENG-04, unveränderlich)
+                                              |
+                     Akte & Vorgang (VOR-01..03) <--Pull-Rückkanal (VOR-04)-- DMS/Mail
+                                              |
+                     Regelbasiertes Routing (RTE-01..04) --optional-- KI-Vorschlag (AI WFS-02, RTE-05)
+```
+
+Trust-Boundaries: (1) DMS/Mail→Workflow (Push-Registrierung, Service-Credentials), (2) DMS/Mail←Workflow (Pull-Rückkanal VOR-04), (3) Workflow→Core-Benachrichtigungs-Dispatcher, (4) Workflow→AI (optionaler KI-Vorschlag).
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Information Disclosure / Elevation of Privilege | VOR-04 Rückkanal-API | Kein festgelegter Tenant-Kontext-Abgleich bei Pull-Anfrage von DMS/Mail — Bypass der Mandantentrennung über den Rückkanal möglich | Hoch | `VOR-06` |
+| 2 | Spoofing | ENG-02 Registrierungsschnittstelle | Tenant-Kontext bei Push-Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-Finding) | Mittel | `ENG-06` |
+| 3 | Repudiation | ENG-04 Instanzschritt-Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5/DMS `VER-08`) | Mittel | `ENG-07` |
+| 4 | Elevation of Privilege | APR-02 Vier-Augen-Freigabe | Bereits abgedeckt — generisches, modulunabhängiges Vier-Augen-Muster vorgesehen | Niedrig | abgedeckt |
+| 5 | Elevation of Privilege | RTE-05 KI-Vorschlag im Routing | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Engine bleibt maßgebliche Entscheidungsinstanz | Niedrig | abgedeckt |
+
+### Bereits abgedeckt
+
+- **Vier-Augen-Prinzip für Freigaben** (`APR-02`) generisch und modulunabhängig konfigurierbar.
+- **KI bleibt Vorschlag, nie Entscheidung** (`RTE-05`) — verhindert stille Rechte-/Entscheidungsverlagerung an ein optionales KI-Modul.
+- **Vermerke unveränderlich nach Speichern** (`VOR-02`, Ergänzung statt Bearbeitung) — passendes Muster für Nachvollziehbarkeit, unabhängig vom technischen Append-only-Finding zu `ENG-04`.
+
+## 18. Threat Model: NEXARCH AI (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: AI-Kanban (KI-Engine & Modell-Anbindung, Klassifizierung, Extraktion, Zusammenfassung, semantische Suche & Chat, Workflow-Vorschläge, Datenschutz & Governance) — alleinige Quelle für KI-Funktionen für DMS und Mail, optional aktivierbar über Core `LIC-02`. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 10 des AI-Boards umgesetzt (siehe `ai-kanban/README.md`).
+
+### Systemüberblick
+
+```
+DMS/Mail --Registrierung (GOV-01)--> AI-Governance
+                                              |
+                     KI-Engine (ENG-01..06) --> Ollama (Standard) / externer Cloud-Adapter (ENG-03, optional)
+                                              |
+              Inferenz-Warteschlange (ENG-05) --> Klassifizierung/Extraktion/Zusammenfassung/SEM-Chat
+                                              |
+                     Prompt-Injection-Härtung (GOV-06) / Audit-Protokollierung (GOV-05 -> Core AUD-01)
+                                              |
+                     Workflow-Vorschläge (WFS-01..03) --> Workflow-Board (nur Vorschlag, keine Entscheidung)
+```
+
+Trust-Boundaries: (1) DMS/Mail→AI (Registrierung, Service-Credentials), (2) AI→Ollama/externer Provider (ENG-03, ggf. Datenabfluss außerhalb der eigenen Infrastruktur), (3) Dokument-/Mailinhalt→Prompt (Prompt-Injection-Fläche), (4) AI→Core-Audit-Log, (5) AI→Workflow (Vorschlags-Rückkanal).
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Spoofing | GOV-01 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-/Workflow-Finding) | Mittel | `GOV-07` |
+| 2 | Denial of Service | ENG-05 Inferenz-Warteschlange | Keine Ressourcenlimits je Anfrage (Kontextlänge/Verarbeitungszeit) | Mittel | `ENG-07` |
+| 3 | Tampering | GOV-06 Prompt-Injection-Härtung | Bereits abgedeckt — strikte Trennung Systemanweisung/Nutzerinhalt, Schema-Validierung, Instruktions-Muster-Erkennung explizit vorgesehen | Niedrig | abgedeckt |
+| 4 | Repudiation | GOV-05 KI-Entscheidungsprotokoll | Bereits abgedeckt — Protokollierung über Core-Audit-Schnittstelle statt eigenem Log | Niedrig | abgedeckt |
+| 5 | Elevation of Privilege | WFS-02/03 Workflow-Vorschläge | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Workflow-Engine bleibt maßgebliche Entscheidungsinstanz (siehe Abschnitt 17) | Niedrig | abgedeckt |
+| 6 | Information Disclosure | ENG-03 externer Cloud-Adapter | Optionaler Datenabfluss an externen Anbieter — durch `GOV-03` (Steuerung lokal/extern je Tenant, Trainingsausschluss) bereits adressiert; DSGVO-Auftragsverarbeitungsvertrag mit externem Anbieter ist ein Vertrags-, kein Ticket-Thema | Niedrig | Hinweis (organisatorisch, kein Ticket) |
+
+### Bereits abgedeckt
+
+- **Prompt-Injection-Härtung** (`GOV-06`) — ungewöhnlich vollständig für ein Planungsdokument: Trennung Systemanweisung/Inhalt, Schema-Validierung, Muster-Erkennung.
+- **KI-Entscheidungen vollständig auditierbar** (`GOV-05`) über die zentrale Core-Audit-Schnittstelle statt eigenem Log.
+- **Feingranulare Tenant-Steuerung** (`GOV-02`/`GOV-03`) für einzelne KI-Funktionen und lokal-vs-extern, mit explizitem Trainingsausschluss auf Kundendaten.
+- **Verbrauchsobergrenzen je Tenant** (`GOV-04`) gekoppelt an Core-Lizenzsteuerung — verhindert bereits einen Teil der Ressourcenerschöpfungs-Angriffsfläche auf Tenant-Ebene (ergänzt durch `ENG-07` auf Einzelanfrage-Ebene).
+- **Grounding mit Belegpflicht** (`SEM-04`/`SEM-05`) — keine Chat-Antwort ohne nachvollziehbare Quellenangabe.
+
+## 19. Threat Model: NEXARCH Connect (STRIDE)
+
+Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Connect-Kanban (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität) — baut vollständig auf Core auf, keine eigene API-Infrastruktur. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Connect-Boards umgesetzt (siehe `connect-kanban/README.md`). Letztes der sieben Boards, das mit diesem Skill durchlaufen wurde — Abschnitte 13–19 decken jetzt alle NEXARCH-Boards ab.
+
+### Systemüberblick
+
+```
+Connector-Engine (ENG-01) --Plugin-Registrierung--> ERP/CRM (ERP-01..04), DATEV (DAT-01..03),
+                                                      M365 (M365-01..03), Andere-DMS (DMS2-01..03)
+                    |
+      Zugangsdaten-Verwaltung (ENG-02) --verschlüsselt--> je Connector-Instanz
+                    |
+      Sync-Jobs (ENG-03) --Fehlerbehandlung/Retry (ENG-05)--> Drittsystem
+                    |
+      Alle Connector-Aktionen --> Core-Audit-Log (ENG-06)
+```
+
+Trust-Boundaries: (1) NEXARCH↔Drittsystem (OAuth/API-Key, ausgehend), (2) Connector-Engine→Zugangsdaten-Speicher, (3) Sync-Job→Drittsystem (Netzwerk, außerhalb eigener Kontrolle), (4) Connect→Core-Audit-Log.
+
+### Findings
+
+| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
+|---|--------|------------|-----------|--------------|--------|
+| 1 | Information Disclosure | ENG-02 Zugangsdaten-Verwaltung | Verschlüsselung ohne festgelegte Anbindung an die zentrale Tenant-KEK-Hierarchie — Risiko eines zweiten, separat zu härtenden Verschlüsselungspfads | Mittel | `ENG-07` |
+| 2 | Denial of Service | ENG-03/ENG-05 Sync-Jobs | Keine Obergrenzen für Laufzeit/Datenmenge je Sync-Lauf, Retry-Abbruchgrenze nicht technisch erzwungen | Mittel | `ENG-08` |
+| 3 | Repudiation | ENG-06 Audit-Kopplung | Bereits abgedeckt — alle Connector-Aktionen an Core-Audit-Log gekoppelt | Niedrig | abgedeckt |
+| 4 | Information Disclosure | DMS2-03 externe Backup-Ziele | Bereits abgedeckt — „verschlüsselter Export“ explizit vorgesehen | Niedrig | abgedeckt |
+
+### Bereits abgedeckt
+
+- **Alle Connector-Aktionen im Core-Audit-Log** (`ENG-06`) — Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert.
+- **Verschlüsselter Export zu externen Backup-Zielen** (`DMS2-03`).
+- **Keine eigene API-/Rate-Limiting-/Webhook-Infrastruktur** — vollständig auf Core aufgebaut, reduziert die Angriffsfläche gegenüber einer zweiten, parallelen Implementierung.
+- **LDAP/SSO bleibt Core-Sache** — Connect dupliziert keine Identitäts-Infrastruktur.

ai-kanban/README.md

@@ -0,0 +1,97 @@
+# AI-Kanban – lokal abarbeiten
+
+46 Arbeitskacheln · 8 Epics · 126 Personentage · 10 Wellen (inkl. Welle 10: Threat-Model-Nachtrag 2026-09-12 — GOV-07, ENG-07).
+
+Dieses Board ist die alleinige Quelle für KI-Funktionen (Klassifizierung, Extraktion, Zusammenfassung, semantische Suche, Chat, Workflow-Vorschläge). DMS-Board referenziert dieses Board extern in der Ausgangslage betroffener Tickets. KI-Nutzung ist optional (Core LIC-02 Feature-Flag), lokal/On-Premise-first via Ollama, kein Training auf Kundendaten.
+
+Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board.
+Stand: 2026-08-26
+
+## 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 (`ENG-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** (2 Kacheln): ENG-01, QA-01
+- **Welle 2** (5 Kacheln): ENG-02, ENG-03, ENG-04, ENG-05, ENG-06
+- **Welle 3** (9 Kacheln): CLS-01, EXT-01, GOV-01, GOV-03, GOV-04, QA-02, SEM-01, SUM-01, SUM-02
+- **Welle 4** (14 Kacheln): CLS-02, CLS-03, CLS-04, CLS-05, EXT-02, EXT-03, GOV-02, GOV-05, GOV-06, QA-07, SEM-02, SUM-03, SUM-04, WFS-01
+- **Welle 5** (5 Kacheln): EXT-04, EXT-05, QA-05, SEM-03, WFS-02
+- **Welle 6** (3 Kacheln): QA-03, SEM-04, WFS-03
+- **Welle 7** (3 Kacheln): QA-08, SEM-05, SEM-06
+- **Welle 8** (1 Kacheln): QA-04
+- **Welle 9** (1 Kacheln): QA-06
+
+Kritischer Pfad (26 PT): ENG-01 → ENG-05 → SEM-01 → SEM-02 → SEM-03 → SEM-04 → SEM-06 → QA-04 → QA-06
+
+## Produkt-DNA
+
+### Übernehmen
+- **Ollama**: Lokale Modell-Bereitstellung als einfache, austauschbare Standardanbindung – on-premise first.
+- **LangChain/LlamaIndex (Konzept)**: RAG-Grundmuster – Retrieval vor Generation, Quellenverweise werden konsequent mitgeführt – bewusst schlanker umgesetzt, kein schweres Framework.
+- **Docspell**: Strukturierte Extraktion konkreter Werte als Vorschlag mit Konfidenz, keine automatische Übernahme ohne Bestätigung.
+
+### Vermeiden
+- **Schwergewichtige Agent-Frameworks – hoher Ressourcen- und Konfigurationsaufwand ohne Mehrwert für die klar umrissenen KI-Funktionen dieses Moduls.**: Schlanke Provider-Abstraktion und eine schmale RAG-Pipeline statt vollem Orchestrierungs-Framework.
+- **Automatische Übernahme von KI-Vorschlägen – untergräbt Vertrauen in Klassifizierung und Extraktion, Lehre aus Docspell/paperless-ngx im DMS-Board.**: Jeder Vorschlag trägt Konfidenz und verlangt Bestätigung, konsequent über alle Funktionen hinweg.
+
+## 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).

ai-kanban/board.csv

@@ -0,0 +1,234 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+ENG-01,"Provider-Interface (OpenAI-kompatibel, austauschbar)",🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,3,1,Backlog,"Go-Interface, Chat-/Completion-/Embedding-Abstraktion","Einheitliche Schnittstelle für Inferenz-Aufrufe (Chat, Completion, Embedding), OpenAI-kompatibles Anfrage-/Antwortformat, austauschbar hinter einem Provider-Interface.",,ENG-02 ENG-03 ENG-04 ENG-05 ENG-06 GOV-06,"Provider-Interface deckt Chat, Completion und Embedding ab
+Ein neuer Provider lässt sich ohne Änderung der Aufrufer einbinden
+Fehler eines Providers werden einheitlich abgebildet","Zwei Provider-Implementierungen gegen dasselbe Interface getestet
+Timeout- und Fehlerfall am Interface geprüft
+Vertrag per Contract-Test abgesichert"
+ENG-02,"Ollama-Adapter (lokal, Standard)",🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,3,2,Backlog,"Ollama-HTTP-API, lokale Modell-Bereitstellung","Adapter für lokal gehostete Ollama-Instanz als Standard-Provider, inklusive Modell-Warmup und Health-Check.",ENG-01,GOV-03 QA-02,"Ollama-Adapter erfüllt das Provider-Interface vollständig
+Nicht erreichbare Ollama-Instanz wird erkannt und gemeldet
+Standard-Provider ist ohne weitere Konfiguration aktiv
+Modellgrößen-Empfehlung je Betriebsstufe ist dokumentiert","Anfrage gegen lokale Ollama-Instanz erfolgreich beantwortet
+Ausfall der Instanz führt zu klarer Fehlermeldung, nicht zu Absturz
+Modellwechsel ohne Dienst-Neustart geprüft
+Dokumentierte Modellgrößen-Empfehlung mit tatsächlichem Ressourcenverbrauch abgeglichen"
+ENG-03,Externer-API-Adapter (optional),🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,3,2,Backlog,"OpenAI-kompatible Cloud-API, API-Schlüssel-Verwaltung","Optionaler Adapter für externe, OpenAI-kompatible Cloud-Anbieter als Alternative zum lokalen Standardbetrieb.",ENG-01,GOV-03 QA-02,"Externer Adapter erfüllt das Provider-Interface vollständig
+Aktivierung ist ausdrücklich und je Tenant konfigurierbar
+Zugangsdaten liegen ausschließlich in Umgebungsvariablen","Anfrage gegen externen Anbieter erfolgreich beantwortet
+Deaktivierter externer Adapter wird nie automatisch verwendet
+Kein Dokumentinhalt verlässt das System ohne explizite Freigabe"
+ENG-04,Modellverwaltung & -auswahl je Tenant,🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,3,2,Backlog,"Modellregister, Tenant-Konfiguration, PostgreSQL",Verwaltung verfügbarer Modelle je Provider und Auswahl des aktiven Modells je Tenant und Funktion.,ENG-01,QA-02,"Modelle sind je Tenant konfigurierbar hinterlegt
+Modellwechsel wirkt ohne Neustart
+Nicht verfügbares Modell wird beim Speichern abgewiesen","Modellwechsel im Test sofort wirksam
+Fehlkonfiguration wird beim Speichern verhindert
+Mandantentrennung der Modellauswahl geprüft"
+ENG-05,Inferenz-Queue,🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,3,2,Backlog,"Postgres-Jobqueue, Worker, Rückstandsverarbeitung","Asynchrone Warteschlange für Inferenz-Aufrufe, damit lange KI-Anfragen keine Anfrage-Bearbeitung blockieren.",ENG-01,CLS-01 EXT-01 GOV-01 GOV-04 SEM-01 SUM-01 SUM-02 QA-08 QA-02 ENG-07,"Inferenz-Aufrufe laufen asynchron über die Queue
+Fehlgeschlagene Aufrufe werden mit Rückverfolgung wiederholt
+Warteschlangenstand ist beobachtbar","Lastspitze ohne blockierte Anfragen durchlaufen
+Wiederholung nach Fehlschlag im Test nachvollzogen
+Warteschlangenstand im Monitoring sichtbar"
+ENG-06,Prompt-Vorlagen-Verwaltung (versioniert),🧠 KI-Engine & Modell-Anbindung,Backend,Einfach,2,2,Backlog,"Versionierte Prompt-Vorlagen, PostgreSQL","Verwaltung von Prompt-Vorlagen je Funktion mit Versionierung, damit Änderungen nachvollziehbar und rückrollbar sind.",ENG-01,QA-02,"Prompt-Vorlagen sind versioniert gespeichert
+Frühere Version ist wiederherstellbar
+Aktive Version je Funktion ist eindeutig bestimmt","Rollback auf frühere Vorlage im Test erfolgreich
+Änderung einer Vorlage ohne Versionsverlust geprüft
+Aktive Version für jede Funktion eindeutig ermittelt"
+CLS-01,Dokumentklassifizierung (generisches Modell),🏷️ Klassifizierung & Verschlagwortung,Backend,Mittel,3,3,Backlog,"Sprachmodell, Klassifizierungsschema","Dokumentklassifizierung anhand von Inhalt und Struktur über ein generisches, konfigurierbares Klassifizierungsmodell.",ENG-05,CLS-02 CLS-03 CLS-04 CLS-05 WFS-01,"Klassifizierung liefert Kategorie mit Konfidenz
+Ergebnis folgt einem definierten Ausgabeschema
+Unbekannte Dokumentart wird als solche gekennzeichnet","Genauigkeit an gelabeltem Testset gemessen und dokumentiert
+Verhalten bei unbekannter Dokumentart geprüft
+Ausgabeschema in allen Testfällen eingehalten"
+CLS-02,Dokumenttyp-Erkennung,🏷️ Klassifizierung & Verschlagwortung,Backend,Mittel,3,4,Backlog,"Sprachmodell, Dokumenttyp-Taxonomie","Erkennung des konkreten Dokumenttyps (z. B. Rechnung, Vertrag, Lieferschein) aufbauend auf der generischen Klassifizierung.",CLS-01,QA-03,"Dokumenttyp wird mit Konfidenz vorgeschlagen
+Taxonomie ist je Tenant erweiterbar
+Mehrdeutige Fälle werden erkennbar markiert","Trefferquote je Dokumenttyp gemessen und dokumentiert
+Erweiterung der Taxonomie ohne Codeänderung geprüft
+Mehrdeutiger Testfall korrekt markiert"
+CLS-03,Automatische Verschlagwortung,🏷️ Klassifizierung & Verschlagwortung,Backend,Mittel,3,4,Backlog,"Sprachmodell, Tag-Vorschlagslogik","Automatische Vorschläge für Schlagworte auf Basis von Inhalt, bestehender Tag-Taxonomie und Modul-Kontext.",CLS-01,QA-03,"Tag-Vorschläge werden mit Konfidenz angezeigt
+Bestehende Tag-Taxonomie wird respektiert statt dupliziert
+Vorschlag erfolgt ohne automatische Übernahme","Dopplung bestehender Tags im Test ausgeschlossen
+Trefferquote an Testset gemessen und dokumentiert
+Keine automatische Übernahme ohne Bestätigung geprüft"
+CLS-04,Erkennung wichtiger Inhalte,🏷️ Klassifizierung & Verschlagwortung,Backend,Mittel,3,4,Backlog,"Sprachmodell, Segmentierung","Erkennung besonders relevanter Textabschnitte im Dokument (z. B. Fristen, Kernaussagen) zur Hervorhebung.",CLS-01,QA-03,"Relevante Abschnitte werden mit Position markiert
+Ergebnis ist auf lange Dokumente stabil
+Kein relevanter Abschnitt wird stillschweigend verworfen","Erkennung an mehrseitigem Testdokument nachvollzogen
+Stabilität bei sehr langen Dokumenten geprüft
+Nachvollziehbarkeit der Markierung im Test bestätigt"
+CLS-05,Konfidenz-Schwelle & Korrektur-Feedback-Loop,🏷️ Klassifizierung & Verschlagwortung,Backend,Mittel,3,4,Backlog,"Konfidenz-Schwellenwerte, Feedback-Speicherung",Konfigurierbare Konfidenz-Schwelle je Funktion und Erfassung von Nutzerkorrekturen zur laufenden Qualitätsverbesserung.,CLS-01,QA-03,"Schwelle ist je Funktion und Tenant konfigurierbar
+Korrektur wird strukturiert erfasst und gespeichert
+Auswertung der Korrekturen ist einsehbar","Schwellenwertänderung wirkt ohne Neustart
+Korrektur-Feedback im Test vollständig erfasst
+Auswertung liefert nachvollziehbare Kennzahlen"
+EXT-01,Strukturierte Feld-Extraktion (generisches Modell),📑 Extraktion,Backend,Komplex,4,3,Backlog,"Sprachmodell, Extraktionsschema, JSON-Schema-Validierung","Strukturierte Extraktion konkreter Werte aus Dokumenten (Datum, Betrag, Vertragspartner u. a.) über ein generisches, definiertes Ausgabeschema.",ENG-05,EXT-02 EXT-03 GOV-06,"Extraktion folgt einem definierten Ausgabeschema
+Jeder Wert trägt einen Konfidenzwert
+Fehlender Wert wird als solcher markiert, nicht erraten","Extraktionsgenauigkeit an gelabeltem Testset gemessen
+Schemaverletzung im Test zuverlässig abgewiesen
+Verhalten bei fehlendem Wert geprüft"
+EXT-02,Rechnungsdaten-Extraktion,📑 Extraktion,Backend,Mittel,3,4,Backlog,"Extraktionsschema Rechnung, Sprachmodell","Spezialisiertes Extraktionsschema für Rechnungsdaten: Rechnungsnummer, Betrag, Steuersatz, Fälligkeitsdatum, Absender.",EXT-01,EXT-04,"Rechnungsfelder werden vollständig und typisiert erkannt
+Mehrere Steuersätze in einer Rechnung werden korrekt zugeordnet
+Fehlerhafte Rechnung wird nicht stillschweigend akzeptiert","Genauigkeit an gelabeltem Rechnungs-Testset dokumentiert
+Mehrfachsteuersatz-Fall im Test korrekt ausgewertet
+Fehlerhafte Testrechnung korrekt zurückgewiesen"
+EXT-03,Extraktions-Validierung & Confidence-Score,📑 Extraktion,Backend,Mittel,3,4,Backlog,"Validierungsregeln, Confidence-Scoring","Plausibilitätsprüfung extrahierter Werte (Formate, Wertebereiche, Konsistenz) und Zusammenführung zu einem Gesamt-Confidence-Score.",EXT-01,EXT-04 EXT-05,"Unplausibler Wert wird markiert, nicht stillschweigend übernommen
+Gesamt-Confidence-Score ist nachvollziehbar hergeleitet
+Validierungsregeln sind konfigurierbar","Unplausibler Testwert im Test erkannt
+Score-Herleitung im Test nachvollzogen
+Regeländerung ohne Codeänderung wirksam"
+EXT-04,Extraktions-Korrektur-Oberfläche,📑 Extraktion,Frontend,Mittel,3,5,Backlog,"Next.js/React/TypeScript, Formularkomponenten","Oberfläche zur Ansicht, Korrektur und Bestätigung extrahierter Werte vor Übernahme in die Metadaten des aufrufenden Moduls.",EXT-02 EXT-03 SHL-01,,"Vorschläge werden mit Konfidenz angezeigt
+Nutzer bestätigt oder korrigiert vor Übernahme
+Korrektur ist pro Feld einzeln möglich","Bestätigungsfluss im Test vollständig durchlaufen
+Korrektur eines einzelnen Felds ohne Seiteneffekt geprüft
+Abbruch ohne Übernahme im Test bestätigt"
+EXT-05,Extraktions-Ergebnis-Kopplung an Modul-Metadatenfelder,📑 Extraktion,Backend,Mittel,3,5,Backlog,"Modul-Adapter-Schnittstelle, Feld-Mapping",Kopplung bestätigter Extraktionsergebnisse an die Metadatenfelder des aufrufenden Moduls (DMS/Mail) über den Modul-Adapter.,EXT-03,QA-03,"Bestätigter Wert landet im richtigen Metadatenfeld des Moduls
+Feld-Mapping ist je Modul konfigurierbar
+Nicht zuordenbarer Wert wird nicht verworfen, sondern gemeldet","Übernahme in DMS-Metadatenfeld im Test nachvollzogen
+Fehlkonfiguriertes Mapping im Test erkannt
+Nicht zuordenbarer Wert im Test korrekt gemeldet"
+SUM-01,Dokument-Zusammenfassung,📝 Zusammenfassungen,Backend,Mittel,3,3,Backlog,"Sprachmodell, Zusammenfassungs-Pipeline",Automatische Kurz-Zusammenfassung eines Dokuments mit konfigurierbarer Länge und Sprache.,ENG-05,SUM-03 SUM-04,"Zusammenfassung ist inhaltlich belegbar aus dem Original
+Länge ist konfigurierbar
+Sehr lange Dokumente werden ohne Absturz verarbeitet","Stichprobe manuell gegen Originaldokument geprüft
+Verhalten bei sehr langem Dokument getestet
+Konfigurierbare Länge im Test eingehalten"
+SUM-02,E-Mail-/Thread-Zusammenfassung,📝 Zusammenfassungen,Backend,Mittel,3,3,Backlog,"Sprachmodell, Thread-Aggregation",Zusammenfassung eines E-Mail-Threads über mehrere Nachrichten hinweg mit Verlaufsbezug.,ENG-05,SUM-03,"Zusammenfassung bildet den Threadverlauf korrekt ab
+Zitierte Altnachrichten werden nicht doppelt zusammengefasst
+Neue Nachricht aktualisiert die Zusammenfassung","Mehrteiliger Test-Thread korrekt zusammengefasst
+Duplizierung von Zitaten im Test ausgeschlossen
+Aktualisierung nach neuer Nachricht geprüft"
+SUM-03,Zusammenfassungs-Oberfläche,📝 Zusammenfassungen,Frontend,Einfach,2,4,Backlog,Next.js/React/TypeScript,Oberfläche zur Anzeige von Dokument- und Thread-Zusammenfassungen inklusive Verweis auf die Quelle.,SUM-01 SUM-02 SHL-01,,"Zusammenfassung ist am Dokument/Thread sichtbar
+Verweis auf Original ist ein Klick entfernt
+Ladezustand ist erkennbar","Anzeige an Beispieldokument und Beispiel-Thread geprüft
+Verweis auf Original im Test funktionsfähig
+Ladezustand im Test sichtbar"
+SUM-04,Zusammenfassungs-Qualitätsbewertung,📝 Zusammenfassungen,Backend,Einfach,2,4,Backlog,"Bewertungsmetriken, Stichprobenprüfung",Qualitätsbewertung erzeugter Zusammenfassungen anhand von Stichproben und einfachen Kennzahlen.,SUM-01,QA-06,"Qualitätskennzahl ist je Zusammenfassungstyp abrufbar
+Auffällig schlechte Zusammenfassung wird erkennbar markiert
+Bewertung ist nachvollziehbar dokumentiert","Kennzahl an Testset berechnet und dokumentiert
+Auffälliger Testfall im Test markiert
+Nachvollziehbarkeit der Bewertung bestätigt"
+SEM-01,Embeddings-Pipeline,🔎 Semantische Suche & Chat,Backend,Mittel,3,3,Backlog,"Embedding-Modell, Batch-Verarbeitung",Pipeline zur Erzeugung von Embeddings für Dokumente und E-Mails inklusive Chunking langer Inhalte.,ENG-05,SEM-02,"Embeddings werden für neue Inhalte automatisch erzeugt
+Lange Inhalte werden sinnvoll in Abschnitte zerlegt
+Fehlerhafte Erzeugung wird erkannt und wiederholt","Chunking an langem Testdokument nachvollzogen
+Fehlerfall im Test erkannt und wiederholt
+Durchsatz an Testmenge dokumentiert"
+SEM-02,Vektorindex-Speicherung,🔎 Semantische Suche & Chat,Backend,Mittel,3,4,Backlog,PostgreSQL mit Vektorerweiterung,Speicherung und Indizierung der erzeugten Embeddings inklusive Mandantentrennung.,SEM-01,SEM-03,"Vektorindex ist mandantengetrennt abfragbar
+Ähnlichkeitssuche liefert stabile Ergebnisse
+Löschung eines Dokuments entfernt auch dessen Vektoren","Mandantentrennung im Test bestätigt
+Löschung im Test vollständig nachvollzogen
+Abfragezeit an Testmenge dokumentiert"
+SEM-03,Semantische-Such-API,🔎 Semantische Suche & Chat,Backend,Mittel,3,5,Backlog,"REST-API, Ähnlichkeitssuche",Schnittstelle für semantische Suche über Dokumente/E-Mails eines Tenants mit Relevanz-Ranking.,SEM-02,SEM-04 SEM-06,"Suche liefert nach Relevanz sortierte Treffer
+Nur berechtigte Dokumente erscheinen im Ergebnis
+Leere Trefferliste wird sauber gemeldet","Relevanz-Ranking an Testkorpus stichprobenartig geprüft
+Rechteprüfung im Test bestätigt
+Leerfall im Test korrekt behandelt"
+SEM-04,Chat-mit-Dokumenten (RAG-Pipeline),🔎 Semantische Suche & Chat,Backend,Komplex,4,6,Backlog,"RAG-Pipeline: Retrieval vor Generation, Sprachmodell","Chat-Oberfläche über Dokumente eines Tenants: Retrieval relevanter Abschnitte vor der Antwort-Generierung, keine Antwort ohne Beleg.",SEM-03,SEM-05 SEM-06 QA-08,"Antwort stützt sich auf tatsächlich abgerufene Abschnitte
+Frage ohne belastbaren Treffer wird als solche beantwortet
+Antwortzeit bleibt für Chat-Nutzung praktikabel","Beleg-Antwort-Zuordnung an Testfragen nachvollzogen
+Fall ohne Treffer im Test korrekt behandelt
+Antwortzeit an Testkorpus gemessen"
+SEM-05,Quellenverweise & Zitat-Nachvollziehbarkeit,🔎 Semantische Suche & Chat,Backend,Mittel,3,7,Backlog,"Zitat-Verweise, Quellen-Mapping","Mitführen und Anzeigen der Quellenabschnitte je Chat-Antwort, damit jede Aussage auf ein Dokument zurückführbar ist.",SEM-04,QA-04,"Jede Antwort führt mindestens einen Quellenverweis
+Verweis führt zum tatsächlichen Abschnitt im Dokument
+Antwort ohne Beleg wird nicht als gesichert dargestellt","Quellenverweis an Testfrage stichprobenartig nachvollzogen
+Sprung zum Originalabschnitt im Test funktionsfähig
+Unbelegte Antwort im Test korrekt gekennzeichnet"
+SEM-06,Semantische-Such-/Chat-Oberfläche,🔎 Semantische Suche & Chat,Frontend,Mittel,3,7,Backlog,Next.js/React/TypeScript,Oberfläche für semantische Suche und Dokumenten-Chat inklusive Quellenanzeige und Verlauf.,SEM-03 SEM-04 SHL-01,QA-04,"Suche und Chat sind aus einer Oberfläche erreichbar
+Quellenverweise sind in der Antwort sichtbar
+Verlauf bleibt innerhalb der Sitzung erhalten","Bedienfluss Suche und Chat im Test durchlaufen
+Quellenanzeige im Test sichtbar bestätigt
+Verlauf nach Navigation im Test erhalten"
+WFS-01,Vorschlagsmodell (Routing/Klassifizierung aus Historie),💡 Workflow-Vorschläge,Backend,Mittel,3,4,Backlog,"Historische Auswertung, Sprachmodell/Regelableitung",Ableitung von Routing- und Klassifizierungsvorschlägen aus dem historischen Bearbeitungsverlauf eines Tenants.,CLS-01,WFS-02 QA-06,"Vorschlag stützt sich auf tatsächliche Historie
+Vorschlag trägt einen Konfidenzwert
+Zu geringe Datenlage wird erkannt und gemeldet","Vorschlagsgüte an historischem Testbestand gemessen
+Fall geringer Datenlage im Test korrekt behandelt
+Konfidenzwert im Test nachvollzogen"
+WFS-02,Vorschlags-API (Kopplung Workflow-Board Modul-Adapter),💡 Workflow-Vorschläge,Backend,Mittel,3,5,Backlog,"REST-API, Modul-Adapter-Schnittstelle","Schnittstelle, über die das Workflow-Board Vorschläge für Routing-Entscheidungen abruft.",WFS-01,WFS-03 QA-06,"Workflow-Board kann Vorschläge über die Schnittstelle abrufen
+Antwort enthält Vorschlag, Konfidenz und Begründung
+Nicht erreichbare AI-Instanz blockiert das Workflow-Board nicht","Abruf aus Sicht des Workflow-Boards im Test nachvollzogen
+Ausfallverhalten im Test bestätigt
+Antwortformat gegen Vertrag geprüft"
+WFS-03,Vorschlags-Feedback-Loop,💡 Workflow-Vorschläge,Backend,Mittel,3,6,Backlog,"Feedback-Speicherung, Nachtrainingslogik","Erfassung, ob ein Vorschlag übernommen oder korrigiert wurde, zur laufenden Verbesserung des Vorschlagsmodells.",WFS-02,QA-06,"Annahme und Korrektur eines Vorschlags werden erfasst
+Auswertung der Trefferquote ist einsehbar
+Feedback fließt nachvollziehbar in künftige Vorschläge ein","Erfassung von Annahme/Korrektur im Test bestätigt
+Trefferquoten-Auswertung im Test nachvollzogen
+Wirkung des Feedbacks auf Folgevorschlag geprüft"
+GOV-01,Modul-Adapter-Schnittstelle (DMS/Mail registrieren KI-fähige Objekttypen),🛡️ Datenschutz & Governance,Backend,Mittel,3,3,Backlog,"Modul-Adapter-Schnittstelle, Objekttyp-Registry","Schnittstelle, über die DMS und Mail KI-fähige Objekttypen (Dokument, E-Mail, Thread) und deren Felder registrieren, statt eigene KI-Logik zu bauen.",ENG-05,GOV-02 GOV-05 QA-07 GOV-07,"Modul kann Objekttyp mit Feldern registrieren
+Registrierung ist ohne Codeänderung im AI-Modul möglich
+Nicht registrierter Objekttyp wird sauber abgewiesen","Registrierung aus Sicht eines Testmoduls nachvollzogen
+Fehlregistrierung im Test korrekt abgewiesen
+Zwei Module parallel registriert und geprüft"
+GOV-02,Opt-in/Opt-out je Tenant & Funktion,🛡️ Datenschutz & Governance,Backend,Mittel,3,4,Backlog,Feature-Flags je Tenant und Funktion,"Feingranulare Aktivierung/Deaktivierung einzelner KI-Funktionen je Tenant, oberhalb des globalen Core-LIC-02-Schalters.",GOV-01 LIC-02,QA-05,"Jede Funktion ist einzeln je Tenant schaltbar
+Deaktivierte Funktion wird nicht aufgerufen
+Änderung wirkt ohne Neustart","Deaktivierung einer Funktion im Test wirksam bestätigt
+Globaler Schalter (Core LIC-02) im Test respektiert
+Änderung ohne Neustart im Test nachvollzogen"
+GOV-03,Keine Training auf Kundendaten – Datenresidenz-Kontrolle,🛡️ Datenschutz & Governance,Backend,Mittel,3,3,Backlog,"Datenresidenz-Konfiguration, Provider-Routing","Nachvollziehbare, je Tenant konfigurierbare Steuerung, ob Inferenz lokal (Ollama) oder extern erfolgt, mit Ausschluss von Training auf Kundendaten.",ENG-02 ENG-03,QA-05,"Datenresidenz ist je Tenant einsehbar konfiguriert
+Externe Verarbeitung erfordert ausdrückliche Freigabe
+Kein Kundendokument fließt in ein Training ein","Konfiguration lokal/extern im Test nachvollzogen
+Fehlende Freigabe verhindert externe Verarbeitung im Test
+Trainingsausschluss vertraglich und technisch geprüft"
+GOV-04,Kostenkontrolle & Quota (Kopplung Core LIC-03),🛡️ Datenschutz & Governance,Backend,Mittel,3,3,Backlog,"Kostenzähler, Quota-Schwellen, Kopplung Core LIC-03","Verbrauchszählung und Obergrenzen je Tenant für Inferenz-Nutzung, gekoppelt an die Lizenzsteuerung aus Core LIC-03.",ENG-05 LIC-03,QA-05,"Verbrauch ist je Tenant nachvollziehbar erfasst
+Überschreitung der Quota wird zuverlässig verhindert
+Näherung an die Grenze wird vorab gemeldet","Quota-Überschreitung im Test zuverlässig blockiert
+Vorabwarnung im Test ausgelöst
+Verbrauchszählung gegen tatsächliche Aufrufe abgeglichen"
+GOV-05,KI-Entscheidungs-Nachvollziehbarkeit (Kopplung Core AUD),🛡️ Datenschutz & Governance,Backend,Einfach,2,4,Backlog,"Audit-Ereignisse, Kopplung Core AUD","Protokollierung jeder KI-gestützten Entscheidung (Modell, Prompt-Version, Eingabe-Referenz, Ergebnis) über die Audit-Schnittstelle von Core.",GOV-01,QA-05,"Jede KI-Entscheidung erzeugt einen Audit-Eintrag
+Eintrag verweist auf Modell- und Prompt-Version
+Eintrag ist nachträglich unveränderlich","Audit-Eintrag an Testentscheidung nachvollzogen
+Verweis auf Modell-/Promptversion im Test bestätigt
+Unveränderlichkeit des Eintrags im Test geprüft"
+QA-01,Teststrategie AI,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Backlog,"Teststrategie, anonymisierter Testdatenbestand","Festlegen, was auf welcher Ebene geprüft wird, und Aufbau eines realistischen, anonymisierten Testdatenbestands mit gelabelten Referenzdokumenten für KI-Funktionen.",,,"Teststrategie ist je Funktion dokumentiert
+Testdatenbestand ist anonymisiert und gelabelt
+Referenzdokumente decken die wichtigsten Dokumentarten ab
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Testdatenbestand auf Anonymisierung geprüft
+Abdeckung der Dokumentarten dokumentiert
+Teststrategie von zweiter Person nachvollzogen"
+QA-02,Prüfgate Engine & Modellanbindung,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,3,Backlog,Integrationstests Engine/Modelle,"Prüfen von Provider-Austauschbarkeit, Modellverwaltung, Inferenz-Queue und Prompt-Versionierung.",ENG-06 ENG-02 ENG-03 ENG-04 ENG-05,QA-06,"Providerwechsel funktioniert ohne Aufrufer-Änderung
+Warteschlange verarbeitet Lastspitzen ohne Verlust
+Prompt-Rollback funktioniert nachweislich","Providerwechsel im Test nachvollzogen
+Lastspitzen-Test dokumentiert
+Rollback-Test dokumentiert"
+QA-03,Prüfgate Klassifizierung & Extraktion,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Backlog,Datenqualitätstests Klassifizierung/Extraktion,Prüfen von Klassifizierungs- und Extraktionsgüte gegen den Referenzkorpus sowie der Korrektur-Feedback-Schleife.,CLS-05 EXT-05 CLS-02 CLS-03 CLS-04,QA-06,"Klassifizierungsgenauigkeit erreicht die Zielgenauigkeit
+Extraktionsgenauigkeit erreicht die Zielgenauigkeit
+Korrektur-Feedback wirkt nachweislich auf künftige Vorschläge","Genauigkeit an Referenzkorpus dokumentiert
+Feedback-Wirkung im Test nachvollzogen
+Ausgabeschema in allen Testfällen eingehalten"
+QA-04,Prüfgate Semantische Suche & Chat,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,8,Backlog,End-to-End-Tests Suche/Chat,"Prüfen von Suchqualität, RAG-Antwortgüte und Quellenverweis-Nachvollziehbarkeit.",SEM-06 SEM-05,QA-06,"Suchqualität an Testkorpus dokumentiert
+Chat-Antworten sind durchgängig mit Quelle belegt
+Unbelegte Antwort wird zuverlässig gekennzeichnet","Relevanz-Stichprobe dokumentiert
+Beleg-Antwort-Zuordnung an Testfragen dokumentiert
+Antwortzeit an Testkorpus dokumentiert"
+QA-05,Datenschutz- & Governance-Prüfung,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,5,Backlog,Datenschutz- und Governance-Prüfung,"Prüfen von Opt-in/Opt-out, Datenresidenz-Kontrolle, Trainingsausschluss, Kostenkontrolle und Entscheidungs-Nachvollziehbarkeit.",GOV-05 GOV-02 GOV-03 GOV-04 GOV-06,QA-06,"Opt-out einer Funktion wird in der Praxis respektiert
+Datenresidenz-Konfiguration wird eingehalten
+Jede geprüfte Entscheidung ist im Audit nachvollziehbar","Opt-out-Fall im Test bestätigt
+Datenresidenz-Fall lokal und extern geprüft
+Audit-Nachvollziehbarkeit an Stichprobe bestätigt"
+QA-06,Abnahme-Prüfung AI,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,9,Backlog,"Abnahmeprüfung, Gesamtprotokoll",Zusammenführende Abnahmeprüfung aller vorangehenden AI-Prüfgates zu einem Gesamtprotokoll vor Freigabe des Moduls.,QA-02 QA-03 QA-04 QA-05 QA-07 QA-08 QA-09 SUM-04 WFS-01 WFS-02 WFS-03,,"Alle vorangehenden Prüfgates sind bestanden dokumentiert
+Gesamtprotokoll ist an einem Ort abgelegt
+Offene Punkte sind mit Verantwortlichkeit vermerkt","Vollständigkeit des Gesamtprotokolls geprüft
+Rückverfolgbarkeit zu Einzelprüfgates bestätigt
+Freigabeentscheidung dokumentiert"
+QA-07,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,4,Backlog,"Vertragstests, CI-Pipeline","Vertragstests für die AI-Modul-Adapter-Schnittstelle, über die DMS und Mail KI-fähige Objekttypen registrieren – Breaking Changes werden automatisiert erkannt.",GOV-01,QA-06,"Vertragstests decken die Modul-Adapter-Schnittstelle GOV-01 ab
+Ein absichtlich brechender Schema-Wechsel lässt die Vertragstests fehlschlagen
+Vertragstests laufen automatisiert in der CI, nicht nur manuell","Testlauf gegen aktuellen Stand grün
+Simulierte Breaking Change wird erkannt
+CI-Integration nachgewiesen"
+QA-08,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,7,Backlog,"Lastgenerator, Messprotokoll",Lasttest für die Inferenz-Queue und den Chat-mit-Dokumenten-Pfad unter realistischer paralleler Nutzung – insbesondere ob die dort zugesicherte 'keine spürbare Verzögerung' unter Last hält.,ENG-05 SEM-04,QA-06,"Definierte Ziel-Antwortzeit für Chat-Anfragen unter paralleler Last eingehalten
+Inferenz-Queue verarbeitet mehrere gleichzeitige Klassifizierungs-/Extraktionsanfragen ohne unkontrolliertes Anwachsen der Warteschlange
+Verhalten bei Überlast (Queue voll) ist definiert, nicht undefiniert","Lasttest mit parallelen Chat-Anfragen, Antwortzeit gemessen und dokumentiert
+Queue-Länge unter Last beobachtet und gegen Zielwert geprüft
+Überlast-Szenario simuliert, definiertes Verhalten bestätigt"
+GOV-06,Prompt-Injection-Schutz,🛡️ Datenschutz & Governance,Backend,Mittel,3,4,Backlog,"Strukturierte Prompt-Vorlagen, Schema-Validierung, Muster-Erkennung","Härtung gegen Prompt-Injection aus Dokument-/Mailinhalten – strikte Trennung zwischen Systemanweisung und Nutzerinhalt im Prompt-Aufbau, Validierung von Extraktionsergebnissen gegen ein erwartetes Schema, Erkennung auffälliger Instruktions-Muster im Dokumentinhalt vor der Verarbeitung.",ENG-01 EXT-01,QA-05,"Dokumentinhalt wird im Prompt strukturell von der Systemanweisung getrennt (z. B. über klar markierte Abschnitte oder strukturierte Eingabe), nicht als freier Text vermischt
+Extraktionsergebnisse werden gegen ein erwartetes Schema/Format validiert, bevor sie weiterverarbeitet werden
+Kein KI-Ergebnis löst allein eine automatische Freigabe-, Lösch- oder Statusänderungs-Aktion aus – jede sicherheitsrelevante Aktion bleibt an eine menschliche Bestätigung gekoppelt (Docspell-Prinzip, hier als Sicherheitsgrenze verankert)","Test mit Dokument, das eine eingebettete Anweisung enthält (""ignoriere vorherige Anweisung..."") – Verarbeitung folgt der eigentlichen Aufgabe, nicht der eingebetteten Anweisung
+Test: Extraktionsergebnis außerhalb des erwarteten Schemas wird abgelehnt/markiert, nicht stillschweigend übernommen
+Test bestätigt, dass keine sicherheitsrelevante Aktion ohne menschliche Bestätigung ausgelöst wurde"
+QA-09,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,8,Backlog,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller AI-Oberflächen (Extraktions-Korrektur-Oberfläche, Zusammenfassungs-Oberfläche, Semantische-Such-/Chat-Oberfläche) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",EXT-04 SUM-03 SEM-06,QA-06,"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"
+GOV-07,Unabhängige Tenant-Validierung bei KI-Objekttyp-Registrierung durch DMS/Mail,🛡️ Datenschutz & Governance,Backend,Mittel,2,10,Backlog,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","GOV-01 nimmt Registrierungen KI-fähiger Objekttypen und Felder von DMS und Mail entgegen. Analog zu Archive `RET-12` und Workflow `ENG-06` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen – sonst könnte eine Kompromittierung/Fehlkonfiguration in DMS/Mail dazu führen, dass KI-Funktionen (Klassifizierung, Extraktion, semantische Suche) auf falsch zugeordnete Tenant-Daten angewendet werden.",GOV-01,,"Jede Objekttyp-/Feld-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+Bestehende, korrekte Registrierungsabläufe aus GOV-01 funktionieren unverändert","Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig"
+ENG-07,Ressourcenlimits für die Inferenz-Warteschlange,🧠 KI-Engine & Modell-Anbindung,Backend,Mittel,2,10,Backlog,"Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Eingabegröße/Kontextlänge)","ENG-05 stellt eine asynchrone Warteschlange für Inferenz-Aufrufe bereit, damit lange KI-Anfragen keine Anfrage-Bearbeitung blockieren, ohne Obergrenzen pro Einzelanfrage festzulegen. Eine sehr lange Eingabe (z. B. ein extrem langes Dokument bei Zusammenfassung/Embedding) oder eine bewusst konstruierte Anfrage kann einen Inferenz-Worker unverhältnismäßig lange blockieren und damit andere Mandanten in der gemeinsamen Warteschlange verzögern. Harte Obergrenzen je Anfrage definieren (max. Eingabegröße/Kontextlänge, max. Verarbeitungszeit) – bei Überschreitung wird die Anfrage kontrolliert abgelehnt statt den Worker zu blockieren.",ENG-05,,"Jede Inferenz-Anfrage hat konfigurierbare Obergrenzen für Eingabegröße/Kontextlänge und maximale Verarbeitungszeit
+Eine Überschreitung führt zur kontrollierten Ablehnung der Anfrage mit klarer Fehlermeldung, nicht zur Blockade des Workers
+Andere, gleichzeitig laufende Inferenz-Anfragen (auch anderer Mandanten) bleiben von einer überschreitenden Anfrage unbeeinflusst","Test mit einer Eingabe, die absichtlich die Kontextlängen-/Größenobergrenze überschreitet: Anfrage wird kontrolliert abgelehnt
+Lasttest: eine überschreitende Anfrage blockiert nicht die Verarbeitung paralleler, regulärer Anfragen
+Regressionstest: normale, innerhalb der Grenzen liegende Anfragen funktionieren unverändert"

ai-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>AI Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>AI 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": 126, "epics": [{"key": "ENG", "name": "KI-Engine & Modell-Anbindung", "emoji": "🧠", "color": "#7C3AED", "description": "Provider-Abstraktion, lokale und externe Modell-Anbindung, Modellverwaltung, Inferenz-Queue und versionierte Prompt-Vorlagen. Grundlage für alle KI-Funktionen."}, {"key": "CLS", "name": "Klassifizierung & Verschlagwortung", "emoji": "🏷️", "color": "#0D9488", "description": "Dokumentklassifizierung, Dokumenttyp-Erkennung, automatische Verschlagwortung und Konfidenz-gesteuerte Korrektur-Feedback-Schleife."}, {"key": "EXT", "name": "Extraktion", "emoji": "📑", "color": "#B45309", "description": "Strukturierte Feld-Extraktion, Rechnungsdaten, Validierung mit Confidence-Score und Korrektur-Oberfläche."}, {"key": "SUM", "name": "Zusammenfassungen", "emoji": "📝", "color": "#0369A1", "description": "Dokument- und E-Mail-/Thread-Zusammenfassung samt Oberfläche und Qualitätsbewertung."}, {"key": "SEM", "name": "Semantische Suche & Chat", "emoji": "🔎", "color": "#4338CA", "description": "Embeddings-Pipeline, Vektorindex, semantische Suche, Chat-mit-Dokumenten (RAG) mit nachvollziehbaren Quellenverweisen."}, {"key": "WFS", "name": "Workflow-Vorschläge", "emoji": "💡", "color": "#C2410C", "description": "Routing- und Klassifizierungsvorschläge aus Historie, gekoppelt an das Workflow-Board über den Modul-Adapter."}, {"key": "GOV", "name": "Datenschutz & Governance", "emoji": "🛡️", "color": "#BE185D", "description": "Modul-Adapter-Schnittstelle, Opt-in/Opt-out, Datenresidenz-Kontrolle, Kostenkontrolle und Nachvollziehbarkeit von KI-Entscheidungen."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab."}], "waves": [{"welle": 1, "codes": ["ENG-01", "QA-01"]}, {"welle": 2, "codes": ["ENG-02", "ENG-03", "ENG-04", "ENG-05", "ENG-06"]}, {"welle": 3, "codes": ["CLS-01", "EXT-01", "GOV-01", "GOV-03", "GOV-04", "QA-02", "SEM-01", "SUM-01", "SUM-02"]}, {"welle": 4, "codes": ["CLS-02", "CLS-03", "CLS-04", "CLS-05", "EXT-02", "EXT-03", "GOV-02", "GOV-05", "GOV-06", "QA-07", "SEM-02", "SUM-03", "SUM-04", "WFS-01"]}, {"welle": 5, "codes": ["EXT-04", "EXT-05", "QA-05", "SEM-03", "WFS-02"]}, {"welle": 6, "codes": ["QA-03", "SEM-04", "WFS-03"]}, {"welle": 7, "codes": ["QA-08", "SEM-05", "SEM-06"]}, {"welle": 8, "codes": ["QA-04"]}, {"welle": 9, "codes": ["QA-06"]}, {"welle": 10, "codes": ["GOV-07", "ENG-07"]}], "kritischerPfad": {"tage": 26, "pfad": ["ENG-01", "ENG-05", "SEM-01", "SEM-02", "SEM-03", "SEM-04", "SEM-06", "QA-04", "QA-06"]}, "produktDna": {"uebernehmen": [{"produkt": "Ollama", "staerke": "Lokale Modell-Bereitstellung als einfache, austauschbare Standardanbindung – on-premise first."}, {"produkt": "LangChain/LlamaIndex (Konzept)", "staerke": "RAG-Grundmuster: Retrieval vor Generation, Quellenverweise werden konsequent mitgeführt – bewusst schlanker umgesetzt, kein schweres Framework."}, {"produkt": "Docspell", "staerke": "Strukturierte Extraktion konkreter Werte als Vorschlag mit Konfidenz, keine automatische Übernahme ohne Bestätigung."}], "vermeiden": [{"produkt": "Schwergewichtige Agent-Frameworks", "risiko": "Hoher Ressourcen- und Konfigurationsaufwand ohne Mehrwert für die klar umrissenen KI-Funktionen dieses Moduls.", "loesung": "Schlanke Provider-Abstraktion und eine schmale RAG-Pipeline statt vollem Orchestrierungs-Framework."}, {"produkt": "Automatische Übernahme von KI-Vorschlägen", "risiko": "Falsch übernommene Werte ohne Kontrolle untergraben Vertrauen in Klassifizierung und Extraktion – Lehre aus Docspell/paperless-ngx im DMS-Board.", "loesung": "Jeder Vorschlag trägt Konfidenz und verlangt Bestätigung, konsequent über alle Funktionen hinweg."}]}, "epicDna": {"ENG": {"leitsatz": "Ollama als einfache, austauschbare Modell-Bereitstellung – lokal zuerst, Cloud optional dahinter.", "uebernehmen": ["Ollama: einfache, lokale Modell-Bereitstellung als Standardbetrieb, kein schwerer Cloud-Zwang.", "Klar geschnittene Provider-Abstraktion, damit ein Anbieter ohne Umbau der Aufrufer ausgetauscht werden kann."], "vermeiden": ["Kein schwergewichtiges Agent-Framework als Voraussetzung – schlanke Provider-Schnittstelle genügt.", "Keine versteckte Standardwahl externer Cloud-Anbieter ohne ausdrückliche Konfiguration."]}, "CLS": {"leitsatz": "Docspell-Konfidenz trifft auf ein verständliches Grundmodell – vorschlagen statt entscheiden.", "uebernehmen": ["Docspell: Konfidenzwerte statt binärer Ja/Nein-Entscheidungen bei jeder automatischen Zuordnung.", "Verständliches Grundmodell aus Kategorie, Typ und Tags, das ohne Schulung begreifbar bleibt."], "vermeiden": ["Keine automatische Übernahme ohne Bestätigung. Vorschläge werden mit Sicherheitsgrad angezeigt und freigegeben."]}, "EXT": {"leitsatz": "Die ExtraktionsqualitLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

ai-kanban/tickets/ENG-07.md

@@ -0,0 +1,58 @@
+# ENG-07 – Ressourcenlimits für die Inferenz-Warteschlange
+
+**Epic:** 🧠 KI-Engine & Modell-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH AI (KI-Engine & Modell-Anbindung, Klassifizierung, Extraktion, Zusammenfassung, semantische Suche & Chat, Workflow-Vorschläge, Datenschutz & Governance), lokal/On-Premise-first via Ollama, optionaler externer Adapter, kein Training auf Kundendaten.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-05 stellt eine asynchrone Warteschlange für Inferenz-Aufrufe bereit, damit lange KI-Anfragen keine Anfrage-Bearbeitung blockieren, ohne Obergrenzen pro Einzelanfrage festzulegen. Eine sehr lange Eingabe (z. B. ein extrem langes Dokument bei Zusammenfassung/Embedding) oder eine bewusst konstruierte Anfrage kann einen Inferenz-Worker unverhältnismäßig lange blockieren und damit andere Mandanten in der gemeinsamen Warteschlange verzögern. Harte Obergrenzen je Anfrage definieren (max. Eingabegröße/Kontextlänge, max. Verarbeitungszeit) – bei Überschreitung wird die Anfrage kontrolliert abgelehnt statt den Worker zu blockieren.
+
+**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Eingabegröße/Kontextlänge)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Unleash: konfigurierbare Grenzen (Quotas) statt unbegrenzter Ressourcennutzung, hier auf Inferenz-Anfragen übertragen.
+
+**Bewusst vermeiden:**
+- LangChain/LlamaIndex (verbreitetes Anti-Muster in einfachen Integrationen) – unbegrenzte Kontextlängen führen zu unvorhersehbaren Latenzen/Kosten.: harte, konfigurierbare Obergrenzen je Anfrage von Anfang an.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-05.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Inferenz-Anfrage hat konfigurierbare Obergrenzen für Eingabegröße/Kontextlänge und maximale Verarbeitungszeit
+2. Eine Überschreitung führt zur kontrollierten Ablehnung der Anfrage mit klarer Fehlermeldung, nicht zur Blockade des Workers
+3. Andere, gleichzeitig laufende Inferenz-Anfragen (auch anderer Mandanten) bleiben von einer überschreitenden Anfrage unbeeinflusst
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit einer Eingabe, die absichtlich die Kontextlängen-/Größenobergrenze überschreitet: Anfrage wird kontrolliert abgelehnt
+2. Lasttest: eine überschreitende Anfrage blockiert nicht die Verarbeitung paralleler, regulärer Anfragen
+3. Regressionstest: normale, innerhalb der Grenzen liegende Anfragen funktionieren unverändert
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (AI-Board, 2026-09-12), analog zu DMS-Finding `FDN-11` und Mail-Finding `SRC-12`: unbegrenzte Einzelanfrage-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Inferenz-Worker-Pool, auch ohne böswillige Absicht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-05` Inferenz-Queue
+
+## 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: `ENG-07: ressourcenlimits-f-r-die-inferenz-warteschlange`
+- Branch: `feature/eng-07-ressourcenlimits-f-r-die-inferenz-warteschlange`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

ai-kanban/tickets/GOV-07.md

@@ -0,0 +1,58 @@
+# GOV-07 – Unabhängige Tenant-Validierung bei KI-Objekttyp-Registrierung durch DMS/Mail
+
+**Epic:** 🛡️ Datenschutz & Governance  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH AI (KI-Engine & Modell-Anbindung, Klassifizierung, Extraktion, Zusammenfassung, semantische Suche & Chat, Workflow-Vorschläge, Datenschutz & Governance), lokal/On-Premise-first via Ollama, optionaler externer Adapter, kein Training auf Kundendaten.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+GOV-01 nimmt Registrierungen KI-fähiger Objekttypen und Felder von DMS und Mail entgegen. Analog zu Archive `RET-12` und Workflow `ENG-06` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen – sonst könnte eine Kompromittierung/Fehlkonfiguration in DMS/Mail dazu führen, dass KI-Funktionen (Klassifizierung, Extraktion, semantische Suche) auf falsch zugeordnete Tenant-Daten angewendet werden.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der meldenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: AI verifiziert den Tenant-Kontext jeder eingehenden Registrierung selbst gegen die Core-Registry.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: GOV-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Objekttyp-/Feld-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+2. Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+3. Bestehende, korrekte Registrierungsabläufe aus GOV-01 funktionieren 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: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+2. Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (AI-Board, 2026-09-12), analog zu Archive-Finding `RET-12` und Workflow-Finding `ENG-06`: AI ist die Senke für Objekttyp-Registrierungen aus zwei anderen Modulen — ohne eigene Validierung würde ein Fehler oder eine Kompromittierung in DMS/Mail unmittelbar auf KI-Funktionen durchschlagen, die dann potenziell mit falscher Tenant-Zuordnung auf Inhalte angewendet werden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `GOV-01` Modul-Adapter-Schnittstelle (DMS/Mail registrieren KI-fähige Objekttypen)
+
+## 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: `GOV-07: unabh-ngige-tenant-validierung-bei-ki-objekttyp-registrierung-durch-dms-mail`
+- Branch: `feature/gov-07-unabh-ngige-tenant-validierung-bei-ki-objekttyp-registrierung-durch-dms-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.

archive-kanban/README.md

@@ -0,0 +1,92 @@
+# Archive-Kanban – lokal abarbeiten
+
+40 Arbeitskacheln · 5 Epics · 93 Personentage · 7 Wellen (inkl. Welle 7: Threat-Model-Nachtrag 2026-09-12 — RET-11, RET-12, BAK-09, BAK-10).
+
+Hinweis: Dieses Board ist die alleinige Quelle für Aufbewahrung/WORM/Compliance/Backup. DMS-Board und Mail-Board referenzieren dieses Board extern in der Ausgangslage betroffener Tickets, statt eigene Retention-Logik zu implementieren.
+Stand: 2026-08-26
+
+## 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 (`RET-01.md` …).
+Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage,
+Akzeptanzkriterien, Prüfungen und Abschlussregeln.
+
+- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren.
+- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen.
+- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch.
+
+## Weg 4 – Eigenes Board im Netzwerk (Team)
+
+Selbst gehostet, jeweils mit CSV-Import:
+
+```bash
+# Focalboard
+docker run -d -p 8000:8000 --name focalboard mattermost/focalboard
+
+# Planka
+docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest
+
+# Vikunja
+docker run -d -p 3456:3456 --name vikunja vikunja/vikunja
+```
+
+Danach `board.csv` importieren.
+
+## Reihenfolge der Arbeit
+
+Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar,
+sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen.
+
+- **Welle 1** (5 Kacheln): RET-01, CMP-04, BAK-01, BAK-02, QA-01
+- **Welle 2** (8 Kacheln): RET-02, RET-04, RET-05, CMP-01, CMP-02, BAK-03, BAK-05, BAK-07
+- **Welle 3** (9 Kacheln): RET-03, RET-06, RET-07, CMP-03, CMP-05, BAK-04, BAK-06, ANA-01, QA-06
+- **Welle 4** (5 Kacheln): CMP-06, ANA-02, ANA-03, QA-02, QA-04
+- **Welle 5** (1 Kachel): QA-03
+- **Welle 6** (1 Kachel): QA-05
+
+Kritischer Pfad (16 PT): RET-01 → RET-02 → RET-03 → CMP-06 → QA-03 → QA-05
+
+## Produkt-DNA
+
+### Übernehmen
+- **Alfresco**: Retention Policies mit Stichtagsberechnung, revisionssichere Ablage und Aufbewahrungssperre (Legal Hold).
+- **Alfresco**: Vier-Augen-Prinzip bei Freigaben, insbesondere bei Löschungen.
+- **ecoDMS**: Revisionssicherheit als Grundhaltung – unveränderliches Protokoll, nachvollziehbare Vernichtung.
+- **restic/Borg**: Inkrementelle, deduplizierende Sicherung mit eingebauter Verifikation und routinemäßigem Restore-Test.
+
+### Vermeiden
+- **Alfresco – schwergewichtige Plattform mit hohem Ressourcenbedarf und trägem Betrieb.**: Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur.
+
+## 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).

archive-kanban/board.csv

@@ -0,0 +1,208 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+RET-01,Generisches Retention-Objektmodell,⏳ Retention & WORM,Backend,Mittel,3,1,Fertig,"PostgreSQL, pgx/v5, SQL-Migrationen (kein ORM)","Generisches Datenmodell für aufbewahrungspflichtige Objekte anlegen: Objekttyp, Objekt-Referenz (modulübergreifend über Adapter), Aufbewahrungsklasse, Status. Migrationen versioniert und rückrollbar.",,RET-02 RET-04 RET-05 CMP-01 CMP-02,"Objektmodell bildet beliebige Objekttypen aus DMS und Mail ab, ohne modulspezifische Spalten
+Aufbewahrungsklasse ist je Objekt eindeutig zugeordnet und historisierbar
+Migration läuft gegen leere Datenbank durch und ist rückrollbar","Migration vorwärts und rückwärts getestet
+Testobjekt aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet
+Tenant-Isolation der Kern-Tabellen durch Negativtest belegt"
+RET-02,Aufbewahrungsfristen-Engine,⏳ Retention & WORM,Backend,Mittel,3,2,Fertig,"PostgreSQL, Postgres-Jobqueue (geplante Jobs statt Redis)","Fristenmodell je Aufbewahrungsklasse mit Stichtagsberechnung (Beginn, Dauer, Ablaufdatum) und periodischem Job, der ablaufende Objekte ermittelt.",RET-01,RET-03 RET-06 RET-07,"Frist wird je Aufbewahrungsklasse konfiguriert und auf jedes zugeordnete Objekt angewendet
+Stichtag wird korrekt aus Beginn- und Dauerangabe berechnet, inklusive Kalenderfällen (Schaltjahr, Monatsende)
+Periodischer Job liefert Liste ablaufender Objekte je Tenant","Fristberechnung an Referenzdaten mit bekannten Ablaufdaten geprüft
+Job liefert bei leerem Bestand ein leeres, nicht fehlerhaftes Ergebnis
+Mehrfachausführung des Jobs erzeugt keine doppelten Einträge"
+RET-03,Löschworkflow & Aufbewahrungssperre (Legal Hold),⏳ Retention & WORM,Backend,Mittel,3,3,Fertig,"PostgreSQL, transaktionaler Zustandswechsel","Löschworkflow für abgelaufene Objekte: Freigabe, Vernichtung, Protokolleintrag. Aufbewahrungssperre (Legal Hold) verhindert jede Löschung unabhängig vom Fristablauf.",RET-02,CMP-06 QA-02 CMP-07 QA-07,"Ablauf der Frist löst einen Freigabeprozess aus, keine automatische Sofortlöschung
+Aufbewahrungssperre verhindert Löschung auch bei abgelaufener Frist, mit Begründungspflicht beim Setzen
+Jede Vernichtung erzeugt einen unveränderlichen Protokolleintrag mit Zeitpunkt und ausführender Person","Objekt mit aktiver Sperre widersteht einem direkten Löschversuch
+Protokolleintrag nach Vernichtung ist nachträglich nicht änderbar (DB-Constraint oder Trigger)
+Aufheben einer Sperre ist selbst protokolliert"
+RET-04,WORM-Speicher-Garantie (Append-only),⏳ Retention & WORM,Backend,Mittel,3,2,Fertig,"Objekt-Storage-Anbindung, Append-only-Schreibpfad","Speicherpfad für archivierte Objektinhalte, der nach dem Schreiben keine Änderung und kein Überschreiben mehr zulässt (Write Once, Read Many).",RET-01,QA-02 RET-11,"Einmal geschriebener Objektinhalt kann nicht überschrieben werden
+Loeschung ist ausschliesslich ueber den kontrollierten Loeschworkflow moeglich, nicht ueber die Go-API dieses Pakets (keine Delete-Funktion) - struktureller Schutz auf Anwendungsebene, kein absoluter Schutz gegen root-OS-Zugriff
+Prüfsumme je Objekt wird beim Schreiben erzeugt und bei jedem Lesezugriff verglichen","Direkter Überschreibversuch am Speicherpfad wird abgewiesen
+Prüfsummenabgleich erkennt eine manipulierte Testdatei zuverlässig
+Loeschung ist ueber die Go-API des Pakets technisch unmoeglich (keine Delete-Funktion vorhanden), nicht nur per Konvention verboten"
+RET-05,Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen),⏳ Retention & WORM,Backend,Mittel,3,2,Fertig,"REST-Schnittstelle, Registrierungs-API","Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.",RET-01,CMP-03 ANA-01 CMP-07 QA-07 RET-12,"Modul kann einen Objekttyp mit Aufbewahrungsklasse und Rückruf-Adresse für Löschbestätigung registrieren
+Archive ruft das registrierte Modul beim Vernichten des Objekts zurück, statt selbst Modul-Interna zu kennen
+Registrierung ist idempotent und mandantenfähig","Zwei fiktive Module (DMS, Mail) parallel registriert ohne Kollision
+Rückruf bei Vernichtung erfolgreich gegen einen Testendpunkt ausgeführt
+Erneute Registrierung desselben Objekttyps ändert nichts am bestehenden Zustand"
+RET-06,Aufbewahrungsfristen-Konfigurationsoberfläche,⏳ Retention & WORM,Frontend,Mittel,3,3,Fertig,Next.js/React/TypeScript,"Next.js/React-Oberflaeche zur Pflege von Aufbewahrungsklassen und Fristen je Objekttyp und Tenant, inklusive Vorschauliste bald ablaufender Objekte. Backend-API bereits fertig (RET-06-API), RBAC-Provisorium darin durch RET-08 auf echtes RBAC-06 migriert - dieses Ticket ist reiner Frontend-Scope.",RET-02 RET-06-API RET-08,QA-02,"Aufbewahrungsklasse mit Frist lässt sich anlegen, ändern und deaktivieren
+Vorschauliste zeigt in den nächsten 30 Tagen ablaufende Objekte
+Änderungen an Fristen sind nur berechtigten Rollen zugänglich","Änderung einer Frist wirkt sich nur auf künftige Berechnungen aus, nicht rückwirkend auf bereits protokollierte Vernichtungen
+Nicht berechtigte Rolle erhält keinen Zugriff auf die Konfiguration
+Vorschauliste stimmt mit dem Ergebnis des periodischen Jobs überein"
+RET-07,Fristablauf-Benachrichtigungen,⏳ Retention & WORM,Backend,Einfach,2,3,Fertig,Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher),"Benachrichtigung verantwortlicher Personen vor Ablauf einer Aufbewahrungsfrist, konfigurierbarer Vorlauf je Aufbewahrungsklasse. Der eigentliche Versand läuft ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), erreichbar über den HTTP-Wrapper CFG-05 (Archive kann internal/notifyprefs nicht direkt importieren) – Archive erzeugt nur das Ereignis, versendet keine E-Mail selbst. Empfaenger ist eine konfigurierte zustaendige Rolle (Tenant-Admin), kein Objekt-Owner — RET-01 fuehrt bewusst keine Owner-Beziehung.",RET-02 CFG-05,QA-02,"Benachrichtigung wird im konfigurierten Vorlauf vor Fristablauf als Ereignis an Core CFG-02 (ueber CFG-05) uebergeben, adressiert an eine konfigurierte zustaendige Rolle (Tenant-Admin), nicht selbst versendet
+Mehrfachversand derselben Benachrichtigung wird verhindert
+Benachrichtigung lässt sich je Aufbewahrungsklasse ein- und ausschalten","Testfrist mit kurzem Vorlauf löst genau eine Benachrichtigung aus
+Deaktivierte Benachrichtigung verschickt nachweislich nichts
+Fehlgeschlagener Versand wird protokolliert und nicht stillschweigend verworfen"
+CMP-01,GoBD-Verfahrensdokumentation,⚖️ Compliance & eDiscovery,Backend,Mittel,3,2,Backlog,"PDF-Export, versionierte Dokumentvorlage","Exportierbare Verfahrensdokumentation gemäß GoBD: Beschreibung der Aufbewahrungs-, Zugriffs- und Löschverfahren, automatisch aus der aktuellen Konfiguration erzeugt.",RET-01,CMP-05 QA-03,"Dokumentation wird automatisiert aus der aktuellen Retention-Konfiguration erzeugt, nicht manuell gepflegt
+Export liegt als versioniertes PDF mit Erzeugungsdatum vor
+Änderung an Aufbewahrungsklassen spiegelt sich in der nächsten Erzeugung wider","Erzeugtes Dokument enthält alle aktiven Aufbewahrungsklassen mit Fristen
+Zwei aufeinanderfolgende Exporte ohne Konfigurationsänderung sind inhaltlich identisch
+Export einer zweiten Person als GoBD-tauglich nachvollzogen"
+CMP-02,DSGVO-/Datenschutz-Berichte,⚖️ Compliance & eDiscovery,Backend,Mittel,3,2,Fertig,PDF/CSV-Export,"Berichte für Auskunftsersuchen, Verarbeitungsübersichten und Zugriffsnachweise je betroffener Person und Tenant.",RET-01,CMP-05 CMP-07,"Auskunftsbericht listet alle gespeicherten Objekte einer betroffenen Person mit Aufbewahrungsklasse
+Verarbeitungsübersicht zeigt Zweck und Rechtsgrundlage je Objekttyp
+Export ist mandantenscharf und enthält keine Daten anderer Tenants","Auskunftsbericht für Testperson mit bekanntem Datenbestand stimmt mit erwarteter Liste überein
+Bericht für einen Tenant enthält keine Objekte eines anderen Tenants
+Export lässt sich als CSV weiterverarbeiten"
+CMP-03,eDiscovery-Suche & Export (modulübergreifend),⚖️ Compliance & eDiscovery,Backend,Komplex,4,3,Backlog,"Modulübergreifende Such-API, ZIP-Export mit Prüfsummen","Suche über registrierte Objekttypen aus DMS und Mail hinweg für Rechtsverfahren, mit vollständigem, prüfsummengesichertem Export der Treffer.",RET-05,QA-03,"Suche liefert Treffer aus mehreren registrierten Modulen in einer gemeinsamen Ergebnisliste
+Export enthält Originalobjekte, Metadaten und eine Prüfsummenliste je Datei
+Suchlauf und Export werden als eigener Vorgang protokolliert (wer, wann, welche Kriterien)","Testsuche über zwei fiktive Module liefert erwartete kombinierte Trefferzahl
+Prüfsumme jeder exportierten Datei stimmt nach Entpacken überein
+Protokolleintrag zum Suchlauf ist nachträglich nicht veränderbar"
+CMP-04,Audit-Trail-Kopplung an Core-Audit-Log,⚖️ Compliance & eDiscovery,Backend,Einfach,2,1,Backlog,REST-Anbindung an NEXARCH Core Audit-Log,"Alle sicherheitsrelevanten Vorgänge in Archive (Fristsetzung, Sperre, Löschung, Export) werden an das zentrale Audit-Log in NEXARCH Core gemeldet, statt ein eigenes Protokoll zu führen.",AUD-01,QA-03,"Jeder sicherheitsrelevante Vorgang erzeugt einen Eintrag im zentralen Audit-Log
+Eintrag enthält Tenant, handelnde Person, Vorgang und Zeitstempel
+Ausfall des Audit-Log-Dienstes blockiert nicht den Fachvorgang, wird aber sichtbar nachgemeldet","Testvorgänge (Sperre setzen, Löschung, Export) erzeugen je einen nachvollziehbaren Audit-Eintrag
+Simulierter Ausfall des Audit-Dienstes verhindert nicht die Fachfunktion
+Nachmeldung nach Ausfallende ist vollständig, keine Lücke im Protokoll"
+CMP-05,Compliance-Berichts-Oberfläche,⚖️ Compliance & eDiscovery,Frontend,Mittel,3,3,Backlog,Next.js/React/TypeScript,"Oberfläche zum Anfordern, Einsehen und Herunterladen von GoBD-Verfahrensdokumentation und DSGVO-Berichten je Tenant.",CMP-01 CMP-02,QA-03,"Berichte lassen sich mit wenigen Klicks anfordern und herunterladen
+Nur berechtigte Rollen sehen Berichte anderer Personen ein
+Historie angeforderter Berichte ist je Tenant einsehbar","Anforderung eines Berichts löst den zugehörigen Backend-Export korrekt aus
+Nicht berechtigte Rolle erhält keinen Zugriff auf fremde Berichte
+Downloadlink eines abgelaufenen Berichts wird abgewiesen"
+CMP-06,Vier-Augen-Freigabe für Löschungen,⚖️ Compliance & eDiscovery,Backend,Mittel,3,4,Fertig,"PostgreSQL mit FOR UPDATE-Lock, Timing-safe Vergleich","Löschung abgelaufener Objekte erfordert eine zweite, unabhängige Bestätigung durch eine andere Person, bevor der Löschworkflow ausgeführt wird.",RET-03,QA-03 CMP-07,"Löschung wird erst nach zweiter Bestätigung durch eine von der anfordernden Person verschiedene Rolle ausgeführt
+Gleichzeitige Bestätigungsversuche führen nicht zu doppelter Ausführung
+Löschbestätigung wird mit einem geheimen, zeitlich begrenzten Bestätigungs-Token abgesichert","Zwei parallele Bestätigungsanfragen auf dasselbe Objekt: genau eine Löschung wird ausgeführt (Lock-Test)
+Bestätigung durch dieselbe Person wie die Anforderung wird abgewiesen
+Vergleich des Bestätigungs-Tokens erfolgt zeitkonstant und ist gegen Timing-Angriffe getestet"
+BAK-01,Datenbank-Backup-Strategie,💾 Backup & Wiederherstellung,Backend,Mittel,3,1,Fertig,"PostgreSQL (pg_dump/pg_basebackup), inkrementelle Sicherung","Automatisierte, inkrementelle Sicherung der PostgreSQL-Datenbank mit Aufbewahrung mehrerer Generationen und Verifikation jeder Sicherung.",,BAK-03 BAK-05 BAK-07 BAK-09,"Vollsicherung und inkrementelle Sicherung laufen automatisiert nach Zeitplan
+Jede Sicherung wird nach Abschluss auf Lesbarkeit verifiziert, nicht nur auf Erstellung geprüft
+Mehrere Sicherungsgenerationen werden nach konfigurierbarer Regel vorgehalten und alte automatisch entfernt","Sicherung gegen Testdatenbank erfolgreich erstellt und verifiziert
+Verifikation erkennt eine absichtlich beschädigte Sicherungsdatei
+Rotationsregel entfernt nachweislich nur die ältesten Generationen"
+BAK-02,Objekt-Storage-Backup/Snapshots,💾 Backup & Wiederherstellung,Backend,Mittel,3,1,Fertig,"Objekt-Storage-Snapshots, inkrementell und deduplizierend","Automatisierte, deduplizierende Sicherung der im Objekt-Storage abgelegten Dateiinhalte, angelehnt an das restic/Borg-Sicherungskonzept.",,BAK-03 BAK-05 BAK-07 BAK-09,"Sicherung erfasst neue und geänderte Objekte inkrementell, ohne unveränderte Objekte erneut zu übertragen
+Sicherung ist deduplizierend, identische Inhalte werden nur einmal gespeichert
+Jede Sicherung lässt sich einzeln auf Vollständigkeit prüfen","Zweiter Sicherungslauf nach unverändertem Bestand überträgt keine Daten erneut
+Zwei identische Testdateien belegen nachweislich nur einmal Speicherplatz
+Vollständigkeitsprüfung erkennt ein fehlendes Objekt in der Sicherung"
+BAK-03,Restore-Verfahren,💾 Backup & Wiederherstellung,Backend,Mittel,3,2,Fertig,Atomarer Restore über temporäres Verzeichnis,"Dokumentiertes, wiederholbares Verfahren zur Wiederherstellung von Datenbank und Objekt-Storage aus einer Sicherung, für Notfall wie für Einzelobjekt-Restore.",BAK-01 BAK-02,BAK-04 BAK-06,"Restore stellt Datenbank und Objekt-Storage aus einer gewählten Sicherungsgeneration wieder her
+Restore in ein nicht-leeres Zielverzeichnis beschädigt den bestehenden Inhalt nicht, solange der Vorgang nicht bestätigt wird
+Restore-Vorgang wird protokolliert (Quelle, Zeitpunkt, Ergebnis)","Restore auf leerem System vollständig und erfolgreich durchgeführt
+Restore auf nicht-leeres Zielverzeichnis lässt bei Abbruch den ursprünglichen Inhalt unverändert
+Protokolleintrag zum Restore ist vollständig und nachvollziehbar"
+BAK-04,Tenant-Backup & -Restore (einzelner Mandant),💾 Backup & Wiederherstellung,Backend,Mittel,3,3,Fertig,Tenant-scharfer Export/Import auf Basis von BAK-03,"Sicherung und Wiederherstellung der Daten eines einzelnen Mandanten, ohne andere Mandanten zu berühren – etwa für Mandanten-Umzug oder isolierte Notfallwiederherstellung.",BAK-03,QA-04,"Sicherung eines Tenants enthält ausschließlich dessen Daten aus Datenbank und Objekt-Storage
+Wiederherstellung eines Tenants verändert keine Daten anderer Tenants
+Tenant-Sicherung lässt sich unabhängig vom Gesamt-Backup planen und ausführen","Sicherung von Tenant A enthält keine Datensätze von Tenant B (Stichprobe)
+Wiederherstellung von Tenant A in eine Testumgebung verändert Tenant B dort nicht
+Tenant-Sicherung und -Restore vollständig protokolliert"
+BAK-05,Reconciliation (Konsistenzprüfung Storage vs. DB),💾 Backup & Wiederherstellung,Backend,Mittel,3,2,Fertig,"Geplanter Abgleichs-Job, Postgres-Jobqueue","Periodische Prüfung, ob jeder in der Datenbank referenzierte Objekt-Storage-Eintrag tatsächlich existiert und umgekehrt, mit Bericht über Abweichungen.",BAK-01 BAK-02,QA-04,"Job erkennt Datenbankeinträge ohne zugehöriges Objekt im Storage
+Job erkennt Objekte im Storage ohne zugehörigen Datenbankeintrag
+Abweichungen werden berichtet, nicht automatisch stillschweigend behoben","Absichtlich entferntes Storage-Objekt wird vom Job als Abweichung erkannt
+Absichtlich verwaister Datenbankeintrag wird vom Job als Abweichung erkannt
+Lauf ohne Abweichungen liefert einen leeren, eindeutig als sauber erkennbaren Bericht"
+BAK-06,Restore-Testverfahren,💾 Backup & Wiederherstellung,Backend,Einfach,2,3,Fertig,"Automatisierter, periodischer Restore-Test in Testumgebung","Regelmäßiger, automatisierter Testlauf des Restore-Verfahrens gegen eine isolierte Testumgebung, mit Ergebnisprotokoll als Nachweis der Wiederherstellbarkeit.",BAK-03,QA-04 BAK-10,"Testlauf führt einen vollständigen Restore in eine isolierte Testumgebung durch
+Ergebnis (erfolgreich/fehlgeschlagen) wird mit Zeitstempel protokolliert
+Fehlgeschlagener Testlauf löst eine sichtbare Warnung aus","Geplanter Testlauf gegen aktuelle Sicherung erfolgreich durchgeführt und protokolliert
+Absichtlich beschädigte Sicherung lässt den Testlauf sichtbar fehlschlagen
+Protokollhistorie zeigt mehrere zurückliegende Testläufe nachvollziehbar an"
+ANA-01,Kennzahlen-Aggregation (modulübergreifend),📊 Kennzahlen & Reporting,Backend,Mittel,3,3,Backlog,Aggregations-Job über registrierte Module,"Zentraler Dienst, der Kennzahlen (Objektbestand, Aufbewahrungsstatus, Löschvorgänge, Speichervolumen) aus allen über RET-05 registrierten Modulen aggregiert.",RET-05,ANA-02 ANA-03 QA-05,"Kennzahlen werden je Tenant und Modul sowie modulübergreifend aggregiert
+Aggregation läuft periodisch und liefert konsistente Werte über einen Zeitverlauf
+Neues registriertes Modul wird ohne Codeänderung in die Aggregation einbezogen","Aggregation über zwei fiktive Module liefert korrekte Summen- und Einzelwerte
+Wiederholte Aggregation ohne Datenänderung liefert stabile Ergebnisse
+Neu registriertes drittes Testmodul erscheint automatisch in der nächsten Aggregation"
+ANA-02,Auswertungs-Dashboard,📊 Kennzahlen & Reporting,Frontend,Mittel,3,4,Backlog,Next.js/React/TypeScript,"Dashboard zur Visualisierung der aggregierten Kennzahlen mit Filtern nach Tenant, Modul und Zeitraum.",ANA-01,QA-05,"Dashboard zeigt Bestands-, Aufbewahrungs- und Löschkennzahlen je Tenant
+Filter nach Modul und Zeitraum funktionieren kombinierbar
+Dashboard lädt auch bei großem Datenbestand in angemessener Zeit","Filterkombination liefert dieselben Werte wie eine direkte Abfrage der Aggregation
+Dashboard mit synthetisch großem Testbestand bleibt bedienbar
+Rollen ohne Berechtigung sehen keine Kennzahlen fremder Tenants"
+ANA-03,Lizenz-/Nutzungs-Reports,📊 Kennzahlen & Reporting,Backend,Einfach,2,4,Backlog,CSV/PDF-Export,"Bericht über Nutzung und Lizenzrelevantes je Tenant (Speichervolumen, aktive Objekte, Nutzeranzahl-Bezug), abgestimmt mit dem Lizenzmodell aus NEXARCH Core.",ANA-01,QA-05,"Bericht zeigt lizenzrelevante Nutzungswerte je Tenant für einen wählbaren Zeitraum
+Werte stimmen mit der zugrunde liegenden Kennzahlen-Aggregation überein
+Export ist als CSV und PDF verfügbar","Bericht für Testzeitraum stimmt mit manuell nachgerechneten Werten überein
+Export in beiden Formaten enthält identische Kernwerte
+Bericht für Tenant ohne Aktivität liefert nachvollziehbar leere/Null-Werte statt Fehler"
+QA-01,Teststrategie Archive,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Backlog,"Testplan-Dokument, Testdatensatz-Konzept","Teststrategie für das Archive-Board festlegen: Testebenen, Referenzdatensatz für Retention/WORM/Backup, Verantwortlichkeiten je Prüfgate.",,,"Teststrategie benennt Testebenen (Unit, Integration, Wiederherstellungstest) und deren Verantwortliche
+Referenzdatensatz für Retention- und Backup-Tests ist definiert und wiederverwendbar
+Strategie ist als Dokument abgelegt und von zweiter Person gegengelesen
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Referenzdatensatz lässt sich reproduzierbar in einer Testumgebung aufsetzen
+Zweite Person bestätigt schriftlich die Nachvollziehbarkeit der Strategie
+Strategie deckt erkennbar alle folgenden Prüfgates ab (Abgleich mit QA-02 bis QA-05)"
+QA-02,Prüfgate Retention & WORM,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,4,Backlog,Abnahmeprotokoll,"Prüfgate für Fristenengine, Löschworkflow, Aufbewahrungssperre und WORM-Garantie vor Freigabe der Retention-Funktionen.",RET-04 RET-03 RET-06 RET-07,QA-05,"Alle Akzeptanzkriterien von RET-03 und RET-04 sind gegen den Referenzdatensatz nachgewiesen
+Versuch, eine gesperrte oder WORM-geschützte Ablage zu umgehen, scheitert nachweislich
+Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt","Löschversuch an gesperrtem Objekt schlägt fehl (Wiederholung des RET-03-Tests unter Prüfgate-Bedingungen)
+Überschreibversuch am WORM-Speicher schlägt fehl (Wiederholung des RET-04-Tests unter Prüfgate-Bedingungen)
+Offene Restrisiken sind schriftlich benannt"
+QA-03,Prüfgate Compliance & eDiscovery,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Backlog,Abnahmeprotokoll,Prüfgate für eDiscovery-Export und Vier-Augen-Freigabe vor Freigabe der Compliance-Funktionen.,CMP-03 CMP-06 CMP-07 CMP-01 CMP-04 CMP-05,QA-05,"eDiscovery-Export wird gegen den Referenzdatensatz erneut durchgeführt und geprüft
+Vier-Augen-Freigabe wird mit zwei unabhängigen Testrollen erneut nachgewiesen
+Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt","Export-Prüfsummen stimmen bei wiederholtem Testlauf erneut überein
+Löschversuch durch dieselbe Person ohne zweite Bestätigung scheitert erneut
+Offene Restrisiken sind schriftlich benannt"
+QA-04,Prüfgate Backup & Restore,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,4,Fertig,"Abnahmeprotokoll, realer Wiederherstellungstest","Prüfgate für Backup-Strategie und Restore-Verfahren vor Freigabe der Backup-Funktionen, inklusive einem real durchgeführten Wiederherstellungstest.",BAK-06 BAK-04 BAK-05 BAK-07,QA-05,"Restore wird real auf ein leeres Testsystem durchgeführt und dokumentiert
+Reconciliation nach Restore zeigt keine Abweichungen zwischen Storage und Datenbank
+Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt","Realer Restore-Testlauf erfolgreich und protokolliert
+Reconciliation nach dem Testlauf liefert einen sauberen Bericht
+Offene Restrisiken sind schriftlich benannt"
+QA-05,Abnahme- & Compliance-Prüfung Archive,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Backlog,Abnahmeprotokoll,"Gesamtabnahme des Archive-Boards vor Freigabe: Retention/WORM, Compliance/eDiscovery und Backup/Restore müssen alle bestanden sein.",QA-02 QA-03 QA-04 QA-06 QA-07 ANA-01 ANA-02 ANA-03 BAK-08,,"Alle drei fachlichen Prüfgates (QA-02, QA-03, QA-04) sind bestanden
+Gesamtprotokoll fasst alle drei Prüfgates mit Ergebnis zusammen
+Abnahmeprotokoll ist unterzeichnet","Zusammenfassung aller drei Prüfgates gegen die jeweiligen Einzelprotokolle abgeglichen
+Offene Restrisiken aus allen drei Gates sind konsolidiert und schriftlich benannt
+Freigabeentscheidung ist dokumentiert"
+QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Backlog,"Vertragstests (Consumer-Driven Contracts), CI-Pipeline","Vertragstests für die Modul-Adapter-Schnittstelle (RET-05), über die DMS und Mail Objekte bei der Retention-Engine registrieren – Breaking Changes müssen automatisiert erkannt werden, bevor sie ein konsumierendes Modul stillschweigend bricht.",RET-05,QA-05,"Vertragstests decken RET-05 vollständig ab
+Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen
+Tests laufen automatisiert in der CI","Testlauf gegen aktuellen Stand grün
+Simulierte Breaking Change erkannt
+CI-Integration nachgewiesen"
+BAK-07,Aufbewahrungsfrist für Backup-Snapshots,💾 Backup & Wiederherstellung,Backend,Mittel,3,2,Fertig,"PostgreSQL, Postgres-Jobqueue (geplante Jobs statt Redis)","Eigene, von der Dokumenten-Retention (RET-02) unabhängige Aufbewahrungsfrist für Backup-Snapshots selbst – nach restic/Borg-Vorbild eine Prune-Policy (z. B. tägliche Snapshots 14 Tage, wöchentliche 3 Monate, monatliche 1 Jahr – konkrete Staffelung als Konfiguration, nicht hart codiert), damit Backups nicht unbegrenzt wachsen, aber auch nicht zu früh gelöscht werden.",BAK-01 BAK-02,QA-04,"Backup-Snapshots folgen einer konfigurierbaren Prune-Policy (Staffelung nach Alter), unabhängig von RET-02
+Snapshot-Löschung nach Ablauf der Frist läuft automatisiert
+Eine gültige, nicht abgelaufene Aufbewahrungssperre auf einem Dokument (RET-03/CMP-06) verhindert nicht das Pruning älterer Backup-Snapshots, solange mindestens ein aktueller Snapshot das Dokument noch enthält","Prune-Test mit simulierten Snapshots über mehrere Altersstufen ergibt korrekte Staffelung
+Automatisierte Löschung abgelaufener Snapshots im Test nachgewiesen
+Legal-Hold-Test bestätigt, dass Pruning nicht mit Dokumenten-Retention kollidiert"
+CMP-07,"DSGVO-Löschantrag (Recht auf Löschung, Art. 17)",⚖️ Compliance & eDiscovery,Backend,Mittel,4,4,Fertig,"PostgreSQL, transaktionaler Zustandswechsel, Modul-Adapter-Schnittstelle (RET-05)","Workflow für den Löschantrag einer betroffenen Person (Art. 17 DSGVO): modulübergreifende Suche (CMP-02), Löschung ohne Aufbewahrungspflicht, begründete Ablehnung mit Aufbewahrungspflicht, Freigabe über CMP-06, vollständiges Protokoll je Objekt.",RET-03 RET-05 CMP-02 CMP-06,QA-03,"Löschantrag findet über die Suche aus CMP-02 alle Objekte einer betroffenen Person, mandantenscharf
+Jedes gefundene Objekt wird EINZELN entschieden: Löschung oder Ablehnung mit Begründung – niemals eine pauschale Sammelentscheidung
+Tatsächliche Löschung durchläuft denselben Vier-Augen-Freigabeprozess wie jede andere Löschung (CMP-06), keine zweite Implementierung
+Ergebnis des Löschantrags (je Objekt: gelöscht/abgelehnt+Grund) ist vollständig und dauerhaft protokolliert","Löschantrag für eine Testperson mit gemischtem Datenbestand liefert exakt eine Löschung und eine begründete Ablehnung
+Aufbewahrungssperre (Legal Hold) verhindert die Löschung auch bei bereits abgelaufener regulärer Frist
+Löschantrag für einen Tenant führt nachweislich zu keiner Aktion an Objekten eines anderen Tenants"
+QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Backlog,"Lastgenerator, Messprotokoll","Lasttest für Archive unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Retention-Prüfpfad (RET-03), Modul-Adapter-Registrierung (RET-05) und WORM-Schreibpfad unter Last.",RET-05 RET-03,QA-05,"Definierte Ziel-Latenz für die Retention-/Legal-Hold-Abfrage unter Last eingehalten
+WORM-Schreibpfad bleibt unter simulierter Last aus zwei gleichzeitig zugreifenden Modulen (DMS und Mail) korrekt und ohne Datenverlust
+Modul-Adapter-Registrierung (RET-05) verkraftet gleichzeitige Registrierung mehrerer Objekttypen ohne Race Condition","Lasttest mit simulierten parallelen Anfragen aus DMS und Mail durchgeführt, Ergebnis dokumentiert
+WORM-Schreibpfad unter Last auf Datenverlust/Race Conditions geprüft
+Gleichzeitige Registrierung mehrerer Objekttypen bei RET-05 getestet"
+BAK-08,Checksum-basierte Objekt-Integritätsprüfung (Scrub-Job),💾 Backup & Wiederherstellung,Backend,Mittel,3,4,Fertig,"Postgres-Jobqueue (FDN-04), SHA-256-Stream-Prüfung, Meldung über Core OPS-05","Periodischer Job, der Stichproben gespeicherter Objekte herunterlädt, deren SHA-256 neu berechnet und mit der in file_revisions.checksum_sha256 (FDN-02) hinterlegten Prüfsumme vergleicht. Ergänzt BAK-05 (reine Existenzprüfung) um Inhalts-Integrität – deckt stille Korruption und Bit-Rot insbesondere auf extern eingebundenem, nicht selbst überwachtem S3-Storage auf.",BAK-05 FDN-04 FDN-09 OPS-05,,"Job zieht periodisch eine konfigurierbare Stichprobe gespeicherter Objekte, lädt sie, berechnet SHA-256 neu und vergleicht mit file_revisions.checksum_sha256 – Abweichung gilt als Befund
+Sampling priorisiert alte, unveränderte Objekte (GoBD-Relevanz: still vergammelnde Bytes, die niemand mehr anfasst, fallen sonst erst beim Restore auf); Neu-Schreibvorgänge sind bereits beim Schreiben verifiziert und werden nicht bevorzugt geprüft
+Befund wird gemeldet, nicht automatisch repariert – Meldung läuft über Core OPS-05 (Alerting) mit Objekt-Referenz, erwarteter vs. tatsächlicher Prüfsumme und Zeitpunkt
+Job läuft über die Postgres-Jobqueue (FDN-04) mit konfigurierbarer Kadenz und Stichprobengröße; Lauf ist idempotent und unterbrechbar ohne inkonsistenten Zustand
+Stichprobengröße und Kadenz sind je Betriebsstufe konfigurierbar, damit ein vollständiger Durchlauf über den Bestand in einem dokumentierten Zeitraum abgeschlossen wird (kein täglicher Voll-Download aller Objekte)
+Der Job erkennt Abweichungen nur bei Objekten, die gelesen und erneut geprüft werden können. Er ersetzt keine storage-seitige WORM-/Versionierungsstrategie und keine Zugriffs-/Audit-Logs des Storage-Providers (siehe STORAGE-KONZEPT.md Abschnitt 6.1) — bei extern eingebundenem, nicht-kompatiblem Kunden-Storage (Betriebsmodus 3, ohne Versioning/Object Lock/Audit-Logs) bleibt eine Lücke, die BAK-08 technisch nicht schließen kann.","Testobjekt mit absichtlich manipuliertem Byte im Storage wird als Abweichung erkannt und gemeldet (Alert-Eingang über OPS-05 nachgewiesen)
+Unverändertes Testobjekt erzeugt keinen Befund (kein False-Positive)
+Verschlüsseltes Testobjekt (über FDN-09) wird korrekt gelesen und geprüft – der Job nutzt denselben Decrypt-Pfad wie reguläre Lesezugriffe, vergleicht also Klartext-Prüfsumme, nicht Chiffretext
+Test gegen ein simuliertes externes S3-Ziel (nicht selbst überwacht): Korruption dort wird erkannt – genau der Fall, der sonst unsichtbar bleibt
+Sampling-Statistik dokumentiert: Anteil alter vs. neuer Objekte in der Stichprobe entspricht der konfigurierten Priorisierung"
+RET-06-API,Aufbewahrungsfristen-Konfigurations-Backend,⏳ Retention & WORM,Backend,Mittel,2,3,Fertig,"Go/net/http, PostgreSQL, provisorischer Rollen-Check (kein RBAC-02-HTTP-Wrapper vorhanden)","Backend-API fuer RET-06: Aufbewahrungsklassen anlegen/aendern/deaktivieren, Vorschauliste ablaufender Objekte. Aus RET-06 herausgeloest (Board-Entscheidung: Backend zuerst, Next.js-Frontend als eigenes Folgeticket), damit kein Pseudo-Frontend-Protokoll entsteht.",RET-02,RET-06,"Aufbewahrungsklasse mit Frist lässt sich per API anlegen, ändern und deaktivieren
+API liefert Vorschauliste bald ablaufender Objekte, identisch zum periodischen Job
+Änderungen an Fristen sind nur mit gültiger Rollen-Kennung zugänglich (provisorischer Check, echter RBAC-02-HTTP-Wrapper folgt als Core-Ticket)","Änderung einer Frist wirkt sich nur auf künftige Berechnungen aus, nicht rückwirkend
+Fehlende/falsche Rollen-Kennung erhält 403, gültige Kennung 200 (Negativ- und Positivtest)
+Vorschauliste stimmt mit dem Ergebnis des periodischen Jobs überein"
+RET-08,RET-06-API auf RBAC-06 migrieren (Provisorium abbauen),⏳ Retention & WORM,Backend,Klein,1,4,Fertig,"Go, HTTP-Client","internal/retentionapi.RequireRole (Header-basiertes Provisorium aus RET-06-API) durch einen echten Aufruf von Core RBAC-06 (POST /authorize, service-token-authentifiziert) ersetzen. Baut das seit RET-06-API dokumentierte Provisorium ab, jetzt da RBAC-06 real existiert und deployed ist.",RBAC-06 RET-06-API,RET-06,"Der RBAC-Check in retentionapi nutzt ausschliesslich RBAC-06 (HTTP), nicht mehr das lokale Header-Provisorium
+Bestehende Endpunkte (POST /retention-classes, POST /retention-classes/{class}/deactivate) verhalten sich funktional unveraendert (gleiche AC wie RET-06-API)
+Fehlerfall: RBAC-06 nicht erreichbar oder verweigert -> Zugriff wird abgelehnt (fail closed), nicht stillschweigend erlaubt","403-Nachweis erfolgt gegen echte Policy-Rules ueber RBAC-06, nicht mehr nur gegen einen Header-Wert
+Bestehende RET-06-API-Tests (Preview stimmt mit periodischem Job ueberein, Deaktivierung wirkt) laufen weiterhin gruen nach der Migration
+Ausfall/Nichterreichbarkeit von RBAC-06 fuehrt zu einer Ablehnung (kein Fallback auf offenen Zugriff)"
+RET-09,Modul-Adapter-Dienst starten (RET-05 als laufender HTTP-Endpunkt),⏳ Retention & WORM,Backend,Klein,1,5,Fertig,"Go, HTTP","archive/internal/moduleadapter.RegisterHandler (RET-05) existiert als fertiger Go-Handler, laeuft aber nirgends als Dienst. RET-09 startet ihn als eigenstaendigen HTTP-Dienst (main.go + systemd), OHNE neue Archive-Logik - reines Wiring, analog RBAC-06/CFG-05 fuer andere Module.",RET-05,DOC-16 ARC-11,"moduleadapter.RegisterHandler laeuft als eigenstaendiger, ueber systemd verwalteter HTTP-Dienst
+Ein externer Client (anderes Modul) kann real POST /register gegen den laufenden Dienst aufrufen
+Keine neue Autorisierungs- oder Registrierungslogik - reiner Start des bestehenden Handlers","Dienst startet und bleibt stabil (systemctl status aktiv)
+Realer POST /register von einem externen Testclient gegen den laufenden Dienst liefert die erwartete Registrierung (idempotent, wie in RET-05 getestet)
+Code-Review: keine Aenderung an moduleadapter.go/handler.go selbst, nur main.go+systemd neu"
+RET-10,CORS für RET-06-API (Frontend-Zugriff aus dem Browser),⏳ Retention & WORM,Backend,Klein,1,5,Fertig,"Go, HTTP-Middleware (CORS)","retention-api (RET-06-API) setzt keine CORS-Header - ein echter Browser blockiert den Fetch von RET-06 (Next.js-Frontend, anderer Origin) zum Backend. Real per Sichtpruefung des laufenden RET-06-Frontends gefunden (curl umgeht CORS, Go-/Vitest-Tests pruefen nicht browserseitig), nicht durch die urspruenglichen RET-06/RET-06-API-Pruefungen erfasst.",RET-06-API,,"retention-api setzt Access-Control-Allow-Origin fuer den konfigurierten Frontend-Origin (Umgebungsvariable, kein Wildcard in Produktion)
+Preflight-Anfragen (OPTIONS) werden korrekt beantwortet fuer POST/GET-Endpunkte
+RET-06-Frontend kann alle vier Endpunkte real aus einem Browser-Kontext (nicht nur curl) erreichen","Realer Browser-Fetch (nicht curl) vom RET-06-Frontend gegen retention-api gelingt, Same-Origin-Policy nicht mehr blockierend
+OPTIONS-Preflight liefert korrekte CORS-Header fuer POST /retention-classes
+Fetch von einem NICHT konfigurierten Origin wird weiterhin blockiert (kein Wildcard-Leck)"
+RET-11,Storage-seitige WORM-Durchsetzung (Object-Lock statt nur Anwendungslogik),⏳ Retention & WORM,Backend,Mittel,2,7,Backlog,"S3 Object Lock / Compliance-Mode, PostgreSQL, Go","RET-04 verhindert Änderung/Überschreiben archivierter Objektinhalte nach dem Schreiben, aber ohne explizite Festlegung, ob dies nur durch Anwendungscode (übersprungen bei direktem Storage-Zugriff) oder durch eine Storage-seitige Garantie (z. B. S3 Object Lock im Compliance-Mode) erzwungen wird. WORM-Objekte über die Object-Lock-Funktion des Storage-Backends selbst sperren, sodass auch ein Zugriff mit vollen Storage-Zugangsdaten unterhalb der Anwendung keine Änderung/Löschung vor Fristablauf erlaubt.",RET-04,,"Jedes WORM-Objekt wird beim Schreiben mit einer Storage-seitigen Object-Lock-Sperre bis zum Ablauf der Aufbewahrungsfrist versehen
+Ein Löschversuch mit direkten Storage-Zugangsdaten (unterhalb der Anwendung) schlägt vor Fristablauf fehl, nachweislich durch das Storage-Backend selbst und nicht nur durch Anwendungscode
+Nach Fristablauf und regulärer Freigabe (RET-03) ist das Objekt normal löschbar","Test: direkter Löschversuch über die Storage-API (nicht über die NEXARCH-Anwendung) auf ein gesperrtes Objekt schlägt fehl
+Test: nach Fristablauf und Freigabe durch RET-03 ist die Löschung über den regulären Workflow möglich
+Konfigurationsprüfung: Object-Lock/Compliance-Mode ist für den produktiven Bucket aktiviert, dokumentiert in der Betriebsanleitung"
+RET-12,Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail,⏳ Retention & WORM,Backend,Mittel,2,7,Backlog,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","RET-05 nimmt Objekttyp- und Aufbewahrungsklassen-Registrierungen von DMS und Mail entgegen. Ohne unabhängige Prüfung würde Archive dem vom registrierenden Modul mitgelieferten Tenant-Kontext blind vertrauen. Jede Registrierung muss den mitgelieferten Tenant-Kontext gegen die Core-Registry (TEN-01) validieren, unabhängig vom Service-Credential-Scope des aufrufenden Moduls – Archive verlässt sich nicht allein auf die Angabe von DMS/Mail.",RET-05,,"Jede Objekttyp-/Aufbewahrungsklassen-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+Bestehende, korrekte Registrierungsabläufe aus RET-05 funktionieren unverändert","Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig"
+BAK-09,Envelope-Encryption für Backup-Snapshots (Datenbank & Objekt-Storage),💾 Backup & Wiederherstellung,Backend,Mittel,2,7,Backlog,"Envelope-Encryption (Tenant-KEK aus Core API-10), restic/Borg-artige Sicherung","BAK-01/BAK-02 sichern Datenbank und Objekt-Storage-Inhalte, ohne festzulegen, ob die Sicherungen selbst verschlüsselt sind. Archivierte Objekte sind live über die Tenant-KEK-Hierarchie (Core API-10) verschlüsselt – Backups dürfen kein schwächer geschütztes Abbild derselben Daten sein. Backup-Snapshots über denselben Tenant-KEK verschlüsseln wie die Live-Daten, sodass ein kompromittiertes Backup-Ziel ohne den jeweiligen Tenant-KEK keine verwertbaren Klartextdaten liefert.",BAK-01 BAK-02,,"Backup-Snapshots von Datenbank und Objekt-Storage sind mit dem Tenant-KEK des jeweiligen Mandanten verschlüsselt
+Ein Zugriff auf das Backup-Ziel ohne den jeweiligen Tenant-KEK liefert keine verwertbaren Klartextdaten
+Wiederherstellung (BAK-03/BAK-04) funktioniert unverändert unter Verwendung des korrekten Tenant-KEK","Test: Backup-Datei ohne Tenant-KEK ist nicht auswertbar (Stichprobe auf Klartext-Reste)
+Restore-Test mit korrektem Tenant-KEK stellt die Daten vollständig wieder her
+Test: Restore mit falschem/fremdem Tenant-KEK schlägt fehl, statt fremde Daten zu liefern"
+BAK-10,Schutzniveau der Restore-Testumgebung (DSGVO-konform),💾 Backup & Wiederherstellung,Backend,Einfach,1,7,Backlog,"Isolierte Testumgebung, Zugriffskontrolle, Betriebsdokument","BAK-06 testet das Restore-Verfahren regelmäßig automatisiert gegen eine isolierte Testumgebung – diese enthält dabei zwangsläufig echte (wiederhergestellte) Mandantendaten. Ohne festgelegtes Schutzniveau könnte die Testumgebung schwächer abgesichert sein als die Produktivumgebung und so zu einem leichteren Angriffsziel für dieselben Daten werden. Schutzniveau der Testumgebung verbindlich festlegen (gleiche Zugriffskontrolle, Netzwerksegmentierung und Löschfrist nach Testlauf wie produktiv) und dokumentieren.",BAK-06,,"Die Restore-Testumgebung unterliegt derselben Zugriffskontrolle und Netzwerksegmentierung wie die Produktivumgebung
+Wiederhergestellte Testdaten werden nach Abschluss des Testlaufs und Protokollierung des Ergebnisses gelöscht, nicht dauerhaft vorgehalten
+Das Schutzniveau ist im Betriebsdokument zu BAK-06 explizit festgehalten","Prüft Zugriffskontrolle/Netzwerksegmentierung der Testumgebung gegen die Produktivumgebung
+Prüft, dass nach einem Testlauf keine wiederhergestellten Daten über die dokumentierte Frist hinaus verbleiben
+Prüft, dass das Betriebsdokument das Schutzniveau explizit benennt"

archive-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>Archive Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Archive 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": 93, "epics": [{"key": "RET", "name": "Retention & WORM", "emoji": "⏳", "color": "#B45309", "description": "Aufbewahrungsfristen, Legal Hold, WORM-Speicher und Modul-Adapter-Schnittstelle für DMS/Mail."}, {"key": "CMP", "name": "Compliance & eDiscovery", "emoji": "⚖️", "color": "#7C3AED", "description": "GoBD-Verfahrensdokumentation, DSGVO-Berichte, eDiscovery-Export und Vier-Augen-Freigaben."}, {"key": "BAK", "name": "Backup & Wiederherstellung", "emoji": "💾", "color": "#0369A1", "description": "Datenbank- und Objekt-Storage-Sicherung, Restore-Verfahren und Konsistenzprüfung."}, {"key": "ANA", "name": "Kennzahlen & Reporting", "emoji": "📊", "color": "#A855F7", "description": "Modulübergreifende Kennzahlen-Aggregation, Auswertungs-Dashboard und Lizenz-/Nutzungs-Reports."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates für Retention, Compliance und Backup."}], "waves": [{"welle": 1, "codes": ["RET-01", "CMP-04", "BAK-01", "BAK-02", "QA-01"]}, {"welle": 2, "codes": ["RET-02", "RET-04", "RET-05", "CMP-01", "CMP-02", "BAK-03", "BAK-05", "BAK-07"]}, {"welle": 3, "codes": ["RET-03", "RET-06", "RET-07", "CMP-03", "CMP-05", "BAK-04", "BAK-06", "ANA-01", "QA-06"]}, {"welle": 4, "codes": ["CMP-06", "ANA-02", "ANA-03", "QA-02", "QA-04", "CMP-07"]}, {"welle": 5, "codes": ["QA-03"]}, {"welle": 6, "codes": ["QA-05", "QA-07"]}, {"welle": 7, "codes": ["RET-11", "RET-12", "BAK-09", "BAK-10"]}], "kritischerPfad": {"path": ["RET-01", "RET-02", "RET-03", "CMP-06", "QA-03", "QA-05"], "days": 16}, "produktDna": {"uebernehmen": [{"produkt": "Alfresco", "staerke": "Retention Policies mit Stichtagsberechnung, revisionssichere Ablage und Aufbewahrungssperre (Legal Hold)."}, {"produkt": "Alfresco", "staerke": "Vier-Augen-Prinzip bei Freigaben, insbesondere bei Löschungen."}, {"produkt": "ecoDMS", "staerke": "Revisionssicherheit als Grundhaltung: unveränderliches Protokoll, nachvollziehbare Vernichtung."}, {"produkt": "restic/Borg", "staerke": "Inkrementelle, deduplizierende Sicherung mit eingebauter Verifikation und routinemäßigem Restore-Test."}], "vermeiden": [{"produkt": "Alfresco – schwergewichtige Plattform mit hohem Ressourcenbedarf und trägem Betrieb.", "ansatz": "Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur."}]}, "epicDna": {"RET": {"leitsatz": "Aufbewahrung mit dem Ernst von Alfrescos Retention Policies, aber ohne dessen Ressourcen-Overhead.", "uebernehmen": ["Alfresco: Retention Policies mit Stichtagsberechnung je Objekttyp und automatischem Ablauf.", "ecoDMS: Revisionssicherheit als Grundhaltung – einmal archiviert, nicht mehr veränderbar.", "Alfresco: Aufbewahrungssperre (Legal Hold), die jede Löschregel überstimmt."], "vermeiden": ["Alfresco – hoher Ressourcen-Overhead der Plattform: schlanker Go-Dienst statt schwergewichtiger Anwendungsserver.", "Keine modulspezifische Retention-Logik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen."]}, "CMP": {"leitsatz": "Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.", "uebernehmen": ["Alfresco: Vier-Augen-Prinzip bei Freigaben – Löschung nur mit zweiter, unabhängiger Bestätigung.", "ecoDMS: Nachvollziehbare Vernichtung mit lückenlosem Protokoll.", "GoBD-konforme Verfahrensdokumentation als exportierbares Dokument, nicht als Prosa-Anhang."], "vermeiden": ["Alfresco – Freigabeprozesse mit hoher Konfigurationslast: feste, einfache Vier-Augen-Regel statt konfigurierbarer Workflow-Engine.", "Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf."]}, "BAK": {"leitsatz": "Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.", "uebernehmen": ["restic/Borg: Inkrementelle, deduplizierende Sicherung mit Verifikation jeder Sicherung.", "restic/Borg: Wiederherstellung ist Routine, nicht Ausnahmefall – regelmäßig getestet.", "Reconciliation zwischen Objekt-Storage und Datenbank als eigenständige, planbare Prüfung."], "vermeiden": ["Keine Sicherung ohne belegten Wiederherstellungstest – eine ungeprüfte Sicherung zählt nicht als Sicherung.", "Kein Restore, der ein nicht-leeres Zielverzeichnis direkt überschreibt, ohne Atomarität zu garantieren."]}, "ANA": {"leitsatz": "Kennzahlen modulübergreifend an einer Stelle, nicht in jedem Modul einzeln nachgebaut.", "uebernehmen": ["Ein Aggregationsdienst für Kennzahlen aus DMS, Mail und Archive statt Silo-Reports je Modul.", "Dashboard mit Facetten und Filtern statt starrer Report-Vorlagen."], "vermeiden": ["Keine Kennzahlenlogik, die doppelt in DMS und Mail gepflegt werden muss."]}, "QA": {"leitsatz": "Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.", "uebernehmen": ["Fester PrüLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

archive-kanban/tickets/BAK-09.md

@@ -0,0 +1,59 @@
+# BAK-09 – Envelope-Encryption für Backup-Snapshots (Datenbank & Objekt-Storage)
+
+**Epic:** 💾 Backup & Wiederherstellung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+BAK-01/BAK-02 sichern Datenbank und Objekt-Storage-Inhalte, ohne festzulegen, ob die Sicherungen selbst verschlüsselt sind. Archivierte Objekte sind live über die Tenant-KEK-Hierarchie (Core API-10) verschlüsselt – Backups dürfen kein schwächer geschütztes Abbild derselben Daten sein. Backup-Snapshots über denselben Tenant-KEK verschlüsseln wie die Live-Daten, sodass ein kompromittiertes Backup-Ziel ohne den jeweiligen Tenant-KEK keine verwertbaren Klartextdaten liefert.
+
+**Technische Grundlage:** Envelope-Encryption (Tenant-KEK aus Core API-10), restic/Borg-artige Sicherung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- restic/Borg: clientseitige Verschlüsselung vor dem Verlassen des Quellsystems als Standard, nicht als Zusatzoption.
+
+**Bewusst vermeiden:**
+- restic/Borg (Fehlkonfiguration in der Praxis) – unverschlüsseltes Backup-Repository bei falscher Einrichtung.: Verschlüsselung ist über die bestehende Tenant-KEK-Hierarchie erzwungen, keine separate, optionale Backup-Passphrase.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: BAK-01, BAK-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Backup-Snapshots von Datenbank und Objekt-Storage sind mit dem Tenant-KEK des jeweiligen Mandanten verschlüsselt
+2. Ein Zugriff auf das Backup-Ziel ohne den jeweiligen Tenant-KEK liefert keine verwertbaren Klartextdaten
+3. Wiederherstellung (BAK-03/BAK-04) funktioniert unverändert unter Verwendung des korrekten Tenant-KEK
+
+## 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: Backup-Datei ohne Tenant-KEK ist nicht auswertbar (Stichprobe auf Klartext-Reste)
+2. Restore-Test mit korrektem Tenant-KEK stellt die Daten vollständig wieder her
+3. Test: Restore mit falschem/fremdem Tenant-KEK schlägt fehl, statt fremde Daten zu liefern
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Archive-Board, 2026-09-12): ein unverschlüsseltes oder schwächer geschütztes Backup wäre ein einfacherer Angriffspfad auf dieselben Daten als das gut geschützte Live-System.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `BAK-01` Datenbank-Backup-Strategie
+- `BAK-02` Objekt-Storage-Backup/Snapshots
+
+## 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: `BAK-09: envelope-encryption-f-r-backup-snapshots-datenbank-objekt-storage`
+- Branch: `feature/bak-09-envelope-encryption-f-r-backup-snapshots-datenbank-objekt-storage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

archive-kanban/tickets/BAK-10.md

@@ -0,0 +1,58 @@
+# BAK-10 – Schutzniveau der Restore-Testumgebung (DSGVO-konform)
+
+**Epic:** 💾 Backup & Wiederherstellung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+BAK-06 testet das Restore-Verfahren regelmäßig automatisiert gegen eine isolierte Testumgebung – diese enthält dabei zwangsläufig echte (wiederhergestellte) Mandantendaten. Ohne festgelegtes Schutzniveau könnte die Testumgebung schwächer abgesichert sein als die Produktivumgebung und so zu einem leichteren Angriffsziel für dieselben Daten werden. Schutzniveau der Testumgebung verbindlich festlegen (gleiche Zugriffskontrolle, Netzwerksegmentierung und Löschfrist nach Testlauf wie produktiv) und dokumentieren.
+
+**Technische Grundlage:** Isolierte Testumgebung, Zugriffskontrolle, Betriebsdokument
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Betriebsdisziplin: Testdaten mit Personenbezug erhalten dasselbe Schutzniveau wie Produktivdaten, keine Ausnahme für Testumgebungen.
+
+**Bewusst vermeiden:**
+- verbreitetes Anti-Muster in Testumgebungen: Produktivdaten in schwächer gesicherte Staging-/Test-Umgebungen kopiert, dort länger als nötig aufbewahrt.: Restore-Testumgebung wird nach jedem Testlauf zurückgesetzt/gelöscht, Zugriffskontrolle identisch zu produktiv.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: BAK-06.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die Restore-Testumgebung unterliegt derselben Zugriffskontrolle und Netzwerksegmentierung wie die Produktivumgebung
+2. Wiederhergestellte Testdaten werden nach Abschluss des Testlaufs und Protokollierung des Ergebnisses gelöscht, nicht dauerhaft vorgehalten
+3. Das Schutzniveau ist im Betriebsdokument zu BAK-06 explizit festgehalten
+
+## 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. Prüft Zugriffskontrolle/Netzwerksegmentierung der Testumgebung gegen die Produktivumgebung
+2. Prüft, dass nach einem Testlauf keine wiederhergestellten Daten über die dokumentierte Frist hinaus verbleiben
+3. Prüft, dass das Betriebsdokument das Schutzniveau explizit benennt
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Archive-Board, 2026-09-12): eine schwächer geschützte Testumgebung mit echten wiederhergestellten Mandantendaten würde den durch Modell C und Envelope-Encryption erreichten Schutz umgehen, ohne dass dies wie ein klassischer Sicherheitsvorfall aussieht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `BAK-06` Restore-Testverfahren
+
+## 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: `BAK-10: schutzniveau-der-restore-testumgebung-dsgvo-konform`
+- Branch: `feature/bak-10-schutzniveau-der-restore-testumgebung-dsgvo-konform`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

archive-kanban/tickets/RET-11.md

@@ -0,0 +1,58 @@
+# RET-11 – Storage-seitige WORM-Durchsetzung (Object-Lock statt nur Anwendungslogik)
+
+**Epic:** ⏳ Retention & WORM  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+RET-04 verhindert Änderung/Überschreiben archivierter Objektinhalte nach dem Schreiben, aber ohne explizite Festlegung, ob dies nur durch Anwendungscode (übersprungen bei direktem Storage-Zugriff) oder durch eine Storage-seitige Garantie (z. B. S3 Object Lock im Compliance-Mode) erzwungen wird. WORM-Objekte über die Object-Lock-Funktion des Storage-Backends selbst sperren, sodass auch ein Zugriff mit vollen Storage-Zugangsdaten unterhalb der Anwendung keine Änderung/Löschung vor Fristablauf erlaubt.
+
+**Technische Grundlage:** S3 Object Lock / Compliance-Mode, PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- restic/Borg: Unveränderlichkeit als Eigenschaft des Speichers, nicht nur der aufrufenden Anwendung.
+
+**Bewusst vermeiden:**
+- Alfresco – in älteren Konfigurationen teils nur anwendungsseitige Lösch-Sperre ohne Storage-Garantie.: WORM ist eine Storage-Backend-Garantie (Object Lock), die Anwendungslogik ist die zweite, nicht die einzige Verteidigungslinie.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: RET-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jedes WORM-Objekt wird beim Schreiben mit einer Storage-seitigen Object-Lock-Sperre bis zum Ablauf der Aufbewahrungsfrist versehen
+2. Ein Löschversuch mit direkten Storage-Zugangsdaten (unterhalb der Anwendung) schlägt vor Fristablauf fehl, nachweislich durch das Storage-Backend selbst und nicht nur durch Anwendungscode
+3. Nach Fristablauf und regulärer Freigabe (RET-03) ist das Objekt normal löschbar
+
+## 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: direkter Löschversuch über die Storage-API (nicht über die NEXARCH-Anwendung) auf ein gesperrtes Objekt schlägt fehl
+2. Test: nach Fristablauf und Freigabe durch RET-03 ist die Löschung über den regulären Workflow möglich
+3. Konfigurationsprüfung: Object-Lock/Compliance-Mode ist für den produktiven Bucket aktiviert, dokumentiert in der Betriebsanleitung
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Archive-Board, 2026-09-12): reine Anwendungslogik gegen Überschreiben schützt nicht gegen einen Akteur mit direktem Storage-Zugriff (kompromittierte Zugangsdaten, Fehlkonfiguration) — GoBD/WORM-Anforderungen verlangen eine tatsächlich technische, nicht nur anwendungsseitige Garantie.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RET-04` WORM-Speicher-Garantie (Append-only)
+
+## 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: `RET-11: storage-seitige-worm-durchsetzung-object-lock-statt-nur-anwendungslogik`
+- Branch: `feature/ret-11-storage-seitige-worm-durchsetzung-object-lock-statt-nur-anwendungslogik`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

archive-kanban/tickets/RET-12.md

@@ -0,0 +1,58 @@
+# RET-12 – Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail
+
+**Epic:** ⏳ Retention & WORM  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+RET-05 nimmt Objekttyp- und Aufbewahrungsklassen-Registrierungen von DMS und Mail entgegen. Ohne unabhängige Prüfung würde Archive dem vom registrierenden Modul mitgelieferten Tenant-Kontext blind vertrauen. Jede Registrierung muss den mitgelieferten Tenant-Kontext gegen die Core-Registry (TEN-01) validieren, unabhängig vom Service-Credential-Scope des aufrufenden Moduls – Archive verlässt sich nicht allein auf die Angabe von DMS/Mail.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der meldenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Archive verifiziert den Tenant-Kontext jeder eingehenden Registrierung selbst gegen die Core-Registry, statt der Angabe des meldenden Moduls zu vertrauen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: RET-05.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Objekttyp-/Aufbewahrungsklassen-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+2. Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+3. Bestehende, korrekte Registrierungsabläufe aus RET-05 funktionieren 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: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+2. Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Archive-Board, 2026-09-12): Archive ist die Senke für Retention-Registrierungen aus zwei anderen Modulen — ohne eigene Validierung würde ein Fehler oder eine Kompromittierung in DMS/Mail unmittelbar auf die Compliance-kritische Retention-Zuordnung in Archive durchschlagen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen)
+
+## 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: `RET-12: unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`
+- Branch: `feature/ret-12-unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-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.

connect-kanban/README.md

@@ -0,0 +1,93 @@
+# Connect-Kanban – lokal abarbeiten
+
+32 Arbeitskacheln · 7 Epics · 85 Personentage · 7 Wellen (inkl. Welle 7: Threat-Model-Nachtrag 2026-09-12 — ENG-07, ENG-08).
+
+Hinweis: Dieses Board baut vollständig auf NEXARCH Core auf (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur. LDAP/SSO sind Core-Sache (IAM-05/IAM-06), Scanner-Anbindung ist DMS/Mail-Sache, hier ausschließlich externe Drittsystem-Konnektoren.
+
+Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board.
+Stand: 2026-08-26
+
+## 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 (`ENG-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** (2 Kacheln): ENG-01, QA-01
+- **Welle 2** (10 Kacheln): ENG-02, ENG-03, ENG-04, ENG-06, ERP-01, ERP-02, DAT-01, DMS2-01, DMS2-03, API-03
+- **Welle 3** (10 Kacheln): ENG-05, ERP-03, ERP-04, DAT-02, M365-01, DMS2-02, API-01, QA-02, QA-04, QA-06
+- **Welle 4** (4 Kacheln): DAT-03, M365-02, M365-03, API-02
+- **Welle 5** (1 Kachel): QA-03
+- **Welle 6** (1 Kachel): QA-05
+
+Kritischer Pfad (16 PT): ENG-01 → DAT-01 → DAT-02 → DAT-03 → QA-03 → QA-05
+
+## Produkt-DNA
+
+### Übernehmen
+- **Zapier/n8n**: Connector-Plugin-Modell mit austauschbaren Adaptern statt fest verdrahteter Drittsystem-Logik – Kernidee dieses Boards, bewusst schlanker ohne visuellen Workflow-Builder.
+- **Airbyte**: Sync-Job-Konzept mit Retry und Fehlerbehandlung als Vorbild für robuste, wiederholbare Imports/Exports.
+
+### Vermeiden
+- **Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock.**: Jeder Connector ist offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – was die Oberfläche kann, kann auch die offene Schnittstelle.
+- **Zapier/n8n – voller grafischer Workflow-Builder.**: Nur die Kernidee austauschbarer Adapter, kein eigenes Prozessmodellierungswerkzeug – das übernimmt bei Bedarf NEXARCH Workflow.
+
+## 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).

connect-kanban/board.csv

@@ -0,0 +1,167 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+ENG-01,Connector-Plugin-Modell,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,1,Backlog,"Plugin-Schnittstelle, Go-Interface, Registrierung","Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.",,ENG-02 ENG-03 ENG-04 ENG-06 ERP-01 ERP-02 DAT-01 DMS2-01 DMS2-03 API-03,"Neuer Connector lässt sich ohne Codeänderung an der Engine registrieren
+Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz
+Connector-Metadaten (Name, Version, unterstützte Operationen) sind abrufbar","Zwei Testconnectoren parallel registriert und einzeln ansprechbar
+Deregistrierung entfernt Connector vollständig
+Fehlerhafter Connector wird beim Laden abgewiesen, Engine bleibt lauffähig"
+ENG-02,"Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)",🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Backlog,"Verschlüsselte Speicherung, OAuth2-Client, PostgreSQL","Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.",ENG-01,M365-01 API-01 QA-04 QA-07 QA-02 ENG-07,"Zugangsdaten sind ausschließlich verschlüsselt gespeichert
+OAuth-Token-Erneuerung läuft automatisiert ohne Nutzereingriff
+Widerruf einer Verbindung entfernt zugehörige Zugangsdaten vollständig","Datenbankinhalt der Zugangsdaten-Tabelle ist ohne Schlüssel nicht lesbar
+Ablaufender OAuth-Token wird vor Ablauf erneuert
+Widerruf im Test entfernt Zugangsdaten nachweislich"
+ENG-03,Sync-Job-Verwaltung (periodische Imports/Exports),🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Backlog,"Postgres-Jobqueue, periodische Ausführung","Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.",ENG-01,ENG-05 QA-02 ENG-08,"Sync-Job ist mit Zeitplan konfigurierbar
+Laufender Job überlebt einen Dienst-Neustart
+Manuelles Anstoßen eines Jobs außerhalb des Zeitplans möglich","Zeitplan im Test korrekt eingehalten
+Neustart des Dienstes mit laufendem Job geprüft
+Manueller Anstoß erzeugt genau einen zusätzlichen Lauf"
+ENG-04,Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem),🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Backlog,"Mapping-Konfiguration, Schema-Validierung",Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.,ENG-01,API-01 QA-02,"Feld-Mapping ist ohne Codeänderung konfigurierbar
+Ungültiges Mapping wird beim Speichern abgewiesen
+Pflichtfeld ohne Zuordnung wird vor Ausführung gemeldet","Ungültiges Mapping im Test abgewiesen
+Fehlendes Pflichtfeld-Mapping verhindert Sync-Start
+Geändertes Mapping wirkt erst auf nachfolgende Läufe"
+ENG-05,Fehlerbehandlung & Retry bei Drittsystem-Ausfällen,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,3,Backlog,"Retry mit Backoff, Fehlerprotokoll, Postgres-Jobqueue","Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.",ENG-03,API-02 QA-02 ENG-08,"Fehlgeschlagener Sync-Job wird mit Backoff automatisch wiederholt
+Dauerhafter Ausfall führt nach Grenzwert zu klarem Fehlerstatus statt Endlosschleife
+Fehlerprotokoll je Lauf ist einsehbar","Simulierter Drittsystem-Ausfall löst Retry mit Backoff aus
+Abbruchgrenze im Test erreicht und Status korrekt gesetzt
+Fehlerprotokoll enthält Ursache und Zeitpunkt"
+ENG-06,Connector-Audit-Kopplung (Core AUD),🔌 Connector-Engine & Grundgerüst,Backend,Einfach,2,2,Backlog,Audit-Ereignis-Kopplung,"Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.",ENG-01,QA-02,"Jede sicherheitsrelevante Connector-Aktion erzeugt einen Audit-Eintrag im Core-Audit-Log
+Audit-Eintrag enthält Person, Zeitpunkt und betroffenen Connector
+Fehlende Audit-Kopplung verhindert die Aktion nicht, wird aber protokolliert","Verbindung anlegen erzeugt nachweisbaren Audit-Eintrag
+Zugangsdaten ändern erzeugt nachweisbaren Audit-Eintrag
+Ausfall des Audit-Dienstes blockiert Connector-Betrieb nicht"
+ERP-01,ERP-Connector-Grundgerüst,📈 ERP/CRM-Anbindung,Backend,Mittel,3,2,Backlog,"ERP-Connector, REST/SOAP-Client","Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).",ENG-01,ERP-03 ERP-04,"Verbindung zu einem Test-ERP-System lässt sich aufbauen und prüfen
+Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar
+Verbindungsfehler wird klar gemeldet statt stillem Abbruch","Verbindungsaufbau gegen Test-ERP-System erfolgreich geprüft
+Lese- und Schreiboperation im Test erfolgreich
+Simulierter Verbindungsfehler wird korrekt gemeldet"
+ERP-02,CRM-Connector-Grundgerüst,📈 ERP/CRM-Anbindung,Backend,Mittel,3,2,Backlog,"CRM-Connector, REST-Client","Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.",ENG-01,ERP-03 QA-03,"Verbindung zu einem Test-CRM-System lässt sich aufbauen und prüfen
+Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar
+Verbindungsfehler wird klar gemeldet statt stillem Abbruch","Verbindungsaufbau gegen Test-CRM-System erfolgreich geprüft
+Lese- und Schreiboperation im Test erfolgreich
+Simulierter Verbindungsfehler wird korrekt gemeldet"
+ERP-03,Stammdaten-Abgleich (Kunden/Lieferanten),📈 ERP/CRM-Anbindung,Backend,Mittel,3,3,Backlog,"Sync-Logik, Konfliktbehandlung",Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.,ERP-01 ERP-02,QA-03,"Neuer Stammdatensatz im Drittsystem erscheint nach Sync in NEXARCH
+Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben
+Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung","Neuanlage im Test-ERP nach Sync in NEXARCH sichtbar
+Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt statt Datenverlust
+Zeitplan-gesteuerter Lauf im Test erfolgreich"
+ERP-04,Beleg-/Dokumentexport an ERP,📈 ERP/CRM-Anbindung,Backend,Mittel,3,3,Backlog,"Dokumentexport, Feld-Mapping",Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.,ERP-01,QA-03,"Beleg lässt sich mit zugeordneten Metadaten an das ERP exportieren
+Fehlgeschlagener Export wird über die Fehlerbehandlung erneut versucht
+Bereits exportierter Beleg wird nicht doppelt übertragen","Testbeleg im ERP nach Export mit korrekten Metadaten auffindbar
+Simulierter Exportfehler löst Retry aus
+Doppelversand im Test ausgeschlossen"
+DAT-01,DATEV-Format-Export (Belege/Buchungsstapel),🧾 DATEV-Anbindung,Backend,Mittel,3,2,Backlog,"DATEV-Exportformat, Buchungsstapel-Struktur",Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.,ENG-01 RET-05,DAT-02 DAT-03,"Export erzeugt gültige DATEV-Exportdatei aus Testbelegen
+Pflichtfelder des DATEV-Formats werden vollständig befüllt oder der Export klar abgewiesen
+Exportierter Buchungsstapel ist eindeutig einem Zeitraum zugeordnet
+Exportiertes Objekt (Buchungsstapel) wird bei Archive RET-05 mit der GoBD-Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen","Erzeugte Exportdatei besteht Formatprüfung gegen DATEV-Spezifikation
+Fehlendes Pflichtfeld führt zu klarer Abweisung statt fehlerhaftem Export
+Zeitraumzuordnung im Test korrekt
+Export eines Testbuchungsstapels erzeugt nachweisbar eine Registrierung bei Archive RET-05"
+DAT-02,DATEV-Konnektor (Schnittstellen-Protokoll),🧾 DATEV-Anbindung,Backend,Komplex,4,3,Backlog,"DATEV-Schnittstellenprotokoll, Übertragungslogik","Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.",DAT-01,DAT-03,"Übertragung an ein Test-DATEV-Zielsystem gelingt protokollkonform
+Fehlgeschlagene Übertragung wird über die Fehlerbehandlung erneut versucht
+Übertragungsstatus ist je Lauf nachvollziehbar","Protokollkonforme Übertragung im Test gegen Referenzsystem geprüft
+Simulierter Übertragungsfehler löst Retry aus
+Übertragungsstatus im Test korrekt und nachvollziehbar"
+DAT-03,DATEV-Export-Oberfläche & Protokoll,🧾 DATEV-Anbindung,Frontend,Einfach,2,4,Backlog,"React/Next.js-Oberfläche, Exportprotokoll-Ansicht",Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.,DAT-01 DAT-02 SHL-01,QA-03,"Export lässt sich über die Oberfläche mit Zeitraum-Auswahl anstoßen
+Exportprotokoll ist je Lauf einsehbar
+Fehlgeschlagener Export ist in der Oberfläche klar erkennbar","Export-Anstoß im Test aus der Oberfläche erfolgreich
+Protokollansicht zeigt reale Testläufe korrekt an
+Fehlgeschlagener Testlauf ist visuell klar unterscheidbar"
+M365-01,Microsoft-Graph-API-Anbindung (Auth/Basis),☁️ Microsoft 365-Anbindung,Backend,Mittel,3,3,Backlog,"Microsoft Graph API, OAuth2",Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.,ENG-02,M365-02 M365-03,"Authentifizierung gegen Microsoft Graph im Test erfolgreich
+Zugangsdaten werden über die Connect-Credential-Verwaltung gespeichert
+Abgelaufene Berechtigung wird erkannt und klar gemeldet","OAuth2-Anmeldung im Test gegen Microsoft-Testmandant erfolgreich
+Testaufruf einer Graph-API-Basisoperation erfolgreich
+Simulierter Berechtigungsablauf wird korrekt erkannt und gemeldet"
+M365-02,SharePoint/OneDrive-Dokumentabgleich,☁️ Microsoft 365-Anbindung,Backend,Mittel,3,4,Backlog,"SharePoint/OneDrive-API, Sync-Logik",Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.,M365-01,QA-03,"Dokument aus SharePoint/OneDrive erscheint nach Sync in NEXARCH mit Metadaten
+Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben
+Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung","Testdokument aus SharePoint nach Sync in NEXARCH korrekt vorhanden
+Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt
+Zeitplan-gesteuerter Lauf im Test erfolgreich"
+M365-03,Outlook-Kalender-Kopplung (Fristen/Wiedervorlage),☁️ Microsoft 365-Anbindung,Backend,Mittel,3,4,Backlog,"Outlook-Kalender-API, Fristen-Kopplung",Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.,M365-01,QA-03,"Frist/Wiedervorlage erscheint als Kalendereintrag in Outlook
+Änderung der Frist in NEXARCH aktualisiert den Kalendereintrag
+Gelöschte Frist entfernt den zugehörigen Kalendereintrag","Testfrist im Test-Outlook-Kalender korrekt sichtbar
+Friständerung im Test korrekt im Kalender nachgezogen
+Löschung im Test entfernt Kalendereintrag vollständig"
+DMS2-01,"Standardisiertes Export-/Import-Format (offen, dokumentiert)",🔄 Andere-DMS-Interoperabilität,Backend,Mittel,3,2,Backlog,"Offenes Austauschformat, Schema-Dokumentation",Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.,ENG-01,DMS2-02 QA-03,"Format ist vollständig dokumentiert und ohne NEXARCH-Werkzeug lesbar
+Export enthält Dokument, Metadaten und Versionsbezug
+Format-Validierung weist fehlerhafte Dateien ab","Exportierte Testdatei extern ohne NEXARCH-Werkzeug lesbar geprüft
+Enthaltene Metadaten im Test vollständig und korrekt
+Fehlerhafte Testdatei wird bei Validierung abgewiesen"
+DMS2-02,Import-Assistent für Drittsystem-Exporte,🔄 Andere-DMS-Interoperabilität,Fullstack,Mittel,3,3,Backlog,"Import-Assistent mit Mapping-Vorschau-Oberfläche (Next.js/React), Backend-Parser für Drittsystem-Exportformate","Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.",DMS2-01 SHL-01,QA-03,"Testexport eines gängigen Drittsystems lässt sich einlesen
+Feld-Mapping wird vorgeschlagen und ist vor Import änderbar
+Import-Ergebnis mit Erfolgs-/Fehlerzahl ist einsehbar
+Mapping-Vorschau ist eine bedienbare Oberfläche (nicht nur eine API-Antwort), in der Feldzuordnungen vor dem Import angepasst werden können","Testexport eines Drittsystems im Test erfolgreich eingelesen
+Manuelle Mapping-Korrektur im Test übernommen
+Import-Protokoll zeigt korrekte Erfolgs-/Fehlerzahl
+Mapping-Vorschau im Browser bedient: Zuordnung geändert, Import mit geänderter Zuordnung ausgeführt"
+DMS2-03,Externe-Backup-Ziel-Anbindung,🔄 Andere-DMS-Interoperabilität,Backend,Mittel,3,2,Backlog,"Backup-Ziel-Connector, verschlüsselte Übertragung",Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.,ENG-01,QA-03,"Backup-Ziel lässt sich über das Connector-Plugin-Modell einrichten
+Export an das Backup-Ziel erfolgt verschlüsselt
+Fehlgeschlagener Backup-Export wird über die Fehlerbehandlung erneut versucht","Verbindungsaufbau zu Test-Backup-Ziel im Test erfolgreich
+Übertragung im Test nachweislich verschlüsselt
+Simulierter Übertragungsfehler löst Retry aus"
+API-01,Connect-Konfigurationsoberfläche (Connectoren einrichten),🖥️ Connect-Oberfläche,Frontend,Mittel,3,3,Backlog,"Next.js/React, Connector-Einrichtungsformulare","Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.",ENG-02 ENG-04 SHL-01,,"Connector lässt sich vollständig über die Oberfläche einrichten, ohne Konfigurationsdatei
+Zugangsdaten werden nur maskiert angezeigt, nie im Klartext
+Feld-Mapping ist über die Oberfläche bearbeitbar","Vollständige Einrichtung eines Testconnectors über die Oberfläche erfolgreich
+Zugangsdaten in der Oberfläche im Test nachweislich maskiert
+Mapping-Änderung über die Oberfläche im Test korrekt übernommen"
+API-02,Verbindungsstatus-Übersicht & Diagnose,🖥️ Connect-Oberfläche,Frontend,Einfach,2,4,Backlog,"Next.js/React, Statusanzeige","Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.",ENG-05 SHL-01,,"Verbindungsstatus je Connector ist auf einen Blick erkennbar
+Letzter Sync-Lauf mit Ergebnis ist einsehbar
+Fehlerdiagnose zeigt die Ursache aus dem Fehlerprotokoll","Statusanzeige im Test korrekt für erfolgreichen und fehlgeschlagenen Lauf
+Diagnoseansicht zeigt reale Testfehler nachvollziehbar an
+Aktualisierung nach neuem Sync-Lauf im Test korrekt"
+API-03,Externe Webhook-Abonnements (nutzt Core API-07),🖥️ Connect-Oberfläche,Backend,Mittel,3,2,Backlog,Core-Webhook-Registry-Anbindung,"Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.",ENG-01,,"Connector kann ein Webhook-Ereignis über die Core-Webhook-Registry abonnieren
+Zugestelltes Ereignis löst die zugeordnete Connector-Aktion aus
+Abbestellen entfernt das Abonnement vollständig","Testabonnement über Core-Webhook-Registry im Test erfolgreich registriert
+Testereignis löst im Test die erwartete Connector-Aktion aus
+Abbestellung im Test vollständig entfernt"
+QA-01,Teststrategie Connect,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Backlog,"Testkorpus, Teststrategie-Dokument","Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.",,,"Teststrategie ist dokumentiert und für alle Epics anwendbar
+Testkorpus enthält reale Beispieldaten je angebundenem Drittsystemtyp
+Freigabekriterien je Prüfgate sind eindeutig benannt
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Teststrategie-Dokument liegt vollständig vor und wurde geprüft
+Testkorpus im Test auf Vollständigkeit je Systemtyp geprüft
+Freigabekriterien im Test auf Eindeutigkeit geprüft"
+QA-02,Prüfgate Connector-Engine,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,3,Backlog,"Prüfprotokoll, automatisierte Tests","Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).",ENG-06 ENG-02 ENG-03 ENG-04 ENG-05,QA-05,"Alle Akzeptanzkriterien der ENG-Kacheln sind geprüft und protokolliert
+Automatisierte Tests der ENG-Kacheln laufen fehlerfrei
+Prüfprotokoll ist abgelegt und nachlesbar","Vollständiger Testlauf über alle ENG-Kacheln durchgeführt und protokolliert
+Fehlerinjektion (Drittsystem-Ausfall) im Test korrekt behandelt
+Audit-Kopplung im Test nachweislich vollständig"
+QA-03,Prüfgate ERP/DATEV/M365,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Backlog,"Prüfprotokoll, automatisierte Tests","Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.",ERP-04 DAT-03 M365-03 ERP-02 ERP-03 M365-02 DMS2-01 DMS2-02 DMS2-03,QA-05,"Alle Akzeptanzkriterien der ERP-, DAT- und M365-Kacheln sind geprüft und protokolliert
+Automatisierte Tests laufen fehlerfrei gegen Testsysteme
+Prüfprotokoll ist abgelegt und nachlesbar
+Alle Akzeptanzkriterien der DMS2-Kacheln (Interoperabilität mit Drittsystemen) sind ebenfalls geprüft und protokolliert","Vollständiger Testlauf über ERP-, DAT- und M365-Kacheln durchgeführt und protokolliert
+Mindestens ein echter Testlauf je Drittsystemtyp durchgeführt
+Fehlerbehandlung bei simuliertem Ausfall je Systemtyp geprüft"
+QA-04,Sicherheitsprüfung Drittsystem-Credentials,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Backlog,"Sicherheitsprüfung, Penetrationstest-Checkliste","Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.",ENG-02,QA-05,"Verschlüsselung der Zugangsdaten besteht die Sicherheitsprüfung
+Zugriff auf Zugangsdaten ist auf berechtigte Rollen beschränkt
+Schlüsselverwaltung folgt dokumentierten Sicherheitsvorgaben","Verschlüsselungsprüfung gegen Datenbankinhalt durchgeführt und protokolliert
+Zugriffsprüfung mit unberechtigter Rolle im Test abgewiesen
+Schlüsselrotation im Test ohne Datenverlust durchgeführt"
+QA-05,Abnahme-Prüfung Connect,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Backlog,Abnahmeprotokoll,"Abschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.",QA-02 QA-03 QA-04 QA-06 QA-07 QA-08,,"Alle vorgelagerten Prüfgates sind abgeschlossen und protokolliert
+Zusammenspiel aller Connectoren im Gesamttest geprüft
+Abnahmeprotokoll ist abgelegt und nachlesbar","Gesamttest über alle Connectoren durchgeführt und protokolliert
+Zusammenspiel mit Core-Webhook-Registry im Test geprüft
+Abnahmeprotokoll vollständig und nachvollziehbar abgelegt"
+QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Backlog,"Vertragstests (Consumer-Driven Contracts), CI-Pipeline","Vertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.",API-03,QA-05,"Vertragstests decken das Webhook-Abonnement-Format vollständig ab
+Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen
+Tests laufen automatisiert in der CI","Testlauf gegen aktuellen Stand grün
+Simulierte Breaking Change erkannt
+CI-Integration nachgewiesen"
+QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Backlog,"Lastgenerator, Messprotokoll","Lasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.",ENG-02,QA-05,"Definierte Ziel-Latenz für Credential-Abruf unter Last mehrerer gleichzeitiger Connector-Instanzen eingehalten
+Sync-Job-Queue verarbeitet viele gleichzeitig eingereihte Jobs ohne Verklemmung oder Doppelverarbeitung
+Rate-Limiting gegenüber Drittsystemen bleibt unter Mehrinstanz-Last korrekt eingehalten","Lasttest mit simulierten parallelen Sync-Jobs mehrerer Connector-Typen durchgeführt, Ergebnis dokumentiert
+Test auf Doppelverarbeitung/Verklemmung der Job-Queue unter Last
+Rate-Limit-Verhalten gegenüber Drittsystemen bei mehreren gleichzeitigen Connector-Instanzen geprüft"
+QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,5,Backlog,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",DAT-03 DMS2-02 API-01 API-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"
+ENG-07,Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,2,7,Backlog,"Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go","ENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.",ENG-02,,"Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert
+Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext
+Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung unverändert","Test: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist
+Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin
+Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)"
+ENG-08,Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,2,7,Backlog,"Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)","ENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.",ENG-03 ENG-05,,"Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge
+Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen
+Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert","Test: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen
+Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt
+Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten"

connect-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>Connect Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Connect 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": 85, "epics": [{"key": "ENG", "name": "Connector-Engine & Grundgerüst", "emoji": "🔌", "color": "#0369A1", "description": "Connector-Plugin-Modell, Credential-Verwaltung, Sync-Job-Verwaltung, Feld-Mapping, Fehlerbehandlung/Retry und Audit-Kopplung."}, {"key": "ERP", "name": "ERP/CRM-Anbindung", "emoji": "📈", "color": "#B45309", "description": "ERP- und CRM-Connector-Grundgerüst, Stammdaten-Abgleich und Beleg-/Dokumentexport."}, {"key": "DAT", "name": "DATEV-Anbindung", "emoji": "🧾", "color": "#7C3AED", "description": "DATEV-Format-Export, Konnektor-Protokoll und Export-Oberfläche."}, {"key": "M365", "name": "Microsoft 365-Anbindung", "emoji": "☁️", "color": "#14B8A6", "description": "Microsoft-Graph-Anbindung, SharePoint/OneDrive-Dokumentabgleich und Outlook-Kalender-Kopplung."}, {"key": "DMS2", "name": "Andere-DMS-Interoperabilität", "emoji": "🔄", "color": "#92400E", "description": "Offenes Export-/Import-Format, Import-Assistent für Drittsystem-Exporte und externe Backup-Ziel-Anbindung."}, {"key": "API", "name": "Connect-Oberfläche", "emoji": "🖥️", "color": "#4338CA", "description": "Konfigurationsoberfläche für Connectoren, Verbindungsstatus-Diagnose und externe Webhook-Abonnements."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab."}], "waves": [{"welle": 1, "codes": ["ENG-01", "QA-01"]}, {"welle": 2, "codes": ["ENG-02", "ENG-03", "ENG-04", "ENG-06", "ERP-01", "ERP-02", "DAT-01", "DMS2-01", "DMS2-03", "API-03"]}, {"welle": 3, "codes": ["ENG-05", "ERP-03", "ERP-04", "DAT-02", "M365-01", "DMS2-02", "API-01", "QA-02", "QA-04", "QA-06"]}, {"welle": 4, "codes": ["DAT-03", "M365-02", "M365-03", "API-02"]}, {"welle": 5, "codes": ["QA-03"]}, {"welle": 6, "codes": ["QA-05", "QA-07"]}, {"welle": 7, "codes": ["ENG-07", "ENG-08"]}], "kritischerPfad": {"path": ["ENG-01", "DAT-01", "DAT-02", "DAT-03", "QA-03", "QA-05"], "days": 16}, "produktDna": {"uebernehmen": [{"produkt": "Zapier/n8n", "staerke": "Connector-Plugin-Modell mit austauschbaren Adaptern statt fest verdrahteter Drittsystem-Logik – Kernidee dieses Boards, bewusst schlanker ohne visuellen Workflow-Builder."}, {"produkt": "Airbyte", "staerke": "Sync-Job-Konzept mit Retry und Fehlerbehandlung als Vorbild für robuste, wiederholbare Imports/Exports."}], "vermeiden": [{"produkt": "Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock.", "ansatz": "Jeder Connector ist offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – was die Oberfläche kann, kann auch die offene Schnittstelle."}, {"produkt": "Zapier/n8n – voller grafischer Workflow-Builder.", "ansatz": "Nur die Kernidee austauschbarer Adapter, kein eigenes Prozessmodellierungswerkzeug – das übernimmt bei Bedarf NEXARCH Workflow."}]}, "epicDna": {"ENG": {"leitsatz": "Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.", "uebernehmen": ["Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.", "Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.", "Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt."], "vermeiden": ["Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.", "Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar."]}, "ERP": {"leitsatz": "Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.", "uebernehmen": ["Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.", "Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration."], "vermeiden": ["Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.", "Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert."]}, "DAT": {"leitsatz": "DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.", "uebernehmen": ["Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.", "Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt."], "vermeiden": ["Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.", "Keine stille Fehlklassifizierung von Belegen – AbLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

connect-kanban/tickets/ENG-07.md

@@ -0,0 +1,58 @@
+# ENG-07 – Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.
+
+**Technische Grundlage:** Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Föderations-/Drittsystem-Credentials werden über dieselbe zentrale Schlüsselverwaltung geschützt wie andere sensible Tenant-Daten.
+
+**Bewusst vermeiden:**
+- Airbyte (verbreitetes Anti-Muster bei Connector-Plattformen) – Connector-Credentials teils in einem separaten, eigenen Secret-Store statt der zentralen Schlüsselverwaltung der Plattform.: genau eine Schlüsselhierarchie für alle sensiblen Tenant-Daten, kein zweiter Pfad für Connector-Zugangsdaten.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert
+2. Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext
+3. Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung 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: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist
+2. Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin
+3. Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Connect-Board, 2026-09-12), analog zu DMS-Finding `IAM-19`: ein separates Verschlüsselungsschema für Connector-Credentials wäre ein zweiter, unabhängig zu prüfender Sicherheitsmechanismus statt der Wiederverwendung der bereits gehärteten Core-Schlüsselhierarchie.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)
+
+## 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: `ENG-07: drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`
+- Branch: `feature/eng-07-drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

connect-kanban/tickets/ENG-08.md

@@ -0,0 +1,59 @@
+# ENG-08 – Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.
+
+**Technische Grundlage:** Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Airbyte: Sync-Job mit klar begrenzter Retry-Logik und definierten Abbruchbedingungen als Vorbild.
+
+**Bewusst vermeiden:**
+- Zapier/n8n (verbreitetes Anti-Muster) – Connector-Jobs ohne harte Obergrenze können bei Drittsystem-Fehlverhalten unbegrenzt Ressourcen binden.: harte, konfigurierbare Obergrenzen je Sync-Lauf von Anfang an, nicht erst nach einem Vorfall nachgerüstet.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-03, ENG-05.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge
+2. Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen
+3. Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert
+
+## 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: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen
+2. Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt
+3. Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Connect-Board, 2026-09-12): unbegrenzte Sync-Jobs gegenüber Drittsystemen sind ein Denial-of-Service-Vektor sowohl gegen die eigene Jobqueue (Ressourcenbindung) als auch potenziell gegen das angebundene Drittsystem (unkontrollierte Anfragerate).
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports)
+- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen
+
+## 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: `ENG-08: ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`
+- Branch: `feature/eng-08-ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

core-kanban/README.md

@@ -0,0 +1,108 @@
+# Core-Kanban – lokal abarbeiten
+
+87 Arbeitskacheln · 10 Epics · 202 Personentage · 10 Wellen.
+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,448 @@
+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,"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,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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,Backlog,"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"

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": 202, "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"]}], "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 applikationsseitiger tenant_id-Filterung, bewLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

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/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/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/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/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/RBAC-08.md

@@ -0,0 +1,59 @@
+# RBAC-08 – 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-08: testfall-gegen-tenant-zu-superadmin-rechteeskalation`
+- Branch: `feature/rbac-08-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.

core-kanban/tickets/TEN-09.md

@@ -0,0 +1,60 @@
+# TEN-09 – Registry-Härtung & Zugriffsschutz
+
+**Epic:** 🏢 Mandantenverwaltung  |  **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
+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.
+
+**Technische Grundlage:** PostgreSQL, Netzwerksegmentierung, dedizierte DB-Rollen, AUD-01-Kopplung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Strikte Trennung zwischen Verwaltungsebene (Organisationen/Instanzen) und Nutzdaten.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Realm mit denselben Rechten wie Fachdaten-Realms verwaltet.: Registry-Datenbankrolle strikt von Tenant-Datenbankrollen getrennt, keine gemeinsame Superuser-Rolle.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: TEN-01, AUD-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Core-Prozess greift über eine Datenbankrolle auf die Registry zu, die keine Rechte auf Tenant-Datenbanken besitzt
+2. Jeder Zugriff auf Superadmin-Konten oder Verbindungsinformationen in der Registry erzeugt einen eigenen Audit-Event (Kopplung an AUD-01)
+3. Netzwerkzugriff auf die Registry-Datenbank ist auf den Core-Dienst beschränkt, dokumentiert in der Betriebsanleitung
+
+## 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, dass die Registry-Datenbankrolle keine Tenant-Datenbank lesen/schreiben kann (negativer Zugriffstest)
+2. Simuliert Lesezugriff auf Superadmin-Konten und prüft, dass ein Audit-Event mit korrektem Akteur/Zeitpunkt entsteht
+3. Prüft Firewall-/pg_hba.conf-Konfiguration gegen Zugriff von außerhalb des Core-Dienstes
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): Registry ist das höchstwertige Einzelziel im System (kompromittiert = Zugriff auf alle Mandanten), hatte aber kein eigenes Härtungs-Ticket. Eine gemeinsame Datenbankrolle für Registry und Tenant-Datenbanken würde die durch Modell C gewonnene Isolation auf Anwendungsebene wieder aufheben.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TEN-01` Tenant-Registry & Datenbank-Provisioning
+- `TEN-06` Connection-Routing & Pooling pro Mandant
+- `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: `TEN-09: registry-h-rtung-zugriffsschutz`
+- Branch: `feature/ten-09-registry-h-rtung-zugriffsschutz`
+- 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/TEN-10.md

@@ -0,0 +1,58 @@
+# TEN-10 – Integritätsprüfung von SQL-Migrationen vor Tenant-Rollout
+
+**Epic:** 🏢 Mandantenverwaltung  |  **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
+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.
+
+**Technische Grundlage:** PostgreSQL, SQL-Migrationen, Checksummen/Signaturprüfung, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Unleash: klare Trennung zwischen Definition (Migrationsdatei + Prüfsumme im Manifest) und Ausführung (Rollout-Routine aus TEN-07).
+
+**Bewusst vermeiden:**
+- Keycloak – Update-Skripte werden ohne Integritätsprüfung direkt ausgeführt.: jede Migration wird gegen ein versioniertes Manifest mit Prüfsumme validiert, bevor sie überhaupt eine erste Tenant-Datenbank erreicht.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: TEN-07.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Migrationsdatei hat einen Eintrag mit Prüfsumme im Migrations-Manifest, der vor dem Rollout erzeugt/versioniert wird
+2. Der Rollout gegen alle Tenant-Datenbanken startet nur, wenn die tatsächliche Prüfsumme der Migrationsdatei mit dem Manifest-Eintrag übereinstimmt
+3. Bei Prüfsummen-Abweichung wird der Rollout vollständig abgebrochen, bevor eine einzige Tenant-Datenbank verändert wurde, und es entsteht ein Audit-Event
+
+## 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 unveränderter Migrationsdatei: Rollout läuft normal durch
+2. Test mit nachträglich manipulierter Migrationsdatei (Prüfsumme weicht ab): Rollout bricht vor der ersten Tenant-Datenbank ab
+3. Prüft, dass der Abbruch einen nachvollziehbaren Audit-Event erzeugt (wer/was/wann)
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): TEN-07 adressiert Fehlerbehandlung bei fehlgeschlagenen Einzel-Rollouts, aber keine Integritätsprüfung der Quelle – ein kompromittiertes Deploy-Artefakt würde sonst automatisiert gegen alle Mandanten-Datenbanken laufen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TEN-07` Migrations-Orchestrierung über alle Tenant-Datenbanken
+
+## 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: `TEN-10: integrit-tspr-fung-von-sql-migrationen-vor-tenant-rollout`
+- Branch: `feature/ten-10-integrit-tspr-fung-von-sql-migrationen-vor-tenant-rollout`
+- 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/TEN-11.md

@@ -0,0 +1,58 @@
+# TEN-11 – Deckelung & Rate-Limit für Tenant-Connection-Pooling
+
+**Epic:** 🏢 Mandantenverwaltung  |  **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
+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.
+
+**Technische Grundlage:** Go/pgx, LRU-Pool, Rate-Limiting
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Unleash: konfigurierbare Grenzen (Quotas) statt unbegrenzter Ressourcennutzung.
+
+**Bewusst vermeiden:**
+- Keycloak – Multi-Realm-Betrieb mit hohem Speicher-Overhead pro Realm ohne harte Obergrenze.: feste Obergrenze für gleichzeitig offene Tenant-Pools, Least-Recently-Used-Verdrängung statt unbegrenztem Wachstum.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: TEN-06.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die Anzahl gleichzeitig offener Tenant-Connection-Pools ist konfigurierbar gedeckelt
+2. Ein einzelner Client/Service-Credential kann die Tenant-Wechsel-Rate nicht über ein konfiguriertes Limit hinaus treiben, ohne abgelehnt/gedrosselt zu werden
+3. 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
+
+## 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 vielen parallelen Tenant-Wechseln eines einzelnen Clients: Rate-Limit greift, andere Mandanten bleiben unbeeinträchtigt
+2. Test der LRU-Verdrängung bei Erreichen der Pool-Obergrenze
+3. Regressionstest: normaler Betrieb mit wenigen Mandanten bleibt unverändert performant
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Core-Board, 2026-09-12): ungedeckeltes LRU-Pooling ohne Rate-Limit auf Tenant-Wechsel ist ein Denial-of-Service-Vektor gegen alle Mandanten gemeinsam, nicht nur gegen den verursachenden Client.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TEN-06` Connection-Routing & Pooling pro Mandant
+
+## 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: `TEN-11: deckelung-rate-limit-f-r-tenant-connection-pooling`
+- Branch: `feature/ten-11-deckelung-rate-limit-f-r-tenant-connection-pooling`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/README.md

@@ -0,0 +1,113 @@
+# DMS-Kanban – lokal abarbeiten
+
+80 Arbeitskacheln · 8 Epics · 229 Personentage · 12 Wellen (inkl. Welle 12: Threat-Model-Nachtrag 2026-09-12 — INT-14, INT-15, INT-16, DOC-17, FDN-10, FDN-11, VER-08).
+
+Hinweis: Identität, Rechte, Mandantenverwaltung und Authentifizierung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr, nur externe Verweise in der Ausgangslage betroffener Kacheln.
+
+Hinweis: UI-Shell & Design-System ist ausgelagert in NEXARCH Core (siehe ../core-kanban/, SHL-01) — dieses Board hat dafür kein eigenes Ticket mehr, nur externe Verweise in den betroffenen Oberflächen-Tickets.
+
+Hinweis: REST-API-Grundgerüst, Rate-Limiting, OpenAPI-Tooling und Webhook-Zustellung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/, API-01/03/04/07) — dieses Board definiert nur noch die modul-eigenen Endpunkte.
+Hinweis: Aufbewahrung, WORM, Compliance-Berichte und Backup sind ausgelagert in NEXARCH Archive (siehe ../archive-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr.
+Hinweis: Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing sind ausgelagert in NEXARCH Workflow (siehe ../workflow-kanban/), Benachrichtigungsversand in NEXARCH Core (siehe ../core-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr.
+Hinweis: KI-Funktionen (Klassifizierung, Extraktion, Zusammenfassung, semantische Suche) sind ausgelagert in NEXARCH AI (siehe ../ai-kanban/), optional aktivierbar — dieses Board enthält dafür keine eigenen Tickets mehr.
+Stand: 2026-08-26
+
+## 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 (`FDN-01.md` …).
+Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage,
+Akzeptanzkriterien, Prüfungen und Abschlussregeln.
+
+- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren.
+- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen.
+- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch.
+
+## Weg 4 – Eigenes Board im Netzwerk (Team)
+
+Selbst gehostet, jeweils mit CSV-Import:
+
+```bash
+# Focalboard
+docker run -d -p 8000:8000 --name focalboard mattermost/focalboard
+
+# Planka
+docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest
+
+# Vikunja
+docker run -d -p 3456:3456 --name vikunja vikunja/vikunja
+```
+
+Danach `board.csv` importieren.
+
+## Reihenfolge der Arbeit
+
+Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar,
+sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen.
+
+- **Welle 1** (5 Kacheln): FDN-01, QA-06, UX-01, UX-02, UX-03
+- **Welle 2** (8 Kacheln): FDN-02, FDN-03, FDN-07, FDN-08, FDN-09, SRC-01, UX-04, UX-05
+- **Welle 3** (8 Kacheln): DOC-01, DOC-09, FDN-04, MET-01, MET-02, QA-01, QA-11, VER-05
+- **Welle 4** (18 Kacheln): DOC-02, DOC-03, DOC-04, DOC-06, DOC-07, DOC-10, DOC-11, DOC-14, DOC-15, INT-01, INT-03, INT-08, MET-03, MET-04, QA-02, QA-07, VER-01, VER-06
+- **Welle 5** (10 Kacheln): DOC-05, DOC-08, DOC-12, INT-09, QA-05, SRC-02, SRC-05, VER-02, VER-03, VER-07
+- **Welle 6** (8 Kacheln): DOC-13, INT-06, MET-05, QA-03, SRC-03, SRC-06, SRC-07, VER-04
+- **Welle 7** (6 Kacheln): INT-04, INT-10, QA-08, QA-10, SRC-04, SRC-08
+- **Welle 8** (4 Kacheln): QA-09, QA-12, SRC-09, SRC-10
+- **Welle 9** (1 Kacheln): QA-04
+
+Kritischer Pfad (28 PT): FDN-01 → FDN-02 → DOC-01 → DOC-04 → DOC-05 → VER-04 → QA-08 → QA-12
+
+## Produkt-DNA
+
+### Übernehmen
+- **paperless-ngx**: Kompromisslose Erfassungs-Pipeline: Consume-Ordner, Vorverarbeitung, OCR, durchsuchbares PDF/A – vollautomatisch ohne Nutzerinteraktion.
+- **paperless-ngx**: Regelwerk für automatische Zuordnung von Korrespondent, Dokumenttyp und Tags direkt beim Import.
+- **Docspell**: Sprachverarbeitende Extraktion konkreter Werte: Absender, Datum, Betrag, Vertragspartner werden als strukturierte Felder vorgeschlagen.
+- **Docspell**: Sauberes Mandanten- und Datenmodell sowie ausgereifter Postfach-Abruf inklusive Anhangbehandlung.
+- **Alfresco**: Vererbende Zugriffskontrolle über die Ablagehierarchie mit expliziten Erlaubnissen und Verboten.
+- **Alfresco**: Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- **Alfresco**: Versionierung mit Ausleihen/Einchecken sowie Aufbewahrungssteuerung inklusive Aufbewahrungssperre.
+- **ecoDMS**: Revisionssicherheit als Grundhaltung: unveränderliches Protokoll, nachvollziehbare Vernichtung, Vier-Augen-Freigabe.
+- **ecoDMS**: Praxisnaher Scanner- und Stapelworkflow mit Trennseiten und Klassifizierungsvorlagen.
+
+### Vermeiden
+- **Alfresco – Schwergewichtige Plattform mit hohem Ressourcenbedarf, langer Startzeit und aufwendigem Betrieb.**: Schlanker Dienst plus getrennte Worker. Jede Komponente muss auf einem kleinen Server startklar sein.
+- **Alfresco – Übermächtiges Konfigurationsmodell mit steiler Lernkurve und träger Oberfläche.**: Sinnvolle Voreinstellungen, die ohne Konfiguration funktionieren. Komplexität nur dort, wo sie nachweislich gebraucht wird.
+- **paperless-ngx – Kaum Governance: keine echte Rechtevererbung, keine Freigabeprozesse, keine Versionen, kein belastbares Protokoll.**: Rechte, Versionierung und Protokoll gehören von Anfang an ins Fundament, nicht als Nachrüstung.
+- **paperless-ngx – Flache Ablage ohne Hierarchie, dadurch mühsam in Abteilungsstrukturen.**: Hierarchische Ablage und Verschlagwortung parallel anbieten – der Nutzer entscheidet, nicht das System.
+- **Docspell – Karge Oberfläche und dünne Dokumentation, hohe Einstiegshürde.**: Oberfläche und Hilfetexte sind Teil jeder Kachel, nicht ein späterer Feinschliff.
+- **ecoDMS – Geschlossenes System mit eigenständigem Desktop-Client und eingeschränkter Schnittstelle.**: Alles was die Oberfläche kann, kann auch die offene Schnittstelle. Die Oberfläche ist nur ein Nutzer der eigenen Programmierschnittstelle.
+- **ecoDMS – Herstellerbindung durch proprietäre Ablage- und Datenformate.**: Offene Formate, jederzeit vollständiger Export von Dokumenten und Metadaten ohne Werkzeug des Herstellers.
+
+## 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).

dms-kanban/board.csv

@@ -0,0 +1,411 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+FDN-01,Repository & Projektgerüst,⚙️ Fundament,DevOps,Einfach,2,1,Fertig,"Monorepo, Go, Next.js/TypeScript, golangci-lint, Prettier","Repository anlegen, Ordnerstruktur für App, Worker und Shared-Paket festlegen, Linting/Formatierung und Commit-Konventionen etablieren.",,FDN-02 FDN-03 FDN-07 FDN-08 FDN-09 SRC-01,"Repo lässt sich mit einem Befehl installieren und starten
+Lint- und Format-Checks laufen lokal durch
+Branch- und Commit-Konvention dokumentiert","Frischer Clone baut ohne manuelle Nacharbeit
+Lint-Fehler brechen den Build ab
+README-Setupanleitung von zweiter Person nachvollzogen"
+FDN-02,Datenmodell & Migrationen,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"PostgreSQL, pgx/v5, SQL-Migrationsdateien (kein ORM)","Kern-Entitäten modellieren: Dokument, Datei-Revision, Ordner, Benutzer, Tag, Metadatenfeld. Migrationen versioniert und rückrollbar.",FDN-01,DOC-01 DOC-09 FDN-04 MET-01 MET-02 QA-02 VER-01 VER-05,"Alle Kern-Entitäten mit Beziehungen und Indizes vorhanden
+Migration vorwärts und rückwärts ausführbar
+Seed-Datensatz für Entwicklung vorhanden","Migration auf leerer DB und auf bestehender DB getestet
+Rollback stellt Vorzustand wieder her
+Fremdschlüssel-Constraints durch Negativtests belegt"
+FDN-03,Objekt-Storage-Abstraktion,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"S3-kompatibel, Presigned URLs","Storage-Adapter mit einheitlicher Schnittstelle für Ablegen, Lesen, Löschen und signierte URLs. Lokaler Treiber für Entwicklung, S3 für Produktion.",FDN-01,DOC-01 QA-02 FDN-10,"Ein Interface, zwei austauschbare Treiber
+Signierte URLs mit konfigurierbarer Gültigkeit
+Pfadschema innerhalb des Mandanten-Buckets für Dokument/Revision festgelegt (Bucket-Trennung selbst ist Sache von Core TEN-01)
+Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet","Round-Trip-Test Upload/Download je Treiber
+Abgelaufene signierte URL wird abgewiesen
+Verhalten bei fehlendem Objekt liefert klaren Fehler
+Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe"
+FDN-04,Job-Queue & Worker-Runtime,⚙️ Fundament,Backend,Mittel,3,3,Fertig,"Postgres-Jobqueue (processing_jobs, FOR UPDATE SKIP LOCKED), In-Prozess-Worker-Goroutinen, kein Redis/AMQP","Asynchrone Verarbeitung für OCR, Konvertierung, Indexierung und Exporte. Mit Wiederholungslogik, Backoff und Dead-Letter-Queue.",FDN-02,DOC-04 DOC-06 DOC-08 INT-03 QA-02 SRC-02 SRC-05 FDN-11,"Jobs werden zuverlässig eingereiht und verarbeitet
+Fehlgeschlagene Jobs landen nach n Versuchen in der DLQ
+Job-Status ist abfragbar","Absturz eines Workers führt zu erneuter Zustellung
+Idempotenz bei Doppelzustellung nachgewiesen
+DLQ-Eintrag manuell wiederholbar"
+FDN-07,CI-Pipeline & Testharness,⚙️ Fundament,DevOps,Einfach,2,2,Backlog,"CI-Runner, Unit-/E2E-Testrunner","Automatisierte Pipeline für Lint, Typprüfung, Unit- und E2E-Tests sowie Build-Artefakt. Testdatenbank wird pro Lauf frisch aufgesetzt.",FDN-01,QA-01 QA-02,"Pipeline läuft bei jedem Push
+Roter Test blockiert den Merge
+Testabdeckung wird ausgewiesen
+CI-Pipeline führt Dependency-/Supply-Chain-Scanning aus (govulncheck für Go-Module, npm audit für JS/TS-Pakete), Build schlägt bei kritischen bekannten Schwachstellen fehl.
+Sicherheitsrelevanter Code (Auth, Tenant-Scoping, Verschlüsselung, Berechtigungsprüfung) hat verpflichtende automatisierte Tests als Merge-Gate — ein Merge ohne diese Tests ist technisch blockiert, nicht nur Konvention.","Absichtlich fehlschlagender Test bricht Pipeline ab
+Pipeline-Laufzeit unter vereinbartem Grenzwert
+Artefakt ist reproduzierbar erzeugbar
+Absichtlich eingeführte bekannte Schwachstelle in einer Testabhängigkeit lässt den Build fehlschlagen.
+Merge-Versuch eines sicherheitsrelevanten Codepfads ohne Test wird von der Pipeline blockiert."
+FDN-08,"Logging, Metriken & Fehler-Tracking",⚙️ Fundament,DevOps,Einfach,2,2,Backlog,"Strukturierte Logs, Metrics-Endpoint","Strukturiertes Logging mit Korrelations-ID, technische Metriken und zentrale Fehlererfassung inklusive Alarmierung.",FDN-01,QA-02,"Jede Anfrage besitzt eine Korrelations-ID über alle Schichten
+Metriken für Latenz, Fehlerrate und Queue-Länge vorhanden
+Unbehandelte Fehler werden zentral gemeldet","Provozierter Fehler erscheint innerhalb einer Minute im Tracking
+Logs enthalten keine Passwörter oder Tokens
+Alarm-Schwelle einmal ausgelöst und quittiert"
+DOC-01,Upload-API & Chunk-Handling,🗂️ Dokumentenkern,Backend,Komplex,4,3,Fertig,tus.io / Multipart-Upload,"Serverseitige Aufnahme von Dateien inklusive fortsetzbarem Upload, Größen- und MIME-Validierung sowie Anlage von Dokument und erster Revision.",FDN-02 FDN-03 FDN-09,DOC-02 DOC-03 DOC-04 DOC-07 DOC-14 DOC-15 INT-01 INT-03 INT-06 INT-08 SRC-02 SRC-05 VER-01 INT-11 INT-12 INT-13 DOC-17,"Fortsetzbarer Upload nach Verbindungsabbruch
+Unerlaubte Dateitypen werden abgewiesen
+Dokument und Revision werden transaktional angelegt
+SHA-256 jeder Revision wird auf Klartext berechnet (vor FDN-09-Verschlüsselung) und transaktional mit der Revision in file_revisions.checksum_sha256 persistiert – Voraussetzung für Duplikaterkennung (DOC-02) und spätere Integritätsprüfung (Archive BAK-08)","Upload von 1 GB Datei erfolgreich
+Abbruch bei 50 % und Fortsetzung ergibt identische Prüfsumme
+Parallel-Upload von 20 Dateien ohne Datenverlust
+Nach Upload ist file_revisions.checksum_sha256 befüllt und entspricht der SHA-256 des hochgeladenen Klartexts"
+DOC-02,Dublettenerkennung,🗂️ Dokumentenkern,Backend,Einfach,2,4,Backlog,"SHA-256, Unique-Index","Prüfsumme jeder Datei berechnen, speichern und bei Upload gegen den Bestand prüfen. Nutzer entscheidet über Verwerfen oder bewusstes Duplikat.",DOC-01,SRC-02 SRC-05,"Prüfsumme wird bei jedem Upload persistiert
+Treffer wird dem Nutzer mit Verweis auf das Original gemeldet
+Bewusstes Duplikat ist möglich und wird markiert","Identische Datei zweimal hochgeladen erzeugt Warnung
+Datei mit einem geänderten Byte gilt nicht als Duplikat
+Prüfsummenberechnung bei Großdatei bleibt im Zeitbudget"
+DOC-03,Drag-and-Drop-Upload-Oberfläche,🗂️ Dokumentenkern,Frontend,Mittel,3,4,Backlog,"Dropzone, Fortschrittsanzeige","Upload-Oberfläche mit Ablagebereich, Mehrfachauswahl, Fortschritt je Datei, Abbrechen und verständlichen Fehlermeldungen.",DOC-01,QA-03,"Mehrere Dateien gleichzeitig per Drag-and-Drop
+Fortschritt und Status je Datei sichtbar
+Fehlgeschlagene Datei einzeln wiederholbar","Upload per Tastatur und Dateidialog bedienbar
+Verhalten bei Netzabbruch im Browser geprüft
+Mobile Ansicht bleibt bedienbar"
+DOC-04,Vorschau- & Thumbnail-Pipeline,🗂️ Dokumentenkern,Backend,Komplex,5,4,Backlog,"Renderer-Worker, Bildableitungen","Asynchrone Erzeugung von Seiten-Vorschauen und Thumbnails nach dem Upload, mit Cache und Wiederaufbau bei neuer Revision.",DOC-01 FDN-04,DOC-05 QA-10,"Thumbnail steht nach definierter Zeit bereit
+Vorschau wird gecacht und bei neuer Revision erneuert
+Fehlerhafte Datei blockiert die Pipeline nicht","Beschädigte PDF-Datei führt zu Fehlerstatus statt Absturz
+Durchsatztest mit 500 Dokumenten
+Cache-Invalidierung bei neuer Revision belegt"
+DOC-05,PDF-Viewer-Komponente,🗂️ Dokumentenkern,Frontend,Komplex,4,5,Backlog,PDF.js im Web-Worker,"Inline-Betrachter mit Seitennavigation, Zoom, Suche im Dokument und Textauswahl – ohne Download-Zwang.",DOC-04,DOC-13 QA-03 VER-04,"PDF wird ohne Download angezeigt
+Zoom, Blättern und Textsuche funktionieren
+Große Dokumente werden seitenweise nachgeladen","300-seitiges PDF öffnet im Zeitbudget
+Viewer per Tastatur bedienbar
+Speicherverbrauch im Browser bleibt stabil"
+DOC-06,Office-zu-PDF-Konverter,🗂️ Dokumentenkern,Backend,Komplex,4,4,Backlog,Headless-Konverter im Worker,"Serverseitige Konvertierung von Text-, Tabellen- und Präsentationsformaten in PDF als Vorschau- und Archivderivat.",FDN-04,QA-03 VER-07,"Gängige Office-Formate werden konvertiert
+Konvertierung läuft isoliert mit Zeitlimit
+Ergebnis wird als Derivat der Revision abgelegt","Layouttreue an Referenzdokumenten geprüft
+Zeitlimit bei Endlosdokument greift
+Konverter-Absturz beeinträchtigt andere Jobs nicht"
+DOC-07,Download & signierte URLs,🗂️ Dokumentenkern,Backend,Einfach,2,4,Backlog,Presigned URLs,"Download von Original und Derivaten über kurzlebige signierte URLs, inklusive korrektem Dateinamen und Berechtigungsprüfung.",DOC-01,DOC-08,"Download liefert Originaldatei unverändert
+URL läuft nach kurzer Frist ab
+Ohne Leseberechtigung kein Download","Prüfsumme vor und nach Download identisch
+Weitergegebene abgelaufene URL wird abgewiesen
+Sonderzeichen im Dateinamen korrekt übertragen"
+DOC-08,Massenexport als ZIP,🗂️ Dokumentenkern,Backend,Mittel,3,5,Backlog,"ZIP-Streaming, Export-Job","Auswahl mehrerer Dokumente als Hintergrund-Job zu einem Archiv bündeln, inklusive optionaler Metadaten-Datei und Download-Benachrichtigung.",DOC-07 FDN-04,QA-03,"Export läuft als Job und blockiert die Oberfläche nicht
+Archiv enthält Dokumente und Metadaten-Beilage
+Nur berechtigte Dokumente landen im Archiv","Export von 1000 Dokumenten ohne Speicherüberlauf
+Archiv in gängigen Entpackern lesbar
+Berechtigungsfilter durch Negativtest belegt"
+DOC-09,Ordner- & Kabinettmodell,🗂️ Dokumentenkern,Backend,Mittel,3,3,Backlog,"Baumstruktur, Materialized Path","Hierarchische Ablage mit Verschieben, Umbenennen und effizienten Teilbaum-Abfragen.",FDN-02,DOC-10 DOC-11 DOC-14,"Beliebig tiefe Hierarchie abbildbar
+Verschieben aktualisiert den gesamten Teilbaum
+Teilbaum-Abfrage bleibt performant","Zyklus beim Verschieben wird verhindert
+Abfrage bei 10.000 Ordnern im Zeitbudget
+Umbenennen bricht keine Verweise"
+DOC-10,Ordner-Navigation & Dokumentenliste,🗂️ Dokumentenkern,Frontend,Mittel,3,4,Backlog,"Baum-Navigation, virtualisierte Liste","Navigationsbaum, Brotkrumenpfad und virtualisierte Dokumentenliste mit Sortierung, Spaltenwahl und Mehrfachauswahl.",DOC-09,QA-03,"Baum und Liste bleiben synchron
+Liste bleibt bei vielen Einträgen flüssig
+Mehrfachauswahl mit Umschalt- und Strg-Taste","Liste mit 10.000 Zeilen scrollt ruckelfrei
+Navigation vollständig per Tastatur
+Zustand bleibt beim Zurücknavigieren erhalten"
+DOC-11,Soft-Delete & Papierkorb-Logik,🗂️ Dokumentenkern,Backend,Einfach,2,4,Backlog,"Soft-Delete, Aufräum-Job",Löschen setzt einen Papierkorb-Status statt physischer Entfernung. Endgültige Bereinigung erfolgt nach konfigurierbarer Frist.,DOC-09,DOC-12,"Gelöschte Objekte verschwinden aus allen normalen Ansichten
+Wiederherstellung stellt Ablageort und Metadaten wieder her
+Endgültige Löschung entfernt auch die Dateiobjekte","Gelöschtes Dokument taucht in Suche und Liste nicht mehr auf
+Wiederherstellung nach Ordnerlöschung getestet
+Aufräum-Job löscht nur abgelaufene Einträge"
+DOC-12,Papierkorb-Oberfläche,🗂️ Dokumentenkern,Frontend,Einfach,2,5,Backlog,"Listenansicht, Bestätigungsdialog","Ansicht des Papierkorbs mit Restlaufzeit, Einzel- und Massenwiederherstellung sowie bestätigter endgültiger Löschung.",DOC-11,QA-03,"Restlaufzeit je Eintrag sichtbar
+Wiederherstellung einzeln und in Auswahl möglich
+Endgültiges Löschen erfordert ausdrückliche Bestätigung","Versehentliches Löschen ohne Bestätigung nicht möglich
+Massenwiederherstellung mit 100 Objekten geprüft
+Leerer Papierkorb zeigt verständlichen Hinweis"
+SRC-01,Suchindex-Infrastruktur,🔍 Suche & OCR,DevOps,Mittel,3,2,Backlog,Manticore Search (BM25),"Suchdienst bereitstellen, Index-Schema mit deutscher Sprachbehandlung definieren und Betriebsparameter festlegen.",FDN-01,SRC-02,"Suchdienst ist reproduzierbar startbar
+Index-Schema mit Feldern und Gewichtung dokumentiert
+Deutsche Stemming- und Stoppwortbehandlung aktiv","Neuaufbau des Index aus dem Bestand möglich
+Umlaut- und Kompositasuche liefert Treffer
+Neustart des Dienstes ohne Datenverlust"
+SRC-02,Indexierungs-Worker & Synchronisierung,🔍 Suche & OCR,Backend,Komplex,4,5,Backlog,"Queue-Worker, Bulk-Indexing","Änderungen an Dokumenten, Metadaten und OCR-Texten laufend in den Suchindex übertragen, inklusive Voll-Reindexierung.",SRC-01 DOC-01 FDN-04 DOC-02,SRC-03,"Neues Dokument ist zeitnah auffindbar
+Änderung und Löschung werden im Index nachgezogen
+Voll-Reindexierung ohne Ausfall möglich","Konsistenzabgleich Datenbank gegen Index ergibt keine Abweichung
+Indexierung von 10.000 Dokumenten im Zeitbudget
+Ausfall des Suchdienstes führt zu Nachholung statt Datenverlust"
+SRC-03,Such-API mit Ranking,🔍 Suche & OCR,Backend,Mittel,3,6,Backlog,"Suchabfrage, Relevanz-Tuning","Suchschnittstelle mit Paginierung, Sortierung, Treffer-Ausschnitten und Berücksichtigung der Leseberechtigung.",SRC-02,QA-10 SRC-04 SRC-08,"Ergebnisse enthalten Textausschnitte mit Fundstellen
+Nur berechtigte Dokumente erscheinen
+Antwortzeit unter vereinbartem Grenzwert","Referenz-Suchanfragen liefern erwartete Reihenfolge
+Berechtigungsfilter durch Negativtest belegt
+Lasttest mit gleichzeitigen Suchanfragen bestanden"
+SRC-04,Such-Oberfläche mit Hervorhebung,🔍 Suche & OCR,Frontend,Mittel,3,7,Backlog,"Suchfeld, Ergebnisliste","Suchfeld mit Vorschlägen, Ergebnisliste mit hervorgehobenen Fundstellen und Sprung in die Dokumentvorschau.",SRC-03,QA-04 SRC-09,"Fundstellen sind im Ergebnis hervorgehoben
+Kein Ergebnis liefert hilfreiche Alternativvorschläge
+Suchzustand ist per URL teilbar","Suche vollständig per Tastatur bedienbar
+Verhalten bei sehr langem Suchbegriff geprüft
+Ergebnisliste auf Mobilgerät nutzbar"
+SRC-05,OCR-Worker,🔍 Suche & OCR,Backend,Komplex,5,5,Backlog,"Tesseract, Bildvorverarbeitung","Texterkennung für Scans und Bilder inklusive Entzerrung, Rauschunterdrückung und Speicherung des Volltexts je Seite.",FDN-04 DOC-01 DOC-02,INT-06 MET-05 SRC-06 SRC-07,"Erkannter Text wird seitenweise gespeichert
+Bereits durchsuchbare PDFs werden übersprungen
+Verarbeitung skaliert über mehrere Worker","Erkennungsrate an Referenz-Scanset gemessen und dokumentiert
+Schiefer Scan wird korrekt entzerrt
+Sehr großes Dokument läuft nicht in Zeitüberschreitung"
+SRC-06,PDF/A-Erzeugung mit Textebene,🔍 Suche & OCR,Backend,Mittel,3,6,Backlog,"PDF/A-Konverter, Textlayer",Archivfähiges PDF/A mit unsichtbarer Textebene aus der Texterkennung als zusätzliches Derivat erzeugen.,SRC-05,QA-04,"Erzeugtes PDF ist PDF/A-konform
+Text ist im Dokument markier- und durchsuchbar
+Original bleibt unverändert erhalten","Konformitätsprüfung mit Validierungswerkzeug bestanden
+Textposition deckt sich mit dem Bild
+Dateigröße bleibt im vereinbarten Rahmen"
+SRC-07,Spracherkennung & OCR-Qualitätsbewertung,🔍 Suche & OCR,Backend,Einfach,2,6,Backlog,"Spracherkennung, Konfidenzwerte","Dokumentsprache automatisch bestimmen, passendes Sprachmodell wählen und Konfidenzwerte für eine Nachbearbeitungsliste erfassen.",SRC-05,QA-04,"Sprache wird erkannt und am Dokument gespeichert
+Konfidenzwert je Seite verfügbar
+Dokumente unter Schwellwert erscheinen in einer Prüfliste","Spracherkennung an gemischtsprachigem Set geprüft
+Schlechter Scan landet zuverlässig in der Prüfliste
+Schwellwert ist ohne Neuveröffentlichung konfigurierbar"
+SRC-08,Facetten- & Filter-API,🔍 Suche & OCR,Backend,Mittel,3,7,Backlog,"Facettierung, Filterausdrücke","Kombinierbare Filter nach Typ, Tag, Datum, Ersteller und benutzerdefinierten Feldern samt Trefferzahlen je Facette.",SRC-03 MET-02,SRC-09 SRC-10,"Mehrere Filter sind gleichzeitig kombinierbar
+Facetten liefern korrekte Trefferzahlen
+Datums- und Wertebereiche werden unterstützt","Trefferzahlen gegen Datenbankabfrage abgeglichen
+Filter auf leerem Ergebnis verhält sich stabil
+Antwortzeit mit fünf aktiven Filtern gemessen"
+SRC-09,Filter-Panel in der Suche,🔍 Suche & OCR,Frontend,Mittel,3,8,Backlog,"Facetten-UI, Filter-Chips",Seitliches Filterpanel mit aktiven Filtern als entfernbare Chips und Zurücksetzen-Funktion.,SRC-08 SRC-04,QA-04,"Aktive Filter sind jederzeit sichtbar und einzeln entfernbar
+Trefferzahl aktualisiert sich unmittelbar
+Filterzustand steht in der URL","Geteilte URL stellt identischen Filterzustand her
+Panel auf schmalem Bildschirm bedienbar
+Zurücksetzen entfernt wirklich alle Filter"
+SRC-10,Gespeicherte Suchanfragen,🔍 Suche & OCR,Fullstack,Einfach,2,8,Backlog,Persistierte Abfragen,"Suchen benennen, speichern, erneut ausführen und optional mit dem Team teilen.",SRC-08,QA-04,"Suche lässt sich benennen und wiederherstellen
+Geteilte Suche ist für Berechtigte sichtbar
+Ergebnis wird beim Aufruf frisch ermittelt","Gespeicherte Suche liefert nach Datenänderung aktuelle Treffer
+Geteilte Suche zeigt jedem nur erlaubte Dokumente
+Löschen einer Suche beeinträchtigt andere Nutzer nicht"
+MET-01,Tag-Modell & Tag-API,🏷️ Metadaten,Backend,Einfach,2,3,Backlog,"Tag-Entität, Zuordnungstabelle","Tags mit Farbe und optionaler Hierarchie, Zuordnung zu Dokumenten sowie Zusammenführen und Umbenennen.",FDN-02,DOC-15 MET-03 MET-05,"Tags sind anlegbar, umbenennbar und zusammenführbar
+Mehrfachzuordnung je Dokument möglich
+Löschen eines Tags entfernt nur die Zuordnung","Zusammenführen erhält alle Zuordnungen
+Doppelte Tag-Namen werden verhindert
+Massenzuweisung an 500 Dokumente geprüft"
+MET-02,Benutzerdefinierte Metadatenfelder,🏷️ Metadaten,Backend,Komplex,4,3,Backlog,"Feldschema, Validierung","Frei definierbare Felder mit Datentyp, Pflichtkennzeichen, Standardwert und Validierungsregeln.",FDN-02,MET-03 MET-04 SRC-08,"Feldtypen Text, Zahl, Datum, Auswahl und Ja/Nein verfügbar
+Validierung greift beim Speichern
+Felddefinition ist versioniert änderbar","Ungültiger Wert wird mit klarer Meldung abgewiesen
+Typänderung eines Feldes mit Bestandsdaten getestet
+Pflichtfeld blockiert unvollständiges Speichern"
+MET-03,Metadaten- & Tag-Oberfläche,🏷️ Metadaten,Frontend,Mittel,3,4,Backlog,Dynamische Formulare,"Bearbeitungsbereich am Dokument mit dynamisch erzeugtem Formular, Tag-Eingabe mit Autovervollständigung und Massenbearbeitung.",MET-01 MET-02,QA-05,"Formular passt sich der Felddefinition automatisch an
+Tag-Eingabe schlägt bestehende Tags vor
+Massenbearbeitung für ausgewählte Dokumente möglich","Ungespeicherte Änderungen lösen Warnung aus
+Formular per Tastatur vollständig ausfüllbar
+Massenbearbeitung an 200 Dokumenten geprüft"
+MET-04,Dokumententypen & Vorlagen,🏷️ Metadaten,Backend,Mittel,3,4,Backlog,"Typdefinition, Feldbindung","Dokumententypen wie Rechnung oder Vertrag mit fest zugeordneten Pflichtfeldern, Standard-Tags und Aufbewahrungsvorgabe.",MET-02,QA-05,"Typ bündelt Felder, Tags und Aufbewahrungsvorgabe
+Typwechsel überführt vorhandene Werte
+Typ ist an Ordner vorbelegbar","Typwechsel mit Datenverlustprüfung getestet
+Pflichtfelder des Typs werden erzwungen
+Vorbelegung im Ordner greift beim Upload"
+MET-05,Regelbasierte Auto-Verschlagwortung,🏷️ Metadaten,Backend,Mittel,3,6,Backlog,"Regelwerk, Mustererkennung","Regeln auf Basis von Textmustern, Absender oder Dateiname vergeben automatisch Tags, Typ und Ablageort.",MET-01 SRC-05,INT-04 QA-05,"Regeln sind ohne Eingriff in den Code pflegbar
+Reihenfolge und Priorität der Regeln sind steuerbar
+Automatische Zuweisung ist als solche erkennbar","Regelwerk an Testkorpus mit erwarteter Trefferquote geprüft
+Widersprüchliche Regeln führen zu definiertem Ergebnis
+Regeländerung wirkt ohne Neustart"
+VER-01,Versionsmodell & Check-in/Check-out,🔄 Versionierung & Audit,Backend,Komplex,4,4,Backlog,"Revisionen, Sperren","Jede Änderung erzeugt eine neue Revision. Ausleihen sperrt das Dokument für andere, Einchecken gibt es mit Kommentar frei.",DOC-01 FDN-02,VER-02 VER-03 VER-07,"Alle Revisionen bleiben abrufbar
+Sperre verhindert konkurrierende Änderungen
+Sperre ist durch Administratoren aufhebbar","Zwei gleichzeitige Ausleihversuche – nur einer gewinnt
+Verwaiste Sperre wird nach Frist automatisch gelöst
+Alte Revision ist unverändert abrufbar"
+VER-02,Versionsansicht & Wiederherstellung,🔄 Versionierung & Audit,Frontend,Mittel,3,5,Backlog,"Versionsliste, Wiederherstellen","Liste aller Revisionen mit Autor, Zeitpunkt und Kommentar sowie Wiederherstellung einer früheren Fassung als neue Revision.",VER-01,QA-08,"Revisionen chronologisch mit Metadaten sichtbar
+Wiederherstellung erzeugt eine neue Revision statt Überschreiben
+Jede Revision ist einzeln herunterladbar","Wiederherstellung verändert die Historie nicht
+Ansicht bei 100 Revisionen bleibt übersichtlich
+Berechtigung wird je Revision geprüft"
+VER-03,Änderungshistorie & Diff-Berechnung,🔄 Versionierung & Audit,Backend,Mittel,3,5,Backlog,"Textvergleich, Metadaten-Diff",Unterschiede zwischen zwei Revisionen ermitteln – sowohl im Volltext als auch in Metadaten und Tags.,VER-01,VER-04,"Textunterschiede werden zeilen- oder absatzweise geliefert
+Metadatenänderungen werden als Vorher-Nachher ausgegeben
+Berechnung ist auch für große Dokumente möglich","Diff an Referenzpaaren gegen erwartetes Ergebnis geprüft
+Vergleich zweier identischer Revisionen liefert leeres Ergebnis
+Laufzeit bei 200-seitigem Dokument gemessen"
+VER-04,Diff-Ansicht,🔄 Versionierung & Audit,Frontend,Mittel,3,6,Backlog,"Gegenüberstellung, Farbmarkierung","Zwei Revisionen nebeneinander mit farblicher Markierung von Hinzufügungen, Löschungen und Metadatenänderungen.",VER-03 DOC-05,QA-08,"Revisionen sind frei zum Vergleich wählbar
+Änderungen sind farblich und mit Symbol gekennzeichnet
+Sprung zur nächsten Änderung möglich","Farbmarkierung ist auch ohne Farbwahrnehmung unterscheidbar
+Ansicht funktioniert auf schmalem Bildschirm
+Sehr viele Änderungen bremsen die Ansicht nicht aus"
+VER-05,Revisionssicherer Audit-Trail,🔄 Versionierung & Audit,Backend,Komplex,4,3,Backlog,"Append-only-Protokoll, Hash-Kette",Unveränderliches Protokoll aller sicherheits- und geschäftsrelevanten Ereignisse mit Verkettung zum Nachweis der Unversehrtheit.,FDN-02,VER-06 VER-08,"Einträge sind ausschließlich anfügbar
+Jeder Eintrag enthält Akteur, Zeit, Objekt und Aktion
+Verkettung erlaubt Integritätsprüfung","Manipulationsversuch wird durch Integritätsprüfung erkannt
+Vollständigkeit gegen Referenzoperationen abgeglichen
+Protokollschreiben verlangsamt Kernoperationen nicht spürbar"
+VER-06,Audit-Log-Ansicht & Export,🔄 Versionierung & Audit,Frontend,Einfach,2,4,Backlog,"Filterbare Tabelle, CSV-Export","Durchsuchbare Protokollansicht mit Filtern nach Zeitraum, Akteur, Objekt und Aktion sowie Export für Prüfer.",VER-05,QA-08,"Filter nach Zeitraum, Akteur und Aktion vorhanden
+Export enthält exakt die gefilterten Einträge
+Zugriff nur für berechtigte Rollen","Export mit 100.000 Einträgen läuft ohne Abbruch
+Nicht berechtigter Nutzer erhält keinen Zugriff
+Exportdatei ist in Tabellenkalkulation korrekt lesbar"
+VER-07,Digitale Signatur,🔄 Versionierung & Audit,Backend,Komplex,5,5,Backlog,"PAdES, Zertifikate, Zeitstempel","Dokumente digital signieren und vorhandene Signaturen prüfen, inklusive qualifiziertem Zeitstempel.",VER-01 DOC-06,QA-08,"Signatur wird eingebettet und ist extern prüfbar
+Prüfergebnis wird am Dokument angezeigt
+Zeitstempel stammt von einer vertrauenswürdigen Quelle","Signatur mit externem Prüfwerkzeug validiert
+Nachträgliche Änderung invalidiert die Signatur nachweislich
+Abgelaufenes Zertifikat wird als solches erkannt"
+INT-01,REST-API v1 & Schnittstellenbeschreibung,🔌 Integration & API,Backend,Komplex,4,4,Backlog,"REST, OpenAPI","Dokument-spezifische API-Endpunkte (Dokument abrufen/anlegen/durchsuchen usw.) auf dem zentralen Core-REST-Grundgerüst definieren und dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur, die liefert Core API-01.",DOC-01,INT-09 QA-10,"Alle dokument-eigenen Endpunkte sind in der Beschreibung dokumentiert
+Einheitliches Fehlerformat über alle Endpunkte (geerbt vom Core-REST-Grundgerüst)
+Endpunkte laufen auf der zentralen, versionierten Core-API auf, keine eigene Versionierung","Vertragstests gegen die Beschreibung laufen in der Pipeline
+Berechtigungen greifen identisch wie in der Oberfläche
+Beispielaufrufe aus der Dokumentation funktionieren"
+INT-03,E-Mail-Abruf über IMAP,🔌 Integration & API,Backend,Komplex,4,4,Backlog,"IMAP-Client, Job-Zeitplan","Überwachte Postfächer regelmäßig abrufen, Nachrichten und Anhänge importieren und verarbeitete Nachrichten markieren.",FDN-04 DOC-01,INT-04,"Mehrere Postfächer parallel überwachbar
+Nachricht und Anhänge werden als Dokumente abgelegt
+Verarbeitete Nachrichten werden nicht erneut importiert","Verbindungsabbruch führt zu Wiederholung ohne Duplikate
+Nachricht mit 20 Anhängen korrekt importiert
+Zugangsdaten liegen ausschließlich verschlüsselt vor"
+INT-04,E-Mail-Regeln & Anhangverarbeitung,🔌 Integration & API,Backend,Mittel,3,7,Backlog,"Regelwerk, Anhangfilter","Regeln nach Absender, Betreff oder Anhangtyp steuern Ablageort, Typ und Verschlagwortung importierter Nachrichten.",INT-03 MET-05,QA-09,"Regeln greifen auf Absender, Betreff und Anhangtyp zu
+Signaturbilder und Werbeanhänge sind ausfilterbar
+Nachricht bleibt als Kontext am Dokument erhalten","Regelwerk an Testpostfach mit erwarteter Zuordnung geprüft
+Nachricht ohne passende Regel landet im Klärungskorb
+Filter verwirft keine relevanten Anhänge"
+INT-06,Scanner-Anbindung über Hot-Folder,🔌 Integration & API,Backend,Komplex,4,6,Backlog,"Überwachter Ordner, Trennseiten","Überwachtes Verzeichnis für Netzwerkscanner mit Stapeltrennung, automatischer Texterkennung und Ablage.",DOC-01 SRC-05,INT-10 QA-09 INT-14,"Neue Dateien werden automatisch übernommen
+Stapel werden anhand von Trennseiten aufgeteilt
+Fehlerhafte Dateien landen in einem Fehlerordner","Datei wird erst nach vollständigem Schreiben verarbeitet
+Stapeltrennung an Referenzstapel geprüft
+Doppelte Einlieferung erzeugt kein Duplikat"
+UX-01,Responsive Layout & mobile Navigation,📱 UX & Zugänglichkeit,Frontend,Mittel,3,1,Backlog,"Breakpoints, mobile Muster","Alle Kernansichten für kleine Bildschirme optimieren, mit ausklappbarer Navigation und berührungsfreundlichen Zielen.",,UX-05,"Kernabläufe sind auf dem Telefon vollständig durchführbar
+Keine horizontale Scrollleiste bei 360 Pixel Breite
+Bedienelemente sind ausreichend groß","Test auf drei realen Geräteklassen
+Upload und Suche auf Mobilgerät durchgeführt
+Querformat geprüft"
+UX-02,Dunkles Erscheinungsbild & Theming,📱 UX & Zugänglichkeit,Frontend,Einfach,2,1,Backlog,"Theme-Tokens, Systempräferenz",Umschaltbares helles und dunkles Erscheinungsbild mit Speicherung der Wahl und Berücksichtigung der Systemeinstellung.,,UX-05,"Umschaltung wirkt ohne Neuladen
+Wahl bleibt über Sitzungen erhalten
+Systemeinstellung wird als Voreinstellung übernommen","Kontrastprüfung in beiden Varianten bestanden
+Kein Aufblitzen des falschen Erscheinungsbilds beim Laden
+Diagramme und Vorschauen bleiben lesbar"
+UX-03,Mehrsprachigkeits-Infrastruktur,📱 UX & Zugänglichkeit,Frontend,Mittel,3,1,Backlog,"i18n-Bibliothek, Sprachdateien","Alle Texte auslagern, Sprachumschaltung sowie lokale Formate für Datum, Zahl und Währung bereitstellen.",,UX-04,"Keine fest verdrahteten Texte mehr in Komponenten
+Sprachwechsel wirkt ohne Neuladen
+Datums- und Zahlenformate folgen der Sprache","Automatische Prüfung findet keine unübersetzten Texte
+Fehlender Schlüssel führt zu sichtbarem Hinweis statt leerem Feld
+Serverseitig gerenderte Seite zeigt die richtige Sprache"
+UX-04,Übersetzungen Deutsch und Englisch,📱 UX & Zugänglichkeit,Frontend,Einfach,2,2,Backlog,"Sprachdateien, Terminologieliste",Vollständige Übersetzung der Oberfläche in beide Sprachen inklusive abgestimmter Fachbegriffe.,UX-03,QA-11,"Beide Sprachdateien sind vollständig
+Fachbegriffe folgen einer abgestimmten Liste
+Fehlermeldungen sind ebenfalls übersetzt","Abdeckungsprüfung beider Sprachdateien bei 100 Prozent
+Sichtprüfung auf abgeschnittene Texte in beiden Sprachen
+Fachliche Gegenlesung dokumentiert"
+UX-05,Barrierefreiheit nach WCAG 2.1 AA,📱 UX & Zugänglichkeit,Frontend,Komplex,4,2,Backlog,"ARIA, Fokussteuerung","Semantik, Fokusführung, Tastaturbedienung, Beschriftungen und Kontraste über alle Ansichten hinweg herstellen.",UX-01 UX-02,QA-11,"Alle Abläufe ohne Maus bedienbar
+Sichtbare Fokusmarkierung überall vorhanden
+Formularfelder besitzen zugeordnete Beschriftungen","Automatisierte Prüfung meldet keine kritischen Verstöße
+Vollständiger Durchlauf mit Bildschirmleser dokumentiert
+Fokusfalle in Dialogen geprüft"
+QA-01,Teststrategie & Testdatenbestand,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,3,Backlog,"Teststrategie, anonymisierte Testdaten","Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen, anonymisierten Testdatenbestand mit Referenzdokumenten aufbauen.",FDN-07,QA-03 QA-04 QA-05 QA-07 QA-10,"Testpyramide und Abdeckungsziele sind schriftlich festgelegt
+Referenzkorpus mit Scans, PDFs und Office-Dateien liegt vor
+Testdaten enthalten keine echten Personendaten
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Testdatenbestand ist per Befehl reproduzierbar
+Referenzkorpus deckt alle unterstützten Formate ab
+Strategie im Team abgenommen"
+QA-02,Prüfgate Fundament,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,4,Backlog,"Integrationstests, Betriebsprüfung","Abnahme der Grundlage: Datenmodell, Storage, Queue, Auth, Pipeline und Observability greifen zuverlässig ineinander.",FDN-02 FDN-03 FDN-04 FDN-07 FDN-08 FDN-09,QA-12,"Alle Fundament-Tickets erfüllen ihre Prüfungen
+Ein Durchstich vom Login bis zum abgelegten Objekt funktioniert
+Keine offenen kritischen Befunde
+Verschlüsselung at rest (FDN-09) ist wirksam und die Schlüsselverwaltung geprüft","Neuaufsetzen der Umgebung von null erfolgreich
+Ausfall eines Dienstes führt zu sauberem Fehlerbild
+Prüfbericht abgelegt und freigegeben"
+QA-03,Prüfgate Dokumentenkern,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,6,Backlog,"E2E-Tests, Datenintegrität","Vollständige Prüfung des Lebenszyklus: hochladen, ansehen, ablegen, herunterladen, löschen, wiederherstellen.",DOC-03 DOC-05 DOC-06 DOC-08 DOC-10 DOC-12 QA-01 DOC-13 DOC-14 DOC-15,QA-12,"Kompletter Lebenszyklus als automatisierter Test vorhanden
+Keine Datenveränderung zwischen Upload und Download
+Alle Ticket-Prüfungen des Epics bestanden","Prüfsummenvergleich über den gesamten Lebenszyklus
+Abbruchszenarien in jedem Schritt getestet
+Referenzkorpus vollständig durchlaufen"
+QA-04,Prüfgate Suche & Texterkennung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,9,Backlog,Relevanz- und Erkennungsmessung,"Messen und dokumentieren von Erkennungsgüte, Trefferqualität und Konsistenz zwischen Datenbank und Suchindex.",SRC-04 SRC-06 SRC-07 SRC-09 SRC-10 QA-01,QA-12 QA-06,"Erkennungsrate am Referenzkorpus erreicht den Zielwert
+Relevanz an definierten Suchanfragen erfüllt die Erwartung
+Index und Datenbank sind nachweislich konsistent","Messprotokoll mit Zielwerten und Ergebnissen abgelegt
+Voll-Reindexierung ohne Trefferverlust geprüft
+Berechtigungsfilter in der Suche negativ getestet"
+QA-05,Prüfgate Metadaten & Klassifizierung,✅ Prüfungen & Qualitätssicherung,QA,Einfach,2,7,Backlog,Datenqualitätstests,"Prüfen von Feldvalidierung, Typwechseln, Massenbearbeitung und Güte der automatischen Zuordnung.",MET-03 MET-04 QA-01 MET-05,QA-12,"Validierungsregeln greifen in allen Eingabewegen
+Automatische Vorschläge erreichen die Zielgenauigkeit
+Massenbearbeitung erzeugt keine inkonsistenten Daten","Genauigkeit der Klassifizierung dokumentiert
+Typwechsel mit Bestandsdaten ohne Verlust
+Validierung auch über die Schnittstelle wirksam"
+QA-06,Sicherheits- & Berechtigungsprüfung,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,10,Backlog,"Penetrationstest, Rollenmatrix",Systematische Prüfung aller Zugriffspfade gegen die Rollenmatrix sowie Test auf gängige Sicherheitslücken.,QA-04 SRC-11,QA-12,"Jede Rolle wurde gegen jeden Endpunkt geprüft
+Keine unbefugte Rechteausweitung möglich
+Befunde sind behoben oder bewusst akzeptiert","Zugriff auf fremdes Objekt per ID schlägt fehl
+Prüfung auf Einschleusung, Sitzungsübernahme und unsichere Weiterleitung
+Sicherheitsbericht abgelegt und freigegeben"
+QA-07,Prüfgate Workflow & Benachrichtigung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,4,Backlog,"Prozesstests, Zeitraffer","Durchspielen aller Prozesspfade inklusive Ablehnung, Vertretung, Eskalation und Fristablauf.",QA-01,QA-12,"Alle Prozesspfade sind mindestens einmal durchlaufen
+Fristen und Eskalationen lösen korrekt aus
+Keine Benachrichtigung geht verloren oder wird doppelt versandt","Zeitraffer-Test über simulierte Fristen
+Parallelentscheidungen erzeugen keinen Fehlzustand
+Zustellprotokoll gegen erwartete Ereignisse abgeglichen"
+QA-08,Revisionssicherheits-Prüfung,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,7,Backlog,"Integritätsprüfung, Signaturvalidierung","Nachweis, dass Versionen, Protokoll und Signaturen unveränderlich, vollständig und extern prüfbar sind.",VER-02 VER-04 VER-06 VER-07,QA-12,"Historie ist lückenlos und nicht manipulierbar
+Signaturen sind mit externen Werkzeugen prüfbar
+Jede relevante Aktion erscheint im Protokoll","Manipulationsversuch wird erkannt und protokolliert
+Stichprobe von Aktionen im Protokoll wiedergefunden
+Prüfbericht für die Revision erstellt"
+QA-09,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,8,Backlog,"Vertragstests, Testempfänger","Automatisierte Prüfung, dass die Schnittstelle ihrer Beschreibung entspricht und Importwege zuverlässig arbeiten.",INT-04 INT-06 INT-08 INT-09 INT-10 INT-11 INT-12 INT-13,QA-12,"Vertragstests laufen in der Pipeline
+Import über E-Mail und Hot-Folder verliert keine Dokumente
+Webhook-Zustellung ist nachweisbar","Abweichung zwischen Beschreibung und Verhalten bricht die Pipeline
+Dauerlauf-Import über 24 Stunden ohne Verlust
+Wiederholungsverhalten bei Ausfall belegt"
+QA-10,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,7,Backlog,"Lastgenerator, Messprotokoll","Verhalten unter realistischer und überhöhter Last messen: Suche, Upload, Vorschau und Schnittstelle.",SRC-03 DOC-04 INT-01 QA-01,QA-12,"Zielwerte für Antwortzeit und Durchsatz sind definiert und gemessen
+Engpässe sind identifiziert und dokumentiert
+System erholt sich nach Lastspitze selbstständig","Dauerlast über mehrere Stunden ohne Speicherwachstum
+Verhalten bei Überlast ist definiert statt zufällig
+Messprotokoll mit Zielwertvergleich abgelegt"
+QA-11,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,3,Backlog,"Prüfwerkzeuge, Bildschirmleser",Unabhängige Prüfung aller Ansichten gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf.,UX-04 UX-05,QA-12,"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"
+QA-12,Abnahme- & Compliance-Prüfung,✅ Prüfungen & Qualitätssicherung,QA,Komplex,4,11,Backlog,"Abnahmeprotokoll, Wiederherstellungstest","Gesamtabnahme vor der Freigabe: Aufbewahrung, Löschworkflow, Berichte und nachgewiesene Wiederherstellbarkeit.",QA-08 QA-02 QA-03 QA-04 QA-05 QA-06 QA-07 QA-09 QA-10 QA-11,,"Alle Prüfgates sind bestanden
+Wiederherstellung wurde real durchgeführt
+Abnahmeprotokoll ist unterzeichnet","Notfallwiederherstellung auf leerem System nachgewiesen
+Löschung nur mit Freigabe und Protokoll möglich
+Offene Restrisiken sind schriftlich benannt"
+FDN-09,Verschlüsselung at rest & Schlüsselverwaltung,⚙️ Fundament,Backend,Mittel,3,2,Fertig,"AES-256-GCM, Envelope Encryption","Envelope-Encryption-Modul – Datenverschlüsselungsschlüssel (DEK) pro Objekt, verpackt durch einen Hauptschlüssel (KEK), der über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen wird. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst. Bietet Encrypt/Decrypt-Schnittstelle über Streams, die von der Storage-Abstraktion (FDN-03) beim Ablegen/Lesen genutzt wird.",FDN-01,DOC-01 QA-02,"DEK wird pro Objekt neu erzeugt, nie wiederverwendet
+KEK wird ausschließlich über Core API-10 bezogen, nie im Code oder in der Datenbank im Klartext gespeichert
+Schlüsselrotation des KEK ist ohne Neuverschlüsselung aller Objekte möglich (nur DEK-Wrapper wird neu verpackt)","Round-Trip Encrypt/Decrypt liefert identischen Klartext
+Manipulierter Chiffretext wird bei Decrypt erkannt und abgelehnt (GCM-Auth-Tag)
+KEK-Rotation getestet, alte Objekte weiterhin lesbar"
+DOC-13,Akten-/Vorgangsanzeige im Dokumentkontext,🗂️ Dokumentenkern,Frontend,Einfach,2,6,Backlog,"Next.js/React/TS, externe REST-API","In der Dokument-Detailansicht anzeigen, ob das Dokument zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in DMS.",DOC-05,QA-03,"Dokument-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden
+Kein eigenes Akte-Datenmodell in DMS, ausschließlich Anzeige über die externe API
+Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Dokumentanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“","Dokument mit verknüpfter Akte zeigt Akte-Informationen korrekt an
+Dokument ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler
+Simulierter Ausfall der Workflow-API blockiert die übrige Dokumentanzeige nicht"
+INT-08,Watch-Folder-Import (Consume-Ordner),🔌 Integration & API,Backend,Mittel,3,4,Backlog,"Überwachter Ordner, Dateisystem-Events/Polling","Dateisystem-Ordner, der automatisch überwacht wird — jede dort abgelegte Datei wird ohne API-Aufruf importiert. Ergänzt DOC-01 (Upload-API), ersetzt sie nicht.",DOC-01,QA-09 INT-14,"Datei im überwachten Ordner wird automatisch erkannt und importiert, ohne manuellen Trigger
+Importierte Datei durchläuft denselben Pipeline-Weg wie ein API-Upload (Hash/Dedup/Verschlüsselung/OCR/Index)
+Fehlerhafte/nicht lesbare Datei landet in einem Fehler-Unterordner statt den Import-Prozess zu blockieren","Testdatei im Ordner abgelegt, erscheint automatisch als Dokument
+Pipeline-Schritte (Hash, Dedup-Gate, Verschlüsselung) im Test nachweislich durchlaufen
+Absichtlich beschädigte Datei landet im Fehler-Unterordner, blockiert restlichen Ordner nicht"
+INT-09,CMIS-kompatible Schnittstelle (optional),🔌 Integration & API,Backend,Komplex,4,5,Backlog,CMIS 1.1 (AtomPub oder Browser-Binding),"CMIS-Standardschnittstelle als optionale zusätzliche API neben der eigenen REST-API — ermöglicht Drittwerkzeugen direkten Zugriff auf DMS-Inhalte, ohne NEXARCH-spezifische Integration schreiben zu müssen.",INT-01,QA-09 INT-15,"CMIS-Basisoperationen (Objekt lesen, Ordner navigieren, Dokument hochladen) funktionieren gegen einen CMIS-Standard-Client
+CMIS-Zugriff respektiert dieselben Rechte/Mandantengrenzen wie die eigene REST-API
+Optional aktivierbar, kein Zwangsbestandteil","Test mit einem CMIS-Referenzclient gegen die Schnittstelle
+Berechtigungsprüfung im Test über CMIS-Pfad identisch zur REST-API
+Deaktivierung blockiert CMIS-Zugriff vollständig, REST-API bleibt unberührt"
+INT-10,Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung,🔌 Integration & API,Backend,Mittel,3,7,Backlog,"Leerseiten-Erkennung, Barcode-Decoding (z. B. ZBar/ZXing)","Erkennung von Trennseiten (leere Seite oder Barcode-Seite) in einem Multi-Dokument-Scan-Stapel, der über INT-06 (Hot-Folder) eingeht — trennt automatisch in einzelne Dokumente statt eine große Datei anzulegen.",INT-06,QA-09,"Leere Trennseite wird erkannt und trennt den Stapel in einzelne Dokumente
+Barcode-Trennseite wird erkannt, Barcode-Wert kann optional als Metadatenfeld übernommen werden
+Stapel ohne Trennseiten wird als ein einzelnes Dokument behandelt, kein Fehlverhalten","Test-Stapel mit Leerseiten-Trennung ergibt korrekte Anzahl Einzeldokumente
+Test-Stapel mit Barcode-Trennseiten ordnet Barcode-Werte korrekt zu
+Stapel ohne Trennseiten bleibt ein Dokument"
+DOC-14,Dokument-Zusammenführen & -Aufteilen,🗂️ Dokumentenkern,Backend,Mittel,3,4,Backlog,"PDF-Seitenmanipulation, Versionshistorie, Transaktionale Dokument-Operationen","Nachträgliches Zusammenführen mehrerer Dokumente zu einem (z.B. fälschlich getrennt gescannt) und Aufteilen eines mehrseitigen Dokuments in mehrere eigenständige Dokumente (z.B. Stapel-Scan ohne Trennseiten-Erkennung, siehe INT-10) – beides als nachträgliche Korrektur nach dem Import, nicht nur zum Importzeitpunkt.",DOC-01 DOC-09,QA-03,"Mehrere Dokumente lassen sich zu einem zusammenführen, Ursprungsdokumente bleiben in der Versionshistorie nachvollziehbar
+Ein mehrseitiges Dokument lässt sich an beliebigen Seitengrenzen in mehrere eigenständige Dokumente aufteilen, jedes mit eigenen Metadaten
+Beide Operationen respektieren bestehende Aufbewahrungssperren (Archive-Retention) – eine Kachel mit aktiver Löschsperre kann nicht durch Zusammenführen/Aufteilen umgangen werden","Test: drei Dokumente zusammengeführt, Ursprünge in Historie auffindbar
+Test: fünfseitiges Dokument an zwei Stellen geteilt, drei korrekte Einzeldokumente entstehen
+Test: Zusammenführen/Aufteilen eines Dokuments mit aktiver Löschsperre wird abgelehnt oder erfordert Freigabe, nicht stillschweigend erlaubt"
+DOC-15,Massenbearbeitung von Metadaten,🗂️ Dokumentenkern,Backend,Mittel,3,4,Backlog,"Massenoperation über Dokumentauswahl, transaktionale Verarbeitung","Mehrere ausgewählte Dokumente gleichzeitig mit Tags/Metadatenfeldern/Dokumenttyp bearbeiten (hinzufügen, entfernen, ersetzen) statt Dokument für Dokument – Vorbild paperless-ngx Bulk-Edit.",DOC-01 MET-01,QA-03,"Tag/Metadatenfeld kann über eine Auswahl mehrerer Dokumente gleichzeitig hinzugefügt oder entfernt werden
+Vorgang ist transaktional nachvollziehbar (Versionshistorie/Audit zeigt die Massenänderung, nicht stillschweigend)
+Vorgang respektiert bestehende Aufbewahrungssperren – ein gesperrtes Dokument in der Auswahl wird übersprungen mit klarer Rückmeldung, nicht die ganze Operation blockiert oder die Sperre umgangen","Test: Tag auf 10 ausgewählte Dokumente gleichzeitig angewendet, alle korrekt aktualisiert
+Audit-Log zeigt Massenänderung nachvollziehbar
+Test mit einem gesperrten Dokument in der Auswahl: dieses wird übersprungen, Rest wird bearbeitet, klare Rückmeldung welches übersprungen wurde"
+INT-11,Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage,🔌 Integration & API,Backend,Mittel,3,4,Backlog,"HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping","Dokument-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung/Änderung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik im DMS zu bauen.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert
+Vor Löschung oder Hard-Overwrite eines Dokuments wird eine Sperr-Abfrage an Archive gestellt
+Ist das Dokument gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt
+Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt","Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort
+Test: gesperrtes Dokument kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar
+Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung"
+INT-12,AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01),🔌 Integration & API,Backend,Mittel,2,4,Backlog,"HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping","Dokument-Objekttyp und dessen KI-relevante Felder (Volltext, Metadaten) bei NEXARCH AI registrieren, damit Klassifizierung, Extraktion und semantische Suche für Dokumente optional nutzbar werden, ohne eigene KI-Logik im DMS zu bauen.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert
+Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet das DMS unverändert ohne Fehler
+Registrierungsfehler blockieren niemals den regulären DMS-Betrieb (fail open bei Registrierung, nicht bei Löschung)","Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort
+Test: AI-Modul deaktiviert – DMS startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb
+Test: AI-Endpunkt nicht erreichbar bei Registrierung – DMS-Start wird dadurch nicht blockiert"
+INT-13,Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02),🔌 Integration & API,Backend,Mittel,3,4,Backlog,"HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher","Dokument-Objekttyp und Auslöser-Ereignisse (Dokument angelegt, Status geändert, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik im DMS ausgelöst werden können.",DOC-01,QA-09 INT-16,"Dokument-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert
+Ereignis 'Dokument angelegt' wird beim Anlegen eines Dokuments tatsächlich an Workflow publiziert
+Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende DMS-Aktion (asynchron, nicht im Request-Pfad)","Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort
+Test: Dokument angelegt – Ereignis kommt nachweislich bei Workflow an
+Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Dokumentanlage im DMS bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)"
+SRC-11,Feld-Whitelist-Query-Builder für Suchindex-Zugriff,🔍 Suche & OCR,Backend,Einfach,1,3,Backlog,"Statisches Enum/Switch für Feldnamen, getesteter Query-Builder","Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den DMS-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.",SRC-01,QA-06,"Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau
+Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung
+Entscheidung dokumentiert: DMS-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren","Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert
+Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt"
+DOC-16,RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf,🗂️ Dokumentenkern,Backend,Mittel,3,5,Fertig,"HTTP-Client gegen Archive RET-05, Rückruf-Endpunkt, Postgres-Jobqueue (FDN-04) für Requeue","DMS registriert seine Objekttypen (Dokument, Anhang) bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, empfängt Vernichtungs-Rückrufe und behandelt Registrierungsfehler tolerant statt sie zu verschlucken.",DOC-01 FDN-04 RET-09,,"DMS registriert seine Objekttypen (Dokument, Anhang) bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse
+DMS empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg
+Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue über FDN-04, nicht zu einem Absturz oder stillem Verwerfen","Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert
+Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, DMS-Löschung nachweislich erfolgt, 2xx-Antwort gesendet
+Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag in der Jobqueue, kein Absturz"
+INT-14,Tenant-Zuordnung & Zugriffsschutz für Hot-Folder/Scanner-Verzeichnisse,🔌 Integration & API,Backend,Mittel,2,12,Backlog,"Dateisystem-Zugriffsrechte, Verzeichnisstruktur je Tenant, Go","INT-06 (Netzwerkscanner-Ordner) und INT-08 (Hot-Folder) importieren Dateien ohne API-Aufruf und damit ohne Anwendungs-Auth-Kontext. Ohne klare Zuordnung, welches Verzeichnis zu welchem Mandanten gehört, und ohne Zugriffsschutz auf Dateisystemebene kann eine falsch konfigurierte Freigabe Dokumente dem falschen Tenant zuordnen oder Dritten Schreibzugriff erlauben. Je Tenant ein eigenes, klar benanntes Verzeichnis mit dediziertem Dateisystem-Benutzer/Gruppenrechten einführen, Import-Routine prüft beim Einlesen explizit die Tenant-Zuordnung des Quellverzeichnisses gegen die Registry (Core TEN-01), bevor ein Dokument angelegt wird.",INT-06 INT-08,,"Jedes Hot-Folder-/Scanner-Verzeichnis ist genau einem Tenant fest zugeordnet, verankert in der Core-Registry
+Die Import-Routine lehnt einen Import ab und protokolliert dies, wenn die Verzeichnis-Tenant-Zuordnung nicht auflösbar oder inkonsistent ist
+Dateisystemrechte beschränken Schreibzugriff auf das Verzeichnis auf die vorgesehenen Quellen (Scanner/Sync-Tool), dokumentiert in der Betriebsanleitung","Test: Import aus einem korrekt zugeordneten Verzeichnis legt Dokument beim richtigen Tenant an
+Test: Import aus einem nicht zugeordneten/fehlkonfigurierten Verzeichnis wird abgelehnt und protokolliert
+Prüft Dateisystemrechte des Verzeichnisses gegen die Betriebsanleitung"
+INT-15,CMIS-Schnittstelle: Auth-/Tenant-Scoping-Parität zur REST-API,🔌 Integration & API,Backend,Mittel,2,12,Backlog,"CMIS, gemeinsame Auth-Middleware, Go","INT-09 stellt eine CMIS-Standardschnittstelle für Drittwerkzeuge bereit, ohne festzulegen, ob diese dieselbe Authentifizierung und Tenant-Scoping-Durchsetzung wie die REST-API verwendet. Eine zweite, schwächer geprüfte API-Fläche würde die gesamte Zugriffskontrolle umgehbar machen. CMIS auf dieselbe Auth-Middleware und Tenant-Kontext-Ermittlung wie die REST-API (INT-01) verpflichten – keine eigene, parallele Auth-Implementierung.",INT-09,,"CMIS-Endpunkte verwenden dieselbe Auth-Middleware wie die REST-API, keine eigene Login-/Token-Prüfung
+Ein über CMIS authentifizierter Aufruf ist auf denselben Tenant beschränkt wie über die REST-API mit denselben Credentials
+Ein automatisierter Test vergleicht Zugriffsergebnisse für dieselbe Anfrage über REST und CMIS und erwartet identisches Autorisierungsverhalten","Test: Zugriff auf ein fremdes Tenant-Dokument über CMIS wird identisch zur REST-API abgelehnt
+Test: abgelaufenes/widerrufenes Token wird von CMIS genauso abgelehnt wie von der REST-API (Kopplung an Core IAM-17)
+Code-Review-Gate: CMIS-Handler dürfen keine eigene Auth-Logik enthalten, nur die gemeinsame Middleware referenzieren"
+INT-16,Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow),🔌 Integration & API,Backend,Mittel,2,12,Backlog,"Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go","INT-11/12/13 registrieren DMS-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe (z. B. DOC-13 → Workflow VOR-04) dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl DMS selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.",INT-11 INT-12 INT-13,,"Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
+Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert","Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
+Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
+Integrationstest über DOC-13 → Workflow VOR-04 mit zwei verschiedenen Tenants, prüft Isolation"
+DOC-17,Malware-Scan vor Ablage,🗂️ Dokumentenkern,Backend,Mittel,2,12,Backlog,"Virenscanner-Anbindung (z. B. ClamAV), Go, Postgres-Jobqueue","DOC-01 validiert Größe und MIME-Typ beim Upload, prüft aber nicht auf schädliche Inhalte (Viren, aktive Inhalte in Office-Dokumenten/Makros). Virenscan als verpflichtenden Verarbeitungsschritt vor endgültiger Ablage ergänzen – Upload bleibt in Quarantäne-Status, bis der Scan abgeschlossen ist; bei Fund wird das Dokument abgelehnt und der Vorfall protokolliert.",DOC-01,,"Jede hochgeladene Datei durchläuft einen Virenscan, bevor sie als reguläres Dokument sichtbar/abrufbar wird
+Ein positiver Scan-Fund führt zur Ablehnung des Dokuments und einem Audit-Event, nicht zu stiller Ablage
+Der Scan-Status ist für den hochladenden Nutzer sichtbar (in Bearbeitung/freigegeben/abgelehnt)","Test mit EICAR-Testdatei: wird zuverlässig erkannt und abgelehnt
+Test mit sauberer Datei: durchläuft Scan und wird normal verfügbar
+Lasttest: Scan-Queue verarbeitet mehrere gleichzeitige Uploads ohne Verlust der Reihenfolge/Nachvollziehbarkeit"
+FDN-10,Signierte URLs: Scope-Bindung & kurze Ablaufzeit,⚙️ Fundament,Backend,Einfach,1,12,Backlog,"Storage-Adapter (S3-kompatibel), signierte URLs, Go","FDN-03 stellt signierte URLs für den Storage-Zugriff bereit, ohne deren Scope und Ablaufzeit explizit festzulegen. Jede signierte URL muss fest an genau ein Objekt gebunden sein (nicht an ein Präfix/Verzeichnis) und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden). Nach Ablauf oder nach Löschung/Versionswechsel des Objekts muss die URL ungültig sein.",FDN-03,,"Eine signierte URL gewährt ausschließlich Zugriff auf genau das Objekt, für das sie ausgestellt wurde
+Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
+Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stilles Fallback auf öffentlichen Zugriff","Test: signierte URL für Objekt A liefert bei Zugriffsversuch auf Objekt B einen Fehler
+Test: abgelaufene URL wird abgelehnt
+Test: URL für ein zwischenzeitlich gelöschtes Objekt wird abgelehnt"
+FDN-11,Ressourcenlimits für asynchrone Verarbeitungsjobs,⚙️ Fundament,Backend,Mittel,2,12,Backlog,"Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)","FDN-04 verarbeitet OCR/Konvertierung/Indexierung/Exporte mit Wiederholungslogik, Backoff und Dead-Letter-Queue, ohne Obergrenzen pro Einzeljob festzulegen. Eine sehr große oder speziell präparierte Datei (z. B. sehr viele Seiten, Zip-Bomb-artige Kompression bei Konvertierung) kann einen Worker dauerhaft blockieren und damit die Verarbeitung für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job abgebrochen, in die Dead-Letter-Queue verschoben und der Nutzer informiert, statt den Worker zu blockieren.",FDN-04,,"Jeder Verarbeitungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
+Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
+Andere, gleichzeitig laufende Jobs (auch anderer Mandanten) bleiben von einem überschreitenden Job unbeeinflusst","Test mit einer Datei, die absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
+Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
+Test der Nutzerbenachrichtigung bei abgebrochenem Job"
+VER-08,Technische Durchsetzung Append-only für das Versionierungs-/Ereignisprotokoll,🔄 Versionierung & Audit,Backend,Einfach,2,12,Backlog,"PostgreSQL (REVOKE/Trigger), Go","VER-05 konzipiert ein unveränderliches, verkettetes Protokoll aller sicherheits- und geschäftsrelevanten Ereignisse, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.",VER-05,,"Die vom DMS-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
+Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
+Die Verkettung (Unversehrtheitsnachweis) aus VER-05 bleibt vollständig nutzbar","Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
+Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+Regressionstest: Verkettungsprüfung (Unversehrtheitsnachweis) funktioniert nach der Rechteänderung weiterhin"

dms-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>DMS Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>DMS 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": 229, "epics": [{"key": "FDN", "name": "Fundament", "emoji": "⚙️", "color": "#64748B", "description": "Projektgerüst, Datenmodell, Storage, Queue, Auth-Basis, CI und Observability. Alles andere baut hierauf auf."}, {"key": "DOC", "name": "Dokumentenkern", "emoji": "🗂️", "color": "#3B82F6", "description": "Upload, Vorschau, Download, Ablagestruktur und Papierkorb – das funktionale Herz des DMS."}, {"key": "SRC", "name": "Suche & OCR", "emoji": "🔍", "color": "#06B6D4", "description": "Volltextindex, OCR-Pipeline, Facetten und gespeicherte Suchen."}, {"key": "MET", "name": "Metadaten", "emoji": "🏷️", "color": "#10B981", "description": "Tags, benutzerdefinierte Felder, Dokumententypen und automatische Klassifizierung."}, {"key": "VER", "name": "Versionierung & Audit", "emoji": "🔄", "color": "#EC4899", "description": "Versionskontrolle, Historie, revisionssicherer Audit-Trail und Signatur."}, {"key": "INT", "name": "Integration & API", "emoji": "🔌", "color": "#14B8A6", "description": "Öffentliche REST-API, E-Mail-Import, Webhooks und Scanner-Anbindung."}, {"key": "UX", "name": "UX & Zugänglichkeit", "emoji": "📱", "color": "#F97316", "description": "Responsive Ansicht, Theming, Mehrsprachigkeit und Barrierefreiheit."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#22C55E", "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab."}], "waves": [{"welle": 1, "codes": ["FDN-01", "UX-01", "UX-02", "UX-03"]}, {"welle": 2, "codes": ["FDN-02", "FDN-03", "FDN-07", "FDN-08", "FDN-09", "SRC-01", "UX-04", "UX-05"]}, {"welle": 3, "codes": ["DOC-01", "DOC-09", "FDN-04", "MET-01", "MET-02", "QA-01", "QA-11", "VER-05"]}, {"welle": 4, "codes": ["DOC-02", "DOC-03", "DOC-04", "DOC-06", "DOC-07", "DOC-10", "DOC-11", "DOC-14", "DOC-15", "INT-01", "INT-03", "INT-08", "MET-03", "MET-04", "QA-02", "QA-07", "VER-01", "VER-06", "INT-11", "INT-12", "INT-13"]}, {"welle": 5, "codes": ["DOC-05", "DOC-08", "DOC-12", "INT-09", "SRC-02", "SRC-05", "VER-02", "VER-03", "VER-07"]}, {"welle": 6, "codes": ["DOC-13", "INT-06", "MET-05", "QA-03", "SRC-03", "SRC-06", "SRC-07", "VER-04"]}, {"welle": 7, "codes": ["INT-04", "INT-10", "QA-08", "QA-10", "SRC-04", "SRC-08", "QA-05"]}, {"welle": 8, "codes": ["QA-09", "SRC-09", "SRC-10"]}, {"welle": 9, "codes": ["QA-04"]}, {"welle": 10, "codes": ["QA-06"]}, {"welle": 11, "codes": ["QA-12"]}, {"welle": 12, "codes": ["INT-14", "INT-15", "INT-16", "DOC-17", "FDN-10", "FDN-11", "VER-08"]}], "kritischerPfad": {"tage": 28, "pfad": ["FDN-01", "FDN-02", "DOC-01", "DOC-04", "DOC-05", "VER-04", "QA-08", "QA-12"]}, "produktDna": {"uebernehmen": [{"produkt": "paperless-ngx", "staerke": "Kompromisslose Erfassungs-Pipeline: Consume-Ordner, Vorverarbeitung, OCR, durchsuchbares PDF/A – vollautomatisch ohne Nutzerinteraktion."}, {"produkt": "paperless-ngx", "staerke": "Regelwerk für automatische Zuordnung von Korrespondent, Dokumenttyp und Tags direkt beim Import."}, {"produkt": "Docspell", "staerke": "Sprachverarbeitende Extraktion konkreter Werte: Absender, Datum, Betrag, Vertragspartner werden als strukturierte Felder vorgeschlagen."}, {"produkt": "Docspell", "staerke": "Sauberes Mandanten- und Datenmodell sowie ausgereifter Postfach-Abruf inklusive Anhangbehandlung."}, {"produkt": "Alfresco", "staerke": "Vererbende Zugriffskontrolle über die Ablagehierarchie mit expliziten Erlaubnissen und Verboten."}, {"produkt": "Alfresco", "staerke": "Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik."}, {"produkt": "Alfresco", "staerke": "Versionierung mit Ausleihen/Einchecken sowie Aufbewahrungssteuerung inklusive Aufbewahrungssperre."}, {"produkt": "ecoDMS", "staerke": "Revisionssicherheit als Grundhaltung: unveränderliches Protokoll, nachvollziehbare Vernichtung, Vier-Augen-Freigabe."}, {"produkt": "ecoDMS", "staerke": "Praxisnaher Scanner- und Stapelworkflow mit Trennseiten und Klassifizierungsvorlagen."}], "vermeiden": [{"produkt": "Alfresco", "schwaeche": "Schwergewichtige Plattform mit hohem Ressourcenbedarf, langer Startzeit und aufwendigem Betrieb.", "gegenmittel": "Schlanker Dienst plus getrennte Worker. Jede Komponente muss auf einem kleinen Server startklar sein."}, {"produkt": "Alfresco", "schwaeche": "Übermächtiges Konfigurationsmodell mit steiler Lernkurve und träger Oberfläche.", "gegenmittel": "Sinnvolle Voreinstellungen, die ohne Konfiguration funktionieren. Komplexität nur dort, wo sie nachweislich gebraucht wird."}, {"produkt": "paperless-ngx", "schwaeche": "Kaum Governance: keine echte Rechtevererbung, keine Freigabeprozesse, keine Versionen, kein belastbares Protokoll.", "gegenmittel": "Rechte, Versionierung und Protokoll gehören von Anfang an ins Fundament, nicht als Nachrüstung."}, {"produkt": "paperless-ngx", "schwaeche": "Flache Ablage ohne HierarcLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

dms-kanban/tickets/DOC-17.md

@@ -0,0 +1,58 @@
+# DOC-17 – Malware-Scan vor Ablage
+
+**Epic:** 🗂️ Dokumentenkern  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+DOC-01 validiert Größe und MIME-Typ beim Upload, prüft aber nicht auf schädliche Inhalte (Viren, aktive Inhalte in Office-Dokumenten/Makros). Virenscan als verpflichtenden Verarbeitungsschritt vor endgültiger Ablage ergänzen – Upload bleibt in Quarantäne-Status, bis der Scan abgeschlossen ist; bei Fund wird das Dokument abgelehnt und der Vorfall protokolliert.
+
+**Technische Grundlage:** Virenscanner-Anbindung (z. B. ClamAV), Go, Postgres-Jobqueue
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- paperless-ngx: Verarbeitungspipeline mit klar abgegrenzten, nacheinander laufenden Schritten (hier: Upload → Scan → Freigabe).
+
+**Bewusst vermeiden:**
+- ecoDMS – in älteren Versionen kein verpflichtender Malware-Scan vor Ablage.: Scan ist ein Pflichtschritt, kein optionales Zusatzfeature.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: DOC-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede hochgeladene Datei durchläuft einen Virenscan, bevor sie als reguläres Dokument sichtbar/abrufbar wird
+2. Ein positiver Scan-Fund führt zur Ablehnung des Dokuments und einem Audit-Event, nicht zu stiller Ablage
+3. Der Scan-Status ist für den hochladenden Nutzer sichtbar (in Bearbeitung/freigegeben/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. Test mit EICAR-Testdatei: wird zuverlässig erkannt und abgelehnt
+2. Test mit sauberer Datei: durchläuft Scan und wird normal verfügbar
+3. Lasttest: Scan-Queue verarbeitet mehrere gleichzeitige Uploads ohne Verlust der Reihenfolge/Nachvollziehbarkeit
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): MIME-/Größenvalidierung allein erkennt keine schädlichen Inhalte innerhalb eines gültigen Dateityps (z. B. Makro in einer echten .docx-Datei).
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `DOC-01` Upload-API & Chunk-Handling
+
+## 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: `DOC-17: malware-scan-vor-ablage`
+- Branch: `feature/doc-17-malware-scan-vor-ablage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/FDN-10.md

@@ -0,0 +1,58 @@
+# FDN-10 – Signierte URLs: Scope-Bindung & kurze Ablaufzeit
+
+**Epic:** ⚙️ Fundament  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+FDN-03 stellt signierte URLs für den Storage-Zugriff bereit, ohne deren Scope und Ablaufzeit explizit festzulegen. Jede signierte URL muss fest an genau ein Objekt gebunden sein (nicht an ein Präfix/Verzeichnis) und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden). Nach Ablauf oder nach Löschung/Versionswechsel des Objekts muss die URL ungültig sein.
+
+**Technische Grundlage:** Storage-Adapter (S3-kompatibel), signierte URLs, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- paperless-ngx/Alfresco: zeitlich begrenzte, objektgebundene Zugriffs-Tokens statt dauerhafter Links.
+
+**Bewusst vermeiden:**
+- Alfresco – in älteren Konfigurationen teils lang gültige Download-Links ohne erzwungene kurze TTL.: Ablaufzeit ist ein hartes, kurzes Limit, keine Empfehlung.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: FDN-03.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Eine signierte URL gewährt ausschließlich Zugriff auf genau das Objekt, für das sie ausgestellt wurde
+2. Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
+3. Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stilles Fallback auf öffentlichen Zugriff
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: signierte URL für Objekt A liefert bei Zugriffsversuch auf Objekt B einen Fehler
+2. Test: abgelaufene URL wird abgelehnt
+3. Test: URL für ein zwischenzeitlich gelöschtes Objekt wird abgelehnt
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): ohne explizite Scope-/TTL-Vorgabe könnten signierte URLs versehentlich zu breit (Präfix statt Objekt) oder zu lange gültig ausgestellt werden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `FDN-03` Objekt-Storage-Abstraktion
+
+## 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: `FDN-10: signierte-urls-scope-bindung-kurze-ablaufzeit`
+- Branch: `feature/fdn-10-signierte-urls-scope-bindung-kurze-ablaufzeit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/FDN-11.md

@@ -0,0 +1,58 @@
+# FDN-11 – Ressourcenlimits für asynchrone Verarbeitungsjobs
+
+**Epic:** ⚙️ Fundament  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+FDN-04 verarbeitet OCR/Konvertierung/Indexierung/Exporte mit Wiederholungslogik, Backoff und Dead-Letter-Queue, ohne Obergrenzen pro Einzeljob festzulegen. Eine sehr große oder speziell präparierte Datei (z. B. sehr viele Seiten, Zip-Bomb-artige Kompression bei Konvertierung) kann einen Worker dauerhaft blockieren und damit die Verarbeitung für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job abgebrochen, in die Dead-Letter-Queue verschoben und der Nutzer informiert, statt den Worker zu blockieren.
+
+**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Docspell: klare Verarbeitungsgrenzen statt unbegrenzter Best-Effort-Verarbeitung.
+
+**Bewusst vermeiden:**
+- archivdms (bekannter Fehlerklasse ähnlich) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war in Altsystemen eine wiederkehrende Betriebsstörung.: harte, konfigurierbare Obergrenzen je Job von Anfang an statt nachträglicher Begrenzung nach Vorfall.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: FDN-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Verarbeitungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
+2. Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
+3. Andere, gleichzeitig laufende Jobs (auch anderer Mandanten) bleiben von einem überschreitenden Job unbeeinflusst
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit einer Datei, die absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
+2. Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
+3. Test der Nutzerbenachrichtigung bei abgebrochenem Job
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): unbegrenzte Einzeljob-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Worker-Pool, auch ohne böswillige Absicht (einfach eine sehr große legitime Datei genügt).
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `FDN-04` Job-Queue & Worker-Runtime
+
+## 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: `FDN-11: ressourcenlimits-f-r-asynchrone-verarbeitungsjobs`
+- Branch: `feature/fdn-11-ressourcenlimits-f-r-asynchrone-verarbeitungsjobs`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/INT-14.md

@@ -0,0 +1,59 @@
+# INT-14 – Tenant-Zuordnung & Zugriffsschutz für Hot-Folder/Scanner-Verzeichnisse
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-06 (Netzwerkscanner-Ordner) und INT-08 (Hot-Folder) importieren Dateien ohne API-Aufruf und damit ohne Anwendungs-Auth-Kontext. Ohne klare Zuordnung, welches Verzeichnis zu welchem Mandanten gehört, und ohne Zugriffsschutz auf Dateisystemebene kann eine falsch konfigurierte Freigabe Dokumente dem falschen Tenant zuordnen oder Dritten Schreibzugriff erlauben. Je Tenant ein eigenes, klar benanntes Verzeichnis mit dediziertem Dateisystem-Benutzer/Gruppenrechten einführen, Import-Routine prüft beim Einlesen explizit die Tenant-Zuordnung des Quellverzeichnisses gegen die Registry (Core TEN-01), bevor ein Dokument angelegt wird.
+
+**Technische Grundlage:** Dateisystem-Zugriffsrechte, Verzeichnisstruktur je Tenant, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Docspell: klare Trennung von Eingangsordnern mit expliziter Zuordnung statt impliziter Konvention.
+
+**Bewusst vermeiden:**
+- ecoDMS – geteilte Scan-Ordner ohne harte Mandantentrennung in älteren Setups.: ein Verzeichnis gehört technisch erzwungen genau einem Tenant, keine gemeinsame Ablage mehrerer Mandanten im selben Pfad.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-06, INT-08.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jedes Hot-Folder-/Scanner-Verzeichnis ist genau einem Tenant fest zugeordnet, verankert in der Core-Registry
+2. Die Import-Routine lehnt einen Import ab und protokolliert dies, wenn die Verzeichnis-Tenant-Zuordnung nicht auflösbar oder inkonsistent ist
+3. Dateisystemrechte beschränken Schreibzugriff auf das Verzeichnis auf die vorgesehenen Quellen (Scanner/Sync-Tool), dokumentiert in der Betriebsanleitung
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Import aus einem korrekt zugeordneten Verzeichnis legt Dokument beim richtigen Tenant an
+2. Test: Import aus einem nicht zugeordneten/fehlkonfigurierten Verzeichnis wird abgelehnt und protokolliert
+3. Prüft Dateisystemrechte des Verzeichnisses gegen die Betriebsanleitung
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): dateisystembasierte Importe ohne Auth-Kontext sind ein Einfallstor für Tenant-Fehlzuordnung, das durch Modell C (physische DB-Trennung) allein nicht abgedeckt wird, weil der Fehler bereits vor dem ersten Datenbankzugriff entsteht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-06` Scanner-Anbindung über Hot-Folder
+- `INT-08` Watch-Folder-Import (Consume-Ordner)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-14: tenant-zuordnung-zugriffsschutz-f-r-hot-folder-scanner-verzeichnisse`
+- Branch: `feature/int-14-tenant-zuordnung-zugriffsschutz-f-r-hot-folder-scanner-verzeichnisse`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/INT-15.md

@@ -0,0 +1,59 @@
+# INT-15 – CMIS-Schnittstelle: Auth-/Tenant-Scoping-Parität zur REST-API
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-09 stellt eine CMIS-Standardschnittstelle für Drittwerkzeuge bereit, ohne festzulegen, ob diese dieselbe Authentifizierung und Tenant-Scoping-Durchsetzung wie die REST-API verwendet. Eine zweite, schwächer geprüfte API-Fläche würde die gesamte Zugriffskontrolle umgehbar machen. CMIS auf dieselbe Auth-Middleware und Tenant-Kontext-Ermittlung wie die REST-API (INT-01) verpflichten – keine eigene, parallele Auth-Implementierung.
+
+**Technische Grundlage:** CMIS, gemeinsame Auth-Middleware, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Alfresco: CMIS als zusätzliches Protokoll über derselben Zugriffskontrollschicht, nicht als eigener Sicherheitsperimeter.
+
+**Bewusst vermeiden:**
+- Keycloak – historisch mehrere Auth-Pfade (Admin-API, Account-Console, Protokoll-Endpunkte) mit inkonsistenter Prüfung.: genau eine Auth-/Tenant-Scoping-Implementierung für alle Protokoll-Fassaden (REST, CMIS).
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-09.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. CMIS-Endpunkte verwenden dieselbe Auth-Middleware wie die REST-API, keine eigene Login-/Token-Prüfung
+2. Ein über CMIS authentifizierter Aufruf ist auf denselben Tenant beschränkt wie über die REST-API mit denselben Credentials
+3. Ein automatisierter Test vergleicht Zugriffsergebnisse für dieselbe Anfrage über REST und CMIS und erwartet identisches Autorisierungsverhalten
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Zugriff auf ein fremdes Tenant-Dokument über CMIS wird identisch zur REST-API abgelehnt
+2. Test: abgelaufenes/widerrufenes Token wird von CMIS genauso abgelehnt wie von der REST-API (Kopplung an Core IAM-17)
+3. Code-Review-Gate: CMIS-Handler dürfen keine eigene Auth-Logik enthalten, nur die gemeinsame Middleware referenzieren
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): eine zusätzliche Protokoll-Fassade ohne geteilte Auth-Schicht ist ein klassischer Bypass-Vektor für ansonsten korrekt durchgesetzte Zugriffskontrollen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-09` CMIS-kompatible Schnittstelle (optional)
+- `INT-01` REST-API v1 & 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: `INT-15: cmis-schnittstelle-auth-tenant-scoping-parit-t-zur-rest-api`
+- Branch: `feature/int-15-cmis-schnittstelle-auth-tenant-scoping-parit-t-zur-rest-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.

dms-kanban/tickets/INT-16.md

@@ -0,0 +1,60 @@
+# INT-16 – Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-11/12/13 registrieren DMS-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe (z. B. DOC-13 → Workflow VOR-04) dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl DMS selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Service-Accounts agieren im Namen eines Kontexts, nie mit implizit eigenen, umfassenderen Rechten.
+
+**Bewusst vermeiden:**
+- Keycloak – Service-Client-Aufrufe teilen sich in manchen Integrationen denselben weiten Scope wie der Admin-Client.: Service-Credential trägt nur die Rechte, um im Namen eines übergebenen Tenant-Kontexts zu handeln, nie tenant-übergreifend von sich aus.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-11, INT-12, INT-13.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+2. Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
+3. Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
+2. Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
+3. Integrationstest über DOC-13 → Workflow VOR-04 mit zwei verschiedenen Tenants, prüft Isolation
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12): physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal über Service-Credentials ohne durchgereichten Nutzer-Tenant-Kontext kann diese Isolation modulübergreifend aufweichen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-11` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
+- `INT-12` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
+- `INT-13` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-16: nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Branch: `feature/int-16-nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

dms-kanban/tickets/VER-08.md

@@ -0,0 +1,58 @@
+# VER-08 – Technische Durchsetzung Append-only für das Versionierungs-/Ereignisprotokoll
+
+**Epic:** 🔄 Versionierung & Audit  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 12
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+VER-05 konzipiert ein unveränderliches, verkettetes Protokoll aller sicherheits- und geschäftsrelevanten Ereignisse, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.
+
+**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.: Unveränderlichkeit ist eine Datenbank-Garantie, keine Anwendungs-Konvention.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: VER-05.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die vom DMS-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
+2. Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
+3. Die Verkettung (Unversehrtheitsnachweis) aus VER-05 bleibt vollständig 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 Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
+2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+3. Regressionstest: Verkettungsprüfung (Unversehrtheitsnachweis) funktioniert nach der Rechteänderung weiterhin
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (DMS-Board, 2026-09-12), Analogie zu Core-Finding #5/AUD-07: 'unveränderlich' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VER-05` Revisionssicherer Audit-Trail
+
+## 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: `VER-08: technische-durchsetzung-append-only-f-r-das-versionierungs-ereignisprotokoll`
+- Branch: `feature/ver-08-technische-durchsetzung-append-only-f-r-das-versionierungs-ereignisprotokoll`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

mail-kanban/README.md

@@ -0,0 +1,119 @@
+# Mail-Kanban – lokal abarbeiten
+
+70 Arbeitskacheln · 7 Epics · 171 Personentage · 8 Wellen (inkl. Welle 8: Threat-Model-Nachtrag 2026-09-12 — ING-11, INT-11, INT-12, SRC-12).
+Stand: 2026-08-26
+
+Hinweis: Aufbewahrung, WORM, Compliance-Berichte und Backup sind ausgelagert in NEXARCH Archive (siehe ../archive-kanban/) — dieses Board enthält dafür keine eigenen Tickets mehr.
+
+Hinweis: REST-API-Grundgerüst, Rate-Limiting, OpenAPI-Tooling und Webhook-Zustellung sind ausgelagert in NEXARCH Core (siehe ../core-kanban/, API-01/03/04/07) — dieses Board definiert nur noch die modul-eigenen Endpunkte.
+
+Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board.
+
+NEXARCH Mail ist die Ablösung von archivmail. Code-Wiederverwendung aus archivmail
+ist hier – anders als beim DMS-Board – ausdrücklich erlaubt und gewünscht, weil
+IMAP-/SMTP-/POP3-Protokolllogik komplex und fehleranfällig ist. Übernommener Code
+muss dabei an den in `known-issues-archivmail.md` dokumentierten Stellen korrigiert
+werden, nicht 1:1 kopiert – siehe die Hinweise "Konzept aus archivmail als Vorlage
+nutzbar" bzw. "kein Vorbild in archivmail" in jeder Kachel sowie
+`repos-analyse-mail-reuse.md` für die vollständige Bewertung je Fachbereich.
+
+IAM/Tenancy/Auth/Lizenzierung/Feature-Flags/Audit-Grundmodell werden in diesem
+Board **nicht** behandelt – das liefert bereits `core-kanban/` zentral. Kacheln
+dieses Boards referenzieren Core-Board-Kacheln nur als externe Voraussetzung in
+der Ausgangslage, nicht als Abhängigkeit innerhalb des eigenen Boards.
+
+## Weg 1 – Sofort loslegen (empfohlen)
+
+`kanban.html` per Doppelklick im Browser öffnen. Kein Server, kein Internet, keine Installation.
+
+- Kacheln per Drag & Drop zwischen Backlog → Bereit → In Arbeit → Prüfung → Fertig ziehen
+- Der Stand wird im Browser gespeichert (localStorage) und bleibt nach dem Schließen erhalten
+- Filter nach Epic, Rolle, Welle, Volltext sowie „Nur startbare“ (alle Vorgänger auf Fertig)
+- Klick auf eine Kachel öffnet Details inkl. vollem Bau-Prompt und „Prompt kopieren“
+- „Stand sichern“ exportiert den aktuellen Status als CSV
+
+Hinweis: Der Stand hängt an Browser und Profil. Für Teamarbeit Weg 2 oder 3 nutzen.
+
+## Weg 2 – Import in ein vorhandenes Werkzeug
+
+`board.csv` (UTF-8 mit BOM, Komma-getrennt) importieren:
+
+| Werkzeug | Weg |
+| --- | --- |
+| Trello | Board → Menü → Mehr → CSV importieren (Power-Up) |
+| Jira | Einstellungen → System → Externes Importieren → CSV, Spalte „Status“ auf den Workflow mappen |
+| GitHub Projects | Projekt → … → Import, oder per `gh` CLI aus `board.json` |
+| Notion | Datenbank → … → Merge with CSV |
+| Linear / Asana / ClickUp | jeweils CSV-Import, Spalten wie oben zuordnen |
+
+Spalten: Code, Titel, Epic, Rolle, Komplexitaet, Aufwand_PT, Welle, Status, Technik,
+Beschreibung, Haengt_ab_von, Schaltet_frei, Akzeptanzkriterien, Pruefungen.
+
+## Weg 3 – Dateibasiert in der Entwicklungsumgebung
+
+Der Ordner `tickets/` enthält für jede Kachel eine Markdown-Datei (`ING-01.md` …).
+Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage,
+Akzeptanzkriterien, Prüfungen und Abschlussregeln.
+
+- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren.
+- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen.
+- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch.
+
+## Weg 4 – Eigenes Board im Netzwerk (Team)
+
+Selbst gehostet, jeweils mit CSV-Import:
+
+```bash
+# Focalboard
+docker run -d -p 8000:8000 --name focalboard mattermost/focalboard
+
+# Planka
+docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest
+
+# Vikunja
+docker run -d -p 3456:3456 --name vikunja vikunja/vikunja
+```
+
+Danach `board.csv` importieren.
+
+## Reihenfolge der Arbeit
+
+Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar,
+sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen.
+
+- **Welle 1** (5 Kacheln): ING-01, ING-03, ING-04, QA-01, QA-05
+- **Welle 2** (4 Kacheln): ARC-01, ING-02, ING-05, ING-09
+- **Welle 3** (13 Kacheln): ARC-02, ARC-03, ARC-04, ARC-05, ARC-06, ARC-07, IMP-01, ING-06, ING-07, ING-08, ING-10, QA-07, UX-03
+- **Welle 4** (11 Kacheln): ARC-08, IMP-02, IMP-03, IMP-04, IMP-05, IMP-07, INT-05, QA-04, SRC-01, SRC-07, UX-01
+- **Welle 5** (12 Kacheln): ARC-09, IMP-06, IMP-08, IMP-09, SRC-02, SRC-03, SRC-09, SRC-10, UX-02, UX-04, UX-05, UX-06
+- **Welle 6** (9 Kacheln): INT-01, QA-02, QA-03, SRC-04, SRC-05, SRC-08, UX-07, UX-08, UX-09
+- **Welle 7** (6 Kacheln): INT-06, INT-07, QA-06, QA-08, QA-09, SRC-06
+
+Kritischer Pfad (21 PT): ING-01 → ING-05 → IMP-01 → UX-01 → UX-02 → UX-07 → QA-08
+
+## Produkt-DNA
+
+### Übernehmen
+- **Dovecot**: Referenzarchitektur für robuste IMAP-Server – klare Trennung von Protokoll-Zustandsmaschine, Storage-Backend und Auth-Schicht.
+- **Dovecot**: Defensive Behandlung nicht-konformer Clients/Server statt optimistischem Parsing, das bei Abweichungen still falsch weiterläuft.
+- **Rspamd**: Mailserver-Härtung und Rate-Limiting als eigenständige, vorgeschaltete und konfigurierbare Schicht.
+- **Mailpit/MailHog**: Mailflows sind von Anfang an automatisiert testbar, ohne echten Mailserver oder externe Postfächer.
+- **ecoDMS**: Revisionssichere Ablage – einmal archivierte Inhalte sind unveränderlich und lückenlos nachvollziehbar.
+- **Alfresco**: Aufbewahrungsfristen und Audit-Trail als Kernfunktion der Content-Verwaltung, nicht als Nachrüstung.
+
+### Vermeiden
+- **archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung im Mailer.**: Ausgabe strikt über `net/mail`-Writer oder harte CRLF-/Steuerzeichen-Validierung.
+- **archivmail – ungebremstes `io.ReadAll` beim Anhang-Parsing ohne Größenlimit.**: `io.LimitReader` mit Max-Size und harter Ablehnung bei Überschreitung.
+- **archivmail – nur 2 von 18 Modulen mit Tests trotz protokollkritischer Logik.**: Pflichttests für Tenant-Scoping und Protokoll-State-Machines vor jedem Merge.
+- **archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.**: Spalten- und Tabellennamen ausschließlich aus statischen Konstanten, zentraler Query-Builder mit Feld-Whitelist.
+- **archivmail – Tenant-Filter als Post-Filter statt in der Query bei eDiscovery.**: Tenant-Scoping ausschließlich in Query-/Repository-Schicht.
+- **archivmail – Content-Type-Erkennung bei Anhang-Vorschau nur über Dateiendung, iframe-PDF-Vorschau.**: serverseitige Magic-Bytes-Erkennung, Canvas-Rendering statt iframe.
+- **archivmail – Restore-Datenintegritätsbug bei nicht-leerem Zielverzeichnis.**: atomarer Swap über leeres Temp-Verzeichnis.
+- **archivmail – kein zentrales Issue-Tracking, nur `BUG-N`-Kommentare im Code.**: Bugs durchsuchbar und projektweit sichtbar tracken.
+
+## Arbeitsregeln
+
+Je Kachel ein eigener Branch, schrittweise committen, Branch pushen, dann anhalten.
+Kein Merge und kein Deploy ohne ausdrückliche Freigabe.
+
+Code-Struktur: Hauptdateien/Entry-Points klein halten, Fachlogik in eigene Module/Dateien auslagern. Vor dem Anlegen einer neuen Funktions-/Modul-Datei prüfen, ob dieselbe Funktionalität nicht schon in einem anderen Modul (auch modulübergreifend, z. B. Core) existiert — keine doppelten Funktionsdateien, ein Modul/Board referenziert das andere extern statt Code zu kopieren (gleiches Prinzip wie bei den Konsolidierungen IAM/Archive/Workflow/AI/API/UI-Shell, siehe nexarch-state.json).

mail-kanban/board.csv

@@ -0,0 +1,356 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+ARC-01,Objekt-Speicher-Anbindung für Mails/Anhänge,🗄️ Archivierung & Speicherung,Backend,Mittel,3,2,Fertig,"Go, S3-kompatibles Objektspeicher-API","Anbindung eines Objektspeichers für archivierte Mails und Anhänge: Ablagepfad-Konvention, Schreiben/Lesen, Konsistenzprüfung nach dem Schreiben.",ING-04,ARC-02 ARC-03 ARC-04 ARC-05 ARC-06 ARC-07 INT-01 SRC-01 SRC-07 UX-03 ARC-09 ARC-10 INT-08 INT-09 INT-10 INT-12,"Mails und Anhänge werden nach fester, dokumentierter Pfadkonvention abgelegt
+Jeder Schreibvorgang wird durch Prüfsummenvergleich verifiziert
+Lesezugriff ist unabhängig vom ursprünglichen Importpfad möglich
+Objektgröße wird bei jedem Schreib-/Löschvorgang an den zentralen Speicherverbrauch-Zähler (Core LIC-05) gemeldet","Test: geschriebenes Objekt liefert beim Lesen byteidentischen Inhalt
+Test: absichtlich beschädigtes Objekt wird bei Prüfsummenvergleich erkannt
+Lasttest mit vielen kleinen Objekten bestätigt akzeptable Latenz
+Melde-Aufruf an Core LIC-05 bei Schreib- und Löschvorgang nachweislich ausgelöst, mit korrekter Größenangabe"
+ARC-02,Verschlüsselung at rest,🗄️ Archivierung & Speicherung,Backend,Mittel,3,3,Fertig,"Go, AES-256-GCM","Verschlüsselung archivierter Mails/Anhänge at rest einführen. Der Master-Key (KEK) wird über Core API-10 (Master-Key-Verwaltung & -Rotation, KMS-Anbindung) bezogen. Dieses Ticket bleibt zuständig für die modul-lokale Objekt-Verschlüsselung (DEK pro Objekt, Envelope-Verfahren mit dem von Core bezogenen KEK) – nicht für die Master-Key-Verwaltung selbst.",ARC-01,ARC-08,"Alle archivierten Inhalte sind at rest verschlüsselt abgelegt
+Der Master-Key (KEK) wird über Core API-10 bezogen, Schlüsselmaterial ist getrennt vom Datenspeicher verwaltet und nicht im Code
+Entschlüsselung ist nur mit gültigem, mandantenbezogenem Schlüssel möglich","Test: Zugriff auf Rohspeicher ohne Schlüssel liefert keine lesbaren Inhalte
+Test: falscher Mandantenschlüssel verweigert Entschlüsselung
+Performance-Test bestätigt akzeptablen Overhead durch Verschlüsselung"
+ARC-03,Dublettenerkennung E-Mail,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, Hashing (SHA-256)","Dublettenerkennung für archivierte E-Mails über Inhalts-Hash, um Mehrfachimport derselben Nachricht zu vermeiden bzw. sichtbar zu machen.",ARC-01,SRC-01 SRC-02 SRC-07,"Identische Nachrichten werden über Inhalts-Hash zuverlässig als Duplikat erkannt
+Duplikate werden referenziert statt redundant gespeichert oder klar markiert
+Erkennung funktioniert mandantenübergreifend korrekt getrennt","Test: dieselbe Nachricht aus zwei Quellen wird als Duplikat erkannt
+Test: zwei Mandanten mit identischem Mailinhalt werden nicht fälschlich verknüpft
+Test mit knapp unterschiedlichen Nachrichten bestätigt korrekte Nicht-Erkennung"
+ARC-04,Aufbewahrungsstruktur (Mandant/Postfach/Jahr),🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, Objektspeicher-Pfadkonvention","Aufbewahrungsstruktur nach Mandant/Postfach/Jahr für archivierte Mails festlegen und durchsetzen, als Grundlage für Retention und Export.",ARC-01,QA-05,"Ablagestruktur folgt durchgängig dem Schema Mandant/Postfach/Jahr
+Struktur ist Grundlage für spätere Retention-Regeln ohne Migration
+Abweichende oder fehlende Metadaten führen zu definiertem Fallback-Pfad, nicht zu Ablagefehler","Test: Import über mehrere Jahre erzeugt korrekt getrennte Jahresordner
+Test: fehlendes Postfach-Attribut nutzt dokumentierten Fallback
+Stichprobenprüfung der Struktur durch zweite Person"
+ARC-05,Papierkorb & Soft-Delete für Mails,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Backlog,"Go, Postgres (Soft-Delete-Flag)","Papierkorb-Funktion mit Soft-Delete für archivierte Mails: Wiederherstellbarkeit innerhalb einer Frist, endgültiges Löschen danach.",ARC-01 RET-03,QA-05,"Gelöschte Mails bleiben innerhalb der Frist wiederherstellbar
+Endgültige Löschung nach Fristablauf ist nachvollziehbar protokolliert
+Soft-Delete respektiert bestehende Aufbewahrungssperren (Litigation Hold)","Test: Wiederherstellung innerhalb der Frist liefert unveränderten Inhalt
+Test: Mail mit aktiver Aufbewahrungssperre kann nicht endgültig gelöscht werden
+Test: Fristablauf löst automatische endgültige Löschung aus"
+ARC-06,Mandantentrennung im Objekt-Storage,🗄️ Archivierung & Speicherung,Backend,Einfach,2,3,Fertig,"Go, ein Bucket/Pfad-Root pro Mandant","Physische Mandantentrennung im Objekt-Storage durchsetzen — jeder Mandant hat einen eigenen Bucket/Pfad-Root (angelegt im selben Provisioning-Schritt wie die Tenant-Datenbank, siehe Core TEN-01), keine gemeinsame Ablage mit Pfad-Präfix mehr.",ARC-01,QA-04,"Jeder Mandant hat einen eigenen, physisch getrennten Bucket/Pfad-Root im Objektspeicher
+Ein Zugriffsversuch ohne oder mit falschem Tenant-Kontext kann technisch kein fremdes Bucket erreichen, nicht nur einen falschen Pfad
+Bucket-Provisionierung ist Teil desselben automatisierten Schritts wie die Tenant-Datenbank-Anlage (Core TEN-01), keine manuelle Zusatzaktion nötig","Test bestätigt physische Bucket-Trennung zweier Mandanten
+Simulierter Zugriffsversuch ohne Tenant-Kontext schlägt fehl, weil kein Bucket referenzierbar ist, nicht weil ein Pfadfilter greift
+Provisionierungs-Test legt für einen neuen Mandanten Datenbank UND Bucket in einem Schritt an"
+ARC-07,Export/Portabilität (offenes Format),🗄️ Archivierung & Speicherung,Backend,Mittel,3,3,Backlog,"Go, mbox/eml-Export","Export archivierter Postfächer/Mails in ein offenes, portables Format (mbox/eml) für Migration und Datenmitnahme.",ARC-01,QA-05,"Export erzeugt vollständige, standardkonforme mbox- oder eml-Dateien
+Anhänge bleiben im Export erhalten und sind referenziell konsistent
+Export ist mandantenweise abgrenzbar und nachvollziehbar protokolliert","Test: exportierte Datei lässt sich mit gängigem Mail-Client importieren
+Test: Export enthält keine Daten anderer Mandanten
+Stichprobenvergleich Original vs. Export bestätigt Inhaltstreue"
+ARC-08,Verschlüsselungsschlüssel-Rotation,🗄️ Archivierung & Speicherung,Backend,Mittel,3,4,Fertig,"Go, Envelope-Encryption","Rotation der Verschlüsselungsschlüssel für archivierte Daten einführen, ohne bestehende Archivinhalte neu verschlüsseln zu müssen (Envelope-Encryption).",ARC-02,QA-03,"Neue Datenschlüssel werden über einen Hauptschlüssel gewrappt und rotierbar verwaltet
+Rotation des Hauptschlüssels erfordert kein Neuverschlüsseln des gesamten Archivbestands
+Alte Schlüsselversionen bleiben für Lesezugriff auf Altbestand kontrolliert verfügbar","Test: Rotation des Hauptschlüssels lässt Altbestand weiterhin lesbar
+Test: kompromittierter alter Schlüssel kann gezielt gesperrt werden
+Dokumentierter Rotationsvorgang wurde einmal vollständig durchgespielt"
+IMP-01,IMAP-Postfach-Abruf & Scheduler,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,3,Fertig,"Go, Postgres-Jobqueue, IMAP4rev1","Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem Delta-Sync aufbauen: neue Nachrichten erkennen, Zustandsänderungen (gelesen/gelöscht) abgleichen.",ING-01 ING-05,IMP-02 IMP-03 IMP-04 IMP-05 IMP-07 IMP-08 IMP-09 INT-05 UX-01,"Scheduler erkennt neue Nachrichten seit letztem Abruf zuverlässig über UID-Vergleich
+Zustandsänderungen (gelesen/gelöscht) werden ohne Doppelimport übernommen
+Abrufintervall ist je Postfach konfigurierbar und übersteht Neustarts des Dienstes","Test: zwei aufeinanderfolgende Läufe importieren keine Nachricht doppelt
+Test: simulierter Dienst-Neustart mitten im Abgleich führt zu konsistentem Endzustand
+Test gegen Testpostfach mit realistischem Nachrichtenaufkommen"
+IMP-02,Anhangsverarbeitung bei Import,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, mime/multipart","Anhänge aus importierten Nachrichten extrahieren, validieren und für die Weiterverarbeitung (Speicherung, Virenscan) bereitstellen.",ING-04 IMP-01,IMP-06 IMP-09,"Anhänge werden mit Originaldateiname, Größe und geprüftem Content-Type extrahiert
+Größenlimit pro Anhang und pro Nachricht wird durchgesetzt
+Fehlerhafte Anhänge blockieren nicht den Import der restlichen Nachricht","Test mit Nachricht, die einen überdimensionierten Anhang enthält, wird korrekt begrenzt
+Test mit mehreren Anhängen unterschiedlichen Typs importiert alle korrekt
+Test: ein defekter Anhang lässt Text und übrige Anhänge unangetastet"
+IMP-03,E-Mail-Regeln (Zuordnung/Tags/Klassifizierung),🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, Postgres","Regelwerk für automatische Zuordnung, Verschlagwortung und Klassifizierung importierter E-Mails nach Absender, Betreff, Postfach und Anhangstyp aufbauen.",IMP-01,IMP-09 INT-06,"Regeln lassen sich nach Absender, Betreff-Muster und Postfach definieren
+Mehrere zutreffende Regeln werden nach dokumentierter Priorität angewendet
+Regeländerungen wirken nur auf künftige Importe, nicht rückwirkend ohne expliziten Reindex-Auftrag","Test mit widersprüchlichen Regeln bestätigt dokumentierte Priorisierung
+Test: neue Regel ändert keine bereits importierten Altbestände automatisch
+Regelset mit 20+ Regeln bleibt performant auswertbar"
+IMP-04,Fehlerbehandlung nicht-konformer Server,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,4,Fertig,"Go, IMAP4rev1","Defensive Fehlerbehandlung für nicht-RFC-konforme oder abweichende Mailserver beim Import einführen, mit dokumentierten Fallback-Pfaden statt Abbruch.",IMP-01,IMP-08 QA-02,"Bekannte Abweichungen (u. a. UIDVALIDITY=0) führen zu definiertem Fallback statt Sync-Abbruch
+Unerwartete Serverantworten werden geloggt und übersprungen statt den gesamten Lauf zu stoppen
+Fallback-Verhalten ist dokumentiert und für Support nachvollziehbar","Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback
+Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten
+Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs"
+IMP-05,Hot-Folder/Scanner-Anbindung,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, fsnotify","Anbindung eines Hot-Folder/Scanner-Eingangs für E-Mail-Anhänge/Dokumente außerhalb des IMAP-Postfachs, analog zum Ingestion-Pfad.",IMP-01,QA-02,"Dateien in konfiguriertem Hot-Folder werden erkannt und dem richtigen Mandanten/Postfach zugeordnet
+Bereits verarbeitete Dateien werden nicht doppelt importiert
+Fehlerhafte Dateien werden in einen Fehlerordner verschoben statt den Scan-Lauf zu blockieren","Test: gleiche Datei zweimal abgelegt wird nur einmal importiert
+Test: fehlerhafte Datei landet nachvollziehbar im Fehlerordner
+Dauertest über mehrere Scan-Zyklen ohne Ressourcenleck"
+IMP-06,Anhangs-Virenscan-Anbindung,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,5,Fertig,"Go, ClamAV-kompatible Anbindung","Anbindung eines Virenscanners für importierte Anhänge, mit Quarantäne-Verhalten bei Fund und klarer Statusanzeige.",IMP-02,QA-02,"Jeder importierte Anhang wird vor Archivierung durch den Virenscanner geprüft
+Positiver Fund führt zu Quarantäne des Anhangs statt automatischer Archivierung
+Scanner-Ausfall blockiert den Import nicht unbegrenzt, sondern führt zu definiertem Fehlerzustand","Test mit EICAR-Testdatei bestätigt Quarantäne-Verhalten
+Test: Scanner nicht erreichbar führt zu klar sichtbarem Fehlerzustand statt Hänger
+Durchsatztest bestätigt akzeptable Verzögerung durch Scan-Schritt"
+IMP-07,Mehrfach-Postfach-Verwaltung pro Tenant,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,4,Fertig,"Go, Postgres, tenant_id","Verwaltung mehrerer Postfächer je Mandant: Anlage, Zuordnung zu Benutzern/Abteilungen, getrennte Abruf-Konfiguration pro Postfach.",IMP-01,ARC-09 QA-02,"Ein Mandant kann mehrere Postfächer unabhängig voneinander konfigurieren
+Jedes Postfach hat eigene Abrufparameter (Intervall, Zugangsdaten, Ordnerauswahl)
+Postfach-Liste ist strikt nach tenant_id gefiltert","Test: zwei Mandanten mit je mehreren Postfächern sehen ausschließlich eigene Postfächer
+Test: Löschen eines Postfachs beeinträchtigt andere Postfächer desselben Mandanten nicht
+Konfigurationsänderung an einem Postfach wirkt nicht auf andere"
+IMP-08,Fehler-Benachrichtigung bei Postfach-Sync-Ausfall,🔄 Postfach-Import & Synchronisierung,Backend,Einfach,2,5,Fertig,Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher),"Benachrichtigung bei wiederholtem Postfach-Sync-Ausfall an zuständige Administratoren, mit Eskalationsschwelle statt Einzel-Alarm pro Fehlversuch. Versand ausschließlich über den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02), kein eigener E-Mail-Versand in Mail.",IMP-01 IMP-04,QA-02,"Wiederholte Sync-Fehlschläge über konfigurierbarer Schwelle lösen genau ein Ereignis an Core CFG-02 aus, nicht selbst versendet
+Benachrichtigung enthält Postfach, Fehlerursache und Zeitpunkt des letzten erfolgreichen Abrufs
+Erfolgreicher Sync nach Ausfall setzt den Alarmzustand zurück","Test: N aufeinanderfolgende Fehlschläge lösen genau eine Benachrichtigung aus, keine Spam-Flut
+Test: erfolgreicher Lauf nach Ausfall beendet den Alarmzustand nachvollziehbar
+Test mit mehreren betroffenen Postfächern gleichzeitig bleibt übersichtlich"
+IMP-09,Import-Testsuite,🔄 Postfach-Import & Synchronisierung,Backend,Mittel,3,5,Fertig,"Go testing, testify","Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk aufbauen, inklusive Tenant-Scoping und nicht-konformer Server.",IMP-01 IMP-02 IMP-03,QA-02,"Jeder Importpfad hat automatisierte Tests für Normal- und Fehlerfall
+Tenant-Scoping ist für Postfach-Abruf und Regelanwendung durch eigene Tests abgedeckt
+Testsuite läuft reproduzierbar in CI ohne echte externe Postfächer","Testabdeckungsbericht für Scheduler, Anhangsverarbeitung und Regeln liegt vor
+CI-Lauf grün auf frischem Checkout
+Stichprobenreview bestätigt sinnvolle Testfälle für nicht-konforme Server-Szenarien"
+ING-01,IMAP-Server-Grundgerüst,📥 Ingestion & Protokoll-Server,Backend,Komplex,4,1,Fertig,"Go/net, IMAP4rev1 (RFC 3501)","IMAP-Server-Grundgerüst aufbauen: TCP-Listener, Command-Parser, Session-Zustandsmaschine (Not Authenticated/Authenticated/Selected) und Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT).",,IMP-01 ING-02 ING-05 ING-06 ING-07 ING-08 ING-10 QA-07,"Server nimmt IMAP-Verbindungen an und durchläuft die drei Standard-Zustände korrekt
+Grundbefehle (CAPABILITY, LOGIN, SELECT, FETCH, LOGOUT) sind implementiert und beantwortet
+Ungültige Kommandosequenzen werden mit korrektem IMAP-Fehlercode abgelehnt, nicht mit Verbindungsabbruch","Manuelle Session mit Standard-IMAP-Client durchgespielt und protokolliert
+Automatisierter Test deckt alle drei Zustandsübergänge und deren verbotene Übergänge ab
+Lasttest mit 50 parallelen Sessions ohne Ressourcenleck"
+ING-02,POP3-Server,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go/net, POP3 (RFC 1939)","POP3-Server mit den Zuständen Authorization/Transaction/Update sowie den Kernbefehlen (USER, PASS, STAT, LIST, RETR, DELE, QUIT) aufbauen.",ING-01,ING-06 ING-07 ING-08 ING-10 QA-07,"Server durchläuft alle drei POP3-Zustände korrekt
+RETR liefert vollständige Nachrichten, DELE markiert erst im Update-Zustand endgültig
+Fehlerhafte Anmeldeversuche werden ohne Informationspreisgabe abgelehnt","Automatisierter Test für jede Zustandsübergangs-Regel
+Test mit Standard-POP3-Client (z. B. via Skript) gegen Test-Postfach
+Test: DELE ohne anschließendes QUIT löscht nichts endgültig"
+ING-03,SMTP-Server & Mailer,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,1,Fertig,"Go/net/smtp, net/mail, SMTP (RFC 5321)","SMTP-Server für eingehende Mails sowie Mailer-Komponente für ausgehende Benachrichtigungen/Berichte aufbauen (HELO/EHLO, MAIL FROM, RCPT TO, DATA).",,ING-06 ING-08 ING-09 ING-10 QA-04 QA-07 ING-11,"SMTP-Annahme validiert Envelope und Nachrichtengröße vor der Annahme
+Mailer erzeugt Header ausschließlich über strukturierte Writer-API, keine freie Stringkonkatenation
+Ungültige Empfängerdaten führen zu sauberer SMTP-Fehlermeldung statt Absturz","Test mit Steuerzeichen/CRLF in Betreff und Anzeigenamen schlägt fehl bzw. wird bereinigt, kein Header-Bruch möglich
+Automatisierter Test sendet Testmail über Mailpit/MailHog und prüft Header-Integrität
+Lasttest mit gleichzeitigen Verbindungen ohne Verbindungsleck"
+ING-04,MIME- & Anhang-Parsing,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,1,Fertig,"Go, encoding/mime, mime/multipart","MIME-Parser für ein- und ausgehende Nachrichten inklusive Multipart, Anhängen, Content-Transfer-Encoding und Zeichensatz-Reparatur aufbauen.",,ARC-01 IMP-02 ING-10 ARC-10,"Multipart-Nachrichten mit verschachtelten Teilen werden vollständig zerlegt
+Anhänge werden mit korrektem Dateinamen, Größe und Content-Type extrahiert
+Fehlerhafte/inkonsistente Zeichensatzangaben werden defensiv repariert statt die Verarbeitung abzubrechen","Test mit sehr großem simuliertem Anhang bestätigt harte Ablehnung statt Speicheranstieg
+Testkorpus mit realitätsnahen Multipart-/Encoding-Varianten läuft fehlerfrei durch
+Fuzz-/Grenzwerttest mit kaputten MIME-Strukturen bricht kontrolliert ab, kein Absturz"
+ING-05,Folder-State & UIDVALIDITY-Handling,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go, IMAP4rev1 (RFC 3501 §2.3.1.1)","Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling für IMAP-Ordner aufbauen, damit Clients und Importvorgänge konsistente Sichten erhalten.",ING-01,IMP-01 ING-10,"Jeder Ordner führt UIDVALIDITY und UIDNEXT korrekt gemäß RFC nach
+Ordnerwechsel (SELECT/EXAMINE) liefert konsistenten State auch bei parallelem Zugriff
+State-Änderungen (neue Mail, Löschung) werden atomar und nachvollziehbar persistiert","Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau
+Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz
+Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen"
+ING-06,TLS/STARTTLS-Absicherung,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,3,Fertig,"Go crypto/tls, STARTTLS","TLS/STARTTLS für IMAP-, POP3- und SMTP-Server einrichten: verpflichtende Verschlüsselung für Anmeldedaten, moderne Cipher-Suiten, Zertifikatsverwaltung.",ING-01 ING-02 ING-03,QA-04,"Anmeldedaten werden ausschließlich über TLS oder nach erfolgreichem STARTTLS akzeptiert
+Schwache Cipher-Suiten und veraltete TLS-Versionen sind serverseitig deaktiviert
+Zertifikatswechsel ist ohne Verbindungsabriss für bestehende Sessions möglich","Scan mit Standard-TLS-Prüfwerkzeug bestätigt keine schwachen Suiten
+Test: Login-Versuch ohne TLS/STARTTLS wird verweigert
+Test: Zertifikatsrotation im laufenden Betrieb ohne Dienstunterbrechung"
+ING-07,Protokoll-Fehlerbehandlung & Wiederverbindung,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,3,Fertig,"Go, net, context","Einheitliche Fehlerbehandlung und Wiederverbindungslogik für IMAP-/POP3-Sessions bei Netzwerkabbrüchen, Timeouts und unerwarteten Client-Abbrüchen.",ING-01 ING-02,QA-02,"Verbindungsabbrüche räumen serverseitige Session-Ressourcen zuverlässig auf
+Timeouts sind pro Protokollphase konfigurierbar und greifen nachweislich
+Wiederholte Fehlversuche eines Clients führen zu klar definiertem Backoff statt Dauerschleife","Chaos-Test: Verbindung wird während aktiver Übertragung hart gekappt, kein Ressourcenleck danach
+Test für Timeout-Auslösung in jeder Protokollphase
+Test für Backoff-Verhalten bei wiederholten Fehlversuchen"
+ING-08,Mailserver-Protokoll-Logging & Diagnose,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,3,Fertig,"Go, structured logging (slog)","Strukturiertes Protokoll-Logging für IMAP-/POP3-/SMTP-Sessions mit Diagnosewerkzeug für Support und Fehlersuche, ohne Zugangsdaten im Klartext.",ING-01 ING-02 ING-03,QA-02,"Jede Session erzeugt strukturierte Logs mit Korrelations-ID über die gesamte Verbindungsdauer
+Zugangsdaten und Nachrichteninhalte erscheinen nie im Klartext im Log
+Diagnosewerkzeug kann eine einzelne Session anhand der Korrelations-ID vollständig nachvollziehen","Test bestätigt Redaktion sensibler Felder in allen Log-Pfaden
+Stichprobe: eine komplette Session ist über die Korrelations-ID lückenlos rekonstruierbar
+Lasttest bestätigt, dass Logging die Durchsatzrate nicht relevant beeinträchtigt"
+ING-09,Rate-Limiting auf Protokollebene,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,2,Fertig,"Go, Postgres-Jobqueue, Token-Bucket","Rate-Limiting auf Protokollebene für SMTP-Annahme und Login-Versuche einführen, um Missbrauch und Ressourcenerschöpfung zu verhindern.",ING-03,QA-04,"Login-Versuche pro Quelle/Zeitfenster sind begrenzt und konfigurierbar
+SMTP-Annahmerate pro Absender/Quelle ist begrenzt und konfigurierbar
+Überschreitung führt zu definierter Ablehnung mit Wartezeit-Hinweis, nicht zu Verbindungsabbruch ohne Erklärung","Lasttest bestätigt greifendes Limit bei Überschreitung
+Test: legitime Nutzung unterhalb der Schwelle bleibt unbeeinträchtigt
+Test: Limit ist je Mandant getrennt konfigurierbar und wirksam"
+ING-10,Ingestion-Testsuite,📥 Ingestion & Protokoll-Server,Backend,Mittel,3,3,Fertig,"Go testing, testify, Mailpit/MailHog","Testsuite für alle Ingestion-Protokollserver (IMAP/POP3/SMTP/MIME/Folder-State) aufbauen, inklusive Zustandsmaschinen- und Tenant-Scoping-Tests.",ING-01 ING-02 ING-03 ING-04 ING-05,QA-02,"Jede Protokoll-Zustandsmaschine hat automatisierte Tests für erlaubte und verbotene Übergänge
+Tenant-Scoping ist für jeden Ingestion-Pfad durch einen eigenen Test abgedeckt
+Testsuite läuft reproduzierbar in der CI ohne externe Live-Postfächer","Testabdeckungsbericht für alle fünf Ingestion-Module liegt vor
+CI-Lauf grün auf frischem Checkout ohne manuelle Nacharbeit
+Stichprobenreview durch zweite Person bestätigt sinnvolle Testfälle, nicht nur Zeilenabdeckung"
+INT-01,REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung,🔌 Integration & API,Backend,Mittel,3,6,Fertig,"Go net/http, REST, OpenAPI 3",Mail-spezifische API-Endpunkte (Mail-Liste/Mail-Detail/Anhang-Download usw.) auf dem zentralen Core-REST-Grundgerüst definieren und im modul-eigenen OpenAPI-Beitrag dokumentieren – keine eigene Router-/Versionierungs-Infrastruktur.,ARC-01 SRC-03,INT-06 INT-07 QA-06 INT-12,"API bietet Endpunkte für Mail-Liste, Mail-Detail und Anhang-Download
+Alle Endpunkte sind strikt mandantengebunden
+IAM-nahe Funktionen (Login, Tenant-Verwaltung) sind bewusst nicht Teil dieser API
+Modul-eigener OpenAPI-Beitrag deckt alle v1-Endpunkte inklusive Fehlerantworten ab und ist gegen die tatsächliche API geprüft","Test: Zugriff ohne gültigen Tenant-Kontext wird abgelehnt
+Vertragstest gegen definierte Endpunkte läuft grün
+Codereview bestätigt Abgrenzung zu Core-Board-Zuständigkeiten
+Validierungslauf des OpenAPI-Dokuments gegen Standardwerkzeuge ist fehlerfrei"
+INT-05,"Benachrichtigungs-Service ""neue Mail""",🔌 Integration & API,Backend,Einfach,2,4,Fertig,Kopplung an Core CFG-02 (Benachrichtigungs-Dispatcher),"Client-seitige Kopplung, die Benutzer über neu importierte Mails informiert, indem sie das Ereignis an den zentralen Core-Benachrichtigungs-Dispatcher (CFG-02) übergibt (In-App und optional per Mail über den Dispatcher) – kein eigener Benachrichtigungs-Service in Mail, neu konzipiert ohne archivmail-Vorbild.",IMP-01,QA-06,"Neue Mail im überwachten Postfach löst zeitnah ein Ereignis an Core CFG-02 aus, das den Versand übernimmt
+Benutzer kann Benachrichtigungsart und -häufigkeit konfigurieren
+Massenimport (viele Mails gleichzeitig) erzeugt gebündelte statt Dutzende Einzelbenachrichtigungen","Test: Import einer Mail löst genau eine Benachrichtigung aus
+Test: Massenimport erzeugt eine gebündelte Zusammenfassung statt Flut
+Test: deaktivierte Benachrichtigung erzeugt keine Zustellung"
+INT-06,E-Mail-Regel-Engine über API steuerbar,🔌 Integration & API,Backend,Mittel,3,7,Fertig,"Go net/http, REST","E-Mail-Regel-Engine (aus IMP-03) über die REST-API steuerbar machen: Regeln anlegen, ändern, Reihenfolge/Priorität setzen.",IMP-03 INT-01,QA-06,"Regeln lassen sich vollständig über die API anlegen, ändern und löschen
+Prioritätsreihenfolge ist über die API einsehbar und änderbar
+API-Änderungen wirken identisch zur bisherigen internen Regel-Anwendung","Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab
+Test: über API gesetzte Regel wird beim nächsten Import korrekt angewendet
+Test: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten"
+INT-07,Health-Check-Endpunkt für Mail-Modul,🔌 Integration & API,Backend,Einfach,2,7,Fertig,Go net/http,"Health-Check-Endpunkt für das Mail-Modul bereitstellen: Erreichbarkeit von Datenbank, Objektspeicher, Suchindex und Jobqueue.",INT-01,QA-06,"Health-Endpunkt meldet Status von Datenbank, Objektspeicher, Suchindex und Jobqueue getrennt
+Endpunkt ist ohne Authentifizierung für interne Überwachung erreichbar, aber ohne sensible Details
+Ausfall einer Teilkomponente wird klar als „degraded“ statt generischem Fehler gemeldet","Test: simulierter Ausfall einer Abhängigkeit wird korrekt im Health-Status abgebildet
+Test: Health-Antwort enthält keine sensiblen Konfigurationsdetails
+Integrationstest gegen echten Health-Endpunkt nach Deploy"
+QA-01,Teststrategie Mail,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Fertig,"Testkonzept, Go testing, Playwright/Jest","Teststrategie für das Mail-Modul festlegen: Testarten, Abdeckungsziele, Umgang mit Protokoll-/Compliance-kritischer Logik, zentrales Bug-Tracking.",,,"Teststrategie benennt Testarten (Unit/Integration/E2E) und Mindestabdeckung je Modultyp
+Protokoll- und Compliance-kritische Module haben verbindlich höhere Testpflicht als Standard-Module
+Vorgehen für Bug-Tracking ist festgelegt und durchsuchbar (kein reines Code-Kommentar-Tracking)
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Dokument liegt vor und wurde von zweiter Person gegengelesen
+Stichprobe: mindestens ein Beispieltest je benannter Testart ist umgesetzt
+Bug-Tracking-Vorgehen wurde einmal exemplarisch für einen realen Befund durchgespielt"
+QA-02,Prüfgate Ingestion & Import,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,"Testkonzept, CI","Prüfgate für Ingestion & Import: verbindliche Kriterien, bevor Protokoll-Server und Import als abgeschlossen gelten.",ING-10 IMP-09 IMP-04 IMP-05 IMP-06 IMP-07 IMP-08 ING-07 ING-08,QA-09,"Gate prüft Testabdeckung und Bestehen aller Ingestion-/Import-Testsuiten
+Gate prüft, dass bekannte Fehlerpunkte (Header-Injection, Anhang-Limit, UIDVALIDITY) durch Tests abgedeckt sind
+Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand von ING-10/IMP-09 dokumentiert
+Stichprobe: mindestens ein Regressionstest je bekanntem Fehlerpunkt vorhanden
+Zweite Person bestätigt Gate-Ergebnis unabhängig"
+QA-03,Prüfgate Archivierung & Suche,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,"Testkonzept, CI","Prüfgate für Archivierung & Suche: verbindliche Kriterien für Verschlüsselung, Speicherpfad-Konventionen und Suchqualität.",ARC-08 SRC-10 SRC-02 SRC-04 SRC-05 SRC-08 SRC-09,QA-09,"Gate prüft Bestehen der Archivierungs- und Suchindex-Testsuiten inklusive Schlüsselrotation
+Gate prüft Abwesenheit dynamischer SQL-Klauselbildung im Suchpfad
+Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand von ARC-08/SRC-10 dokumentiert
+Codereview-Stichprobe bestätigt statischen Query-Builder
+Zweite Person bestätigt Gate-Ergebnis unabhängig"
+QA-04,Sicherheits- & Berechtigungsprüfung,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,4,Fertig,"Sicherheitsprüfung, Threat Modeling","Sicherheits- und Berechtigungsprüfung für SMTP-Härtung, Mandantentrennung im Speicherpfad und API-Token/Rate-Limiting.",ING-03 ARC-06 ING-09 ING-06 SRC-11,QA-09,"Prüfung bestätigt wirksame Härtung des SMTP-Pfads gegen bekannte Angriffsmuster
+Prüfung bestätigt lückenlose Mandantentrennung im Speicherpfad
+Prüfung bestätigt korrekt greifendes API-Token-/Rate-Limiting","Gezielter Testangriff auf Header-Injection schlägt fehl
+Stichprobenprüfung mehrerer Speicherpfade auf Mandantentrennung
+Test: API-Zugriff mit widerrufenem/fremdem Token wird verweigert"
+QA-05,Prüfgate Compliance & eDiscovery,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Backlog,Compliance-Prüfung,"Prüfgate für Compliance & eDiscovery: Nachweis, dass Retention, Löschworkflow, eDiscovery und Audit-Kopplung korrekt zusammenwirken.",ARC-05 ARC-07 INT-08 ARC-10 ARC-04 ARC-09,QA-09,"Gate prüft korrekte Kopplung mailrelevanter Ereignisse an das Core-Audit-Log
+Gate prüft, dass eDiscovery-Tenant-Scoping in der Query-Schicht verankert ist
+Gate-Ergebnis ist dokumentiert und nachvollziehbar mit Zeitstempel","Gate-Lauf gegen aktuellen Stand der Audit-Trail-Kopplung (CMP-04) dokumentiert
+Stichprobe: Audit-Eintrag für Testlöschung ist im Core-Audit-Log auffindbar
+Zweite Person bestätigt Gate-Ergebnis unabhängig"
+QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Backlog,"Vertragstests, OpenAPI","Schnittstellen-Vertragstests, die die tatsächliche Mail-API v1 gegen die OpenAPI-Beschreibung prüfen.",INT-01 INT-05 INT-06 INT-07 INT-09 INT-10,QA-09,"Vertragstest deckt alle in der OpenAPI-Beschreibung definierten Endpunkte ab
+Abweichungen zwischen Beschreibung und tatsächlichem Verhalten werden automatisch erkannt
+Vertragstest läuft als Teil der CI bei jeder Änderung","CI-Lauf des Vertragstests ist grün auf aktuellem Stand
+Test: absichtlich eingefügte Abweichung wird vom Vertragstest erkannt
+Stichprobenreview durch zweite Person"
+QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Fertig,Lasttest-Werkzeug (z. B. k6/vegeta),"Last- und Leistungstest für IMAP-, POP3- und SMTP-Server unter realistischer paralleler Last.",ING-01 ING-02 ING-03,QA-09,"Lasttest simuliert realistische Anzahl paralleler Sessions je Protokoll
+Ergebnis zeigt Durchsatz- und Latenzwerte je Protokoll unter Last
+Zielwerte für Antwortzeit/Durchsatz sind definiert und werden erreicht","Lasttest-Lauf mit Ergebnisprotokoll liegt vor
+Vergleich Ist- vs. Zielwert dokumentiert
+Ressourcenverbrauch (CPU/RAM) während des Lasttests bleibt im erwarteten Rahmen"
+QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Backlog,Accessibility-Audit-Werkzeug,Barrierefreiheits-Audit der Postfach-Oberfläche als unabhängige Prüfung nach WCAG 2.1 AA.,UX-07 UX-08 UX-09,QA-09,"Automatisierter Audit-Lauf zeigt keine kritischen Verstöße mehr
+Manuelle Stichprobe bestätigt sinnvolle Tastatur- und Screenreader-Bedienung
+Ergebnis ist dokumentiert und mit Verantwortlichen für Nachbesserung rückgekoppelt","Audit-Bericht liegt vor mit Vorher/Nachher-Vergleich
+Stichprobentest mit Screenreader durch zweite Person
+Offene Punkte sind priorisiert und nachverfolgbar dokumentiert"
+QA-09,Abnahme- & Compliance-Prüfung Mail,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Backlog,Abnahmeprüfung,"Abschließende Abnahme- und Compliance-Prüfung für das Mail-Modul: alle vorgelagerten Gates bestanden, Gesamtsicht dokumentiert.",QA-02 QA-03 QA-04 QA-05 QA-06 QA-07 QA-08 SRC-06,,"Alle vorgelagerten Prüfgates (Ingestion/Import, Archivierung/Suche, Sicherheit, Compliance) sind bestanden
+Abnahmebericht fasst Ergebnisse aller Gates nachvollziehbar zusammen
+Offene Punkte aus einzelnen Gates sind vollständig aufgelistet oder als geschlossen bestätigt","Abnahmebericht liegt vor und wurde gegengelesen
+Stichprobe: mindestens ein Ergebnis je vorgelagertem Gate ist im Bericht nachprüfbar verlinkt
+Freigabeentscheidung ist dokumentiert mit Datum und verantwortlicher Person"
+SRC-01,Manticore-Suchindex für Mails,🔍 Suche & OCR,Backend,Mittel,3,4,Fertig,"Go, Manticore Search SQL/HTTP-API","Manticore-RT-Index für E-Mail-Inhalte (Betreff, Text, Anhangstext, Metadaten) aufbauen, mit striktem, statisch definiertem Schema.",ARC-01 ARC-03,SRC-02 SRC-03 SRC-09,"Index-Schema für Mail-Felder ist definiert und über Migration versioniert
+Schreibzugriffe auf den Index verwenden ausschließlich statische, vordefinierte Feldnamen
+Index ist mandantengetrennt abfragbar","Codereview bestätigt: keine Sprintf/Join-basierte SQL-Klauselbildung im Index-Zugriff
+Test: Abfrage mit manipulierten Eingabewerten verändert keine Spalten-/Tabellennamen
+Funktionstest: Volltextsuche liefert erwartete Treffer für Testkorpus"
+SRC-02,Indexierungs-Worker & Synchronisierung,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, Postgres-Jobqueue","Indexierungs-Worker aufbauen, der neu archivierte Mails asynchron in den Manticore-Index einpflegt und Änderungen (Löschung, Tag-Update) nachzieht.",SRC-01 ARC-03,QA-03 SRC-12,"Neue Archivobjekte erscheinen innerhalb definierter Zeit im Suchindex
+Löschungen und Metadatenänderungen werden im Index nachgezogen
+Worker-Ausfall verliert keine Indexierungsaufträge (Wiederaufnahme aus Postgres-Jobqueue)","Test: Worker-Neustart mitten im Lauf verliert keinen offenen Auftrag
+Test: Löschung einer Mail entfernt sie zuverlässig aus Suchtreffern
+Konsistenztest vergleicht Datenbankbestand mit Indexbestand stichprobenartig"
+SRC-03,Such-API mit Ranking,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, Manticore Search","Such-API mit Ranking (Relevanz, Datum, Anhangstreffer) bereitstellen, mandantengetrennt und mit Grundoperatoren (Phrase, Ausschluss).",SRC-01,INT-01 SRC-04 SRC-05 SRC-08,"Suche liefert nach Relevanz sortierte Treffer mit nachvollziehbarem Ranking
+Ergebnisse sind strikt auf den anfragenden Mandanten beschränkt
+Grundoperatoren (Phrasensuche, Ausschluss) funktionieren korrekt","Test: Suche eines Mandanten liefert keine Treffer eines anderen Mandanten
+Test: Phrasensuche und Ausschlussoperator liefern erwartete Teilmengen
+Performance-Test mit großem Testkorpus bleibt innerhalb Zielzeit"
+SRC-04,Such-Oberfläche mit Hervorhebung,🔍 Suche & OCR,Frontend,Mittel,3,6,Fertig,Next.js/React/TS,Such-Oberfläche mit Live-Trefferliste und Hervorhebung der Suchbegriffe im Kontext (Snippet) aufbauen.,SRC-03 SHL-01,QA-03,"Eingabe liefert Trefferliste mit hervorgehobenen Suchbegriffen im Snippet
+Klick auf Treffer öffnet die zugehörige Mail direkt an der Fundstelle
+Leere Ergebnisse zeigen verständlichen Hinweis statt leerer Fläche","Manueller Test mit typischen Suchanfragen bestätigt korrekte Hervorhebung
+Barrierefreiheits-Kontrastprüfung der Hervorhebung
+Test mit Sonderzeichen in der Suchanfrage bricht die Anzeige nicht"
+SRC-05,Facetten- & Filter-API,🔍 Suche & OCR,Backend,Einfach,2,6,Fertig,"Go, Manticore Facets","Facetten- und Filter-API für Suche bereitstellen (Absender, Zeitraum, Postfach, Anhangstyp, Tag).",SRC-03,SRC-06 QA-03,"API liefert Facettenwerte mit Trefferzahl je Filterdimension
+Mehrere Filter lassen sich kombinieren (UND-Verknüpfung)
+Facetten sind mandantengetrennt berechnet","Test: Facettenzahlen stimmen mit tatsächlicher Treffermenge überein
+Test: Kombination von drei Filtern liefert korrekt eingeschränkte Treffer
+Test: Facetten eines Mandanten enthalten keine Werte eines anderen"
+SRC-06,Facetten-UI & Filter-Chips,🔍 Suche & OCR,Frontend,Einfach,2,7,Fertig,Next.js/React/TS,"Facetten-Oberfläche mit Filter-Chips: aktive Filter sichtbar, einzeln entfernbar, Trefferzahl je Facettenwert angezeigt.",SRC-05 SHL-01,QA-09,"Aktive Filter erscheinen als entfernbare Chips oberhalb der Trefferliste
+Trefferzahl je Facettenwert wird live aktualisiert
+Zurücksetzen aller Filter ist mit einem Klick möglich","Manueller Test: Filterkombination und Einzelentfernung funktionieren wie erwartet
+Tastaturbedienbarkeit der Filter-Chips geprüft
+Test mit vielen aktiven Filtern bleibt die Ansicht übersichtlich"
+SRC-07,OCR für Anhänge,🔍 Suche & OCR,Backend,Mittel,3,4,Fertig,"Go, OCR-Engine-Anbindung (z. B. Tesseract)","OCR-Pipeline für Bild-/PDF-Anhänge einführen, damit deren Text durchsuchbar wird, als eigener Mail-OCR-Pfad unabhängig vom DMS-Board.",ARC-01 ARC-03,SRC-10 SRC-12,"Bild- und gescannte PDF-Anhänge werden automatisch per OCR verarbeitet
+Erkannter Text wird dem zugehörigen Mail-Suchdokument zugeordnet
+Bereits durchsuchbare PDFs (mit Textebene) werden nicht unnötig erneut per OCR verarbeitet","Test: Bildanhang mit bekanntem Text liefert erwartete Texterkennung
+Test: PDF mit vorhandener Textebene wird korrekt übersprungen
+Durchsatztest bestätigt akzeptable Verarbeitungszeit je Anhang"
+SRC-08,Gespeicherte Suchanfragen,🔍 Suche & OCR,Backend,Einfach,2,6,Fertig,"Go, Postgres","Gespeicherte Suchanfragen: Nutzer können Suchkriterien inklusive Filtern benennen, speichern und erneut ausführen.",SRC-03,QA-03,"Suchkriterien inklusive aktiver Filter lassen sich unter einem Namen speichern
+Gespeicherte Suche liefert bei erneuter Ausführung aktuelle Treffer, keinen eingefrorenen Snapshot
+Gespeicherte Suchen sind je Benutzer/Mandant getrennt sichtbar","Test: gespeicherte Suche mit mehreren Filtern wird korrekt reproduziert
+Test: Benutzer sieht keine gespeicherten Suchen anderer Mandanten
+Test: Löschen einer gespeicherten Suche entfernt nur diese"
+SRC-09,Suchindex-Neuaufbau/Reindexierung,🔍 Suche & OCR,Backend,Einfach,2,5,Fertig,"Go, Manticore Search","Werkzeug zum vollständigen Neuaufbau/Reindexieren des Suchindex bereitstellen, für Schema-Änderungen und Konsistenzwiederherstellung.",SRC-01,QA-03,"Voller Reindex lässt sich ohne Datenverlust im laufenden Betrieb anstoßen
+Fortschritt und Abschluss des Reindex sind nachvollziehbar sichtbar
+Alter Index bleibt bis zum erfolgreichen Abschluss des neuen Index abfragbar (kein Suchausfall)","Test: Reindex während laufender Suchanfragen unterbricht die Suche nicht
+Test: abgebrochener Reindex hinterlässt keinen inkonsistenten Zustand
+Stichprobenvergleich Alt-/Neuindex bestätigt gleiche Trefferzahlen"
+SRC-10,Spracherkennung & OCR-Qualitätsbewertung,🔍 Suche & OCR,Backend,Mittel,3,5,Fertig,"Go, OCR-Engine-Anbindung","Spracherkennung für OCR-Texte und Qualitätsbewertung der Erkennung (Konfidenzwert) einführen, um schlechte OCR-Ergebnisse kenntlich zu machen.",SRC-07,QA-03,"Erkannte Sprache wird je OCR-Text gespeichert und für Suche/Anzeige genutzt
+Konfidenzwert der Erkennung wird gespeichert und ist auswertbar
+Anhänge mit niedriger OCR-Qualität sind gezielt auffindbar (z. B. für manuelle Nachbearbeitung)","Test mit mehrsprachigem Testkorpus bestätigt korrekte Spracherkennung
+Test: künstlich verschlechtertes Bild erzeugt niedrigeren Konfidenzwert
+Abfrage aller Anhänge unterhalb einer Konfidenzschwelle liefert erwartete Treffer"
+UX-01,Postfach- & Ordneransicht,📱 Postfach-Oberfläche,Frontend,Mittel,3,4,Backlog,Next.js/React/TS,"Postfach- und Ordneransicht für archivierte Mails: Ordnerbaum, Nachrichtenliste, Sortierung, Grundsuche.",IMP-01 SHL-01,UX-02 UX-04 UX-05 UX-06 UX-07 UX-08,"Ordnerbaum zeigt alle Postfächer/Ordner des angemeldeten Mandanten korrekt
+Nachrichtenliste unterstützt Sortierung nach Datum/Absender/Betreff
+Ansicht bleibt bei mehreren tausend Nachrichten performant bedienbar","Manueller Test mit Testpostfach bestätigt korrekte Ordner-/Listendarstellung
+Performance-Test mit großer Nachrichtenliste bleibt flüssig
+Test: Benutzer sieht ausschließlich Postfächer des eigenen Mandanten"
+UX-02,E-Mail-Detailansicht & Thread-Darstellung,📱 Postfach-Oberfläche,Frontend,Mittel,3,5,Backlog,Next.js/React/TS,"E-Mail-Detailansicht mit Thread-Darstellung (zusammengehörige Antworten gruppiert), Anzeige von Headern und Anhangsliste.",UX-01 SHL-01,UX-07 UX-08 UX-09,"Detailansicht zeigt Nachrichtentext, relevante Header und Anhangsliste vollständig
+Zusammengehörige Nachrichten werden als Thread gruppiert dargestellt
+Navigation zwischen Thread-Nachrichten funktioniert ohne Kontextverlust","Manueller Test mit mehrteiligem Thread bestätigt korrekte Gruppierung
+Test: Anhangsliste stimmt mit tatsächlich archivierten Anhängen überein
+Barrierefreiheits-Grundprüfung der Detailansicht"
+UX-03,Anhang-Vorschau,📱 Postfach-Oberfläche,Frontend,Mittel,3,3,Backlog,"Next.js/React/TS, Canvas-Rendering","Anhang-Vorschau für gängige Formate (PDF, Bilder) direkt in der Oberfläche, ohne unsicheres Rendering von Fremdinhalt.",ARC-01 SHL-01,UX-07,"Vorschau funktioniert für PDF- und Bildanhänge ohne externen Download
+Content-Type wird serverseitig über Magic-Bytes bestimmt, nicht über die Dateiendung
+PDF-Vorschau nutzt Canvas-Rendering, kein iframe/HTML-Rendering von Anhangsinhalt","Test: Anhang mit falscher Dateiendung, aber echtem PDF-Inhalt wird korrekt als PDF erkannt und angezeigt
+Sicherheitsreview bestätigt: keine iframe-Einbindung von Anhangsinhalt
+Test: manipulierter Dateiname mit abweichendem Inhalt löst keine Fehlanzeige/-ausführung aus"
+UX-04,Responsive Layout & mobile Navigation,📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Backlog,"Next.js/React/TS, CSS Grid/Flexbox","Responsives Layout für Postfach-, Detail- und Suchansicht inklusive mobiler Navigation (schmaler Viewport, Touch-Bedienung).",UX-01 SHL-01,UX-07,"Kernansichten sind auf schmalen Viewports vollständig nutzbar
+Navigation zwischen Ordnerliste, Nachrichtenliste und Detail ist auf Mobilgeräten ohne Verlust bedienbar
+Keine horizontal abgeschnittenen Inhalte auf gängigen Bildschirmbreiten","Manueller Test auf mindestens drei Viewport-Breiten
+Touch-Bedienungstest der Kernnavigation
+Automatisierter Layout-Regressionstest für Kernansichten"
+UX-05,Dunkles Erscheinungsbild & Theming,📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Backlog,"Next.js/React/TS, CSS Custom Properties","Dunkles Erscheinungsbild und Theming für die Postfach-Oberfläche, konsistent mit System-/Benutzereinstellung.",UX-01 SHL-01,UX-07,"Dunkles und helles Erscheinungsbild sind vollständig nutzbar, keine unlesbaren Kontraste
+Einstellung folgt Systempräferenz, ist aber manuell überschreibbar
+Theme-Wahl bleibt über Sitzungen hinweg erhalten","Kontrastprüfung für beide Modi nach WCAG-Mindestwerten
+Test: manuelle Theme-Wahl übersteht Neuladen der Seite
+Visuelle Stichprobe aller Kernansichten in beiden Modi"
+UX-06,Mehrsprachigkeit (Deutsch/Englisch),📱 Postfach-Oberfläche,Frontend,Einfach,2,5,Backlog,"Next.js/React/TS, i18n","Mehrsprachigkeit (Deutsch/Englisch) für die Postfach-Oberfläche einführen, inklusive Sprachumschaltung ohne Seiten-Neuladen.",UX-01 SHL-01,UX-07,"Alle Oberflächentexte der Kernansichten liegen in Deutsch und Englisch vor
+Sprachumschaltung wirkt sofort ohne vollständigen Seiten-Neuladen
+Datums-/Zahlenformate folgen der gewählten Sprache","Stichprobenprüfung auf fehlende Übersetzungen (keine Schlüssel sichtbar statt Text)
+Test: Sprachumschaltung funktioniert in allen Kernansichten
+Test: Datumsformat wechselt korrekt zwischen beiden Sprachen"
+UX-07,Barrierefreiheit nach WCAG 2.1 AA,📱 Postfach-Oberfläche,Frontend,Mittel,3,6,Backlog,"Next.js/React/TS, WCAG 2.1 AA","Barrierefreiheit nach WCAG 2.1 AA für alle Kernansichten der Postfach-Oberfläche sicherstellen (Kontrast, Tastatur, Screenreader).",UX-01 UX-02 UX-03 UX-04 UX-05 UX-06 SHL-01,QA-08,"Alle Kernansichten erreichen WCAG 2.1 AA in automatisierter Prüfung ohne kritische Verstöße
+Vollständige Bedienbarkeit ohne Maus ist für alle Kernfunktionen gegeben
+Screenreader-Ausgabe ist für zentrale Elemente sinnvoll und vollständig","Automatisierter Accessibility-Scan aller Kernansichten ohne kritische Befunde
+Manueller Tastatur-Durchlauf durch alle Kernfunktionen
+Stichprobentest mit Screenreader durch zweite Person"
+UX-08,Tastatur-Bedienung & Shortcuts,📱 Postfach-Oberfläche,Frontend,Einfach,2,6,Backlog,Next.js/React/TS,"Tastatur-Bedienung und Shortcuts für häufige Aktionen (Nachricht öffnen, archivieren, nächste/vorherige Nachricht, Suche fokussieren).",UX-01 UX-02 SHL-01,QA-08,"Kernaktionen sind über dokumentierte Tastenkombinationen erreichbar
+Shortcuts kollidieren nicht mit Standard-Browser-Kürzeln
+Aktueller Fokus ist jederzeit visuell erkennbar","Manueller Test aller dokumentierten Shortcuts in den Kernansichten
+Test: kein Shortcut überschreibt sicherheitsrelevante Browser-Funktion
+Fokus-Sichtbarkeitsprüfung in allen Kernansichten"
+UX-09,Akten-/Vorgangsanzeige im Mail-Kontext,📱 Postfach-Oberfläche,Frontend,Einfach,2,6,Backlog,"Next.js/React/TS, externe REST-API","In der E-Mail-Detailansicht anzeigen, ob die Nachricht zu einer Akte gehört, inkl. Vermerke und offener Wiedervorlage – ruft dafür ausschließlich die externe Workflow-Board-API auf (VOR-04), speichert selbst keine Akte-Daten in Mail.",UX-02 SHL-01,QA-08,"E-Mail-Detailansicht zeigt Akte-Zugehörigkeit, Vermerke und offene Wiedervorlagen an, falls vorhanden
+Kein eigenes Akte-Datenmodell in Mail, ausschließlich Anzeige über die externe API
+Fehlerfall (Workflow-Board nicht erreichbar) blockiert die Mailanzeige selbst nicht, zeigt nur den Akte-Bereich als „vorübergehend nicht verfügbar“","E-Mail mit verknüpfter Akte zeigt Akte-Informationen korrekt an
+E-Mail ohne Akte-Verknüpfung zeigt Bereich nicht/leer an, kein Fehler
+Simulierter Ausfall der Workflow-API blockiert die übrige Mailanzeige nicht"
+ARC-09,Postfach-Quota,🗄️ Archivierung & Speicherung,Backend,Einfach,2,5,Fertig,"Go, Postgres, tenant_id","Konfigurierbares Speicherlimit je einzelnem Postfach (nicht nur pro Tenant wie Core LIC-05) – ein Postfach, das sein Limit erreicht, lehnt neue eingehende Mails mit klarer Fehlermeldung ab statt sie stillschweigend zu verwerfen oder den gesamten Tenant zu blockieren.",ARC-01 IMP-07,QA-05,"Speicherlimit ist je Postfach konfigurierbar, unabhängig von der Tenant-weiten Quota aus Core LIC-05
+Postfach am Limit lehnt neue eingehende Mail mit klarer, protokollgerechter Fehlermeldung ab (SMTP-Rückweisung), verwirft nicht stillschweigend
+Ein Postfach am Limit beeinträchtigt keine anderen Postfächer desselben Tenants","Test: Postfach-Quota erreicht, neue eingehende Mail wird mit korrekter SMTP-Fehlermeldung abgelehnt
+Test: anderes Postfach desselben Tenants empfängt weiterhin normal, während eines am Limit ist
+Verbrauchsanzeige je Postfach im Test korrekt gegen tatsächliche Größe geprüft"
+ARC-10,Signatur- und Zeitstempelerhalt (BSI TR-03125),🗄️ Archivierung & Speicherung,Backend,Einfach,3,4,Fertig,"Go (crypto/x509, S/MIME-/PGP-Signaturprüfung), RFC-3161-Zeitstempel-Client oder lokaler Fallback","Für digital signierte Mails (S/MIME, PGP/MIME): Signatur bei Archivierung prüfen und Prüfergebnis inkl. vertrauenswürdigem Zeitstempel dauerhaft mitarchivieren, damit die Signaturgültigkeit auch nach Zertifikatsablauf nachweisbar bleibt (BSI TR-03125).",ING-04 ARC-01,QA-05,"Signierte Mails (S/MIME und PGP/MIME) werden bei Archivierung erkannt, unsignierte Mails durchlaufen KEINE zusätzliche Prüfung
+Signaturprüfergebnis (gültig/ungültig/Prüfung nicht möglich, Zertifikatsdaten, Prüfzeitpunkt) wird unveränderlich mitarchiviert
+Prüfnachweis ist über die Mail-Detailansicht abrufbar, ohne die Original-Mail zu verändern","Test mit echter S/MIME-signierter Testmail: Prüfergebnis 'gültig' korrekt erkannt und archiviert
+Test mit signierter Mail mit manipuliertem Inhalt: Prüfergebnis 'ungültig' korrekt erkannt
+Simulierter Zertifikatsablauf nach Archivierung: archivierter Prüfnachweis bleibt unverändert abrufbar"
+INT-08,Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage,🔌 Integration & API,Backend,Mittel,3,4,Backlog,"HTTP-Client gegen Archive-Modul-Adapter-Schnittstelle, Aufbewahrungsklassen-Mapping","Mail/Anhang-Objekttyp und dessen Aufbewahrungsklasse bei NEXARCH Archive registrieren und vor jeder Löschung eine Aufbewahrungssperre (Legal Hold) abfragen, statt eigene Retention-Logik in Mail zu bauen.",ARC-01,QA-05 INT-11,"Mail-/Anhang-Objekttyp inkl. Aufbewahrungsklasse wird beim Start automatisch bei Archive registriert
+Vor Löschung einer archivierten Mail wird eine Sperr-Abfrage an Archive gestellt
+Ist die Mail gesperrt (Legal Hold), wird die Löschung abgelehnt und die Ablehnung im Audit-Log vermerkt
+Ist Archive nicht erreichbar, wird die Löschung sicherheitshalber verweigert (fail closed), nicht stillschweigend durchgeführt","Registrierung gegen eine echte Archive-Testinstanz durchgeführt, Objekttyp erscheint dort
+Test: gesperrte Mail kann nicht gelöscht werden, Ablehnung ist im Audit-Log sichtbar
+Test: Archive-Endpunkt absichtlich nicht erreichbar – Löschung wird verweigert, kein Fallback auf ungeprüfte Löschung"
+INT-09,AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01),🔌 Integration & API,Backend,Mittel,2,4,Backlog,"HTTP-Client gegen AI-Modul-Adapter-Schnittstelle, Feld-Mapping","Mail-/Thread-Objekttyp und dessen KI-relevante Felder (Betreff, Text, Anhänge) bei NEXARCH AI registrieren, damit Klassifizierung, Zusammenfassung und semantische Suche für Mails optional nutzbar werden, ohne eigene KI-Logik in Mail zu bauen.",ARC-01,QA-06 INT-11,"Mail-/Thread-Objekttyp inkl. KI-relevanter Felder wird beim Start automatisch bei AI registriert
+Registrierung ist optional: ist AI-Modul nicht aktiviert (Core LIC-02), startet Mail unverändert ohne Fehler
+Registrierungsfehler blockieren niemals den regulären Mail-Betrieb (fail open bei Registrierung)","Registrierung gegen eine echte AI-Testinstanz durchgeführt, Objekttyp erscheint dort
+Test: AI-Modul deaktiviert – Mail startet und läuft unverändert, keine Fehlermeldung im Normalbetrieb
+Test: AI-Endpunkt nicht erreichbar bei Registrierung – Mail-Start wird dadurch nicht blockiert"
+INT-10,Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02),🔌 Integration & API,Backend,Mittel,3,4,Backlog,"HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher","Mail-/Thread-Objekttyp und Auslöser-Ereignisse (Mail eingegangen, Zustellung fehlgeschlagen, Frist erreicht) bei NEXARCH Workflow registrieren und beim Eintreten publizieren, damit Genehmigungsprozesse und Aufgaben ohne eigene Workflow-Logik in Mail ausgelöst werden können.",ARC-01,QA-06 INT-11,"Mail-/Thread-Objekttyp inkl. verfügbarer Auslöser-Ereignisse wird beim Start automatisch bei Workflow registriert
+Ereignis 'Mail eingegangen' wird bei Zustellung tatsächlich an Workflow publiziert
+Fehlschlagende Zustellung eines Ereignisses blockiert nicht die auslösende Mail-Aktion (asynchron, nicht im Request-Pfad)","Registrierung gegen eine echte Workflow-Testinstanz durchgeführt, Objekttyp und Ereignisse erscheinen dort
+Test: Mail eingegangen – Ereignis kommt nachweislich bei Workflow an
+Test: Workflow-Endpunkt zum Zustellzeitpunkt nicht erreichbar – Mailzustellung bleibt trotzdem erfolgreich, Ereignis wird nachgeliefert oder sichtbar verworfen (nicht stillschweigend verloren)"
+SRC-11,Feld-Whitelist-Query-Builder für Suchindex-Zugriff,🔍 Suche & OCR,Backend,Einfach,1,4,Fertig,"Statisches Enum/Switch für Feldnamen, getesteter Query-Builder","Zentraler, getesteter Query-Builder mit Feld-Whitelist für den dynamischen Zugriff auf den Mail-Suchindex – Spalten-/Tabellennamen ausschließlich aus statischen Konstanten, nie aus Nutzereingabe oder generischem String-Zusammenbau (`fmt.Sprintf`), auch nicht hinter einer einfachen Whitelist-Funktion.",SRC-01,QA-04,"Spalten-/Feldnamen für dynamische Query-Teile stammen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau
+Whitelist ist nicht die einzige Absicherung – der Query-Builder selbst lässt keine anderen Werte durch, auch nicht bei einem Fehler in der Whitelist-Prüfung
+Entscheidung dokumentiert: Mail-eigene Implementierung, keine geteilte Utility mit dem jeweils anderen Board – konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren","Versuch, ein nicht in der Whitelist enthaltenes Feld anzufragen, wird abgewiesen statt stillschweigend ignoriert
+Code-Review bestätigt: kein dynamischer Spalten-/Tabellenname wird per String-Zusammenbau erzeugt"
+ARC-11,RET-05-Client: Aufbewahrungsklasse registrieren & Vernichtungs-Rückruf,🗄️ Archivierung & Speicherung,Backend,Mittel,3,5,Backlog,"HTTP-Client gegen Archive RET-05, Rückruf-Endpunkt, Postgres-Jobqueue für Requeue","Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit Aufbewahrungsklasse und Rückruf-Adresse, empfängt Vernichtungs-Rückrufe und behandelt Registrierungsfehler tolerant statt sie zu verschlucken.",ARC-01 RET-09,,"Mail registriert seine Objekttypen (Mail, Anhang) getrennt bei Archive RET-05 mit korrekter Aufbewahrungsklasse und eigener Rückruf-Adresse
+Mail empfängt den Vernichtungs-Rückruf, führt die Löschung durch und antwortet mit 2xx bei Erfolg
+Eine fehlgeschlagene Registrierung (Archive nicht erreichbar/Nicht-2xx) führt zu einem Requeue, nicht zu einem Absturz oder stillem Verwerfen","Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert, für Mail UND Anhang getrennt
+Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, Mail-Löschung nachweislich erfolgt, 2xx-Antwort gesendet
+Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag, kein Absturz"
+ING-11,Header-Injection-Schutz für ausgehende Mailer-Komponente,📥 Ingestion & Protokoll-Server,Backend,Einfach,2,8,Backlog,"Go net/mail, RFC 5322, CRLF-Validierung","ING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.",ING-03,,"Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code
+Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen
+Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben","Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert
+Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt
+Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern"
+INT-11,Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow),🔌 Integration & API,Backend,Mittel,2,8,Backlog,"Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go","INT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.",INT-08 INT-09 INT-10,,"Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
+Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert","Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
+Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
+Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation"
+INT-12,Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit,🔌 Integration & API,Backend,Einfach,1,8,Backlog,"Storage-Adapter, signierte URLs, Go","INT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.",INT-01 ARC-01,,"Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang
+Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
+Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff","Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler
+Test: abgelaufene URL wird abgelehnt
+Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt"
+SRC-12,Ressourcenlimits für OCR-/Indexierungs-Jobs,🔍 Suche & OCR,Backend,Mittel,2,8,Backlog,"Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)","SRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.",SRC-02 SRC-07,,"Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
+Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
+Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst","Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
+Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
+Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs"

mail-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>Mail Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Mail Kanban <span class="sub">– lokal, offline, ohne Server</span></h1>
+    <input id="q" placeholder="Suche: Code, Titel, Technik …" style="min-width:220px" />
+    <select id="fEpic"><option value="">Alle Epics</option></select>
+    <select id="fRole"><option value="">Alle Rollen</option></select>
+    <select id="fWave"><option value="">Alle Wellen</option></select>
+    <button id="onlyReady">Nur startbare</button>
+    <button id="exportBtn">Stand sichern</button>
+    <button id="resetBtn">Zurücksetzen</button>
+  </div>
+  <div class="stats" id="stats"></div>
+</header>
+<div class="board" id="board"></div>
+
+<dialog id="dlg">
+  <div class="dlg-head">
+    <div>
+      <div class="code" id="dCode" style="font-family:ui-monospace,Menlo,monospace;font-size:11px;color:var(--muted)"></div>
+      <div id="dTitle" style="font-size:18px;font-weight:600;margin-top:4px"></div>
+      <div id="dMeta" style="margin-top:8px"></div>
+    </div>
+    <div class="row">
+      <button class="primary" id="copyBtn">Prompt kopieren</button>
+      <button id="closeBtn">Schließen</button>
+    </div>
+  </div>
+  <div class="dlg-body">
+    <p id="dDesc" style="font-size:13px;color:#C7D3E5;line-height:1.6;margin-top:0"></p>
+    <h3>Baut auf</h3><div id="dDeps"></div>
+    <h3>Schaltet frei</h3><div id="dNext"></div>
+    <h3>Akzeptanzkriterien</h3><ul id="dAcc"></ul>
+    <h3>Prüfungen vor der Abnahme</h3><ul id="dChk"></ul>
+    <h3>Bau-Prompt</h3><pre id="dPrompt"></pre>
+  </div>
+</dialog>
+
+<script id="data" type="application/json">{"erzeugtAm": "2026-08-26", "totalDays": 171, "epics": [{"key": "ING", "name": "Ingestion & Protokoll-Server", "emoji": "📥", "color": "#0891B2", "description": "IMAP-, POP3- und SMTP-Server, MIME-Parsing, Protokoll-Absicherung und -Diagnose."}, {"key": "IMP", "name": "Postfach-Import & Synchronisierung", "emoji": "🔄", "color": "#2563EB", "description": "Abruf, Regeln, Fehlerbehandlung und Verwaltung mehrerer Postfächer je Mandant."}, {"key": "ARC", "name": "Archivierung & Speicherung", "emoji": "🗄️", "color": "#92400E", "description": "Objektspeicher, Verschlüsselung, Dublettenerkennung, Aufbewahrungsstruktur und Export."}, {"key": "SRC", "name": "Suche & OCR", "emoji": "🔍", "color": "#0E7490", "description": "Manticore-Suchindex, Indexierung, Facetten, gespeicherte Suchen und OCR für Anhänge."}, {"key": "INT", "name": "Integration & API", "emoji": "🔌", "color": "#14B8A6", "description": "REST-API, OpenAPI, Token/Rate-Limiting, Webhooks und Benachrichtigungen."}, {"key": "UX", "name": "Postfach-Oberfläche", "emoji": "📱", "color": "#F97316", "description": "Postfach- und Thread-Ansicht, Anhang-Vorschau, Responsivität, Theming, Sprache, Barrierefreiheit."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates für Ingestion, Archivierung, Compliance und Schnittstellen."}], "waves": [{"welle": 1, "codes": ["ING-01", "ING-03", "ING-04", "QA-01"]}, {"welle": 2, "codes": ["ARC-01", "ING-02", "ING-05", "ING-09"]}, {"welle": 3, "codes": ["ARC-02", "ARC-03", "ARC-04", "ARC-05", "ARC-06", "ARC-07", "IMP-01", "ING-06", "ING-07", "ING-08", "ING-10", "QA-07", "UX-03"]}, {"welle": 4, "codes": ["ARC-08", "IMP-02", "IMP-03", "IMP-04", "IMP-05", "IMP-07", "INT-05", "QA-04", "SRC-01", "SRC-07", "UX-01", "ARC-10", "INT-08", "INT-09", "INT-10"]}, {"welle": 5, "codes": ["ARC-09", "IMP-06", "IMP-08", "IMP-09", "SRC-02", "SRC-03", "SRC-09", "SRC-10", "UX-02", "UX-04", "UX-05", "UX-06", "QA-05"]}, {"welle": 6, "codes": ["INT-01", "QA-02", "QA-03", "SRC-04", "SRC-05", "SRC-08", "UX-07", "UX-08", "UX-09"]}, {"welle": 7, "codes": ["INT-06", "INT-07", "QA-06", "QA-08", "QA-09", "SRC-06"]}, {"welle": 8, "codes": ["ING-11", "INT-11", "INT-12", "SRC-12"]}], "kritischerPfad": {"path": ["ING-01", "ING-05", "IMP-01", "UX-01", "UX-02", "UX-07", "QA-08"], "days": 21}, "produktDna": {"uebernehmen": [{"produkt": "Dovecot", "staerke": "Referenzarchitektur für robuste IMAP-Server: klare Trennung von Protokoll-State-Machine, Storage-Backend und Auth-Schicht."}, {"produkt": "Dovecot", "staerke": "Defensive Behandlung nicht-konformer Clients/Server statt Best-Effort-Parsing, das bei Abweichungen stillschweigend falsch weiterläuft."}, {"produkt": "Rspamd", "staerke": "Mailserver-Härtung und Rate-Limiting als eigenständige, konfigurierbare Schicht vor der eigentlichen Verarbeitung."}, {"produkt": "Mailpit/MailHog", "staerke": "Mailflows sind von Anfang an automatisiert testbar, ohne echten Mailserver oder externe Postfächer."}, {"produkt": "ecoDMS", "staerke": "Revisionssichere Ablage: einmal archivierte Inhalte sind unveränderlich und lückenlos nachvollziehbar."}, {"produkt": "Alfresco", "staerke": "Aufbewahrungsfristen und Audit-Trail als Kernfunktion der Content-Verwaltung, nicht als Nachrüstung."}], "vermeiden": [{"schwaeche": "archivmail – Header-Injection durch ungeprüfte Stringkonkatenation im Mailer.", "loesung": "Ausgabe strikt über net/mail-Writer oder harte CRLF-/Steuerzeichen-Validierung."}, {"schwaeche": "archivmail – ungebremstes io.ReadAll beim Anhang-Parsing ohne Größenlimit.", "loesung": "io.LimitReader mit Max-Size und harter Ablehnung bei Überschreitung."}, {"schwaeche": "archivmail – nur 2 von 18 Modulen mit Tests trotz protokollkritischer Logik.", "loesung": "Pflichttests für Tenant-Scoping und Protokoll-State-Machines vor jedem Merge."}, {"schwaeche": "archivmail – dynamische SQL-Klauseln via Sprintf/Join im Suchindex.", "loesung": "Spalten- und Tabellennamen ausschließlich aus statischen Konstanten, kein String-Zusammenbau."}]}, "epicDna": {"ING": {"leitsatz": "Protokollserver sind die Eintrittstür des Systems – so robust wie Dovecot, so gehärtet wie Rspamd, nicht 1:1 aus archivmail übernommen.", "uebernehmen": ["Dovecot: Saubere Trennung von Protokoll-Zustandsmaschine und Speicher-Backend.", "Dovecot: Defensive Fehlerbehandlung bei nicht-konformen Gegenstellen statt optimistischem Parsing.", "Rspamd: Rate-Limiting und Absicherung als eigene, vorgeschaltete Schicht."], "vermeiden": ["archivmail – Header-Injection durch Stringkonkatenation ohne CRLF-Prüfung.: net/mail-Writer oder harte CRLF-Validierung von Anfang an.", "archivmail – kaum getestete Protokoll-Server (nur 2 von 18 Modulen).: Pflichttests für jede Zustandsmaschine vor Merge."]}, "IMP": {"leitsatz": "Import ist ein Dauerbetrieb-Prozess gegen unzuverlässige Fremdserver Line truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

mail-kanban/tickets/ING-11.md

@@ -0,0 +1,58 @@
+# ING-11 – Header-Injection-Schutz für ausgehende Mailer-Komponente
+
+**Epic:** 📥 Ingestion & Protokoll-Server  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ING-03 baut die Mailer-Komponente für ausgehende Benachrichtigungen/Berichte. Das archivmail-Vorbild hatte hier einen konkreten Header-Injection-Bug (`internal/mailer/mailer.go:144-146` – From/To/Subject per Stringkonkatenation ohne CRLF-Validierung, siehe known-issues-archivmail.md Punkt 1). Alle Mail-Header ausschließlich über `net/mail`/einen strukturierten Header-Writer erzeugen, nie per Stringkonkatenation; jeder Header-Wert wird vor Verwendung hart auf CRLF und andere Steuerzeichen geprüft und bei Fund abgelehnt statt escaped.
+
+**Technische Grundlage:** Go net/mail, RFC 5322, CRLF-Validierung
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Rspamd/Dovecot: strikte RFC-5322-Konformität bei der Header-Erzeugung statt freihändigem String-Bau.
+
+**Bewusst vermeiden:**
+- archivmail – Header per Stringkonkatenation ohne CRLF-Prüfung, konkreter Injection-Bug im Altsystem.: Header-Erzeugung ausschließlich über strukturierten Writer, CRLF-Eingaben werden hart abgelehnt.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ING-03.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle ausgehenden Mail-Header (From, To, Subject, Cc, Bcc, custom Header) werden über einen strukturierten Header-Writer erzeugt, keine Stringkonkatenation im Code
+2. Ein Eingabewert mit eingebettetem CRLF/Steuerzeichen in einem beliebigen Header-Feld führt zur Ablehnung der Mail, nicht zum stillen Escapen oder Durchreichen
+3. Bestehende Benachrichtigungs-/Berichts-Versandfunktionen aus ING-03 funktionieren unverändert für reguläre Eingaben
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Regressionstest gegen den ursprünglichen archivmail-Bug: identischer Eingabewert mit CRLF wird jetzt abgelehnt statt injiziert
+2. Test mit regulären Header-Werten (Umlaute, lange Betreffzeilen, mehrere Empfänger): Mail wird korrekt und RFC-konform erzeugt
+3. Fuzz-/Grenzwerttest mit verschiedenen Steuerzeichen-Kombinationen in Header-Feldern
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), direkter Bezug zu known-issues-archivmail.md Punkt 1: Header-Injection in der Mailer-Komponente ist ein bereits im Altsystem aufgetretener, konkreter Bug und muss beim Übernehmen des Codes zwingend behoben sein, nicht nur vermerkt.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ING-03` SMTP-Server & Mailer
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ING-11: header-injection-schutz-f-r-ausgehende-mailer-komponente`
+- Branch: `feature/ing-11-header-injection-schutz-f-r-ausgehende-mailer-komponente`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

mail-kanban/tickets/INT-11.md

@@ -0,0 +1,60 @@
+# INT-11 – Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow)
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-08/09/10 registrieren Mail-/Thread-Objekttypen und Ereignisse bei Archive, AI und Workflow über Service-Credentials. Rückkanal-Aufrufe dürfen dabei niemals nur im Kontext des Service-Accounts laufen, sondern müssen den ursprünglichen Nutzer-Tenant-Kontext durchreichen – sonst könnte ein Nutzer über den Umweg eines anderen Moduls Daten eines fremden Mandanten sehen, obwohl Mail selbst korrekt mandantengetrennt ist. Tenant-ID des anfragenden Nutzers explizit als Pflichtparameter in jedem Rückkanal-Aufruf verankern und serverseitig gegen den Service-Credential-Scope validieren.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Kontext-Weiterreichung, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Service-Accounts agieren im Namen eines Kontexts, nie mit implizit eigenen, umfassenderen Rechten.
+
+**Bewusst vermeiden:**
+- Keycloak – Service-Client-Aufrufe teilen sich in manchen Integrationen denselben weiten Scope wie der Admin-Client.: Service-Credential trägt nur die Rechte, um im Namen eines übergebenen Tenant-Kontexts zu handeln, nie tenant-übergreifend von sich aus.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-08, INT-09, INT-10.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Rückkanal-Aufruf an Archive/AI/Workflow trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+2. Das aufgerufene Modul validiert, dass der übergebene Tenant-Kontext zum Tenant des Zielobjekts passt, unabhängig vom Service-Credential-Scope
+3. Ein manipulierter/falscher Tenant-Kontext im Aufruf wird abgelehnt und protokolliert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Rückkanal-Aufruf mit korrektem Nutzer-Tenant-Kontext liefert erwartete Daten
+2. Test: Rückkanal-Aufruf mit manipuliertem Tenant-Kontext (fremder Tenant) wird abgelehnt
+3. Integrationstest über INT-08 (Archive Legal Hold) mit zwei verschiedenen Tenants, prüft Isolation
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `INT-16`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal über Service-Credentials ohne durchgereichten Nutzer-Tenant-Kontext kann diese Isolation modulübergreifend aufweichen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-08` Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage
+- `INT-09` AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01)
+- `INT-10` Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-11: nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Branch: `feature/int-11-nutzer-tenant-kontext-in-modul-r-ckkan-len-archive-ai-workflow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

mail-kanban/tickets/INT-12.md

@@ -0,0 +1,59 @@
+# INT-12 – Signierte URLs für Anhang-Download: Scope-Bindung & kurze Ablaufzeit
+
+**Epic:** 🔌 Integration & API  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+INT-01 definiert den Anhang-Download-Endpunkt auf dem Objektspeicher aus ARC-01, ohne festzulegen, wie der Zugriff auf das Objekt technisch abgesichert wird. Analog zu DMS `FDN-10`: jede für einen Anhang-Download ausgestellte signierte URL muss fest an genau ein Objekt gebunden sein und eine kurze, konfigurierbare Ablaufzeit haben (Minuten, nicht Stunden), nicht an ein Postfach- oder Mandanten-Präfix.
+
+**Technische Grundlage:** Storage-Adapter, signierte URLs, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Dovecot/Alfresco: zeitlich begrenzte, objektgebundene Zugriffs-Tokens statt dauerhafter Links.
+
+**Bewusst vermeiden:**
+- Alfresco – in älteren Konfigurationen teils lang gültige Download-Links ohne erzwungene kurze TTL.: Ablaufzeit ist ein hartes, kurzes Limit, keine Empfehlung.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: INT-01, ARC-01.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Eine signierte URL für einen Anhang-Download gewährt ausschließlich Zugriff auf genau diesen Anhang
+2. Ablaufzeit ist konfigurierbar und im Standardfall im Minutenbereich, hart durchgesetzt vom Storage-Adapter
+3. Nach Ablauf liefert ein Zugriffsversuch über die URL einen Fehler, kein stiller Fallback auf öffentlichen Zugriff
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: signierte URL für Anhang A liefert bei Zugriffsversuch auf Anhang B einen Fehler
+2. Test: abgelaufene URL wird abgelehnt
+3. Test: URL für einen zwischenzeitlich gelöschten/in den Papierkorb verschobenen Anhang wird abgelehnt
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-10`: ohne explizite Scope-/TTL-Vorgabe könnten signierte URLs für Anhang-Downloads versehentlich zu breit oder zu lange gültig ausgestellt werden.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `INT-01` REST-API v1 für Mail-Zugriff & Schnittstellenbeschreibung
+- `ARC-01` Objekt-Speicher-Anbindung für Mails/Anhänge
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `INT-12: signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`
+- Branch: `feature/int-12-signierte-urls-f-r-anhang-download-scope-bindung-kurze-ablaufzeit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

mail-kanban/tickets/SRC-12.md

@@ -0,0 +1,59 @@
+# SRC-12 – Ressourcenlimits für OCR-/Indexierungs-Jobs
+
+**Epic:** 🔍 Suche & OCR  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Mail (Ingestion & Protokoll-Server, Postfach-Import, Archivierung, Suche & OCR, Integration/API), Ablösung von archivmail. Code-Wiederverwendung aus archivmail ist ausdrücklich erlaubt, MUSS aber die in known-issues-archivmail.md dokumentierten Fehler korrigieren, nicht 1:1 übernehmen.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+SRC-02 (Indexierungs-Worker) und SRC-07 (OCR-Pipeline für Anhänge) verarbeiten Inhalte asynchron, ohne Obergrenzen pro Einzeljob festzulegen. Ein sehr großer oder speziell präparierter Anhang (viele Seiten, komprimierte Bomben-artige Dateien) kann einen Worker dauerhaft blockieren und damit Indexierung/OCR für andere Mandanten verzögern. Harte Obergrenzen je Job definieren (max. Verarbeitungszeit, max. Speicherverbrauch, max. Seiten-/Dateigröße) – bei Überschreitung wird der Job kontrolliert abgebrochen und in eine Dead-Letter-Queue verschoben statt den Worker zu blockieren.
+
+**Technische Grundlage:** Postgres-Jobqueue, Worker-Goroutinen, Ressourcenlimits (Zeit/Speicher/Seitenzahl)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Rspamd: klare Verarbeitungszeitgrenzen pro Nachricht statt unbegrenzter Best-Effort-Verarbeitung.
+
+**Bewusst vermeiden:**
+- archivmail (bekannte Fehlerklasse) – Ressourcenerschöpfung durch unbegrenzte Einzeljobs war eine wiederkehrende Betriebsstörung in Altsystemen.: harte, konfigurierbare Obergrenzen je Job von Anfang an statt nachträglicher Begrenzung nach Vorfall.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: SRC-02, SRC-07.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder OCR-/Indexierungsjob hat konfigurierbare Obergrenzen für Zeit, Speicher und Eingabegröße/Seitenzahl
+2. Eine Überschreitung führt zum kontrollierten Abbruch des Jobs (Dead-Letter-Queue), nicht zur Blockade des Workers
+3. Andere, gleichzeitig laufende Jobs (auch anderer Mandanten/Postfächer) bleiben von einem überschreitenden Job unbeeinflusst
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test mit einem Anhang, der absichtlich die Seiten-/Größenobergrenze überschreitet: Job wird kontrolliert abgebrochen
+2. Lasttest: ein überschreitender Job blockiert nicht die Verarbeitung paralleler, regulärer Jobs
+3. Test der Dead-Letter-Queue-Sichtbarkeit für abgebrochene Jobs
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Mail-Board, 2026-09-12), analog zu DMS-Finding `FDN-11`: unbegrenzte Einzeljob-Verarbeitung ist ein Denial-of-Service-Vektor gegen den gemeinsamen Worker-Pool, auch ohne böswillige Absicht.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SRC-02` Indexierungs-Worker & Synchronisierung
+- `SRC-07` OCR für Anhänge
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SRC-12: ressourcenlimits-f-r-ocr-indexierungs-jobs`
+- Branch: `feature/src-12-ressourcenlimits-f-r-ocr-indexierungs-jobs`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

workflow-kanban/README.md

@@ -0,0 +1,98 @@
+# Workflow-Kanban – lokal abarbeiten
+
+35 Arbeitskacheln · 6 Epics · 91 Personentage · 8 Wellen (inkl. Welle 8: Threat-Model-Nachtrag 2026-09-12 — VOR-06, ENG-06, ENG-07).
+
+Hinweis: Dieses Board ist die alleinige Quelle für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing. DMS-Board referenziert dieses Board extern in der Ausgangslage betroffener Tickets. Benachrichtigungsversand selbst liegt im Core-Board (CFG-02..04), nicht hier.
+Modul-Adapter ist bidirektional: ENG-02 für Push (Registrierung durch DMS/Mail), VOR-04 für Pull (Rückkanal, damit DMS/Mail Workflow-Daten im eigenen Kontext anzeigen können).
+Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board.
+Stand: 2026-08-26
+
+## 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 (`ENG-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** (2 Kacheln): ENG-01, QA-01
+- **Welle 2** (5 Kacheln): ENG-02, ENG-03, ENG-04, ENG-05, TSK-01
+- **Welle 3** (5 Kacheln): APR-01, TSK-02, RTE-01, QA-02, VOR-01
+- **Welle 4** (9 Kacheln): APR-02, APR-03, APR-04, TSK-03, TSK-04, RTE-02, RTE-03, VOR-02, VOR-03
+- **Welle 5** (5 Kacheln): TSK-05, RTE-04, QA-03, VOR-04, VOR-05
+- **Welle 6** (2 Kacheln): QA-04, QA-06
+- **Welle 7** (1 Kachel): QA-05
+
+Kritischer Pfad (19 PT): ENG-01 → ENG-02 → RTE-01 → RTE-02 → RTE-04 → QA-04 → QA-05
+
+## Produkt-DNA
+
+### Übernehmen
+- **Alfresco**: Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik – Kernidee dieses Boards.
+- **Camunda/Zeebe**: Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse, leichtgewichtig gedacht statt BPMN-Vollausbau.
+- **Trello/Linear**: Einfache, schnelle Aufgaben-Oberfläche als Vorbild – kein Schwergewicht.
+- **Alfresco**: Akten-/Vorgangskonzept mit klarer Statuslogik als Vorbild für die digitale Akte (VOR-01..VOR-05).
+- **ecoDMS**: Klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet (VOR-03).
+
+### Vermeiden
+- **Alfresco – Ressourcen-Overhead und Konfigurationskomplexität der Plattform.**: Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur.
+- **Camunda/Zeebe – voller BPMN-Modellierungsapparat.**: Ein lesbares, versionierbares Prozessdefinitionsformat statt grafischem Modellierungswerkzeug.
+- **Kein zweites, konkurrierendes Aktenmodell parallel in DMS.**: Die Akte lebt ausschließlich in Workflow, DMS und Mail zeigen sie nur über die Rückkanal-API (VOR-04) an.
+
+## 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).

workflow-kanban/board.csv

@@ -0,0 +1,189 @@
+Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
+ENG-01,Workflow-Engine & Zustandsmodell,🔀 Workflow-Engine,Backend,Komplex,4,1,Backlog,"Zustandsautomat, PostgreSQL, pgx/v5","Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.",,ENG-02 ENG-03 ENG-04 ENG-05 APR-01 TSK-01,"Zustände und zulässige Übergänge sind je Prozesstyp definierbar
+Unzulässiger Übergang wird abgewiesen
+Laufende Instanz überlebt einen Neustart","Unzulässiger Übergang wird im Test abgewiesen
+Gleichzeitige Übergänge zweier Nutzer erzeugen keinen Fehlzustand
+Neustart des Dienstes mit laufender Instanz geprüft"
+ENG-02,Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger),🔀 Workflow-Engine,Backend,Mittel,3,2,Backlog,"REST-Schnittstelle, Adapter-Registrierung","Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.",ENG-01,APR-01 QA-02 QA-06 RTE-01 VOR-01 QA-07 ENG-06,"Modul kann Objekttyp und Trigger ohne Codeänderung an der Engine registrieren
+Registrierung ist versionierbar und rückrollbar
+Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz","Testadapter aus fiktivem DMS- und Mail-Modul beide korrekt registriert
+Doppelte Registrierung wird abgewiesen
+Deregistrierung entfernt zugehörige Trigger vollständig"
+ENG-03,"Prozessdefinitions-Format (deklarativ, versionierbar)",🔀 Workflow-Engine,Backend,Mittel,3,2,Backlog,"YAML/JSON-Prozessdefinition, Schema-Validierung","Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.",ENG-01,QA-02,"Prozessdefinition ist ohne Codeänderung änderbar
+Ungültige Definition wird beim Laden abgewiesen
+Ältere Version bleibt für laufende Instanzen gültig","Schema-Validierung gegen fehlerhafte Definition getestet
+Versionswechsel während laufender Instanz verändert deren Verhalten nicht rückwirkend
+Rollback auf Vorgängerversion funktioniert"
+ENG-04,Workflow-Instanz-Historie & Nachvollziehbarkeit,🔀 Workflow-Engine,Backend,Mittel,3,2,Backlog,"Append-only Protokolltabelle, PostgreSQL","Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.",ENG-01,QA-02 ENG-07,"Jeder Übergang wird protokolliert
+Protokoll ist nicht nachträglich veränderbar
+Historie ist je Instanz vollständig abrufbar","Manipulationsversuch am Protokoll schlägt fehl
+Historie einer Beispielinstanz enthält alle Schritte in korrekter Reihenfolge
+Abfrage großer Historien bleibt performant"
+ENG-05,Fehlerbehandlung & Retry bei Workflow-Schritten,🔀 Workflow-Engine,Backend,Mittel,3,2,Backlog,"Postgres-Jobqueue, Backoff-Strategie","Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.",ENG-01,QA-02,"Fehlgeschlagener Schritt wird automatisch wiederholt
+Dauerhaft fehlschlagender Schritt landet in einem einsehbaren Fehlerzustand
+Retry ist idempotent","Simulierter Fehlerfall löst korrekte Wiederholung aus
+Dead-Letter-Instanz ist auffindbar und manuell neu anstoßbar
+Mehrfacher Retry erzeugt keine doppelte Wirkung"
+APR-01,Freigabe-Postfach & Genehmigungsansicht (Backend),✅ Genehmigungen & Freigaben,Backend,Mittel,3,3,Backlog,"PostgreSQL, REST-Schnittstelle","Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.",ENG-01 ENG-02,APR-02 APR-03 APR-04,"Offene Genehmigungsaufgaben sind je Nutzer abrufbar
+Entscheidung ist genau einmal möglich
+Entscheidung ist mit Begründung protokollierbar","Bereits entschiedene Aufgabe lässt sich nicht doppelt entscheiden
+Parallelentscheidung zweier Nutzer erzeugt keinen Fehlzustand
+Entscheidung erscheint korrekt in der Instanz-Historie (ENG-04)"
+APR-02,Vier-Augen-Freigabe (generisches Muster),✅ Genehmigungen & Freigaben,Backend,Mittel,3,4,Backlog,Regelbasierte Zweitprüfung,"Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.",APR-01,QA-03,"Zweitprüfer darf nicht mit dem Ersteller identisch sein
+Freigabe ist erst nach zwei unabhängigen Bestätigungen wirksam
+Konfiguration ist je Prozesstyp aktivierbar","Ersteller kann eigene Freigabe nicht zweitbestätigen
+Fehlende Zweitbestätigung blockiert die Wirkung nachweislich
+Aktivierung für neuen Prozesstyp ohne Codeänderung getestet"
+APR-03,Genehmigungs-Oberfläche,✅ Genehmigungen & Freigaben,Frontend,Mittel,3,4,Backlog,"React/Next.js, TypeScript","Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.",APR-01 SHL-01,,"Offene Freigaben sind gebündelt sichtbar
+Ablehnung erfordert eine Begründung
+Entscheidung ist per Tastatur möglich","Ansicht bei 200 offenen Aufgaben bleibt nutzbar
+Doppelte Entscheidung wird in der Oberfläche verhindert
+Tastaturbedienung für alle drei Aktionen geprüft"
+APR-04,Delegation & Vertretungsregeln bei Abwesenheit,✅ Genehmigungen & Freigaben,Backend,Einfach,2,4,Backlog,"Vertretungsmodell, Zeitraumlogik","Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.",APR-01,,"Vertretung ist zeitlich begrenzt konfigurierbar
+Aufgabe geht während der Abwesenheit automatisch an die Vertretung
+Rückkehr beendet die Vertretung automatisch
+Selbst-Vertretung (Genehmiger setzt sich selbst als Vertretung ein, um APR-02 Vier-Augen-Prinzip zu umgehen) wird verhindert","Aufgabe während aktiver Vertretung landet nachweislich bei der Vertretung
+Überlappende Vertretungsregeln werden eindeutig aufgelöst
+Ende der Vertretung wirkt ohne manuellen Eingriff
+Missbrauchstest: Genehmiger versucht, sich selbst als Vertretung einzutragen und eigene Anfrage über die Vertretung freizugeben – wird abgelehnt"
+TSK-01,Aufgabenmodell & Zuweisung,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,2,Backlog,"PostgreSQL, Aufgabenmodell","Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.",ENG-01,TSK-02 TSK-04 VOR-03,"Aufgabe ist Person oder Gruppe zuweisbar
+Zuweisung an Gruppe erzeugt genau eine Aufgabe
+Aufgabe ist mit beliebigem Modul-Objekt verknüpfbar","Zuweisung an Gruppe erzeugt im Test genau eine Aufgabe
+Verknüpfung mit Testobjekt aus fiktivem Modul funktioniert
+Tenant-Isolation der Aufgabentabellen durch Negativtest belegt"
+TSK-02,Fristen & Kalenderlogik,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,3,Backlog,"Kalenderlogik, Zeitzonenbehandlung","Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.",TSK-01,TSK-03 TSK-04,"Fälligkeit berücksichtigt Arbeitstage
+Wochenenden und Feiertage verschieben die Fälligkeit korrekt
+Zeitzonenwechsel verschiebt Fälligkeit nicht fälschlich","Fristberechnung über Wochenende und Feiertage geprüft
+Zeitzonenwechsel-Testfall bestanden
+Grenzfall Fälligkeit an einem Feiertag korrekt behandelt"
+TSK-03,Erinnerungen & Eskalationsregeln,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,4,Backlog,"Postgres-Jobqueue, zeitgesteuerte Jobs","Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.",TSK-02,TSK-05 QA-03,"Erinnerungszeitpunkte sind konfigurierbar
+Eskalation erfolgt nach definierter Regel bei Fristablauf
+Erledigte Aufgabe löst keine Eskalation mehr aus","Zeitraffer-Test über simulierte Fristen bestanden
+Erledigte Aufgabe vor Fristablauf löst nachweislich keine Eskalation aus
+Wiederholter Joblauf bleibt idempotent"
+TSK-04,Aufgaben-Oberfläche,"⏱️ Aufgaben, Fristen & Eskalation",Frontend,Mittel,3,4,Backlog,"React/Next.js, TypeScript","Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.",TSK-01 TSK-02 SHL-01,,"Überfällige Aufgaben sind klar gekennzeichnet
+Liste ist nach Fälligkeit und Priorität filterbar
+Ansicht bleibt bei 200 Aufgaben nutzbar
+Kanban-Ansicht zeigt Spalten nach Aufgabenstatus, Drag & Drop zwischen Spalten schreibt den neuen Status über TSK-01 zurück
+Kanban-Ansicht zeigt ausschließlich Aufgaben des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet","Filterkombination gegen Testdatensatz geprüft
+Überfällig-Kennzeichnung bei Fristüberschreitung im Test korrekt
+Performance bei 200 Aufgaben gemessen
+Verschieben einer Aufgabe per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über TSK-01
+Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Aufgaben des aktuell aktiven Mandanten"
+TSK-05,Eskalations-Benachrichtigung (ruft Core-Dispatcher),"⏱️ Aufgaben, Fristen & Eskalation",Backend,Einfach,2,5,Backlog,REST-Aufruf an Core-Dispatcher,"Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.",TSK-03,QA-03,"Eskalation ruft den Core-Dispatcher mit korrektem Ereignistyp auf
+Fehlschlag des Dispatcher-Aufrufs bricht die Eskalation nicht ab
+Keine Doppelbenachrichtigung bei mehrfachem Joblauf","Testaufruf gegen simulierten Core-Dispatcher erfolgreich
+Nichterreichbarkeit des Dispatchers führt zu protokolliertem Fehler statt Absturz
+Wiederholter Joblauf erzeugt keinen doppelten Aufruf"
+RTE-01,"Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)",🔁 Regelbasiertes Routing,Backend,Mittel,3,3,Backlog,"Regelwerk-Datenmodell, PostgreSQL","Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.",ENG-02,RTE-02 RTE-03,"Regeln sind priorisierbar
+Bedingungen sind modulunabhängig formulierbar
+Regel ist versionierbar und rückrollbar","Regelpriorität im Test korrekt angewendet
+Testregel aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet
+Rollback auf Vorgängerversion einer Regel funktioniert"
+RTE-02,Routing-Engine-Ausführung,🔁 Regelbasiertes Routing,Backend,Mittel,3,4,Backlog,Regel-Ausführungs-Engine,"Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.",RTE-01,RTE-04,"Nicht zuordenbare Objekte landen in einem Klärungskorb
+Jede Weiterleitung ist nachvollziehbar protokolliert
+Regeländerung wirkt ohne Neustart","Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft
+Kein Testobjekt geht bei fehlender Regel verloren
+Regeländerung zur Laufzeit ohne Neustart wirksam getestet"
+RTE-03,Routing-Regel-Editor (Oberfläche),🔁 Regelbasiertes Routing,Frontend,Mittel,3,4,Backlog,"React/Next.js, TypeScript","Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.",RTE-01 SHL-01,,"Regeln sind in der Oberfläche priorisierbar
+Regeländerung ist ohne Codeänderung möglich
+Regel kann vor Aktivierung getestet werden","Priorisierung per Drag & Drop im Test funktionsfähig
+Testlauf einer Regel vor Aktivierung möglich
+Ungültige Bedingungseingabe wird abgewiesen"
+RTE-04,Testlauf/Simulation von Routing-Regeln,🔁 Regelbasiertes Routing,Backend,Einfach,2,5,Backlog,"Simulationsmodus, Testkorpus","Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.",RTE-02,QA-04 RTE-05 QA-07,"Simulation verändert keine echten Daten
+Simulationsergebnis zeigt erwartete gegen tatsächliche Zuordnung
+Simulation ist gegen beliebigen Testkorpus ausführbar","Simulationslauf hinterlässt keine Spuren in Produktivdaten
+Abweichung zwischen erwarteter und tatsächlicher Zuordnung wird korrekt gemeldet
+Simulation mit leerem Testkorpus bricht nicht ab"
+QA-01,Teststrategie Workflow,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Backlog,"Teststrategie, Testdatenbestand","Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen Testdatenbestand für Engine, Genehmigungen, Aufgaben und Routing aufbauen.",,,"Teststrategie deckt Engine, Genehmigungen, Aufgaben und Routing ab
+Testdatenbestand ist realistisch und anonymisiert
+Verantwortlichkeit je Testebene ist dokumentiert
+Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Teststrategie-Dokument gegen alle vier Bereiche geprüft
+Testdatenbestand enthält keine echten Personendaten
+Zweite Person kann Teststrategie ohne Rückfragen anwenden"
+QA-02,Prüfgate Engine & Adapter,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,3,Backlog,"Integrationstests, Zeitraffer","Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.",ENG-05 ENG-02 ENG-03 ENG-04,QA-05,"Alle Zustandsübergänge sind mindestens einmal durchlaufen
+Adapter-Registrierung ist gegen zwei fiktive Module geprüft
+Fehlerbehandlung und Retry sind nachgewiesen","Unzulässiger Übergang wird in jedem Testlauf abgewiesen
+Zwei fiktive Modul-Adapter gleichzeitig registriert und geprüft
+Simulierter Fehlerfall löst nachweislich korrekten Retry aus"
+QA-03,Prüfgate Genehmigungen & Aufgaben,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Backlog,"Prozesstests, Zeitraffer","Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.",APR-02 TSK-03 APR-04 TSK-05,QA-05,"Vier-Augen-Freigabe ist gegen Missbrauchsversuch geprüft
+Fristen und Eskalationen lösen korrekt aus
+Alle Genehmigungspfade sind mindestens einmal durchlaufen","Ersteller kann eigene Freigabe im Test nicht zweitbestätigen
+Zeitraffer-Test über simulierte Fristen bestanden
+Eskalationspfad bis zum Dispatcher-Aufruf nachvollzogen"
+QA-04,Prüfgate Routing,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Backlog,"Regeltests, Testkorpus","Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.",RTE-04 RTE-05,QA-05,"Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft
+Klärungskorb fängt jedes nicht zuordenbare Objekt auf
+Simulation weicht nicht von echter Ausführung ab","Testkorpus mit bekannten Erwartungswerten vollständig durchlaufen
+Kein Testobjekt im Klärungskorb verloren
+Simulationsergebnis stimmt mit echter Ausführung überein"
+QA-05,Abnahme- & Compliance-Prüfung Workflow,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Backlog,Abnahmeprotokoll,"Abschließende Abnahmeprüfung über Engine, Genehmigungen, Aufgaben und Routing hinweg, mit abgelegtem Protokoll.",QA-02 QA-03 QA-04 QA-06 QA-07 QA-08,,"Alle Einzelprüfgates sind bestanden und referenziert
+Abnahmeprotokoll ist abgelegt und nachlesbar
+Offene Punkte sind explizit benannt, nicht stillschweigend übergangen","Abnahmeprotokoll gegen alle drei Prüfgates abgeglichen
+Protokoll enthält Zielwert, Messwert und Bewertung je Kriterium
+Zweite Person kann Abnahme anhand des Protokolls nachvollziehen"
+VOR-01,Akte/Vorgang-Objektmodell,📁 Akte & Vorgang,Backend,Mittel,3,3,Backlog,"PostgreSQL, Modul-Adapter (ENG-02)","Vorgang/Akte als eigenständiger Objekttyp – Status (offen/in Bearbeitung/geschlossen), Aktenzeichen, Verantwortlicher, Liste referenzierter Fremdobjekte (Typ + ID + Herkunfts-Board, z. B. „DMS-Dokument #123“ oder „Mail-Nachricht #456“) über den bestehenden Modul-Adapter.",ENG-02,VOR-02 VOR-03 VOR-04 VOR-05,"Akte kann Objekte aus mehreren Modulen gleichzeitig referenzieren, ohne deren Rohdaten zu duplizieren
+Statuswechsel ist nachvollziehbar protokolliert
+Aktenzeichen ist pro Tenant eindeutig und konfigurierbar (Format)","Akte mit Referenzen auf ein fiktives DMS-Objekt und ein fiktives Mail-Objekt gleichzeitig angelegt und geprüft
+Statuswechsel im Test erzeugt Protokolleintrag mit Person und Zeitpunkt
+Zwei Akten desselben Tenants mit identischem Aktenzeichen werden im Test abgewiesen"
+VOR-02,Vermerke/Notizen an Akte/Vorgang,📁 Akte & Vorgang,Backend,Einfach,2,4,Backlog,"PostgreSQL, unveränderliche Einträge","Freitext-Vermerke an einer Akte, jeweils mit Autor und Zeitstempel, unveränderlich nach dem Speichern (Ergänzung statt Bearbeitung, wie ein Aktenvermerk in der Realität).",VOR-01,VOR-04 VOR-05,"Vermerk ist nach dem Speichern nicht mehr veränderbar, nur neue Vermerke ergänzbar
+Autor und Zeitstempel sind Pflichtfelder
+Vermerke sind chronologisch sortiert abrufbar","Versuch, einen gespeicherten Vermerk zu ändern, wird im Test abgewiesen
+Vermerk ohne Autor oder Zeitstempel wird im Test abgewiesen
+Abruf mehrerer Vermerke liefert im Test chronologische Reihenfolge"
+VOR-03,Wiedervorlage (Akte/Objekt-Terminverknüpfung),📁 Akte & Vorgang,Backend,Mittel,3,4,Backlog,"TSK-Engine, PostgreSQL","Wiedervorlage-Termin an eine Akte oder ein einzelnes referenziertes Objekt (auch ohne vollständige Akte) hängen, nutzt die bestehende TSK-Engine (Aufgabenmodell/Fristen/Erinnerungen) für Fälligkeit und Benachrichtigung.",VOR-01 TSK-01,VOR-04 VOR-05,"Wiedervorlage kann sowohl an eine ganze Akte als auch an ein einzelnes Objekt gehängt werden
+Fälliger Termin erzeugt eine Aufgabe über TSK-01/TSK-02
+Erledigte Wiedervorlage ist von offener unterscheidbar, keine Löschung der Historie","Wiedervorlage an Akte und Wiedervorlage an Einzelobjekt im Test jeweils erfolgreich angelegt
+Fälliger Termin erzeugt im Test genau eine Aufgabe über die TSK-Engine
+Als erledigt markierte Wiedervorlage bleibt im Test in der Historie sichtbar und unterscheidbar von offenen"
+VOR-04,Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte,📁 Akte & Vorgang,Backend,Mittel,3,5,Backlog,"REST-Schnittstelle, read-only","Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.",VOR-01 VOR-02 VOR-03,QA-06 VOR-06,"Abfrage nach Objekt-Referenz liefert Akte, Vermerke und offene Wiedervorlagen in einem Aufruf
+Antwortzeit ist für den Einsatz in einer Dokument-/Mail-Detailansicht ausreichend kurz (keine spürbare Verzögerung beim Laden)
+API respektiert Berechtigungen – nur Vermerke/Akten sichtbar, für die der anfragende Nutzer berechtigt ist
+Abfrage ist zwingend tenant-gescoped – Tenant-Filter sitzt in der Query-/Repository-Schicht, nicht als nachgelagerter Filter (siehe SICHERHEITSKONZEPT.md); Objekte anderer Mandanten sind selbst bei geratener/falscher Objekt-Referenz nie sichtbar","Abfrage einer bekannten Objekt-Referenz liefert im Test Akte, Vermerke und offene Wiedervorlagen in einem Aufruf
+Antwortzeit im Test unter der für Detailansichten festgelegten Schwelle gemessen
+Abfrage mit nicht berechtigtem Nutzer liefert im Test keine fremden Akte-/Vermerkdaten
+Abfrage mit Objekt-Referenz eines fremden Mandanten liefert im Test keine Daten, auch wenn die Referenz-ID gültig/erratbar ist"
+VOR-05,Akten-Übersicht (Workflow-eigene Oberfläche),📁 Akte & Vorgang,Frontend,Mittel,3,5,Backlog,Next.js/React/TypeScript,"Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen. Zusätzlich eine Kanban-Ansicht für Wiedervorlagen mit Drag & Drop zwischen Statusspalten.",VOR-01 VOR-02 VOR-03 SHL-01,,"Liste aller Akten ist nach Status und Verantwortlichem filterbar
+Detailansicht zeigt Vermerke, Wiedervorlagen und verknüpfte Objekte einer Akte vollständig an
+Übersicht funktioniert unabhängig davon, ob der Zugriff über DMS/Mail oder direkt in Workflow erfolgt
+Kanban-Ansicht für Wiedervorlagen zeigt Spalten nach Fälligkeit/Status, Drag & Drop zwischen Spalten schreibt den neuen Status über VOR-03 zurück
+Kanban-Ansicht zeigt ausschließlich Wiedervorlagen des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet","Filter nach Status und Verantwortlichem liefert im Test korrekte Teilmengen
+Detailansicht einer Testakte zeigt im Test Vermerke, Wiedervorlagen und verknüpfte Objekte vollständig
+Akte mit Referenzen aus mehreren Modulen wird im Test korrekt dargestellt
+Verschieben einer Wiedervorlage per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über VOR-03
+Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Wiedervorlagen des aktuell aktiven Mandanten"
+QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Backlog,"Vertragstests (Consumer-Driven Contracts), CI-Pipeline","Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.",VOR-04 ENG-02,QA-05,"Vertragstests decken ENG-02 (Push) und VOR-04 (Pull) beide ab
+Absichtlich brechender Schema-Wechsel an jeder der beiden Schnittstellen lässt Tests fehlschlagen
+Tests laufen automatisiert in der CI","Testlauf gegen aktuellen Stand grün
+Simulierte Breaking Change an beiden Schnittstellen einzeln erkannt
+CI-Integration nachgewiesen"
+RTE-05,KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02),🔁 Regelbasiertes Routing,Backend,Mittel,3,6,Backlog,"HTTP-Client gegen AI-Vorschlags-API (WFS-02), Fallback auf regelbasiertes Routing","Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.",RTE-04,QA-04,"Routing-Ansicht zeigt bei aktiviertem AI-Modul einen KI-Vorschlag zusätzlich zur regelbasierten Entscheidung an
+Ist das AI-Modul nicht aktiviert oder nicht erreichbar, funktioniert das regelbasierte Routing unverändert ohne Vorschlag (fail open, kein Blockieren)
+Ein KI-Vorschlag wird niemals automatisch übernommen – Bearbeiter muss ihn aktiv bestätigen","Test gegen echte AI-Testinstanz: Vorschlag wird korrekt angezeigt und nachvollziehbar begründet
+Test: AI-Endpunkt nicht erreichbar – regelbasiertes Routing läuft unverändert weiter, keine Fehlermeldung im Regelpfad
+Test: KI-Vorschlag wird nicht bestätigt – Routing folgt der regelbasierten Entscheidung, nicht dem Vorschlag"
+QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,7,Backlog,"Lastgenerator, Messprotokoll","Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.",ENG-02 RTE-04,QA-05,"Definierte Ziel-Latenz für die Ereigniszustellung (ENG-02) unter Last aus zwei Modulen eingehalten
+Genehmigungs-Engine bleibt unter simulierter Mehrfach-Zustellung korrekt (keine doppelten Freigaben, keine verlorenen Anfragen)
+Regelbasiertes Routing bleibt unter Last korrekt und deterministisch","Lasttest mit simulierten parallelen Ereignissen aus DMS und Mail durchgeführt, Ergebnis dokumentiert
+Test auf doppelte/verlorene Genehmigungsanfragen unter Last
+Routing-Determinismus unter Last geprüft (gleiche Eingabe, gleiches Ergebnis)"
+QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,6,Backlog,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",APR-03 TSK-04 RTE-03 VOR-05,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"
+VOR-06,Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage),📁 Akte & Vorgang,Backend,Mittel,2,8,Backlog,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","VOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.",VOR-04,,"Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls
+Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten preiszugeben","Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten
+Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation"
+ENG-06,Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail,🔀 Workflow-Engine,Backend,Mittel,2,8,Backlog,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","ENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.",ENG-02,,"Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren unverändert","Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig"
+ENG-07,Technische Durchsetzung Append-only für das Instanzschritt-Protokoll,🔀 Workflow-Engine,Backend,Einfach,2,8,Backlog,"PostgreSQL (REVOKE/Trigger), Go","ENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.",ENG-04,,"Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
+Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
+Bestehende ENG-04-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar","Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
+Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin"

workflow-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>Workflow Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Workflow 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": 91, "epics": [{"key": "ENG", "name": "Workflow-Engine", "emoji": "🔀", "color": "#4338CA", "description": "Zustandsautomat, Modul-Adapter-Schnittstelle, deklaratives Prozessdefinitions-Format, Instanz-Historie und Fehlerbehandlung."}, {"key": "APR", "name": "Genehmigungen & Freigaben", "emoji": "✅", "color": "#0D9488", "description": "Freigabe-Postfach, Vier-Augen-Freigabe, Genehmigungs-Oberfläche und Delegation bei Abwesenheit."}, {"key": "TSK", "name": "Aufgaben, Fristen & Eskalation", "emoji": "⏱️", "color": "#C2410C", "description": "Aufgabenmodell, Fristen mit Kalenderlogik, Erinnerungen/Eskalationsregeln und die Aufgaben-Oberfläche."}, {"key": "RTE", "name": "Regelbasiertes Routing", "emoji": "🔁", "color": "#BE185D", "description": "Modulunabhängiges Routing-Regel-Modell, Ausführungs-Engine, Regel-Editor und Simulation."}, {"key": "QA", "name": "Prüfungen & Qualitätssicherung", "emoji": "✅", "color": "#16A34A", "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab."}, {"key": "VOR", "name": "Akte & Vorgang", "emoji": "📁", "color": "#92400E", "description": "Akte/Vorgang-Objektmodell, Vermerke, Wiedervorlage und Rückkanal-API für DMS/Mail sowie Workflow-eigene Akten-Übersicht."}], "waves": [{"welle": 1, "codes": ["ENG-01", "QA-01"]}, {"welle": 2, "codes": ["ENG-02", "ENG-03", "ENG-04", "ENG-05", "TSK-01"]}, {"welle": 3, "codes": ["APR-01", "TSK-02", "RTE-01", "QA-02", "VOR-01"]}, {"welle": 4, "codes": ["APR-02", "APR-03", "APR-04", "TSK-03", "TSK-04", "RTE-02", "RTE-03", "VOR-02", "VOR-03"]}, {"welle": 5, "codes": ["TSK-05", "RTE-04", "QA-03", "VOR-04", "VOR-05"]}, {"welle": 6, "codes": ["QA-04", "QA-06", "RTE-05"]}, {"welle": 7, "codes": ["QA-05", "QA-07"]}, {"welle": 8, "codes": ["VOR-06", "ENG-06", "ENG-07"]}], "kritischerPfad": {"path": ["ENG-01", "ENG-02", "RTE-01", "RTE-02", "RTE-04", "QA-04", "QA-05"], "days": 19}, "produktDna": {"uebernehmen": [{"produkt": "Alfresco", "staerke": "Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik – Kernidee dieses Boards."}, {"produkt": "Camunda/Zeebe", "staerke": "Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse, leichtgewichtig gedacht statt BPMN-Vollausbau."}, {"produkt": "Trello/Linear", "staerke": "Einfache, schnelle Aufgaben-Oberfläche als Vorbild – kein Schwergewicht."}], "vermeiden": [{"produkt": "Alfresco – Ressourcen-Overhead und Konfigurationskomplexität der Plattform.", "ansatz": "Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur."}, {"produkt": "Camunda/Zeebe – voller BPMN-Modellierungsapparat.", "ansatz": "Ein lesbares, versionierbares Prozessdefinitionsformat statt grafischem Modellierungswerkzeug."}]}, "epicDna": {"ENG": {"leitsatz": "Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.", "uebernehmen": ["Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.", "Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.", "Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt."], "vermeiden": ["Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.", "Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start."]}, "APR": {"leitsatz": "Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.", "uebernehmen": ["Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.", "Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.", "Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit."], "vermeiden": ["Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.", "Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen."]}, "TSK": {"leitsatz": "Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.", "uebernehmen": ["Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.", "Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.", "Fristen mit Arbeitstagslogik statt naiver Kalendertage."], "vermeiden": ["KeineLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>

workflow-kanban/tickets/ENG-06.md

@@ -0,0 +1,58 @@
+# ENG-06 – Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der meldenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder eingehenden Registrierung selbst gegen die Core-Registry.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+2. Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+3. Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren 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: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+2. Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), analog zu Archive-Finding `RET-12`: Workflow ist die Senke für Objekttyp-Registrierungen aus zwei anderen Modulen — ohne eigene Validierung würde ein Fehler oder eine Kompromittierung in DMS/Mail unmittelbar durchschlagen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)
+
+## 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: `ENG-06: unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`
+- Branch: `feature/eng-06-unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-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.

workflow-kanban/tickets/ENG-07.md

@@ -0,0 +1,58 @@
+# ENG-07 – Technische Durchsetzung Append-only für das Instanzschritt-Protokoll
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.
+
+**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.: Unveränderlichkeit ist eine Datenbank-Garantie, keine Anwendungs-Konvention.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
+2. Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
+3. Bestehende ENG-04-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 Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
+2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+3. Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), Analogie zu Core-Finding #5/`AUD-07` und DMS `VER-08`: 'unveränderlich' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit
+
+## 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: `ENG-07: technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`
+- Branch: `feature/eng-07-technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.

workflow-kanban/tickets/VOR-06.md

@@ -0,0 +1,58 @@
+# VOR-06 – Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage)
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+VOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der anfragenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder VOR-04-Anfrage selbst, statt der Angabe des anfragenden Moduls zu vertrauen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: VOR-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+2. Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls
+3. Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten 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. Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten
+2. Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), analog zu DMS-Finding `INT-16`/Mail-Finding `INT-11`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal ohne eigene Tenant-Validierung kann diese Isolation modulübergreifend aufweichen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+
+## 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: `VOR-06: tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`
+- Branch: `feature/vor-06-tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.