feat(compliance): P-12 sessionStorage-Bereinigung bei Logout (0.8.68)

Sicherheit P-12 (MITT-05): logout() entfernt alle sj_coach_*-Schlüssel aus sessionStorage gezielt per Präfix-Löschung. Fremde Schlüssel (Browser-Extensions etc.) bleiben erhalten. Verhindert Datenleak bei Nutzerwechsel im selben Tab (geteilter Rechner). - AuthContext.jsx: Präfix-Schleife in logout() - tests/dev-smoke-test.spec.js: Playwright-Test P-12 (injects/checks 3 sj_coach_*-Schlüssel + 1 Fremd-Schlüssel; prüft selektive Löschung) Compliance-Dokumentation: - docs/compliance-implementation.md: P-12 ✅, Version 0.8.68 - docs/compliance-package-register.md: kanonisches Paketregister (neu) - docs/compliance-roadmap.md: lebende Steuerungs-Roadmap (neu) - docs/compliance-audit.md: §20 Paket-ID-Stabilitätsregel version: 0.8.68 (backend + frontend) module: auth 1.2.0 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-10 09:08:28 +02:00 · 2026-05-10 09:08:28 +02:00 · 28ca64b5b4
commit 28ca64b5b4
parent fc33bfbdeb
8 changed files with 942 additions and 39 deletions
--- a/backend/version.py
+++ b/backend/version.py
@ -1,6 +1,6 @@
 # Shinkan Jinkendo Version Information

-APP_VERSION = "0.8.67"
+APP_VERSION = "0.8.68"
 BUILD_DATE = "2026-05-10"
 DB_SCHEMA_VERSION = "20260508049"

