# P-06 – Fachlich-technische Spezifikation: Upload-Einwilligungsdialog

**Paket-ID:** P-06 (kanonisch, unveränderlich)  
**Kanonischer Titel:** Upload-Einwilligungsdialog (Recht am eigenen Bild, Personen, Minderjährige)  
**Dokument-Typ:** Spezifikation — keine Umsetzungsfreigabe  
**Erstellt:** 2026-05-10  
**App-Version bei Erstellung:** 0.8.74  
**Status P-06:** ❌ offen — Umsetzung erst nach Entscheidung zu offenen juristischen Punkten  
**Rechtlicher Hinweis:** Alle als „juristisch zu prüfen" markierten Einschätzungen sind keine Rechtsberatung. Keine konkrete Textfassung von Erklärungen in diesem Dokument — Formulierungen obliegen dem Rechtsanwalt.

---

## 1. Kontext und Ziel

### 1.1 Ausgangslage (Initial-Audit-Befund)

Das Initial-Audit (`docs/compliance-audit.md`, §8.2–8.3) identifiziert folgende Lücken:

- Keine verbindliche Rechteerklärung beim Medienupload
- Keine Abfrage, ob erkennbare Personen enthalten sind
- Keine Abfrage, ob Minderjährige abgebildet sind
- Keine Abfrage, ob erforderliche Einwilligungen abgebildeter Personen vorliegen
- Keine Dokumentation, wer wann welche Erklärung abgegeben hat

### 1.2 Regulatorische Prüfanker (technische Modellierung)

| Norm | Relevanz für Datenmodell | Juristisch zu prüfen |
|------|--------------------------|----------------------|
| § 22 KUG | Bildnisse erkennbarer Personen erfordern Einwilligung vor Verbreitung/Zurschaustellung | Gilt auch für vereinsinterne Sichtbarkeit? |
| Art. 8 DSGVO | Bei Minderjährigen ggf. Einwilligung Erziehungsberechtigter | Ab welchem Alter? Welche Mechanismen? |
| § 19a UrhG | Öffentliche Zugänglichmachung = eigener Nutzungstatbestand | Ab wann gilt `official` als „öffentlich zugänglich"? |
| DSGVO Art. 5(1)(e) | Datenminimierung — welche Nachweisdaten dürfen gespeichert werden? | Was ist verhältnismäßig? |

### 1.3 Ziel dieser Spezifikation

P-06 soll sicherstellen, dass:

1. Jeder Medien-Upload mit einer strukturierten, gespeicherten Rechteerklärung verknüpft ist
2. Die Erklärung nach Sichtbarkeitsstufe gestuft wird (private minimal, official vollständig)
3. Bestehende Prüfungen aus P-04 (copyright_notice) komplementär erhalten bleiben
4. Juristische Textanpassungen ohne Codeänderungen möglich sind (Versionierung)
5. Altmedien ohne rückwirkenden Zwang behandelt werden können
6. Backend-Erzwingung (keine reine Frontend-Kosmetik) besteht

---

## 2. IST-Analyse

### 2.1 Upload-Pfade (vollständige Bestandsaufnahme)

| # | Endpoint | Datei | Upload-Typ | Sichtbarkeit wählbar | Copyright bei Upload |
|---|----------|-------|-----------|---------------------|----------------------|
| U1 | `POST /api/exercises/{id}/media` | `routers/exercises.py:2518` | Einzeldatei oder Embed-URL | Folgt Übungssichtbarkeit (implizit) | Nicht abgefragt |
| U2 | `POST /api/media-assets/bulk-upload` | `routers/media_assets.py:787` | 1–n Dateien | `visibility` + `club_id` als Form-Parameter | Optional (`copyright_notice` fehlt im POST-Body, nur via PATCH nachträglich) |

**Kein weiterer Upload-Endpoint vorhanden** (geprüft über Codebase-Suche nach `UploadFile`).

**Weitere indirekte Upload-Pfade:**
- `POST /api/exercises/{id}/media/from-asset` (`exercises.py`) — verknüpft ein bestehendes Archiv-Asset mit einer Übung; kein Upload, kein neues Medium
- Embed-URL (`embed_url`, `embed_platform`) — keine Datei, keine Rechteerklärung für Dateiinhalte; externe Plattform verantwortlich

### 2.2 Promotionspfade (Sichtbarkeitsänderung)

| # | Endpoint | Datei | Mögliche Promotion |
|---|----------|-------|--------------------|
| PR1 | `PATCH /api/media-assets/{id}` | `routers/media_assets.py:1223` | private→club, private→official, club→official, auch Rückstufung |
| PR2 | `POST /api/media-assets/bulk-patch` | `routers/media_assets.py:1094` | Massenpromotion, gleiche Richtungen |
| PR3 | Implizit bei `PUT /api/exercises/{id}` | `routers/exercises.py` | Übungssichtbarkeit→club/official löst `apply_official_exercise_media_rules()` oder `apply_club_exercise_media_copyright_rules()` aus |

**Rückstufungen** (official→club, club→private) werden nicht gesperrt — juristisch zu prüfen, ob Rückstufung Rechte-Konsequenzen hat.

### 2.3 Datenmodell `media_assets` (Migration 045 + 046)

```
media_assets
├── id SERIAL PK
├── mime_type VARCHAR(100)
├── byte_size INT
├── sha256 CHAR(64) NOT NULL
├── original_filename VARCHAR(300)
├── visibility VARCHAR(32) NOT NULL DEFAULT 'private'     ← Sichtbarkeitsstufe
├── club_id INT REFERENCES clubs(id)                      ← Vereinszuordnung
├── uploaded_by_profile_id INT REFERENCES profiles(id)    ← Uploader
├── copyright_notice TEXT                                  ← Urheberrechtshinweis (P-04)
├── storage_backend VARCHAR(32)
├── storage_key TEXT NOT NULL UNIQUE
├── lifecycle_state VARCHAR(32) DEFAULT 'active'
├── trash_soft_at, trash_hidden_at, purge_after_at TIMESTAMP
├── created_at, updated_at TIMESTAMP
└── tags TEXT[] DEFAULT '{}'
```

**Fehlende P-06-Felder:** Keine Einwilligungsfelder vorhanden. Keine Personenabbildungsmarkierung. Keine Deklarations-Versionierung.

### 2.4 Rollen und Berechtigungen (Zusammenfassung `_item_permissions()`)

