DOC-16: ret-05-client-aufbewahrungsklasse-registrieren-vernichtungs-rueckruf
- dms/internal/retentionclient: HTTP-Client fuer Archive RET-05/RET-09
- dms/internal/retentiondestroy: RegisterOrRequeue (FDN-04-Requeue bei
Fehlschlag, kein Absturz/stilles Verwerfen), DestroyCallbackHandler
(physische Loeschung aller Datei-Revisionen ueber storage.Service,
markiert Dokument als vernichtet, 2xx erst danach)
- dms/cmd/app: mountet destroy-callback, registriert beim Start
- dms/cmd/worker: verarbeitet Requeue-Jobs (Retry)
- nur dms_document registriert (DOC-01/FDN-02 kennen keinen separaten
Anhang-Typ, kein Umbau angrenzender Bereiche)
- real getestet: registrierung gegen echten fake-RET-05-Server, echte
Loeschung inkl. Storage-Byte-Nachweis, echter Requeue-Eintrag bei
Fehlschlag, erfolgreicher Retry
- live auf 131 gegen echten RET-09-Dienst (Port 8095) verifiziert,
echter curl-Vernichtungs-Rueckruf mit real geloeschter Datei
- reale Core-API-06-Deploy-Luecke dokumentiert (nicht verschwiegen):
/internal/resync/usage auf 131 aktuell nicht gemountet
Pruefungen siehe dms/docs/DOC-16-PRUEFPROTOKOLL.md
sysops
9843275e9c