docs: reduce enterprise readiness plan from 45 to 10 days — only what is really missing, no new tables or plugins, based on code verification

ENTERPRISE_READINESS_PLAN.md

@@ -1,524 +1,210 @@
-# LeoCRM — Enterprise-Readiness Plan
+# LeoCRM — Enterprise-Readiness Plan (Reduziert)
 
 **Ziel:** KI und Business-Plattform für kleine bis mittlere Firmen (max. 500 Mitarbeiter)
 **Erstellt:** 2026-08-20
+**Prinzip:** Nur was wirklich fehlt. Kein Over-Engineering. Basis ist schon im Code vorhanden.
 
 ---
 
-## 1. RLS (Row Level Security)
+## Was schon funktioniert (keine Action nötig)
 
-### 20 Tabellen ohne RLS in Produktion — Klassifizierung
-
-**Absichtlich kein RLS (10 Tabellen — Auth/System-Tabellen):**
-Diese Tabellen brauchen kein RLS weil sie vor der Tenant-Auflösung gebraucht werden oder global sind:
-| Tabelle | Grund |
-|---------|-------|
-| `alembic_version` | Migration-Tracking, global |
-| `notification_types` | Globale Type-Definitionen |
-| `password_reset_tokens` | Auth vor Tenant-Context |
-| `plugin_allowlist` | Globale Plugin-Konfiguration |
-| `plugin_migrations` | Globale Plugin-Migration-Tracking |
-| `plugins` | Globale Plugin-Registry |
-| `sessions` | Auth vor Tenant-Context |
-| `tenants` | Die Tenant-Tabelle selbst |
-| `user_tenants` | Mapping Users ↔ Tenants |
-| `users` | Auth vor Tenant-Context |
-
-**Brauchen RLS (10 Tabellen):**
-| Tabelle | Warum RLS nötig | Migration |
-|---------|-----------------|----------|
-| `ai_decision_records` | Tenant-spezifische AI-Entscheidungen | 0129 |
-| `approval_requests` | Tenant-spezifische Approvals | 0129 |
-| `automation_agent_run_steps` | Tenant-spezifische Agent-Run-Steps | 0129 |
-| `outbox_deliveries` | Tenant-spezifische Event-Zustellungen | 0129 |
-| `roles` | Tenant-spezifische Rollen | 0129 |
-| `sequences` | Tenant-spezifische Sequenzen | 0129 |
-| `wiki_articles` | Tenant-spezifische Wiki-Artikel | 0129 |
-| `wiki_article_versions` | Tenant-spezifische Wiki-Versionen | 0129 |
-| `wiki_categories` | Tenant-spezifische Wiki-Kategorien | 0129 |
-| `marketplace_listings` | Prüfen: Global oder per-Tenant? | 0129 |
-
-### Ablaufplan RLS:
-1. Migration 0129 erstellen: `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` + `CREATE POLICY tenant_isolation ON ...`
-2. In Test-DB ausführen und verifizieren
-3. In Produktion deployen
-4. RLS-Tests schreiben: Cross-Tenant-Zugriff muss blockiert werden
-5. Verifizieren: `SELECT count(*) FILTER (WHERE rowsecurity=true) FROM pg_tables WHERE schemaname='public'` → muss 123 sein (133 - 10 system)
+| Bereich | Status | Details |
+|---------|--------|--------|
+| Rate Limiting | ✅ Basis da | `GeneralRateLimitMiddleware` aktiv, `RateLimitPolicy` Enum, LLM Cost-Protection |
+| Audit Log | ✅ Komplett | `AuditLog` Model, `log_audit()`, Routes, Frontend Page — läuft |
+| Health Checks | ✅ Da | `/health/live`, `/health/ready`, `/health` |
+| Error Tracking | ✅ Da | `record_error()`, structlog, trace_id |
+| Graceful Shutdown | ✅ Da | Connection Draining, 30s Timeout |
+| Metrics | ✅ Da | Prometheus Endpoint `/api/v1/metrics` |
+| Soft Delete | ✅ Da | `deleted_at` auf allen Entitäten, Hard-Delete mit `?gdpr=true` |
+| Outbox Retention | ✅ Da | ARQ-Job, 30 Tage, hourly Cleanup |
+| Backup Script | ✅ Da | `scripts/backup.py` (pg_dump + files) |
+| Restore Script | ✅ Da | `scripts/restore.py`, `scripts/restore_test.sh` |
+| ARQ Scheduler | ✅ Da | Cron-Jobs mit Redis Lock, 38 registrierte Jobs |
 
 ---
 
-## 2. Security Audit & Penetration Test
+## Was wirklich fehlt (reduzierter Plan)
 
