feat(sdk): Multi-Tenancy, Versionierung, Change-Requests, Dokumentengenerierung (Phase 1-6)

6-Phasen-Implementation fuer cloud-faehiges, mandantenfaehiges Compliance SDK:

Phase 1: Multi-Tenancy Fix
- Shared tenant_utils.py Dependency (UUID-Validierung, kein "default" mehr)
- VVT tenant_id Column + tenant-scoped Queries
- DSFA/Vendor DEFAULT_TENANT_ID von "default" auf UUID migriert
- Migration 035

Phase 2: Stammdaten-Erweiterung
- Company Profile um JSONB-Felder erweitert (processing_systems, ai_systems, technical_contacts)
- Regulierungs-Flags (NIS2, AI Act, ISO 27001)
- GET /template-context Endpoint
- Migration 036

Phase 3: Dokument-Versionierung
- 5 Versions-Tabellen (DSFA, VVT, TOM, Loeschfristen, Obligations)
- Shared versioning_utils.py Helper
- /{id}/versions Endpoints auf allen 5 Dokumenttypen
- Migration 037

Phase 4: Change-Request System
- Zentrale CR-Inbox mit CRUD + Accept/Reject/Edit Workflow
- Regelbasierte CR-Engine (VVT DPIA → DSFA CR, Datenkategorien → Loeschfristen CR)
- Audit-Trail
- Migration 038

Phase 5: Dokumentengenerierung
- 5 Template-Generatoren (DSFA, VVT, TOM, Loeschfristen, Obligations)
- Preview + Apply Endpoints (erzeugt CRs, keine direkten Dokumente)

Phase 6: Frontend-Integration
- Change-Request Inbox Page mit Stats, Filtern, Modals
- VersionHistory Timeline-Komponente
- SDKSidebar CR-Badge (60s Polling)
- Company Profile: 2 neue Wizard-Steps + "Dokumente generieren" CTA

Docs: 5 neue MkDocs-Seiten, CLAUDE.md aktualisiert
Tests: 97 neue Tests (alle bestanden)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs-src/services/sdk-modules/change-requests.md

