# LeoCRM — Vollständiger Test-Plan

> **Erstellt:** 2026-08-17
> **Codebasis:** ~230.000 Zeilen
> **Ziel:** Jede Komponente testen, jeden Fehler finden, nichts überspringen

---

## Was getestet werden muss

| Schicht | Was | Anzahl | Zeilen |
|---|---|---|---|
| Backend API | Endpoints | 224 | 75.797 |
| Backend Services | Service-Module | 42 | (in app/) |
| Backend Models | SQLAlchemy-Models | 40 | (in app/) |
| Backend Core | Core-Module | 38 | (in app/) |
| Plugins | Built-in Plugins | 25 | (in app/) |
| Migrationen | Alembic-Versionen | 121 | 9.177 |
| Scripts | Python-Scripts | 20 | 4.601 |
| Frontend Seiten | React-Pages | 62 | (in src/) |
| Frontend Komponenten | React-Components | 154 | (in src/) |
| Frontend Stores | Zustand-Stores | 12 | (in src/) |
| Frontend Hooks | Custom Hooks | 11 | (in src/) |
| Frontend API | API-Clients | 48 | (in src/) |
| Existierende Tests | Backend-Tests | 86 | 40.214 |
| Existierende Tests | Frontend-Tests | 79 | 7.369 |
| Existierende Tests | E2E-Tests | 7 | 1.175 |
| Docs | Dokumentation | 18 | 12.484 |
| Config | Docker/Deploy | — | 1.076 |
| **Gesamt** | | **~1.000 Komponenten** | **~230.000** |

---

## Phase 1: Backend API — Alle 224 Endpoints testen

### 1.1 Endpoint-Discovery
- OpenAPI-Spec parsen (`/openapi.json`)
- Alle Endpoints mit Method, Path, Auth-Requirement extrahieren
- Erwartete Status-Codes pro Endpoint ableiten

### 1.2 Admin-Test (als is_system_admin=True)
- Login → Session-Cookie holen
- Alle 224 Endpoints aufrufen (GET/POST/PUT/DELETE)
- Für GET: Echte Daten abrufen, 200/404/403 erwartet, **nicht 500**
- Für POST/PUT/DELETE: Mit minimalen Payloads, 201/200/400/403/404 erwartet, **nicht 500**
- Alle 500er = Server-Crash → finden und fixen
- Alle 422er = Schema-Mismatch → finden und fixen

### 1.3 Non-Admin-Test (als normaler User)
- Neuen User erstellen ohne is_system_admin
- Alle 224 Endpoints aufrufen
- 403 erwartet für Admin-Only Endpoints
- 200 erwartet für User-Endpunkte
- 500er = Permission-Resolver-Crash → finden und fixen

### 1.4 Unauthenticated-Test (ohne Login)
- Alle 224 Endpoints aufrufen
- 401 erwartet für geschützte Endpoints
- 200 erwartet für öffentliche Endpoints (health, login)
- 500er = Auth-Middleware-Crash → finden und fixen

### 1.5 Plugin-Endpoint-Test
- Alle Plugin-Routes identifizieren (aus Registry)
- Pro Plugin: Alle Routes aufrufen
- Plugin-spezifische Errors finden

**Aufwand: ~6h**
**Findet: Alle Backend-Crashes, Import-Fehler, Query-Fehler, Schema-Mismatches**

---

## Phase 2: Frontend — Alle 62 Seiten testen

### 2.1 Route-Discovery
- Router-Config aus `routes/index.tsx` parsen
- Alle 62 Routes mit Path, Permission-Requirement extrahieren

### 2.2 Admin-Route-Test (als Admin eingeloggt)
- Login über Browser
- Alle 62 Routes nacheinander laden
- Pro Route prüfen:
  - `#root` nicht leer (keine weiße Seite)
  - Keine Weiterleitung zu `/kein-zugriff`
  - Keine JS-Console-Errors
  - Keine unhandled Promise rejections
  - API-Calls erfolgreich (keine 500er in Network-Tab)

### 2.3 Non-Admin-Route-Test
- Als normaler User einloggen
- Alle 62 Routes laden
- Permission-geschützte Routes → Weiterleitung zu `/kein-zugriff` erwartet
- Nicht-geschützte Routes → Seite lädt

### 2.4 Component-Test
- Alle 154 Komponenten identifizieren
- Pro Komponente: Wird sie auf mindestens einer Route gerendert?
- Komponenten die nirgends gerendert werden = tot oder fehlende Integration

### 2.5 Store-Test
- Alle 12 Stores prüfen:
  - Wird der Store initialisiert?
  - Werden die Actions aufgerufen?
  - Stimmt der State nach API-Calls?

### 2.6 Hook-Test
- Alle 11 Hooks prüfen:
  - Wird der Hook aufgerufen?
  - Macht er die erwarteten API-Calls?
  - Verarbeitet er die Response korrekt?

**Aufwand: ~5h**
**Findet: Alle weißen Seiten, Router-Context-Fehler, fehlende Provider, kaputte Hooks, tote Komponenten**

---

## Phase 3: Plugin-System — Alle 25 Plugins testen

### 3.1 Plugin-Discovery
- Alle 25 Plugins aus Registry holen
- Pro Plugin: Manifest, Routes, Hooks, Services identifizieren

### 3.2 Plugin-Manifest-Test
- Pro Plugin: Manifest laden über API
- Prüfen: menu_items, page_routes, settings_pages, detail_tabs vorhanden?
- Frontend: Werden Plugin-Menü-Items in Sidebar angezeigt?

