Stand von chore/ai-kanban-security-folgetickets. Die Historie dieses Branches hat keinen gemeinsamen
Vorfahren mit main, daher als Snapshot. _shared enthaelt CSS/JS der
Kanban-Ansicht (identisch in allen Board-Branches).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
/datev/exports braucht connect.datev.write (POST) bzw. connect.datev.read
(GET) mit der Rolle aus X-User-Role. Registriert nur mit
NEXARCH_CONNECT_APP_ARCHIVE_URL; die DATEV-Uebertragung bleibt aus.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Bisher fragte statusapi mit fester Rolle user. bearerauth setzt X-User-Role
aus dem Token; ohne Header bleibt es bei user.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die beiden gleichen Kopien entfallen; common v0.2.2. Das Testpflicht-Muster
fuer bearerauth wandert vom workflow-Gate in das common-Gate.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Beide Module halten dieselbe Middleware (nur der Kommentar unterscheidet
sich). Hier liegt die gemeinsame Fassung; workflow und connect stellen
nach dem Tag in einem Folge-PR um.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Account auf 131 hat Next 14.2.35, die Quelle braucht 16.3.5 (--webpack
unbekannt). Abhaengigkeiten werden jetzt per Lockdatei-Hash erneuert,
shl/node_modules wird auf die der App verlinkt (eine React-Instanz).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Auf 131 hat /opt/nexarch-web/portal/web/shl kein node_modules; der rsync
laesst node_modules aus. Typpruefung scheiterte mit TS2307 'react'.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Env-Datei, Unit, nginx-Block 8450, nft-Regel, Audience portal, CORS am Core
und Neubau von Portal und Login in einem idempotenten Lauf mit Sicherungen.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die Kachel zeigt Punkt und Text, wenn die Statusseite ein Pruefziel kennt,
dessen Name dem Modul-Schluessel oder der Bezeichnung entspricht. Ohne
Berechtigung (403) oder ohne Statusquelle bleibt die Kachel unveraendert.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
NEXT_PUBLIC_PORTAL_URL ist das Ziel (ohne Wert wie bisher /profile). Das
Profil bekommt einen Link zum Portal.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Gleiche Aenderung wie workflow/internal/bearerauth, damit die Rechtepruefung
aus #418 die echte Rolle bekommt.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
workflow bearerauth setzt X-User-Role nur aus den Claims (Client-Header werden
entfernt); taskapi und connectorsetupapi fragen mit dieser Rolle, Default user.
Migration 0029: connect.setup.write nur fuer tenant_admin.
ai-app, workflow-app, connect-app starten ohne POLICY_URL nicht mehr, ausser
mit NEXARCH_<MODUL>_APP_POLICY_DISABLED=1.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
connect/internal/bearerauth (wie workflow): verifiziertes Core-Token setzt
X-User-Id/X-Tenant-Slug, ohne Token nur mit NEXARCH_CONNECT_APP_ALLOW_HEADER_AUTH=1.
Mit JWKS ist NEXARCH_CONNECT_APP_TENANT_SLUG Pflicht (Mandant der Datenbank).
common auf v0.2.1 (moduleauth). Frontends nutzen createBearerClient("connect").
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- semanticsearchapi: ai.search.read per policyclient (WithPolicy), Tenant aus
dem Anfragekoerper, nach Service-Token-Pruefung
- taskapi: workflow.task.read (GET /tasks) und workflow.task.write (PATCH
status); Paket jetzt in cmd/workflow-app verdrahtet (lag bisher nur im
a11y-Fixture) und damit hinter bearerauth
- connectorsetupapi: connect.setup.read/write je Route
- Migration 0029 (up/down): neue Rechte fuer user und tenant_admin
- Wiring: NEXARCH_{AI,WORKFLOW,CONNECT}_APP_POLICY_URL/_POLICY_SERVICE_TOKEN;
ohne URL Warnung und keine Pruefung (Uebergang), URL ohne Token Startfehler;
connect-app setzt die bestehende statusapi-Pruefung damit ebenfalls scharf
- Tests je API: 403 bei Ablehnung, 200 bei Freigabe, 503 bei Ausfall, Policy
wird ohne Identitaet/Service-Token nicht befragt
- MODULE_REGISTRY: ai_search_chat, workflow_tasks, connect_setup (+ Icons,
Portal-Rechteliste)
- Doku: BETRIEB-PORTAL.md, ENG-11 Umgebungsvariablen
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
workflow-approvals, workflow-tasks, workflow-cases und routing-rules hatten
identische lib/http.ts und lib/forward.ts; mail-search eine fuenfte Variante.
Verhalten unveraendert.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die BFF-Route reicht mit Bearer nur das Token weiter; user/tenant aus der
URL gelten nur noch ohne Token. Der Client sendet das Token ueber eine
zweite Sitzung (module workflow), sobald NEXT_PUBLIC_CORE_API_BASE gesetzt ist.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Aenderungen an bearerauth (Durchsetzungspunkt fuer Bearer-Token der Frontends)
brauchen jetzt eine begleitende _test.go im selben Package.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Vorbereitung auf mehrere NEXARCH_ACCOUNT_MODULE_AUDIENCES: der Core lehnt
Token-Anfragen ohne ?module ab, sobald mehr als eine Audience konfiguriert ist.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Mit NEXT_PUBLIC_CORE_API_BASE holen die Frontends ein workflow-Token ueber die
Sitzung und senden Authorization; die BFF-Routen reichen es weiter und ignorieren
userId/tenant aus der URL. Ohne die Variable bleibt der Uebergangsweg.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Das Pflichttest-Gate von workflow verweist nicht mehr auf die geloeschten
Pakete (common hat ein eigenes Gate).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
auditclient und policyclient aus der Liste in check-security-test-coverage.sh
entfernt (Pakete liegen jetzt in common, dort durch das common-Gate gedeckt).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Das Pflichttest-Gate von ai verweist nicht mehr auf das geloeschte
svcauth-Paket (common hat ein eigenes Gate).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die common-Fassung von apierror enthaelt die 5xx-Behebung (Text verborgen,
Korrelations-ID). Der Waechtertest gegen http.DefaultClient liegt jetzt in
internal/archtest.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
apierror, auditclient, httpclient, httpharden, svcauth und tenantregistryclient
kommen aus gitea.perlbach24.de/scripte/nexarch/common. Der Wächtertest gegen
http.DefaultClient liegt jetzt in internal/archtest.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
CheckDiff(changed, patterns): gleiche Logik wie die Modul-Gates, Pfadmuster
vom Aufrufer. cmd/pflichttestgate + Workflow decken svcauth,
tenantregistryclient, auditclient, policyclient, apierror, httpharden ab.
README: Auswirkungsliste und Minor-Version bei Breaking Changes.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Pakete: apierror, auditclient, httpclient, httpharden, loadtest, migrate,
policyclient, svcauth, tenantregistryclient, testdb. Code stammt aus den
bisher byte-gleichen Modulkopien (ohne Kommentare/Importpfade verglichen).
migrate/testdb brauchen pgx v5.9.2.
Auslieferung per Git-Tag common/vX.Y.Z (Workflow common-tag.yml, setzt nach
Merge in main den naechsten Patch-Tag nach Build/Vet/Test). Kein replace,
damit Module einzeln baubar bleiben. Verbraucher werden in Folge-PRs
umgestellt.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
NewServer verlangt seit ENG-06 einen TenantVerifier; der Vertragstest
rief noch mit drei Argumenten auf, go vet schlug fehl. Stub wie beim
backchannel-Vertragstest (alwaysValidVerifier).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Fable-Review auf Code-Dopplung (P1). web/dms-browser, web/dms-upload,
web/pdf-viewer hatten byteidentische components/AccountBar.tsx. Darstellung
jetzt einmal in web/shl/components/AccountBar.tsx (visible/onLogout als
Props). Die drei App-lokalen Dateien bleiben als duenne 10-Zeilen-Wrapper
bestehen (loesen authMode()/getSession() aus dem jeweils eigenen,
unterschiedlichen lib/http.ts auf) statt komplett zu verschwinden --
direktes Reichen der onLogout-Funktion von layout.tsx (Server Component)
an die shl-Komponente verletzt sonst die RSC-Props-Grenze ("Event handlers
cannot be passed to Client Component props"), erst beim Build entdeckt
und korrigiert.
next build + npx vitest run auf allen 3 Apps gruen (Testhost 131).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-19 23:17:02 +02:00
587 changed files with 11792 additions and 3624 deletions
@@ -6,6 +6,17 @@ Stand: 2026-08-26. Zusammenführung aller bisherigen Entscheidungen aus `nexarch
NEXARCH ist die Nachfolgeplattform von **archivmail** (E-Mail-Archivierung) und **archivdms** (Dokumentenmanagement) — nicht als Umbenennung, sondern als modulare Neuentwicklung unter der Positionierung **"Next Generation Information Management"**: E-Mails, Dokumente, digitale Archivierung, OCR, Volltextsuche, Workflows, Compliance, Integrationen, KI — als ein zusammenhängendes System, nicht als zwei getrennte Werkzeuge nebeneinander.
## 1a. Vorbildsysteme
NEXARCH vereint die Stärken bestehender Systeme und vermeidet deren bekannte Schwächen (Details: `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md`).
| Bereich | Vorbildsysteme |
|---|---|
| Mail | **archivmail** (eigenes Produkt, Vorgänger), **MailPiler** |
Weitere Vergleichsprojekte (z. B. OpenKM, Nuxeo, Mayan EDMS, Seafile) sind noch zu prüfen. Für das DMS-Modul siehe auch `dms/README.md`.
## 2. Architekturprinzip
**Ein modularer Monolith aus sieben eigenständigen, aber koordinierten Diensten** — kein Microservice-Zwang, aber klare Dienstgrenzen mit eigenem Datenmodell, eigenem Go-Binary, eigenem Kanban-Board:
@@ -64,6 +75,8 @@ Kein Modul kopiert die Daten eines anderen — stattdessen ein wiederkehrendes *
Gemeinsamer Nenner aller drei: **Referenz statt Kopie, Adapter statt Direktkopplung.**
Go-`internal/`-Pakete sind zwischen den Modulen nicht sichtbar; identische Querschnittspakete liegen deshalb im versionierten Modul `common/` (Git-Tags `common/vX.Y.Z`, siehe `common/README.md`). So bleiben Module einzeln baubar (Docker, eigenes Repo, Partner-Build). Fachlich verschiedene Pakete (`audittrail`, `cutoverstage`, `crypto`) bleiben modul-lokal.
Dasselbe Prinzip gilt auch innerhalb eines Moduls, auf Code-Ebene: Hauptdateien/Entry-Points bleiben klein, Fachlogik wandert in eigene Module. Vor einer neuen Funktions-/Modul-Datei wird geprüft, ob dieselbe Funktionalität nicht schon woanders existiert (auch modulübergreifend, z. B. in Core) — keine doppelten Funktionsdateien. Das eigene Kanban-Planungswerkzeug wurde nach genau diesem Muster korrigiert (sieben `kanban.html` enthielten identisches JS/CSS als Volltext-Duplikat, damals in `_shared/kanban.js`/`kanban.css` ausgelagert) — die Boards selbst sind inzwischen komplett aus dem Repo entfernt (Ticket-Historie liegt in der Gitea-PR-Historie), das Prinzip "keine doppelten Funktionsdateien" gilt unverändert für den eigentlichen NEXARCH-Code.
## 6. Technische Architektur (Kurzfassung, Details in eigenen Dokumenten)
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:
- **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).
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
Fehlgeschlagener Versand wird protokolliert und nicht stillschweigend verworfen"
CMP-01,GoBD-Verfahrensdokumentation,⚖️ Compliance & eDiscovery,Backend,Mittel,3,2,Fertig,"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,Fertig,"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,Fertig,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,Fertig,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,Fertig,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,Fertig,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,Fertig,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,Fertig,"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,Fertig,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,Fertig,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,Fertig,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,Fertig,"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,Fertig,"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)
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,Fertig,"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,Fertig,"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
BAK-09,Envelope-Encryption für Backup-Snapshots (Datenbank & Objekt-Storage),💾 Backup & Wiederherstellung,Backend,Mittel,2,7,Fertig,"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,Fertig,"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"
RET-15,Echter End-zu-Ende-Nachweis Storage-Object-Lock auf chattr-fähigem Host,⏳ Retention & WORM,Backend,Einfach,1,9,Backlog,,,,,chattr-faehiger Host/Alternative identifiziert; Loeschversuch auf storage-gesperrtes Objekt schlaegt nachweislich fehl; Ergebnis als Nachtrag zu RET-11 dokumentiert,Test auf identifiziertem Host durchgefuehrt; falls kein Host verfuegbar begruendete Dokumentation
RET-16,STORAGE-KONZEPT.md: Widerspruch ZFS als WORM-Backend klären,⏳ Retention & WORM,Backend,Einfach,0.5,9,Backlog,,,,,Ausnahmevermerk ZFS fuer WORM-Basisverzeichnis ergaenzt; Verweis auf RET-11-Pruefprotokoll; keine sonstigen Aenderungen,Dokument-Review; Diff-Pruefung
CMP-08,Ende-zu-Ende-Nachweis eDiscovery-Adapter (reale Drittmodul-Integration),⚖️ Compliance & eDiscovery,Backend,Mittel,2,9,Backlog,,,,,eDiscovery-Export gegen echte DMS-/Mail-Testinstanzen; Treffer korrekt und pruefsummengesichert; Nachtrag zu QA-03 dokumentiert,Echter Testlauf dokumentiert; Pruefsummen identisch; offene Restrisiken benannt
SEC-01,"Rolle muss aus verifizierter Identität kommen, nicht aus Client-Header",🔒 Sicherheit,Backend,Hoch,3,10,Backlog,"Go, bestehende Authentifizierungs-Infrastruktur (Session/JWT), Next.js (Frontend-Teil)",Rolle wird in retentionapi/kennzahlenapi/complianceapi aus X-User-Role-Header statt verifizierter Identität gelesen (K3); NEXT_PUBLIC_USER_ROLE im Frontend muss entfernt werden.,,SEC-02,"authz.go liest Rolle ausschliesslich aus verifizierter Identitaet (Session/JWT), X-User-Role wird ignoriert/abgelehnt
NEXT_PUBLIC_USER_ROLE aus compliance-reports und retention-admin Frontend entfernt
requested_by speichert nachvollziehbare Nutzeridentitaet statt nur Rollenname
CORS laesst Rollen-Header-basierte Cross-Origin-Zugriffe nicht mehr zu","Angriff mit gefaelschtem X-User-Role Header real nachgestellt und als blockiert nachgewiesen
Legitimer Aufruf mit echter Rolle aus verifizierter Session funktioniert weiterhin
Audit-Log enthaelt tatsaechliche Nutzeridentitaet
Frontend-Build enthaelt NEXT_PUBLIC_USER_ROLE nachweislich nicht mehr"
SEC-02,Tenant-Validierung in kennzahlenapi fehlt (Cross-Tenant-Leseleck),🔒 Sicherheit,Backend,Niedrig,1,10,Backlog,"Go, bestehendes InstanceTenant-Validierungsmuster aus legalholdapi.go","kennzahlenapi/handler.go:45 validiert den Query-Tenant nicht gegen InstanceTenant (H11), ermoeglicht Cross-Tenant-Lesen von Kennzahlen.",,,"handler.go validiert tenant Query-Parameter gegen InstanceTenant nach Muster aus legalholdapi.go
Abweichung fuehrt zu Ablehnung (403), kein stillschweigendes Ignorieren
Bestehende legitime Aufrufe funktionieren unveraendert","Angriff mit fremdem tenant Query-Parameter real nachgestellt und als blockiert nachgewiesen
Legitimer Aufruf mit eigenem tenant liefert weiterhin korrekte Daten
Musterkonsistenz mit legalholdapi.go dokumentiert"
SEC-03,TOCTOU Legal Hold vs. Destroy; Destroy ausserhalb der aeusseren Transaktion,🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"PostgreSQL, pgx/v5, atomare UPDATE-Bedingungen, Transaktionssteuerung","deletionworkflow.go prueft Legal Hold in separatem Query vor dem Loesch-UPDATE (TOCTOU, M1); deletionapproval.go ruft Destroy ausserhalb der aeusseren Transaktion auf.",,,"Legal-Hold-Pruefung ist Teil derselben atomaren UPDATE-Anweisung wie die Statusaenderung
Destroy() laeuft innerhalb derselben Transaktion wie die Antragsfinalisierung
Kein Codepfad mehr, in dem physische Vernichtung und DB-Zustand auseinanderlaufen","TOCTOU-Fenster real nachgestellt (Legal Hold zwischen Pruefung und Update gesetzt) und als blockiert nachgewiesen
Simulierter Fehler nach Destroy() vor Commit nachgestellt, Konsistenz nachgewiesen
Regulaerer Loeschvorgang ohne Hold und ohne Fehler funktioniert weiterhin"
SEC-04,"wormstore: Release/Destroy ohne Legal-Hold-Pruefung, Reihenfolge-Problem",🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"Go, Dateisystemoperationen, Zwei-Phasen-Commit-Muster, Pfad-Validierung","wormstore.go prueft bei Release/Destroy keinen Legal Hold, physische Operation erfolgt vor DB-Commit (M2); filepath.Join ohne Traversal-Check auf key.",,,"Release/Destroy pruefen vor Ausfuehrung aktiven Legal Hold und verweigern bei Treffer
Physische Operation erfolgt erst nach erfolgreichem DB-Commit bzw. Zwei-Phasen-Commit-Muster verhindert inkonsistenten Zwischenzustand
key wird gegen Pfad-Traversal validiert","Release/Destroy mit aktivem Legal Hold real nachgestellt und als blockiert nachgewiesen
Simulierter Absturz zwischen physischer Operation und Commit nachgestellt, kein inkonsistenter Zustand
Traversal-Angriff mit ../ Segmenten real nachgestellt und als blockiert nachgewiesen
Regulaerer Release/Destroy ohne Hold und ohne Traversal funktioniert weiterhin"
SEC-05,"moduleadapter /register: fehlende Tenant-Bindung, optionale Authentifizierung",🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"PostgreSQL, SQL-Migrationen (kein ORM), Go, bestehende Authentifizierungs-Middleware","UNIQUE(module_name, object_type) ohne Tenant-Spalte (M3) erlaubt Cross-Tenant-Kollision bei Registrierung; ALLOW_UNAUTHENTICATED=true schaltet Auth fuer /register und /legal-hold komplett ab.",,,"UNIQUE-Constraint umfasst Tenant-Spalte, zwei Mandanten koennen denselben module_name/object_type unabhaengig registrieren
Migration ueberfuehrt bestehende Registrierungen korrekt, ist rueckrollbar
ALLOW_UNAUTHENTICATED hat in keiner produktionsnahen Konfiguration Standardwert true
/register und /legal-hold verlangen bei deaktiviertem Schalter gueltige Authentifizierung","Cross-Tenant-Kollision bei Registrierung real nachgestellt, nach Fix bestehen beide Registrierungen unabhaengig
Migration vorwaerts und rueckwaerts gegen Datenbank mit bestehenden Testregistrierungen getestet
Aufruf ohne Authentifizierung bei deaktiviertem Schalter real nachgestellt und als blockiert nachgewiesen
SEC-06,Append-only-Luecken bei mehreren Archive-Tabellen,🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"PostgreSQL, SQL-Migrationen, bestehendes REVOKE/Trigger-Muster aus RET-11/AUD-07","legal_holds hat ON DELETE CASCADE, retention_class_assignments/dsgvo_decision_log/deletion_requests/worm_objects haben trotz Append-only-Anspruch kein DB-seitiges REVOKE/Trigger (M4).",,,"legal_holds verwendet ON DELETE RESTRICT oder eigene Historisierung statt CASCADE
Betroffene vier Tabellen erhalten REVOKE UPDATE/DELETE von App-Rolle plus Trigger mit RAISE WARNING nach RET-11/AUD-07-Muster
Bestehender Code mit UPDATE/DELETE auf worm_objects auf Insert-only-Logik umgestellt","Direkter UPDATE/DELETE-Versuch auf allen vier Tabellen real nachgestellt und als blockiert/protokolliert nachgewiesen
Loeschen eines Objekts mit aktivem Legal Hold real nachgestellt, Kaskaden-Verlust des Hold-Nachweises verhindert
Migration vorwaerts und rueckwaerts gegen Datenbank mit Testdaten getestet
Umgestellter Anwendungscode fuer worm_objects mit regulaerem Statuswechsel-Testfall erfolgreich durchlaufen"
1
Code
Titel
Epic
Rolle
Komplexitaet
Aufwand_PT
Welle
Status
Technik
Beschreibung
Haengt_ab_von
Schaltet_frei
Akzeptanzkriterien
Pruefungen
2
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
3
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
4
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
5
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
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
7
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
8
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
9
CMP-01
GoBD-Verfahrensdokumentation
⚖️ Compliance & eDiscovery
Backend
Mittel
3
2
Fertig
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
10
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
11
CMP-03
eDiscovery-Suche & Export (modulübergreifend)
⚖️ Compliance & eDiscovery
Backend
Komplex
4
3
Fertig
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
12
CMP-04
Audit-Trail-Kopplung an Core-Audit-Log
⚖️ Compliance & eDiscovery
Backend
Einfach
2
1
Fertig
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
13
CMP-05
Compliance-Berichts-Oberfläche
⚖️ Compliance & eDiscovery
Frontend
Mittel
3
3
Fertig
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
14
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
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
16
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
17
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
18
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
19
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
20
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
21
ANA-01
Kennzahlen-Aggregation (modulübergreifend)
📊 Kennzahlen & Reporting
Backend
Mittel
3
3
Fertig
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
22
ANA-02
Auswertungs-Dashboard
📊 Kennzahlen & Reporting
Frontend
Mittel
3
4
Fertig
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
23
ANA-03
Lizenz-/Nutzungs-Reports
📊 Kennzahlen & Reporting
Backend
Einfach
2
4
Fertig
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
24
QA-01
Teststrategie Archive
✅ Prüfungen & Qualitätssicherung
Backend
Einfach
2
1
Fertig
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)
25
QA-02
Prüfgate Retention & WORM
✅ Prüfungen & Qualitätssicherung
Backend
Einfach
2
4
Fertig
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
26
QA-03
Prüfgate Compliance & eDiscovery
✅ Prüfungen & Qualitätssicherung
Backend
Einfach
2
5
Fertig
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
27
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
28
QA-05
Abnahme- & Compliance-Prüfung Archive
✅ Prüfungen & Qualitätssicherung
Backend
Einfach
2
6
Fertig
Abnahmeprotokoll
Gesamtabnahme des Archive-Boards vor Freigabe: Retention/WORM, Compliance/eDiscovery und Backup/Restore müssen alle bestanden sein.
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
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
30
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
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
32
QA-07
Last- & Leistungstest
✅ Prüfungen & Qualitätssicherung
Backend
Mittel
3
6
Fertig
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
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
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
35
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)
36
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
37
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)
38
RET-11
Storage-seitige WORM-Durchsetzung (Object-Lock statt nur Anwendungslogik)
⏳ Retention & WORM
Backend
Mittel
2
7
Fertig
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
39
RET-12
Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail
⏳ Retention & WORM
Backend
Mittel
2
7
Fertig
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
40
BAK-09
Envelope-Encryption für Backup-Snapshots (Datenbank & Objekt-Storage)
💾 Backup & Wiederherstellung
Backend
Mittel
2
7
Fertig
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
41
BAK-10
Schutzniveau der Restore-Testumgebung (DSGVO-konform)
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
42
RET-15
Echter End-zu-Ende-Nachweis Storage-Object-Lock auf chattr-fähigem Host
⏳ Retention & WORM
Backend
Einfach
1
9
Backlog
chattr-faehiger Host/Alternative identifiziert; Loeschversuch auf storage-gesperrtes Objekt schlaegt nachweislich fehl; Ergebnis als Nachtrag zu RET-11 dokumentiert
Test auf identifiziertem Host durchgefuehrt; falls kein Host verfuegbar begruendete Dokumentation
43
RET-16
STORAGE-KONZEPT.md: Widerspruch ZFS als WORM-Backend klären
⏳ Retention & WORM
Backend
Einfach
0.5
9
Backlog
Ausnahmevermerk ZFS fuer WORM-Basisverzeichnis ergaenzt; Verweis auf RET-11-Pruefprotokoll; keine sonstigen Aenderungen
Rolle wird in retentionapi/kennzahlenapi/complianceapi aus X-User-Role-Header statt verifizierter Identität gelesen (K3); NEXT_PUBLIC_USER_ROLE im Frontend muss entfernt werden.
SEC-02
authz.go liest Rolle ausschliesslich aus verifizierter Identitaet (Session/JWT), X-User-Role wird ignoriert/abgelehnt
NEXT_PUBLIC_USER_ROLE aus compliance-reports und retention-admin Frontend entfernt
requested_by speichert nachvollziehbare Nutzeridentitaet statt nur Rollenname
CORS laesst Rollen-Header-basierte Cross-Origin-Zugriffe nicht mehr zu
Angriff mit gefaelschtem X-User-Role Header real nachgestellt und als blockiert nachgewiesen
Legitimer Aufruf mit echter Rolle aus verifizierter Session funktioniert weiterhin
Audit-Log enthaelt tatsaechliche Nutzeridentitaet
Frontend-Build enthaelt NEXT_PUBLIC_USER_ROLE nachweislich nicht mehr
46
SEC-02
Tenant-Validierung in kennzahlenapi fehlt (Cross-Tenant-Leseleck)
🔒 Sicherheit
Backend
Niedrig
1
10
Backlog
Go, bestehendes InstanceTenant-Validierungsmuster aus legalholdapi.go
kennzahlenapi/handler.go:45 validiert den Query-Tenant nicht gegen InstanceTenant (H11), ermoeglicht Cross-Tenant-Lesen von Kennzahlen.
handler.go validiert tenant Query-Parameter gegen InstanceTenant nach Muster aus legalholdapi.go
Abweichung fuehrt zu Ablehnung (403), kein stillschweigendes Ignorieren
Bestehende legitime Aufrufe funktionieren unveraendert
Angriff mit fremdem tenant Query-Parameter real nachgestellt und als blockiert nachgewiesen
Legitimer Aufruf mit eigenem tenant liefert weiterhin korrekte Daten
Musterkonsistenz mit legalholdapi.go dokumentiert
47
SEC-03
TOCTOU Legal Hold vs. Destroy; Destroy ausserhalb der aeusseren Transaktion
deletionworkflow.go prueft Legal Hold in separatem Query vor dem Loesch-UPDATE (TOCTOU, M1); deletionapproval.go ruft Destroy ausserhalb der aeusseren Transaktion auf.
Legal-Hold-Pruefung ist Teil derselben atomaren UPDATE-Anweisung wie die Statusaenderung
Destroy() laeuft innerhalb derselben Transaktion wie die Antragsfinalisierung
Kein Codepfad mehr, in dem physische Vernichtung und DB-Zustand auseinanderlaufen
TOCTOU-Fenster real nachgestellt (Legal Hold zwischen Pruefung und Update gesetzt) und als blockiert nachgewiesen
Simulierter Fehler nach Destroy() vor Commit nachgestellt, Konsistenz nachgewiesen
Regulaerer Loeschvorgang ohne Hold und ohne Fehler funktioniert weiterhin
48
SEC-04
wormstore: Release/Destroy ohne Legal-Hold-Pruefung, Reihenfolge-Problem
wormstore.go prueft bei Release/Destroy keinen Legal Hold, physische Operation erfolgt vor DB-Commit (M2); filepath.Join ohne Traversal-Check auf key.
Release/Destroy pruefen vor Ausfuehrung aktiven Legal Hold und verweigern bei Treffer
Physische Operation erfolgt erst nach erfolgreichem DB-Commit bzw. Zwei-Phasen-Commit-Muster verhindert inkonsistenten Zwischenzustand
key wird gegen Pfad-Traversal validiert
Release/Destroy mit aktivem Legal Hold real nachgestellt und als blockiert nachgewiesen
Simulierter Absturz zwischen physischer Operation und Commit nachgestellt, kein inkonsistenter Zustand
Traversal-Angriff mit ../ Segmenten real nachgestellt und als blockiert nachgewiesen
Regulaerer Release/Destroy ohne Hold und ohne Traversal funktioniert weiterhin
UNIQUE(module_name, object_type) ohne Tenant-Spalte (M3) erlaubt Cross-Tenant-Kollision bei Registrierung; ALLOW_UNAUTHENTICATED=true schaltet Auth fuer /register und /legal-hold komplett ab.
UNIQUE-Constraint umfasst Tenant-Spalte, zwei Mandanten koennen denselben module_name/object_type unabhaengig registrieren
Migration ueberfuehrt bestehende Registrierungen korrekt, ist rueckrollbar
ALLOW_UNAUTHENTICATED hat in keiner produktionsnahen Konfiguration Standardwert true
/register und /legal-hold verlangen bei deaktiviertem Schalter gueltige Authentifizierung
Cross-Tenant-Kollision bei Registrierung real nachgestellt, nach Fix bestehen beide Registrierungen unabhaengig
Migration vorwaerts und rueckwaerts gegen Datenbank mit bestehenden Testregistrierungen getestet
Aufruf ohne Authentifizierung bei deaktiviertem Schalter real nachgestellt und als blockiert nachgewiesen
Bestehende authentifizierte Registrierungsablaeufe funktionieren weiterhin
50
SEC-06
Append-only-Luecken bei mehreren Archive-Tabellen
🔒 Sicherheit
Backend
Mittel
2
10
Backlog
PostgreSQL, SQL-Migrationen, bestehendes REVOKE/Trigger-Muster aus RET-11/AUD-07
legal_holds hat ON DELETE CASCADE, retention_class_assignments/dsgvo_decision_log/deletion_requests/worm_objects haben trotz Append-only-Anspruch kein DB-seitiges REVOKE/Trigger (M4).
legal_holds verwendet ON DELETE RESTRICT oder eigene Historisierung statt CASCADE
Betroffene vier Tabellen erhalten REVOKE UPDATE/DELETE von App-Rolle plus Trigger mit RAISE WARNING nach RET-11/AUD-07-Muster
Bestehender Code mit UPDATE/DELETE auf worm_objects auf Insert-only-Logik umgestellt
Direkter UPDATE/DELETE-Versuch auf allen vier Tabellen real nachgestellt und als blockiert/protokolliert nachgewiesen
Loeschen eines Objekts mit aktivem Legal Hold real nachgestellt, Kaskaden-Verlust des Hold-Nachweises verhindert
Migration vorwaerts und rueckwaerts gegen Datenbank mit Testdaten getestet
Umgestellter Anwendungscode fuer worm_objects mit regulaerem Statuswechsel-Testfall erfolgreich durchlaufen
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Zentraler Dienst, der Kennzahlen (Objektbestand, Aufbewahrungsstatus, Löschvorgänge, Speichervolumen) aus allen über RET-05 registrierten Modulen aggregiert.
**Technische Grundlage:** Aggregations-Job über registrierte Module
## Produkt-DNA für diesen Bereich
> Kennzahlen modulübergreifend an einer Stelle, nicht in jedem Modul einzeln nachgebaut.
**Übernehmen:**
- Ein Aggregationsdienst für Kennzahlen aus DMS, Mail und Archive statt Silo-Reports je Modul.
- Dashboard mit Facetten und Filtern statt starrer Report-Vorlagen.
**Bewusst vermeiden:**
- Keine Kennzahlenlogik, die doppelt in DMS und Mail gepflegt werden muss.
**Für genau diese Kachel:** Eine Aggregationsstelle für alle Module – DMS und Mail bauen keine eigene Kennzahlenlogik mehr.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Kennzahlen werden je Tenant und Modul sowie modulübergreifend aggregiert
2. Aggregation läuft periodisch und liefert konsistente Werte über einen Zeitverlauf
3. Neues registriertes Modul wird ohne Codeänderung in die Aggregation einbezogen
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Aggregation über zwei fiktive Module liefert korrekte Summen- und Einzelwerte
2. Wiederholte Aggregation ohne Datenänderung liefert stabile Ergebnisse
3. Neu registriertes drittes Testmodul erscheint automatisch in der nächsten Aggregation
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`ANA-02` Auswertungs-Dashboard
-`ANA-03` Lizenz-/Nutzungs-Reports
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Oberfläche und Bedienbarkeit. Ruft ausschließlich vorhandene Schnittstellen auf, keine eigene Geschäftslogik.
## Auftrag
Dashboard zur Visualisierung der aggregierten Kennzahlen mit Filtern nach Tenant, Modul und Zeitraum.
> Kennzahlen modulübergreifend an einer Stelle, nicht in jedem Modul einzeln nachgebaut.
**Übernehmen:**
- Ein Aggregationsdienst für Kennzahlen aus DMS, Mail und Archive statt Silo-Reports je Modul.
- Dashboard mit Facetten und Filtern statt starrer Report-Vorlagen.
**Bewusst vermeiden:**
- Keine Kennzahlenlogik, die doppelt in DMS und Mail gepflegt werden muss.
**Für genau diese Kachel:** Kennzahlen ohne Dashboard bleiben Rohdaten – erst die Visualisierung macht sie für Fachanwender nutzbar.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`ANA-01` Kennzahlen-Aggregation (modulübergreifend) – Zentraler Dienst, der Kennzahlen (Objektbestand, Aufbewahrungsstatus, Löschvorgänge, Speichervolumen) aus allen über RET-05 registrierten Modulen aggregiert.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Dashboard zeigt Bestands-, Aufbewahrungs- und Löschkennzahlen je Tenant
2. Filter nach Modul und Zeitraum funktionieren kombinierbar
3. Dashboard lädt auch bei großem Datenbestand in angemessener Zeit
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Filterkombination liefert dieselben Werte wie eine direkte Abfrage der Aggregation
2. Dashboard mit synthetisch großem Testbestand bleibt bedienbar
3. Rollen ohne Berechtigung sehen keine Kennzahlen fremder Tenants
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Bericht über Nutzung und Lizenzrelevantes je Tenant (Speichervolumen, aktive Objekte, Nutzeranzahl-Bezug), abgestimmt mit dem Lizenzmodell aus NEXARCH Core.
**Technische Grundlage:** CSV/PDF-Export
## Produkt-DNA für diesen Bereich
> Kennzahlen modulübergreifend an einer Stelle, nicht in jedem Modul einzeln nachgebaut.
**Übernehmen:**
- Ein Aggregationsdienst für Kennzahlen aus DMS, Mail und Archive statt Silo-Reports je Modul.
- Dashboard mit Facetten und Filtern statt starrer Report-Vorlagen.
**Bewusst vermeiden:**
- Keine Kennzahlenlogik, die doppelt in DMS und Mail gepflegt werden muss.
**Für genau diese Kachel:** Lizenzrelevante Nutzungswerte gehören sauber belegt vorzuliegen, statt bei Bedarf händisch aus Rohdaten geschätzt zu werden.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`ANA-01` Kennzahlen-Aggregation (modulübergreifend) – Zentraler Dienst, der Kennzahlen (Objektbestand, Aufbewahrungsstatus, Löschvorgänge, Speichervolumen) aus allen über RET-05 registrierten Modulen aggregiert.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Bericht zeigt lizenzrelevante Nutzungswerte je Tenant für einen wählbaren Zeitraum
2. Werte stimmen mit der zugrunde liegenden Kennzahlen-Aggregation überein
3. Export ist als CSV und PDF verfügbar
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Bericht für Testzeitraum stimmt mit manuell nachgerechneten Werten überein
2. Export in beiden Formaten enthält identische Kernwerte
3. Bericht für Tenant ohne Aktivität liefert nachvollziehbar leere/Null-Werte statt Fehler
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Automatisierte, inkrementelle Sicherung der PostgreSQL-Datenbank mit Aufbewahrung mehrerer Generationen und Verifikation jeder Sicherung.
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Ohne verifizierte Sicherung ist jede spätere Wiederherstellung reine Hoffnung – die Verifikation ist deshalb Pflichtbestandteil, nicht Kür.
## Ausgangslage
Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Vollsicherung und inkrementelle Sicherung laufen automatisiert nach Zeitplan
2. Jede Sicherung wird nach Abschluss auf Lesbarkeit verifiziert, nicht nur auf Erstellung geprüft
3. Mehrere Sicherungsgenerationen werden nach konfigurierbarer Regel vorgehalten und alte automatisch entfernt
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Sicherung gegen Testdatenbank erfolgreich erstellt und verifiziert
2. Verifikation erkennt eine absichtlich beschädigte Sicherungsdatei
3. Rotationsregel entfernt nachweislich nur die ältesten Generationen
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`BAK-03` Restore-Verfahren
-`BAK-05` Reconciliation (Konsistenzprüfung Storage vs. DB)
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Automatisierte, deduplizierende Sicherung der im Objekt-Storage abgelegten Dateiinhalte, angelehnt an das restic/Borg-Sicherungskonzept.
**Technische Grundlage:** Objekt-Storage-Snapshots, inkrementell und deduplizierend
## Produkt-DNA für diesen Bereich
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Inkrementell und deduplizierend wie restic/Borg – Sicherungsvolumen und -dauer bleiben auch bei großen Beständen beherrschbar.
## Ausgangslage
Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Sicherung erfasst neue und geänderte Objekte inkrementell, ohne unveränderte Objekte erneut zu übertragen
2. Sicherung ist deduplizierend, identische Inhalte werden nur einmal gespeichert
3. Jede Sicherung lässt sich einzeln auf Vollständigkeit prüfen
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Zweiter Sicherungslauf nach unverändertem Bestand überträgt keine Daten erneut
2. Zwei identische Testdateien belegen nachweislich nur einmal Speicherplatz
3. Vollständigkeitsprüfung erkennt ein fehlendes Objekt in der Sicherung
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`BAK-03` Restore-Verfahren
-`BAK-05` Reconciliation (Konsistenzprüfung Storage vs. DB)
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Dokumentiertes, wiederholbares Verfahren zur Wiederherstellung von Datenbank und Objekt-Storage aus einer Sicherung, für Notfall wie für Einzelobjekt-Restore.
**Technische Grundlage:** Atomarer Restore über temporäres Verzeichnis
## Produkt-DNA für diesen Bereich
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Restore ist das eigentliche Produkt einer Sicherung – eine Sicherung ohne funktionierenden Restore ist wertlos.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-01` Datenbank-Backup-Strategie – Automatisierte, inkrementelle Sicherung der PostgreSQL-Datenbank mit Aufbewahrung mehrerer Generationen und Verifikation jeder Sicherung.
-`BAK-02` Objekt-Storage-Backup/Snapshots – Automatisierte, deduplizierende Sicherung der im Objekt-Storage abgelegten Dateiinhalte, angelehnt an das restic/Borg-Sicherungskonzept.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Restore stellt Datenbank und Objekt-Storage aus einer gewählten Sicherungsgeneration wieder her
2. Restore in ein nicht-leeres Zielverzeichnis beschädigt den bestehenden Inhalt nicht, solange der Vorgang nicht bestätigt wird
3. Restore-Vorgang wird protokolliert (Quelle, Zeitpunkt, Ergebnis)
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Restore auf leerem System vollständig und erfolgreich durchgeführt
2. Restore auf nicht-leeres Zielverzeichnis lässt bei Abbruch den ursprünglichen Inhalt unverändert
3. Protokolleintrag zum Restore ist vollständig und nachvollziehbar
## Bekannte Fehler vermeiden
Aus einem bereits produktiven Schwestersystem bekannt: Restore in ein nicht-leeres Zielverzeichnis kann den bestehenden Inhalt beschädigen, wenn nicht atomar vorgegangen wird (`cmd_backup.go:206`, Bug-Klasse „-force restore where destination isn't empty“). Restore deshalb immer in ein leeres temporäres Verzeichnis schreiben und erst danach per atomarem Swap (z. B. Verzeichnis-Rename) an die Zielstelle bringen. Niemals direkt in ein belegtes Zielverzeichnis hineinschreiben.
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Sicherung und Wiederherstellung der Daten eines einzelnen Mandanten, ohne andere Mandanten zu berühren – etwa für Mandanten-Umzug oder isolierte Notfallwiederherstellung.
**Technische Grundlage:** Tenant-scharfer Export/Import auf Basis von BAK-03
## Produkt-DNA für diesen Bereich
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Ein Mandant will manchmal umziehen oder isoliert wiederhergestellt werden, ohne dass alle anderen Mandanten betroffen sind.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-03` Restore-Verfahren – Dokumentiertes, wiederholbares Verfahren zur Wiederherstellung von Datenbank und Objekt-Storage aus einer Sicherung, für Notfall wie für Einzelobjekt-Restore.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Sicherung eines Tenants enthält ausschließlich dessen Daten aus Datenbank und Objekt-Storage
2. Wiederherstellung eines Tenants verändert keine Daten anderer Tenants
3. Tenant-Sicherung lässt sich unabhängig vom Gesamt-Backup planen und ausführen
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Sicherung von Tenant A enthält keine Datensätze von Tenant B (Stichprobe)
2. Wiederherstellung von Tenant A in eine Testumgebung verändert Tenant B dort nicht
3. Tenant-Sicherung und -Restore vollständig protokolliert
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Periodische Prüfung, ob jeder in der Datenbank referenzierte Objekt-Storage-Eintrag tatsächlich existiert und umgekehrt, mit Bericht über Abweichungen.
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Sicherung und Datenbank laufen über Jahre leicht auseinander – Reconciliation macht diesen stillen Drift sichtbar, bevor ein Restore daran scheitert.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-01` Datenbank-Backup-Strategie – Automatisierte, inkrementelle Sicherung der PostgreSQL-Datenbank mit Aufbewahrung mehrerer Generationen und Verifikation jeder Sicherung.
-`BAK-02` Objekt-Storage-Backup/Snapshots – Automatisierte, deduplizierende Sicherung der im Objekt-Storage abgelegten Dateiinhalte, angelehnt an das restic/Borg-Sicherungskonzept.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Job erkennt Datenbankeinträge ohne zugehöriges Objekt im Storage
2. Job erkennt Objekte im Storage ohne zugehörigen Datenbankeintrag
3. Abweichungen werden berichtet, nicht automatisch stillschweigend behoben
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Absichtlich entferntes Storage-Objekt wird vom Job als Abweichung erkannt
2. Absichtlich verwaister Datenbankeintrag wird vom Job als Abweichung erkannt
3. Lauf ohne Abweichungen liefert einen leeren, eindeutig als sauber erkennbaren Bericht
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Regelmäßiger, automatisierter Testlauf des Restore-Verfahrens gegen eine isolierte Testumgebung, mit Ergebnisprotokoll als Nachweis der Wiederherstellbarkeit.
**Technische Grundlage:** Automatisierter, periodischer Restore-Test in Testumgebung
## Produkt-DNA für diesen Bereich
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- 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.
**Bewusst 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.
**Für genau diese Kachel:** Eine Sicherung gilt erst als geprüft, wenn ihr Restore regelmäßig und automatisiert getestet wird – nicht nur einmal beim Einrichten.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-03` Restore-Verfahren – Dokumentiertes, wiederholbares Verfahren zur Wiederherstellung von Datenbank und Objekt-Storage aus einer Sicherung, für Notfall wie für Einzelobjekt-Restore.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Testlauf führt einen vollständigen Restore in eine isolierte Testumgebung durch
2. Ergebnis (erfolgreich/fehlgeschlagen) wird mit Zeitstempel protokolliert
3. Fehlgeschlagener Testlauf löst eine sichtbare Warnung aus
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Geplanter Testlauf gegen aktuelle Sicherung erfolgreich durchgeführt und protokolliert
2. Absichtlich beschädigte Sicherung lässt den Testlauf sichtbar fehlschlagen
3. Protokollhistorie zeigt mehrere zurückliegende Testläufe nachvollziehbar an
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-04` Prüfgate Backup & Restore
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
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.
**Technische Grundlage:** PostgreSQL, Postgres-Jobqueue (geplante Jobs statt Redis)
## Produkt-DNA für diesen Bereich
> Sicherung nach dem Vorbild von restic/Borg: inkrementell, deduplizierend, verifizierbar.
**Übernehmen:**
- restic/Borg: Inkrementelle, deduplizierende Sicherung mit Verifikation jeder Sicherung.
- restic/Borg: eigene, konfigurierbare Prune-Policy für die Aufbewahrung der Sicherungen selbst (Staffelung nach Alter).
- Reconciliation zwischen Objekt-Storage und Datenbank als eigenständige, planbare Prüfung.
**Bewusst vermeiden:**
- Backup-Aufbewahrung mit der Dokumenten-Retention (RET-02) zu verwechseln ist ein Kategorienfehler – ein Dokument kann 10 Jahre aufbewahrungspflichtig sein, während die tägliche Backup-Kopie davon nur 14 Tage vorgehalten werden muss, weil die nächste Kopie sie ohnehin ersetzt. Beide Fristen sind unabhängig konfigurierbar, nicht gekoppelt.
- Kein Pruning, das den letzten verbliebenen Snapshot eines noch unter Aufbewahrungssperre (Legal Hold) stehenden Dokuments entfernt, solange kein aktuellerer Snapshot dieses Dokument enthält.
**Für genau diese Kachel:** Ohne eigene Prune-Policy wachsen Backups unbegrenzt oder werden willkürlich gelöscht – die Frist für die Sicherung selbst ist eine andere Frist als die für das gesicherte Dokument.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-01` Datenbank-Backup-Strategie – Automatisierte, inkrementelle Sicherung der PostgreSQL-Datenbank mit Aufbewahrung mehrerer Generationen und Verifikation jeder Sicherung.
-`BAK-02` Objekt-Storage-Backup/Snapshots – Automatisierte, deduplizierende Sicherung der im Objekt-Storage abgelegten Dateiinhalte.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Backup-Snapshots folgen einer konfigurierbaren Prune-Policy (Staffelung nach Alter), unabhängig von RET-02
2. Snapshot-Löschung nach Ablauf der Frist läuft automatisiert
3. 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
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Prune-Test mit simulierten Snapshots über mehrere Altersstufen ergibt korrekte Staffelung
2. Automatisierte Löschung abgelaufener Snapshots im Test nachgewiesen
3. Legal-Hold-Test bestätigt, dass Pruning nicht mit Dokumenten-Retention kollidiert
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
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.
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.
- 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.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Exportierbare Verfahrensdokumentation gemäß GoBD: Beschreibung der Aufbewahrungs-, Zugriffs- und Löschverfahren, automatisch aus der aktuellen Konfiguration erzeugt.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Berichte für Auskunftsersuchen, Verarbeitungsübersichten und Zugriffsnachweise je betroffener Person und Tenant.
**Technische Grundlage:** PDF/CSV-Export
## Produkt-DNA für diesen Bereich
> Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.
**Übernehmen:**
- 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.
- Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf.
**Für genau diese Kachel:** Auskunftsersuchen unter Fristdruck sind der Härtetest – ohne fertigen Bericht wird jede Anfrage zur manuellen Notoperation.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-01` Generisches Retention-Objektmodell – Generisches Datenmodell für aufbewahrungspflichtige Objekte anlegen: Objekttyp, Objekt-Referenz (modulübergreifend über Adapter), Aufbewahrungsklasse, Status. Migrationen versioniert und rückrollbar.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Auskunftsbericht listet alle gespeicherten Objekte einer betroffenen Person mit Aufbewahrungsklasse
2. Verarbeitungsübersicht zeigt Zweck und Rechtsgrundlage je Objekttyp
3. Export ist mandantenscharf und enthält keine Daten anderer Tenants
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Auskunftsbericht für Testperson mit bekanntem Datenbestand stimmt mit erwarteter Liste überein
2. Bericht für einen Tenant enthält keine Objekte eines anderen Tenants
3. Export lässt sich als CSV weiterverarbeiten
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`CMP-05` Compliance-Berichts-Oberfläche
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Suche über registrierte Objekttypen aus DMS und Mail hinweg für Rechtsverfahren, mit vollständigem, prüfsummengesichertem Export der Treffer.
**Technische Grundlage:** Modulübergreifende Such-API, ZIP-Export mit Prüfsummen
## Produkt-DNA für diesen Bereich
> Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.
**Übernehmen:**
- 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.
- Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf.
**Für genau diese Kachel:** eDiscovery ist der Beweis, dass die Modul-Adapter-Schnittstelle trägt: eine Suche, viele Module, ein rechtssicherer Export.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Suche liefert Treffer aus mehreren registrierten Modulen in einer gemeinsamen Ergebnisliste
2. Export enthält Originalobjekte, Metadaten und eine Prüfsummenliste je Datei
3. Suchlauf und Export werden als eigener Vorgang protokolliert (wer, wann, welche Kriterien)
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Testsuche über zwei fiktive Module liefert erwartete kombinierte Trefferzahl
2. Prüfsumme jeder exportierten Datei stimmt nach Entpacken überein
3. Protokolleintrag zum Suchlauf ist nachträglich nicht veränderbar
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-03` Prüfgate Compliance & eDiscovery
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
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.
**Technische Grundlage:** REST-Anbindung an NEXARCH Core Audit-Log
## Produkt-DNA für diesen Bereich
> Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.
**Übernehmen:**
- 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.
- Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf.
**Für genau diese Kachel:** Ein zentrales Audit-Log statt eines eigenen – Archive dupliziert keine Protokoll-Infrastruktur, die es in Core bereits gibt.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
- Core `AUD-01` Zentrales Audit-Log-Modell – Zentrales Audit-Log-Datenmodell für sicherheits- und compliancerelevante Ereignisse (wer, was, wann, an welchem Tenant) als eigenständiges Modell getrennt vom Anwendungs-Log.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Jeder sicherheitsrelevante Vorgang erzeugt einen Eintrag im zentralen Audit-Log
2. Eintrag enthält Tenant, handelnde Person, Vorgang und Zeitstempel
3. Ausfall des Audit-Log-Dienstes blockiert nicht den Fachvorgang, wird aber sichtbar nachgemeldet
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Testvorgänge (Sperre setzen, Löschung, Export) erzeugen je einen nachvollziehbaren Audit-Eintrag
2. Simulierter Ausfall des Audit-Dienstes verhindert nicht die Fachfunktion
3. Nachmeldung nach Ausfallende ist vollständig, keine Lücke im Protokoll
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Oberfläche und Bedienbarkeit. Ruft ausschließlich vorhandene Schnittstellen auf, keine eigene Geschäftslogik.
## Auftrag
Oberfläche zum Anfordern, Einsehen und Herunterladen von GoBD-Verfahrensdokumentation und DSGVO-Berichten je Tenant.
- Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf.
**Für genau diese Kachel:** Ohne Oberfläche bleiben GoBD- und DSGVO-Berichte Kommandozeilen-Werkzeug für Entwickler statt Alltagswerkzeug für Prüfer.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`CMP-01` GoBD-Verfahrensdokumentation – Exportierbare Verfahrensdokumentation gemäß GoBD: Beschreibung der Aufbewahrungs-, Zugriffs- und Löschverfahren, automatisch aus der aktuellen Konfiguration erzeugt.
-`CMP-02` DSGVO-/Datenschutz-Berichte – Berichte für Auskunftsersuchen, Verarbeitungsübersichten und Zugriffsnachweise je betroffener Person und Tenant.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Berichte lassen sich mit wenigen Klicks anfordern und herunterladen
2. Nur berechtigte Rollen sehen Berichte anderer Personen ein
3. Historie angeforderter Berichte ist je Tenant einsehbar
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Anforderung eines Berichts löst den zugehörigen Backend-Export korrekt aus
2. Nicht berechtigte Rolle erhält keinen Zugriff auf fremde Berichte
3. Downloadlink eines abgelaufenen Berichts wird abgewiesen
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Löschung abgelaufener Objekte erfordert eine zweite, unabhängige Bestätigung durch eine andere Person, bevor der Löschworkflow ausgeführt wird.
**Technische Grundlage:** PostgreSQL mit FOR UPDATE-Lock, Timing-safe Vergleich
## Produkt-DNA für diesen Bereich
> Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.
**Übernehmen:**
- 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.
- Keine Berichte, die nur manuell zusammengestellt werden können – jeder Bericht ist ein Exportknopf.
**Für genau diese Kachel:** Vorbild: das Vier-Augen-Muster mit FOR UPDATE-Lock und zeitkonstantem Vergleich aus archivdms hat sich bewährt und wird hier als Standardlösung übernommen, statt es erneut zu erfinden.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Löschung wird erst nach zweiter Bestätigung durch eine von der anfordernden Person verschiedene Rolle ausgeführt
2. Gleichzeitige Bestätigungsversuche führen nicht zu doppelter Ausführung
3. Löschbestätigung wird mit einem geheimen, zeitlich begrenzten Bestätigungs-Token abgesichert
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Zwei parallele Bestätigungsanfragen auf dasselbe Objekt: genau eine Löschung wird ausgeführt (Lock-Test)
2. Bestätigung durch dieselbe Person wie die Anforderung wird abgewiesen
3. Vergleich des Bestätigungs-Tokens erfolgt zeitkonstant und ist gegen Timing-Angriffe getestet
## Vorbild aus bestehendem System
Ein bereits produktives Schwestersystem hat das Vier-Augen-Prinzip bei Löschbestätigung mit einem `FOR UPDATE`-Lock auf dem betroffenen Datensatz und einem zeitkonstanten (timing-safe) Vergleich des Bestätigungs-Tokens umgesetzt. Beides hat sich bewährt und wird hier als Vorbild übernommen: der Lock verhindert doppelte gleichzeitige Ausführung, der zeitkonstante Vergleich verhindert das Erraten des Tokens über Zeitmessung.
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-03` Prüfgate Compliance & eDiscovery
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Workflow für den Löschantrag einer betroffenen Person (Art. 17 DSGVO): modulübergreifende Suche nach allen zu dieser Person gespeicherten Objekten (wiederverwendet die Auskunfts-Suche aus `CMP-02`), Löschung jedes Objekts OHNE aktive Aufbewahrungspflicht (`RET-03` hat Vorrang), nachvollziehbare Ablehnung mit Begründung für jedes Objekt MIT Aufbewahrungspflicht, vollständiges Protokoll der Entscheidung je Objekt. Tatsächliche Vernichtung läuft über denselben Vier-Augen-Freigabeprozess wie jede andere Löschung (`CMP-06`), keine zweite Lösch-Implementierung.
**Technische Grundlage:** PostgreSQL, transaktionaler Zustandswechsel, Wiederverwendung der Modul-Adapter-Schnittstelle (`RET-05`)
## Produkt-DNA für diesen Bereich
> Nachweisführung wie ecoDMS, Vier-Augen-Prinzip wie Alfresco, aber schlank umgesetzt.
**Übernehmen:**
- 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.
**Bewusst vermeiden:**
- Ein Vorgänger-Projekt (archivmail) hat den DSGVO-Löschantrag ursprünglich als eigenständigen, von der übrigen Löschlogik getrennten Sonderpfad gebaut: ein Löschantrag ruft hier stattdessen denselben Löschworkflow (`RET-03`/`CMP-06`) auf wie jede andere Löschung – kein Duplikat der Aufbewahrungs-/Vier-Augen-Prüfung.
- Keine stille Teillöschung: ein Löschantrag mit gemischtem Ergebnis (teils gelöscht, teils wegen Aufbewahrungspflicht abgelehnt) macht das Ergebnis je Objekt einzeln nachvollziehbar, statt eine pauschale Sammelantwort zu liefern.
**Für genau diese Kachel:** Ein Löschantrag unter Fristdruck (DSGVO kennt hierfür i.d.R. eine Monatsfrist) ist der Härtetest für das Zusammenspiel von Aufbewahrungspflicht und Löschrecht – beides muss automatisiert und nachvollziehbar entschieden werden, nicht manuell pro Fall.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Rückruf-Mechanismus, über den Archive ein Modul beim Vernichten eines Objekts anspricht.
-`CMP-02` DSGVO-/Datenschutz-Berichte – modulübergreifende Suche nach allen Objekten einer betroffenen Person.
-`CMP-06` Vier-Augen-Freigabe für Löschungen – zweite, unabhängige Bestätigung vor tatsächlicher Vernichtung.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Löschantrag findet über die Suche aus `CMP-02` alle Objekte einer betroffenen Person, mandantenscharf
2. Jedes gefundene Objekt wird EINZELN entschieden: Löschung (keine Aufbewahrungspflicht) oder Ablehnung mit Begründung (aktive Aufbewahrungspflicht/Legal Hold aus `RET-03`) – niemals eine pauschale Sammelentscheidung
3. Tatsächliche Löschung durchläuft denselben Vier-Augen-Freigabeprozess wie jede andere Löschung (`CMP-06`), keine zweite Implementierung
4. Ergebnis des Löschantrags (je Objekt: gelöscht/abgelehnt+Grund) ist vollständig und dauerhaft 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. Löschantrag für eine Testperson mit gemischtem Datenbestand (ein Objekt ohne, ein Objekt mit aktiver Aufbewahrungspflicht) liefert exakt eine Löschung und eine begründete Ablehnung
2. Aufbewahrungssperre (Legal Hold) verhindert die Löschung nachweislich auch dann, wenn die reguläre Aufbewahrungsfrist bereits abgelaufen wäre
3. Löschantrag für einen Tenant führt nachweislich zu keiner Aktion an Objekten eines anderen Tenants
## Bekannte Fehler vermeiden
archivmail (Vorgängerprojekt) implementierte den DSGVO-Löschantrag ursprünglich als eigenständigen Workflow parallel zur regulären Aufbewahrungs-/Löschlogik – zwei Stellen, die dieselbe Aufbewahrungsregel auswerten, laufen bei Änderungen an einer Stelle auseinander. Diese Kachel ruft stattdessen ausschließlich `RET-03` (Aufbewahrungsprüfung) und `CMP-06` (Freigabe) auf, statt eine zweite Prüf-/Freigabelogik zu bauen.
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Die Suche nach Objekten einer Person selbst (`CMP-02`)
- Die eigentliche Aufbewahrungsprüfung (`RET-03`) und Freigabe (`CMP-06`)
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
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
QA-03 (Archive-Board, Prüfgate Compliance & eDiscovery) hat den eDiscovery-Export gegen den Referenzdatensatz real geprüft, aber den eDiscovery-Adapter zu DMS/Mail (die tatsächlichen Quellmodule der durchsuchten Objekte) nur fiktiv getestet (siehe QA-03-PRUEFPROTOKOLL.md, offene Restrisiken). Diese Kachel schließt die Lücke: ein echter Ende-zu-Ende-Testlauf, bei dem der eDiscovery-Export tatsächlich gegen laufende DMS- und Mail-Instanzen (nicht nur gegen Referenzdatensatz-Fixtures) durchgeführt wird.
**Technische Grundlage:** reale DMS-/Mail-Testinstanzen auf Host 204, bestehender Modul-Adapter-Mechanismus (RET-05)
## Ausgangslage
Setzt auf folgenden bereits fertigen Kacheln auf: `CMP-03` eDiscovery-Suche & Export, `QA-03` Prüfgate Compliance & eDiscovery (Archive-Board), `RET-05` Modul-Adapter-Schnittstelle.
## Akzeptanzkriterien
1. eDiscovery-Export wird gegen echte, über RET-05 registrierte DMS- und Mail-Testinstanzen durchgeführt (nicht nur gegen Referenzdatensatz-Fixtures)
2. Treffer aus beiden Modulen sind im Export korrekt vorhanden und prüfsummengesichert
3. Ergebnis ist als Nachtrag zu QA-03-PRUEFPROTOKOLL.md dokumentiert
## Prüfungen vor der Abnahme
1. Echter Testlauf gegen laufende DMS- und Mail-Instanz durchgeführt, Ergebnis dokumentiert
2. Export-Prüfsummen bei wiederholtem Testlauf identisch
3. Offene Restrisiken (falls neue gefunden) schriftlich benannt
## Nicht Bestandteil dieser Kachel
- Neue eDiscovery-Funktionalität (nur End-zu-Ende-Nachweis des bestehenden Adapters)
- RBAC-Rollenberechtigung der Vier-Augen-Freigabe (separates, bereits in QA-03 benanntes offenes Risiko)
## Arbeitsweise
1. Lies zuerst CMP-03, QA-03-PRUEFPROTOKOLL.md und RET-05 vollständig.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Teststrategie für das Archive-Board festlegen: Testebenen, Referenzdatensatz für Retention/WORM/Backup, Verantwortlichkeiten je Prüfgate.
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Prüfplan je Ausbaustufe mit abgelegtem, nachlesbarem Protokoll.
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf.
- Keine Prüfung nur auf dem Entwicklungsrechner mit synthetischen Testdaten.
**Für genau diese Kachel:** Ohne gemeinsame Teststrategie prüft jedes Prüfgate nach eigenem Gutdünken – das Fundament für vergleichbare Prüfergebnisse.
## Ausgangslage
Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Teststrategie benennt Testebenen (Unit, Integration, Wiederherstellungstest) und deren Verantwortliche
2. Referenzdatensatz für Retention- und Backup-Tests ist definiert und wiederverwendbar
3. Strategie ist als Dokument abgelegt und von zweiter Person gegengelesen
4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Referenzdatensatz lässt sich reproduzierbar in einer Testumgebung aufsetzen
2. Zweite Person bestätigt schriftlich die Nachvollziehbarkeit der Strategie
3. Strategie deckt erkennbar alle folgenden Prüfgates ab (Abgleich mit QA-02 bis QA-06)
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Prüfgate für Fristenengine, Löschworkflow, Aufbewahrungssperre und WORM-Garantie vor Freigabe der Retention-Funktionen.
**Technische Grundlage:** Abnahmeprotokoll
## Produkt-DNA für diesen Bereich
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Prüfplan je Ausbaustufe mit abgelegtem, nachlesbarem Protokoll.
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf.
- Keine Prüfung nur auf dem Entwicklungsrechner mit synthetischen Testdaten.
**Für genau diese Kachel:** Ein eigenes Gate für Retention und WORM, weil hier die Kernversprechen des gesamten Boards stehen und Wiederholungen unter Prüfbedingungen zählen.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-04` WORM-Speicher-Garantie (Append-only) – Speicherpfad für archivierte Objektinhalte, der nach dem Schreiben keine Änderung und kein Überschreiben mehr zulässt (Write Once, Read Many).
-`RET-06` Aufbewahrungsfristen-Konfigurationsoberfläche – Oberfläche zur Pflege von Aufbewahrungsklassen und Fristen je Objekttyp und Tenant, inklusive Vorschauliste bald ablaufender Objekte.
-`RET-07` Fristablauf-Benachrichtigungen – 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) – Archive erzeugt nur das Ereignis, versendet keine E-Mail selbst.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Alle Akzeptanzkriterien von RET-03 und RET-04 sind gegen den Referenzdatensatz nachgewiesen
2. Versuch, eine gesperrte oder WORM-geschützte Ablage zu umgehen, scheitert nachweislich
3. Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Löschversuch an gesperrtem Objekt schlägt fehl (Wiederholung des RET-03-Tests unter Prüfgate-Bedingungen)
2. Überschreibversuch am WORM-Speicher schlägt fehl (Wiederholung des RET-04-Tests unter Prüfgate-Bedingungen)
3. Offene Restrisiken sind schriftlich benannt
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-05` Abnahme- & Compliance-Prüfung Archive
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Prüfgate für eDiscovery-Export und Vier-Augen-Freigabe vor Freigabe der Compliance-Funktionen.
**Technische Grundlage:** Abnahmeprotokoll
## Produkt-DNA für diesen Bereich
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Prüfplan je Ausbaustufe mit abgelegtem, nachlesbarem Protokoll.
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf.
- Keine Prüfung nur auf dem Entwicklungsrechner mit synthetischen Testdaten.
**Für genau diese Kachel:** Compliance-Funktionen entscheiden im Ernstfall vor Gericht oder Aufsichtsbehörde – ein eigenes Gate stellt das vor Freigabe sicher.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`CMP-03` eDiscovery-Suche & Export (modulübergreifend) – Suche über registrierte Objekttypen aus DMS und Mail hinweg für Rechtsverfahren, mit vollständigem, prüfsummengesichertem Export der Treffer.
-`CMP-06` Vier-Augen-Freigabe für Löschungen – Löschung abgelaufener Objekte erfordert eine zweite, unabhängige Bestätigung durch eine andere Person, bevor der Löschworkflow ausgeführt wird.
-`CMP-07` DSGVO-Löschantrag (Recht auf Löschung, Art. 17) – 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.
-`CMP-01` GoBD-Verfahrensdokumentation – Exportierbare Verfahrensdokumentation gemäß GoBD: Beschreibung der Aufbewahrungs-, Zugriffs- und Löschverfahren, automatisch aus der aktuellen Konfiguration erzeugt.
-`CMP-04` Audit-Trail-Kopplung an 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.
-`CMP-05` Compliance-Berichts-Oberfläche – Oberfläche zum Anfordern, Einsehen und Herunterladen von GoBD-Verfahrensdokumentation und DSGVO-Berichten je Tenant.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. eDiscovery-Export wird gegen den Referenzdatensatz erneut durchgeführt und geprüft
2. Vier-Augen-Freigabe wird mit zwei unabhängigen Testrollen erneut nachgewiesen
3. Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Export-Prüfsummen stimmen bei wiederholtem Testlauf erneut überein
2. Löschversuch durch dieselbe Person ohne zweite Bestätigung scheitert erneut
3. Offene Restrisiken sind schriftlich benannt
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-05` Abnahme- & Compliance-Prüfung Archive
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Prüfgate für Backup-Strategie und Restore-Verfahren vor Freigabe der Backup-Funktionen, inklusive einem real durchgeführten Wiederherstellungstest.
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Prüfplan je Ausbaustufe mit abgelegtem, nachlesbarem Protokoll.
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf.
- Keine Prüfung nur auf dem Entwicklungsrechner mit synthetischen Testdaten.
**Für genau diese Kachel:** Backup ohne real durchgeführten Restore-Test ist eine unbelegte Behauptung – dieses Gate erzwingt den Beleg.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`BAK-06` Restore-Testverfahren – Regelmäßiger, automatisierter Testlauf des Restore-Verfahrens gegen eine isolierte Testumgebung, mit Ergebnisprotokoll als Nachweis der Wiederherstellbarkeit.
-`BAK-04` Tenant-Backup & -Restore (einzelner Mandant) – Sicherung und Wiederherstellung der Daten eines einzelnen Mandanten, ohne andere Mandanten zu berühren – etwa für Mandanten-Umzug oder isolierte Notfallwiederherstellung.
-`BAK-05` Reconciliation (Konsistenzprüfung Storage vs. DB) – Periodische Prüfung, ob jeder in der Datenbank referenzierte Objekt-Storage-Eintrag tatsächlich existiert und umgekehrt, mit Bericht über Abweichungen.
-`BAK-07` Aufbewahrungsfrist für Backup-Snapshots – 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.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Restore wird real auf ein leeres Testsystem durchgeführt und dokumentiert
2. Reconciliation nach Restore zeigt keine Abweichungen zwischen Storage und Datenbank
3. Protokoll mit Zielwert, Messwert und Bewertung ist abgelegt
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Realer Restore-Testlauf erfolgreich und protokolliert
2. Reconciliation nach dem Testlauf liefert einen sauberen Bericht
3. Offene Restrisiken sind schriftlich benannt
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
-`QA-05` Abnahme- & Compliance-Prüfung Archive
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Gesamtabnahme des Archive-Boards vor Freigabe: Retention/WORM, Compliance/eDiscovery und Backup/Restore müssen alle bestanden sein.
**Technische Grundlage:** Abnahmeprotokoll
## Produkt-DNA für diesen Bereich
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Prüfplan je Ausbaustufe mit abgelegtem, nachlesbarem Protokoll.
- Nachgewiesene Wiederherstellbarkeit als Freigabevoraussetzung.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf.
- Keine Prüfung nur auf dem Entwicklungsrechner mit synthetischen Testdaten.
**Für genau diese Kachel:** Erst wenn Retention, Compliance und Backup einzeln bestanden sind, ist Archive insgesamt freigabefähig – diese Kachel bündelt den Nachweis.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`QA-02` Prüfgate Retention & WORM – Prüfgate für Fristenengine, Löschworkflow, Aufbewahrungssperre und WORM-Garantie vor Freigabe der Retention-Funktionen.
-`QA-03` Prüfgate Compliance & eDiscovery – Prüfgate für eDiscovery-Export und Vier-Augen-Freigabe vor Freigabe der Compliance-Funktionen.
-`QA-04` Prüfgate Backup & Restore – Prüfgate für Backup-Strategie und Restore-Verfahren vor Freigabe der Backup-Funktionen, inklusive einem real durchgeführten Wiederherstellungstest.
-`QA-06` Schnittstellen-Vertragstests – 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.
-`QA-07` Last- & Leistungstest – 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.
-`ANA-01` Kennzahlen-Aggregation (modulübergreifend) – Zentraler Dienst, der Kennzahlen (Objektbestand, Aufbewahrungsstatus, Löschvorgänge, Speichervolumen) aus allen über RET-05 registrierten Modulen aggregiert.
-`ANA-02` Auswertungs-Dashboard – Dashboard zur Visualisierung der aggregierten Kennzahlen mit Filtern nach Tenant, Modul und Zeitraum.
-`ANA-03` Lizenz-/Nutzungs-Reports – Bericht über Nutzung und Lizenzrelevantes je Tenant (Speichervolumen, aktive Objekte, Nutzeranzahl-Bezug), abgestimmt mit dem Lizenzmodell aus NEXARCH Core.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Alle drei fachlichen Prüfgates (QA-02, QA-03, QA-04) sind bestanden
2. Gesamtprotokoll fasst alle drei Prüfgates mit Ergebnis zusammen
3. Abnahmeprotokoll ist unterzeichnet
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Zusammenfassung aller drei Prüfgates gegen die jeweiligen Einzelprotokolle abgeglichen
2. Offene Restrisiken aus allen drei Gates sind konsolidiert und schriftlich benannt
3. Freigabeentscheidung ist dokumentiert
## Nicht Bestandteil dieser Kachel
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
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.
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Fester Vertragskorpus je Schnittstelle, an dem Kompatibilität wiederholbar geprüft wird.
- Nachgewiesene Erkennung von Breaking Changes als Freigabevoraussetzung, wie es verbindliche Schnittstellenverträge verlangen.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
- Keine Prüfung nur auf dem Entwicklungsrechner mit einer Handvoll Beispielaufrufen.
**Für genau diese Kachel:** Die Modul-Adapter-Schnittstelle ist der eigentliche Zweck des Boards – ein unbemerkter Bruch trifft DMS und Mail gleichermaßen und muss automatisiert auffallen, bevor er ausgeliefert wird.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
## Akzeptanzkriterien
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
1. Vertragstests decken RET-05 vollständig ab
2. Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen
3. Tests laufen automatisiert in der CI
## Prüfungen vor der Abnahme
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
1. Testlauf gegen aktuellen Stand grün
2. Simulierte Breaking Change erkannt
3. CI-Integration nachgewiesen
## Nicht Bestandteil dieser Kachel
- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
## Arbeitsweise
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
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.
> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
**Übernehmen:**
- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung, wie in allen anderen Boards.
**Bewusst vermeiden:**
- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
**Für genau diese Kachel:** Archive wird von zwei Modulen gleichzeitig angesprochen (DMS und Mail) – ohne Lasttest bleibt unklar, ob der Retention-Prüfpfad das verkraftet.
## Ausgangslage
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
-`RET-05` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen) – Schnittstelle, über die DMS und Mail ihre Objekttypen (Dokument, Mail, Anhang) und die zugehörige Aufbewahrungsklasse bei Archive registrieren, statt eigene Retention-Logik zu bauen.
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (zentrales, modulübergreifendes Modul für Aufbewahrung, WORM, Compliance und Backup), das sich an Alfresco (Retention Policies, revisionssichere Ablage, Vier-Augen-Prinzip), ecoDMS (Revisionssicherheit, nachvollziehbare Vernichtung) und restic/Borg (inkrementelle, deduplizierende, verifizierbare Sicherung) orientiert und deren bekannte Schwächen bewusst vermeidet – insbesondere den Ressourcen-Overhead von Alfresco.
Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
## Auftrag
Generisches Datenmodell für aufbewahrungspflichtige Objekte anlegen: Objekttyp, Objekt-Referenz (modulübergreifend über Adapter), Aufbewahrungsklasse, Status. Migrationen versioniert und rückrollbar.
- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
Loaded 100 of 587 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
patrickandClaude Sonnet 5.5