archive-kanban: Ticket RET-13 (Legal-Hold-Abfrage-Endpunkt für Module) anlegen

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

archive-kanban/tickets/RET-13.md

@@ -0,0 +1,56 @@
+# RET-13 – Legal-Hold-Abfrage-Endpunkt für Module
+
+**Epic:** ⏳ Retention & WORM  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+RET-03 hält Aufbewahrungssperren (Legal Hold) in `legal_holds`, aber nur als Go-Funktion (`deletionworkflow.IsOnLegalHold`). Module, die Objekte endgültig löschen (DMS: Papierkorb-Leerung, Ablauf der Papierkorbfrist), können die Sperre bisher nicht abfragen. Archive stellt dafür einen schreibgeschützten HTTP-Endpunkt bereit, den das DMS (INT-11, `retentionclient.CheckLegalHold`) bereits als Vertrag annimmt.
+
+**Technische Grundlage:** `GET /legal-hold?object_type=<typ>&object_reference=<referenz>`, Antwort `200 {"on_hold": bool, "reason": string}`; Tenant-Registry-Abgleich (RET-12), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Alfresco/ecoDMS: Die Sperre wirkt vor jeder Löschung, unabhängig davon, welches Modul löscht.
+
+**Bewusst vermeiden:**
+- Ein Aufrufer, der bei Unklarheit „nicht gesperrt“ annimmt. Archive liefert nur, was in der Datenbank steht. Alles Unklare (Fehler, Fremdmandant, fehlende Konfiguration) ist ein Fehlerstatus, nie `on_hold: false`.
+- Vertrauen in den vom Modul mitgelieferten Tenant-Kontext (RET-12): Archive prüft ihn selbst und bindet ihn an die Instanz.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: RET-03, RET-05, RET-12.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `GET /legal-hold` liefert für ein registriertes Objekt mit aktiver Sperre `on_hold: true` samt Grund, ohne aktive Sperre (nie gesperrt oder aufgehoben) `on_hold: false`
+2. Ein fehlender oder fremder Tenant-Kontext, ein unbekannter Tenant, ein nicht erreichbares Tenant-Register und ein Datenbankfehler führen zu einem Fehlerstatus (400/403/503), nie zu `on_hold: false`
+3. Die Abfrage ist rein lesend und mandantengetrennt: Sie liest ausschließlich die Datenbank der Instanz und ändert keine Sperre
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test gegen echte Datenbank: gesperrtes, freigegebenes, nie gesperrtes und unbekanntes Objekt liefern die erwartete Antwort
+2. Test: fremder Tenant, manipulierter Tenant-Header, Registry-Ausfall und Datenbankausfall werden nie als „nicht gesperrt“ beantwortet
+3. Vertragstest: der DMS-`retentionclient` fragt den echten Archive-Handler ab (lokaler Lauf gegen Wegwerf-Datenbank)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RET-03` Setzen und Aufheben von Sperren
+- Dienst-zu-Dienst-Authentifizierung über Core-Modul-Tokens (Core-Board): Archive prüft optional ein Service-Token, bis Core es verbindlich ausliefert
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RET-13: legal-hold-abfrage-endpunkt`
+- Branch: `feature/ret-13-legal-hold-abfrage-endpunkt`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.