### 3.3 Plugin-Route-Test
- Pro Plugin: Alle Plugin-Routes laden
- Prüfen: Seite rendert, keine 500er, keine weiße Seite

### 3.4 Plugin-Hook-Test
- Pro Plugin: Alle registrierten Hooks identifizieren
- Trigger auslösen (z.B. contact.after_create)
- Prüfen: Hook wird ausgeführt, kein Crash

### 3.5 Plugin-Settings-Test
- Pro Plugin: Settings-Seite laden
- Prüfen: Seite rendert, Settings können gespeichert werden

### 3.6 Plugin-Activation-Test
- Pro Plugin: Deaktivieren → Aktivieren
- Prüfen: Kein Crash, Hooks korrekt registriert/deregistriert

**Aufwand: ~4h**
**Findet: Alle Plugin-Verkabelungs-Fehler, fehlende Manifeste, kaputte Hooks**

---

## Phase 4: DB-Schema — Alle 126 Tabellen testen

### 4.1 Schema-vs-Model-Test
- Alle 40 SQLAlchemy-Models laden
- Pro Model: Tabelle existiert in DB?
- Pro Model: Alle Spalten in DB vorhanden?
- Pro Model: Spalten-Typen stimmen überein?
- Pro Model: FKs vorhanden und korrekt?

### 4.2 RLS-Test
- Pro Tabelle mit tenant_id: RLS-Policy vorhanden?
- Pro Tabelle: Cross-Tenant-Zugriff blockiert?
- Pro Tabelle: Admin-Bypass funktioniert?

### 4.3 Migration-Integrität
- Alembic current = head?
- Alle 121 Migration-Hashes gültig?
- Downgrade-Test: Letzte Migration zurücknehmen, wieder anwenden

### 4.4 Seed-Test
- seed_admin.py ausführen → User erstellt?
- seed_default_workspace() → Workspace + Module erstellt?
- Plugin-Schema-Sync → Alle Plugin-Tabellen vorhanden?

**Aufwand: ~3h**
**Findet: Alle Schema-Drifts, fehlende Tabellen, RLS-Lücken**

---

## Phase 5: Permission-System — Vollständige Matrix

### 5.1 Permission-Definitionen
- Alle definierten Permissions aus `permissions.py` holen
- Alle Plugin-Permissions aus Manifesten holen
- Prüfen: Frontend kennt alle Backend-Permissions?

### 5.2 Permission-Matrix
- Admin (is_system_admin=True): Alle 224 Endpoints → 200/201/204 erwartet
- Non-Admin mit Rolle "admin" (*:* Permission): Alle Endpoints → 200/201/204
- Non-Admin ohne Rolle: Geschützte Endpoints → 403
- Guest: Nur Guest-Endpoints → 200, Rest → 403

### 5.3 Frontend-Permission-Checks
- Alle PermissionRoute-Komponenten identifizieren
- Pro Route: Mit Admin → Seite lädt
- Pro Route: Ohne Permission → Weiterleitung zu /kein-zugriff

### 5.4 Field-Level-Permissions
- Pro Entity: Field-Permissions testen
- Admin: Alle Felder sichtbar
- Non-Admin: Nur erlaubte Felder sichtbar

**Aufwand: ~3h**
**Findet: Alle RBAC-Verkabelungs-Fehler, fehlende Permission-Checks, Field-Level-Bugs**

---

## Phase 6: Existierende Tests — Laufen sie überhaupt?

### 6.1 Backend-Tests (86 Dateien, 40.214 Zeilen)
- `pytest tests/ -v --tb=short` ausführen
- Alle Failures dokumentieren
- Prüfen: Sind die Tests korrekt oder ist der Code kaputt?
- Mocks/Fixtures prüfen: Werden Permissions weg-gemockt?

### 6.2 Frontend-Tests (79 Dateien, 7.369 Zeilen)
- `npx vitest run` ausführen
- Alle Failures dokumentieren
- Prüfen: Test-Setup korrekt?

### 6.3 E2E-Tests (7 Dateien, 1.175 Zeilen)
- `npx playwright test` ausführen
- Alle Failures dokumentieren
- Prüfen: Test-Environment korrekt?

**Aufwand: ~2h**
**Findet: Welche Tests wirklich laufen, welche kaputt sind, welche wertlos (gemockt)**

---

## Phase 7: Integration — Frontend ↔ Backend Contracts

### 7.1 API-Response vs Frontend-Erwartung
- Pro Frontend-API-Call: Welche Felder erwartet das Frontend?
- Pro Backend-Endpoint: Welche Felder liefert er?
- Mismatches finden (z.B. is_system_admin fehlt in Login-Response)

### 7.2 WebSocket-Test
- Comm WebSocket: Connect, Subscribe, Message send/receive
- AI UI Control WebSocket: Connect, Command send/receive

### 7.3 File-Upload-Test
- DMS: Datei hochladen, herunterladen, löschen
- Mail: Attachment hochladen
- Avatar: Bild hochladen

### 7.4 Search-Test
- Global Search: Query senden, Ergebnisse prüfen
- Pro Search-Provider: Funktioniert er?

**Aufwand: ~3h**
**Findet: Alle Contract-Mismatches, WebSocket-Bugs, Upload-Bugs, Search-Bugs**

---

## Phase 8: Deployment & Config

### 8.1 Docker-Build-Test
- `docker compose build` — funktioniert?
- `docker compose up` — starten alle Services?

### 8.2 prestart.sh-Test
- Alembic migration: Läuft durch?
- DB role passwords: Werden gesetzt?
- sync_plugin_schema: Läuft?
- seed_admin: Läuft und erstellt User + Workspace?

