nexarch/docs/SHL-02-PRUEFPROTOKOLL.md

SHL-02 – Prüfprotokoll (Zentrales Portal)

Datum: 2026-09-26. Host: Entwicklungshost 192.168.1.204, frischer Klon von main (Head 30cd3572).

Umsetzung

• Neue App web/portal (Next.js/React/TS + @nexarch/shl).
• Modul-Registry als reine Konfigurationsdatei web/portal/config/modules.json (Name, Beschreibung, Link, benötigte RBAC-Permission je Modul) — kein hartcodierter Modul-Code (Akzeptanzkriterium 3).
• Sichtbarkeit: app/api/visible-modules/route.ts (Backend-for-Frontend, hält das policy-api-Dienst-Token serverseitig) ruft für jeden Registry-Eintrag POST /authorize beim bestehenden Core-policy-api auf (internal/policyapi/internal/policy/module_scope.go, AuthorizeRequest) — Core entscheidet über RBAC-Rolle UND Mandanten-Feature-Flag in einem einzigen, bereits existierenden Aufruf; das Portal trifft keine eigene zweite Entscheidung (Akzeptanzkriterium 2).
• Authentifizierung: bestehendes createSession/redirectToLogin aus @nexarch/shl (UX-10), dieselbe Cookie-→Modul-Token-Sitzung wie bei dms-upload/dms-browser/pdf-viewer — keine neue Auth-Architektur.
• Kernlogik (filterVisibleModules) als reine, injizierbare Funktion extrahiert, damit Akzeptanzkriterium 2/3 ohne echten policy-api-Server unit-testbar sind.

Akzeptanzkriterien — Ergebnis

1. Nach Anmeldung Kachel-Übersicht je sichtbarem Modul: erfüllt, real im Browser geprüft (siehe Prüfung 1).
2. Sichtbarkeit hängt von Mandanten-Feature-Flag UND Nutzerrolle ab, nicht von einer statischen Frontend-Liste: erfüllt, POST /authorize ist die alleinige Entscheidungsquelle.
3. Neues Modul ohne Portal-Code-Änderung: erfüllt, siehe Prüfung 2.
4. Barrierefreie, mobilfreundliche Oberfläche (WCAG 2.1 AA): erfüllt, siehe Prüfung 3.

Prüfungen — Ergebnis

1. Zwei Testnutzer mit unterschiedlichen Rechten sehen unterschiedliche Kacheln. Real durchgeführt in zwei Schichten:
   • Unit-Test (app/api/visible-modules/route.test.ts): role=user liefert 5 Module, role=tenant_admin liefert zusätzlich tenant_admin (6 Module) — bestanden.
   • Echter Browser-Test (Chrome stable + Puppeteer, Host 204): Fixture-Server (/root/shl02-work/fixture/server.mjs, mock core+policy-api) simulierte einen echten createSession-Ablauf (Cookie→Modul-Token, CORS). Mit Rolle user erschienen 5 Kacheln, "Mandantenverwaltung" fehlte vollständig aus dem DOM. Nach Umstellen der Fixture-Standardrolle auf tenant_admin und Neuladen erschien die Kachel "Mandantenverwaltung" zusätzlich — ADMIN-KACHEL SICHTBAR bestätigt per page.evaluate.
2. Neues Test-Modul nur über Konfiguration. Test ein neues Modul per Konfigurationseintrag erscheint ohne Codeaenderung in route.test.ts: ein synthetischer Registry-Eintrag (neues_testmodul) durchläuft exakt denselben filterVisibleModules-Code-Pfad wie die echten Module, ohne dass Rendering- oder Prüf-Code angepasst wurde — bestanden.
3. Echter Barrierefreiheits-Check (pa11y --standard WCAG2AA, Chrome stable, /usr/bin/google-chrome-stable) gegen den laufenden Produktionsbuild (next start, Port 19803) mit echtem, sichtbarem Kachel-Inhalt: "No issues found!"
4. Kein Modul ohne Berechtigung sichtbar (negativer Zugriffstest). Strukturell erzwungen (nicht CSS): filterVisibleModules nimmt ein Modul nur in die zurückgegebene Liste auf, wenn authorize() true liefert; Test laesst kein Modul ohne Berechtigung durch und laesst kein Modul durch wenn 'authorize' fehlschlaegt (fail-closed bei Ausfall) beide bestanden. Im echten Browser-Test war "Mandantenverwaltung" bei Rolle user komplett aus dem gerenderten HTML abwesend, nicht nur optisch verborgen.

Tests

• npx vitest run: 10/10 grün (lib/modules.test.ts, app/api/visible-modules/route.test.ts — 7 Fälle inkl. der oben genannten, app/ModuleGrid.test.tsx).
• npx tsc --noEmit: sauber (nach dem bekannten Turbopack/@nexarch/shl-Symlink→Realkopie-Fix, wie bei APR-03/VOR-05/SUM-03/EXT-04).
• npx next build: erfolgreich (3 Routen: /, /_not-found, /api/visible-modules).

Nicht Bestandteil (wie in der Kachel festgelegt)

• Single-Sign-On zwischen den Modul-Apps selbst
• Umbau der bestehenden Modul-Apps
• Cross-Modul-Volltextsuche

Nebenbefund

Ein 404 auf favicon.ico im Browser-Konsolen-Log — kein App-Fehler, keine fehlende Ressource für die Kernfunktion, nicht behoben (außerhalb des Tickets).