leocrm/FIX-PLAN.md

# LeoCRM — Umfassender Fix-Plan

> Erstellt: 2026-07-25
> Quellen: Externes Audit (geprüft), eigene Code-Inspektion, Coolify-Deployment-Prüfung

---

## P0 — Sofort blockierend (vor jeder Nutzung)

### P0-1: Authentifizierungs-Bypass entfernen

**Problem:** `app/deps.py` akzeptiert `X-Internal-Call: true` mit `X-Tenant-Id` und `X-User-Id` Headern. Keine Signatur, kein Token, keine IP-Beschränkung. `except (ValueError, Exception): pass` verschleiert Fehler.

**Datei:** `app/deps.py:37-58`

**Maßnahme:**
- Header-Authentifizierung komplett entfernen
- Für interne Service-Kommunikation: dedizierte Service-Accounts mit kurzlebigen signierten Tokens (JWT mit `aud`, `iss`, `sub`, `tenant_id`, `exp`)
- Separate interne API oder mTLS
- Keine Übernahme beliebiger `user_id` aus einem Header
- Audit-Logging jeder Delegation
- `except (ValueError, Exception): pass` ersetzen durch spezifisches Exception-Handling mit Logging

**Aufwand:** 2-4 Stunden

---

### P0-2: Destruktive Migrationen ersetzen

**Problem:**
- `alembic/versions/0021_unified_contacts.py`: `DROP TABLE` ohne Datenübernahme
- `alembic/versions/0027_unify_company_to_contact.py`: `company_id` wird gelöscht ohne Datenübernahme; Downgrade ändert pauschal alle `entity_type='contact'` zurück zu `'company'`
- `migration_0021.sql` im Projekt-Root: konkurrierender Migrationsweg, manipuliert `alembic_version` direkt

**Dateien:**
- `alembic/versions/0021_unified_contacts.py`
- `alembic/versions/0027_unify_company_to_contact.py`
- `migration_0021.sql` (löschen)

**Maßnahme:**
1. `migration_0021.sql` löschen
2. Migration 0021 durch echte Transformationsmigration ersetzen:
   - Alte Tabellen umbenennen (`_old` suffix), nicht löschen
   - Daten mit `INSERT ... SELECT` übertragen
   - Anzahl, Checksummen und Plausibilität vor/nach der Migration vergleichen
   - Alttabellen erst in späterer Migration entfernen
3. Migration 0027 korrigieren:
   - `company_id` Werte vor Drop in `contact_id` übertragen
   - Downgrade: nur Datensätze zurückändern, die ursprünglich `'company'` waren (Tracking-Spalte oder separate Tabelle)
4. Automatisierten Upgrade-Test von jeder unterstützten Version auf `head` einführen
5. Migrationen gegen reale anonymisierte DB-Kopien testen

**Aufwand:** 4-8 Stunden

---

### P0-3: Plugin-Upload und URL-Installation deaktivieren

**Problem:** `app/routes/plugins.py` führt `spec.loader.exec_module(module)` aus **bevor** die Sicherheitsprüfung läuft. Das ist Remote Code Execution. Weitere Probleme: unzureichende ZIP-Traversal-Prüfung, kein Symlink-Check, keine ZIP-Bomb-Prävention, SSRF bei URL-Installation, Plugin wird in laufenden Container kopiert.

**Datei:** `app/routes/plugins.py:347-354` (`_extract_plugin_from_zip`)

**Maßnahme:**
1. **Sofort:** Upload- und URL-Installationsendpunkte (`/upload`, `/install-url`) deaktivieren oder entfernen
2. **Langfristig — Vertrauensmodell:**
   - Nur signierte Plugin-Artefakte aus einer Allowlist
   - Plugin-Code wird vor der Ausführung auf Signatur geprüft
3. **Langfristig — Isolationsmodell:**
   - Plugin-Ausführung in separaten Containern mit minimalen Rechten
   - Versionierte Plugin-API