-### Security Audit (Code-Level)
-1. **SQL Injection** — Alle Routes auf Raw-SQL prüfen (`grep -rn 'text(\|execute(\|raw' app/routes/`)
-2. **XSS** — Frontend auf `dangerouslySetInnerHTML` prüfen
-3. **CSRF** — CSRF Middleware prüfen (vorhanden in `app/core/middleware.py`)
-4. **Auth Bypass** — Routes ohne `require_permission` oder `get_current_user` identifizieren
-5. **Secret Exposure** — `.env`, API-Keys, Tokens im Code prüfen
-6. **Dependency Audit** — `pip-audit` (Python) + `npm audit` (Frontend)
-7. **Rate Limiting** — Prüfen ob Rate-Limiting auf kritischen Routes aktiv ist
+### 1. RLS für 10 Tabellen — 0.5 Tage
 
-### Penetration Test (Extern)
-1. **OWASP Top 10** Checkliste abarbeiten
-2. **Burp Suite / OWASP ZAP** Scan gegen https://crm.media-on.de
-3. **Auth Tests** — Session-Hijacking, Cookie-Flags, Login-Brute-Force
-4. **API Tests** — Unautorisierte Zugriffe, IDOR (Insecure Direct Object Reference)
-5. **Multi-Tenant Tests** — Cross-Tenant Datenzugriff versuchen
+10 Tabellen brauchen RLS (Tenant-Isolation):
+- `ai_decision_records`, `approval_requests`, `automation_agent_run_steps`, `outbox_deliveries`, `roles`, `sequences`, `wiki_articles`, `wiki_article_versions`, `wiki_categories`, `marketplace_listings` (prüfen)
 
-### Ablaufplan Security:
-1. Code-Level Security Audit (automatisiert, 1 Tag)
-2. Dependency Audit (pip-audit + npm audit, 0.5 Tage)
-3. Externer Pen-Test (manuell, 2 Tage)
-4. Findings dokumentieren und beheben
-5. Re-Test nach Fixes
+**Aktion:**
+- Migration 0129: `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` + `CREATE POLICY tenant_isolation`
+- Test-DB + Produktion
+- RLS-Test: Cross-Tenant-Zugriff blockiert
 
 ---
 
-## 3. Testing — 100% Abdeckung planen
+### 2. Test-DB auf Alembic umstellen — 1 Tag
 
-### Test-Strategie
+**Problem:** Test-DB wird über `Base.metadata.create_all()` erstellt → keine RLS-Policies, keine echten Migrationen.
 
-**Schicht 1: Unit-Tests (vorhanden, erweitern)**
-- Pure Funktionen, Utilities, Helper
-- Keine DB, keine externen Services
-- Ziel: 200+ Tests
-
-**Schicht 2: Integration-Tests (ausbauen)**
-- Echte DB (leocrm_test mit Alembic-Migrationen, nicht create_all)
-- Echte Redis-Verbindung
-- API-Tests über httpx AsyncClient
-- LLM gemockt (llm_complete/llm_embed)
-- Ziel: 300+ Tests
-
-**Schicht 3: Cross-Module Tests (neu)**
-- Plugin A → Contract → Plugin B
-- Agent → Tool → DB → Audit
-- Workflow → Step → External Service (gemockt)
-- Event Bus → Outbox → Consumer
-- Ziel: 50+ Tests
-
-**Schicht 4: E2E Tests (Playwright, erweitern)**
-- Login → Contact erstellen → Search → Edit → Delete
-- Mail: Account → Folder → Message → Attachment
-- Agent: Create → Run → Result → Approval
-- Workflow: Create → Run → Step → Complete
-- Ziel: 30+ Tests
-
-**Schicht 5: Performance Tests (neu)**
-- locust/k6: Login, Contact-List, Search unter Last
-- 10, 50, 100 gleichzeitige User
-- Response-Time < 500ms, Error-Rate < 1%
-- Ziel: 10+ Test-Szenarien
-
-### Test-DB Fix (wichtig!)
-1. conftest.py umstellen: Alembic-Migrationen statt `Base.metadata.create_all()`
-2. RLS-Policies in Test-DB aktivieren
-3. Test-Isolation: Jeder Test bekommt clean Schema (TRUNCATE zwischen Tests)
-4. Test-Daten-Fixtures: Realistische Test-Daten (Contacts, Companies, Mail, etc.)
-
-### Ablaufplan Testing:
-1. Test-DB auf Alembic umstellen (1 Tag)
-2. Bestehende Mock-Tests zu Integration-Tests migrieren (3 Tage)
-3. Neue Cross-Module Tests schreiben (2 Tage)
-4. E2E Tests erweitern (2 Tage)
-5. Performance Tests einrichten (1 Tag)
-6. CI-Pipeline: Alle Tests müssen grün sein vor Deploy (0.5 Tage)
+**Aktion:**
+- conftest.py: Alembic-Migrationen statt `create_all()`
+- RLS-Policies in Test-DB aktiv
+- Test-Isolation: TRUNCATE zwischen Tests
+- Echte Integration-Tests statt Mock-Tests
 
 ---
 