### 8.3 Health-Check-Test
- `/api/v1/health` → 200, alle Checks up?
- Worker healthcheck → Redis ping?

### 8.4 Config-Validation
- Alle ENV-Variablen gesetzt?
- SECRET_KEY nicht default?
- Production-Checks in config.py

**Aufwand: ~2h**
**Findet: Deploy-Bugs, fehlende ENV-Vars, Seed-Fehler**

---

## Phase 9: Scripts (20 Stück, 4.601 Zeilen)

### 9.1 Script-Ausführung
- Pro Script: `python3 scripts/<name>.py --help` — läuft?
- Kritische Scripts testen:
  - backup.py: Backup erstellen
  - restore.py: Restore testen
  - sync_plugin_schema.py: Schema sync
  - seed_admin.py: Admin seed
  - check_migration_hashes.py: Hash validation
  - check_indexes.py: Index check
  - check_cross_plugin_imports.py: Import check

**Aufwand: ~1h**
**Findet: Kaputte Scripts, fehlende Dependencies**

---

## Phase 10: Docs-Accuracy (18 Dateien, 12.484 Zeilen)

### 10.1 API-Docs vs Code
- `docs/api-documentation.md` vs OpenAPI-Spec — stimmen die Endpoints?

### 10.2 Deploy-Guide vs Realität
- `docs/deploy-guide.md` — stimmen die Befehle?

### 10.3 Test-Strategy vs Realität
- `docs/test-strategy.md` — wird sie befolgt?

**Aufwand: ~1h**
**Findet: Veraltete/irreführende Dokumentation**

---

## Zusammenfassung

| Phase | Was | Aufwand | Findet |
|---|---|---|---|
| 1 | Backend API (224 Endpoints) | 6h | Alle Server-Crashes |
| 2 | Frontend (62 Seiten) | 5h | Alle weißen Seiten |
| 3 | Plugins (25 Stück) | 4h | Alle Plugin-Verkabelungs-Fehler |
| 4 | DB-Schema (126 Tabellen) | 3h | Alle Schema-Drifts |
| 5 | Permissions (Matrix) | 3h | Alle RBAC-Fehler |
| 6 | Existierende Tests (172 Stück) | 2h | Welche Tests wirklich laufen |
| 7 | Integration (Contracts) | 3h | Alle Frontend↔Backend-Mismatches |
| 8 | Deployment & Config | 2h | Alle Deploy-Bugs |
| 9 | Scripts (20 Stück) | 1h | Kaputte Scripts |
| 10 | Docs (18 Dateien) | 1h | Veraltete Docs |
| **Gesamt** | **Alles** | **~30h** | **Vollständige Abdeckung** |

---

## Ausführung

### Reihenfolge
1. Phase 6 zuerst — wissen welche Tests existieren und laufen
2. Phase 1 — alle API-Crashes finden
3. Phase 2 — alle weißen Seiten finden
4. Phase 4 — DB-Schema verifizieren
5. Phase 5 — Permission-System verifizieren
6. Phase 3 — Plugins testen
7. Phase 7 — Integration testen
8. Phase 8 — Deployment testen
9. Phase 9 — Scripts testen
10. Phase 10 — Docs prüfen

### Nach jeder Phase
- Alle gefundenen Fehler dokumentieren
- Fehler fixen
- Phase nochmal laufen lassen
- Erst weiter wenn 0 Fehler

### Automatisierung
- Phase 1: Python-Script das OpenAPI-Spec parst und alle Endpoints testet
- Phase 2: Playwright-Script das alle Routes lädt
- Phase 3: Python-Script das Plugin-Registry ausliest und testet
- Phase 4: Python-Script das Models vs DB-Schema vergleicht
- Phase 5: Python-Script das Permission-Matrix testet
- Alle Scripts in `scripts/test_*.py` speichern
- CI-Pipeline kann sie automatisch ausführen

---

## Ergebnis

Nach Abschluss dieses Plans:
- Jedes der 224 Endpoints wurde aufgerufen
- Jede der 62 Seiten wurde geladen
- Jedes der 25 Plugins wurde getestet
- Jede der 126 Tabellen wurde verifiziert
- Jede Permission-Kombination wurde getestet
- Jeder existierende Test wurde ausgeführt
- Jeder Frontend↔Backend-Contract wurde geprüft
- Jedes Script wurde ausgeführt
- Jede Doku wurde gegen Code geprüft

**Das ist nicht läppisch. Das ist vollständige Abdeckung der Basis-Funktionalität.**

---

## Phase 11: Edge Cases & Input Validation

### 11.1 Leere/Null-Daten
- Alle GET-Listen mit leerer DB → 200, `{items: [], total: 0}`
- Alle POST mit leeren Pflichtfeldern → 422
- Alle POST mit null-Werten für optionale Felder → 200/201
- Filter/Search mit leerem Query-String → 200, leere Ergebnisse

### 11.2 Ungültige Inputs
- Ungültige UUIDs → 422 (nicht 500)
- Ungültige Datumsformate → 422
- Ungültige Email-Format → 422
- SQL-Sonderzeichen in Search (`'; DROP TABLE--`) → 200, keine Injection
- Unicode/Emoji in allen Text-Feldern → 200/201
- Sehr lange Strings (>10.000 Zeichen) → 200/201 oder 422 mit klarer Meldung
- Negative Zahlen für IDs/Counts → 422