| Aktion | private | club | official |
|--------|---------|------|----------|
| Upload (neu) | Jeder authentifizierte Nutzer | Vereinsmitglied + club_id | Nur Superadmin |
| `edit_metadata` | Superadmin, Plattform-Admin, Uploader | Superadmin, Plattform-Admin, Club-Admin | Nur Superadmin |
| Promotion zu club | Eigener Upload: Uploader; Club-Asset: Club-Admin | — | — |
| Promotion zu official | Nur Superadmin | Nur Superadmin | — |
| Lifecycle (trash) | Uploader, Plattform-Admin, Superadmin | Club-Admin, Plattform-Admin, Superadmin | Nur Superadmin |

### 2.5 Bestehende Frontend-Dialoge

| Stelle | Datei | Aktuelles Verhalten |
|--------|-------|---------------------|
| Übungsformular Medienupload | `ExerciseFormPage.jsx` | Datei-Picker, kein Einwilligungsdialog |
| Archiv Bulk-Upload | `MediaLibraryPage.jsx` | Datei-Picker + optional `copyright_notice` im Editmodal, kein Pflichtdialog |
| Übung → official (API-Error) | `ExerciseFormPage.jsx:624` | `window.prompt()` für copyright_notice nach 422-Fehler — reaktiv, kein proaktiver Dialog |
| Archiv PATCH Sichtbarkeit | `MediaLibraryPage.jsx` | Backend wirft 400 wenn copyright fehlt; Frontend-Feedback unklar |

**Ergebnis:** Kein proaktiver strukturierter Einwilligungsdialog vorhanden. Alle Copyright-Abfragen sind reaktiv (nach API-Fehler) oder optional.

### 2.6 Bestehende Copyright-Prüfungen P-04 (Referenz)

P-04 erzwingt `copyright_notice` bei Promotion zu `club` oder `official`:
- `patch_media_asset()`: HTTP 400 wenn `copyright_notice` leer bei Ziel club/official
- `bulk_media_patch()`: Asset in `failed`-Liste wenn copyright fehlt
- `apply_official_exercise_media_rules()`: HTTP 422 `OFFICIAL_MEDIA_CONFIRM_REQUIRED` wenn Assets kein copyright
- Mindestlänge: 3 Zeichen (`_MIN_OFFICIAL_MEDIA_COPYRIGHT_LEN = 3`)

**Verhältnis zu P-06:** P-04 (copyright_notice) = Attribution für Dritte (wer besitzt das Recht). P-06 = Selbsterklärung des Uploaders (habe ich das Recht, dieses Medium hochzuladen). Ergänzend, nicht konkurrierend.

### 2.7 IST-Lücken (P-06-spezifisch)

| Lücke | Schwere |
|-------|---------|
| Kein Pflichtfeld „Ich bin Rechteinhaber" beim Upload | Kritisch (Grundlage aller Uploads) |
| Keine Abfrage „erkennbare Personen enthalten?" | Hoch (§ 22 KUG-Risiko bei club/official) |
| Keine Abfrage „Minderjährige enthalten?" | Hoch (Art. 8 DSGVO, besonderer Schutz) |
| Keine Speicherung von Einwilligungszeitpunkt und -version | Hoch (Nachweisbarkeit) |
| Keine Erzwingung im Backend (nur Frontend-Checkbox wäre zu wenig) | Kritisch |
| Kein Einwilligungslog (wer hat wann welche Version bestätigt?) | Hoch |
| copyright_notice beim Erstupload nicht abgefragt | Mittel (P-04 fragt erst bei Promotion) |

### 2.8 Altbestandsrisiken

- Alle bestehenden `media_assets`-Zeilen haben keine Einwilligungsmetadaten
- Unbekannt, ob bei bestehenden Medien erkennbare Personen/Minderjährige abgebildet sind
- Medien mit `visibility=club` oder `visibility=official` existieren ohne dokumentierte Einwilligung
- Superadmin kann bestehende official-Medien weiter sehen/nutzen ohne Nachdeklaration
- Bei Neuzuweisung zu einer anderen Übung werden bestehende Medien ohne Prüfung verknüpft

---

## 3. Entscheidungsmatrix

Anforderungen nach **Sichtbarkeitsstufe** (Zeilen) × **Aktion** (Spalten). „Pflicht" = Backend-Sperre wenn fehlend. „Optional" = abfragen aber nicht erzwingen.

| Aktion → | Erstupload | Promotion club | Promotion official | Metadaten-Edit | Reuse in neuer Übung |
|-----------|-----------|---------------|-------------------|---------------|---------------------|
| **private** | `rights_holder`: Pflicht; Personen-Fragen: optional | — | — | Keine P-06-Pflicht | Keine P-06-Pflicht |
| **club** | `rights_holder`: Pflicht; `contains_persons`: Pflicht; `person_consent`: Pflicht wenn Personen | `contains_persons` + `person_consent`: Pflicht; `contains_minors`: Pflicht | — | Keine P-06-Pflicht | Keine P-06-Pflicht |
| **official** | Alles Pflicht | Alles Pflicht | Alle Felder Pflicht + copyright_notice (P-04) | Keine P-06-Pflicht | Keine P-06-Pflicht |

**B: Medieninhalt — Konsequenzen:**

| Inhalt | private | club | official |
|--------|---------|------|----------|
| Keine erkennbaren Personen | `person_consent` entfällt | `person_consent` entfällt | `person_consent` entfällt |
| Erkennbare Erwachsene | Optional zu deklarieren | Einwilligung Pflicht (juristisch zu prüfen) | Einwilligung Pflicht |
| Erkennbare Minderjährige | Optional zu deklarieren | Einwilligung Erziehungsberechtigter Pflicht (juristisch zu prüfen) | Einwilligung Pflicht |
| Unklar / nicht beantwortet | Zulässig bei private | Blockiert bei club/official | Blockiert |

**C: Rechteinhalt — Konsequenzen:**

| Inhalt | Konsequenz |
|--------|-----------|
| Nutzer ist selbst Urheber | `rights_holder_confirmed = true` genügt |
| Nutzer hat Nutzungsrechte | `rights_holder_confirmed = true` genügt; copyright_notice sollte Rechteinhaber nennen |
| Drittmaterial enthalten | `rights_holder_confirmed = true` nur wenn Lizenz vorhanden; copyright_notice Pflicht bei club/official |
| Musik enthalten | `contains_music = true`; `music_rights_confirmed` Pflicht (juristisch zu prüfen) |
| Logos/Marken/sonstige Fremdinhalte | Fällt unter `rights_holder_confirmed`; juristisch zu prüfen |