-## 4. Monitoring — System Dashboard für Admins
+### 3. Multi-Tenant Prüfung — 1 Tag
 
-### Backend
-1. **Neue Route:** `app/routes/system_dashboard.py`
-   - `GET /api/v1/system-dashboard` — Admin-only (`require_permission("system:read")`)
-   - Sammelt: Health, DB-Stats, Redis-Stats, Worker-Queue, Active Users, Error-Rate, Response-Times
-   - Bei Problemen: `post_system_message()` an internes Nachrichten-System
-
-2. **Monitoring Daten sammeln:**
-   - DB: Connection-Pool-Stats, Query-Count, Slow-Queries
-   - Redis: Memory, Connections, PubSub Channels
-   - Worker: Queue-Length, Failed-Jobs, Running-Jobs
-   - App: Active Sessions, Request-Count, Error-Rate
-   - Plugins: Active-Status, Health pro Plugin
-   - LLM: Cost pro Tag/Agent/Workflow
-
-3. **Alerting:**
-   - Wenn Health-Check failed → System-Message an Communication-System
-   - Wenn Error-Rate > 5% → System-Message
-   - Wenn Worker-Queue > 100 → System-Message
-   - Wenn DB-Disk > 80% → System-Message
-   - Wenn Redis-Memory > 80% → System-Message
-
-### Frontend
-1. **Neue Page:** `frontend/src/pages/SystemDashboard.tsx`
-   - Nur für Admins sichtbar (`PermissionRoute permission="system:read"`)
-   - Link im linken Menü (Sidebar) — nur für Admins
-   - Real-Time Updates (WebSocket oder 30s Polling)
-   - Cards: System Health, DB, Redis, Worker, Active Users, Errors, LLM Costs
-   - Charts: Response-Time-Trend, Error-Rate-Trend, Queue-Length
-   - Alert-Feed: System-Messages aus Communication-System
-
-2. **Sidebar Eintrag:**
-   - `{ to: '/system-dashboard', labelKey: 'nav.systemDashboard', icon: <Activity />, order: 95 }`
-   - Nur sichtbar wenn `is_system_admin === true`
-
-### Ablaufplan Monitoring:
-1. Backend: `system_dashboard.py` Route mit echten DB/Redis/Worker-Stats (1 Tag)
-2. Backend: Alerting → System-Message bei Problemen (0.5 Tage)
-3. Frontend: `SystemDashboard.tsx` mit Cards und Charts (2 Tage)
-4. Frontend: Sidebar-Eintrag + Permission-Check (0.5 Tage)
-5. Tests: Integration-Test für Dashboard-Route (0.5 Tage)
+**Aktion:**
+- ORM Auto-Filter verifizieren (tenant_id wird automatisch gefiltert?)
+- Routes ohne Tenant-Check identifizieren
+- Cross-Tenant Integration-Tests
+- 20 Tabellen ohne RLS klassifizieren (10 absichtlich, 10 brauchen RLS → Punkt 1)
 
 ---
 
-## 5. Backup — Automatisiert über ARQ Scheduler
+### 4. Security Audit — 1 Tag
 
-### Vorhandene Infrastruktur
-- `scripts/backup.py` — Backup-Script (pg_dump + files)
-- `scripts/restore.py` — Restore-Script
-- ARQ Worker mit cron-Scheduler (vorhanden)
-- `scheduler_tick` Job registriert
+**Aktion (Code-Level, automatisiert):**
+- SQL Injection: `grep -rn 'text(\|execute(\|raw' app/routes/`
+- XSS: Frontend `dangerouslySetInnerHTML` prüfen
+- Auth Bypass: Routes ohne `require_permission` oder `get_current_user`
+- Secret Exposure: API-Keys/Tokens im Code
+- Dependency Audit: `pip-audit` + `npm audit`
+- Login-Brute-Force-Schutz: Rate-Limit auf Login-Route (5 Versuche)
 
