nexarch/docs/SHL-03-PRUEFPROTOKOLL.md

SHL-03 – Prüfprotokoll (Zentrale Core-Steuerungsseite)

Datum: 2026-09-28. Host: Entwicklungshost 192.168.1.204, frischer Klon von origin/main (Head 6e1b72ed).

Umsetzung

• Neue App web/core-control (Next.js/React/TS + @nexarch/shl), Muster von web/portal (SHL-02) übernommen: Sektions-Registry als reine Konfigurationsdatei (config/sections.json), Sichtbarkeitsprüfung über app/api/visible-sections/route.ts (filterVisibleSections, identischer Aufbau wie filterVisibleModules), Sitzung über bestehendes createSession/redirectToLogin aus @nexarch/shl.
• Jede der vier Sektionen (Tenant-Verwaltung/TEN-05, Rechte-Administration/RBAC-05, Lizenz-/Modulverwaltung/LIC-04, Benachrichtigungs-Einstellungen/CFG-04) wird als Tab (role="tab"/role="tabpanel") dargestellt und bindet die jeweils bestehende, eigenständige App per <iframe> ein — keine Wiederimplementierung ihrer Komponenten/API-Aufrufe, kein Eingriff in web/tenant-admin, web/rbac-admin, web/lic-admin, web/notifications (unverändert, git status bestätigt keine Diffs dort).
• Jeder Tab verlinkt zusätzlich auf die eigenständige Oberfläche ("Eigenständig öffnen") — Akzeptanzkriterium 4.

Entscheidung zur Rechte-Zuordnung (dokumentiert, wie in der Aufgabenstellung vorgesehen)

Recherche vor der Umsetzung (migrations/0018_module_policy_rules.up.sql, web/portal/config/modules.json, docs/GESAMTPROJEKT-PRUEFPROTOKOLL.md Zeile 1108) ergab: nur tenant_admin hat mit core.tenant.admin eine reale, migrierte Berechtigung. rbac-admin hat keine eigene reale Berechtigung — das bestehende Portal-Modul-Katalog (SHL-02) ordnet ihm bereits dasselbe core.tenant.admin zu, mangels einer spezifischeren, real existierenden Regel. lic-admin und notifications wurden im Portal-Katalog laut GESAMTPROJEKT-PRUEFPROTOKOLL.md bewusst ausgelassen, weil kein passendes reales Recht existiert und keines erfunden werden sollte.

Diese Kachel verlangt jedoch alle vier Bereiche gebündelt, jede Sektion rechte-gesteuert sichtbar, ohne neue Backend-Logik/neue Rechte zu schaffen. Entscheidung (klein, reversibel, dokumentiert statt stillschweigend): alle vier Sektionen werden mit dem einzigen real existierenden, migrierten Administrations-Recht core.tenant.admin sichtbarkeitsgesteuert — exakt dasselbe Muster, das der Portal-Katalog für rbac_admin bereits anwendet (Wiederverwendung einer bestehenden Regel statt Erfindung einer neuen). Es wird keine neue Zeile in policy_rules/Migrationen ergänzt. Die vier bestehenden Oberflächen bleiben selbst unverändert (sie prüfen serverseitig weiterhin über ihren eigenen Admin-Service-Token bzw. manuell eingegebene Superadmin-ID, wie vor dieser Kachel) — die neue Steuerungsseite entscheidet nur über die Sichtbarkeit des Tabs, nicht über neue Backend-Autorisierung.

Konsequenz für Prüfung 1: da alle vier Sektionen dasselbe reale Recht nutzen, unterscheiden sich zwei Testnutzer mit unterschiedlichen Rechtekombinationen im Ergebnis "alle vier sichtbar" vs. "keine sichtbar" (nicht in einer feineren Mischung) — das ist die durch die tatsächliche Rechtelandschaft mögliche Granularität, kein Implementierungsfehler dieser Kachel.

Akzeptanzkriterien — Ergebnis

1. Eine Seite bündelt alle vier Bereiche als Tabs: erfüllt, app/ControlSections.tsx.
2. Jede Sektion nur mit zugehöriger Berechtigung sichtbar (wiederverwendet, keine neue Logik): erfüllt über core.tenant.admin, siehe Entscheidung oben.
3. Nutzer ohne jede Berechtigung sieht klar erklärte Leerdarstellung statt Fehler: erfüllt, ControlSections.tsx rendert einen erklärenden Text ohne role="alert".
4. Bestehende Einzeloberflächen bleiben unverändert und eigenständig erreichbar: erfüllt, kein Diff in web/tenant-admin, web/rbac-admin, web/lic-admin, web/notifications; jeder Tab verlinkt zusätzlich auf die Standalone-URL.

Prüfungen — Ergebnis

1. Zwei Testnutzer mit unterschiedlichen Rechtekombinationen sehen jeweils nur ihre zugelassenen Sektionen.
   • Unit-Test (app/api/visible-sections/route.test.ts): Rolle mit core.tenant.admin erhält alle vier Sektionen, Rolle ohne die Berechtigung keine — bestanden.
   • Komponententest (app/ControlSections.test.tsx, @testing-library/react, echte gemockte Sitzung/Token-Antwort): Testnutzer A (tenant_admin, Berechtigung vorhanden) sieht alle vier Tabs im DOM; Testnutzer B (user, keine Berechtigung) sieht keinen Tab — bestanden.
2. Nutzer ohne jede Berechtigung: klare Leerdarstellung, kein Fehlerzustand. Testfall in ControlSections.test.tsx prüft explizit screen.queryByRole("alert") ist null und der erklärende Text erscheint — bestanden.
3. Reale pa11y-WCAG2AA-Prüfung gegen den laufenden Produktionsbuild auf Host 204 (next build && next start, Port 39232, Chrome stable /usr/bin/google-chrome, gemockter core/policy-api liefert eine echte Sitzung mit core.tenant.admin, alle vier Tabs sichtbar gerendert): „No issues found!“
4. Bestehende Einzeloberflächen-Tests laufen unverändert grün (keine Regression). web/tenant-admin, web/rbac-admin, web/lic-admin, web/notifications haben laut Repo-Stand keine eigene Testsuite (vorbestehender Zustand, siehe docs/QA-15-F17-NEXTJS16-PRUEFPROTOKOLL.md Zeile 53) und wurden durch diese Kachel nicht angefasst (git status zeigt ausschließlich web/core-control/ als neu) — strukturell keine Regressionsmöglichkeit.

Tests

• npx vitest run (in web/core-control): 11/11 grün (app/api/visible-sections/route.test.ts 7 Fälle, app/ControlSections.test.tsx 4 Fälle).
• npx tsc --noEmit: sauber.
• npx next build: erfolgreich (3 Routen: /, /_not-found, /api/visible-sections); kein Turbopack/@nexarch/shl-Symlink-Problem aufgetreten (npm install --install-links legt von Anfang an eine Realkopie an).

Nicht Bestandteil (wie in der Kachel festgelegt)

• Keine neuen Verwaltungsfunktionen über die vier bestehenden Bereiche hinaus.
• Keine Cross-Modul-Suche oder Kennzahlen-Dashboards (ANA-01/02).
• Kein Rollout/Deploy auf Host 131.