**D: Aktion — Blockierungslogik:**

| Aktion | Fehlendes Pflichtfeld | Verhalten Backend |
|--------|----------------------|-------------------|
| Upload | rights_holder_confirmed fehlt | HTTP 400 `RIGHTS_DECLARATION_REQUIRED` |
| Promotion club | contains_persons / person_consent fehlt | HTTP 400 `CONSENT_REQUIRED_FOR_CLUB` |
| Promotion official | Beliebiges Pflichtfeld fehlt | HTTP 400 `CONSENT_REQUIRED_FOR_OFFICIAL` |
| Promotion mit Altmedium (legacy) | rights_status = legacy_unreviewed | HTTP 400 `LEGACY_REDECLARATION_REQUIRED` |

---

## 4. Empfohlenes Zielmodell

### 4.1 Neue Tabelle: `media_asset_rights_declarations`

Append-only Audit-Log. Jede Erklärung (Upload, Promotion, Nachdeklaration) erzeugt einen neuen Eintrag. Bestehende Einträge werden nie geändert.

```sql
CREATE TABLE media_asset_rights_declarations (
    id SERIAL PRIMARY KEY,
    media_asset_id INT NOT NULL REFERENCES media_assets(id) ON DELETE CASCADE,
    declared_by_profile_id INT REFERENCES profiles(id) ON DELETE SET NULL,
    declared_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),

    -- Kontext
    action_type VARCHAR(50) NOT NULL
        CHECK (action_type IN (
            'upload',              -- Erstupload
            'promote_club',        -- Promotion zu club
            'promote_official',    -- Promotion zu official
            're_declaration',      -- Nachdeklaration (auf Aufforderung)
            'legacy_re_declaration' -- Altmedium: erste Deklaration nachgereicht
        )),
    target_visibility VARCHAR(32) NOT NULL,        -- Sichtbarkeit für die erklärt wird
    declaration_version VARCHAR(20) NOT NULL DEFAULT 'p06-v1.0',  -- Textversion der Erklärung

    -- Pflichtfeld (alle Sichtbarkeiten)
    rights_holder_confirmed BOOLEAN NOT NULL,

    -- Personenrechte (Pflicht ab club)
    contains_identifiable_persons BOOLEAN,
    person_consent_confirmed BOOLEAN,             -- Pflicht wenn contains_identifiable_persons = true
    contains_minors BOOLEAN,
    parental_consent_confirmed BOOLEAN,           -- Pflicht wenn contains_minors = true (juristisch zu prüfen)

    -- Drittmaterial (optional MVP, Pflicht später)
    contains_music BOOLEAN,
    music_rights_confirmed BOOLEAN,
    third_party_content_confirmed BOOLEAN,

    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_mar_declarations_asset ON media_asset_rights_declarations (media_asset_id);
CREATE INDEX idx_mar_declarations_profile ON media_asset_rights_declarations (declared_by_profile_id);
```

### 4.2 Neue Felder in `media_assets`

Drei neue Schnellzugriffs-Felder (kein Ersatz für den Log, nur für performante Abfragen):

```sql
ALTER TABLE media_assets
    ADD COLUMN rights_status VARCHAR(32)
        NOT NULL DEFAULT 'legacy_unreviewed'
        CHECK (rights_status IN ('pending', 'declared', 'legacy_unreviewed', 'blocked')),
    ADD COLUMN rights_declared_for_visibility VARCHAR(32),   -- Höchste Stufe, für die erklärt wurde
    ADD COLUMN rights_declared_at TIMESTAMP WITH TIME ZONE;  -- Zeitpunkt der aktuellsten Erklärung
```

**Status-Semantik:**

| rights_status | Bedeutung |
|---------------|-----------|
| `legacy_unreviewed` | Bestehendes Medium ohne P-06-Daten — Altbestand |
| `pending` | Neues Medium, Upload noch ohne Deklaration (Zwischenzustand, darf nie persistent sein) |
| `declared` | Gültige Deklaration vorhanden für `rights_declared_for_visibility` |
| `blocked` | Deklaration widerrufen oder durch Admin gesperrt (→ P-11/P-13 Schnittstelle) |

**Visibility-Hierarchie für Prüfung:**
```
private (1) < club (2) < official (3)
```

Promotion ist erlaubt wenn: `rights_declared_for_visibility` ≥ Ziel-Visibility. Sonst ist neue Deklaration erforderlich.

### 4.3 Feld-Bewertung: MVP vs. später

| Feld | MVP-Pflicht | Sinnvoll später | Unnötig / zu früh | Juristisch abhängig |
|------|-------------|-----------------|-------------------|---------------------|
| `rights_holder_confirmed` | ✅ | — | — | Nein |
| `contains_identifiable_persons` | ✅ ab club | — | — | Nein |
| `person_consent_confirmed` | ✅ wenn Personen + ≥ club | — | — | Teilweise |
| `contains_minors` | ✅ ab official | ✅ auch club | — | Ja (Schwelle) |
| `parental_consent_confirmed` | — | ✅ | — | Ja (juristisch zu klären) |
| `contains_music` | — | ✅ | — | Ja |
| `music_rights_confirmed` | — | ✅ | — | Ja |
| `third_party_content_confirmed` | — | ✅ | — | Teilweise |
| `declaration_version` | ✅ | — | — | Nein |
| `action_type` | ✅ | — | — | Nein |
| `rights_status` in media_assets | ✅ | — | — | Nein |
| `rights_declared_for_visibility` | ✅ | — | — | Nein |
| Separates Upload von Einwilligungsdokumenten | — | — | Zu früh | Ja |
| `may_be_embedded_in_exercises` | — | — | Unnötig (exercise_media-Tabelle reicht) | — |
| `declaration_scope_*` als einzelne Booleans | — | — | Unnötig (visibility-String reicht) | — |

### 4.4 Designentscheidungen (mit Begründung)

**Entscheidung 1: Gestufte Erklärungen je Sichtbarkeitsstufe**

Nicht eine universale Erklärung für alle Stufen, sondern Promotion auf höhere Stufe erfordert neue Erklärung.

*Begründung:* Rechtliche Anforderungen steigen mit Sichtbarkeit. Private Medien: nur Eigentümer sieht sie. Official-Medien: plattformweit sichtbar (ggf. öffentlich). Stufenmodell ist rechtsanschlussfähig — spätere juristische Textanpassungen pro Stufe ohne Systemwechsel möglich.

**Entscheidung 2: Minimalset beim Erstupload**