-### Plan
-1. **Backup ARQ Job registrieren:**
-   - `register_job("auto_backup", auto_backup_job)`
-   - Cron-Schedule: Täglich um 03:00 Uhr (einstellbar)
-   - Ruft `scripts/backup.py` auf
-   - Speichert Backup in `/backups/` (oder S3/Nextcloud)
-
-2. **Settings-Erweiterung:**
-   - `backup_enabled: bool = True`
-   - `backup_schedule: str = "0 3 * * *"` (cron)
-   - `backup_destination: str = "local"` (local/s3/nextcloud)
-   - `backup_retention_days: int = 7`
-   - In Settings-Page im Frontend einstellbar
-
-3. **Backup-Verifizierung:**
-   - Nach jedem Backup: Manifest prüfen (Datei-Anzahl, Größe)
-   - Wöchentlich: Test-Restore in Test-DB + Row-Count-Validierung
-   - Bei Fehler: System-Message an Communication-System
-
-4. **Restore-Test:**
-   - `scripts/restore_test.sh` existiert bereits
-   - Als ARQ-Cron-Job: Wöchentlich Restore in Test-DB, Schema validieren
-
-### Ablaufplan Backup:
-1. `auto_backup_job` in `app/core/jobs.py` registrieren (0.5 Tage)
-2. Settings-Schema erweitern + Frontend-UI (1 Tag)
-3. Backup-Verifizierung + Alerting (0.5 Tage)
-4. Restore-Test als Cron-Job (0.5 Tage)
-5. Tests: Backup erstellen → Restore → Validieren (1 Tag)
+**Externer Pen-Test:** Bei Bedarf später, nicht jetzt.
 
 ---
 
-## 6. Multi-Tenant — RLS Lücken prüfen
+### 5. Monitoring System Dashboard — 2 Tage
 
-### Aktuell
-- 113/133 Tabellen haben RLS in Produktion
-- 10 Tabellen absichtlich ohne RLS (Auth/System)
-- 10 Tabellen brauchen RLS (siehe Punkt 1)
+**Backend:**
+- `app/routes/system_dashboard.py` — Admin-only Route
+- Sammelt: Health, DB-Stats, Redis-Stats, Worker-Queue, Active Users, Error-Rate, LLM Costs
+- Bei Problemen: `post_system_message()` an Communication-System
 
-### Weitere Prüfung
-1. **ORM Auto-Filter** — Prüfen ob SQLAlchemy automatisch `tenant_id` filtert
-2. **Routes ohne Tenant-Check** — Gibt es Routes die `tenant_id` nicht prüfen?
-3. **Cross-Tenant Queries** — Gibt es Queries die `tenant_id` nicht filtern?
-4. **Plugin-Tables** — Haben alle Plugin-Tables `tenant_id`?
-5. **Admin-Bypass** — Können Admins andere Tenants sehen? (Sollten sie nicht)
-
-### Ablaufplan Multi-Tenant:
-1. RLS für 10 fehlende Tabellen hinzufügen (Punkt 1) (0.5 Tage)
-2. ORM Auto-Filter verifizieren (0.5 Tage)
-3. Routes ohne Tenant-Check identifizieren und fixen (1 Tag)
-4. Cross-Tenant Integration-Tests schreiben (1 Tag)
+**Frontend:**
+- `frontend/src/pages/SystemDashboard.tsx` — Admin-only Page
+- Sidebar-Eintrag (nur für Admins sichtbar)
+- Cards: System Health, DB, Redis, Worker, Errors, LLM Costs
+- Alert-Feed: System-Messages aus Communication-System
 
 ---
 
-## 7. Compliance — Geplant in Phase K
+### 6. Backup Automation — 1 Tag
 
-Phase K (EU Compliance) ist in der Roadmap geplant mit 6 Tasks:
-- AI Use-Case Registry
-- Processing Activities Register
-- DSR Automation (Access/Erasure/Correction)
-- DPIA (Data Protection Impact Assessment)
-- AI Act Compliance
-- Compliance Reports
-
-Das ist geplant und muss implementiert werden wenn Phase I+J abgeschlossen sind.
+**Aktion:**
+- `auto_backup_job` ARQ-Job registrieren (ruft `scripts/backup.py` auf)
+- Cron-Schedule: Täglich 03:00 Uhr (einstellbar in Settings)
+- Settings: `backup_enabled`, `backup_schedule`, `backup_retention_days`
+- Backup-Verifizierung: Manifest prüfen nach Backup
+- Bei Fehler: System-Message an Communication-System
 
 ---
 
-## 8. Performance Tests
+### 7. Audit Log Retention + Export — 0.5 Tage
 
-### Plan
-1. **locust/k6 Setup** — Load-Testing-Tool installieren
-2. **Test-Szenarien:**
-   - Login (100 gleichzeitige User)
-   - Contact-List (50 User, paginated)
-   - Search (50 User, verschiedene Queries)
-   - Mail-List (30 User, IMAP-Sync)
-   - Agent-Run (10 User, gleichzeitige Agent-Runs)
-3. **Metriken:**
-   - Response-Time (P50, P95, P99)
-   - Error-Rate
-   - Throughput (Requests/sec)
-   - DB-Query-Count pro Request
-   - Redis-Hit-Rate
-4. **Baseline messen** — Aktuelle Performance aufzeichnen
-5. **Optimierung** — Bottlenecks identifizieren und beheben
-
-### Ablaufplan Performance:
-1. locust/k6 installieren + Test-Szenarien schreiben (1 Tag)
-2. Baseline messen (0.5 Tage)
-3. Bottlenecks identifizieren (0.5 Tage)
-4. Optimierung (N+1 Queries, Caching, Indexes) (2 Tage)
-5. Re-Test nach Optimierung (0.5 Tage)
+**Aktion:**
+- Config: `audit_retention_days: int = 365` (einstellbar)
+- ARQ-Cron-Job: Audit-Logs älter als Retention archivieren
+- Route: `GET /api/v1/audit-log/export` (CSV/JSON Export)
+- Tamper-Proof: DELETE auf AuditLog nur mit `?gdpr=true` + Admin
 
 ---
 
