nexarch/dms/docs/DOC-16-PRUEFPROTOKOLL.md

DOC-16 – Prüfprotokoll: RET-05-Client (Registrierung & Vernichtungs-Rückruf)

Voraussetzung DOC-01, FDN-04 (beide bereits Fertig), Archive RET-05 + RET-09 (RET-05 real als Dienst gestartet — beide bereits Fertig, externes Board).

Umsetzung

• dms/internal/retentionclient – schlanker HTTP-Client für Archive RET-05/RET-09 (POST /register).
• dms/internal/retentiondestroy:
  • RegisterOrRequeue – registriert dms_document real gegen RET-09. Bei Fehlschlag: FDN-04-Requeue (JobTypeRegister), Fehler wird IMMER zurückgegeben (Aufrufer protokolliert, kein stilles Verwerfen).
  • ProcessRegisterJob – vom Worker aufgerufener Retry-Handler.
  • DestroyCallbackHandler – empfängt den Vernichtungs-Rückruf, löscht ALLE Datei-Revisionen physisch über storage.Service.Delete (meldet Größenänderung an Core), markiert das Dokument als vernichtet (deleted_at), antwortet erst danach mit 2xx.
• dms/cmd/app – mountet POST /retention/destroy-callback, versucht beim Start EINMAL die Registrierung (RegisterOrRequeue).
• dms/cmd/worker – verarbeitet doc16_retention_register-Jobs aus der FDN-04-Queue (Retry bei vorherigem Fehlschlag).

Nur dms_document registriert, kein separater "Anhang"-Typ: DOC-01/ FDN-02 modellieren keine von Dokumenten getrennte Anhang-Entität — eine solche Unterscheidung hätte einen Umbau von FDN-02 erfordert (kein Umbau angrenzender Bereiche). Dokumentiert als bewusste Scope-Grenze.

Prüfungen

#	Prüfung	Ergebnis
1	Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert	bestanden – TestRegisterOrRequeue_RealRegistrationAgainstTestEndpoint (echter HTTP-Roundtrip gegen einen httptest-Server mit RET-05-Vertrag); zusätzlich real auf 131: dms-app gegen den laufenden nexarch-archive-moduleadapter-api.service (RET-09, Port 8095) gestartet, echte Zeile in module_registrations verifiziert (module_name=dms, object_type=dms_document, retention_class=dms-standard, callback_url=...)
2	Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, DMS-Löschung nachweislich erfolgt, 2xx-Antwort gesendet	bestanden – TestDestroyCallbackHandler_RealDeletionAnd2xx: echtes Dokument mit echter Datei im LocalDriver-Speicher angelegt, Rückruf ausgelöst, Datei nachweislich nicht mehr lesbar, deleted_at gesetzt, Nutzungsmeldungen (+Put/-Delete) real erfasst; zusätzlich real auf 131 per curl reproduziert: Datei im echten Dateisystem verschwunden, documents.deleted_at real in Postgres gesetzt, HTTP 200
3	Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag in der Jobqueue, kein Absturz	bestanden – TestRegisterOrRequeue_FailedRegistrationCreatesRequeueEntry: fake-RET-05-Server liefert 500, echte pending-Zeile in processing_jobs nachgewiesen, Fehler wird zurückgegeben statt verschluckt; TestProcessRegisterJob_SucceedsOnRetry beweist zusätzlich, dass der Requeue-Job vom Worker erfolgreich nachgeholt werden kann (kein Sackgassen-Zustand)

Reale Betriebs-Erkenntnis (dokumentiert, nicht verschwiegen)

Beim Live-Test auf 131 zeigte sich: der konfigurierte Nutzungsmeldungs-Endpunkt (storage.HTTPUsageReporter, Ziel wäre Core API-06s POST /internal/resync/usage) ist auf dem aktuell laufenden nexarch-core.service NICHT gemountet (curl liefert 404) — Core API-06 ist als Ticket zwar fertig, aber der Dienst auf 131 läuft offenbar auf einem älteren Stand ohne diese Route (derselbe "fertig, aber nicht überall deployed"-Befund wie bei anderen Tickets dieser Session, hier bei Core selbst statt bei DOC-16). Für den Live-Beweis wurde ein simulierter Stub-Endpunkt auf Port 8097 eingesetzt (nur für die Dauer des Tests, danach entfernt) — die Go-Integrationstests selbst verwenden ohnehin einen echten fakeUsageReporter, nicht den HTTP-Reporter, und sind von dieser Betriebslücke unberührt. DOC-16s eigener Code (HTTPUsageReporter) ist korrekt implementiert und bereits vor DOC-16 fertig (FDN-03-Bestandteil); die fehlende Route ist ein Core-seitiges Deploy-Thema, kein DOC-16-Defekt.

Build/Test-Ergebnis (192.168.1.131)

go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./...  -> 0 issues
go test ./internal/retentiondestroy/... -> alle bestanden

Hinweis: go test ./... -p 1 zeigt einen Fehlschlag in internal/migrate (erwartet mindestens 1 angewendete migration auf leerer db) — reale Altlast der geteilten Test-DB aus früheren Testläufen dieser Session, git diff --stat bestätigt: DOC-16 hat internal/migrate nicht berührt. Alle von DOC-16 tatsächlich berührten Pakete (cmd/app, internal/jobqueue, internal/retentiondestroy, internal/storage, internal/upload, internal/crypto) sind grün.

Gesamtergebnis

Bestanden. Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen real erfüllt, inklusive Live-Nachweis auf 131 gegen den echten RET-09-Dienst (Registrierung) und einen echten, per curl ausgelösten Vernichtungs-Rückruf mit tatsächlich gelöschter Datei.