Pflicht beim privaten Upload: nur `rights_holder_confirmed`. Personen-Fragen: optional beim Upload, Pflicht erst bei Promotion zu club/official.

*Begründung:* Die meisten Uploads bleiben privat und werden nie promoted. Volle Fragebogenbelastung beim Upload würde Nutzung hemmen ohne rechtlichen Mehrwert. Personen-Fragen werden erzwungen sobald der Upload für andere sichtbar wird.

**Entscheidung 3: Keine globale Nutzer-Einwilligung (pro Upload)**

Erklärung wird pro Upload abgegeben, nicht einmalig pro Nutzer.

*Begründung:* Jedes Medium ist inhaltlich unterschiedlich. Eine pauschale Einwilligung beim Registrieren oder einmalig je Nutzer deckt nicht ab, ob bei diesem konkreten Video Minderjährige abgebildet sind.

**Entscheidung 4: Append-only Audit-Log**

Einmal abgegebene Erklärungen werden nie geändert oder gelöscht. Neue Erklärung = neuer Eintrag.

*Begründung:* Nachweisbarkeit. Bei späterem Streit muss belegbar sein, was wann erklärt wurde.

**Entscheidung 5: Versionierung via `declaration_version`-String**

Wenn Rechtsanwalt Erklärungstexte ändert, wird die neue Version als "p06-v1.1" deklariert. Keine Datenbank-FK auf eine Textversion-Tabelle (zu komplex für MVP).

*Begründung:* Einfach nachvollziehbar. Ob bei Versionswechsel alle Altdeklarationen erneuert werden müssen, ist juristisch zu entscheiden — technisch ermöglicht das System beides.

**Entscheidung 6: copyright_notice bleibt separat (P-04 unberührt)**

P-06 führt keine copyright_notice-Redundanz ein. copyright_notice (P-04) = Attribution. rights_holder_confirmed (P-06) = Berechtigung. Beide sind Pflicht bei official.

---

## 5. Ziel-Flows

### Flow 1: Erstupload eines privaten Mediums (Übung oder Archiv)

**Frontend:**
1. Nutzer öffnet Upload-Dialog (Exercise oder Archiv)
2. Dateiauswahl
3. **P-06-Dialog erscheint vor Upload-Button-Aktivierung:**
   - ☑ „Ich bin der Rechteinhaber oder besitze die erforderlichen Nutzungsrechte an diesem Medium." [Pflicht]
   - ☐ „Das Medium enthält erkennbare Personen." [optional]
   - → wenn ja: ☑ „Alle abgebildeten Personen haben der Nutzung zugestimmt." [optional bei private, Pflicht bei Promotion]
   - ☐ „Das Medium enthält Minderjährige." [optional]
4. Upload-Button aktiv erst wenn Pflicht-Checkbox gesetzt

**Backend:**
- Empfängt neue Felder: `rights_holder_confirmed`, optional `contains_identifiable_persons`, `person_consent_confirmed`, `contains_minors`
- Prüft: `rights_holder_confirmed == true` — sonst HTTP 400 `RIGHTS_DECLARATION_REQUIRED`
- INSERT in `media_assets` mit `rights_status = 'declared'`, `rights_declared_for_visibility = 'private'`, `rights_declared_at = NOW()`
- INSERT in `media_asset_rights_declarations` mit `action_type = 'upload'`, `declaration_version = 'p06-v1.0'`, alle Felder

**Fehlermeldungen:**
- `RIGHTS_DECLARATION_REQUIRED`: "Bitte bestätige, dass du die erforderlichen Rechte an diesem Medium besitzt."

**Tests:**
- Upload ohne `rights_holder_confirmed` → 400
- Upload mit `rights_holder_confirmed=true` → 201, `rights_status='declared'` in DB
- Declaration-Log-Eintrag vorhanden mit korrektem `action_type='upload'`

**Offene juristische Fragen:** Reicht Selbsterklärung oder muss der Betreiber den Upload ansonsten ablehnen? (→ §7.1)

---

### Flow 2: Erstupload direkt als club-Medium (Archiv-Bulk-Upload)

**Frontend:**
- Nutzer wählt `visibility = club` im Bulk-Upload-Dialog
- P-06-Dialog erweitert (zusätzlich zur privaten Pflicht-Checkbox):
  - ☑ „Das Medium enthält erkennbare Personen." [Antwort Pflicht bei club]
  - → wenn ja: ☑ „Alle abgebildeten Personen haben der vereinsinternen Nutzung zugestimmt." [Pflicht]
  - ☑ „Das Medium enthält Minderjährige." [Antwort Pflicht]
  - → wenn ja: ☑ „Einwilligung der Erziehungsberechtigten liegt vor." [Pflicht, juristisch zu prüfen]

**Backend:**
- Prüft alle Pflichtfelder für club: `rights_holder_confirmed`, `contains_identifiable_persons` (must be answered), `person_consent_confirmed` (wenn contains_persons=true)
- `rights_declared_for_visibility = 'club'`
- Eintrag in `media_asset_rights_declarations` mit `action_type = 'upload'`, `target_visibility = 'club'`

---

### Flow 3: Bulk-Upload durch Admin (Plattform-Admin / Superadmin)

**Besonderheit:** Admin lädt oft viele Dateien auf einmal. Dialog-Design muss batch-fähig sein.

**Empfehlung:** Eine Einwilligungserklärung für den gesamten Batch (nicht je Datei). Alle Dateien des Batches erhalten den gleichen Declarations-Record, jedoch referenziert je `media_asset_id`.

**Frontend:**
- Vor Upload: Batch-Deklaration (gilt für alle Dateien des Batches)
- Alternativ: Je Datei separate Deklaration (aufwändiger aber präziser) — juristisch zu prüfen welche Variante ausreichend ist

**Backend:**
- `action_type = 'upload'` für alle Dateien des Batches
- Wenn Batch-Deklaration: eine Deklarations-Transaktion, n Einträge in Log (je asset_id)

**Offene juristische Fragen:** Genügt eine Sammelbestätigung für Batches? (→ §7.6)

---

### Flow 4: Promotion private → club

**Frontend:**
1. Nutzer ändert Sichtbarkeit eines Mediums zu `club` (im Archiv oder via Übungssichtbarkeit)
2. Frontend erkennt Sichtbarkeitserhöhung
3. **P-06-Promotions-Dialog:**
   - ☑ „Das Medium enthält erkennbare Personen." [Pflicht — Antwort erforderlich]
   - → wenn ja: ☑ „Alle abgebildeten Personen haben der vereinsinternen Nutzung zugestimmt." [Pflicht]
   - ☑ „Das Medium enthält Minderjährige." [Pflicht — Antwort erforderlich]
   - → wenn ja: ☑ „Einwilligung der Erziehungsberechtigten liegt vor." [Pflicht, juristisch zu prüfen]
