patrickandClaude Sonnet 5
d4416bc362
Ausgangsmessung durchgefuehrt statt nur Code gelesen: bestehender Test dms/internal/cmis/cmis_test.go::TestPermissionParityWithREST auf Host 204 gegen echte migrierte Testdatenbank ausgefuehrt (TEST_TENANT_DSN), PASS. Bestaetigt per echtem Testlauf: fremder Nutzer mit gueltigem Token liest fremdes Dokument ueber CMIS -> 403; gefaelschter caller-Parameter neben echtem fremden Token -> weiterhin 403 (Token-Identitaet gewinnt). Ursache: cmisBackend.Set(routes) in cmd/app/main.go:109 verdrahtet CMIS auf die komplette Middleware-Kette, interner Re-Dispatch prueft CanAccessDocument/ CanAccessFolder erneut. Kein Code-Fix noetig, Ticket dokumentiert die negative Pruefung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
65 KiB
65 KiB
| 1 | Code | Titel | Epic | Rolle | Komplexitaet | Aufwand_PT | Welle | Status | Technik | Beschreibung | Haengt_ab_von | Schaltet_frei | Akzeptanzkriterien | Pruefungen |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 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 | |
| 3 | 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 |
| 4 | 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 |
| 5 | 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 |
| 6 | FDN-07 | CI-Pipeline & Testharness | ⚙️ Fundament | DevOps | Einfach | 2 | 2 | Fertig | 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. |
| 7 | FDN-08 | Logging, Metriken & Fehler-Tracking | ⚙️ Fundament | DevOps | Einfach | 2 | 2 | Fertig | 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 |
| 8 | 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 |
| 9 | DOC-02 | Dublettenerkennung | 🗂️ Dokumentenkern | Backend | Einfach | 2 | 4 | Fertig | 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 |
| 10 | DOC-03 | Drag-and-Drop-Upload-Oberfläche | 🗂️ Dokumentenkern | Frontend | Mittel | 3 | 4 | Fertig | 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 |
| 11 | DOC-04 | Vorschau- & Thumbnail-Pipeline | 🗂️ Dokumentenkern | Backend | Komplex | 5 | 4 | Fertig | 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 |
| 12 | DOC-05 | PDF-Viewer-Komponente | 🗂️ Dokumentenkern | Frontend | Komplex | 4 | 5 | Fertig | 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 |
| 13 | DOC-06 | Office-zu-PDF-Konverter | 🗂️ Dokumentenkern | Backend | Komplex | 4 | 4 | Fertig | 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 |
| 14 | DOC-07 | Download & signierte URLs | 🗂️ Dokumentenkern | Backend | Einfach | 2 | 4 | Fertig | 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 |
| 15 | DOC-08 | Massenexport als ZIP | 🗂️ Dokumentenkern | Backend | Mittel | 3 | 5 | Fertig | 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 DOC-18 | 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 |
| 16 | DOC-09 | Ordner- & Kabinettmodell | 🗂️ Dokumentenkern | Backend | Mittel | 3 | 3 | Fertig | 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 |
| 17 | DOC-10 | Ordner-Navigation & Dokumentenliste | 🗂️ Dokumentenkern | Frontend | Mittel | 3 | 4 | Fertig | 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 |
| 18 | DOC-11 | Soft-Delete & Papierkorb-Logik | 🗂️ Dokumentenkern | Backend | Einfach | 2 | 4 | Fertig | 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 |
| 19 | DOC-12 | Papierkorb-Oberfläche | 🗂️ Dokumentenkern | Frontend | Einfach | 2 | 5 | Fertig | 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 |
| 20 | SRC-01 | Suchindex-Infrastruktur | 🔍 Suche & OCR | DevOps | Mittel | 3 | 2 | Fertig | 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 |
| 21 | SRC-02 | Indexierungs-Worker & Synchronisierung | 🔍 Suche & OCR | Backend | Komplex | 4 | 5 | Fertig | 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 |
| 22 | SRC-03 | Such-API mit Ranking | 🔍 Suche & OCR | Backend | Mittel | 3 | 6 | Fertig | 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 |
| 23 | SRC-04 | Such-Oberfläche mit Hervorhebung | 🔍 Suche & OCR | Frontend | Mittel | 3 | 7 | Fertig | 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 |
| 24 | SRC-05 | OCR-Worker | 🔍 Suche & OCR | Backend | Komplex | 5 | 5 | Fertig | 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 |
| 25 | SRC-06 | PDF/A-Erzeugung mit Textebene | 🔍 Suche & OCR | Backend | Mittel | 3 | 6 | Fertig | 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 |
| 26 | SRC-07 | Spracherkennung & OCR-Qualitätsbewertung | 🔍 Suche & OCR | Backend | Einfach | 2 | 6 | Fertig | 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 |
| 27 | SRC-08 | Facetten- & Filter-API | 🔍 Suche & OCR | Backend | Mittel | 3 | 7 | Fertig | 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 |
| 28 | SRC-09 | Filter-Panel in der Suche | 🔍 Suche & OCR | Frontend | Mittel | 3 | 8 | Fertig | 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 |
| 29 | SRC-10 | Gespeicherte Suchanfragen | 🔍 Suche & OCR | Fullstack | Einfach | 2 | 8 | Fertig | 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 |
| 30 | MET-01 | Tag-Modell & Tag-API | 🏷️ Metadaten | Backend | Einfach | 2 | 3 | Fertig | 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 |
| 31 | MET-02 | Benutzerdefinierte Metadatenfelder | 🏷️ Metadaten | Backend | Komplex | 4 | 3 | Fertig | 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 |
| 32 | MET-03 | Metadaten- & Tag-Oberfläche | 🏷️ Metadaten | Frontend | Mittel | 3 | 4 | Fertig | 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 |
| 33 | MET-04 | Dokumententypen & Vorlagen | 🏷️ Metadaten | Backend | Mittel | 3 | 4 | Fertig | 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 |
| 34 | MET-05 | Regelbasierte Auto-Verschlagwortung | 🏷️ Metadaten | Backend | Mittel | 3 | 6 | Fertig | 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 |
| 35 | VER-01 | Versionsmodell & Check-in/Check-out | 🔄 Versionierung & Audit | Backend | Komplex | 4 | 4 | Fertig | 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 |
| 36 | VER-02 | Versionsansicht & Wiederherstellung | 🔄 Versionierung & Audit | Frontend | Mittel | 3 | 5 | Fertig | 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 |
| 37 | VER-03 | Änderungshistorie & Diff-Berechnung | 🔄 Versionierung & Audit | Backend | Mittel | 3 | 5 | Fertig | 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 |
| 38 | VER-04 | Diff-Ansicht | 🔄 Versionierung & Audit | Frontend | Mittel | 3 | 6 | Fertig | 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 |
| 39 | VER-05 | Revisionssicherer Audit-Trail | 🔄 Versionierung & Audit | Backend | Komplex | 4 | 3 | Fertig | 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 |
| 40 | VER-06 | Audit-Log-Ansicht & Export | 🔄 Versionierung & Audit | Frontend | Einfach | 2 | 4 | Fertig | 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 |
| 41 | VER-07 | Digitale Signatur | 🔄 Versionierung & Audit | Backend | Komplex | 5 | 5 | Fertig | 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 |
| 42 | INT-01 | REST-API v1 & Schnittstellenbeschreibung | 🔌 Integration & API | Backend | Komplex | 4 | 4 | Fertig | 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 |
| 43 | INT-03 | E-Mail-Abruf über IMAP | 🔌 Integration & API | Backend | Komplex | 4 | 4 | Fertig | 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 |
| 44 | INT-04 | E-Mail-Regeln & Anhangverarbeitung | 🔌 Integration & API | Backend | Mittel | 3 | 7 | Fertig | 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 |
| 45 | INT-06 | Scanner-Anbindung über Hot-Folder | 🔌 Integration & API | Backend | Komplex | 4 | 6 | Fertig | Ü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 |
| 46 | UX-01 | Responsive Layout & mobile Navigation | 📱 UX & Zugänglichkeit | Frontend | Mittel | 3 | 1 | Fertig | 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 | |
| 47 | UX-02 | Dunkles Erscheinungsbild & Theming | 📱 UX & Zugänglichkeit | Frontend | Einfach | 2 | 1 | Fertig | 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 | |
| 48 | UX-03 | Mehrsprachigkeits-Infrastruktur | 📱 UX & Zugänglichkeit | Frontend | Mittel | 3 | 1 | Fertig | 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 | |
| 49 | UX-04 | Übersetzungen Deutsch und Englisch | 📱 UX & Zugänglichkeit | Frontend | Einfach | 2 | 2 | Fertig | 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 |
| 50 | UX-05 | Barrierefreiheit nach WCAG 2.1 AA | 📱 UX & Zugänglichkeit | Frontend | Komplex | 4 | 2 | Fertig | 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 |
| 51 | QA-01 | Teststrategie & Testdatenbestand | ✅ Prüfungen & Qualitätssicherung | QA | Einfach | 2 | 3 | Fertig | 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 |
| 52 | QA-02 | Prüfgate Fundament | ✅ Prüfungen & Qualitätssicherung | QA | Einfach | 2 | 4 | Fertig | 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 |
| 53 | QA-03 | Prüfgate Dokumentenkern | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 6 | Fertig | 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 |
| 54 | QA-04 | Prüfgate Suche & Texterkennung | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 9 | Fertig | 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 |
| 55 | QA-05 | Prüfgate Metadaten & Klassifizierung | ✅ Prüfungen & Qualitätssicherung | QA | Einfach | 2 | 7 | Fertig | 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 |
| 56 | QA-06 | Sicherheits- & Berechtigungsprüfung | ✅ Prüfungen & Qualitätssicherung | QA | Komplex | 4 | 10 | Fertig | 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 |
| 57 | QA-07 | Prüfgate Workflow & Benachrichtigung | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 4 | Fertig | 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 |
| 58 | QA-08 | Revisionssicherheits-Prüfung | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 7 | Fertig | 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 |
| 59 | QA-09 | Schnittstellen-Vertragstests | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 8 | Fertig | 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 |
| 60 | 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 |
| 61 | QA-11 | Barrierefreiheits-Audit | ✅ Prüfungen & Qualitätssicherung | QA | Mittel | 3 | 3 | Fertig | 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 |
| 62 | 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 | |
| 63 | 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 |
| 64 | DOC-13 | Akten-/Vorgangsanzeige im Dokumentkontext | 🗂️ Dokumentenkern | Frontend | Einfach | 2 | 6 | Fertig | 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 |
| 65 | INT-08 | Watch-Folder-Import (Consume-Ordner) | 🔌 Integration & API | Backend | Mittel | 3 | 4 | Fertig | Ü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 |
| 66 | INT-09 | CMIS-kompatible Schnittstelle (optional) | 🔌 Integration & API | Backend | Komplex | 4 | 5 | Fertig | 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 |
| 67 | INT-10 | Scanner-Stapelverarbeitung mit Trennseiten-/Barcode-Erkennung | 🔌 Integration & API | Backend | Mittel | 3 | 7 | Fertig | 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 |
| 68 | DOC-14 | Dokument-Zusammenführen & -Aufteilen | 🗂️ Dokumentenkern | Backend | Mittel | 3 | 4 | Fertig | 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 |
| 69 | DOC-15 | Massenbearbeitung von Metadaten | 🗂️ Dokumentenkern | Backend | Mittel | 3 | 4 | Fertig | 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 |
| 70 | INT-11 | Archive-Anbindung: Objekttyp-Registrierung & Retention-Abfrage | 🔌 Integration & API | Backend | Mittel | 3 | 4 | Fertig | 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 |
| 71 | INT-12 | AI-Anbindung: Objekttyp-Registrierung (Kopplung AI GOV-01) | 🔌 Integration & API | Backend | Mittel | 2 | 4 | Fertig | 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 |
| 72 | INT-13 | Workflow-Anbindung: Objekttyp- & Auslöser-Registrierung (Kopplung Workflow ENG-02) | 🔌 Integration & API | Backend | Mittel | 3 | 4 | Fertig | HTTP-Client gegen Workflow-Modul-Adapter-Schnittstelle, Ereignis-Publisher | 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) |
| 73 | SRC-11 | Feld-Whitelist-Query-Builder für Suchindex-Zugriff | 🔍 Suche & OCR | Backend | Einfach | 1 | 3 | Fertig | 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 |
| 74 | 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 | |
| 75 | INT-14 | Tenant-Zuordnung & Zugriffsschutz für Hot-Folder/Scanner-Verzeichnisse | 🔌 Integration & API | Backend | Mittel | 2 | 12 | Fertig | 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 | |
| 76 | INT-15 | CMIS-Schnittstelle: Auth-/Tenant-Scoping-Parität zur REST-API | 🔌 Integration & API | Backend | Mittel | 2 | 12 | Fertig | 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 | |
| 77 | INT-16 | Nutzer-Tenant-Kontext in Modul-Rückkanälen (Archive/AI/Workflow) | 🔌 Integration & API | Backend | Mittel | 2 | 12 | Fertig | 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 | |
| 78 | DOC-17 | Malware-Scan vor Ablage | 🗂️ Dokumentenkern | Backend | Mittel | 2 | 12 | Fertig | 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 | |
| 79 | FDN-10 | Signierte URLs: Scope-Bindung & kurze Ablaufzeit | ⚙️ Fundament | Backend | Einfach | 1 | 12 | Fertig | 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 | |
| 80 | FDN-11 | Ressourcenlimits für asynchrone Verarbeitungsjobs | ⚙️ Fundament | Backend | Mittel | 2 | 12 | Fertig | 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 | |
| 81 | VER-08 | Technische Durchsetzung Append-only für das Versionierungs-/Ereignisprotokoll | 🔄 Versionierung & Audit | Backend | Einfach | 2 | 12 | Fertig | 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 | |
| 82 | DOC-18 | Obergrenze für Gesamtgröße/Anzahl bei Archiv-Bündelung | 🗂️ Dokumentenkern | Backend | Einfach | 1 | 13 | Fertig | Postgres-Jobqueue, Ressourcenlimits, Go | DOC-08 bündelt mehrere ausgewählte Dokumente als Hintergrund-Job zu einem Archiv, ohne Obergrenze für Gesamtgröße oder Anzahl der Dokumente je Anfrage. Eine übermäßig große Auswahl kann sonst den Bündelungs-Job unverhältnismäßig lange laufen lassen und Ressourcen auf Kosten anderer Mandanten binden. Harte, konfigurierbare Obergrenze für maximale Gesamtgröße und maximale Dokumentanzahl je Bündelungs-Anfrage einführen – bei Überschreitung wird die Anfrage mit klarer Fehlermeldung abgelehnt, bevor der Job gestartet wird. | DOC-08 | Eine Bündelungs-Anfrage mit konfigurierbar zu großer Gesamtgröße oder Dokumentanzahl wird vor Jobstart abgelehnt, mit klarer Fehlermeldung an den Nutzer Innerhalb der Obergrenze funktioniert die Bündelung aus DOC-08 unverändert Die Obergrenzen sind konfigurierbar, nicht hart im Code verankert | Test: Anfrage mit Auswahl oberhalb der konfigurierten Obergrenze wird abgelehnt, kein Job wird gestartet Test: Anfrage innerhalb der Obergrenze wird normal verarbeitet Regressionstest bestehender DOC-08-Funktionalität nach Einführung der Prüfung | |
| 83 | SEC-01 | Unauthentifizierter Vernichtungs-Rückruf löscht Dokumente physisch | 🔒 Sicherheit | Backend | Komplex | 3 | 13 | Backlog | Service-Token-Pflicht, Legal-Hold-Check, Body-Limit | Der Vernichtungs-Rückruf des Retention-Dienstes ist im Standardbetrieb fail-open: ohne Bearer-Token werden Dokumente physisch gelöscht, Legal Hold wird nicht geprüft, der Audit-Akteur wird falsch protokolliert. | RequireServiceToken serverseitig fest auf true erzwungen Aufruf ohne gültiges Bearer-Token wird mit 401/403 abgelehnt Legal-Hold-Status wird vor physischer Löschung geprüft Request-Body ist auf eine feste Obergrenze begrenzt Audit-Eintrag protokolliert den tatsächlichen Service-Akteur | Angriffsnachstellung ohne Bearer-Token: vor Fix löschend, nach Fix abgelehnt Aufruf gegen Objekt mit aktivem Legal Hold wird abgelehnt Request-Body oberhalb der Obergrenze wird abgelehnt Audit-Log nach legitimem Aufruf enthält korrekten Service-Akteur | ||
| 84 | SEC-02 | Mail-Postfachverwaltung ohne Rollenprüfung ermöglicht Credential-Exfiltration | 🔒 Sicherheit | Backend | Komplex | 3 | 13 | Backlog | Rollenprüfung Admin-only, Passwortbindung bei Host-Änderung | Die Mail-Postfachverwaltung erlaubt jeder authentifizierten Identität Host/Port-Änderungen ohne Passwortbestätigung, wodurch gespeicherte IMAP-Zugangsdaten an einen angreifereigenen Server exfiltriert werden können; ImportUserID ist zusätzlich frei wählbar. | needsGuard für mail-accounts auf true gesetzt, nur Admin-Rolle Host/Port-Änderung verlangt erneute Passworteingabe ImportUserID wird serverseitig auf den authentifizierten Actor fixiert Automatisierter Test belegt Ablehnung von Host-Änderung ohne Passwort | Angriffsnachstellung: Host-Änderung mit leerem Passwort auf fremden IMAP-Server, vor/nach Fix dokumentiert Angriffsnachstellung: Import mit fremdem ImportUserID, vor/nach Fix dokumentiert Regressionstest: legitime Host-Änderung mit Passwort funktioniert weiterhin | ||
| 85 | SEC-03 | Guard-Lücken: Papierkorb/Ordnerbaum/Trigger-Webhooks ohne Zugriffsprüfung | 🔒 Sicherheit | Backend | Mittel | 2 | 13 | Backlog | needsGuard-Korrektur, eigentümerbezogene Filterung | GET /trash, /folders und /triggers liefern mandanten-/nutzerübergreifend Daten aus, da needsGuard für diese Routen auf false steht. | needsGuard für GET /folders/*, /trash, /triggers auf true GET /trash liefert nur eigene Papierkorb-Einträge folderapi liefert nur sichtbaren Teilbaum triggerapi liefert webhook_url nur bei Berechtigung | Angriffsnachstellung GET /trash fremder Nutzer, vor/nach Fix dokumentiert Gleiche Nachstellung für /folders und /triggers Regressionstest: eigene Daten weiterhin vollständig sichtbar | ||
| 86 | SEC-04 | Virenscan standardmäßig nicht in die Verarbeitungs-Pipeline eingereiht | 🔒 Sicherheit | Backend | Mittel | 2 | 13 | Backlog | enqueueTypes-Default, Sichtbarkeitsfilter umkehren | malwarescan.scan ist nicht in enqueueTypes enthalten; Dokumente ohne jemals ausgeführten Scan sind sofort sichtbar, da nur explizit unclean markierte Dokumente ausgeblendet werden. | malwarescan.scan standardmäßig in enqueueTypes Sichtbarkeit nur bei explizitem status = clean Bestehende ungescannte Dokumente werden per Nachlauf erfasst | Angriffsnachstellung: Upload bei deaktiviertem Scan-Worker, vor/nach Fix dokumentiert Regressionstest: clean-Dokument bleibt sichtbar Regressionstest: unclean-Dokument bleibt gesperrt | ||
| 87 | SEC-05 | Upload-Limit standardmäßig unbegrenzt, Client-MIME ungeprüft, authentifizierter OOM | 🔒 Sicherheit | Backend | Mittel | 3 | 13 | Backlog | Upload-Limit-Default, Server-MIME-Sniffing, Streaming-Verschlüsselung | Upload-Limit 0 gilt als unbegrenzt, MIME-Typ wird vom Client übernommen, und die Verschlüsselung liest die komplette Datei ins RAM — ein authentifizierter Nutzer kann per großem Upload einen RAM-OOM auslösen. | Standard-Upload-Limit ist fester Wert > 0 MIME-Typ wird serverseitig gesnifft und abgeglichen Verschlüsselungspfad verarbeitet den Stream statt vollständigem RAM-Puffer Request-Body ist hart begrenzt | Angriffsnachstellung: großer Upload, RAM-Verbrauch vor/nach Fix gemessen und dokumentiert Angriffsnachstellung: falsch deklarierter Content-Type wird per Sniffing erkannt Regressionstest: reguläre Uploads funktionieren weiterhin | ||
| 88 | SEC-06 | Modul-Verifier akzeptiert fremde Tenants wenn TENANT_SLUG leer | 🔒 Sicherheit | Backend | Einfach | 1 | 13 | Backlog | TENANT_SLUG-Pflicht beim Dienststart | Ist TENANT_SLUG beim Dienststart leer, wird die Tenant-Prüfung im Modul-Verifier übersprungen und Tokens für jeden Tenant akzeptiert. | Dienststart verweigert bei fehlendem/leerem TENANT_SLUG verifier.go prüft Tenant immer, keine Ausnahme bei leerem Wert Token für fremden Tenant wird in jedem Fall abgelehnt | Angriffsnachstellung: Start ohne TENANT_SLUG, fremdes Token, vor/nach Fix dokumentiert Regressionstest: korrekter Start mit eigenem Token funktioniert Test: fremdes Token bei korrektem TENANT_SLUG weiterhin abgelehnt | ||
| 89 | SEC-07 | NEXARCH_DMS_APP_ALLOW_CALLER_IDENTITY umgeht komplette Authentifizierung | 🔒 Sicherheit | Backend | Mittel | 2 | 13 | Backlog | Produktionssperre für Übergangs-Flag | Das Flag ALLOW_CALLER_IDENTITY erlaubt Admin-Zugriff per Query-Parameter ohne echte Authentifizierung und ist nur per Deployment-Checkliste, nicht technisch, auf Host 131 beschränkt. | Flag wirkt nur bei explizit markierter Nicht-Produktionsumgebung Bei Produktion oder fehlender Markierung wird das Flag ignoriert Deployment-Checkliste enthält Entfernungsschritt vor Produktivbetrieb | Angriffsnachstellung: Flag ohne Nicht-Produktions-Markierung, vor/nach Fix dokumentiert Regressionstest: Flag mit korrekter Markierung funktioniert für Host 131 weiterhin Test: Flag ohne jede Umgebungsvariable wird ignoriert | ||
| 90 | SEC-08 | Objektrechte (Ordner-ACL) existieren im Code, werden aber nie geprueft | 🔒 Sicherheit | Backend | Komplex | 3 | 13 | Backlog | ObjectAllowed in authz verdrahten | PoolChecker entscheidet Sichtbarkeit nur ueber created_by == caller plus statische Admin-Liste. policyclient.ObjectAllowed (Core RBAC-11, Ordner-/Dokumentpfad inkl. Gruppen) existiert fertig implementiert, wird aber nirgends aufgerufen. Suche filtert ebenfalls hart auf created_by. | CanAccessDocument/CanAccessFolder fragen zusaetzlich ObjectAllowed ab, hasEntries=false aendert nichts am bisherigen Verhalten Bei hasEntries=true entscheidet ausschliesslich ObjectAllowed Suche filtert bei vorhandenen Objektrechten auf erlaubte Ordner-IDs statt created_by Ausfall der Objektrechte-Abfrage fuehrt zu Ablehnung (fail-closed) groupIDs-Herkunft dokumentiert | Mandant ohne Objektrechte-Eintrag: Verhalten identisch zum Stand vorher Dokument mit Freigabe fuer fremden Nutzer: dieser kann nun zugreifen Dokument mit Entzug fuer Ersteller: Ersteller wird abgelehnt RBAC-11 nicht erreichbar: Zugriff verweigert Suche liefert nur erlaubte Treffer | ||
| 91 | SEC-09 | CMIS-Autorisierungspfad geprueft: kein Bypass bestaetigt | 🔒 Sicherheit | Backend | Mittel | 2 | 13 | Fertig | CMIS-Zugriffspruefung geklaert | Vermuteter Bypass geprueft und per echtem Test (TestPermissionParityWithREST, Host 204, TEST_TENANT_DSN) widerlegt: CMIS-Backend ist auf die komplette Middleware-Kette verdrahtet, interner Re-Dispatch prueft CanAccessDocument/CanAccessFolder erneut. Kein Code-Fix noetig. | Dokumentiert und per Test belegt, dass CMIS-Zugriff auf fremdes Dokument NICHT durchgeht - erledigt Kein Code-Fix erforderlich, da kein Bypass bestaetigt Verbleibendes AllowCaller-Restrisiko als bereits durch SEC-07 abgedeckt dokumentiert | Ausgangsmessung durchgefuehrt: bestehender Test TestPermissionParityWithREST auf Host 204 gegen echte migrierte Testdatenbank ausgefuehrt, PASS Fremder Nutzer mit gueltigem Token liest fremdes Dokument ueber CMIS: 403 bestaetigt Gefaelschter caller-Parameter neben echtem fremden Token: 403 bestaetigt (Token-Identitaet gewinnt) REST und CMIS liefern fuer alle Tokenzustaende identische Statuscodes |