-## 9. Documentation — Anpassen an aktuellen und geplanten Stand
+### 8. Trash Cleanup — 0.5 Tage
 
-### Was aktualisiert werden muss
-1. **README.md** — Aktualisiert ✅ (KI und Business-Plattform)
-2. **docs/api-documentation.md** — Alle 468 Routes dokumentieren (aktualisieren)
-3. **docs/plugin-development-guide.md** — 23 Plugins dokumentieren (aktualisieren)
-4. **docs/infrastructure.md** — Docker, PostgreSQL, Redis, ARQ (aktualisieren)
-5. **docs/monitoring.md** — System Dashboard, Alerting (neu schreiben)
-6. **docs/security_kernel.md** — RLS, ABAC, Audit, Pen-Test (aktualisieren)
-7. **docs/admin-guide.md** — Backup, Restore, Monitoring, Settings (aktualisieren)
-8. **docs/deploy-guide.md** — Deploy-Process, Coolify (aktualisieren)
-9. **docs/test-strategy.md** — Test-Schichten, Test-DB, CI (aktualisieren)
-10. **docs/ui-design-guidelines.md** — System Dashboard, neue Komponenten (aktualisieren)
-11. **AGENTS.md** — Build/Test-Commands, Konventionen (aktualisieren)
-12. **PROGRESS.md** — Aktueller Stand (aktualisiert ✅)
-13. **PLATFORM_ROADMAP.md** — Phasen-Status (aktualisiert ✅)
-
-### Ablaufplan Documentation:
-1. Alle Doku-Dateien durchgehen und veraltete Inhalte aktualisieren (2 Tage)
-2. Neue Doku für System Dashboard, Backup-Automation, Performance (1 Tag)
-3. API-Doku für neue Routes ergänzen (1 Tag)
+**Aktion:**
+- Config: `trash_retention_days: int = 90` (einstellbar)
+- ARQ-Cron-Job: `cleanup_expired_trash` — `deleted_at < now() - retention_days` endgültig löschen
+- Bei Löschung: Audit-Log Eintrag
 
 ---
 
-## 10. HA/Scaling — Architektur-Prüfung
+### 9. Incident Response Runbook — 0.5 Tage
 
-### Aktuelle Architektur
-- Single-Instance: 1x crm_app, 1x crm_worker, 1x postgres, 1x redis
-- Docker-Compose auf einem Hetzner VPS
-
-### Kann die Architektur skalieren?
-**Ja, bedingt.** Die Architektur unterstützt Horizontal-Scaling:
-
-1. **crm_app** — Kann horizontal skalieren (stateless, Session in Redis)
-   - Mehrere Instanzen hinter Load Balancer (Coolify unterstützt das)
-   - WebSocket: Redis PubSub für Multi-Instance (bereits implementiert)
-   - Cron-Locks: Bereits implementiert (`_acquire_cron_lock`)
-
-2. **crm_worker** — Kann horizontal skalieren
-   - ARQ Worker sind stateless
-   - Redis als Queue (bereits implementiert)
-   - Cron-Locks verhindern doppelte Ausführung (bereits implementiert)
-
-3. **postgres** — Vertikales Scaling (größerer Server)
-   - Für HA: Managed PostgreSQL (z.B. Hetzner Cloud DB, RDS)
-   - Read-Replicas für Search-Queries möglich
-
-4. **redis** — Vertikales Scaling
-   - Für HA: Redis Sentinel oder Managed Redis
-
-### Was für HA noch fehlt
-- Load Balancer (Coolify/Traefik kann das)
-- Health-Checks für Auto-Restart (vorhanden)
-- Graceful Shutdown (vorhanden)
-- Session-Sharing über Redis (vorhanden)
-
-### Fazit: Die Architektur unterstützt HA/Scaling. Bei Bedarf können einfach mehr crm_app und crm_worker Instanzen hinzugefügt werden. PostgreSQL und Redis brauchen dann Managed Services.
-
-### Ablaufplan HA (bei Bedarf):
-1. 2-3 crm_app Instanzen hinter Traefik Load Balancer (Coolify)
-2. 2 crm_worker Instanzen
-3. Managed PostgreSQL (Hetzner Cloud DB oder extern)
-4. Managed Redis (oder Redis Sentinel)
-5. Keine Code-Änderungen nötig — nur Docker-Compose Anpassung
+**Aktion:**
+- `docs/incident-response.md` schreiben:
+  - Server-Ausfall: Coolify Restart → Health-Check → System-Message
+  - DB-Crash: PostgreSQL Restart → Migration-Check → Backup-Restore
+  - Redis-Crash: Redis Restart → Session-Check
+  - Security-Breach: Logs prüfen → Password-Reset → Audit-Log Export
+- Alerting kommt über System Dashboard (Punkt 5)
 
 ---
 