4. ZIP-Traversal-Prüfung korrigieren: `os.path.abspath` gegen Base-Dir prüfen nach Extraction
5. Symlink-Check hinzufügen
6. Entpackungsgrößen-Limit (Anzahl Dateien + Gesamtgröße)
7. URL-Download: Redirects verbieten, interne IP-Ranges blockieren, Streaming statt RAM

**Aufwand:** Sofort-Deaktivierung 30 Min; Langfristig 2-3 Tage

---

### P0-4: Mandantentrennung (RLS) reparieren

**Problem:**
- `alembic/versions/0015_rls_policies.py`: Kein `FORCE ROW LEVEL SECURITY`, kein `WITH CHECK`
- Tabellen-Owner umgeht RLS
- Plugin-Tabellen nicht in RLS-Liste
- `TenantMixin` Docstring behauptet ORM-Autofilterung, die nicht existiert
- `app/core/tenant.py` hat nur manuelle `apply_tenant_filter()` Funktion
- `contactpersons` hat `tenant_id` aber FK auf `contacts.id` ohne Tenant-Bedingung → Cross-Tenant-FK möglich

**Dateien:**
- `alembic/versions/0015_rls_policies.py`
- `app/core/db/__init__.py` (TenantMixin Docstring)
- `app/core/tenant.py`
- Neue Migration für FORCE + WITH CHECK

**Maßnahme:**
1. Neue Migration: `ALTER TABLE ... FORCE ROW LEVEL SECURITY` für alle Tenant-Tabellen
2. Policies mit `USING` und `WITH CHECK` neu erstellen
3. Separater DB-Migrationsowner; Runtime-User ohne Owner- oder Bypass-RLS-Rechte
4. RLS für alle mandantenbezogenen Tabellen, einschließlich Plugin-Tabellen
5. CI-Test: Cross-Tenant-Lese- und Schreibversuche
6. Composite-Integrität: eindeutiges `(tenant_id, id)` und FK auf `(tenant_id, contact_id)`
7. `TenantMixin` Docstring korrigieren: Autofilterung existiert nicht
8. Zentralen Query-/Repository-Mechanismus einführen statt freiwilliger Tenant-Filter
9. Später neu erstellte Tabellen automatisch erfassen (Event-Listener oder CI-Check)

**Aufwand:** 1-2 Tage

---

### P0-5: Plugin-System Doppelregistrierung beheben

**Problem:**
- `app/main.py` `create_app()` registriert alle Plugin-Routen unabhängig vom Aktivierungsstatus
- `lifespan()` registriert dieselben Routen nochmal → Doppelregistrierung
- `lifespan()` auto-installiert und auto-aktiviert alle Builtins bei jedem Start
- Deaktivierte Plugins werden reaktiviert
- `registry._plugins` wird direkt zugegriffen (private Feld)
- Migrationsfehler werden nur geloggt, Aktivierung wird trotzdem versucht
- 204 direkte Cross-Imports zwischen Built-in-Plugins

**Datei:** `app/main.py:317-330` und `app/main.py:112-165`

**Maßnahme:**
1. Routen **einmalig** beim Prozessstart registrieren — entweder in `create_app()` ODER in `lifespan()`, nicht beides
2. Aktivierungsstatus vor dem Router-Aufbau laden und respektieren
3. Keine dynamische Änderung von FastAPI-Routen während des Betriebs
4. Aktivierung/Deaktivierung erfordert kontrollierten Neustart
5. Fehlgeschlagene Migration blockiert den Start (nicht nur loggen)
6. Core-Module und optionale Module klar trennen
7. Kein Zugriff auf `registry._plugins` — öffentliche API verwenden
8. Plugin-Abhängigkeiten über deklarierte Contracts prüfen
9. **Langfristig:** Cross-Imports reduzieren — öffentliche Schnittstellen statt direkter Modell-Imports

**Aufwand:** 1 Tag für Doppelregistrierung; Cross-Import-Reduktion 1-2 Wochen

---

### P0-6: Persistent Volume für Coolify-Deployment