4. Bestehende copyright_notice-Abfrage (P-04) bleibt erhalten — läuft parallel oder im gleichen Dialog

**Backend:**
- PATCH `/api/media-assets/{id}` empfängt: `visibility='club'`, P-06-Felder, `copyright_notice`
- Prüft: rights_status='declared' AND rights_declared_for_visibility ≥ 'club' — wenn ja, keine neue Deklaration nötig (z. B. bereits als club hochgeladen)
- Wenn nicht: neue Pflichtfelder prüfen, INSERT in Declarations-Log mit `action_type='promote_club'`
- Bestehende P-04-Prüfung: copyright_notice weiterhin Pflicht
- `rights_declared_for_visibility` in media_assets auf 'club' setzen

**Backend-Fehler:**
- `CONSENT_REQUIRED_FOR_CLUB`: Personenfragen nicht beantwortet
- `LEGACY_REDECLARATION_REQUIRED`: Altmedium, muss Nachdeklaration abgeben
- `RIGHTS_DECLARATION_REQUIRED` (P-04): copyright_notice fehlt (bestehend)

---

### Flow 5: Promotion private/club → official

**Frontend:**
1. Nur Superadmin kann zu official promoten
2. Dialog zeigt vollständige Erklärung:
   - Alle Felder aus Flow 4 (Pflicht)
   - ☑ zusätzlich: „Das Medium enthält Musik oder sonstige Fremdinhalte." [Pflicht — Antwort erforderlich]
   - → wenn ja: ☑ „Ich besitze die erforderlichen Lizenzen für die öffentliche Nutzung." [Pflicht]
3. copyright_notice (P-04) weiterhin Pflicht (bestehende Logik)

**Backend:**
- Prüft alle Felder + copyright_notice
- `action_type = 'promote_official'`, `target_visibility = 'official'`
- `rights_declared_for_visibility = 'official'`

**Offene juristische Fragen:** Reicht Selbstdeklaration oder muss Superadmin bei official höhere Sorgfalt nachweisen? (→ §7.3)

---

### Flow 6: Nachbearbeitung von Metadaten (ohne Sichtbarkeitsänderung)

**Szenario:** Nutzer ändert nur `copyright_notice`, `original_filename`, `tags` — keine Sichtbarkeitsänderung.

**P-06-Anforderung:** Keine neue Deklaration erforderlich (Metadaten-Edit ist kein Promotions-Schritt).

**Ausnahme:** Wenn `rights_status = 'blocked'` (durch P-11/P-13 gesetzt) → Metadaten-Edit erlaubt, aber Sichtbarkeitsänderungen bleiben gesperrt.

---

### Flow 7: Verwendung bestehender Medien in neuer Übung (`from-asset`)

**Szenario:** Trainer verknüpft ein bereits im Archiv liegendes Medium mit einer neuen Übung über `POST /api/exercises/{id}/media/from-asset`.

**P-06-Anforderung:** Keine neue Deklaration erforderlich. Die Deklaration gilt für das Medium selbst, nicht für die Verknüpfung. Voraussetzung: `rights_status` des Assets ist 'declared' für die Sichtbarkeit der Übung.

**Backend-Prüfung (neu):**
- Asset-Sichtbarkeit ≥ Übungs-Sichtbarkeit? Bestehende Prüfung.
- `rights_declared_for_visibility` ≥ Übungs-Sichtbarkeit? → Neue Prüfung durch P-06
- Wenn nicht: HTTP 400 `RIGHTS_DECLARATION_REQUIRED_FOR_TARGET_VISIBILITY`

---

### Flow 8: Behandlung von Altmedien ohne P-06-Metadaten

**Strategie: Soft-Block bei Promotion, kein Rückwirkungs-Zwang für private Altmedien**

| Situation | Verhalten |
|-----------|-----------|
| Altmedium private → weiterhin privat | Unverändert zugänglich; keine Zwangs-Nachdeklaration |
| Altmedium privat → Anzeige in Übung (private) | Unverändert; keine neue Deklaration |
| Altmedium privat → Promotion zu club | Blocked: `LEGACY_REDECLARATION_REQUIRED`; Nutzer muss Nachdeklaration abgeben |
| Altmedium club → Promotion zu official | Blocked; Superadmin muss Nachdeklaration abgeben |
| Altmedium mit `rights_status = 'legacy_unreviewed'` | Einsehbar, nicht promotable |

**Nachdeklarations-Flow:**
1. Nutzer versucht Promotion eines Altmediums
2. Backend gibt HTTP 400 `LEGACY_REDECLARATION_REQUIRED` zurück
3. Frontend zeigt Hinweis und Deklarations-Dialog (analog zu neuem Upload-Dialog)
4. Nutzer füllt Deklaration aus
5. PATCH mit `legacy_re_declaration=true` + alle Pflichtfelder + `visibility`
6. Backend: INSERT in Declarations-Log mit `action_type='legacy_re_declaration'`, aktualisiert `rights_status`, `rights_declared_for_visibility`

**Migrationsstrategie für bestehende Daten:**
- Alle bestehenden `media_assets`-Zeilen bleiben mit `rights_status = 'legacy_unreviewed'` (Default in Migration)
- Keine rückwirkende Sperrung
- Bestehende club/official-Medien: `rights_status = 'legacy_unreviewed'` — die historische Sichtbarkeit bleibt erhalten, spätere Änderungen erfordern aber Nachdeklaration

**Juristisch zu prüfen:** Muss der Betreiber aktiv alle Altmedien auf club/official sperren bis zur Nachdeklaration? (→ §7.8)

---

### Flow 9: Widerruf / nachträglich fehlende Rechte erkannt

**Szenario:** Abgebildete Person widerruft Einwilligung oder Uploader erkennt, dass er keine Rechte hatte.

**P-06 implementiert keinen Widerrufsmechanismus direkt.** Anschluss an spätere Pakete:

- **P-11 (Legal-Hold):** Superadmin kann `rights_status = 'blocked'` setzen → Medium sofort aus allen öffentlichen Abfragen entfernt
- **P-13 (Content-Melde-Backend):** Dritte können Rechtsverletzung melden → Moderationsqueue → Superadmin entscheidet über Sperrung

