Files
nexarch/archive/docs/RET-01-PRUEFPROTOKOLL.md
T
sysops b37b790792 feat(archive): RET-01 generisches Retention-Objektmodell
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.
2026-08-30 01:25:31 +02:00

65 lines
3.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# RET-01 Prüfprotokoll: Generisches Retention-Objektmodell
Keine Vorbedingungen (Welle 1 des RET-Epics).
## Grundsatzentscheidung: Adapter-Muster, keine Fremdschlüssel auf Modul-Tabellen
`retention_objects.object_type`/`object_reference` sind reine
Textfelder — Archive importiert weder DMS- noch Mail-Code (eigene
Go-Module, physisch getrennte Verantwortung, dieselbe Disziplin wie
BAK-05s `reconcile`-Paket gegenüber `file_revisions`). Ein neues Modul
kann retention-pflichtige Objekte einbinden, ohne dieses Paket zu
ändern — nur `RegisterObject(objectType, objectReference)` aufrufen.
Aufbewahrungsklassen-Zuordnung ist historisiert: `AssignClass` fügt
IMMER eine neue Zeile hinzu, ändert nie eine bestehende — die "aktuelle"
Klasse ist die mit dem jüngsten `assigned_at`. Damit bleibt
nachvollziehbar, wann und wie oft sich die Klasse eines Objekts
geändert hat, ohne eigene Audit-Tabelle.
## Umsetzung
- `migrations/0002_retention.up.sql`/`.down.sql``retention_objects`,
`retention_class_assignments`.
- `internal/retention.RegisterObject` — idempotent (`ON CONFLICT`).
- `internal/retention.AssignClass`/`CurrentClass`/`ClassHistory`.
## Prüfungen
| # | Prüfung | Ergebnis |
|---|---|---|
| 1 | Migration vorwärts und rückwärts getestet | **bestanden**`TestMigration_ForwardAndBackward`: real gegen die tatsächlichen Migrationsdateien (nicht nachgebaut), vorwärts→Tabellen vorhanden, rückwärts→Tabellen weg, erneut vorwärts→sauber (kein Rest blockiert erneuten Lauf) |
| 2 | Testobjekt aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet | **bestanden**`TestRegisterObject_MapsDMSAndMailAdapterObjectsIdentically`: `dms_document`/`mail_message` beide ohne modulspezifische Spalten abgebildet, zusätzlich Idempotenz bewiesen (erneute Registrierung liefert dieselbe ID) |
| 3 | Tenant-Isolation der Kern-Tabellen durch Negativtest belegt | **bestanden**`TestTenantIsolation_Negativtest`: reales zweites Tenant-DB (`ret01_tenant_test_b`), Objekt aus Tenant A über Verbindung zu Tenant B abgefragt, `count=0` — technisch nicht sichtbar, keine gemeinsame Tabelle mit `tenant_id`-Filter (Modell C, TEN-01) |
Zusätzlich: `TestAssignClass_IsHistoricized` — zwei Klassen-Zuordnungen,
`CurrentClass` liefert die jüngste, `ClassHistory` beide chronologisch.
## Echte Verdrahtung auf 192.168.1.131
- Migration real gegen `dms_tenant_test` angewendet (`psql -f
migrations/0002_retention.up.sql`) — `retention_objects`,
`retention_class_assignments` bestätigt vorhanden (`\dt retention*`)
- Kein systemd-Dienst/Timer nötig — RET-01 ist reines Datenmodell +
Bibliothek, kein eigenständiger Prozess (Verbraucher sind spätere
RET-Tickets, allen voran RET-05 als Adapter-Interface)
- Zweites Tenant-DB (`ret01_tenant_test_b`) nur für den Isolationstest
angelegt, danach entfernt
## Build/Test-Ergebnis (192.168.1.131, `make check`)
```
go build ./... -> clean
go vet ./... -> clean
golangci-lint run ./... -> 0 issues
go test ./... -p 1 -count=1 -> 8/8 Pakete mit Tests ok (backup, objectbackup, reconcile, restore, restoretest, retention, scrub, tenantbackup), 0 Fehlschläge
```
## Gesamtergebnis
**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
Pflichtprüfungen real erfüllt — Migration gegen die tatsächlichen
`.sql`-Dateien (nicht nachgebaut) getestet, Mandantentrennung gegen ein
echtes zweites Tenant-DB bewiesen. Grundlage für RET-05 (Adapter-
Interface, als Nächstes) und RET-02 gelegt.