**Problem:** Der laufende Container hat **keine Volume-Mounts** (`[]`). `/data/storage` ist nicht persistent. Alle hochgeladenen Dateien (DMS, Attachments, Bilder) gehen bei jedem Redeployment verloren. Plugin-Dateien in `app/plugins/builtins/` überleben keinen Neustart.

**Gefunden in:** Coolify-Container-Inspect (live)

**Maßnahme:**
1. In Coolify persistentes Volume für `/data/storage` konfigurieren
2. Alternativ: S3-kompatiblen Object Storage verwenden (`.env.example` hat bereits `STORAGE_BACKEND=s3` Support)
3. Plugin-Dateien nicht in Container-Filesystem kopieren — separate Plugin-Registry mit DB-basierter Konfiguration

**Aufwand:** 1-2 Stunden (Volume in Coolify konfigurieren)

---

### P0-7: App von öffentlicher Domain nehmen

**Problem:** Die App läuft unter `https://crm.media-on.de` und ist öffentlich erreichbar — mit allen P0-Schwachstellen (Auth-Bypass, Plugin-RCE, XSS, etc.).

**Gefunden in:** Coolify-Deployment-Prüfung

**Maßnahme:**
1. **Sofort:** App von öffentlicher Domain nehmen oder IP-Whitelist/Basic Auth vorschalten
2. Mindestens P0-1 (Auth-Bypass) und P0-3 (Plugin-Upload) beheben bevor wieder öffentlich
3. Alternativ: VPN/Tunnel-Zugang statt öffentliche Domain

**Aufwand:** 30 Minuten

---

## P1 — Vor Nutzung realer Kundendaten

### P1-1: Benutzer- und Mandantenmodell bereinigen

**Problem:**
- `User` hat `tenant_id`, `role`, `role_id` — gleichzeitig existiert `UserTenant` mit `tenant_id`, `role_id`, `is_default`
- Zwei Quellen der Wahrheit für Mandantenzugehörigkeit und Rollen
- `login()` sucht nur nach `email` mit `scalar_one_or_none()` → crasht bei mehreren Treffern (gleiche E-Mail in mehreren Mandanten)
- `tenant_slug` Parameter in `login()` wird von Login-Route nicht übergeben
- `TenantService.list_tenant_users()` sucht über `User.tenant_id` und ignoriert N:M-Mitgliedschaften

**Dateien:**
- `app/models/user.py`
- `app/services/auth_service.py:30-80`
- `app/routes/auth.py`

**Maßnahme:**
1. `users.email` global eindeutig machen (nicht `(tenant_id, email)`)
2. `User.tenant_id` und `User.role`/`User.role_id` entfernen
3. `tenant_memberships` als einzige Quelle: `tenant_id`, `user_id`, `role_id`, `status`, `is_default`
4. `login()` mit `tenant_slug` verknüpfen oder Default-Tenant verwenden
5. `TenantService.list_tenant_users()` über `UserTenant` suchen

**Aufwand:** 1 Tag

---

### P1-2: Redis-Verbindungen zentralisieren

**Problem:** `app/core/auth.py:49-51` erstellt pro Aufruf einen neuen Redis-Client. Kein Pool, kein Close. Dasselbe bei `enqueue_job()` für ARQ-Pools. Folgen: Connection-Lecks, Socket-Erschöpfung, instabiles Verhalten unter Last.

**Datei:** `app/core/auth.py:49-51`, `app/core/worker.py` (enqueue_job)

**Maßnahme:**
1. Redis-Client einmal im Application-Lifespan initialisieren
2. Bei Shutdown schließen
3. Über Dependency Injection verteilen
4. ARQ-Pool einmalig erstellen und wiederverwenden

**Aufwand:** 2-4 Stunden

---

### P1-3: Worker und Scheduler aus API-Container auslagern