@@ -0,0 +1,125 @@
+# Change-Request System (CP-CR)
+
+Das Change-Request-System ist die zentrale Inbox fuer alle Dokumentenaenderungen im Compliance SDK. Statt Dokumente direkt zu erstellen oder zu aendern, werden alle Aenderungen als Change-Requests vorgeschlagen und muessen explizit angenommen oder abgelehnt werden.
+
+## Architektur
+
+```mermaid
+graph TD
+    A[Trigger-Event] --> B[Change-Request Engine]
+    B --> C[CR-Inbox pending]
+    C --> D{Entscheidung}
+    D -->|Accept| E[Version erstellen]
+    D -->|Edit & Accept| F[Bearbeiten + Version]
+    D -->|Reject| G[Ablehnen + Begruendung]
+    E --> H[Audit-Log]
+    F --> H
+    G --> H
+```
+
+## API-Endpoints
+
+| Methode | Pfad | Beschreibung |
+|---------|------|--------------|
+| `GET` | `/change-requests` | Liste (Filter: status, doc_type, priority) |
+| `GET` | `/change-requests/stats` | Statistik: pending, critical, accepted, rejected |
+| `GET` | `/change-requests/{id}` | Detail mit Audit-Log |
+| `POST` | `/change-requests` | Manuell erstellen |
+| `POST` | `/change-requests/{id}/accept` | Aenderung uebernehmen, Version erstellen |
+| `POST` | `/change-requests/{id}/reject` | Ablehnen mit Begruendung |
+| `POST` | `/change-requests/{id}/edit` | Vorschlag bearbeiten und annehmen |
+| `DELETE` | `/change-requests/{id}` | Soft-Delete |
+
+## Status-Workflow
+
+```
+pending --> accepted
+pending --> rejected
+pending --> edited_and_accepted
+```
+
+## Prioritaeten
+
+- `critical` — Sofortige Aktion erforderlich
+- `high` — Wichtig, zeitnah bearbeiten
+- `normal` — Standard-Prioritaet
+- `low` — Kann warten
+
+## Trigger-Typen
+
+| Trigger | Erzeugte Change-Requests |
+|---------|--------------------------|
+| `generation` | Automatisch aus Stammdaten generiert |
+| `vvt_dpia` | VVT-Aktivitaet mit dpia_required=true → DSFA CR |
+| `vvt_data_category` | Neue Datenkategorie → Loeschfristen CR |
+| `use_case_risk` | Use Case mit hohem Risiko → DSFA CR |
+| `use_case_ai` | Use Case mit KI → DSFA Sektion-Update CR |
+| `manual` | Manuell erstellt |
+
+## Change-Request Engine
+
+Die Engine (`change_request_engine.py`) generiert automatisch Change-Requests bei bestimmten Trigger-Events:
+
+### VVT-Trigger
+```python
+generate_change_requests_for_vvt(db, tenant_id, activity, user)
+```
+- Wenn `dpia_required=true`: DSFA-CR wird erstellt
+- Fuer jede neue Datenkategorie: Loeschfristen-CR wird erstellt
+
+### Use-Case-Trigger
+```python
+generate_change_requests_for_use_case(db, tenant_id, use_case, user)
+```
+- Bei `risk_level` high/critical: DSFA-CR
+- Bei KI-Involvement: DSFA-Sektions-Update-CR
+
+## Frontend
+
+Die Change-Request Inbox ist unter `/sdk/change-requests` erreichbar:
+- Stats-Bar mit Zahlen (pending, critical, accepted, rejected)
+- Filter nach Status und Dokumenttyp
+- Card-Liste mit Trigger-Badge, Titel, Prioritaet
+- Accept/Edit/Reject Modals
+- 60s Auto-Refresh
+
+## Datenbank
+
+### Migration 038
+
+```sql
+CREATE TABLE compliance_change_requests (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    tenant_id VARCHAR(255) NOT NULL,
+    trigger_type VARCHAR(50) NOT NULL,
+    target_document_type VARCHAR(50),
+    target_document_id UUID,
+    target_section VARCHAR(100),
+    proposal_title VARCHAR(500) NOT NULL,
+    proposal_body TEXT,
+    proposed_changes JSONB DEFAULT '{}',
+    status VARCHAR(30) DEFAULT 'pending',
+    priority VARCHAR(20) DEFAULT 'normal',
+    decided_by VARCHAR(255),
+    decided_at TIMESTAMPTZ,
+    rejection_reason TEXT,
+    created_by VARCHAR(255) DEFAULT 'system',
+    created_at TIMESTAMPTZ DEFAULT NOW(),
+    deleted_at TIMESTAMPTZ
+);
+
+CREATE TABLE compliance_change_request_audit (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    change_request_id UUID REFERENCES compliance_change_requests(id),
+    action VARCHAR(50) NOT NULL,
+    performed_by VARCHAR(255),
+    before_state JSONB,
+    after_state JSONB,
+    created_at TIMESTAMPTZ DEFAULT NOW()
+);
+```
+
+## Tests
+
+- 26 Tests in `test_change_request_routes.py`
+- Schema-Validierung, Engine-Regeln, Route-Registrierung

docs-src/services/sdk-modules/dokumentengenerierung.md