### 11.3 Große Datenmengen
- 10.000 Kontakte erstellen → Performance <5s
- Paginierung: page=1&page_size=1 vs page=10000&page_size=100 → korrekte Ergebnisse
- Bulk-Import mit 5.000 Zeilen → Erfolg oder klarer Fehler
- Datei-Upload 50MB (Limit) → Erfolg
- Datei-Upload 51MB → 413

### 11.4 Pydantic-Schema-Validation
- Alle Schemas mit falschen Typen testen (String für Integer-Feld, etc.)
- Alle Schemas mit fehlenden Pflichtfeldern
- Alle Schemas mit zusätzlichen unbekannten Feldern (sollten ignoriert oder 422)
- Nested Objects mit falschen Strukturen

**Aufwand: ~4h**
**Findet: Alle Input-Validation-Lücken, SQL-Injection-Vektoren, Performance-Bottlenecks**

---

## Phase 12: Security & Penetration

### 12.1 SQL-Injection
- Alle GET-Parameter mit SQL-Injection-Patterns testen
- Alle POST/PUT-Body-Felder mit SQL-Injection-Patterns
- Search-Queries mit Injection-Patterns
- Raw-SQL-Queries im Code identifizieren und prüfen

### 12.2 XSS
- Alle Text-Eingabefelder mit `<script>alert(1)</script>` testen
- Prüfen ob Output escaped wird (Frontend + Backend)
- Markdown-Rendering mit XSS-Payloads
- HTML-E-Mail-Anzeige mit XSS-Payloads
- DOMPurify funktioniert in allen Render-Pfaden?

### 12.3 CSRF
- Alle POST/PUT/DELETE ohne CSRF-Token → 403
- Alle POST/PUT/DELETE mit falschem CSRF-Token → 403
- CSRF-Token-Rotation nach Login

### 12.4 Path-Traversal
- File-Download mit `../../../etc/passwd` → 404/403
- DMS-Dateipfade mit Traversal-Patterns
- Attachment-Pfade mit Traversal

### 12.5 RLS-Bypass
- User A kann nicht auf Tenant B Daten zugreifen
- User A kann nicht auf User B's private Daten zugreifen
- Admin-Bypass funktioniert nur mit is_system_admin=True
- RLS-Policies für alle 126 Tabellen mit tenant_id prüfen

### 12.6 Session-Security
- Session-Cookie: HttpOnly, Secure, SameSite
- Session-Fixation: Session-ID ändert sich nach Login
- Session-Expiry nach TTL
- Concurrent-Session-Limit (falls konfiguriert)
- Logout invalidiert Session in Redis

### 12.7 File-Upload-Security
- MIME-Type-Validation: `.py` als `image/jpeg` → abgelehnt
- File-Size-Limits enforced
- Filename-Sanitization (keine `../`, keine Null-Bytes)
- Virus-Scan (falls konfiguriert)

### 12.8 API-Token-Security
- Token-Erstellung, -Validierung, -Revocation
- Token-Scopes enforced
- Token-Expiry

**Aufwand: ~6h**
**Findet: Alle Security-Lücken, Injection-Vektoren, Auth-Bypasses**

---

## Phase 13: Data Integrity & Audit

### 13.1 Soft-Delete
- Alle Entities: DELETE → `deleted_at` gesetzt, nicht aus DB entfernt
- Alle Listen: Gelöschte Entities nicht sichtbar
- `?gdpr=true` → Hard-Delete funktioniert
- Restore aus Papierkorb funktioniert

### 13.2 Audit-Log
- Pro Mutation (Create/Update/Delete): Audit-Log-Eintrag erstellt?
- Audit-Log enthält: user_id, action, entity_type, entity_id, changes
- Audit-Log ist immutable (kein Update/Delete möglich)

### 13.3 Entity-History
- Pro Update: History-Eintrag mit diff erstellt?
- Undo funktioniert (Restore einer vorherigen Version)
- History zeigt korrekte Feld-Änderungen

### 13.4 FK-Constraints
- Contact löschen → Person wird gelöscht/NULL gesetzt (je nach Config)
- Tenant löschen → Alle Tenant-Daten gelöscht (Cascade)
- Role löschen → UserTenant.role_id wird NULL gesetzt

### 13.5 Outbox-Reliability
- Mutation → Outbox-Eintrag erstellt
- Worker verarbeitet Outbox-Eintrag
- Bei Fehler: Retry-Logic funktioniert
- Dead-Letter-Queue für fehlgeschlagene Events

**Aufwand: ~3h**
**Findet: Alle Data-Integrity-Verletzungen, fehlende Audit-Logs, kaputte FKs**

---

## Phase 14: Concurrent & Race Conditions

### 14.1 Gleichzeitige Edits
- Zwei User editieren gleichen Kontakt gleichzeitig → Optimistic Locking oder Last-Write-Wins
- Zwei User erstellen Kontakt mit gleicher Email → Unique-Constraint oder Dedup

### 14.2 WebSocket bei mehreren Clients
- Zwei Browser-Tabs gleicher User → Messages synchron?
- Two Users in gleicher Conversation → Real-time Updates?
- WebSocket Reconnect nach Verbindungsabbruch

### 14.3 Worker-Concurrency
- Mehrere Worker-Instanzen → Cron-Jobs nicht doppelt ausgeführt (Redis-Lock)
- Gleichzeitige Background-Jobs → Keine Deadlocks

### 14.4 Session-Concurrency
- Login von zwei Geräten → Beide Sessions gültig?
- Logout auf Gerät A → Gerät B noch eingeloggt?

**Aufwand: ~3h**
**Findet: Alle Race Conditions, Deadlock-Gefahren, WebSocket-Sync-Issues**

---

## Phase 15: Error Recovery & Resilience