**Problem:** `prestart.sh` startet ARQ-Worker im Hintergrund und Uvicorn als PID 1. Worker-Tod wird nicht erkannt. Worker und API konkurrieren um Ressourcen. Keine separate Skalierung. Cron-Jobs können bei mehreren Replikas mehrfach ausgeführt werden.

**Datei:** `prestart.sh`

**Maßnahme:**
1. Worker in separaten Container auslagern
2. Scheduler in separaten Container mit verteilter Lock-/Leader-Election
3. Idempotente Jobs
4. Heartbeat mit Zeitstempel
5. Dead-Letter-/Failed-Job-Strategie
6. Retry-Policy pro Jobtyp
7. Worker-Healthcheck prüft ob Worker lebt, nicht nur ob Redis-Queue lesbar ist

**Aufwand:** 1-2 Tage

---

### P1-4: Transactional Outbox einführen

**Problem:** `app/core/event_bus.py` ist rein speicherbasiert. Events verschwinden bei Prozessabsturz, Neustart, mehreren Replikas, Handler-Fehlern. `asyncio.gather(..., return_exceptions=True)` sammelt Fehler ohne Behandlung.

**Datei:** `app/core/event_bus.py`

**Maßnahme:**
1. Transactional Outbox in PostgreSQL
2. Worker verarbeitet Outbox-Einträge
3. Inbox/Idempotency-Key auf Konsumentenseite
4. Retry und Dead Letter
5. Events versionieren
6. In-Process-Bus nur für unkritische lokale Benachrichtigungen

**Aufwand:** 2-3 Tage

---

### P1-5: XSS-Stellen schließen

**Problem:**
- `HtmlBlock.tsx`: Regex-Sanitizer + `dangerouslySetInnerHTML` — HTML lässt sich nicht sicher mit Regex sanitizen
- `SignatureManager.tsx:201`: `dangerouslySetInnerHTML={{ __html: sig.body_html }}` **ohne jegliche Sanitization**
- `ActionCardBlock.tsx:21-28`: `window.open(action.action)` ohne URL-Validierung — `javascript:`-URLs möglich
- Mail-Service: `body_html_sanitized = body_html` ohne Sanitizer an manchen Stellen

**Dateien:**
- `frontend/src/components/comm/blocks/HtmlBlock.tsx`
- `frontend/src/components/mail/SignatureManager.tsx`
- `frontend/src/components/comm/blocks/ActionCardBlock.tsx`
- Mail-Service (body_html_sanitized)

**Maßnahme:**
1. Serverseitig konsequent `nh3` verwenden
2. Frontend zusätzlich `DOMPurify` als zweite Barriere
3. Keine selbst gebauten Regex-Sanitizer
4. Nur `https:` und kontrollierte interne Pfade erlauben
5. Strikte Content Security Policy ohne `unsafe-inline`
6. Signatur-, Mail-, KI- und Kommunikationsinhalte als nicht vertrauenswürdig behandeln

**Aufwand:** 4-6 Stunden

---

### P1-6: DMS Dateiverarbeitung lastfest machen

**Problem:** `app/plugins/builtins/dms/routes.py` liest die komplette Datei in RAM (`content = await file.read()`). Max 100 MB. Bei 10 parallelen Uploads mehrere GB RAM. Kein Virenscan, kein Content-Hash, keine Dublettenerkennung, keine Tenant-Quotas, kein Versionierungsmodell, kein Garbage Collector für physische Dateien nach Soft Delete. `storage_path` wird an Frontend ausgegeben. Benutzerdateiname direkt in Content-Disposition.

**Datei:** `app/plugins/builtins/dms/routes.py:421-436`

**Maßnahme:**
1. Chunked Streaming direkt in Object Storage
2. Maximale Größe auf Proxy- und Anwendungsebene
3. SHA-256 Content-Hash
4. Malware-Scan
5. Quotas pro Tenant
6. Versionierte Metadaten
7. Garbage Collector für physische Dateien nach Soft Delete
8. `storage_path` nicht an Frontend ausgeben
9. Benutzerdateiname sanitizen vor Content-Disposition
10. Synchronen MinIO-Client aus `async def` entfernen