@ -29,6 +29,13 @@ MODULE_VERSIONS = {
 }

 CHANGELOG = [
+    {
+        "version": "0.8.68",
+        "date": "2026-05-10",
+        "changes": [
+            "Sicherheit P-12 (MITT-05): logout() bereinigt alle sj_coach_*-Schlüssel aus sessionStorage; Präfix-gezielte Löschung, keine fremden Schlüssel betroffen",
+        ],
+    },
    {
        "version": "0.8.67",
        "date": "2026-05-10",
--- a/docs/compliance-audit.md
+++ b/docs/compliance-audit.md
@ -928,4 +928,61 @@ Verwende diese exakten Formulierungen zur Freigabe einzelner Pakete:

 ---

+## 20. Regel zur Paket-ID-Stabilität
+
+> Ergänzt: 2026-05-10 — Kanonisches Referenzdokument: `docs/compliance-package-register.md`
+
+### 20.1 Grundsatz
+
+Paket-IDs (P-01 bis P-24 und alle künftigen) werden nach ihrer ersten Vergabe in diesem Dokument **nie wieder umnummeriert, gelöscht oder wiederverwendet.** Die in §17 (Umsetzungsplan) vergebenen IDs sind dauerhaft stabil.
+
+### 20.2 Regeln im Einzelnen
+
+| Regel | Beschreibung |
+|-------|-------------|
+| **ID-Stabilität** | Eine einmal vergebene Paket-ID bleibt für immer mit dem ursprünglichen fachlichen Inhalt verknüpft. |
+| **Titel-Präzisierung erlaubt** | Der Titel eines Pakets darf präzisiert werden, wenn die fachliche Substanz unverändert bleibt. Die ID ändert sich dabei nicht. |
+| **Neue Pakete** | Künftige Arbeitspakete erhalten aufsteigende neue IDs (P-25, P-26 …). Keine Wiedervergabe von IDs abgeschlossener oder gelöschter Pakete. |
+| **Nacharbeiten mit Suffix** | Nacharbeiten, Korrekturen oder Teilprobleme eines bestehenden Pakets werden mit alphabetischen Suffixen dokumentiert (P-03b, P-05b, …), nicht als eigenständige Hauptpakete. |
+| **Freigabe-Formulierung** | Freigaben müssen immer die Paket-ID **und** den kanonischen Titel aus diesem Dokument oder aus `docs/compliance-package-register.md` nennen, um Verwechslungen auszuschließen. |
+| **Kanonisches Register** | `docs/compliance-package-register.md` ist die verbindliche Quelle für alle Umsetzungsberichte, Re-Audit-Dokumente und Freigaben. Bei Widerspruch zwischen Dokumenten gilt dieses Audit als ursprüngliche Quelle; das Register als aktuell gepflegte Wahrheit. |
+
+### 20.3 Umgang mit Drift in nachgelagerten Dokumenten
+
+Falls ein nachgelagertes Dokument (Umsetzungsbericht, Re-Audit, Mini-Fix) eine abweichende Beschreibung für eine bekannte ID verwendet, gilt:
+
+1. Die abweichende Beschreibung ist ein **Dokumentationsfehler**, kein neues Paket.
+2. Das betroffene Dokument ist auf die kanonische ID und den kanonischen Titel zu korrigieren.
+3. Der Drift und die Korrektur sind im Konsistenzbericht des Paketregisters zu vermerken.
+4. Kein fachlicher Inhalt darf bei der Korrektur verloren gehen — er wird ggf. dem richtigen Paket-Eintrag zugeordnet.
+
+### 20.4 Freigabe-Vorlagen (aktualisiert)
+
+Verwende diese exakten Formulierungen zur Freigabe einzelner Pakete:
+
+| Paket | Freigabe-Formulierung |
+|-------|----------------------|
+| P-01 | „Freigabe zur Umsetzung P-01: Rechtstexte" |
+| P-02 | „Freigabe zur Umsetzung P-02: Self-Service-Kontolöschung und Datenexport" |
+| P-03 | „Freigabe zur Umsetzung P-03: Papierkorb-Retention-Job aktivieren" |
+| P-04 | „Freigabe zur Umsetzung P-04: Copyright-Pflicht für Archiv-Promotion vereinheitlichen" |
+| P-05 | „Freigabe zur Umsetzung P-05: Passwort-Mindestlänge angleichen" |
+| P-06 | „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog" |
+| P-07 | „Freigabe zur Umsetzung P-07: ALLOW_PUBLIC_MEDIA_STATIC dokumentieren und testen" |
+| P-08 | „Freigabe zur Umsetzung P-08: HSTS und externe Proxy-Sicherheit dokumentieren" |
+| P-09 | „Freigabe zur Umsetzung P-09: Admin-Audit-Log" |
+| P-10 | „Freigabe zur Umsetzung P-10: Mindestalter-Abfrage" |
+| P-11 | „Freigabe zur Umsetzung P-11: Legal-Hold Lifecycle-Status" |
+| P-12 | „Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen" |
+| P-13 | „Freigabe zur Umsetzung P-13: Content-Melde-Backend" |
+| P-17 | „Freigabe zur Umsetzung P-17: MFA für Superadmins" |
+| P-18 | „Freigabe zur Umsetzung P-18: HttpOnly-Cookie als Auth-Alternative" |
+| P-22 | „Freigabe zur Umsetzung P-22: HTML-Sanitizer für Rich-Text-Felder" |
+| Etappe 1 komplett | „Freigabe zur Umsetzung Etappe 1" |
+| Etappe 1+2 | „Freigabe zur Umsetzung Etappen 1 und 2" |
+
+> Die ursprüngliche Freigabe-Tabelle in §19.8 bleibt erhalten und zeigt den Stand des Initial-Audits. §20.4 ist die aktuellere, vollständigere Version.
+
+---
+
 *Dokument erstellt: 2026-05-09 | Auditor: Claude Code | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.*
--- a/docs/compliance-implementation.md
+++ b/docs/compliance-implementation.md
@ -3,7 +3,7 @@
 **Erstellt:** 2026-05-09  
 **Zuletzt aktualisiert:** 2026-05-10  
 **Audit-Basis:** `docs/compliance-audit.md`  
-**App-Version nach Umsetzung:** 0.8.67
+**App-Version nach Umsetzung:** 0.8.68

 ---

@ -139,40 +139,38 @@ FastAPI lehnt Requests mit `new_password < 8 Zeichen` nun mit HTTP **422** (Pyda

 ---

-### P-12 – sessionStorage bei Logout bereinigen ❌
+### P-12 – sessionStorage bei Logout bereinigen ✅

-**Status:** Nicht umgesetzt — weiterhin offen (MITT-05)
+**Status:** Umgesetzt (2026-05-10, Version 0.8.68)
+
+**Betroffene Dateien:**
+- `frontend/src/context/AuthContext.jsx` – `logout()`
+- `tests/dev-smoke-test.spec.js` – neuer Playwright-Test
+
+**Befund (war offen):**  
+`logout()` löschte nur `localStorage`-Einträge. `TrainingCoachPage` schrieb sessionStorage-Schlüssel mit Präfix `sj_coach_` (`sj_coach_step_{unitId}`, `sj_coach_deltas_{unitId}`, `sj_coach_debrief_{unitId}`), die nach Logout im Tab erhalten blieben. Bei Nutzerwechsel im selben Tab (geteilter Rechner) konnte der neue Nutzer Trainingsfortschritt des Vorgängers sehen.
+
+**Technische Änderung:**  
+Gezielte Präfix-Löschung aller `sj_coach_*`-Schlüssel beim Logout (kein `sessionStorage.clear()`). Fremde sessionStorage-Schlüssel (Browser-Extensions o. ä.) bleiben erhalten.

-**Befund:**  
-`logout()` in `frontend/src/context/AuthContext.jsx` löscht nur `localStorage`-Einträge:
 ```javascript
-const logout = () => {
-    setUser(null)
-    localStorage.removeItem('authToken')
-    localStorage.removeItem(ACTIVE_CLUB_STORAGE_KEY)
-    // sessionStorage wird NICHT geleert
+// AuthContext.jsx logout() — Ergänzung:
+for (const key of Object.keys(sessionStorage)) {
+  if (key.startsWith('sj_coach_')) {
+    sessionStorage.removeItem(key)
+  }
 }
 ```

-`TrainingCoachPage` schreibt folgende Schlüssel in `sessionStorage`:
- `storageStepKey(unitId)` – aktueller Trainingsschritt (Zahl)
- `storageDeltasKey(unitId)` – Trainingsdeltas (JSON)
- `storageDebriefKey(unitId)` – Debrief-Status (Boolean)
+**Begründung gezielte statt vollständiger Löschung:**  
+Alle Shinkan-spezifischen sessionStorage-Schlüssel sind eindeutig über den Präfix `sj_coach_` identifizierbar (definiert in `TrainingCoachPage.jsx` Zeilen 15–25). Ein `sessionStorage.clear()` würde auch Schlüssel fremder Quellen im selben Tab löschen; die Präfix-Löschung ist spezifischer und sicherer.

-Nach einem Logout bleiben diese Daten im `sessionStorage` des Tabs erhalten. Bei einem Nutzerwechsel im selben Tab (geteilter Rechner) kann der neue Nutzer Trainingsfortschritt des Vorgängers sehen, bis der Tab geschlossen wird.
+**Tests:** Playwright E2E-Test `tests/dev-smoke-test.spec.js` (Test „P-12: sessionStorage wird bei Logout bereinigt"):
+- Setzt drei `sj_coach_*`-Schlüssel und einen fremden Schlüssel
+- Klickt „Abmelden"
+- Prüft: `sj_coach_*` → null (entfernt), fremder Schlüssel → erhalten, `authToken` → null (localStorage weiterhin korrekt bereinigt)

-**Risikoeinstufung:** MITT-05 (mittleres Risiko; sessionStorage ist tab-lokal und wird beim Tab-Schließen gelöscht; erfordert physischen Zugang zum selben offenen Tab)
-
-**Fix (nicht durchgeführt, ca. 15 Minuten Aufwand):**
-```javascript
-// AuthContext.jsx logout():
-const logout = () => {
-    setUser(null)
-    localStorage.removeItem('authToken')
-    localStorage.removeItem(ACTIVE_CLUB_STORAGE_KEY)
-    sessionStorage.clear()  // oder gezielt nach 'shinkan_coach_' prefix
-}
-```
+**Hinweis Tests:** Das Projekt verfügt über kein Frontend-Unit-Test-Framework (kein Vitest/Jest in package.json). Der Test ist als Playwright E2E-Test implementiert, der einen laufenden Dev-Server voraussetzt. Automatisierte Ausführung der Playwright-Tests erfordert `npx playwright test` mit gesetzter `PLAYWRIGHT_BASE_URL`.

 ---

@ -222,16 +220,29 @@ Fehlgeschlagener Test: test_list_media_assets_invalid_lifecycle_400

 ## Nicht umgesetzte Pakete

-| Paket | Status | Begründung |
-|-------|--------|------------|
-| P-01 | offen | Rechtstexte — Scope ausgeschlossen |
-| P-02 | offen | Self-Service-Löschworkflow — Scope ausgeschlossen |
-| P-06 | offen | HSTS-Header — Scope ausgeschlossen |
-| P-09 | offen | Kein Einwilligungsdialog Recht am eigenen Bild — Scope ausgeschlossen |
-| P-10 | offen | DSA-Meldeverfahren — Scope ausgeschlossen |
-| P-11 | offen | HttpOnly-Cookie-Migration — Scope ausgeschlossen |
-| P-12 | offen | sessionStorage bei Logout — nicht freigegeben, Aufwand ca. 15 min |
-| P-13–P-16 | offen | Scope ausgeschlossen |
+> Paket-IDs und -Titel gemäß kanonischem Register `docs/compliance-package-register.md`.
+> Abweichende Beschreibungen in der Ursprungsversion dieses Abschnitts wurden am 2026-05-10 korrigiert (P-06, P-08, P-09, P-10, P-11, P-18 — Details im Konsistenzbericht des Registers).
+
+| Paket | Kanonischer Titel | Status | Begründung |
+|-------|------------------|--------|------------|
+| P-01 | Rechtstexte | offen | Scope ausgeschlossen (juristischer Inhalt) |
+| P-02 | Self-Service-Kontolöschung + Datenexport | offen | Scope ausgeschlossen |
+| P-06 | Upload-Einwilligungsdialog (Recht am eigenen Bild) | offen | Scope ausgeschlossen |
+| P-08 | HSTS / externe Proxy-Sicherheit dokumentieren | offen | Scope ausgeschlossen (außerhalb Repo — Reverse-Proxy) |
+| P-09 | Admin-Audit-Log | offen | Scope ausgeschlossen |
+| P-10 | Mindestalter-Abfrage | offen | Scope ausgeschlossen |
+| P-11 | Legal-Hold Lifecycle-Status | offen | Scope ausgeschlossen |
+| P-12 | sessionStorage bei Logout bereinigen | ✅ umgesetzt | Version 0.8.68 — siehe §P-12 oben |
+| P-13 | Content-Melde-Backend | offen | Scope ausgeschlossen (erst juristisch klären) |
+| P-14 | Moderations-UI | offen | Scope ausgeschlossen |
+| P-15 | Uploader-Benachrichtigung bei Sperrung | offen | Scope ausgeschlossen |
+| P-16 | Beschwerdeverfahren | offen | Scope ausgeschlossen |
+| P-17 | MFA für Superadmins (TOTP) | offen | Scope ausgeschlossen |
+| P-18 | HttpOnly-Cookie als Auth-Alternative | offen | Scope ausgeschlossen |
+| P-19 | Anti-Virus-Scan (ClamAV) | offen | Scope ausgeschlossen |
+| P-20 | VVT erstellen | offen | Scope ausgeschlossen (Betreiber-Aufgabe) |
+| P-21 | AV-Verträge abschließen | offen | Scope ausgeschlossen (Betreiber-Aufgabe) |
+| P-22 | HTML-Sanitizer für Rich-Text-Felder | offen | Scope ausgeschlossen |

 ---

--- a/docs/compliance-package-register.md
+++ b/docs/compliance-package-register.md
@ -0,0 +1,433 @@
+# Compliance-Paketregister – Shinkan Jinkendo
+
+**Typ:** Kanonisches Referenzdokument  
+**Erstellt:** 2026-05-10  
+**Basisdokument:** `docs/compliance-audit.md` (Initial-Audit 2026-05-09, App-Version 0.8.65)  
+**Letzte Aktualisierung:** 2026-05-10 (App-Version 0.8.67)
+
+---
+
+> **Verbindliche Regel:** Paket-IDs werden nach ihrer ersten Vergabe in `docs/compliance-audit.md` nie wieder umnummeriert oder wiederverwendet. Dieses Dokument ist der kanonische Verweis für alle Freigaben, Umsetzungsberichte und Audits. Abweichende Nummerierungen in nachgelagerten Dokumenten sind Fehler und müssen auf die kanonische ID korrigiert werden. Nacharbeiten zu einem Paket erhalten Suffixe (z. B. P-03b, P-05b), keine neue Hauptnummer.
+
+---
+
+## Status-Legende
+
+| Symbol | Bedeutung |
+|--------|-----------|
+| ✅ implemented | Vollständig umgesetzt und getestet |
+| ⚠️ partially implemented | Teilweise umgesetzt; Nacharbeit dokumentiert |
+| ❌ open | Nicht umgesetzt, offen |
+| 🔒 scope excluded | Bewusst außerhalb des technischen Umsetzungsscopes |
+
+---
+
+## Etappe 1 – Pflicht vor öffentlichem Betrieb
+
+### P-01 – Rechtstexte
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Rechtstexte (Impressum, Datenschutzerklärung, AGB, Medienrichtlinie) |
+| **Findings** | KRIT-01 |
+| **Etappe** | 1 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Technische Routen fehlen. Inhalt durch Rechtsanwalt erforderlich. |
+| **Verweise** | `docs/compliance-audit.md` §14.2, §17, §19.1 |
+| **Hinweise** | Keine Nummerierungsabweichung in nachgelagerten Dokumenten festgestellt. |
+
+---
+
+### P-02 – Self-Service-Kontolöschung + Datenexport
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Self-Service-Kontolöschung und Datenexport (DSGVO Art. 17, 15, 20) |
+| **Findings** | KRIT-02, KRIT-05 |
+| **Etappe** | 1 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. `DELETE /api/profiles/{pid}` nur für Plattform-Admin. |
+| **Verweise** | `docs/compliance-audit.md` §7.3, §11.2, §17 |
+| **Hinweise** | In `docs/compliance-implementation.md` als „Self-Service-Löschworkflow" bezeichnet — inhaltlich korrekt, Titel leicht abgekürzt. |
+
+---
+
+### P-03 – Papierkorb-Retention-Job aktivieren
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Papierkorb-Retention-Job aktivieren (automatische tägliche Ausführung) |
+| **Findings** | KRIT-07 |
+| **Etappe** | 1 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt in Version 0.8.66. Neuer Docker-Service `retention-cron` in `docker-compose.yml`. Python-basierter Loop, täglich 03:00 Uhr. |
+| **Nacharbeit** | P-03b (Retention-Zeiten mit Löschkonzept abgleichen) — siehe unten |
+| **Verweise** | `docs/compliance-audit.md` §9.2, §17; `docs/compliance-implementation.md` §P-03 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+#### P-03b – Nacharbeit: Retention-Zeiten mit Löschkonzept abgleichen
+
+| Feld | Inhalt |
+|------|--------|
+| **Typ** | Nacharbeit zu P-03 (kein eigenes Hauptpaket) |
+| **Status** | ✅ implemented (2026-05-10, Version 0.8.67) |
+| **Befund** | Default `HIDDEN_TO_PURGE_DAYS` war 90 Tage; fachliches Löschkonzept sieht 30+30 vor. |
+| **Änderung** | `backend/media_lifecycle.py`: Default `"90"` → `"30"`; `docker-compose.yml`: Env-Variable dokumentiert. |
+| **Verweise** | `docs/compliance-implementation.md` §P-03b |
+
+---
+
+### P-04 – Copyright-Pflicht für Archiv-Promotion vereinheitlichen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Copyright-Pflicht bei Archiv-Promotion vereinheitlichen |
+| **Findings** | KRIT-06 |
+| **Etappe** | 1 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt in Version 0.8.66. `patch_media_asset()` und `bulk_media_patch()` erzwingen `copyright_notice` bei Promotion auf `club`/`official`. 7 Tests, alle grün. |
+| **Verweise** | `docs/compliance-audit.md` §6.3, §8.1, §17; `docs/compliance-implementation.md` §P-04; `backend/tests/test_media_assets_copyright_promotion.py` |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-05 – Passwort-Mindestlänge angleichen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Passwort-Mindestlänge angleichen (alle Endpoints: mindestens 8 Zeichen) |
+| **Findings** | MITT-01, SEC-04, SEC-12, NIED-06 |
+| **Etappe** | 1 |
+| **Status** | ✅ implemented (vollständig, inkl. P-05b) |
+| **Letzter Stand** | Version 0.8.66: `PUT /api/auth/pin`, `LoginPage.jsx`, `AccountSettingsPage.jsx`. Version 0.8.67: `POST /api/auth/reset-password` via P-05b. Alle 6 Punkte geschlossen. |
+| **Nacharbeit** | P-05b (`reset-password` Mindestlänge) — siehe unten |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-04, SEC-12), §16 (MITT-01); `docs/compliance-implementation.md` §P-05, §P-05b |
+| **Hinweise** | P-05 gilt als vollständig geschlossen nach Abschluss von P-05b (2026-05-10). |
+
+#### P-05b – Nacharbeit: reset-password Mindestlänge
+
+| Feld | Inhalt |
+|------|--------|
+| **Typ** | Nacharbeit zu P-05 (kein eigenes Hauptpaket) |
+| **Status** | ✅ implemented (2026-05-10, Version 0.8.67) |
+| **Befund** | `POST /api/auth/reset-password` hatte kein Mindestlängen-Limit im Backend. |
+| **Änderung** | `backend/models.py`: `PasswordResetConfirm.new_password = Field(min_length=8, max_length=128)`. 7 neue Tests. |
+| **Verweise** | `docs/compliance-implementation.md` §P-05b; `backend/tests/test_auth_password_reset_minlength.py` |
+
+---
+
+### P-06 – Upload-Einwilligungsdialog
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Upload-Einwilligungsdialog (Recht am eigenen Bild, Personen, Minderjährige) |
+| **Findings** | KRIT-04 |
+| **Etappe** | 1 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Keine Pflicht-Einwilligung beim Medienupload. Juristisch zu prüfen (§22 KUG, §8 DSGVO). |
+| **Verweise** | `docs/compliance-audit.md` §8.2, §8.3, §11.4, §17 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) wurde P-06 fälschlich als „HSTS-Header" beschrieben. Der korrekte Titel ist „Upload-Einwilligungsdialog". HSTS gehört zu P-08. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+## Etappe 2 – Sicherheit und Datenschutz
+
+### P-07 – ALLOW_PUBLIC_MEDIA_STATIC dokumentieren + Test
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | ALLOW_PUBLIC_MEDIA_STATIC dokumentieren und Release-Test einrichten |
+| **Findings** | HOCH-01, SEC-05 |
+| **Etappe** | 2 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt in Version 0.8.66. 2 Tests in `test_security_release.py`: Flag deaktiviert per Default; Flag aktiviert mounted `/media`. |
+| **Verweise** | `docs/compliance-audit.md` §13.5, §17; `docs/compliance-implementation.md` §P-07; `backend/tests/test_security_release.py` |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-08 – HSTS / externe Proxy-Sicherheit dokumentieren
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | HSTS und externe Proxy-Sicherheit dokumentieren |
+| **Findings** | HOCH-02, SEC-01 |
+| **Etappe** | 2 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. HSTS liegt außerhalb des Repo-Scopes (Reverse-Proxy/Fritz!Box). Betreiber-Verantwortung. |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-01), §19.7 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) fehlte P-08 vollständig in der „Nicht umgesetzte Pakete"-Tabelle. Der Inhalt „HSTS-Header" war fälschlich P-06 zugeordnet. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+### P-09 – Admin-Audit-Log
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Admin-Audit-Log (Protokollierung von Admin-Aktionen) |
+| **Findings** | HOCH-05, SEC-07 |
+| **Etappe** | 2 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Keine `admin_audit_log`-Tabelle vorhanden. Profil-Löschungen und Lifecycle-Aktionen nicht protokolliert. |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-07), §16 (HOCH-05), §17 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) wurde P-09 fälschlich als „Kein Einwilligungsdialog Recht am eigenes Bild" beschrieben. Der korrekte Titel ist „Admin-Audit-Log". Der Einwilligungsdialog gehört zu P-06. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+### P-10 – Mindestalter-Abfrage
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Mindestalter-Abfrage bei Registrierung |
+| **Findings** | HOCH-06 |
+| **Etappe** | 2 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Keine Altersverifikation bei Registrierung. Juristisch zu prüfen (§8 DSGVO). |
+| **Verweise** | `docs/compliance-audit.md` §11.4, §16 (HOCH-06), §17 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) wurde P-10 fälschlich als „DSA-Meldeverfahren" beschrieben. Der korrekte Titel ist „Mindestalter-Abfrage". Das DSA-Meldeverfahren gehört zu P-13–P-16. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+### P-11 – Legal-Hold Lifecycle-Status
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Legal-Hold Lifecycle-Status (Sofortsperrung bei Rechtsverletzung) |
+| **Findings** | MITT-02 |
+| **Etappe** | 2 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Stufe-1-Papierkorb dauert 30 Tage bis zur vollständigen Unsichtbarkeit. Kein direkter Sperr-Status. |
+| **Verweise** | `docs/compliance-audit.md` §9.2, §16 (MITT-02), §17 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) wurde P-11 fälschlich als „HttpOnly-Cookie-Migration" beschrieben. Der korrekte Titel ist „Legal-Hold Lifecycle-Status". HttpOnly-Cookie gehört zu P-18. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+### P-12 – sessionStorage bei Logout bereinigen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | sessionStorage bei Logout bereinigen |
+| **Findings** | MITT-05 |
+| **Etappe** | 2 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt 2026-05-10, Version 0.8.68. `logout()` in `AuthContext.jsx` löscht jetzt alle `sj_coach_*`-Schlüssel via Präfix-Iteration. Gezielte Löschung (kein `sessionStorage.clear()`), fremde Schlüssel bleiben erhalten. Playwright-Test ergänzt in `tests/dev-smoke-test.spec.js`. |
+| **Verweise** | `docs/compliance-audit.md` §5.6, §16 (MITT-05), §17; `docs/compliance-implementation.md` §P-12; `frontend/src/context/AuthContext.jsx`; `tests/dev-smoke-test.spec.js` |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-22 – HTML-Sanitizer für Rich-Text-Felder
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | HTML-Sanitizer für Rich-Text-Felder (bleach/nh3 Allowlist) |
+| **Findings** | NIED-09, SEC-11 |
+| **Etappe** | 2 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. `exercise_rich_text.py` normalisiert nur Inline-Media-Markup. Beliebiges HTML in `summary`, `goal`, `execution`, `preparation`, `trainer_notes` möglich. CSP schützt gegen Script-Execution. |
+| **Verweise** | `docs/compliance-audit.md` §13.3 (SEC-11), §13.2 (NIED-09), §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-23 – LoginPage: minLength angleichen + Versionsstring entfernen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | LoginPage: minLength angleichen und hartcodierten Versionsstring entfernen |
+| **Findings** | NIED-06, NIED-07, SEC-12, SEC-13 |
+| **Etappe** | 2 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt in Version 0.8.66. `minLength="6"` → `"8"`; Versionsstring `v0.1.0 • Development` entfernt. |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-12, SEC-13, NIED-06, NIED-07), §17; `docs/compliance-implementation.md` §P-23 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-24 – CORS einschränken
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | CORS allow_methods und allow_headers auf tatsächlich benötigte Werte einschränken |
+| **Findings** | NIED-08, SEC-14 |
+| **Etappe** | 2 |
+| **Status** | ✅ implemented |
+| **Letzter Stand** | Umgesetzt in Version 0.8.66. `allow_methods=["GET","POST","PUT","PATCH","DELETE","OPTIONS"]`; `allow_headers=["Content-Type","X-Auth-Token","X-Active-Club-Id"]`. |
+| **Verweise** | `docs/compliance-audit.md` §13.3, §17; `docs/compliance-implementation.md` §P-24 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+## Etappe 3 – DSA-Meldeverfahren
+
+### P-13 – Content-Melde-Backend
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Content-Melde-Backend (content_reports-Tabelle + Endpoints) |
+| **Findings** | KRIT-03 |
+| **Etappe** | 3 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Juristisch zu klären (DSA-Anwendungsbereich). Technische Spec vorhanden in `docs/compliance-audit.md` §17. |
+| **Verweise** | `docs/compliance-audit.md` §12, §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-14 – Moderations-UI
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Moderations-UI (Frontend für Moderation-Queue) |
+| **Findings** | KRIT-03 |
+| **Etappe** | 3 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Abhängig von P-13. |
+| **Verweise** | `docs/compliance-audit.md` §12, §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-15 – Uploader-Benachrichtigung bei Sperrung
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Uploader-Benachrichtigung bei Sperrung oder Löschung |
+| **Findings** | KRIT-03 |
+| **Etappe** | 3 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Kein Benachrichtigungssystem vorhanden. |
+| **Verweise** | `docs/compliance-audit.md` §9.2, §12, §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-16 – Beschwerdeverfahren
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Beschwerdeverfahren (Nutzer-Rechtsbehelfsweg gegen Moderationsentscheidungen) |
+| **Findings** | KRIT-03 |
+| **Etappe** | 3 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Abhängig von P-13–P-15. |
+| **Verweise** | `docs/compliance-audit.md` §12, §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+## Etappe 4 – Langfristige Optimierungen
+
+### P-17 – MFA für Superadmins (TOTP)
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | MFA für Superadmins (TOTP-Zweifaktorauthentifizierung) |
+| **Findings** | HOCH-04, SEC-06 |
+| **Etappe** | 4 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Kein TOTP/OTP implementiert. |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-06), §16 (HOCH-04), §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-18 – HttpOnly-Cookie als Auth-Alternative
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | HttpOnly-Cookie als Auth-Alternative (XSS-Schutz für Auth-Token) |
+| **Findings** | HOCH-03, SEC-02 |
+| **Etappe** | 4 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Auth-Token liegt weiterhin in `localStorage`. Größere Architekturänderung erforderlich. |
+| **Verweise** | `docs/compliance-audit.md` §10.3, §13.2 (SEC-02), §17 |
+| **Hinweise** | **Drift-Hinweis:** In `docs/compliance-implementation.md` (vor Korrektur 2026-05-10) wurde der Inhalt „HttpOnly-Cookie-Migration" fälschlich P-11 zugeordnet. Der korrekte Titel gehört zu P-18. Korrigiert in `docs/compliance-implementation.md`. |
+
+---
+
+### P-19 – Anti-Virus-Scan (ClamAV)
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Anti-Virus-Scan für Uploads (ClamAV oder vergleichbar) |
+| **Findings** | NIED-02, SEC-10 |
+| **Etappe** | 4 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Hoher Aufwand, Risiko bei lokalem Storage gering. |
+| **Verweise** | `docs/compliance-audit.md` §13.2 (SEC-10), §16 (NIED-02), §17 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-20 – VVT erstellen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | Verzeichnis der Verarbeitungstätigkeiten (VVT) erstellen (DSGVO Art. 30) |
+| **Findings** | MITT-03 |
+| **Etappe** | 4 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Betreiber-Aufgabe. Identifizierte Verarbeitungsvorgänge in `docs/compliance-audit.md` §11.1. |
+| **Verweise** | `docs/compliance-audit.md` §11.1, §17, §19.6 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+### P-21 – AV-Verträge abschließen
+
+| Feld | Inhalt |
+|------|--------|
+| **Kanonischer Titel** | AV-Verträge mit Auftragsverarbeitern abschließen (SMTP, MediaWiki, OpenRouter) |
+| **Findings** | MITT-04, MITT-07, MITT-08 |
+| **Etappe** | 4 |
+| **Status** | ❌ open |
+| **Letzter Stand** | Nicht umgesetzt. Betreiber-Aufgabe. Drei identifizierte Auftragsverarbeiter ohne Vertrag. |
+| **Verweise** | `docs/compliance-audit.md` §11.3, §17, §19.6 |
+| **Hinweise** | Keine Nummerierungsabweichung festgestellt. |
+
+---
+
+## Übersichtstabelle aller Pakete
+
+| ID | Kanonischer Titel | Etappe | Findings | Status |
+|----|------------------|--------|----------|--------|
+| P-01 | Rechtstexte | 1 | KRIT-01 | ❌ open |
+| P-02 | Self-Service-Kontolöschung + Datenexport | 1 | KRIT-02, KRIT-05 | ❌ open |
+| P-03 | Papierkorb-Retention-Job aktivieren | 1 | KRIT-07 | ✅ implemented |
+| P-03b | _Nacharbeit:_ Retention-Zeiten mit Löschkonzept abgleichen | — | — | ✅ implemented |
+| P-04 | Copyright-Pflicht für Archiv-Promotion vereinheitlichen | 1 | KRIT-06 | ✅ implemented |
+| P-05 | Passwort-Mindestlänge angleichen | 1 | MITT-01, SEC-04, SEC-12, NIED-06 | ✅ implemented |
+| P-05b | _Nacharbeit:_ reset-password Mindestlänge | — | — | ✅ implemented |
+| P-06 | Upload-Einwilligungsdialog | 1 | KRIT-04 | ❌ open |
+| P-07 | ALLOW_PUBLIC_MEDIA_STATIC dokumentieren + Test | 2 | HOCH-01, SEC-05 | ✅ implemented |
+| P-08 | HSTS / externe Proxy-Sicherheit dokumentieren | 2 | HOCH-02, SEC-01 | ❌ open |
+| P-09 | Admin-Audit-Log | 2 | HOCH-05, SEC-07 | ❌ open |
+| P-10 | Mindestalter-Abfrage | 2 | HOCH-06 | ❌ open |
+| P-11 | Legal-Hold Lifecycle-Status | 2 | MITT-02 | ❌ open |
+| P-12 | sessionStorage bei Logout bereinigen | 2 | MITT-05 | ✅ implemented |
+| P-13 | Content-Melde-Backend | 3 | KRIT-03 | ❌ open |
+| P-14 | Moderations-UI | 3 | KRIT-03 | ❌ open |
+| P-15 | Uploader-Benachrichtigung bei Sperrung | 3 | KRIT-03 | ❌ open |
+| P-16 | Beschwerdeverfahren | 3 | KRIT-03 | ❌ open |
+| P-17 | MFA für Superadmins (TOTP) | 4 | HOCH-04, SEC-06 | ❌ open |
+| P-18 | HttpOnly-Cookie als Auth-Alternative | 4 | HOCH-03, SEC-02 | ❌ open |
+| P-19 | Anti-Virus-Scan (ClamAV) | 4 | NIED-02, SEC-10 | ❌ open |
+| P-20 | VVT erstellen | 4 | MITT-03 | ❌ open |
+| P-21 | AV-Verträge abschließen | 4 | MITT-04, MITT-07, MITT-08 | ❌ open |
+| P-22 | HTML-Sanitizer für Rich-Text-Felder | 2 | NIED-09, SEC-11 | ❌ open |
+| P-23 | LoginPage: minLength angleichen + Versionsstring entfernen | 2 | NIED-06, NIED-07, SEC-12, SEC-13 | ✅ implemented |
+| P-24 | CORS einschränken (Methoden + Header) | 2 | NIED-08, SEC-14 | ✅ implemented |
+
+---
+
+## Fortschritt
+
+**Implementiert:** P-03, P-03b, P-04, P-05, P-05b, P-07, P-12, P-23, P-24 — 9 Pakete (inkl. 2 Nacharbeiten)  
+**Offen:** P-01, P-02, P-06, P-08, P-09, P-10, P-11, P-13, P-14, P-15, P-16, P-17, P-18, P-19, P-20, P-21, P-22 — 17 Pakete  
+**App-Version bei letzter Aktualisierung:** 0.8.68  
+**Letztes Umsetzungsdatum:** 2026-05-10
+
+---
+
+*Erstellt: 2026-05-10 | Quelle: `docs/compliance-audit.md` (Initial-Audit 2026-05-09) | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.*
--- a/docs/compliance-roadmap.md
+++ b/docs/compliance-roadmap.md
@ -0,0 +1,349 @@
+# Compliance-Roadmap – Shinkan Jinkendo
+
+**Typ:** Lebendes Steuerungsdokument  
+**Erstellt:** 2026-05-10  
+**App-Version:** 0.8.68  
+**Zuletzt aktualisiert:** 2026-05-10
+
+---
+
+## 1. Zweck und Geltung
+
+Dieses Dokument steuert die aktuelle Priorisierung, Release-Readiness und nächste Freigabeschritte für das Compliance-Programm. Es ersetzt **keines** der folgenden Dokumente, sondern ergänzt sie:
+
+| Dokument | Rolle |
+|----------|-------|
+| `docs/compliance-audit.md` | Historischer Initialbefund (unveränderlich als Quelle) |
+| `docs/compliance-package-register.md` | Kanonische Quelle für Paket-IDs und aktuellen Paketstatus |
+| `docs/compliance-implementation.md` | Chronologischer Umsetzungsnachweis |
+| **`docs/compliance-roadmap.md`** | **Aktuelle Prioritäten, Release-Gates, nächste Freigaben** |
+
+**Bindungsregeln:**
+- Paket-IDs → immer aus dem Paketregister
+- Historische Findings und Severity-Einstufungen → immer aus dem Initial-Audit
+- Aktuelle Reihenfolge und Freigabeempfehlungen → **dieses Dokument**
+
+Diese Roadmap ist nach jedem Re-Audit zu aktualisieren. Abweichungen von der bisherigen Priorität werden mit Datum und Begründung dokumentiert (→ §4, §10).
+
+---
+
+## 2. Aktueller Stand (2026-05-10)
+
+### App-Version: 0.8.67
+
+### Geschlossene Pakete
+
+| ID | Titel | Version |
+|----|-------|---------|
+| P-03 | Papierkorb-Retention-Job aktivieren | 0.8.66 |
+| P-03b | _Nacharbeit:_ Retention-Zeiten 30+30 Tage | 0.8.67 |
+| P-04 | Copyright-Pflicht für Archiv-Promotion vereinheitlichen | 0.8.66 |
+| P-05 | Passwort-Mindestlänge angleichen (alle Endpoints) | 0.8.66–0.8.67 |
+| P-05b | _Nacharbeit:_ reset-password Mindestlänge | 0.8.67 |
+| P-07 | ALLOW_PUBLIC_MEDIA_STATIC dokumentieren + Release-Test | 0.8.66 |
+| P-12 | sessionStorage bei Logout bereinigen | 0.8.68 |
+| P-23 | LoginPage: minLength angleichen + Versionsstring entfernen | 0.8.66 |
+| P-24 | CORS einschränken (Methoden + Header) | 0.8.66 |
+
+**Abgeschlossene Pakete:** 7 Hauptpakete + 2 Nacharbeiten = 9 Umsetzungseinheiten
+
+### Offene Pakete (17)
+
+P-01, P-02, P-06, P-08, P-09, P-10, P-11, P-13, P-14, P-15, P-16, P-17, P-18, P-19, P-20, P-21, P-22
+
+### Gesamtstatus
+
+> **⛔ Nicht öffentlich freigabefähig**
+
+**Begründung:** Die App kann im aktuellen Zustand nicht für allgemeine öffentliche Registrierung beworben oder aktiv vermarktet werden. Folgende zwingende Voraussetzungen fehlen noch:
+
+1. **P-01:** Kein Impressum, keine Datenschutzerklärung, keine AGB. Eine öffentlich erreichbare App ohne Impressum ist eine Ordnungswidrigkeit nach TMG §5.
+2. **P-06:** Keine Einwilligungserklärung beim Medienupload. Personenbilder können ohne jede Rechteabklärung hochgeladen werden.
+3. **P-02:** Nutzer können ihr Konto nicht selbst löschen (DSGVO Art. 17). Der Prozess ist noch nicht einmal fachlich spezifiziert.
+4. **P-13:** Keine Möglichkeit, rechtswidrige Inhalte zu melden. Bei einer UGC-Plattform mit öffentlichen Inhalten ist dies ein erhebliches Restrisiko, unabhängig davon, ob der DSA formal anwendbar ist.
+5. **P-11:** Kein Legal-Hold-Status. Bei erkannten Rechtsverletzungen dauert es bis zu 30 Tage, bis Inhalte vollständig ausgeblendet sind.
+
+**Was geöffnet bleiben kann (mit Dokumentation):** Vereinsinterne Nutzung durch bekannte Trainer-Gruppen ist mit dem aktuellen Stand vertretbar, solange keine öffentliche Vermarktung stattfindet und kein `official`-Content aktiviert wird.
+
+---
+
+## 3. Aktuelle Blocker vor öffentlichem Betrieb
+
+Die folgenden Pakete sind vor der Freigabe für allgemeine öffentliche Registrierung zwingend zu adressieren. Die Reihenfolge entspricht der in §5 definierten Umsetzungsreihenfolge.
+
+### Blocker 1 — P-01: Rechtstexte
+
+**Finding:** KRIT-01 (Ordnungswidrigkeit, TMG §5)  
+**Warum zwingend:** Eine öffentlich erreichbare App ohne Impressum ist seit dem ersten Tag der öffentlichen Zugänglichkeit bußgeldbewehrt. Auch eine Beta-/Invite-Only-Phase ohne Impressum trägt dieses Risiko, sobald die URL öffentlich bekannt ist.  
+**Abhängigkeit:** Technische Seiten können sofort angelegt werden (Platzhalter). Inhalt erfordert Rechtsanwalt.
+
+### Blocker 2 — P-06: Upload-Einwilligungsdialog
+
+**Finding:** KRIT-04 (§22 KUG, §8 DSGVO)  
+**Warum zwingend:** Jeder hochgeladene Bildinhalt mit erkennbaren Personen ist ohne dokumentierte Einwilligung rechtlich problematisch. Das Risiko besteht nicht erst bei öffentlichen Inhalten — es beginnt beim Upload.  
+**Abhängigkeit:** Keine; kann als Frontend-Dialog mit Backend-Flag implementiert werden.
+
+### Blocker 3 — P-11: Legal-Hold Lifecycle-Status
+
+**Finding:** MITT-02  
+**Warum jetzt statt Etappe 2:** Der aktuelle Papierkorb-Mechanismus reicht für reaktive Maßnahmen bei Rechtsverletzungen nicht aus. Zwischen Meldung und vollständiger Unsichtbarkeit liegen bis zu 30 Tage (Stufe 1). Für eine Plattform mit öffentlichen Inhalten ist das nicht akzeptabel.  
+**Abhängigkeit:** Sinnvoll mit P-13 zusammen umzusetzen (Moderationssystem braucht direkten Sperr-Status).
+
+### Blocker 4 — P-13: Content-Melde-Backend (Minimalversion)
+
+**Finding:** KRIT-03  
+**Warum vorgezogen (Abweichung vom Initial-Audit):** → Siehe §4  
+**Minimalumfang:** Meldung einreichen + Moderations-Queue für Admin. Nicht der volle P-14–P-16-Stack.  
+**Abhängigkeit:** P-11 (Legal-Hold) für direkte Reaktion auf Meldungen empfohlen.
+
+### Blocker 5 — P-02: DSGVO-Self-Service (fachliche Spezifikation zuerst)
+
+**Finding:** KRIT-02, KRIT-05  
+**Warum zuerst spezifizieren, dann umsetzen:** P-02 berührt Kontolöschung, Medienarchiv, Vereinsinhalte, Backups und Fristen. Eine voreilige Implementierung riskiert unvollständige oder juristisch falsche Umsetzung. → Erst spezifizieren (→ §5 Etappe C), dann freigeben.  
+**Juristisch zu klären:** Anonymisierung vs. Löschung bei Vereinsinhalten; Backup-Retention-Policy.
+
+### Blocker 6 — P-08: HSTS-Betriebsnachweis (Betreiber-Aufgabe)
+
+**Finding:** HOCH-02, SEC-01  
+**Status:** Außerhalb des Repo-Scopes. HSTS muss am externen Reverse-Proxy (Fritz!Box → Synology → Nginx) konfiguriert sein.  
+**Anforderung:** Vor öffentlichem Betrieb: manueller Nachweis (z. B. `curl -I https://shinkan.jinkendo.de` zeigt `Strict-Transport-Security`-Header).  
+**Nicht im Code zu lösen** — aber als Release-Gate dokumentiert (→ §7).
+
+---
+
+## 4. Abweichungen gegenüber der ursprünglichen Audit-Reihenfolge
+
+### P-13 wird vorgezogen (Etappe 3 → Etappe B)
+
+Das Initial-Audit (`docs/compliance-audit.md` §17) ordnete P-13–P-16 (DSA-Meldeverfahren) in Etappe 3 ein, nach den Sicherheits- und Datenschutzpaketen von Etappe 2. Die Begründung war: juristische Klärung des DSA-Anwendungsbereichs zuerst.
+
+**Aktuelle Einschätzung (2026-05-10):** Diese Reihenfolge bleibt für den vollen DSA-Stack (P-14–P-16) richtig. Für den Kern von P-13 — die technische Möglichkeit, eine Inhaltsmeldung abzugeben und zu bearbeiten — ist eine Vorziehung geboten, weil:
+
+- Die App erlaubt bereits jetzt Upload und Anzeige von Nutzerinhalten mit `official`-Sichtbarkeit
+- Das Risiko ungemeldeter Rechtsverletzungen ist kein langfristiges, sondern ein unmittelbares
+- Die juristische DSA-Bewertung (ab welcher Nutzerzahl, welche Pflichten) bleibt offen — sie entscheidet über den Umfang, nicht über das Ob einer Grundfähigkeit
+- Eine minimale Melde-Queue kostet weniger als P-14–P-16 zusammen und schafft handlungsfähige Grundstruktur
+
+**Keine ID-Änderung:** P-13 bleibt P-13. Die Neuprioritisierung ist eine Planungsentscheidung, keine inhaltliche Änderung des Pakets.
+
+### P-22 (HTML-Sanitizer) bleibt in Etappe D
+
+Das Initial-Audit platzierte P-22 in Etappe 2. Die aktuelle Einschätzung: CSP `script-src 'self'` reduziert das XSS-Risiko für eingeloggte Nutzer erheblich. Das Risiko ist real, aber kein harter Blocker vor öffentlichem Betrieb im Vergleich zu P-01, P-06, P-11, P-13. P-22 bleibt auf der Roadmap, wird aber nicht als Release-Gate behandelt.
+
+---
+
+## 5. Aktuell empfohlene Umsetzungsreihenfolge
+
+### Etappe A – Sofortmaßnahme (ca. 15 Minuten)
+
+| Paket | Titel | Aufwand | Freigabe-Formulierung |
+|-------|-------|---------|----------------------|
+| P-12 | sessionStorage bei Logout bereinigen | ~15 min | „Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen" |
+
+**Begründung:** Minimaler Aufwand, bereits vollständig dokumentiert mit Fix-Code in `docs/compliance-implementation.md` §P-12. Schließt MITT-05. Keine Abhängigkeiten. Sollte nicht weiter offen bleiben.
+
+---
+
+### Etappe B – Technische Grundlagen für öffentlichen Betrieb
+
+Reihenfolge innerhalb der Etappe ist flexibel; P-01 und P-06 haben keine gegenseitige Abhängigkeit.
+
+| Paket | Titel | Aufwand | Abhängigkeit | Freigabe-Formulierung |
+|-------|-------|---------|-------------|----------------------|
+| P-01 | Rechtstexte technisch anlegen (Platzhalter-Seiten, Routen) | 2–4 h Technik | Inhalt durch Rechtsanwalt separat | „Freigabe zur Umsetzung P-01: Rechtstexte" |
+| P-06 | Upload-Einwilligungsdialog | 2–4 Tage | — | „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog" |
+| P-11 | Legal-Hold Lifecycle-Status | 2–3 Tage | sinnvoll vor P-13 | „Freigabe zur Umsetzung P-11: Legal-Hold Lifecycle-Status" |
+| P-13 | Content-Melde-Backend (Minimalversion) | 3–5 Tage | P-11 empfohlen | „Freigabe zur Umsetzung P-13: Content-Melde-Backend" |
+
+**Hinweis P-01:** Die technische Anlage (leere Seiten, Routen `/impressum`, `/datenschutz`, `/nutzungsbedingungen`) ist von der juristischen Ausarbeitung des Inhalts zu trennen. Beide Teilschritte können unabhängig voneinander freigegeben und durchgeführt werden.
+
+**Hinweis P-13 Minimalumfang:** Im Rahmen von Etappe B umfasst P-13 ausschließlich:
+- `POST /api/reports` — Meldung einreichen
+- `GET /api/admin/reports` — Moderations-Queue
+- `PATCH /api/admin/reports/{id}` — Status setzen
+
+P-14 (Moderations-UI), P-15 (Uploader-Benachrichtigung), P-16 (Beschwerdeverfahren) folgen in Etappe D.
+
+---
+
+### Etappe C – DSGVO-Self-Service sauber spezifizieren (vor Umsetzungsfreigabe)
+
+P-02 erhält eine eigene Spezifikationsphase, bevor eine Umsetzungsfreigabe erteilt wird. Zu klärende Punkte:
+
+| Frage | Entscheidungsträger |
+|-------|---------------------|
+| Löschung vs. Anonymisierung bei Vereinsinhalten | Betreiber + Rechtsanwalt |
+| Verhalten bei Medien, die anderen Vereinen zugeordnet sind | Betreiber + Technik |
+| Umgang mit Backups (Retention vs. Löschung auf Antrag) | Betreiber + Rechtsanwalt |
+| Fristen: Bearbeitungszeit für Löschanträge | Rechtsanwalt |
+| Audit-Log für Löschanträge (wer, wann, was) | Technik |
+| Datenexport-Format und Umfang | Technik + Betreiber |
+
+Erst wenn diese Fragen beantwortet und als Spec dokumentiert sind, wird P-02 in Etappe C freigegeben.
+
+---
+
+### Etappe D – Ausbau und langfristige Optimierungen
+
+| Paket | Titel | Aufwand | Priorität |
+|-------|-------|---------|-----------|
+| P-09 | Admin-Audit-Log | 3–5 Tage | Hoch |
+| P-10 | Mindestalter-Abfrage | 1–2 Tage | Mittel |
+| P-14 | Moderations-UI (Frontend) | 3–5 Tage | Mittel (nach P-13) |
+| P-15 | Uploader-Benachrichtigung bei Sperrung | 1–2 Tage | Mittel (nach P-13) |
+| P-16 | Beschwerdeverfahren | 2–4 Tage | Niedrig (nach P-15) |
+| P-08 | HSTS-Dokumentation / Betriebsnachweis | Betreiber | Hoch (Release-Gate) |
+| P-22 | HTML-Sanitizer für Rich-Text-Felder | 1–2 Tage | Mittel |
+| P-20 | VVT erstellen | Betreiber | Hoch |
+| P-21 | AV-Verträge abschließen | Betreiber | Hoch |
+| P-02 | Self-Service-Kontolöschung + Datenexport | 5–8 Tage | Hoch (nach Spezifikation Etappe C) |
+| P-17 | MFA für Superadmins (TOTP) | 5–8 Tage | Mittel |
+| P-18 | HttpOnly-Cookie als Auth-Alternative | 3–5 Tage | Niedrig |
+| P-19 | Anti-Virus-Scan (ClamAV) | 3–5 Tage | Niedrig |
+
+---
+
+## 6. Nächste empfohlene Freigabe
+
+**Empfehlung: Kein Großpaket.**
+
+Die nächste Freigabe sollte **P-12 allein** umfassen:
+
+> „Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"
+
+**Begründung:**
+- Aufwand: ca. 15 Minuten
+- Risiko: null (isolierte Änderung in `AuthContext.jsx`)
+- Fix ist vollständig dokumentiert in `docs/compliance-implementation.md` §P-12
+- Schließt MITT-05 ohne Regressionsgefahr
+- Erfordert keinen Re-Audit — kann direkt committet werden
+
+**Alternativ: P-12 + P-01 (technische Platzhalterseiten)**
+
+Wenn Rechtstexte-Seiten rein technisch angelegt werden sollen (leere Routen, Hinweis „Inhalt folgt"), kann P-01 (technischer Teil) gleichzeitig freigegeben werden:
+
+> „Freigabe zur Umsetzung P-01: Rechtstexte technisch anlegen (Platzhalter-Seiten und Routen)"
+
+Inhaltliche Ausarbeitung der Rechtstexte bleibt davon getrennt und erfordert einen Rechtsanwalt.
+
+**Nach dieser Freigabe:** Mini-Re-Audit, dann Freigabe für Etappe B als Paket.
+
+---
+
+## 7. Release-Gates
+
+### Gate 1 — Öffentliche allgemeine Registrierung freischalten
+
+Folgende Bedingungen müssen **alle** erfüllt sein:
+
+| Bedingung | Paket | Typ |
+|-----------|-------|-----|
+| Impressum und Datenschutzerklärung mit juristisch geprüftem Inhalt | P-01 | Code + Rechtsanwalt |
+| Upload-Einwilligungsdialog aktiv | P-06 | Code |
+| DSGVO-Löschprozess spezifiziert (Spec akzeptiert, auch wenn nicht vollständig implementiert) | P-02 | Spezifikation |
+| Legal-Hold-Status vorhanden | P-11 | Code |
+| Content-Melde-Backend (Minimalversion) aktiv | P-13 | Code |
+| HSTS am externen Reverse-Proxy nachgewiesen | P-08 | Betreiber |
+| Papierkorb-Retention-Job läuft (Monitoring aktiv) | P-03 | Bereits erfüllt |
+| `ALLOW_PUBLIC_MEDIA_STATIC` nicht in Prod-Env gesetzt | P-07 | Bereits erfüllt |
+| sessionStorage bei Logout bereinigt | P-12 | Code (nach Freigabe) |
+
+**Darf bei Gate 1 offen bleiben (mit Dokumentation):**
+- P-02 vollständige Implementierung (Spezifikation genügt als Zwischenstand, wenn aktiver Prozess für Löschanfragen per E-Mail dokumentiert ist)
+- P-09 Admin-Audit-Log
+- P-10 Mindestalter-Abfrage
+- P-14–P-16 Moderationsausbau
+- P-17 MFA, P-18 HttpOnly-Cookie, P-19 Anti-Virus-Scan
+- P-20 VVT (in Erstellung), P-21 AV-Verträge (in Klärung)
+
+---
+
+### Gate 2 — Aktivierung öffentlicher Official-Medien (`visibility = official`)
+
+Bevor Inhalte mit `official`-Sichtbarkeit (plattformweit sichtbar, ohne Login) aktiv eingesetzt werden:
+
+| Bedingung | Paket | Typ |
+|-----------|-------|-----|
+| Gate 1 vollständig erfüllt | — | Voraussetzung |
+| Upload-Einwilligungsdialog für Personenbilder aktiv | P-06 | Code |
+| Legal-Hold-Status aktiv (Sofortsperrung möglich) | P-11 | Code |
+| Content-Melde-Backend aktiv | P-13 | Code |
+| Copyright-Pflicht bei Promotion aktiv und getestet | P-04 | Bereits erfüllt |
+| Moderationsprozess organisatorisch dokumentiert (wer, wie schnell, Eskalationspfad) | — | Betreiber |
+
+---
+
+### Gate 3 — Aktivierung öffentlicher Inhalte im Vereinsbereich (`visibility = club`)
+
+Bedingungen für Vereinsinhalte sind weniger streng als für `official`, da der Personenkreis begrenzt ist:
+
+| Bedingung | Status |
+|-----------|--------|
+| Copyright-Pflicht bei Promotion aktiv | ✅ bereits erfüllt (P-04) |
+| Papierkorb-Retention-Job aktiv | ✅ bereits erfüllt (P-03) |
+| Upload-Einwilligungsdialog vorhanden | muss mit P-06 kommen |
+| Mitgliedschaftsbasierte Zugriffskontrolle funktioniert | ✅ (TenantContext, library_content_visibility_sql) |
+
+---
+
+## 8. Juristisch zu prüfende Punkte
+
+Alle folgenden Punkte erfordern Einschätzung durch einen Rechtsanwalt oder Datenschutzbeauftragten. Keine der nachfolgenden Einschätzungen ist rechtlich verbindlich.
+
+| Thema | Frage | Priorität |
+|-------|-------|-----------|
+| **Rechtstexte** | Vollständige Angaben Impressum, Datenschutzerklärung, AGB, Medienrichtlinie. Inhalte können nicht technisch generiert werden. | Sofort |
+| **DSA-Anwendungsbereich** | Ab welcher Nutzerzahl und unter welchen Voraussetzungen gilt der DSA für diese Plattform? Welche Pflichten für sehr kleine Plattformen? | Vor öffentlichem Betrieb |
+| **Einwilligungsmodell Personenbilder** | §22 KUG: Welche Einwilligungen sind für Bilder erkennbarer Personen im Vereinskontext erforderlich? Reicht eine pauschale Upload-Erklärung? | Vor öffentlichem Betrieb |
+| **Minderjährigenschutz** | §8 DSGVO: Ab welchem Alter ist keine elterliche Einwilligung nötig? Wie ist mit Bildern Minderjähriger umzugehen? | Vor öffentlichem Betrieb |
+| **DSGVO-Löschprozess** | Anonymisierung vs. Löschung bei Vereinsinhalten; Umgang mit Backups; Fristen für Löschanträge (Art. 17) | Vor Implementierung P-02 |
+| **Datenübertragbarkeit** | Welcher Exportumfang ist für Art. 20 DSGVO ausreichend? Welches Format? | Vor Implementierung P-02 |
+| **AV-Verträge** | Welche Dienstleister benötigen einen AVV (SMTP-Anbieter, MediaWiki, OpenRouter)? | Vor öffentlichem Betrieb |
+| **Backup-Retention** | Wie muss die Backup-Retention-Policy aussehen, damit DSGVO-Löschanfragen auch Backups erfassen? | Vor öffentlichem Betrieb |
+| **MediaWiki-Lizenz** | Welche Lizenzanforderungen gelten für Übungsinhalte von karatetrainer.net? | Klärenswert |
+
+---
+
+## 9. Betreiber-Aufgaben
+
+Diese Punkte liegen außerhalb des Code-Scopes und erfordern organisatorische Maßnahmen durch den Betreiber:
+
+| Aufgabe | Bezug | Dringlichkeit |
+|---------|-------|--------------|
+| Rechtsanwalt beauftragen (Rechtstexte, DSA, KUG) | P-01, P-06 | Sofort |
+| VVT erstellen (DSGVO Art. 30) | P-20 | Vor öffentlichem Betrieb |
+| AV-Verträge klären (SMTP, MediaWiki, OpenRouter) | P-21 | Vor öffentlichem Betrieb |
+| HSTS am Reverse-Proxy (Fritz!Box/Synology) konfigurieren und nachweisen | P-08 | Vor öffentlichem Betrieb |
+| Backup-Konzept dokumentieren und Restore-Test durchführen | — | Dringend empfohlen |
+| Moderationsprozess organisatorisch festlegen: Wer moderiert? Wie schnell? Eskalationspfad? | P-13–P-16 | Vor Aktivierung öffentlicher Inhalte |
+| Notfallkontakt für Datenpannen benennen (DSGVO Art. 33) | — | Vor öffentlichem Betrieb |
+| Papierkorb-Retention-Job überwachen (`docker logs shinkan-retention-cron`) | P-03 | Laufend |
+
+---
+
+## 10. Aktualisierungsregel
+
+| Anlass | Maßnahme |
+|--------|----------|
+| Nach jedem Re-Audit | §2 (Aktueller Stand) und §5 (Reihenfolge) aktualisieren |
+| Nach jeder Freigabe | Paketregister (`docs/compliance-package-register.md`) aktualisieren; §2 dieser Roadmap anpassen |
+| Prioritätsänderung gegenüber bisheriger Roadmap | Datum und Begründung in §4 dokumentieren |
+| Neue Paket-IDs | Immer im Initial-Audit + Paketregister vergeben; nie nur in dieser Roadmap |
+| Paketstatus | Nie direkt in dieser Roadmap pflegen — immer aus Paketregister übernehmen |
+
+**Diese Roadmap enthält keine eigenständigen Statusangaben.** §2 wird durch Abfrage des Paketregisters befüllt und bei Aktualisierungen synchronisiert.
+
+---
+
+## Anhang: Schnellreferenz Freigabe-Formulierungen
+
+| Empfohlene nächste Freigabe | Formulierung |
+|-----------------------------|-------------|
+| P-12 allein | „Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen" |
+| P-12 + P-01 technisch | „Freigabe zur Umsetzung P-12 und P-01: sessionStorage bereinigen und Rechtstexte-Routen technisch anlegen (Platzhalter)" |
+| Etappe B komplett | „Freigabe zur Umsetzung Etappe B: P-01, P-06, P-11, P-13" |
+| P-02 Spezifikation | „Freigabe zur Spezifikation P-02: DSGVO-Self-Service-Prozess" |
+
+---
+
+*Erstellt: 2026-05-10 | Quellen: `docs/compliance-audit.md`, `docs/compliance-package-register.md`, `docs/compliance-implementation.md` | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.*
--- a/frontend/src/context/AuthContext.jsx
+++ b/frontend/src/context/AuthContext.jsx
@ -118,6 +118,11 @@ export function AuthProvider({ children }) {
    setUser(null)
    localStorage.removeItem('authToken')
    localStorage.removeItem(ACTIVE_CLUB_STORAGE_KEY)
+    for (const key of Object.keys(sessionStorage)) {
+      if (key.startsWith('sj_coach_')) {
+        sessionStorage.removeItem(key)
+      }
+    }
  }

  const value = {
--- a/frontend/src/version.js
+++ b/frontend/src/version.js
@ -1,6 +1,6 @@
 // Shinkan Jinkendo Frontend Version

-export const APP_VERSION = "0.8.67"
+export const APP_VERSION = "0.8.68"
 export const BUILD_DATE = "2026-05-10"

 export const PAGE_VERSIONS = {
--- a/tests/dev-smoke-test.spec.js
+++ b/tests/dev-smoke-test.spec.js
@ -141,6 +141,47 @@ test('7. Session-Persistenz nach Reload', async ({ page }) => {
  console.log('✓ Session bleibt nach Reload erhalten');
 });

+test('P-12: sessionStorage wird bei Logout bereinigt (sj_coach_* Schlüssel)', async ({ page }) => {
+  await page.setViewportSize({ width: 1280, height: 800 });
+  await login(page);
+  await page.waitForLoadState('networkidle');
+
+  // Coach-Sitzungsdaten simulieren (wie sie TrainingCoachPage schreibt)
+  await page.evaluate(() => {
+    sessionStorage.setItem('sj_coach_step_42', '3');
+    sessionStorage.setItem('sj_coach_deltas_42', '[{"id":1}]');
+    sessionStorage.setItem('sj_coach_debrief_42', '0');
+    sessionStorage.setItem('fremd_anderer_key', 'muss_erhalten_bleiben');
+  });
+
+  const vorLogout = await page.evaluate(() => ({
+    step: sessionStorage.getItem('sj_coach_step_42'),
+    fremd: sessionStorage.getItem('fremd_anderer_key'),
+  }));
+  expect(vorLogout.step).toBe('3');
+  expect(vorLogout.fremd).toBe('muss_erhalten_bleiben');
+
+  await page.getByRole('button', { name: 'Abmelden' }).click();
+  await page.waitForLoadState('networkidle');
+
+  const nachLogout = await page.evaluate(() => ({
+    step:    sessionStorage.getItem('sj_coach_step_42'),
+    deltas:  sessionStorage.getItem('sj_coach_deltas_42'),
+    debrief: sessionStorage.getItem('sj_coach_debrief_42'),
+    fremd:   sessionStorage.getItem('fremd_anderer_key'),
+    token:   localStorage.getItem('authToken'),
+  }));
+
+  expect(nachLogout.step).toBeNull();
+  expect(nachLogout.deltas).toBeNull();
+  expect(nachLogout.debrief).toBeNull();
+  expect(nachLogout.fremd).toBe('muss_erhalten_bleiben');
+  expect(nachLogout.token).toBeNull();
+
+  await page.screenshot({ path: 'screenshots/p12-session-storage-nach-logout.png' });
+  console.log('✓ P-12: sj_coach_* entfernt, Fremd-Key erhalten, authToken entfernt');
+});
+
 test('8. Keine kritischen Console-Fehler', async ({ page }) => {
  const errors = [];
  page.on('console', msg => {