### 15.1 DB-Verbindungsabbruch
- DB kurzzeitig nicht erreichbar → API gibt 503, nicht 500
- DB wieder da → API erholt sich automatisch
- Circuit-Breaker öffnet/schließt korrekt

### 15.2 Redis-Ausfall
- Redis nicht erreichbar → Sessions funktionieren nicht (klare Fehlermeldung)
- Redis wieder da → Alles normal
- Worker: Redis-Ausfall → Retry, nicht Crash

### 15.3 Worker-Crash
- Worker stirbt mittendrin → Job wird retryt
- Job schlägt 3x fehl → Dead-Letter oder klarer Fehler

### 15.4 LLM-Timeout/Error
- LLM-Provider nicht erreichbar → Timeout nach konfigurierten Sekunden
- LLM gibt Fehler → KI-Chat zeigt Fehlermeldung, nicht weiße Seite
- Cost-Tracking funktioniert auch bei Fehlern

### 15.5 External Service-Ausfall
- SMTP nicht erreichbar → Password-Reset-Email schlägt fehl mit klarer Meldung
- IMAP nicht erreichbar → Mail-Sync schlägt fehl, retryt später
- Forgejo/GitHub Webhook-Empfänger nicht erreichbar → Retry-Logic

**Aufwand: ~3h**
**Findet: Alle unhandled Errors, fehlende Circuit-Breaker, Crash-bei-Ausfall-Szenarien**

---

## Phase 16: Performance & Scalability

### 16.1 Response-Zeiten
- Alle 224 Endpoints: Response-Zeit <200ms (mit DB-Daten)
- Listen-Endpoints mit 1.000 Einträgen: <500ms
- Search-Queries: <1s

### 16.2 N+1 Queries
- Kontakte-Liste lädt nicht pro Kontakt eine separate Query für Companies/Persons
- Plugin-Manifeste: Nicht pro Plugin eine separate Query
- Audit-Log: Nicht pro Eintrag eine separate User-Query

### 16.3 Memory-Leaks
- Längerer Last-Test (100 Requests/min für 10min) → Memory stabil?
- Frontend: Seitenwechsel 50x → Memory stabil?

### 16.4 DB-Query-Performance
- EXPLAIN ANALYZE für kritische Queries (Contacts, Mails, Files, Search)
- Fehlende Indexe identifizieren
- Slow-Query-Log aktivieren und auswerten

### 16.5 Frontend-Bundle-Size
- Bundle-Analyse: Chunks >500kB identifizieren
- Lazy-Loading funktioniert für alle 62 Seiten
- Code-Splitting effektiv?

**Aufwand: ~3h**
**Findet: Alle Performance-Bottlenecks, N+1 Queries, Memory-Leaks, fehlende Indexe**

---

## Phase 17: Cross-Plugin & Plugin-Lifecycle

### 17.1 Plugin-Dependencies
- Plugin A deaktivieren während Plugin B von A abhängt → Fehlermeldung
- Plugin A aktivieren bevor Dependency B aktiv ist → Fehlermeldung
- Dependency-Graph korrekt?

### 17.2 Hook-Ketten
- Contact erstellen → ContactsPlugin Hook → HistoryPlugin Hook → SearchPlugin Hook → AIPlugin Hook
- Alle Hooks werden in korrekter Reihenfolge ausgeführt
- Ein Hook crasht → Andere Hooks laufen trotzdem

### 17.3 Plugin-Activation/Deactivation
- Alle 25 Plugins: Aktivieren → Hooks registriert, Tabellen erstellt
- Alle 25 Plugins: Deaktivieren → Hooks deregistriert, Tabellen bleiben
- Re-Aktivieren → Hooks wieder registriert, keine Duplikate

### 17.4 Plugin-Isolation
- Plugin A kann nicht Plugin B's Hooks löschen (clear_actions Bug war P0-3)
- Plugin A kann nicht auf Plugin B's private Tabellen zugreifen

**Aufwand: ~3h**
**Findet: Alle Plugin-Dependency-Issues, Hook-Ketten-Fehler, Isolation-Verletzungen**

---

## Phase 18: State Management & Frontend Consistency

### 18.1 Store-Consistency nach API-Fehlern
- API gibt 500 → Store bleibt konsistent (kein halber State)
- API gibt 403 → UI zeigt korrekte Fehlermeldung
- Network-Error → UI zeigt Offline-Banner, Store bleibt konsistent

### 18.2 State nach Page-Refresh
- Alle 12 Stores: Persistierter State korrekt geladen?
- authStore: User, isAuthenticated, is_system_admin nach Refresh korrekt?
- workspaceStore: Active Workspace nach Refresh korrekt?
- themeStore: Theme nach Refresh korrekt?

### 18.3 TanStack Query Cache
- Cache invalidation nach Mutations (Create/Update/Delete)
- staleTime korrekt konfiguriert?
- refetchOnWindowFocus disabled (konfiguriert)
- Query-Keys eindeutig?

### 18.4 Optimistic Updates
- Contact-Edit: UI aktualisiert sofort, rollback bei API-Fehler
- Mail-Send: UI zeigt sofort, rollback bei Fehler

**Aufwand: ~2h**
**Findet: Alle State-Inconsistencies, Cache-Bugs, fehlende Rollbacks**

---

## Phase 19: Accessibility (a11y)

### 19.1 ARIA-Attributes
- Alle interaktiven Elemente haben aria-label
- Alle Buttons haben aria-label oder sichtbaren Text
- Alle Form-Inputs haben label
- Navigation hat aria-label