@@ -0,0 +1,82 @@
+# Dokumentengenerierung aus Stammdaten
+
+Basierend auf dem Unternehmensprofil (Stammdaten) koennen Compliance-Dokumente automatisch als Entwuerfe generiert werden. Die Generierung erzeugt Change-Requests, KEINE direkten Dokumente — alles muss ueber die CR-Inbox reviewed werden.
+
+## Workflow
+
+```mermaid
+graph LR
+    A[Stammdaten] --> B[Template-Engine]
+    B --> C[Draft-Dokumente]
+    C --> D[Change-Requests]
+    D --> E[CR-Inbox Review]
+    E --> F[Finales Dokument]
+```
+
+## API-Endpoints
+
+| Methode | Pfad | Beschreibung |
+|---------|------|--------------|
+| `GET` | `/generation/preview/{doc_type}` | Vorschau ohne DB-Writes |
+| `POST` | `/generation/apply/{doc_type}` | Generiert Drafts → erstellt CRs |
+
+### Gueltige Dokumenttypen
+
+`dsfa`, `vvt`, `tom`, `loeschfristen`, `obligation`
+
+## Template-Generatoren
+
+### DSFA (`dsfa_template.py`)
+- Erstellt DSFA-Skeleton basierend auf Firmenprofil
+- Wenn KI-Systeme vorhanden: `risk_level = high`, AI-Sections befuellt
+- DPO-Name und Aufsichtsbehoerde automatisch eingesetzt
+
+### VVT (`vvt_template.py`)
+- Ein VVT-Eintrag pro `processing_system`
+- US-Cloud-Hosting → automatisch Drittlandtransfer-Eintrag
+- Datenkategorien und Rechtsgrundlagen vorausgefuellt
+
+### TOM (`tom_template.py`)
+- 8 Basis-TOMs (DSGVO-Standard)
+- +3 bei `subject_to_nis2` (Cybersicherheit)
+- +3 bei `subject_to_ai_act` (KI-Compliance)
+- +3 bei `subject_to_iso27001` (ISMS)
+
+### Loeschfristen (`loeschfristen_template.py`)
+- Eine Loeschfrist pro Datenkategorie aus processing_systems
+- 10 Standard-Perioden (z.B. Bankdaten → 10 Jahre HGB)
+- Unbekannte Kategorien → "Noch festzulegen"
+- Deduplizierung bei mehreren Systemen mit gleicher Kategorie
+
+### Pflichten (`obligation_template.py`)
+- 8 Basis-DSGVO-Pflichten
+- +3 bei AI Act
+- +2 bei NIS2
+
+## Stammdaten-Kontext
+
+Der Template-Kontext wird aus `compliance_company_profiles` gelesen und enthaelt:
+
+| Feld | Beschreibung |
+|------|--------------|
+| `company_name` | Firmenname |
+| `dpo_name`, `dpo_email` | Datenschutzbeauftragter |
+| `supervisory_authority` | Aufsichtsbehoerde |
+| `processing_systems` | IT-Systeme mit pbD |
+| `ai_systems` | KI-System-Katalog |
+| `subject_to_nis2/ai_act/iso27001` | Regulierungs-Flags |
+| `review_cycle_months` | Pruefzyklus |
+
+## Frontend
+
+Im Company-Profile-Wizard erscheint nach Abschluss (`is_complete = true`) ein CTA-Panel "Dokumente generieren":
+- Pro Dokumenttyp ein "Generieren"-Button
+- Ergebnis: Anzahl erstellter Change-Requests
+- Link zur CR-Inbox
+
+## Tests
+
+- 21 Tests in `test_generation_routes.py`
+- Alle 5 Template-Generatoren mit verschiedenen Kontext-Variationen
+- Regulierungs-Flag-Kombinationen
+- Route-Registrierung

docs-src/services/sdk-modules/multi-tenancy.md

@@ -0,0 +1,60 @@
+# Multi-Tenancy
+
+Das Compliance SDK ist vollstaendig mandantenfaehig. Jeder Tenant hat isolierte Daten — kein Tenant kann auf Daten eines anderen zugreifen.
+
+## Tenant-ID
+
+- Format: UUID v4 (z.B. `9282a473-5c95-4b3a-bf78-0ecc0ec71d3e`)
+- Der String `"default"` wird NICHT mehr akzeptiert
+- Validierung via Regex in `tenant_utils.py`
+
+## Shared Tenant Middleware
+
+`compliance/api/tenant_utils.py` stellt eine zentrale FastAPI-Dependency:
+
+```python
+from compliance.api.tenant_utils import get_tenant_id
+
+@router.get("/example")
+async def example(tid: str = Depends(get_tenant_id)):
+    # tid ist validierte UUID
+    ...
+```
+
+### Resolution-Reihenfolge
+
+1. `X-Tenant-ID` HTTP-Header
+2. `tenant_id` Query-Parameter
+3. `DEFAULT_TENANT_ID` Umgebungsvariable
+4. Fallback: `9282a473-5c95-4b3a-bf78-0ecc0ec71d3e`
+
+## Migration 035: VVT Tenant Isolation
+
+- `compliance_vvt_activities`, `compliance_vvt_organization`, `compliance_vvt_audit_log`: `tenant_id VARCHAR(255) NOT NULL` hinzugefuegt
+- Bestehende Daten auf Standard-UUID backfilled
+- UNIQUE-Constraint `(tenant_id, vvt_id)` statt globalem `vvt_id`
+- DSFA/Vendor: `"default"` → UUID migriert
+
+## Betroffene Module
+
+| Modul | Aenderung |
+|-------|-----------|
+| VVT | `tenant_id` Column + Query-Filter auf alle Endpoints |
+| DSFA | `DEFAULT_TENANT_ID` von `"default"` auf UUID |
+| Vendor Compliance | `DEFAULT_TENANT_ID` von `"default"` auf UUID |
+| Change-Requests | Nativ mit `tenant_id` |
+| Versionierung | Nativ mit `tenant_id` |
+| Company Profile | Nativ mit `tenant_id` |
+
+## Frontend-Proxy
+
+Der Next.js-Proxy setzt automatisch den `X-Tenant-ID` Header:
+
+```typescript
+headers['X-Tenant-ID'] = clientTenantId || process.env.DEFAULT_TENANT_ID || '9282a473-...'
+```
+
+## Tests
+
+- 20 Tests in `test_vvt_tenant_isolation.py`
+- UUID-Validierung, Header-/Query-Precedence, Model-Column-Checks, Route-Isolation