-## 11. API Versioning
+### 10. Performance Tests — 1 Tag
 
-### Aktuell
-- Alle Routes unter `/api/v1/`
-- Kein automatisches Versioning
-
-### Plan
-- Bei Breaking Changes: Neue Routes unter `/api/v2/`
-- Alte Routes bleiben verfügbar (Deprecation)
-- Versionierung über URL-Präfix (nicht Header)
-- Das ist ausreichend für KMU bis 500 Mitarbeiter
-
-### Fazit: v1 ist ausreichend. Bei v2 einfach neuen Prefix hinzufügen. Keine zusätzliche Infrastruktur nötig.
+**Aktion:**
+- locust/k6: Login, Contact-List, Search unter Last (10, 50, 100 User)
+- Baseline messen: Response-Time, Error-Rate, Throughput
+- Bottlenecks identifizieren (N+1 Queries, fehlende Indexes)
+- Bei Bedarf optimieren
 
 ---
 
-## 12. Rate Limiting — Erklärung
+### 11. Documentation — 1 Tag
 
-**Was ist Rate Limiting?**
-Rate Limiting begrenzt wie viele API-Anfragen ein User in einer bestimmten Zeit machen kann.
-
-**Beispiel:** Ein User kann maximal 100 API-Anfragen pro Minute machen. Wenn er mehr macht, bekommt er einen 429 (Too Many Requests) Fehler.
-
-**Warum wichtig?**
-- Schutz vor Missbrauch (Brute-Force, DDoS)
-- Faire Ressourcen-Verteilung (ein User kann nicht alle Ressourcen verbrauchen)
-- Schutz vor Endlos-Schleifen (z.B. Agent der zu viele LLM-Calls macht)
-
-**Aktuell:**
-- Globales Rate-Limiting vorhanden (`GeneralRateLimitMiddleware` in `app/core/rate_limit.py`)
-- LLM Cost-Protection vorhanden (Budget-Limits pro Tenant)
-
-**Was fehlt:**
-- Per-User Rate-Limiting (nicht nur global)
-- Per-Tenant Rate-Limiting
-- Spezifische Limits für kritische Endpoints (Login, Password-Reset, Agent-Run)
-
-### Ablaufplan Rate Limiting:
-1. Per-User und Per-Tenant Limits in `rate_limit.py` implementieren (1 Tag)
-2. Spezifische Limits für Login, Password-Reset, Agent-Run (0.5 Tage)
-3. Tests: Rate-Limit wird durchgesetzt (0.5 Tage)
+**Aktion:**
+- README.md ✅ (aktualisiert)
+- docs/api-documentation.md — Neue Routes ergänzen
+- docs/monitoring.md — System Dashboard, Alerting
+- docs/admin-guide.md — Backup, Restore, Monitoring
+- docs/security_kernel.md — RLS, Audit, Pen-Test
+- docs/test-strategy.md — Test-DB, Integration-Tests
+- docs/incident-response.md — Runbook (Punkt 9)
 
 ---
 
-## 13. Audit Log — Erklärung
+## Was weggelassen wurde (nicht nötig für KMU)
 