### 19.2 Keyboard-Navigation
- Tab-Reihenfolge logisch (top-to-bottom, left-to-right)
- Enter auf Button löst Klick aus
- Escape schließt Modals/Dialogs
- Tab-Trapping in Modals

### 19.3 Touch-Targets
- Alle interaktiven Elemente ≥44px (min-h-touch class)
- Mobile: Keine zu kleinen Buttons

### 19.4 Screen-Reader
- Skip-to-content Link funktioniert
- Heading-Hierarchie korrekt (h1 → h2 → h3)
- Status-Messages haben role=status oder aria-live

### 19.5 Color-Contrast
- Alle Text/Background-Kombinationen ≥4.5:1 (WCAG AA)
- Dark-Mode: Contrast korrekt?

**Aufwand: ~2h**
**Findet: Alle a11y-Verstöße, fehlende ARIA, Keyboard-Traps**

---

## Phase 20: i18n (Internationalisierung)

### 20.1 Translation-Completeness
- Deutsch: Alle t()-Keys vorhanden? Keine hardcoded Strings?
- Englisch: Alle t()-Keys vorhanden? Keine hardcoded Strings?
- Fallback: Fehlender Key → Fallback auf Deutsch?

### 20.2 Dynamic-Values
- Interpolation: `{{count}}`, `{{name}}` funktionieren in allen Sprachen
- Plural-Forms korrekt?

### 20.3 Date/Number-Formatting
- Datumsformat korrekt pro Locale (de: dd.MM.yyyy, en: MM/dd/yyyy)
- Zahlenformat korrekt (de: 1.234,56, en: 1,234.56)

**Aufwand: ~1h**
**Findet: Fehlende Übersetzungen, hardcoded Strings, Formatierungs-Fehler**

---

## Phase 21: Backup & Restore

### 21.1 Full-Backup
- `scripts/backup.py` → pg_dump + files → Backup erstellt
- Backup-Datei gültig (kann restored werden)
- Backup-Retention funktioniert

### 21.2 Full-Restore
- `scripts/restore.py` → DB + Files restored
- Alle Daten nach Restore korrekt
- RLS-Policies nach Restore intakt

### 21.3 Partial-Restore
- Nur DB restore → funktioniert
- Nur Files restore → funktioniert
- Restore auf andere DB → funktioniert

### 21.4 Backup-Schedule
- Cron-Job für regelmäßige Backups konfiguriert?
- Backup-Fehler → Notification

**Aufwand: ~2h**
**Findet: Backup/Restore-Bugs, fehlende Schedules**

---

## Phase 22: Migration Safety

### 22.1 Rollback-Test
- Letzte Migration zurücknehmen (`alembic downgrade -1`)
- Wieder anwenden (`alembic upgrade head`)
- Daten nach Roundtrip intakt?

### 22.2 Hash-Validierung
- `scripts/check_migration_hashes.py` → alle Hashes gültig?
- Manuell geänderte Migrationen erkannt?

### 22.3 Fehlgeschlagene Migration
- Migration simuliert fehlschlagen → DB konsistent?
- Recovery: `alembic stamp` vs `alembic upgrade`

### 22.4 Migration-Order
- Alle 121 Migrationen in korrekter Reihenfolge
- Keine zirkulären Dependencies
- Down-Revisions korrekt

**Aufwand: ~2h**
**Findet: Migration-Order-Fehler, kaputte Rollbacks, Hash-Mismatches**

---

## Phase 23: Rate Limiting & Circuit Breaker

### 23.1 Rate-Limiting
- Login: 5 Versuche → Rate-Limit aktiviert
- API: 100 Requests/min → Rate-Limit aktiviert
- Rate-Limit-Reset nach Window

### 23.2 Circuit-Breaker
- DB: 5 Fehler in 30s → Circuit öffnet
- Circuit offen → API gibt 503, nicht 500
- Nach Cooldown → Circuit schließt, Requests gehen durch

### 23.3 Retry-Logic
- DB-Retry: 3 Versuche mit Backoff
- LLM-Retry: Konfigurierte Versuche
- Worker-Retry: Failed-Job wird retryt

**Aufwand: ~1h**
**Findet: Fehlende Rate-Limits, kaputte Circuit-Breaker, fehlende Retries**

---

## Phase 24: Webhooks & External Integration

### 24.1 Webhook-Delivery
- Webhook registriert → Event ausgelöst → Delivery an externe URL
- Externe URL nicht erreichbar → Retry-Logic
- Webhook-Signatur korrekt

### 24.2 Forgejo/GitHub-Integration
- Forgejo-Error-Reporter: Fehler werden gemeldet
- GitHub-Actions: CI-Pipeline funktioniert

### 24.3 MCP-Server/Client
- MCP-Server: Tools verfügbar, ausführbar
- MCP-Client: Server-Config, Connection, Tool-Call

**Aufwand: ~2h**
**Findet: Webhook-Delivery-Fehler, fehlende Retries, kaputte Integrationen**

---

## Phase 25: Search & AI

### 25.1 Unified-Search
- Global-Search: Query → Ergebnisse aus allen Providern
- Pro Provider (13 Stück): Funktioniert er?
- Reindexing: `reindex_all` → alle Entities neu indiziert
- pgvector: Embeddings korrekt, HNSW-Index funktioniert

### 25.2 AI-Assistant
- Chat-Session erstellen → Message senden → Antwort erhalten
- Streaming: Token-weise Ausgabe funktioniert
- Cost-Tracking: Kosten pro Request erfasst
- Error-Handling: LLM-Fehler → klare Meldung