**P-06-Schnittstelle:** Das Feld `rights_status = 'blocked'` in `media_assets` ist die technische Brücke zu P-11 und P-13.

**Empfehlung:** Declaration-Log-Tabelle hat `ON DELETE CASCADE` auf `media_assets.id` — wenn ein Medium purged wird, werden auch alle Deklarationseinträge entfernt. Juristisch zu prüfen, ob Deklarationslog nach Löschung aufbewahrt werden muss (Rechenschaftspflicht Art. 5 Abs. 2 DSGVO).

---

### Flow 10: Zusammenspiel mit späterem P-11 und P-13

| P-06-Element | P-11-Anschluss | P-13-Anschluss |
|-------------|---------------|---------------|
| `rights_status = 'blocked'` | P-11 setzt diesen Status (Legal-Hold) | P-13-Moderator triggert P-11-Sperre |
| Declaration-Log | Zeigt, welche Version bei Sperrung galt | Kontext für Moderationsentscheidung |
| `contains_identifiable_persons` | Relevant für Löschbegründung (KUG) | Relevanzmerkmal für Meldekategorie |
| `contains_minors` | Höchste Priorität bei P-11-Sofortsperrung | CSAM-Eskalationspfad in P-13 |

P-06 darf nicht im Widerspruch zu den späteren Paketen implementiert werden. Der `rights_status`-Enum muss `'blocked'` bereits in P-06a (Migration) enthalten.

---

## 6. Legacy- und Migrationskonzept

### 6.1 Fragen und Antworten

| Frage | Empfehlung | Juristisch zu prüfen |
|-------|-----------|----------------------|
| Dürfen Altmedien sichtbar bleiben? | Ja — keine rückwirkende Sperrung | Ja — insb. club/official ohne Einwilligung |
| Dürfen Altmedien in neuen Übungen verwendet werden? | Ja, wenn Sichtbarkeit kompatibel | Ja — falls keine Rechte vorhanden |
| Dürfen Altmedien zu club promoted werden? | Nein — Nachdeklaration erforderlich | Ja — ob Selbstdeklaration genügt |
| Dürfen Altmedien zu official promoted werden? | Nein — vollständige Nachdeklaration | Ja — höhere Anforderungen |
| Muss bei erster Bearbeitung Nachdeklaration erzwungen werden? | Nein (nur bei Promotion) | Ja — Betreiber-Ermessen |

### 6.2 Migration-Schritte

1. **Migration (P-06a):** Neue Spalten in `media_assets` mit `DEFAULT 'legacy_unreviewed'` → alle bestehenden Zeilen erhalten automatisch Status `legacy_unreviewed`
2. **Neue Uploads nach P-06:** Code setzt `rights_status = 'declared'` nach erfolgreicher Deklaration
3. **Altmedien-Promotion:** Backend blockiert mit `LEGACY_REDECLARATION_REQUIRED`; Nutzer muss Nachdeklaration abgeben
4. **Keine automatische Batch-Re-Deklaration** durch Betreiber (wäre fachlich falsch — Betreiber kann nicht für Uploader erklären)

### 6.3 Empfohlene Übergangsstrategie (Minimales Risiko)

```
private Altmedien:  weiter sichtbar und nutzbar | Promotion blockiert
club Altmedien:     weiter sichtbar             | Sichtbarkeitsänderung blockiert
official Altmedien: weiter sichtbar             | Sichtbarkeitsänderung blockiert
```

*Begründung:* Vollständige Sperrung aller Altmedien würde Betrieb lahmlegen. Die Blockierung bei Promotion schützt vor Eskalation ohne existierende Nutzung zu zerstören. Juristisch bleibt das Risiko bei bereits exponierten Medien — das ist ein organisatorisches Problem, kein technisches.

---

## 7. Juristische Klärungsliste

Alle folgenden Punkte müssen durch einen Rechtsanwalt oder Datenschutzbeauftragten bewertet werden. Keine der folgenden Einschätzungen ist rechtlich bindend.

| # | Frage | Technische Relevanz | Dringlichkeit |
|---|-------|---------------------|---------------|
| 7.1 | Welche Erklärung ist für **private** Medien (nur Uploader sieht sie) erforderlich? Reicht `rights_holder_confirmed` oder ist auch ohne Sichtbarkeit Dritter eine Personeneinwilligung nötig? | Ob Personen-Fragen bei private Pflicht werden | Vor MVP |
| 7.2 | Welche Erklärung ist für **club**-interne Sichtbarkeit (Vereinsmitglieder) erforderlich? Gilt § 22 KUG für vereinsintern? Reicht Selbsterklärung des Uploaders? | Pflichtfelder bei Promotion zu club | Vor MVP |
| 7.3 | Welche Erklärung ist für **official** (plattformweit, ggf. öffentlich) erforderlich? Reicht Selbsterklärung oder muss Einwilligung nachgewiesen werden? | Pflichtfelder bei Promotion zu official | Vor MVP |
| 7.4 | Wie ist mit erkennbaren **Minderjährigen** zu verfahren? Ab welchem Alter benötigen Minderjährige elterliche Einwilligung? Welche Einwilligungsform ist rechtssicher? | `contains_minors` + `parental_consent_confirmed` — Pflicht ab welcher Stufe? | Vor MVP |
| 7.5 | Reicht eine **Selbsterklärung** des Uploaders oder müssen Einwilligungs-Dokumente (Scan, Upload) archiviert werden? | Dateiupload für Einwilligungs-Scan nötig? (MVP oder später?) | Vor MVP |
| 7.6 | Ist eine **Batch-Deklaration** (eine Erklärung für mehrere Dateien des Uploads) rechtlich ausreichend? | Flow 3: Bulk-Upload-Design | Vor MVP |
| 7.7 | Muss die **Textfassung** der Erklärungen (Checkbox-Labels) durch Rechtsanwalt freigegeben werden? Welche konkreten Formulierungen sind erforderlich? | `declaration_version` Textbasis | Vor MVP |
| 7.8 | Wie sind **Altmedien** zu behandeln, die bereits mit club/official-Sichtbarkeit in der DB stehen? Muss der Betreiber diese sperren bis zur Nachdeklaration? | Migrationsstrategie §6.3 | Zeitnah |
| 7.9 | Wie ist bei **Widerruf** einer Einwilligung vorzugehen? Welche Fristen gelten? Muss das Medium sofort gelöscht oder nur gesperrt werden? | rights_status='blocked', Schnittstelle P-11 | Vor P-11 |
| 7.10 | Welche **Nachweisdaten** dürfen/sollen gespeichert werden (Datensparsamkeit vs. Rechenschaftspflicht)? Wie lange muss der Declaration-Log aufbewahrt werden? | Retention-Policy für `media_asset_rights_declarations` | Vor MVP |
| 7.11 | Welche Anforderungen gelten für **Trainingsvideos mit mehreren Personen**? Muss jede Person einzeln einwilligen oder reicht eine kollektive Erklärung? | `person_consent_confirmed` als Boolean vs. Mehrfach-Einwilligung | Vor MVP |
| 7.12 | Welche Anforderungen gelten für **Musik, Logos, Marken, Grafiken** von Dritten im Video/Bild? Ab wann ist eine separate Lizenz nötig? Reicht `music_rights_confirmed` als Selbsterklärung? | `contains_music`, `music_rights_confirmed` — MVP oder Pflicht? | Mittel |