docs-src/services/sdk-modules/stammdaten.md

@@ -0,0 +1,90 @@
+# Stammdaten / Company Profile
+
+Das Unternehmensprofil (Stammdaten) bildet die Grundlage fuer die automatische Dokumentengenerierung. Es wird in einem mehrstufigen Wizard erfasst.
+
+## Wizard-Schritte
+
+| Schritt | Name | Felder |
+|---------|------|--------|
+| 1 | Basisinfos | Firmenname, Rechtsform, Branche, Gruendungsjahr |
+| 2 | Geschaeftsmodell | B2B/B2C/B2B2C, Angebote |
+| 3 | Firmengroesse | Unternehmengroesse, Mitarbeiterzahl, Umsatz |
+| 4 | Standorte | Hauptsitz, Zielmaerkte |
+| 5 | Datenschutz | Datenschutz-Rolle, KI-Nutzung, DSB |
+| 6 | Systeme & KI | IT-Systeme (pbD), KI-System-Katalog |
+| 7 | Rechtlicher Rahmen | NIS2/AI Act/ISO 27001, Aufsichtsbehoerde, Pruefzyklus, Ansprechpartner |
+| 8 | Produkt & Maschine | Nur fuer Maschinenbauer: CE, Safety, Software |
+
+## API-Endpoints
+
+| Methode | Pfad | Beschreibung |
+|---------|------|--------------|
+| `GET` | `/company-profile` | Profil laden |
+| `POST` | `/company-profile` | Profil erstellen/aktualisieren (Upsert) |
+| `DELETE` | `/company-profile` | Profil loeschen (DSGVO Art. 17) |
+| `GET` | `/company-profile/template-context` | Flacher Dict fuer Template-Substitution |
+
+## Erweiterte Felder (Phase 2)
+
+### Migration 036
+
+| Spalte | Typ | Beschreibung |
+|--------|-----|--------------|
+| `repos` | JSONB | Git-Repos im Scope |
+| `document_sources` | JSONB | Bestehende Compliance-Dokumente |
+| `processing_systems` | JSONB | IT-Systeme mit personenbezogenen Daten |
+| `ai_systems` | JSONB | Strukturierter KI-System-Katalog |
+| `technical_contacts` | JSONB | CISO, IT-Manager etc. |
+| `subject_to_nis2` | BOOLEAN | NIS2-Pflicht |
+| `subject_to_ai_act` | BOOLEAN | AI Act relevant |
+| `subject_to_iso27001` | BOOLEAN | ISO 27001 Zertifizierung |
+| `supervisory_authority` | VARCHAR(255) | Zustaendige Aufsichtsbehoerde |
+| `review_cycle_months` | INTEGER | Pruefzyklus in Monaten |
+
+### Processing Systems Format
+
+```json
+[
+  {
+    "name": "SAP HR",
+    "vendor": "SAP",
+    "hosting": "cloud",
+    "personal_data_categories": ["Mitarbeiter", "Bankdaten"]
+  }
+]
+```
+
+### AI Systems Format
+
+```json
+[
+  {
+    "name": "Chatbot",
+    "purpose": "Kundensupport",
+    "risk_category": "limited",
+    "vendor": "OpenAI",
+    "has_human_oversight": true
+  }
+]
+```
+
+## Template-Kontext
+
+Der Endpoint `GET /company-profile/template-context` liefert einen flachen Dict, der direkt in die Template-Generierung einfliessen kann:
+
+```json
+{
+  "company_name": "Acme GmbH",
+  "processing_systems": [...],
+  "ai_systems": [...],
+  "subject_to_nis2": false,
+  "subject_to_ai_act": true,
+  "has_ai_systems": true,
+  "is_complete": true
+}
+```
+
+## Tests
+
+- 10 Tests in `test_company_profile_extend.py`
+- Pydantic-Schema-Validierung, Row-to-Response-Mapping, Template-Kontext

