nexarch/archive/docs/RET-06-PRUEFPROTOKOLL.md

RET-06 – Prüfprotokoll: Aufbewahrungsfristen-Konfigurationsoberfläche

Voraussetzung RET-02, RET-06-API, RET-08 (RBAC-Migration) – alle bereits Fertig. RET-08 hat das Header-Provisorium in RET-06-API bereits durch einen echten Aufruf von Core RBAC-06 ersetzt – dieses Ticket testet daher von Anfang an gegen echte RBAC-Autorisierung, nicht gegen ein Provisorium (siehe RET-08-Prüfprotokoll).

Umsetzung

• web/retention-admin – eigenständige Next.js/React/TypeScript-App (kein /admin-Annex im Go-Backend), analog zu web/notifications (CFG-04) und web/lic-admin (LIC-04), aufbauend auf web/shl (SHL-01, gemeinsames Design-System).
• lib/api.ts – dünner Client für RET-06-API. Reicht die vom Nutzer beanspruchte Rolle über X-User-Role durch (RET-08 prüft sie gegen RBAC-06), trifft selbst keine Autorisierungsentscheidung. Wirft ForbiddenError bei HTTP 403, getrennt von generischen ApiErrors.
• app/classes/page.tsx – Akzeptanzkriterium 1: Aufbewahrungsklasse anlegen/ändern (ein Formular, Backend-UPSERT) und deaktivieren. Akzeptanzkriterium 3: ForbiddenError führt zu einer expliziten "Zugriff verweigert"-Anzeige, nicht zu einer leeren Tabelle.
• app/preview/page.tsx – Akzeptanzkriterium 2: Vorschauliste über /retention-classes/preview, dieselbe Funktion wie der periodische Job (RET-02/RET-06-API), keine eigene Berechnung im Frontend.

Prüfungen

#	Prüfung	Ergebnis
1	Änderung einer Frist wirkt nur auf künftige Berechnungen, nicht rückwirkend	bestanden (Backend-seitig bereits durch RET-02/RET-06-API bewiesen) – Frontend ruft ausschließlich den bestehenden UPSERT-Endpunkt auf, keine eigene Berechnungslogik im Frontend, die dies unterlaufen könnte
2	Nicht berechtigte Rolle erhält keinen Zugriff auf die Konfiguration	bestanden – expliziter 403-Nachweis, nicht nur der 200-Fall: lib/api.test.ts, describe("api client - 403-Nachweis (keine berechtigte Rolle)") – zwei Tests (fetchClassRules, configureClassRule) mit real gemockter 403-HTTP-Antwort, beide werfen ForbiddenError; ClassesPage/PreviewPage fangen ForbiddenError ab und zeigen role="alert" "Zugriff verweigert" statt einer leeren/stillen Seite. Der 403-Vertrag selbst (RET-06-API antwortet real mit 403 bei fehlender RBAC-06-Berechtigung) ist bereits in RET-08 end-zu-ende gegen den laufenden Dienst auf 131 bewiesen (curl ohne Policy-Rule → 403) – dieses Ticket prüft, dass das Frontend diesen real existierenden Vertrag korrekt behandelt, nicht das Backend erneut
3	Vorschauliste stimmt mit dem Ergebnis des periodischen Jobs überein	bestanden (Backend-seitig bereits durch RET-06-API bewiesen) – PreviewPage ruft exakt denselben /retention-classes/preview-Endpunkt auf, der intern retentionengine.ListExpiringObjects verwendet (identische Funktion wie der periodische Job), keine zweite Implementierung im Frontend

Build/Test-Ergebnis (lokal, node v22.16.0/npm 10.9.2 – bereits installiert)

npx tsc --noEmit          -> clean (eigener Code; siehe Hinweis)
npx next build            -> Compiled successfully, 3 Routen (/, /classes, /preview)
npx vitest run            -> 3/3 Tests bestanden

Hinweis: web/shl (SHL-01, bereits Fertig) hatte kein eigenes node_modules im Checkout – ohne npm install dort lieferte tsc kaskadierende "Cannot find module 'react'"-Fehler in shl-eigenen Dateien, nicht durch RET-06 verursacht. Für den lokalen Testlauf wurde npm install in web/shl ausgeführt (kein Code-Umbau, nur Abhängigkeiten installiert); web/shl/package-lock.json wurde dadurch neu erzeugt, aber bewusst NICHT mitcommittet (gehört zu SHL-01, nicht zu diesem Ticket – kein Umbau angrenzender Bereiche).

Gesamtergebnis

Bestanden. Alle drei Akzeptanzkriterien real erfüllt, insbesondere der explizit geforderte negative 403-Fall (nicht nur der Erfolgsfall) sowie die eigenständige Next.js-App-Struktur (kein Backend-Annex). Frontend testet von Anfang an gegen die durch RET-08 real hergestellte RBAC-06-Autorisierung, nicht gegen ein Provisorium.