---

## 8. Umsetzungsplan (für spätere Codephase — keine Umsetzungsfreigabe)

### P-06a – Datenmodell / Migration

| Feld | Wert |
|------|------|
| **Ziel** | Neue Tabelle `media_asset_rights_declarations` anlegen; drei neue Spalten in `media_assets` |
| **Betroffene Dateien** | `backend/migrations/048_media_rights_declarations.sql` (neu) |
| **Migrationsbedarf** | Neue Migration; `DEFAULT 'legacy_unreviewed'` automatisch für bestehende Zeilen |
| **Abhängigkeiten** | Keine (neue Tabelle) |
| **Testbedarf** | Migration idempotent; bestehende `media_assets`-Zeilen haben `rights_status='legacy_unreviewed'` nach Migration; neue Zeilen haben `rights_status='declared'` nach P-06b |
| **Akzeptanzkriterien** | Tabelle angelegt, alle Spalten korrekt typisiert, Indizes vorhanden, ALTER-Migration ohne Downtime anwendbar |
| **Risiko** | Niedrig (neue Tabelle + ALTER mit DEFAULT ohne Table-Lock in PostgreSQL 16) |
| **Rollback** | DROP TABLE media_asset_rights_declarations; ALTER TABLE media_assets DROP COLUMN rights_status, rights_declared_for_visibility, rights_declared_at |

---

### P-06b – Backend-Erzwingung

| Feld | Wert |
|------|------|
| **Ziel** | Backend blockiert Upload und Promotion wenn Pflichtfelder fehlen; schreibt Declarations-Log |
| **Betroffene Dateien** | `backend/routers/media_assets.py` (bulk-upload + patch + bulk-patch), `backend/routers/exercises.py` (upload_exercise_media, from-asset), neues Modul `backend/media_rights.py` (Hilfslogik) |
| **Neue Pydantic-Models** | `RightsDeclaration` (Pflichtfelder + optionale Felder); Integration in `MediaAssetPatch` + Upload-Endpoints |
| **Neue Fehlercodes** | `RIGHTS_DECLARATION_REQUIRED`, `CONSENT_REQUIRED_FOR_CLUB`, `CONSENT_REQUIRED_FOR_OFFICIAL`, `LEGACY_REDECLARATION_REQUIRED`, `RIGHTS_DECLARATION_REQUIRED_FOR_TARGET_VISIBILITY` |
| **Abhängigkeiten** | P-06a (Migration) muss abgeschlossen sein |
| **Testbedarf** | Unit-Tests für jeden neuen Fehlercode; Integrationstests Upload → Deklarationslog; Promotion ohne/mit Deklaration; Legacy-Block |
| **Akzeptanzkriterien** | Upload ohne `rights_holder_confirmed` → 400; promotion ohne Personen-Deklaration → 400; gültige Deklaration → Eintrag in DB vorhanden; bestehender P-04-Test weiterhin grün |
| **Risiko** | Mittel (Breaking Change für alle Upload-Clients); Feature-Flag zum schrittweisen Rollout empfohlen |
| **Rollback** | Feature-Flag deaktivieren; kein DB-Rollback nötig |

---

### P-06c – Frontend-Dialoge

| Feld | Wert |
|------|------|
| **Ziel** | Einwilligungsdialog in allen Upload-Pfaden; Promotions-Dialog bei Sichtbarkeitsänderung |
| **Betroffene Dateien** | `frontend/src/components/RightsDeclarationDialog.jsx` (neu, wiederverwendbar), `frontend/src/pages/ExerciseFormPage.jsx`, `frontend/src/pages/MediaLibraryPage.jsx`, `frontend/src/utils/api.js` |
| **Dialog-Typen** | Upload-Dialog (privat/club/official je nach Kontext), Promotions-Dialog (erkennt Sichtbarkeitserhöhung), Nachdeklarations-Dialog (für Legacy) |
| **Abhängigkeiten** | P-06b (Backend-Codes müssen definiert sein); juristische Textfreigabe für Checkbox-Labels |
| **Testbedarf** | Playwright E2E: Dialog erscheint; Upload ohne Checkbox → deaktivierter Button; Dialog mit allem ausgefüllt → erfolgreicher Upload; Backend-Fehler → korrekte Fehlermeldung |
| **Akzeptanzkriterien** | Dialog erscheint bei allen Upload-Pfaden; Checkbox-State korrekt; Labels entsprechen juristisch geprüften Formulierungen; Promotions-Dialog erkennt Sichtbarkeitserhöhung |
| **Risiko** | Mittel (UX-Änderung an häufig genutzten Pfaden) |
| **Rollback** | Feature-Flag; Dialoge können ohne Backend-Änderung deaktiviert werden |

---

### P-06d – Tests / Dokumentation

| Feld | Wert |
|------|------|
| **Ziel** | Vollständige Testabdeckung für P-06 + Doku-Update |
| **Betroffene Dateien** | `backend/tests/test_media_rights_declaration.py` (neu), `tests/dev-smoke-test.spec.js` (neue P-06-Tests), `docs/compliance-implementation.md`, `docs/compliance-package-register.md`, Access-Layer-Audit aktualisieren |
| **Backend-Tests** | Upload-Flows, Promotions-Flows, Legacy-Block, Declaration-Log, alle Fehlercodes |
| **Playwright-Tests** | Dialog erscheint, Checkbox-Validierung, vollständiger Upload-Flow, Promotions-Dialog |
| **Abhängigkeiten** | P-06a, P-06b, P-06c abgeschlossen |
| **Akzeptanzkriterien** | Alle neuen Tests grün; bestehende Tests unverändert grün; ACCESS_LAYER_STRICT=1 grün |
| **Risiko** | Niedrig |