docs-src/services/sdk-modules/versionierung.md

@@ -0,0 +1,80 @@
+# Dokument-Versionierung
+
+Alle Compliance-Dokumente (DSFA, VVT, TOM, Loeschfristen, Pflichten) werden automatisch versioniert. Jede Aenderung erzeugt eine neue Version mit Snapshot, Change-Summary und geaenderten Sektionen.
+
+## Architektur
+
+Das Versionierungs-Pattern folgt dem bestehenden `compliance_legal_document_versions`-Ansatz:
+- Separate Versions-Tabelle pro Dokumenttyp
+- Snapshot als JSONB (vollstaendiger Dokumentstand)
+- Status-Workflow: draft → approved
+- `current_version` Column auf der Haupt-Tabelle
+
+## Unterstuetzte Dokumenttypen
+
+| Typ | Versions-Tabelle | FK-Column |
+|-----|-----------------|-----------|
+| DSFA | `compliance_dsfa_versions` | `dsfa_id` |
+| VVT | `compliance_vvt_activity_versions` | `activity_id` |
+| TOM | `compliance_tom_versions` | `measure_id` |
+| Loeschfristen | `compliance_loeschfristen_versions` | `policy_id` |
+| Pflichten | `compliance_obligation_versions` | `obligation_id` |
+
+## API-Endpoints
+
+Fuer jeden Dokumenttyp gibt es zwei Versioning-Endpoints:
+
+| Methode | Pfad | Beschreibung |
+|---------|------|--------------|
+| `GET` | `/{id}/versions` | Alle Versionen (neueste zuerst) |
+| `GET` | `/{id}/versions/{v}` | Spezifische Version mit Snapshot |
+
+### Beispiele
+
+```
+GET /api/compliance/dsfa/{dsfa_id}/versions
+GET /api/compliance/dsfa/{dsfa_id}/versions/3
+GET /api/compliance/activities/{id}/versions
+GET /api/compliance/measures/{id}/versions
+GET /api/compliance/loeschfristen/{id}/versions
+GET /api/compliance/obligations/{id}/versions
+```
+
+## Shared Helper
+
+`versioning_utils.py` stellt drei Funktionen bereit:
+
+```python
+create_version_snapshot(db, doc_type, doc_id, tenant_id, snapshot, change_summary, changed_sections, created_by)
+list_versions(db, doc_type, doc_id, tenant_id)
+get_version(db, doc_type, doc_id, tenant_id, version_number)
+```
+
+## Frontend-Komponente
+
+Die `VersionHistory` React-Komponente zeigt eine Timeline aller Versionen:
+
+```tsx
+<VersionHistory
+  documentType="dsfa"
+  documentId={dsfa.id}
+  apiPath={`dsfa/${dsfa.id}/versions`}
+/>
+```
+
+Features:
+- Expandierbare Timeline mit Version-Dots
+- Status-Badges (approved/draft)
+- Datum und geaenderte Sektionen
+- Change-Summary
+
+## Datenbank
+
+### Migration 037
+
+Erstellt 5 Versions-Tabellen und fuegt `current_version INTEGER DEFAULT 0` zu allen Quell-Tabellen hinzu.
+
+## Tests
+
+- 20 Tests in `test_document_versions.py`
+- VERSION_TABLES Mapping, create/list/get Version, Route-Registrierung