- migrations/0010_deletion_requests: speichert nur den Token-Hash,
nie das Token selbst
- archive/internal/deletionapproval: RequestDeletion (einmaliges
Klartext-Token), ConfirmAndExecute (FOR UPDATE-Lock, andere Person
als requester, zeitkonstanter Tokenvergleich via subtle.ConstantTimeCompare,
ruft danach genau einmal deletionworkflow.Destroy (RET-03) auf)
- 4 Tests real bestanden, inkl. echtem Nebenlaeufigkeits-Test (zwei
echte Goroutinen, genau 1 Erfolg + 1 ErrAlreadyExecuted, genau ein
destruction_log-Eintrag)
- Migration real auf dms_tenant_test angewendet
Pruefungen siehe archive/docs/CMP-06-PRUEFPROTOKOLL.md
- migrations/0009_data_subject_ref: additive nullable Spalte auf
retention_objects, schliesst die Luecke fuer 'betroffene Person' in
RET-01
- retention.RegisterObjectForSubject: NEUE additive Funktion, RegisterObject
selbst unveraendert (kein Diff, keine Produktionsaufrufer betroffen)
- archive/internal/dpreport: SubjectReport (Auskunftsbericht),
ProcessingOverview (Verarbeitungsuebersicht, statisch gepflegte
Zweck/Rechtsgrundlage je Objekttyp), WriteSubjectReportCSV
- Mandantentrennung strukturell durch Modell C (ein Pool pro Tenant),
real mit zwei physisch getrennten Tenant-DBs bewiesen (tenant_acme/
tenant_globex), nicht nur behauptet
- 4 Tests, alle Pflichtpruefungen real bestanden
- Migration real auf dms_tenant_test angewendet
Pruefungen siehe archive/docs/CMP-02-PRUEFPROTOKOLL.md
- migrations/0008_legal_hold_destruction: legal_holds (historisiert,
Partial-Unique-Index gegen doppelte aktive Sperre), destruction_log
(append-only, per Postgres-Trigger gegen UPDATE/DELETE geschuetzt)
- archive/internal/deletionworkflow: SetLegalHold (Begruendungspflicht),
ReleaseLegalHold (Aufheben selbst protokolliert, keine Loeschung der
Zeile), ReleaseExpired (Freigabeprozess active->expired, keine
Sofortloeschung, Sperre wird respektiert), Destroy (verlangt
vorherigen expired-Status, prueft Sperre erneut, transaktional mit
Protokolleintrag)
- 6 Tests, alle Pflichtpruefungen real bestanden (Sperre widersteht
Loeschversuch, Protokoll real unveraenderlich per Trigger, Aufheben
real protokolliert)
- Migration real auf dms_tenant_test angewendet
Pruefungen siehe archive/docs/RET-03-PRUEFPROTOKOLL.md
- archive/internal/wormstore.Store: Put schreibt einmalig (chmod 0400
danach, ErrAlreadyExists bei Ueberschreibversuch inkl. DB-seitiger
Sperre gegen Wettlaufsituationen), GetVerified prueft SHA-256 bei
jedem Zugriff, KEINE Delete-Funktion (strukturelle API-Grenze)
- migrations/0007_worm_objects: append-only Metadatentabelle
- AC2/Pruefung 3 vor Umsetzung praezisiert: Schutz ueber Go-API,
kein absoluter Schutz gegen root (Nutzerentscheidung: kein chattr +i,
nicht portabel/nicht ehrlich als absolut behauptbar)
- Reflection-Test beweist strukturell: keine Loesch-Methode vorhanden
- zusaetzlich echter Nachweis auf 131 als Nicht-Root-Betriebsnutzer
(sudo -u nexarch): direkter Ueberschreibversuch scheitert real,
Automatiktest selbst laeuft als root und uebersprang diesen Teil
bewusst
Pruefungen siehe archive/docs/RET-04-PRUEFPROTOKOLL.md
Board-Entscheidung: Backend-API zuerst, echtes Next.js-Frontend als
separates Folgeticket - vermeidet Pseudo-Frontend-Protokoll.
internal/retentionapi: 4 Endpunkte (anlegen/aendern, deaktivieren,
liste, vorschau), Vorschau nutzt dieselbe ListExpiringObjects-Funktion
wie RET-02s periodischer Job (keine Doppel-Implementierung).
RequireRole ist AUSDRUECKLICH kein RBAC-02-Ersatz, sondern ein
dokumentiertes Provisorium (Header-Check) - RBAC-02 ist reiner
Core-interner Go-Code ohne HTTP-Schnittstelle fuer andere Module,
derselbe Befund wie FDN-03/FDN-09. Provisorium real getestet inkl.
Negativfall (403 ohne/mit falscher Rolle). retention_class_rules um
active-Flag erweitert (deaktivieren ohne Historienverlust). Real auf
131 deployed und per curl end-to-end verifiziert.
internal/retentionengine: Frist je Aufbewahrungsklasse als natives
Postgres-INTERVAL, Stichtagsberechnung an Postgres delegiert statt
eigener Kalenderrechnung (Schaltjahr/Monatsende-Referenzwerte real
verifiziert: 2024-02-29+1y=2025-02-28, 2026-01-31+1mo=2026-02-28).
Periodischer Job (ListExpiringObjects) beschraenkt sich per DISTINCT ON
auf die juengste Klassenzuordnung je Objekt - sonst wuerden Objekte mit
mehrfach geaenderter Klasse (RET-01-Historisierung) doppelt auftauchen,
real mit einem Zwei-Zuordnungen-Testobjekt bewiesen. Scope bewusst eng
gehalten: keine RET-05-Anbindung, keine Vernichtungslogik - das ist
Ticket-Scope, dependsOn ist nur RET-01.
Vor Board-Flip bemerkt: Akzeptanzkriterium 1 fordert Objekttyp MIT
Aufbewahrungsklasse UND Rueckruf-Adresse, retention_class fehlte im
ersten Entwurf komplett. Migration, Registration-Struct, Register,
ListRegistrations und RegisterHandler ergaenzt, Tests angepasst
(Idempotenz jetzt auch fuer retention_class geprueft, nicht nur
callback_url). Real auf 131 gedroppt und neu angewendet.
internal/moduleadapter: Registrierungs-API + Rueckruf-Ausloeser fuer
DMS/Mail, bewusst NUR Archives eigene Seite - keine Modul-Empfaenger-
Implementierung (Nutzervorgabe: Interface zuerst festlegen, damit
DMS/Mail spaeter nicht gegen ein sich noch aenderndes Interface bauen).
Register ist ON-CONFLICT-DO-NOTHING (erneute Registrierung aendert nie
bestehende callback_url), NotifyDestruction echter HTTP-POST mit festem
DestructionNotice-Vertrag. Idempotenz sowohl auf Go- als auch HTTP-
Ebene bewiesen, Rueckruf gegen echten Testendpunkt verifiziert.
internal/retention: object_type/object_reference als reine Textfelder
(Adapter-Muster, keine Fremdschluessel auf DMS-/Mail-Tabellen).
Aufbewahrungsklassen-Zuordnung historisiert (jede Zuordnung eigene,
unveraenderliche Zeile). Migration real vorwaerts+rueckwaerts gegen
die tatsaechlichen .sql-Dateien getestet, Mandantentrennung gegen
echtes zweites Tenant-DB bewiesen. Grundlage fuer RET-05 (Adapter-
Interface) und RET-02.
sysops