**Aufwand:** 1-2 Tage

---

### P1-7: Berechtigungssystem vereinheitlichen

**Problem:**
- Legacy-Rollenstrings (`admin`/`editor`/`viewer`) + neue Rollen mit `role_id` + Gruppen + Allow/Deny + Feldrechte + `is_system_admin` + globale Write-Hilfsrechte
- `permission_version` wird gespeichert, beim Cache-Lesen aber nicht geprüft
- Cache-Invalidierung verwendet `redis.keys()` — blockiert Redis bei großen Datenmengen
- Feldrechte mehrerer Gruppen werden per `dict.update()` überschrieben (last-write-wins)
- `viewer` erhält `user_preferences:write`
- `require_write()` erlaubt `*:write` oder `*:create` (zu breit)
- `db.rollback()` bei Permission-Fehler setzt fremde Transaktionsarbeit zurück

**Datei:** `app/core/permissions.py`, `app/deps.py`

**Maßnahme:**
1. Nur noch Capability-basierte Berechtigungen (`contacts.read`, `contacts.create`, etc.)
2. Keine generische `require_write`-Freigabe
3. Alte Rollenlogik entfernen
4. Feldrechte deterministisch nach "strengstes Recht gewinnt" zusammenführen
5. `permission_version` beim Cache-Lesen prüfen
6. `redis.keys()` ersetzen durch `redis.scan()` oder gezielte Cache-Key-Invalidierung
7. `db.rollback()` nur in eigenen Transaktionskontext

**Aufwand:** 1-2 Tage

---

### P1-8: Password Reset funktionsfähig machen

**Problem:** `request_password_reset()` erstellt ein Token, speichert es in der DB, sendet es aber nicht. Nicht einmal geloggt. Die Variable `raw_token` wird nach Erstellung ignoriert. Die Route sagt "a reset link has been sent" — das ist fachlich falsch. Nach Passwortwechsel werden bestehende Sessions nicht widerrufen.

**Datei:** `app/services/auth_service.py:159-200`

**Maßnahme:**
1. Reset-Mail über echte Queue verschicken (ARQ-Worker)
2. Token nur einmal verwendbar
3. Alle Sessions des Benutzers nach Passwortänderung widerrufen
4. Sicherheitsereignis protokollieren
5. Optional: Nutzer über Passwortänderung informieren

**Aufwand:** 2-4 Stunden

---

### P1-9: Metrics-Endpunkt absichern

**Problem:** `app/routes/metrics.py` sagt "admin-only" im Docstring, verwendet aber nur `get_current_user` statt `require_admin`. Jeder angemeldete Benutzer kann Prometheus-Metriken abrufen.

**Datei:** `app/routes/metrics.py`

**Maßnahme:**
1. `require_admin` oder `require_permission("system:metrics")` verwenden
2. Alternativ: internes Netzwerk, Reverse-Proxy-Allowlist, dedizierten Monitoring-Token oder mTLS

**Aufwand:** 30 Minuten

---

### P1-10: Coolify-Dokumentation korrigieren

**Problem:**
- `COOLIFY_SETUP.md` Abschnitt 6 dokumentiert `/health` als Healthcheck-Pfad — die App hat nur `/api/v1/health`. `/health` liefert nur die SPA `index.html` (Catch-All).
- `COOLIFY_SETUP.md` listet `JWT_ALGORITHM` und `JWT_EXPIRY_HOURS` — werden von der App nicht verwendet.
- `CORS_ORIGINS` in Coolify ohne `:443` — `COOLIFY_SETUP.md` sagt explizit Port ist mandatory.

**Dateien:** `COOLIFY_SETUP.md`, `docs/deployment-guide.md`