-**Was ist Audit Log?**
-Audit Log protokolliert jede Änderung am System: Wer hat was wann geändert.
-
-**Beispiel:** "User admin@media-on.de hat Kontakt 'Max Mustermann' um 14:30 Uhr aktualisiert — Feld 'email' geändert von 'alt@example.com' zu 'neu@example.com'"
-
-**Warum wichtig?**
-- Nachvollziehbarkeit bei Fehlern
-- Compliance (DSGVO fordert Protokollierung)
-- Security (wer hat auf welche Daten zugegriffen?)
-
-**Aktuell:**
-- `app/models/audit.py` — AuditLog Model vorhanden
-- `app/routes/audit.py` — Audit-Log API vorhanden
-- `do_action()` feuert bei jeder Änderung
-- 81 do_action-Aufrufe im Code
-
-**Was fehlt:**
-- **Retention Policy** — Wie lange werden Audit-Logs aufbewahrt? (z.B. 90 Tage, 1 Jahr, 7 Jahre je nach Gesetz)
-- **Audit-Log-Export** — Export für Compliance-Prüfung
-- **Tamper-Proof** — Audit-Logs sollten nicht löschbar sein (außer durch Admin mit GDPR-Flag)
-
-### Ablaufplan Audit Log:
-1. Retention Policy in Settings konfigurierbar (0.5 Tage)
-2. ARQ-Cron-Job: Audit-Logs älter als Retention-Period archivieren (0.5 Tage)
-3. Audit-Log-Export als CSV/JSON (0.5 Tage)
-4. Tamper-Proof: DELETE auf AuditLog nur mit `?gdpr=true` und Admin-Permission (0.5 Tage)
+| Bereich | Grund weggelassen |
+|---------|------------------|
+| Per-User Rate Limiting | Globales Rate-Limiting reicht, Login-Brute-Force-Schutz in Punkt 4 |
+| Per-Tenant Rate Limiting | Nicht nötig für KMU bis 500 Mitarbeiter |
+| Externer Pen-Test | Bei Bedarf später, Code-Level Audit reicht erstmal |
+| DSGVO-Lösch-Workflow | In Phase K geplant |
+| Post-Mortem Template | Runbook reicht |
+| HA/Scaling | Architektur unterstützt es, bei Bedarf einfach mehr Instanzen |
+| API Versioning | v1 ausreichend, v2 bei Bedarf neuer Prefix |
+| Compliance (Phase K) | Geplant, separat |
+| 300+ Integration-Tests | Test-DB Fix + schrittweise Migration der Mock-Tests |
+| 30+ E2E Tests | Vorhandene E2E Tests erweitern bei Bedarf |
+| Cross-Module Tests | Bei Bedarf, nicht als Pflicht |
 
 ---
 
-## 14. Data Retention — Erklärung
+## Zusammenfassung — Reduzierter Plan
 
-**Was ist Data Retention?**
-Data Retention definiert wie lange Daten aufbewahrt werden und wann sie gelöscht werden.
+| # | Bereich | Aufwand | Neue Tabellen? | Neue Plugins? |
+|---|---------|--------|---------------|---------------|
+| 1 | RLS für 10 Tabellen | 0.5 Tage | Nein (Migration) | Nein |
+| 2 | Test-DB auf Alembic | 1 Tag | Nein | Nein |
+| 3 | Multi-Tenant Prüfung | 1 Tag | Nein | Nein |
+| 4 | Security Audit (Code-Level) | 1 Tag | Nein | Nein |
+| 5 | Monitoring System Dashboard | 2 Tage | Nein | Nein |
+| 6 | Backup Automation | 1 Tag | Nein | Nein |
+| 7 | Audit Log Retention + Export | 0.5 Tage | Nein | Nein |
+| 8 | Trash Cleanup | 0.5 Tage | Nein | Nein |
+| 9 | Incident Response Runbook | 0.5 Tage | Nein | Nein |
+| 10 | Performance Tests | 1 Tag | Nein | Nein |
+| 11 | Documentation | 1 Tag | Nein | Nein |
 
-**Beispiel:** "E-Mails werden 7 Jahre aufbewahrt (gesetzliche Pflicht), danach automatisch gelöscht. Gelöschte Kontakte werden 90 Tage im Trash behalten, danach endgültig gelöscht."
+**Gesamtaufwand:** ~10 Tage (statt 45 Tage)
 
-**Warum wichtig?**
-- Gesetzliche Aufbewahrungspflichten (Handelsrecht, Steuerrecht, DSGVO)
-- Speicherplatz-Management
-- DSGVO: „Recht auf Vergessenwerden" — Daten müssen löschbar sein
+**Keine neuen Tabellen. Keine neuen Plugins.** Alles aufbauend auf vorhandenem Code.
 
-**Aktuell:**
-- Soft-Delete mit `deleted_at` vorhanden (alle Entitäten)
-- Hard-Delete nur mit `?gdpr=true` (vorhanden)
-- Entity History mit Restore vorhanden (Phase D)
-- Keine automatische Retention/Löschung nach Zeit
-
-**Was fehlt:**
-- Konfigurierbare Retention-Policies pro Datentyp (z.B. Mail=7 Jahre, Contacts=90 Tage Trash)
-- ARQ-Cron-Job der abgelaufene Daten archiviert/löscht
-- DSGVO-Lösch-Workflow (Betroffenenrechts-Anfragen)
-
-### Ablaufplan Data Retention:
-1. Retention-Settings in `config.py` + Settings-Page (0.5 Tage)
-2. ARQ-Cron-Job: `cleanup_expired_data` (1 Tag)
-3. DSGVO-Lösch-Workflow (in Phase K geplant)
-4. Tests: Daten werden nach Retention-Period gelöscht (0.5 Tage)
+**Reihenfolge:**
+1. RLS (0.5 Tage)
+2. Test-DB Fix (1 Tag)
+3. Multi-Tenant (1 Tag)
+4. Security Audit (1 Tag)
+5. Monitoring Dashboard (2 Tage)
+6. Backup Automation (1 Tag)
+7. Audit Retention + Export (0.5 Tage)
+8. Trash Cleanup (0.5 Tage)
+9. Incident Response Runbook (0.5 Tage)
+10. Performance Tests (1 Tag)
+11. Documentation (1 Tag)
 
 ---
 