### 25.3 AI-Proactive
- Context-Tracking: Seitenwechsel → Context aktualisiert
- Suggestion-Generation: Vorschläge basierend auf Context

### 25.4 AI-UI-Control
- WebSocket: Command senden → UI führt Aktion aus
- Navigation, Filter, Modal, Tab, Settings Commands

### 25.5 Automation & Agents
- Automation erstellen → Trigger auslösen → Action ausführen
- Agent erstellen → Execute → Subtasks → Result
- Dry-Run: Automation ohne echte Ausführung
- Cron-Jobs: Scheduler-Tick funktioniert

**Aufwand: ~3h**
**Findet: Alle Search/AI/Automation-Verkabelungs-Fehler**

---

## Phase 26: Communication & Collaboration

### 26.1 Comm-WebSocket
- Connect → Subscribe → Message senden → Message empfangen
- Typing-Indicators
- Read-Receipts
- Message-Blocks (Markdown, HTML, Audio, Video, File, Action-Card, Contact-Card, MiniApp)
- Reconnect nach Verbindungsabbruch

### 26.2 Conversations
- Create, List, Archive, Pin, Mute
- Direct-Chat zwischen Usern
- System-Channel (Notifications)
- AI-Channel (Assistant)

### 26.3 Message-Editing
- Message editieren → Edit-History gespeichert
- Message löschen → Soft-Delete
- Reactions auf Messages

**Aufwand: ~2h**
**Findet: Alle Comm-Verkabelungs-Fehler, WebSocket-Bugs, Message-Rendering-Issues**

---

## Phase 27: Workspace & Tenant

### 27.1 Workspace-Operations
- Workspace erstellen, bearbeiten, löschen
- Module zuweisen, Sichtbarkeit togglen
- User zuweisen, Rollen vergeben
- Workspace-Switching: Context ändert sich korrekt

### 27.2 Tenant-Operations
- Tenant erstellen (Multi-Tenant)
- User zu Tenant einladen
- Tenant-Switching: Daten isoliert
- Cross-Tenant-Access: Blockiert durch RLS

### 27.3 Workspace-Module-Visibility
- Pro Module: Sichtbar in Sidebar?
- Module ohne Permission → ausgeblendet
- Admin sieht alle Module

**Aufwand: ~2h**
**Findet: Alle Workspace/Tenant-Isolation-Fehler**

---

## Phase 28: Browser Compatibility

### 28.1 Chrome (aktuell)
- Alle 62 Seiten laden
- Alle Features funktionieren

### 28.2 Firefox (aktuell)
- Alle 62 Seiten laden
- CSS-Rendering korrekt

### 28.3 Safari (aktuell)
- Alle 62 Seiten laden
- Datei-Upload funktioniert
- WebSocket funktioniert

### 28.4 Mobile (Chrome Android / Safari iOS)
- Responsive-Layout korrekt
- Touch-Targets ≥44px
- Mobile-Sidebar (Off-Canvas) funktioniert
- Virtual Keyboard verdeckt nicht Inputs

**Aufwand: ~2h**
**Findet: Browser-spezifische Bugs, Mobile-Issues**

---

## Phase 29: File Storage & DMS

### 29.1 File-Operations
- Upload (einzelne Datei, mehrere Dateien, Drag-Drop)
- Download (einzelne Datei, Bulk-Download)
- Rename, Move, Copy
- Delete (Soft-Delete, Hard-Delete mit GDPR)
- Restore aus Papierkorb

### 29.2 Folder-Operations
- Create, Rename, Move, Delete
- Nested-Folders (5+ Ebenen)
- Folder-Permissions (User, Group)

### 29.3 Share-Links
- Share-Link erstellen mit Password
- Share-Link mit Expiry-Date
- Public-Access über Share-Link
- Share-Link revoken

### 29.4 Storage-Limits
- Max-File-Size enforced
- Storage-Quota (falls konfiguriert)
- Cleanup verwaister Dateien

**Aufwand: ~2h**
**Findet: Alle DMS/File-Storage-Bugs**

---

## Phase 30: Mail System

### 30.1 Mail-Accounts
- IMAP-Account hinzufügen, testen, synchronisieren
- SMTP-Account konfigurieren
- Shared vs Personal Accounts
- Account löschen → Mails bleiben oder werden gelöscht

### 30.2 Mail-Operations
- Mail empfangen, lesen, als gelesen/ungelesen markieren
- Mail senden (mit/ohne Attachments)
- Reply, Reply-All, Forward
- Flag, Move, Delete, Restore
- Search in Mails

### 30.3 Mail-Rules
- Rule erstellen (Condition → Action)
- Rule ausführen auf neue Mails
- Rule löschen

### 30.4 Mail-Labels
- Label erstellen, zuweisen, entfernen
- Filter nach Labels

### 30.5 Mail-Signatures
- Signature erstellen, als Default setzen
- Signature in neuer Mail eingefügt

### 30.6 Vacation-Responder
- Aktivieren, konfigurieren, deaktivieren
- Auto-Response wird gesendet

### 30.7 PGP-Verschlüsselung
- Key importieren
- Mail verschlüsseln/entschlüsseln
- Contact-PGP-Key speichern

**Aufwand: ~3h**
**Findet: Alle Mail-System-Bugs**

---

## Vollständige Zusammenfassung (alle 30 Phasen)