**Maßnahme:**
1. Healthcheck-Pfad in Doku auf `/api/v1/health` korrigieren
2. JWT-Variablen aus Doku entfernen oder App auf JWT umstellen
3. `CORS_ORIGINS` in Coolify auf `https://crm.media-on.de:443` setzen
4. `docker-compose.yml` Healthcheck auf `/api/v1/health` korrigieren
5. `docker-compose.yml` Redis-Service hinzufügen
6. `docker-compose.yml` `REDIS_URL` setzen
7. `docker-compose.yml` persistentes Volume für `/data/storage`
8. `docker-compose.yml` `SESSION_COOKIE_SECURE=true` für Production
9. `docker-compose.yml` `STORAGE_PATH=/data/storage` setzen
10. `config.py` Default `storage_path` von `/tmp` auf `/data/storage` ändern
11. `config.py` Default `session_cookie_secure` auf `True` ändern (Production-Default)
12. `config.py` Startup-Validierung: `ENVIRONMENT=production` + `session_cookie_secure=False` → harter Abbruch

**Aufwand:** 2-3 Stunden

---

### P1-11: Cross-Tenant referenzielle Integrität

**Problem:** `contactpersons` hat `tenant_id` aber `contact_id` FK referenziert nur `contacts.id` ohne Tenant-Bedingung. Die DB verhindert nicht, dass ein Contactperson-Datensatz aus Mandant A auf einen Kontakt aus Mandant B zeigt.

**Datei:** `alembic/versions/0021_unified_contacts.py` (contactpersons Tabelle)

**Maßnahme:**
1. Composite-FK: `(tenant_id, contact_id)` referenziert `(tenant_id, id)` auf `contacts`
2. Eindeutiges `(tenant_id, id)` auf `contacts`
3. Dasselbe für alle mandantenbezogenen FK-Beziehungen

**Aufwand:** 2-4 Stunden

---

## P2 — Architektonische Konsolidierung

### P2-1: Unified Contact Model normalisieren

**Problem:** Eine Tabelle enthält Unternehmen, Personen, 3 Adressarten, Bankdaten, Steuernummern, Rabatte, Projektinformationen, Warnungen, Tags, Custom Fields, Suchindex. Dubletten zu vorhandenen Modellen für Adressen, Bankkonten, Tags, Custom Fields.

**Weitere Probleme:**
- Rabatte als `Float` statt `Numeric`/`Decimal`
- Keine DB-Checks für Werte 0-100
- Keine eindeutigen Kontakt-/Buchhaltungscodes pro Mandant
- Keine klare Validierung welche Felder bei Person/Firma erlaubt sind
- `surfix` — dauerhaft übernommener Tippfehler
- `JSON` statt `JSONB`
- Suche fest auf Deutsch eingestellt
- Keine normalisierten Suchschlüssel für E-Mail und Telefonnummer
- CSV-Import ohne Dubletten-/Encoding-/Dezimal-/Rollback-Strategie

**Maßnahme:**
1. Adressen in separate Tabelle auslagern (bereits vorhanden — nutzen)
2. Bankdaten in separate Tabelle (bereits vorhanden — nutzen)
3. Tags als Relation (bereits vorhanden — nutzen)
4. Custom Fields als Relation (bereits vorhanden — nutzen)
5. Rabatte: `Numeric(5,2)` statt `Float`
6. DB-Check: `discount_* BETWEEN 0 AND 100`
7. Eindeutige `(tenant_id, code)` und `(tenant_id, accounting_code)`
8. `surfix` → `suffix` (Migration mit Rename)
9. `JSON` → `JSONB`
10. Suchkonfiguration pro Mandant konfigurierbar
11. Normalisierte Suchschlüssel (lowercase, trimmed) für E-Mail und Telefon
12. CSV-Import: Dubletten-Erkennung, Encoding-Detection, Decimal-Parsing, Transaction-Rollback

**Aufwand:** 2-3 Tage

---

### P2-2: Plugin-Cross-Imports reduzieren

**Problem:** 204 direkte `from app.plugins.builtins` Imports zwischen Plugins. Automatisierung importiert Modelle/Services von Kommunikation, Mail, Kalender. Verteilter Monolith ohne Modulgrenzen.