-## 15. Incident Response — Erklärung
-
-**Was ist Incident Response?**
-Incident Response ist der Plan was passiert wenn etwas schiefgeht (Server-Ausfall, Datenverlust, Security-Breach).
-
-**Beispiel:** „Server ist down → 1. Admin bekommt Alert über System-Dashboard → 2. Backup wird restored → 3. User werden informiert → 4. Post-Mortem wird geschrieben"
-
-**Warum wichtig?**
-- Schnelle Reaktion bei Problemen
-- Minimierung von Ausfallzeiten
-- Dokumentation für Verbesserung
-
-**Aktuell:**
-- Health-Check vorhanden (`/api/v1/health`)
-- Graceful Shutdown vorhanden
-- Error-Logging vorhanden (structlog + trace_id)
-- Kein automatisches Alerting
-- Kein Runbook
-
-**Was fehlt:**
-- **Runbook** — Dokument mit Schritten bei verschiedenen Incident-Typen
-- **Alerting** — Automatische Benachrichtigung bei Problemen (über System Dashboard → Communication-System)
-- **Post-Mortem Template** — Vorlage für Incident-Dokumentation
-
-### Ablaufplan Incident Response:
-1. Runbook schreiben (Server-Ausfall, DB-Crash, Redis-Crash, Security-Breach) (1 Tag)
-2. Alerting im System Dashboard implementiert (siehe Punkt 4) (bereits geplant)
-3. Post-Mortem Template in `docs/incident-response.md` (0.5 Tage)
-4. Recovery-Test: Backup restore + App-Neustart (0.5 Tage)
-
----
-
-## Zusammenfassung — Alle Ablaufpläne
-
-| # | Bereich | Aufwand | Priorität | Abhängigkeit |
-|---|---------|--------|-----------|-------------|
-| 1 | RLS für 10 Tabellen | 0.5 Tage | 🔴 Hoch | Keine |
-| 2 | Security Audit + Pen-Test | 3.5 Tage | 🔴 Hoch | Nach RLS |
-| 3 | Testing 100% | 9.5 Tage | 🔴 Hoch | Nach Test-DB Fix |
-| 4 | Monitoring System Dashboard | 4.5 Tage | 🟡 Mittel | Keine |
-| 5 | Backup Automation | 3.5 Tage | 🟡 Mittel | ARQ Scheduler |
-| 6 | Multi-Tenant Prüfung | 3 Tage | 🔴 Hoch | Nach RLS |
-| 7 | Compliance (Phase K) | Geplant | 🟡 Mittel | Nach Phase I+J |
-| 8 | Performance Tests | 4.5 Tage | 🟡 Mittel | Nach Testing |
-| 9 | Documentation | 4 Tage | 🟡 Mittel | Nach allen Änderungen |
-| 10 | HA/Scaling | Bei Bedarf | 🟢 Low | Architektur unterstützt es |
-| 11 | API Versioning | v1 ausreichend | 🟢 Low | Keine |
-| 12 | Rate Limiting | 2 Tage | 🟡 Mittel | Keine |
-| 13 | Audit Log | 2 Tage | 🟡 Mittel | Keine |
-| 14 | Data Retention | 2.5 Tage | 🟡 Mittel | ARQ Scheduler |
-| 15 | Incident Response | 2.5 Tage | 🟡 Mittel | Nach Monitoring |
-
-**Gesamtaufwand:** ~45 Tage (ohne Compliance, HA, API Versioning)
-
-**Reihenfolge (empfohlen):**
-1. RLS (Punkt 1) — 0.5 Tage
-2. Test-DB Fix (Teil von Punkt 3) — 1 Tag
-3. Multi-Tenant Prüfung (Punkt 6) — 3 Tage
-4. Security Audit (Punkt 2) — 3.5 Tage
-5. Monitoring (Punkt 4) — 4.5 Tage
-6. Testing (Punkt 3) — 9.5 Tage
-7. Backup (Punkt 5) — 3.5 Tage
-8. Rate Limiting (Punkt 12) — 2 Tage
-9. Audit Log (Punkt 13) — 2 Tage
-10. Data Retention (Punkt 14) — 2.5 Tage
-11. Performance (Punkt 8) — 4.5 Tage
-12. Incident Response (Punkt 15) — 2.5 Tage
-13. Documentation (Punkt 9) — 4 Tage
-14. Compliance (Phase K) — Geplant
-15. HA/Scaling (Punkt 10) — Bei Bedarf
-
----
-
-*Ende des Enterprise-Readiness Plans*
+*Ende des reduzierten Enterprise-Readiness Plans*