| Phase | Was | Aufwand |
|---|---|---|
| 1 | Backend API (224 Endpoints) | 6h |
| 2 | Frontend (62 Seiten, 154 Komponenten, 12 Stores, 11 Hooks) | 5h |
| 3 | Plugins (25 Stück) | 4h |
| 4 | DB-Schema (126 Tabellen, 40 Models) | 3h |
| 5 | Permissions (Matrix, Field-Level) | 3h |
| 6 | Existierende Tests (172 Stück) | 2h |
| 7 | Integration (Contracts, WebSocket, Upload, Search) | 3h |
| 8 | Deployment & Config | 2h |
| 9 | Scripts (20 Stück) | 1h |
| 10 | Docs (18 Dateien) | 1h |
| 11 | Edge Cases & Input Validation | 4h |
| 12 | Security & Penetration | 6h |
| 13 | Data Integrity & Audit | 3h |
| 14 | Concurrent & Race Conditions | 3h |
| 15 | Error Recovery & Resilience | 3h |
| 16 | Performance & Scalability | 3h |
| 17 | Cross-Plugin & Lifecycle | 3h |
| 18 | State Management & Consistency | 2h |
| 19 | Accessibility | 2h |
| 20 | i18n | 1h |
| 21 | Backup & Restore | 2h |
| 22 | Migration Safety | 2h |
| 23 | Rate Limiting & Circuit Breaker | 1h |
| 24 | Webhooks & External Integration | 2h |
| 25 | Search & AI & Automation | 3h |
| 26 | Communication & Collaboration | 2h |
| 27 | Workspace & Tenant | 2h |
| 28 | Browser Compatibility | 2h |
| 29 | File Storage & DMS | 2h |
| 30 | Mail System | 3h |
| **Gesamt** | **Vollständige Abdeckung** | **~80h** |

---

## Ausführung

### Reihenfolge (angepasst)
1. Phase 6 — Existierende Tests ausführen
2. Phase 1 — Alle 224 API-Endpoints
3. Phase 2 — Alle 62 Frontend-Seiten
4. Phase 4 — DB-Schema verifizieren
5. Phase 5 — Permission-Matrix
6. Phase 12 — Security (früh, weil kritisch)
7. Phase 3 — Plugins testen
8. Phase 7 — Integration
9. Phase 11 — Edge Cases
10. Phase 13 — Data Integrity
11. Phase 15 — Error Recovery
12. Phase 16 — Performance
13. Phase 17 — Cross-Plugin
14. Phase 18 — State Management
15. Phase 14 — Concurrent
16. Phase 8 — Deployment
17. Phase 21 — Backup/Restore
18. Phase 22 — Migration Safety
19. Phase 23 — Rate Limiting
20. Phase 24 — Webhooks
21. Phase 25 — Search & AI
22. Phase 26 — Communication
23. Phase 27 — Workspace & Tenant
24. Phase 29 — File Storage & DMS
25. Phase 30 — Mail System
26. Phase 19 — Accessibility
27. Phase 20 — i18n
28. Phase 28 — Browser Compatibility
29. Phase 9 — Scripts
30. Phase 10 — Docs

### Nach jeder Phase
- Alle gefundenen Fehler in `docs/test-results/phase-XX.md` dokumentieren
- Fehler fixen
- Phase nochmal laufen lassen
- Erst weiter wenn 0 Fehler

### Automatisierung
- Phase 1: `scripts/test_all_endpoints.py` — OpenAPI-Spec parsen, alle Endpoints testen
- Phase 2: `scripts/test_all_routes.py` — Playwright, alle Routes laden
- Phase 3: `scripts/test_all_plugins.py` — Plugin-Registry, Manifeste, Routes
- Phase 4: `scripts/test_schema_vs_models.py` — Models vs DB-Schema
- Phase 5: `scripts/test_permission_matrix.py` — Permission-Matrix
- Phase 11: `scripts/test_edge_cases.py` — Edge-Case-Payloads
- Phase 12: `scripts/test_security.py` — Security-Scans
- Phase 16: `scripts/test_performance.py` — Performance-Benchmarks
- Alle Scripts in `scripts/test_*.py` speichern
- CI-Pipeline kann sie automatisch ausführen

---

## Ergebnis nach Abschluss

- Jedes der 224 Endpoints wurde mit gültigen/ungültigen/leeren/bösartigen Inputs getestet
- Jede der 62 Seiten wurde in Chrome geladen und auf JS-Errors geprüft
- Jedes der 25 Plugins wurde aktiviert/deaktiviert und getestet
- Jede der 126 Tabellen wurde gegen Models validiert
- Jede Permission-Kombination (Admin/Non-Admin/Guest/Unauth) wurde getestet
- Jeder der 172 existierenden Tests wurde ausgeführt
- Jeder Frontend↔Backend-Contract wurde geprüft
- Jedes Script wurde ausgeführt
- Jede Doku wurde gegen Code geprüft
- Security: SQL-Injection, XSS, CSRF, Path-Traversal, RLS-Bypass, Session getestet
- Performance: Response-Zeiten, N+1 Queries, Memory-Leaks getestet
- Resilience: DB/Redis/Worker/LLM-Ausfall getestet
- Accessibility: ARIA, Keyboard, Touch-Targets, Contrast getestet
- i18n: Alle Übersetzungen, alle Sprachen getestet
- Backup/Restore: Vollständiger Cycle getestet
- Migration: Rollback, Hash-Validierung getestet
- Browser: Chrome, Firefox, Safari, Mobile getestet
- Mail: Kompletter Mail-Cycle getestet
- DMS: Kompletter File-Cycle getestet
- Communication: WebSocket, Messages, Blocks getestet
- AI: Chat, Streaming, Cost-Tracking, Automation, Agents getestet

**30 Phasen. ~80 Stunden. Vollständige Abdeckung. Nichts übersprungen.**