**Maßnahme:**
1. Öffentliche Schnittstellen (Contracts) für jedes Modul definieren
2. Direkte Imports fremder Plugin-Modelle verbieten
3. Kommunikation nur über Events oder öffentliche Service-API
4. CI-Check: keine direkten Cross-Plugin-Imports

**Aufwand:** 1-2 Wochen

---

### P2-3: Commands und Statusmaschinen

**Problem:** Geschäftsoperationen als `Route → Service → mehrere flush/commit` statt als zentrale Commands. Statusstrings frei beschreibbar statt Statusmaschinen.

**Maßnahme:**
1. `Route → Command → Authorization → Domain Operation → Transaction → Audit → Outbox Events → Commit`
2. Explizite Statusmaschinen für Angebote, Aufträge, Rechnungen
3. Übergänge validiert und auditiert

**Aufwand:** 1-2 Wochen

---

### P2-4: SPA Path-Traversal-Schutz vervollständigen

**Problem:** `app/main.py` SPA-Catch-All blockiert `..` nur in bestimmten Positionen. `..` in anderen Positionen wird nicht erfasst.

**Datei:** `app/main.py` (spa_spa Funktion)

**Maßnahme:**
1. `os.path.abspath` gegen `frontend_dist` prüfen nach Join
2. Kein `..` in irgendeiner Position erlauben

**Aufwand:** 30 Minuten

---

## Zusammenfassung

| Priorität | Anzahl | Geschätzter Aufwand |
|---|---|---|
| P0 (sofort) | 7 | ~5-7 Tage |
| P1 (vor Kundendaten) | 11 | ~7-10 Tage |
| P2 (architektonisch) | 4 | ~2-4 Wochen |
| **Total** | **22** | **~4-6 Wochen** |

## Reihenfolge

### Woche 1: P0 absichern
1. P0-7: App von öffentlicher Domain nehmen (30 Min)
2. P0-1: Auth-Bypass entfernen (2-4h)
3. P0-3: Plugin-Upload deaktivieren (30 Min Sofort, langfristig später)
4. P0-6: Persistent Volume in Coolify (1-2h)
5. P0-2: Migrationen ersetzen (4-8h)
6. P0-4: RLS reparieren (1-2 Tage)
7. P0-5: Plugin-Doppelregistrierung beheben (1 Tag)

### Woche 2-3: P1 Fundament
8. P1-9: Metrics absichern (30 Min)
9. P1-8: Password Reset (2-4h)
10. P1-10: Coolify-Doku & Config korrigieren (2-3h)
11. P1-2: Redis zentralisieren (2-4h)
12. P1-5: XSS schließen (4-6h)
13. P1-11: Cross-Tenant FK (2-4h)
14. P1-1: User/Tenant-Modell (1 Tag)
15. P1-7: Permission-System (1-2 Tage)
16. P1-6: DMS lastfest (1-2 Tage)
17. P1-3: Worker auslagern (1-2 Tage)
18. P1-4: Transactional Outbox (2-3 Tage)

### Woche 4-6: P2 Architektur
19. P2-4: SPA Path-Traversal (30 Min)
20. P2-1: Contact Model normalisieren (2-3 Tage)
21. P2-2: Cross-Imports reduzieren (1-2 Wochen)
22. P2-3: Commands & Statusmaschinen (1-2 Wochen)

---

## Validierung nach jedem Fix

- [ ] Python-Syntax-Check: `python -m py_compile app/**/*.py`
- [ ] pytest: `pytest tests/ -x`
- [ ] Frontend-Typecheck: `cd frontend && npx tsc --noEmit`
- [ ] Frontend-Build: `cd frontend && npx vite build`
- [ ] Manueller Smoke-Test: Login, Kontakt erstellen, DMS-Upload
- [ ] Cross-Tenant-Test: Datensatz aus Mandant A kann nicht aus Mandant B gelesen werden
- [ ] Deployment: Coolify Deploy + Healthcheck prüfen