# 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.