---

### P-06e – Legacy-Nacharbeit (optional, nach juristischer Klärung)

| Feld | Wert |
|------|------|
| **Ziel** | Massenprüfung und ggf. Sperrung bestehender club/official-Medien ohne Deklaration, falls juristisch notwendig |
| **Betroffene Dateien** | `backend/scripts/media_rights_audit.py` (neu), evtl. Admin-UI |
| **Inhalt** | Script listet alle `visibility IN ('club', 'official')` mit `rights_status='legacy_unreviewed'`; Superadmin kann Massenmarkierung oder individuelle Überprüfung anstoßen |
| **Abhängigkeiten** | P-06a–d; juristische Klärung §7.8 |
| **Akzeptanzkriterien** | Script läuft ohne Fehler; erzeugt CSV-Report mit betroffenen Assets |
| **Risiko** | Mittel (wenn Sperrung aktiv: Betriebsunterbrechung für Vereinsmedien) |
| **Hinweis** | Erst nach juristischer Entscheidung über Altbestand-Behandlung umsetzen |

---

## 9. Abschlussbewertung

### 9.1 Neue / geänderte Dokumente

| Dokument | Änderung |
|----------|---------|
| `docs/p06-upload-rights-spec.md` | Neu erstellt (dieses Dokument) |
| `docs/compliance-roadmap.md` | P-06: Spezifikation erstellt vermerkt; nächste Freigabe angepasst |
| `docs/compliance-implementation.md` | Kurzer P-06-Eintrag: Spezifikation erstellt, keine Umsetzung |
| `docs/compliance-package-register.md` | P-06 Letzter Stand: Spezifikation vorhanden |

### 9.2 Empfohlene P-06-Zielarchitektur (Kurzfassung)

- **Append-only Log-Tabelle** `media_asset_rights_declarations` (Wer, Wann, Was, Welche Version)
- **Drei Status-Felder** in `media_assets`: `rights_status` / `rights_declared_for_visibility` / `rights_declared_at`
- **Gestufte Erklärungen**: Upload = Minimalset; Promotion club = Personen-Pflicht; Promotion official = vollständig
- **Backend-Erzwingung** über neue Fehlercodes; keine reine Frontend-Checkbox
- **Versionierung** über `declaration_version`-String; kein FK auf Texttabelle
- **Legacy**: `rights_status = 'legacy_unreviewed'`; Promotion blockiert; Nachdeklarations-Flow

### 9.3 Kritische Designentscheidungen

| Entscheidung | Begründung |
|-------------|-----------|
| Gestufte Erklärungen je Sichtbarkeitsstufe | Rechtsrisiko steigt mit Sichtbarkeit; Rechtsanschlussfähigkeit |
| Minimalset beim Erstupload | Nutzbarkeit vs. Compliance; Pflicht-Erweiterung bei Promotion |
| Append-only Log (nie löschen/ändern) | Nachweisbarkeit; Audit-Integrität |
| rights_status = 'legacy_unreviewed' per Default | Keine rückwirkende Sperrung; kontrollierbarer Übergang |
| Kein Einwilligungs-Datei-Upload (MVP) | Aufwand vs. Mehrwert; spätere Nachrüstung möglich |
| `rights_status = 'blocked'` als P-11-Schnittstelle | Zukunftssicherheit; P-11/P-13 können sofort anschließen |

### 9.4 Offene juristische Fragen (Priorisiert)

| Priorität | Frage | Paket-Impact |
|-----------|-------|-------------|
| Vor MVP | §7.7 Textfassung der Erklärungen | P-06c (Dialog-Labels) |
| Vor MVP | §7.1 Private: Reicht rights_holder allein? | Pflichtfeld-Definition |
| Vor MVP | §7.2 Club: § 22 KUG vereinsintern? | contains_persons bei club Pflicht? |
| Vor MVP | §7.4 Minderjährige: Schwelle und Form | parental_consent MVP oder später |
| Vor MVP | §7.5 Selbsterklärung oder Dokumenten-Upload? | Scope P-06c |
| Zeitnah | §7.8 Altmedien club/official: Sperrpflicht? | P-06e Scope |
| Vor P-11 | §7.9 Widerruf: Fristen und Mechanismus | P-11-Design |
| Mittel | §7.10 Aufbewahrung Declaration-Log | Retention-Policy |

### 9.5 Empfohlene spätere Umsetzungsschritte

1. Rechtsanwalt beauftragt für §7.7 (Texte) und §7.1–7.3 (Anforderungen je Stufe)
2. Nach Klärung §7.7: Freigabe P-06a + P-06b parallel (kein Frontend-Merge nötig)
3. Nach §7.7 Textfreigabe: Freigabe P-06c (Frontend-Dialoge)
4. P-06d: Tests + Doku beim gleichen Merge wie P-06b/P-06c
5. Nach §7.8-Klärung: ggf. P-06e (Legacy-Massenprüfung)

### 9.6 Implementierungsbereitschaft

| Kriterium | Einschätzung |
|-----------|-------------|
| P-06 implementierungsreif | Teilweise — Datenmodell und Backend-Logik spezifizierbar; Dialog-Labels nicht ohne juristische Textfreigabe |
| Juristische Vorabklärung erforderlich | Ja — §7.7 (Textfassung) blockiert P-06c; §7.1–7.3 bestimmen Pflichtfelder |
| P-06a (Migration) vorab umsetzbar | Ja — unabhängig von juristischen Texten |
| P-06b (Backend) vorab umsetzbar | Ja — mit Platzhalter-Fehlercodes, Texte nachrüstbar |
| P-06c (Frontend-Dialog) vorab umsetzbar | Nein — Dialog-Labels müssen juristisch freigegeben sein |

### 9.7 Scope-Drift-Prüfung

| Prüfung | Ergebnis |
|---------|---------|
| Codeänderungen vorgenommen? | Nein |
| Neue Migrationen erstellt? | Nein |
| Neue Endpoints erstellt? | Nein |
| Paket-ID geändert? | Nein |
| Andere Paket-IDs berührt? | Nein (P-11, P-13 nur als Referenz) |
| P-06 bleibt nach dieser Arbeit offen? | Ja |

---

**P-06 fachlich-technisch spezifiziert. Keine Codeänderungen vorgenommen.**

---

*Erstellt: 2026-05-10 | Autor: Claude Code | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.*