kanban: Ticket OPS-11 (Next.js-Migration auf 16.x) anlegen

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

core-kanban/tickets/OPS-11.md

@@ -0,0 +1,59 @@
+# OPS-11 – Next.js-Migration auf 16.x (alle Web-Apps)
+
+**Epic:** 📈 Monitoring & Betrieb  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 14
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Core (Identity, Tenancy, Auth, Lizenzierung, Feature Flags, Audit, zentrale Konfiguration, API-Grundgerüst, Monitoring), das sich an den Schwächen bekannter Systeme orientiert und sie vermeidet.
+Betrieb, Bereitstellung und Härtung. Änderungen bleiben nachvollziehbar und rückbaubar.
+
+## Auftrag
+Alle 13 Web-Apps (`web/account`, `web/audit-log`, `web/dms-browser`, `web/dms-upload`, `web/kennzahlen-dashboard`, `web/lic-admin`, `web/mail-search`, `web/notifications`, `web/pdf-viewer`, `web/rbac-admin`, `web/retention-admin`, `web/status-page`, `web/tenant-admin`) nutzen `next@14.2.35` ohne aktuelle Sicherheitsupdates (Befund F-17). Anhebung auf `next@16.x` (Nutzerentscheidung 2026-09-22, statt 15.5.x).
+
+**Technische Grundlage:** `web/*/package.json`, React 19, Next.js 16 Upgrade-Anleitung
+
+## Produkt-DNA für diesen Bereich
+> Bekannte Fehler in Abhängigkeiten werden nicht mitgeschleppt.
+
+**Übernehmen:**
+- Offizielle Next.js-Upgrade-Anleitung und Codemods statt manueller Rateversuche.
+
+**Bewusst vermeiden:**
+- Keine funktionalen Änderungen über das Upgrade hinaus.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-15` Sicherheitsprüfung Gesamtprojekt – Befundbericht `docs/SICHERHEITSPRUEFUNG-GESAMTPROJEKT.md`, hier: F-17 (mittel).
+- `UX-10` Anmeldung und Bearer-Token in den Oberflächen (Sitzungsmodul in `@nexarch/shl`).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle 13 Web-Apps bauen mit `next@16.x` und React 19
+2. Keine funktionale Regression: bestehende Testsuiten je App bestehen unverändert
+3. Bekannte Next.js-16-Breaking-Changes sind berücksichtigt (asynchrone Request-APIs, Config-Schema, Middleware)
+
+## 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. `tsc` und `next build` je App
+2. Vitest-Suiten je App
+3. Browserlauf/Barrierefreiheitsprüfung im Token-Modus (falls Chrome verfügbar, sonst als offen ausweisen)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Go-Abhängigkeiten/Toolchains (OPS-09)
+- Neue Frontend-Funktionalität
+
+## 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: `OPS-11: next.js-migration auf 16.x`
+- Branch: `feature/qa-15-f17-nextjs-16-upgrade`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.