„Die Module sollen als Plugins realisiert sein, sodass das CRM später durch Plugins erweitert werden kann. Module (Mail, Kalender, Dateien, Tags) sind Plugins."
+
+**F-PLUGIN-02 (Zeile 857-860)** definiert Plugin-Schnittstelle, Lifecycle-Hooks, Plugin-Manifest.
+
+**Gleichzeitig** werden genau diese Module als detaillierte Core-Features mit konkreten HTTP-Endpunkten, DB-Schemas und Test-Szenarien spezifiziert:
+- **F-DMS-01 bis F-DMS-07 (Zeilen 991-1083):** DMS mit `POST /api/dms/folders`, `PATCH /api/dms/files/{id}`, etc.
+- **F-CAL-01 bis F-CAL-18 (Zeilen 1397-1662):** Kalender mit `POST /api/calendar/entries`, `GET /api/calendar/kanban`, etc.
+- **F-MAIL-01 bis F-MAIL-19 (Zeilen 1668-1951):** Mail mit `POST /api/mail/send`, IMAP IDLE, SMTP, PGP, etc.
+- **F-TAG-01 bis F-TAG-04 (Zeilen 1173-1223):** Tags mit `POST /api/tags/assign`, etc.
+
+**Widerspruch:** Wenn Module Plugins sind, dann gehören ihre detaillierten Feature-Spezifikationen (Endpunkte, DB-Schemas, Test-Szenarien) NICHT in die Core-Requirements. Der Core definiert die Plugin-Schnittstelle; das Plugin definiert seine eigenen Features. So wie es jetzt ist, wird das Plugin-System deklariert, aber dann werden die „Plugin-Module" im Core-Requirements-Dokument detailliert spezifiziert — als wären sie Core-Features.
+
+**F-CORE-01 bis F-CORE-13 (Zeilen 864-953)** definieren Core-Infrastruktur (Event Bus, Tenant-Isolation, Plugin-Migration, Service Container, API-First, Async Queue, Caching, Storage, Import/Export, PDF-Gen, Notification Service). Diese sind allesamt Architekturentscheidungen, keine Requirements.
+
+**Fazit:** Die Datei versucht gleichzeitig zu sagen „ diese Module sind Plugins" UND „ diese Module sind Core-Features mit konkreten Implementierungsdetails". Das ist ein architektonischer Widerspruch, der in der Architektur-Phase aufgelöst werden muss — nicht in den Requirements.
+
+### 1.2 Multi-Tenant (F-AUTH-07) vs. ältere Requirements ohne Tenant-Kontext (WARNING)
+
+**F-AUTH-07 (Zeile 135-138)** deklariert Multi-Tenant als v1-Feature:
+> „Das System ist Multi-Tenant-fähig. Mehrere Firmen (Tenants) können im System verwaltet werden. Daten sind pro Tenant isoliert."
+
+**F-CORE-02 (Zeile 871-874)** spezifiziert `tenant_id` auf allen Tabellen, ORM-Middleware für automatisches Query-Scoping.
+
+**Annahme 1 (Zeile 1978):** „v1 ist Multi-Tenant (Multi-Company) — mehrere Firmen (Tenants) im System."
+
+**Aber:** Die früher geschriebenen Requirements (F-AUTH-01 bis F-CONT-07, Zeilen 57-410) erwähnen Tenant-Kontext an keiner Stelle:
+- F-AUTH-01 (Login): kein Tenant-Bezug
+- F-AUTH-03 (User-Verwaltung): kein Tenant-Bezug — aber in Multi-Tenant muss ein User einem Tenant zugeordnet sein
+- F-COMP-01 (Firma anlegen): kein `tenant_id` in Feld-Tabelle (Zeile 156-186)
+- F-CONT-01 (Kontakt anlegen): kein `tenant_id` in Feld-Tabelle (Zeile 300-333)
+- F-COMP-05 (Pagination): kein Tenant-Filter erwähnt
+- F-COMP-06 (Suche): kein Tenant-Scoping erwähnt
+
+**Fazit:** Multi-Tenant wurde später hinzugefügt und die frühen Requirements wurden nicht nachträglich aktualisiert. Das führt zu einer Lücke: Wie verhält sich F-COMP-01 (Firma anlegen) in Multi-Tenant-Kontext? Wird die Firma automatisch dem aktiven Tenant zugeordnet? Kann ein User Firmen in mehreren Tenants anlegen? Diese Fragen sind in den Requirements nicht beantwortet.
+
+### 1.3 KI-Copilot (F-AI-01) mit voller API-Kontrolle vs. ältere UI-only-Flow-Requirements (WARNING)
+
+**F-AI-01 (Zeile 798-806)** deklariert:
+> „Der Copilot hat Zugriff auf die volle API und soll alles steuern können — Daten abfragen, erstellen, bearbeiten, löschen, Aktionen auslösen, Workflows triggern."
+
+**F-CORE-06 (Zeile 899-902)** deklariert API-First:
+> „Alle Core-Features und Plugin-Features sind primär über die API nutzbar. Die UI ist ein API-Client."
+
+**Aber:** Mehrere Requirements beschreiben nur UI-Flows ohne API-Bezug:
+- F-UI-01 (Responsive Design, Zeile 495-503): nur CSS-Breakpoints, kein API-Bezug
+- F-UI-02 (i18n, Zeile 509-517): nur Frontend-Library, kein API-Bezug
+- F-UI-03 (Toast-Notifications, Zeile 523-531): nur Frontend-Komponente
+- F-UI-04 (Loading-States, Zeile 537-545): nur Frontend-State
+- F-UI-05 (Empty-States, Zeile 551-559): nur Frontend-Komponente
+- F-UI-06 (Confirmation-Dialogs, Zeile 565-573): nur Frontend-Modal
+- F-UI-08 (Datenansichten, Zeile 579-582): nur Frontend-Toggle
+
+**Einschränkung:** Diese UI-Requirements sind legitimerweise UI-only — sie beschreiben Präsentationslogik, keine Datenoperationen. F-CORE-06 sollte explizit ausschließen, dass reine UI-Präsentations-Features keine API-Entpunkte benötigen. Aktuell ist die Formulierung „alle Features über API nutzbar" zu breit und suggeriert, dass auch Toast-Notifications einen API-Endpunkt haben müssten.
+
+**Zusätzlicher Befund:** F-AI-01 und F-CORE-06 wurden retroaktiv hinzugefügt. Die ursprünglichen Requirements (v0.1, archiviert in Appendix A, Zeile 2089-2128) beschreiben Jinja2-Templates und SQLite — eine völlig andere Architektur. Die Datei hat also mindestens drei Evolutionsschichten:
+1. v0.1: Single-Tenant, Jinja2, SQLite (archiviert)
+2. v0.3: React SPA, PostgreSQL, RBAC (Hauptteil)
+3. v0.5+: Multi-Tenant, Plugin-System, API-First, KI-Copilot, Mail/Kalender/DMS (hinzugefügt)
+
+Die Schichten wurden nicht vollständig integriert — Rückbezüge fehlen.
+
+### 1.4 Auth-Mechanismus-Unschärfe (WARNING)
+
+**F-AUTH-01 (Zeile 58):** „Session-basierte Auth mit HttpOnly+Secure+SameSite=Strict Cookie"
+
+**F-AUTH-02 (Zeile 72-78):** Test-Szenario sagt „Token wird entfernt" und Akzeptanzkriterium sagt „Server-Token-Blacklist optional für v1" — das suggeriert Token-basierte Auth (JWT?), nicht Session-basierte Auth.
+
+**F-INT-02 (Zeile 714-722):** „API-Endpunkte sind via Session-Cookie authentifiziert" aber erwähnt auch „Optional: API-Key für externe Integrationen".
+
+**F-SEC-03 (Zeile 616-624):** „Session läuft nach 8h ab" — aber „Token gültig <8h" und „Token nach 8h → API gibt 401" — wieder Token-Sprache.
+
+**Fazit:** Die Datei wechselt inkonsistent zwischen „Session" und „Token". Entweder es ist Session-basiert (Cookie + Server-Side Session Store) oder Token-basiert (JWT Stateless). Das muss entschieden und einheitlich formuliert werden.
+
+---
+
+## Section 2: Requirements vs. Bauanleitung Assessment
+
+### 2.1 Enthaltene Implementierungsdetails
+
+Die Datei enthält massiv Implementierungsdetails, die in eine Requirements-Spec nicht gehören:
+
+#### HTTP-Endpunkte (Architektur, nicht Requirement)
+Jedes einzelne Akzeptanzkriterium spezifiziert konkrete HTTP-Endpunkte mit Pfaden, HTTP-Methoden, Query-Parametern und Response-Codes:
+- `POST /api/auth/login` (Zeile 65)
+- `GET /api/companies/{id}` (Zeile 207)
+- `DELETE /api/companies/{id}?cascade=true|false` (Zeile 235)
+- `GET /api/contacts?page=1&page_size=25&sort_by=last_name&sort_order=asc` (Zeile 396)
+- `POST /api/dms/files/upload` (Zeile 1013)
+- `GET /api/dms/files/{id}/preview` (Zeile 1041)
+- `POST /api/calendar/entries` (Zeile 1439)
+- `GET /api/calendar/kanban?period=this_week` (Zeile 1419)
+- `POST /api/mail/send` (Zeile 1693)
+- `GET /api/mail/search?q=angebot&folder=inbox` (Zeile 1709)
+- ...und dutzende weitere
+
+**Problem:** Der Endpunkt-Pfad ist eine Architekturentscheidung. Ein Requirement sagt „User kann sich einloggen" — der Pfad `/api/auth/login` ist Implementierung.
+
+#### DB-Schema-Definitionen (Architektur, nicht Requirement)
+- **F-COMP-01 (Zeilen 156-186):** Vollständige Feld-Tabelle mit Typen: `String(100)`, `Integer`, `Decimal`, `Picklist`, `FK→Company`, `Text(32000)`, etc. — das ist ein DB-Schema
+- **F-CONT-01 (Zeilen 300-333):** Vollständige Feld-Tabelle für Kontakte mit Typen
+- **F-COMP-07 (Zeile 277):** `audit_log` Tabellenname
+- **F-COMP-08 (Zeile 291):** `deletion_log` Tabellenname
+- **F-CONT-07 (Zeile 424):** `company_contacts` N:M-Tabellenname
+- **F-CORE-02 (Zeile 872):** `tenant_id` Feld auf allen Tabellen
+- **F-MAIL-03 (Zeile 1709):** `tsvector`-Index, `mail_body_tsv`, `mail_subject_tsv`
+- **F-CAL-12 (Zeile 1572):** `user_calendar_visibility` Tabellenname
+- **F-CAL-15 (Zeile 1614):** `assigned_to: user_id` Feldname
+
+**Problem:** Feldnamen, -typen und Tabellennamen sind Implementierungsdetails, die in das DB-Schema der Architektur gehören.
+
+#### Technologie-Entscheidungen (Architektur, nicht Requirement)
+- **F-CORE-07 (Zeile 907):** „Celery + Redis oder RQ + Redis" — Technologie-Wahl
+- **F-CORE-08 (Zeile 914):** „Redis als Cache-Backend" — Technologie-Wahl
+- **F-CORE-10 (Zeile 928):** „S3-kompatibles Storage (z.B. MinIO)" — Technologie-Wahl
+- **F-MAIL-02 (Zeile 1693):** „DOMPurify" — Library-Wahl
+- **F-MAIL-12 (Zeile 1846):** „python-gnupg" — Library-Wahl
+- **F-UI-02 (Zeile 517):** „react-i18next" — Library-Wahl
+- **F-DMS-04 (Zeile 1034):** „PDF.js" — Library-Wahl
+- **F-DATA-03 (Zeile 459):** „Pydantic-Schemas" — Library-Wahl
+- **F-INFRA-03 (Zeile 666):** „Python logging mit JSON-Formatter" — Library-Wahl
+
+#### Protokoll-Details (Architektur, nicht Requirement)
+- **F-MAIL-01 (Zeile 1670):** „IMAP4rev1 (RFC 3501)", „IMAP IDLE (RFC 2177)"
+- **F-MAIL-02 (Zeile 1693):** „multipart/mixed", „SMTP-Versand"
+- **F-MAIL-05 (Zeile 1733):** „References- und In-Reply-To-Header (RFC 5322)"
+- **F-MAIL-18 (Zeile 1929):** „AES-256, Key via Env-Var"
+- **F-CAL-08 (Zeile 1516):** „RRULE (RFC 5545)"
+- **F-CAL-09 (Zeile 1530):** „RFC 5545 konform"
+- **F-MAIL-18 (Zeile 1929):** „IMAP MOVE (RFC 6851)"
+
+#### Frontend-Komponenten-Namen (Architektur, nicht Requirement)
+- **F-CAL-01 (Zeile 1405):** `CalendarView` Komponente
+- **F-CAL-02 (Zeile 1419):** `KanbanCalendar` Komponente
+- **F-FILEUI-01 (Zeile 1321):** `FileBrowser`, `SidebarTree`, `MainView` Komponenten
+- **F-FILEUI-02 (Zeile 1335):** `Breadcrumb` Komponente
+- **F-FILEUI-03 (Zeile 1349):** `ContextMenu` Komponente
+- **F-FILEUI-04 (Zeile 1363):** Multi-Select-State in `FileBrowser`
+- **F-MAIL-05 (Zeile 1741):** `ThreadView` Komponente
+
+#### Farbcodes und UI-Implementierung (Architektur, nicht Requirement)
+- **F-CAL-06 (Zeile 1485):** `{appointment+normal: "#3B82F6", task+normal: "#F59E0B", *+follow_up: "#F97316", *+private: "#9CA3AF"}` — konkrete Hex-Codes
+- **F-COMP-04 (Zeile 235):** `deleted_at = NOW` — SQL-Ausdruck
+- **F-FILEUI-02 (Zeile 1335):** „Materialized Path oder rekursive Abfrage" — DB-Pattern
+- **F-FILEUI-06 (Zeile 1391):** „HTML5 Drag & Drop API" — Browser-API
+- **F-FILEUI-05 (Zeile 1377):** „XMLHttpRequest (für Progress-Events) oder WebSocket" — Technologie
+
+#### Algorithmus- und Logik-Details (Architektur, nicht Requirement)
+- **F-MAIL-07 (Zeilen 1762-1771):** Regelauswertungs-Reihenfolge, Background-Worker-Trigger
+- **F-MAIL-08 (Zeile 1786):** `vacation_sent_log`, No-Reply-Erkennung: „noreply", „no-reply", „donotreply"
+- **F-CAL-08 (Zeile 1516):** Recurrence-Instanz-Generierung, Exception-Handling
+- **F-CAL-15 (Zeile 1614):** Notification-Versand bei Zuweisung
+
+### 2.2 Schätzung des Anteils
+
+| Kategorie | Zeilen (geschätzt) | Anteil |
+|-----------|--------------------|--------|
+| **Genuine Requirements (das WAS)** | ~700-750 | ~35% |
+| — Projektbeschreibung, Domain Knowledge | ~25 | |
+| — Feature-Anforderung-Texte („User kann...") | ~250 | |
+| — Test-Szenarien (Verhalten, nicht Implementation) | ~300 | |
+| — Non-funktionale Anforderungen | ~20 | |
+| — Annahmen, Non-Goals, Checkliste, Open Questions | ~155 | |
+| **Architektur/Implementierung (das HOW)** | ~1380-1430 | ~65% |
+| — HTTP-Endpunkte in Akzeptanzkriterien | ~400 | |
+| — DB-Schema-Definitionen (Feld-Tabellen, Typen) | ~150 | |
+| — F-CORE-01 bis F-CORE-13 (Architekturentscheidungen) | ~100 | |
+| — F-PLUGIN-01/02 (Plugin-System-Architektur) | ~20 | |
+| — F-WF-01 (Workflow-Engine-Architektur) | ~10 | |
+| — Protokoll-Details (RFCs, IMAP, SMTP) | ~80 | |
+| — Technologie-/Library-Wahlen | ~60 | |
+| — Frontend-Komponenten-Namen | ~40 | |
+| — Farbcodes, SQL-Ausdrücke, Algorithmus-Details | ~50 | |
+| — Redundanzen (F-FILE vs F-DMS, F-SCHED vs F-CORE-07) | ~100 | |
+| — Historische/archivierte Requirements (Appendix A) | ~40 | |
+| — Formatierung, Leerzeilen, Trennlinien | ~370 | |
+
+**Fazit:** Die Datei ist zu ~35% eine Requirements-Spec und zu ~65% eine Architektur-/Implementierungs-Dokumentation. Sie hat den Charakter einer Bauanleitung angenommen, nicht den einer Anforderungsspezifikation.
+
+---
+
+## Section 3: Empfehlung
+
+### 3.1 Was in requirements.md bleiben sollte
+
+**Genuine Requirements — das WAS:**
+
+1. **Projektbeschreibung** (Zeilen 10-14) — Was ist das Projekt?
+2. **Domain Knowledge** (Zeilen 17-31) — Fachliche Begriffe und Referenzen
+3. **Tech-Stack-Entscheidungen** (Zeilen 34-52) — Hohe-Level-Entscheidungen (Backend, DB, Frontend, Deployment)
+4. **Feature-Anforderungstexte** — Die „Anforderung:"-Absätze jedes Features, bereinigt um Implementierungsdetails:
+ - F-AUTH-01 bis F-AUTH-08: Was muss die Auth können?
+ - F-COMP-01 bis F-COMP-08: Was muss Firmen-Management können?
+ - F-CONT-01 bis F-CONT-07: Was muss Kontakt-Management können?
+ - F-DATA-01 bis F-DATA-06: Was muss Daten-Management können?
+ - F-UI-01 bis F-UI-08: Was muss die UI bieten?
+ - F-SEC-01 bis F-SEC-03: Welche Sicherheitsanforderungen?
+ - F-INFRA-01 bis F-INFRA-04: Welche Infrastrukturanforderungen?
+ - F-MIG-01: Was muss Migration/Import können?
+ - F-INT-01: Welche Integrationsanforderung?
+ - F-TEST-01: Welche Test-Strategie?
+ - F-ENV-01: Welche Environment-Anforderung?
+ - F-DOC-01: Welche Doku-Anforderung?
+ - F-PERF-01: Welche Performance-Anforderung?
+ - F-SEARCH-01: Was muss die globale Suche können?
+ - F-NAV-01: Welche Navigation?
+ - F-SET-01: Welche Einstellungen?
+ - F-DMS-01 bis F-DMS-07: Was muss DMS können? (ohne Endpunkte)
+ - F-LINK-01 bis F-LINK-06: Was muss Verknüpfung können? (ohne Endpunkte)
+ - F-TAG-01 bis F-TAG-04: Was muss Tagging können? (ohne Endpunkte)
+ - F-PERM-01 bis F-PERM-06: Welche Berechtigungs-Requirements? (ohne Endpunkte)
+ - F-FILEUI-01 bis F-FILEUI-06: Welche UI-Requirements für Datei-Browser? (ohne Komponentennamen)
+ - F-CAL-01 bis F-CAL-18: Was muss Kalender können? (ohne Endpunkte, ohne Farbcodes)
+ - F-MAIL-01 bis F-MAIL-19: Was muss Mail können? (ohne Protokoll-Details)
+ - F-AI-01: Was muss der KI-Copilot können?
+ - F-SCHED-01: Welche Background-Job-Anforderung?
+5. **Test-Szenarien** — Aber bereinigt: nur Verhalten beschreiben („User klickt X → Y passiert"), keine Implementierung („`deleted_at = NOW` gesetzt", „`tsvector`-Index")
+6. **Non-funktionale Anforderungen** (Zeilen 1957-1973) — Bleiben, aber Metriken ohne Library-Namen
+7. **Annahmen** (Zeilen 1976-1999) — Bleiben
+8. **Non-Goals** (Zeilen 2001-2046) — Bleiben
+9. **Discovery-Checkliste** (Zeilen 2049-2073) — Bleibt
+10. **Open Questions** (Zeilen 2077-2085) — Bleibt
+
+### 3.2 Was nach architecture.md verschoben werden sollte
+
+**Architektur/Implementierung — das HOW:**
+
+1. **F-CORE-01 bis F-CORE-13 (Zeilen 864-953):** Komplett in architecture.md
+ - Event Bus, Tenant-Isolation (`tenant_id`), Plugin-Migration, UI-Plugin-Framework, Service Container/DI, API-First (Endpunkt-Versionierung `/api/v1/`), Async Job Queue (Celery/Redis), Caching (Redis), Storage-Backend (S3/MinIO), Import/Export Service, PDF-Gen, Notification Service
+
+2. **F-PLUGIN-01, F-PLUGIN-02 (Zeilen 848-860):** Plugin-System-Architektur → architecture.md
+ - Plugin-Schnittstelle, Manifest-Format, Lifecycle-Hooks, Abhängigkeiten
+
+3. **F-WF-01 (Zeile 812-815):** Workflow-Engine-Architektur → architecture.md
+ - Hybrid-Ansatz, Code-Engine vs. konfigurierbare Regeln
+
+4. **Alle HTTP-Endpunkt-Spezifikationen:** → architecture.md (API-Contract-Sektion)
+ - `POST /api/auth/login`, `GET /api/companies/{id}`, etc.
+ - Request/Response-Body-Formate
+ - Query-Parameter-Spezifikationen
+ - HTTP-Status-Codes
+
+5. **Alle DB-Schema-Definitionen:** → architecture.md (DB-Schema-Sektion)
+ - Feld-Tabellen mit Typen (F-COMP-01 Zeilen 156-186, F-CONT-01 Zeilen 300-333)
+ - Tabellennamen (`audit_log`, `deletion_log`, `company_contacts`, `user_calendar_visibility`)
+ - `tenant_id`-Feld-Spezifikation
+ - `tsvector`-Index-Spezifikation
+
+6. **Protokoll-Details:** → architecture.md
+ - IMAP4rev1, IMAP IDLE, IMAP MOVE, SMTP-Auth
+ - RFC 5545 (RRULE), RFC 5322 (Threading)
+ - PGP-Verschlüsselung (python-gnupg)
+ - DOMPurify-Sanitization
+ - AES-256-Verschlüsselung für Passwörter
+
+7. **Frontend-Komponenten-Architektur:** → architecture.md (Frontend-Architektur-Sektion)
+ - Komponenten-Namen (`CalendarView`, `KanbanCalendar`, `FileBrowser`, `Breadcrumb`, `ContextMenu`, `ThreadView`)
+ - State-Management (`Multi-Select-State`, `user_calendar_visibility`)
+ - HTML5 Drag & Drop API, XMLHttpRequest
+ - Materialized Path Pattern
+
+8. **Farbcodes und UI-Mappings:** → architecture.md oder design-system.md
+ - Hex-Codes für Kalender-Typen
+ - Farb-Mapping-Logik
+
+9. **Algorithmus-Details:** → architecture.md
+ - Mail-Regel-Auswertung
+ - Auto-Reply-Logik (No-Reply-Erkennung, `vacation_sent_log`)
+ - Recurrence-Instanz-Generierung
+ - Thread-Gruppierung
+
+10. **F-FILE-01 bis F-FILE-04 (Zeilen 955-985):** Duplikate von F-DMS/F-PERM — entfernen oder konsolidieren
+11. **F-SCHED-01 (Zeile 784-792):** Duplikat von F-CORE-07 — konsolidieren
+12. **Appendix A: Historische Anforderungen (Zeilen 2089-2128):** In separates `changelog.md` oder entfernen
+
+### 3.3 Wie die Widersprüche (Plugin vs. Core-Feature) aufgelöst werden können
+
+**Option A: Module sind Core-Features (empfohlen für v1/v2)**
+- Entferne F-PLUGIN-01, F-PLUGIN-02, F-CORE-01 bis F-CORE-13 aus requirements.md
+- Module (Mail, Kalender, DMS, Tags) sind Core-Features mit Requirements
+- Plugin-System ist ein Non-Goal für v1/v2 („Plugin-System für spätere Versionen")
+- Vorteil: Konsistent, weniger Komplexität, schneller implementierbar
+- Nachteil: Weniger Erweiterbarkeit
+
+**Option B: Module sind Plugins**
+- Core-Requirements definieren nur Plugin-Schnittstelle und Core-Infrastruktur
+- Plugin-Requirements (Mail, Kalender, DMS) werden in separate Plugin-Specs ausgelagert
+- Core-Requirements sagen: „Das System unterstützt Plugins. Plugin 'Mail' muss X können. Plugin 'Kalender' muss Y können."
+- Die detaillierten Feature-Spezifikationen (F-MAIL-*, F-CAL-*, F-DMS-*) wandern in Plugin-Requirements
+- Vorteil: Saubere Trennung, Erweiterbarkeit
+- Nachteil: Mehr Dokumentation, mehr Komplexität, Over-Engineering für ein Mini-CRM
+
+**Empfehlung: Option A für v1/v2.**
+Ein Mini-CRM mit 10 concurrent Users braucht kein Plugin-System. Das Plugin-System ist ein Architektur-Non-Goal für v1/v2. Die Module werden als Core-Features implementiert. Wenn Erweiterbarkeit später benötigt wird, kann ein Plugin-System in v3+ hinzugefügt werden. F-PLUGIN-01, F-PLUGIN-02, F-CORE-01 bis F-CORE-13 werden zu Non-Goals.
+
+---
+
+## Section 4: Spezifische Konflikte (Tabelle)
+
+| ID/Zeile | Issue | Severity | Vorschlag |
+|----------|-------|----------|-----------|
+| F-PLUGIN-01 (848) vs F-DMS/F-CAL/F-MAIL | Module als Plugins deklariert, aber als Core-Features mit Endpunkten/DB-Schemas spezifiziert | **critical** | Plugin-System als Non-Goal für v1/v2; Module als Core-Features deklarieren |
+| F-FILE-01-04 (955-985) vs F-DMS-01-07 (991-1083) | F-FILE und F-DMS beschreiben dasselbe Modul mit unterschiedlichen IDs. F-FILE-01 (Datei-Explorer) = F-DMS-01 (Ordner-Struktur), F-FILE-03 (PDF-Preview) = F-DMS-04, F-FILE-04 (OnlyOffice) = F-DMS-05 | **critical** | F-FILE-01 bis F-FILE-04 entfernen; durch F-DMS-Referenzen ersetzen |
+| F-FILE-03 (973) vs F-DMS-04 (1033) | Beide spezifizieren PDF-Preview im Browser — Duplikat | **critical** | F-FILE-03 entfernen; F-DMS-04 behalten (detaillierter) |
+| F-FILE-04 (982) vs F-DMS-05 (1047) | Beide spezifizieren OnlyOffice-Integration — Duplikat | **critical** | F-FILE-04 entfernen; F-DMS-05 behalten (detaillierter) |
+| F-FILE-02 (964) vs F-PERM-03/04 (1257-1279) | F-FILE-02 (Datei-Sharing) ist vereinfachte Version von F-PERM-03/04 — Redundanz | **warning** | F-FILE-02 entfernen; F-PERM-03/04 als maßgeblich deklarieren |
+| F-SCHED-01 (784) vs F-CORE-07 (906) | Beide beschreiben Background-Jobs/Async-Queue — F-SCHED-01 ist vereinfachte Version von F-CORE-07 | **warning** | F-SCHED-01 entfernen; F-CORE-07 in architecture.md verschieben; Requirement „lange Operationen als Background-Job" in requirements.md behalten |
+| F-DATA-01/02 (430-452) vs F-CORE-11 (934) | CSV/Excel-Export (F-DATA) überlappt mit Generic Import/Export Service (F-CORE-11) | **warning** | F-CORE-11 in architecture.md; F-DATA-01/02 in requirements.md behalten (das WAS); F-CORE-11 beschreibt das HOW |
+| F-AUTH-07 (135) vs F-AUTH-01-F-CONT-07 (57-410) | Multi-Tenant deklariert, aber frühe Requirements erwähnen Tenant-Kontext nicht | **warning** | Frühe Requirements um Tenant-Bezug ergänzen: „Firma wird dem aktiven Tenant zugeordnet", „Suche ist Tenant-gefiltert" |
+| F-AUTH-01 (58) vs F-AUTH-02 (72-78) | F-AUTH-01: „Session-basiert", F-AUTH-02: „Token wird entfernt", „Server-Token-Blacklist" — inkonsistente Terminologie | **warning** | Einheitlich „Session" verwenden; Token-Blacklist entfernen oder klar als Session-Invalidierung benennen |
+| F-SEC-03 (616) vs F-AUTH-01 (58) | F-SEC-03 spricht von „Token" („Token gültig <8h", „Token nach 8h → 401"), F-AUTH-01 von „Session-Cookie" | **warning** | Einheitlich Session-basiert formulieren; „Session läuft nach 8h ab" |
+| F-CORE-06 (899) vs F-UI-01-06 (495-573) | API-First („alle Features über API") vs. reinen UI-Features ohne API-Bezug (Toast, Loading-States, Empty-States) | **warning** | F-CORE-06 einschränken: „Alle Daten- und Funktions-Features über API nutzbar; reine UI-Präsentations-Features (Loading-States, Toasts) ausgenommen" |
+| F-AUTH-06 (126) vs F-AUTH-04 (98) | F-AUTH-06 (Multi-User mit Rollen) überlappt mit F-AUTH-04 (RBAC) — F-AUTH-06 ist detailliertere Version | **warning** | Zusammenführen oder F-AUTH-06 als Erweiterung von F-AUTH-04 kennzeichnen |
+| F-AUTH-08 (144) vs F-AUTH-04/06 (98-129) | F-AUTH-08 (Feld-Ebene-Granularität) erweitert F-AUTH-04/06, wird aber nicht kreuzreferenziert | **warning** | F-AUTH-08 als Unterpunkt von F-AUTH-04/06 integrieren oder explizit referenzieren |
+| F-SEARCH-01 (821) vs F-COMP-06 (255)/F-CONT-06 (402) | Globale Suche überlappt mit Firmen-/Kontakt-Suche — keine klare Abgrenzung | **warning** | F-SEARCH-01 als übergeordnete Suche deklarieren; F-COMP-06/F-CONT-06 als Modul-Suche mit Querverweis |
+| F-INT-01 (700) vs F-MAIL-02 (1683) | E-Mail-Integration für Passwort-Reset (F-INT-01) ist Subset des vollen Mail-Moduls (F-MAIL-02) | **info** | F-INT-01 als v1-Requirement behalten; F-MAIL-02 als v2-Erweiterung kennzeichnen; F-INT-01 bei F-MAIL-02 referenzieren |
+| F-CAL-10 (1536) vs Non-Goals (2028) | F-CAL-10 (Ressourcen-Booking) als „Optional für später (post-v2)" markiert, hat aber volle Test-Szenarien und Akzeptanzkriterien | **warning** | Entweder zu Non-Goals verschieben oder als v2-Feature belassen mit klarer Markierung „post-v2" |
+| F-COMP-01 Feldtabelle (156-186) | DB-Schema mit Typen (String(100), Integer, Decimal) in Requirements | **info** | Feldliste als „Felder, die erfasst werden" in requirements.md; Typen und Constraints in architecture.md |
+| F-CONT-01 Feldtabelle (300-333) | DB-Schema mit Typen in Requirements | **info** | Analog zu F-COMP-01 |
+| F-COMP-04 (235) | `deleted_at = NOW` (SQL-Ausdruck) in Akzeptanzkriterium | **info** | „Firma wird als gelöscht markiert (Soft-Delete)" — ohne SQL |
+| F-CONT-07 (424) | `company_contacts` Tabellenname in Akzeptanzkriterium | **info** | „N:M-Verknüpfung wird erstellt" — ohne Tabellennamen |
+| F-CAL-06 (1485) | Hex-Farbcodes in Akzeptanzkriterium | **info** | „Farbe wird basierend auf Typ zugeordnet" — Farbwerte in design-system.md |
+| F-CAL-08 (1516) | RRULE (RFC 5545) in Akzeptanzkriterium | **info** | „Wiederholungsmuster werden unterstützt" — RFC-Referenz in architecture.md |
+| F-MAIL-03 (1709) | `tsvector`-Index in Akzeptanzkriterium | **info** | „Volltext-Suche über alle Mails" — Index-Strategie in architecture.md |
+| F-MAIL-01 (1677) | „IMAP IDLE-Listener läuft als Background-Task" in Akzeptanzkriterium | **info** | „Neue Mails werden innerhalb von 5 Sekunden angezeigt" — Implementierung in architecture.md |
+| F-MAIL-02 (1693) | „DOMPurify" in Akzeptanzkriterium | **info** | „HTML wird sanitisiert" — Library in architecture.md |
+| F-MAIL-12 (1846) | „python-gnupg" in Akzeptanzkriterium | **info** | „PGP-Verschlüsselung wird unterstützt" — Library in architecture.md |
+| F-FILEUI-01 (1321) | `FileBrowser`, `SidebarTree`, `MainView` Komponentennamen | **info** | „Datei-Browser mit Baum-Ansicht und Hauptbereich" — Komponentennamen in architecture.md |
+| F-FILEUI-02 (1335) | „Materialized Path oder rekursive Abfrage" in Akzeptanzkriterium | **info** | „Pfad wird aus Ordner-Hierarchie generiert" — Pattern in architecture.md |
+| F-FILEUI-06 (1391) | „HTML5 Drag & Drop API" in Akzeptanzkriterium | **info** | „Drag & Drop wird unterstützt" — API in architecture.md |
+| F-FILEUI-05 (1377) | „XMLHttpRequest oder WebSocket" in Akzeptanzkriterium | **info** | „Upload-Progress wird angezeigt" — Technologie in architecture.md |
+| F-CORE-07 (907) | „Celery + Redis oder RQ + Redis" — Technologie-Wahl in Requirements | **info** | Komplett in architecture.md |
+| F-CORE-08 (914) | „Redis als Cache-Backend" — Technologie-Wahl in Requirements | **info** | Komplett in architecture.md |
+| F-CORE-10 (928) | „S3-kompatibles Storage (z.B. MinIO)" — Technologie-Wahl in Requirements | **info** | Komplett in architecture.md |
+| F-CORE-02 (872) | `tenant_id`-Feld-Spezifikation in Requirements | **info** | „Daten sind pro Tenant isoliert" — `tenant_id` in architecture.md |
+| DISCOVERY_CHECK (2131) | Behauptet `features_with_ids=127/127` — tatsächlich sind es ~141 aktive Feature-IDs | **warning** | Zählung korrigieren oder klären, welche Features gezählt wurden |
+| F-DATA-05 fehlt | Springt von F-DATA-04 (Zeile 472) zu F-DATA-06 (Zeile 481) — F-DATA-05 existiert nicht | **info** | Entweder F-DATA-05 nachtragen oder Nummerierung korrigieren |
+| F-UI-07 fehlt | Springt von F-UI-06 (Zeile 565) zu F-UI-08 (Zeile 579) — F-UI-07 existiert nicht | **info** | Entweder F-UI-07 nachtragen oder Nummerierung korrigieren |
+| F-COMP-07 (269) vs F-COMP-08 (283) | Audit-Log und DSGVO-Löschung haben überlappende Belange (beide behandeln Logging von Löschungen), Interaktion nicht dokumentiert | **info** | Klarstellen: Audit-Log = schreibende Aktionen; DSGVO-Löschung = harte Löschung inkl. Audit-Log-Einträgen, separate `deletion_log` |
+| NF-06 (1966) | Code-Struktur (`api/`, `models/`, `schemas/`, `services/`, `tests/`) in nicht-funktionaler Anforderung | **info** | In architecture.md verschieben; in requirements.md: „Code-Struktur ist klar getrennt" |
+| Appendix A (2089-2128) | Historische v0.1-Requirements mit veralteten Tech-Stack (Jinja2, SQLite, Python 3.11) | **info** | In `changelog.md` verschieben oder entfernen; verwirrend in requirements.md |
+
+---
+
+## Zusammenfassung
+
+| Metrik | Wert |
+|--------|------|
+| Gesamtzeilen | 2131 |
+| Aktive Feature-IDs | ~141 |
+| Genuine Requirements-Anteil | ~35% |
+| Architektur/Implementierungs-Anteil | ~65% |
+| Critical Issues | 4 |
+| Warning Issues | 14 |
+| Info Issues | 21 |
+| Empfehlung | Requirements bereinigen, ~65% nach architecture.md verschieben, Plugin-System als Non-Goal für v1/v2 |
+
+**Urteil:** Die Datei ist eine Mischung aus Requirements-Spec und Architektur-Dokument. Sie hat den Charakter einer Bauanleitung angenommen. Für eine saubere Trennung sollten ~65% des Inhalts in architecture.md verschoben werden. Die verbleibende requirements.md sollte nur das WAS beschreiben — nicht das HOW.
diff --git a/docs/requirements.md b/docs/requirements.md
new file mode 100644
index 0000000..b8b95b2
--- /dev/null
+++ b/docs/requirements.md
@@ -0,0 +1,2142 @@
+# leocrm — Mini-CRM Requirements
+
+**Projekt:** leocrm
+**Phase:** 1 — Discovery
+**Datum:** 2026-06-28
+**Status:** Bereinigt — ready_for_ui
+
+---
+
+## 1. Projektbeschreibung
+
+Mini-CRM mit Login, Rollen-Rechten, Firmen und Kontaktpersonen. Multi-Tenant (Multi-Company) für v1.
+Ziel: Eine überschaubare CRM-Anwendung, die Firmen und Kontaktpersonen mit N:M-Beziehung verwaltet, mit Suche, Filter, Export und Mehrsprachigkeit. Das System ist Plugin-basiert erweiterbar — Mail, Kalender, DMS und Tags werden als Plugins realisiert.
+
+---
+
+## 2. Domain Knowledge
+
+**Domain:** Customer Relationship Management (CRM)
+
+Standard-Entitäten in CRMs (Referenz: Zoho CRM, HubSpot, Salesforce):
+- **Accounts (Firmen):** Name, Adresse, Industrie, Employees, Revenue, Owner, Phone, Website, Billing/Shipping Address
+- **Contacts (Kontaktpersonen):** Name, Email, Phone, Mobile, Title, Department, Mailing Address, Reports To, Description
+- **Beziehungen:** N:M (ein Kontakt kann mehreren Firmen zugeordnet sein)
+
+Quellen:
+- Zoho CRM Standard Fields Accounts: https://help.zoho.com/portal/en/kb/crm/sales-force-automation/accounts/articles/standard-fields-accounts
+- Zoho CRM Standard Fields Contacts: https://help.zoho.com/portal/en/kb/crm/sales-force-automation/contacts/articles/standard-fields-contacts
+- Encore Business Solutions — 30 CRM Custom Account Fields
+- Bitrix24 Standard fields in CRM
+
+---
+
+## 3. Tech-Stack (Constraints)
+
+| Komponente | Entscheidung | Bemerkung |
+|------------|-------------|----------|
+| Backend | FastAPI | Python |
+| Datenbank | PostgreSQL | Multi-User, Concurrent Writes, 200k Datensätze |
+| Frontend | React SPA | Client-side rendering, i18n bestätigt durch Prototyp |
+| Deployment | Coolify (Docker) | Bestätigt |
+| Testing | pytest + Vitest + Playwright | Backend + Frontend + E2E |
+
+> **Hinweis:** Spezifische Bibliotheken, Versionen und Infrastruktur-Komponenten werden in architecture.md durch den Solution Architect festgelegt. Siehe `extracted-architecture-details.md` für entfernte Implementierungs-Details.
+
+---
+
+## 4. Funktionale Anforderungen
+
+### F-AUTH-01: Login [v1]
+**Anforderung:** User kann sich mit E-Mail und Passwort einloggen. Session-basierte Auth mit sicherem Cookie (HttpOnly, Secure, SameSite=Strict). Daten sind pro Tenant isoliert — Login bestimmt den aktiven Tenant-Kontext.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User gibt korrekte E-Mail + Passwort ein → Login erfolgreich, Session-Cookie wird gesetzt, Weiterleitung zum Dashboard. Tenant-Kontext wird geladen.
+2. **Edge Case:** User gibt falsches Passwort ein → Fehler-Toast „Anmeldedaten ungültig", kein Cookie, kein Redirect.
+3. **Edge Case:** User gibt nicht-existente E-Mail ein → gleiche Fehlermeldung (kein User-Enumeration).
+
+**Akzeptanzkriterium:** Login akzeptiert E-Mail + Passwort, validiert, setzt Session-Cookie oder gibt Fehler zurück. Kein User-Enumeration.
+
+---
+
+### F-AUTH-02: Logout [v1]
+**Anforderung:** User kann sich ausloggen. Session wird serverseitig invalidiert und clientseitig gelöscht.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt „Abmelden" → Session wird beendet, Weiterleitung zur Login-Seite.
+2. **Edge Case:** User ohne gültige Session versucht Logout → Weiterleitung zur Login-Seite ohne Fehler.
+
+**Akzeptanzkriterium:** Logout beendet die Session zuverlässig; clientseitige Session-Daten werden gelöscht.
+
+---
+
+### F-AUTH-03: User-Verwaltung (Admin legt User an) [v1]
+**Anforderung:** Admin kann neue User anlegen (E-Mail, Name, Rolle, initiales Passwort). Keine Self-Registration. User wird einem Tenant zugeordnet.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin legt User mit E-Mail, Name, Rolle „editor" und Passwort an → User erscheint in User-Liste, User kann sich einloggen.
+2. **Edge Case:** Admin versucht User mit bereits existierender E-Mail anzulegen → Fehler „E-Mail bereits vergeben".
+3. **Edge Case:** Nicht-Admin versucht User anzulegen → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Admin kann User anlegen und Tenant zuordnen; Nicht-Admins haben keinen Zugriff auf User-Verwaltung.
+
+---
+
+### F-AUTH-04: Rollen-basierte Zugriffskontrolle (RBAC) [v1]
+**Anforderung:** Mehrere Rollen mit verschiedenen Rechten. Mindestens: admin (alles), editor (CRUD Firmen/Kontakte), viewer (nur lesen). Rechte gelten pro Tenant.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin kann alle Aktionen ausführen (User anlegen, Firmen/Kontakte CRUD, Export).
+2. **Integration:** Editor kann Firmen/Kontakte anlegen/bearbeiten, aber keine User verwalten → Zugriff verweigert.
+3. **Integration:** Viewer kann nur lesen → Schreibversuch wird verweigert, Lesen funktioniert.
+
+**Akzeptanzkriterium:** Jede Aktion prüft Rolle und Tenant-Zugehörigkeit; falsche Rolle → Zugriff verweigert.
+
+---
+
+### F-AUTH-05: Passwort-Reset [v1]
+**Anforderung:** User kann Passwort-Reset anfordern. Reset-Link per E-Mail. User setzt neues Passwort über Link.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt „Passwort vergessen", gibt E-Mail ein → E-Mail mit Reset-Link wird gesendet → User klickt Link, gibt neues Passwort ein → Login mit neuem Passwort funktioniert.
+2. **Edge Case:** User gibt nicht-existente E-Mail ein → gleiche Erfolgsmeldung (kein Enumeration).
+3. **Edge Case:** Reset-Link abgelaufen (>24h) → Fehler „Link abgelaufen", neuer Link nötig.
+
+**Akzeptanzkriterium:** Reset-Flow funktioniert end-to-end; keine User-Enumeration; abgelaufene Links werden abgelehnt.
+
+---
+
+### F-AUTH-06: Multi-User mit Rollen und Rechten [v1]
+**Anforderung:** Mehrere Rollen mit verschiedenen Rechten, anpassbar. Admin legt User an. Rollen bestimmen Sichtbarkeit und Bearbeitungsrechte pro Modul. Gilt pro Tenant.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin erstellt neue Rolle „Sales" mit Leserecht auf Firmen, Schreibrecht auf Kontakte → User mit Rolle „Sales" kann Kontakte bearbeiten, Firmen nur lesen.
+2. **Edge Case:** User ohne Rolle versucht Zugriff → Zugriff verweigert.
+3. **Integration:** Rollen-Editor zeigt alle Module mit Rechten pro Rolle → Änderungen werden sofort wirksam.
+
+**Akzeptanzkriterium:** Rollen-Editor vorhanden, pro Rolle pro Modul Rechte (read/write/delete/admin), User wird Rolle zugewiesen, Rechte werden pro Tenant durchgesetzt.
+
+---
+
+### F-AUTH-07: Multi-Tenant (Multi-Company) [v1]
+**Anforderung:** Das System ist Multi-Tenant-fähig. Mehrere Firmen (Tenants) können im System verwaltet werden. Daten sind pro Tenant isoliert. Ein User kann zu mehreren Tenants gehören.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User gehört zu Tenant A und B → switcht zu Tenant B → sieht nur Daten von Tenant B, keine Daten von Tenant A.
+2. **Edge Case:** User versucht Daten von Tenant A while active Tenant is B → Cross-Tenant-Access wird verweigert.
+3. **Integration:** Admin erstellt neuen Tenant, weist User zu → User sieht Tenant in Auswahlliste, kann dorthin switchen.
+
+**Akzeptanzkriterium:** Tenant-Erstellung, User-Tenant-Zuordnung, Daten-Isolation pro Tenant, Tenant-Switch in der UI.
+
+---
+
+### F-AUTH-08: Granulare Rechte auf Feld-Ebene [v1]
+**Anforderung:** Rechte-System mit Feld-Level-Granularität. Pro Rolle kann definiert werden, welche Felder sichtbar, bearbeitbar oder ausgeblendet sind. Nicht nur Modul-Level, sondern bis auf einzelne Felder herunter.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin setzt Feld „annual_revenue" für Rolle „viewer" auf „hidden" → Viewer sieht das Feld nicht in Firmen-Detail und -Liste.
+2. **Edge Case:** Admin setzt Feld „phone" für Rolle „editor" auf „read-only" → Editor kann Firma bearbeiten, aber Telefonnummer nicht ändern.
+3. **Integration:** Feld-Level-Rechte gelten für Firmen, Kontakte und alle Plugin-Entitäten mit Feldern.
+
+**Akzeptanzkriterium:** Rollen-Editor mit Feld-Level-Rechten, pro Feld: read/write/hidden, gilt für Core- und Plugin-Entitäten.
+
+---
+
+### F-COMP-01: Firma anlegen [v1]
+**Anforderung:** User mit Rolle admin/editor kann eine neue Firma anlegen mit allen Pflicht- und Optionalfeldern. Firma wird im aktiven Tenant-Kontext erstellt.
+
+**Felder (basierend auf CRM-Standard, Zoho/Salesforce Referenz):**
+
+| Feld | Pflicht | Bemerkung |
+|------|---------|-----------|
+| Name | ✅ | Firmenname |
+| Account-Nummer | ❌ | Interne Referenznummer |
+| Branche | ❌ | Auswahlliste (IT, Finance, Manufacturing, etc.) |
+| Account-Typ | ❌ | Auswahlliste (Customer, Partner, Prospect, etc.) |
+| Eigentümer | ❌ | Auswahlliste (Public, Private, Government, etc.) |
+| Mitarbeiterzahl | ❌ | Zahl |
+| Jahresumsatz | ❌ | Zahl |
+| Telefon | ❌ | Haupttelefon |
+| Fax | ❌ | Fax |
+| E-Mail | ❌ | Allgemeine E-Mail |
+| Website | ❌ | URL |
+| Rating | ❌ | Auswahlliste (Hot, Warm, Cold) |
+| Muttergesellschaft | ❌ | Referenz auf andere Firma |
+| Rechnungsadresse | ❌ | Strasse, Stadt, Bundesland, PLZ, Land |
+| Besuchsadresse | ❌ | Strasse, Stadt, Bundesland, PLZ, Land |
+| Beschreibung | ❌ | Freitext-Notizfeld |
+| SIC-Code | ❌ | Standard Industrial Classification |
+| Börsenkürzel | ❌ | Ticker-Symbol |
+| Standort-Name | ❌ | z.B. Headquarters |
+
+**Test Scenarios:**
+1. **Happy Path:** User füllt Name (Pflicht) + optionale Felder aus → Firma wird angelegt, erscheint in Liste.
+2. **Edge Case:** User versucht Firma ohne Name anzulegen → Validierungsfehler „Name ist Pflichtfeld".
+3. **Edge Case:** Viewer versucht Firma anzulegen → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Firma mit allen Pflichtfeldern wird erfolgreich erstellt. Ohne Pflichtfelder wird Validierungsfehler zurückgegeben. Nur admin/editor dürfen anlegen.
+
+---
+
+### F-COMP-02: Firma anzeigen [v1]
+**Anforderung:** User kann Details einer Firma ansehen, inklusive zugeordneter Kontaktpersonen. Nur Daten des aktiven Tenants werden angezeigt.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt auf Firma in Liste → Detail-Seite zeigt alle Felder + zugeordnete Kontakte.
+2. **Edge Case:** Firma hat keine zugeordneten Kontakte → Empty-State „Keine Kontakte zugeordnet".
+3. **Edge Case:** User versucht nicht-existente Firma-ID → „Nicht gefunden".
+
+**Akzeptanzkriterium:** Detail-Ansicht zeigt alle Felder und zugeordnete Kontakte; nicht-existente Firma → Fehlermeldung.
+
+---
+
+### F-COMP-03: Firma bearbeiten [v1]
+**Anforderung:** User mit Rolle admin/editor kann eine Firma bearbeiten.
+
+**Test Scenarios:**
+1. **Happy Path:** User ändert Telefonnummer → Änderung wird gespeichert, in Detail-Ansicht sichtbar.
+2. **Edge Case:** User versucht Name zu leeren → Validierungsfehler „Name ist Pflichtfeld".
+3. **Edge Case:** Viewer versucht Bearbeitung → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Änderungen an Firmen werden gespeichert; Validierungsfehler bei fehlenden Pflichtfeldern; nur admin/editor dürfen bearbeiten.
+
+---
+
+### F-COMP-04: Firma löschen (Soft-Delete mit User-Choice) [v1]
+**Anforderung:** User mit Rolle admin/editor kann Firma löschen. Soft-Delete (recoverable). Vor Löschung: User-Dialog — Kontakte mit löschen (Soft-Delete) oder als Kontakte ohne Firma belassen.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt „Löschen" → Dialog erscheint: „Kontakte mit löschen oder behalten?" → User wählt „Behalten" → Firma wird soft-deleted, Kontakte bleiben sichtbar ohne Firmen-Zuordnung.
+2. **Edge Case:** User wählt „Mit löschen" → Firma + zugeordnete Kontakte werden soft-deleted.
+3. **Edge Case:** Viewer versucht Löschung → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Soft-Delete funktioniert; User-Dialog bietet Wahl zwischen Cascade-Delete und Behalten; nur admin/editor dürfen löschen.
+
+---
+
+### F-COMP-05: Firmen-Liste mit Pagination & Sortierung [v1]
+**Anforderung:** Firmen werden paginiert angezeigt (Default: 25 pro Seite). Sortierung nach Name, Branche, Erstellt-Datum (auf/absteigend). Nur Firmen des aktiven Tenants.
+
+**Test Scenarios:**
+1. **Happy Path:** 100 Firmen in DB → Seite 1 zeigt 25 Firmen, Seite 2 zeigt 25, etc. Pagination-Controls sichtbar.
+2. **Integration:** User sortiert nach Name absteigend → Firmen werden Z→A sortiert.
+3. **Edge Case:** Letzte Seite hat <25 Einträge → zeigt nur verbleibende, keine leeren Zeilen.
+
+**Akzeptanzkriterium:** Pagination funktioniert (page, page_size); Sortierung nach verfügbaren Spalten; Response enthält items, total, page, page_size.
+
+---
+
+### F-COMP-06: Firmen-Suche & Filter [v1]
+**Anforderung:** Einfache Text-Suche (über Name, E-Mail, Telefon, Stadt) UND strukturierte Filter (Branche, Account-Typ, Land, Rating).
+
+**Test Scenarios:**
+1. **Happy Path:** User gibt „Tech" in Suchfeld ein → alle Firmen mit „Tech" in Name/Beschreibung erscheinen.
+2. **Integration:** User filtert nach Branche=IT + Land=Deutschland → nur IT-Firmen in Deutschland.
+3. **Edge Case:** Suche ohne Treffer → Empty-State „Keine Firmen gefunden".
+
+**Akzeptanzkriterium:** Text-Suche und strukturierte Filter kombinierbar; Ergebnisse sind paginiert; Empty-State bei keinen Treffern.
+
+---
+
+### F-COMP-07: Audit-Log [v1]
+**Anforderung:** Wichtige Aktionen werden geloggt: User-Login, Create/Edit/Delete von Firmen und Kontakten. Log enthält: User, Aktion, Entity, Timestamp. Pro Tenant isoliert.
+
+**Test Scenarios:**
+1. **Happy Path:** Admin erstellt Firma → Audit-Log-Eintrag wird erstellt (User, Aktion, Entity, Timestamp).
+2. **Integration:** Editor löscht Kontakt → Audit-Log-Eintrag mit Soft-Delete-Vermerk.
+3. **Edge Case:** Viewer liest Firma → kein Audit-Log-Eintrag (nur schreibende Aktionen werden geloggt).
+
+**Akzeptanzkriterium:** Audit-Log für schreibende Aktionen; Einträge enthalten User, Aktion, Entity, Timestamp; Admin kann Audit-Log paginiert einsehen; pro Tenant isoliert.
+
+---
+
+### F-COMP-08: DSGVO / Datenaufbewahrung [v1]
+**Anforderung:** DSGVO-Konformität: User können alle Daten einer Person einsehen und komplett löschen (Right to be Forgotten). Löschkonzept dokumentiert.
+
+**Test Scenarios:**
+1. **Happy Path:** Admin klickt „Person komplett löschen (DSGVO)" → Kontakt + alle Verknüpfungen + Audit-Log-Einträge werden hart gelöscht (nicht soft-delete).
+2. **Edge Case:** Kontakt war 3 Firmen zugeordnet → N:M-Einträge werden hart gelöscht, Firmen bleiben bestehen.
+3. **Integration:** Separate unveränderliche Lösch-Log-Tabelle dokumentiert die DSGVO-Löschung.
+
+**Akzeptanzkriterium:** DSGVO-Löschung entfernt alle personenbezogenen Daten hart; separate unveränderliche Lösch-Log-Tabelle dokumentiert die Löschung.
+
+---
+
+### F-CONT-01: Kontaktperson anlegen [v1]
+**Anforderung:** User mit Rolle admin/editor kann Kontaktperson anlegen. Kann 0..n Firmen zugeordnet werden. Kontakt wird im aktiven Tenant-Kontext erstellt.
+
+**Felder (basierend auf CRM-Standard, Zoho/Salesforce Referenz):**
+
+| Feld | Pflicht | Bemerkung |
+|------|---------|-----------|
+| Vorname | ❌ | Vorname |
+| Nachname | ✅ | Nachname |
+| Anrede | ❌ | Auswahlliste (Herr, Frau, Dr., etc.) |
+| E-Mail | ❌ | Haupt-E-Mail |
+| Zweit-E-Mail | ❌ | Weitere E-Mail |
+| Telefon | ❌ | Bürotelefon |
+| Mobil | ❌ | Mobiltelefon |
+| Privattelefon | ❌ | Privat |
+| Fax | ❌ | Fax |
+| Jobtitel | ❌ | z.B. CEO, Manager |
+| Abteilung | ❌ | Abteilung |
+| Vorgesetzter | ❌ | Referenz auf anderen Kontakt |
+| Geburtsdatum | ❌ | Datum |
+| Assistent | ❌ | Name |
+| Assistent-Telefon | ❌ | Telefon |
+| Postadresse | ❌ | Strasse, Stadt, Bundesland, PLZ, Land |
+| Andere Adresse | ❌ | Strasse, Stadt, Bundesland, PLZ, Land |
+| Skype | ❌ | Skype-ID |
+| LinkedIn | ❌ | URL |
+| Twitter | ❌ | Handle |
+| Beschreibung | ❌ | Freitext-Notizfeld |
+| Firmen-Zuordnungen | ❌ | N:M-Zuordnung (0..n Firmen) |
+
+**Test Scenarios:**
+1. **Happy Path:** User legt Kontakt mit Nachname + E-Mail + 2 Firmen-Zuordnungen an → Kontakt wird erstellt, erscheint in beiden Firmen-Detailseiten.
+2. **Edge Case:** User legt Kontakt ohne Nachname an → Validierungsfehler „Nachname ist Pflichtfeld".
+3. **Edge Case:** User legt Kontakt ohne Firmen-Zuordnung an → Kontakt wird erstellt, erscheint in Kontakt-Liste ohne Firmen-Link.
+
+**Akzeptanzkriterium:** Kontakt mit Pflichtfeldern wird erstellt; N:M-Zuordnungen zu Firmen funktionieren; Validierung bei fehlenden Pflichtfeldern.
+
+---
+
+### F-CONT-02: Kontaktperson anzeigen [v1]
+**Anforderung:** User kann Details eines Kontakts ansehen, inklusive zugeordneter Firmen.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt auf Kontakt → Detail-Seite zeigt alle Felder + zugeordnete Firmen.
+2. **Edge Case:** Kontakt ohne Firmen → Empty-State „Keine Firmen zugeordnet".
+3. **Edge Case:** Nicht-existente Kontakt-ID → „Nicht gefunden".
+
+**Akzeptanzkriterium:** Detail-Ansicht zeigt alle Felder und zugeordnete Firmen; nicht-existenter Kontakt → Fehlermeldung.
+
+---
+
+### F-CONT-03: Kontaktperson bearbeiten [v1]
+**Anforderung:** User mit Rolle admin/editor kann Kontaktdaten bearbeiten und Firmen-Zuordnungen ändern.
+
+**Test Scenarios:**
+1. **Happy Path:** User ändert Jobtitel → Speichern → Änderung sichtbar.
+2. **Integration:** User fügt neue Firmen-Zuordnung hinzu → Kontakt erscheint in deren Firmen-Detailseite.
+3. **Edge Case:** Viewer versucht Bearbeitung → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Änderungen an Kontaktdaten und Firmen-Zuordnungen werden gespeichert; nur admin/editor dürfen bearbeiten.
+
+---
+
+### F-CONT-04: Kontaktperson löschen (Soft-Delete) [v1]
+**Anforderung:** User mit Rolle admin/editor kann Kontakt soft-deleten. N:M-Verknüpfungen werden entfernt (Firma bleibt bestehen).
+
+**Test Scenarios:**
+1. **Happy Path:** User löscht Kontakt → Kontakt wird als gelöscht markiert, nicht mehr in Listen sichtbar, Firmen bleiben unberührt.
+2. **Edge Case:** Kontakt war 3 Firmen zugeordnet → nach Löschung: Firmen existieren weiter, N:M-Einträge entfernt.
+3. **Edge Case:** Viewer versucht Löschung → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Soft-Delete markiert Kontakt als gelöscht; N:M-Einträge werden entfernt; Firmen bleiben unberührt; nur admin/editor dürfen löschen.
+
+---
+
+### F-CONT-05: Kontakt-Liste mit Pagination & Sortierung [v1]
+**Anforderung:** Kontakte werden paginiert (Default: 25 pro Seite). Sortierung nach Name, E-Mail, Erstellt-Datum. Nur Kontakte des aktiven Tenants.
+
+**Test Scenarios:**
+1. **Happy Path:** 200k Kontakte in DB → Seite 1 lädt <500ms, zeigt 25 Kontakte, Pagination zeigt 8000 Seiten.
+2. **Integration:** User sortiert nach Nachname aufsteigend → A→Z sortiert.
+3. **Edge Case:** Seite jenseits der Daten → Empty-Result, keine Fehler.
+
+**Akzeptanzkriterium:** Pagination funktioniert bei 200k Datensätzen; Response-Zeit <500ms; Sortierung nach verfügbaren Spalten.
+
+---
+
+### F-CONT-06: Kontakt-Suche & Filter [v1]
+**Anforderung:** Text-Suche (Name, E-Mail, Telefon, Firma) UND strukturierte Filter (Firma, Abteilung, Land).
+
+**Test Scenarios:**
+1. **Happy Path:** User sucht „Müller" → alle Kontakte mit Nachname/Vorname „Müller" erscheinen.
+2. **Integration:** User filtert nach Firma=ACME → nur Kontakte, die ACME zugeordnet sind.
+3. **Edge Case:** Keine Treffer → Empty-State.
+
+**Akzeptanzkriterium:** Text-Suche und strukturierte Filter kombinierbar; Ergebnisse sind paginiert; Empty-State bei keinen Treffern.
+
+---
+
+### F-CONT-07: N:M Firmen-Kontakt-Zuordnung [v1]
+**Anforderung:** Ein Kontakt kann mehreren Firmen zugeordnet werden (N:M). Eine Firma kann mehrere Kontakte haben. Zuordnung kann beim Anlegen/Bearbeiten von Kontakt oder Firma erfolgen.
+
+**Test Scenarios:**
+1. **Happy Path:** Kontakt wird 3 Firmen zugeordnet → in jeder Firmen-Detailseite erscheint der Kontakt.
+2. **Integration:** Zuordnung wird entfernt → Kontakt erscheint nicht mehr in Firmen-Detailseite, beide Entitäten bleiben bestehen.
+3. **Edge Case:** Kontakt ohne Firmen-Zuordnung → existiert unabhängig, erscheint in Kontakt-Liste ohne Firmen-Link.
+
+**Akzeptanzkriterium:** N:M-Zuordnung funktioniert in beide Richtungen; Zuordnung kann hinzugefügt und entfernt werden; Entitäten bleiben bei Trennung bestehen.
+
+---
+
+### F-DATA-01: CSV-Export [v1]
+**Anforderung:** User kann Firmen und/oder Kontakte als CSV exportieren. Export berücksichtigt aktuelle Filter.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt „CSV-Export" bei gefilterter Firmen-Liste → CSV-Datei mit nur gefilterten Firmen wird heruntergeladen.
+2. **Integration:** Export aller Kontakte (200k) → CSV wird generiert, Download startet, Datei enthält alle Datensätze.
+3. **Edge Case:** Export mit 0 Datensätzen → CSV mit nur Header-Zeile.
+
+**Akzeptanzkriterium:** CSV-Export berücksichtigt aktive Filter; Download funktioniert; leere Menge ergibt CSV mit nur Header.
+
+---
+
+### F-DATA-02: Excel-Export [v1]
+**Anforderung:** User kann Firmen und/oder Kontakte als Excel exportieren. Export berücksichtigt aktuelle Filter.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt „Excel-Export" → Excel-Datei wird heruntergeladen, in Excel öffnbar.
+2. **Integration:** Export aller Kontakte → Excel-Datei mit allen Datensätzen, Spalten-Header korrekt.
+3. **Edge Case:** Export mit 0 Datensätzen → Excel-Datei mit nur Header.
+
+**Akzeptanzkriterium:** Excel-Export berücksichtigt aktive Filter; Datei ist in Excel öffnbar; leere Menge ergibt Datei mit nur Header.
+
+---
+
+### F-DATA-03: Daten-Validierung [v1]
+**Anforderung:** Alle Eingaben werden serverseitig validiert. E-Mail-Format, Pflichtfelder, Längen-Limits.
+
+**Test Scenarios:**
+1. **Happy Path:** User gibt gültige E-Mail ein → wird akzeptiert.
+2. **Edge Case:** User gibt ungültige E-Mail ein → Validierungsfehler mit Feld-Hinweis.
+3. **Edge Case:** User gibt zu langen Text in Name-Feld ein → Validierungsfehler.
+
+**Akzeptanzkriterium:** Serverseitige Validierung für alle Eingaben; ungültige Eingaben → Validierungsfehler mit detailierter Fehlermeldung.
+
+---
+
+### F-DATA-04: PostgreSQL als Datenbank [v1]
+**Anforderung:** PostgreSQL als Datenbank — wegen der globalen Suche und Multi-User-Concurrent-Writes. Architektur so gestalten, dass sie an andere Software anhängbar ist.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** 10 User greifen gleichzeitig auf DB zu → alle Requests werden concurrent verarbeitet, keine Locking-Verzögerungen.
+2. **Edge Case:** 200k Datensätze in DB → Such-Query läuft in <500ms (mit Index).
+3. **Integration:** Externe Software verbindet sich zur DB → Schema ist dokumentiert, Anbindung möglich.
+
+**Akzeptanzkriterium:** PostgreSQL-Datenbank, ORM mit austauschbarem Backend, Schema dokumentiert für externe Anbindung, Full-Text-Search für globale Suche.
+
+---
+
+### F-DATA-06: ARIA-Rollen auf DataTable [v1]
+**Anforderung:** Alle DataTable-Komponenten (Firmen-Liste, Kontakt-Liste, Task-Liste) erhalten korrekte ARIA-Rollen für Screen-Reader-Zugänglichkeit. Sortierbare Spalten werden als solche angekündigt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Screen-Reader navigiert zur Firmen-Liste → kündigt Tabelle mit Einträge-Anzahl an. Spalten-Header werden als sortierbar angekündigt.
+2. **Edge Case:** User sortiert nach Name absteigend → Sortierrichtung wird von Screen-Reader angekündigt.
+3. **Integration:** Tabelle mit 0 Einträgen → Screen-Reader kündigt „Keine Daten" an.
+
+**Akzeptanzkriterium:** Alle Tabellen haben korrekte ARIA-Rollen und -Attribute; getestet mit Screen-Reader und Accessibility-DevTools.
+
+---
+
+### F-UI-01: Responsive Design [v1]
+**Anforderung:** UI ist voll responsive — Desktop, Tablet, Handy. Touch-Events funktionieren auf Mobile.
+
+**Test Scenarios:**
+1. **Happy Path:** Desktop → Layout mit Sidebar, Tabelle mit allen Spalten.
+2. **Integration:** Handy → Layout passt sich an, Sidebar wird zum Burger-Menu, Tabelle wird Karten-Ansicht.
+3. **Edge Case:** Tablet → Layout intermediär, alle Aktionen erreichbar.
+
+**Akzeptanzkriterium:** Responsive Breakpoints funktionieren; Mobile-First; Touch-Targets min 44px; getestet in DevTools (375px, 768px, 1920px).
+
+---
+
+### F-UI-02: Internationalisierung (i18n: Deutsch + Englisch) [v1]
+**Anforderung:** UI ist auf Deutsch und Englisch verfügbar. User kann Sprache umschalten. Datums-/Zeitformate passen sich an.
+
+**Test Scenarios:**
+1. **Happy Path:** User wählt „English" → alle UI-Texte wechseln zu Englisch.
+2. **Integration:** User wählt „Deutsch" → Datum zeigt „25.06.2026" statt „2026-06-25".
+3. **Edge Case:** Fehlende Übersetzung für einen Text → Fallback auf Deutsch (Default-Sprache).
+
+**Akzeptanzkriterium:** Alle UI-Texte sind übersetzt (DE/EN); Sprachwahl wird persistiert; Datums-/Zeitformate passen sich an.
+
+---
+
+### F-UI-03: Error-Handling & Toast-Notifications [v1]
+**Anforderung:** Fehler werden als Toast-Notifications angezeigt (nicht als Alert-Popups). Error-Pages für 404 und 500.
+
+**Test Scenarios:**
+1. **Happy Path:** API-Fehler beim Speichern → Toast „Fehler beim Speichern: [Detail]" verschwindet nach 5s.
+2. **Edge Case:** Nicht gefundene Seite → freundliche „Seite nicht gefunden" mit Link zum Dashboard.
+3. **Edge Case:** Server-Fehler → generische Fehlerseite mit „Erneut versuchen"-Button.
+
+**Akzeptanzkriterium:** Toast-Notifications (success/error/warning/info) funktionieren; dedizierte Error-Pages vorhanden.
+
+---
+
+### F-UI-04: Loading-States [v1]
+**Anforderung:** Während API-Calls werden Loading-Indicators (Spinner/Skeleton) angezeigt.
+
+**Test Scenarios:**
+1. **Happy Path:** Firmen-Liste lädt → Skeleton-Loader erscheint bis Daten da sind.
+2. **Integration:** Speichern-Button zeigt Spinner während Request → disabled bis Response.
+3. **Edge Case:** Langsamer Request (>3s) → Spinner bleibt sichtbar, kein Timeout-Error.
+
+**Akzeptanzkriterium:** Loading-States werden bei allen API-Calls angezeigt; Buttons sind während Pending disabled.
+
+---
+
+### F-UI-05: Empty-States [v1]
+**Anforderung:** Wenn keine Daten vorhanden sind, wird ein hilfreicher Empty-State angezeigt (nicht nur leere Tabelle).
+
+**Test Scenarios:**
+1. **Happy Path:** Keine Firmen in DB → Empty-State „Noch keine Firmen. Erste Firma anlegen?" mit CTA-Button.
+2. **Edge Case:** Suche ohne Treffer → Empty-State „Keine Ergebnisse für ‚XYZ'".
+3. **Edge Case:** Firma ohne Kontakte → Empty-State „Keine Kontakte zugeordnet. Kontakt hinzufügen?".
+
+**Akzeptanzkriterium:** Empty-States mit Icon + Text + CTA in allen Listen-Ansichten.
+
+---
+
+### F-UI-06: Confirmation-Dialogs [v1]
+**Anforderung:** Destruktive Aktionen (Löschen) erfordern Bestätigungs-Dialog.
+
+**Test Scenarios:**
+1. **Happy Path:** User klickt „Firma löschen" → Dialog „Wirklich löschen?" mit „Ja/Nein" → „Nein" bricht ab.
+2. **Integration:** User bestätigt Löschung → Aktion wird ausgeführt, Erfolg-Toast erscheint.
+3. **Edge Case:** Dialog wird außerhalb geklickt → Dialog schließt, keine Aktion.
+
+**Akzeptanzkriterium:** Alle DELETE-Operationen erfordern Bestätigungs-Dialog; Abbruch möglich.
+
+---
+
+### F-UI-08: Datenansichten — Tabelle/Karten/Liste [v1]
+**Anforderung:** Daten können in drei Ansichten dargestellt werden: Tabelle, Karten (Grid), Liste. Alle Ansichten sind filterbar, mit Suche und Sortierung.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User schaltet von Tabellen- zu Karten-Ansicht → Darstellung ändert sich, Daten bleiben gleich.
+2. **Integration:** Filter aktiv in Karten-Ansicht → nur gefilterte Datensätze werden als Karten angezeigt.
+3. **Edge Case:** Sortierung per Dropdown in Karten/Liste → Sortierung wird angewendet.
+
+**Akzeptanzkriterium:** View-Toggle zwischen Tabelle/Karten/Liste; Filter und Sortierung aktiv in allen Views.
+
+---
+
+### F-A11Y-01: Accessibility (WCAG 2.1 AA) [v1]
+**Anforderung:** UI erfüllt WCAG 2.1 AA: Keyboard-Navigation, Screen-Reader-kompatibel, Kontrast >4.5:1. Text ausschließlich für Screen-Reader sichtbar zu machen wird unterstützt (visual-hidden pattern).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User navigiert nur mit Tab-Taste durch Firmen-Liste → alle Elemente erreichbar, Fokus sichtbar.
+2. **Integration:** Screen-Reader liest Form-Labels vor → Eingabefelder korrekt zugeordnet.
+3. **Edge Case:** Kontrast-Check mit axe DevTools → keine WCAG-Verstöße.
+
+**Akzeptanzkriterium:** Semantische Struktur; Labels für interaktive Elemente; Kontrast >4.5:1; Tab-Reihenfolge logisch.
+
+---
+
+### F-A11Y-02: prefers-reduced-motion [v1]
+**Anforderung:** Die UI respektiert die Benutzer-Präferenz `prefers-reduced-motion`. Bei gesetzter Präferenz werden alle Animationen, Transitions und automatischen Bewegungen deaktiviert oder auf minimale Dauer reduziert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User hat OS-Level „Reduce Motion" aktiviert → alle Animationen werden deaktiviert, Loading-Spinner zeigen statischen Fallback.
+2. **Edge Case:** User ohne „Reduce Motion" → Animationen und Transitions laufen normal mit default Dauer.
+3. **Integration:** Toast-Notifications erscheinen ohne Slide-In-Animation (sofort sichtbar), Modals öffnen ohne Fade-In.
+
+**Akzeptanzkriterium:** Media-Query für reduzierte Bewegung in globalen Styles; alle Transitions und Animationen werden darin deaktiviert. Getestet in Chrome DevTools (Rendering → Emulate CSS prefers-reduced-motion: reduce).
+
+---
+
+### F-A11Y-03: 44px Touch-Targets [v1]
+**Anforderung:** Alle interaktiven Elemente (Buttons, Links, Checkboxen, Icon-Buttons, Tab-Items) haben ein Mindest-Touch-Target von 44×44px (gemäß WCAG 2.5.5 Target Size und Apple HIG). Bei kleineren visuellen Elementen wird das Touch-Target via Padding auf 44px erweitert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User auf Handy (375px) tippt auf Icon-Button (Löschen) → Touch-Target ist 44×44px, Tippen ist zuverlässig auch ohne Präzision.
+2. **Edge Case:** Zwei benachbarte Icon-Buttons (Bearbeiten, Löschen) mit 8px Abstand → beide haben 44px Touch-Target, keine Überlappung, Fehlertipps werden vermieden.
+3. **Integration:** Checkbox in DataTable-Zelle → Checkbox ist visuell 16×16px, aber Touch-Target wird via Padding auf 44×44px erweitert, Mobile-User kann zuverlässig toggeln.
+
+**Akzeptanzkriterium:** Mindest-Touch-Target von 44×44px für alle interaktiven Elemente. Getestet in Chrome DevTools (375px Breite, Touch-Emulation).
+
+---
+
+### F-SEC-01: CSRF-Schutz [v1]
+**Anforderung:** State-changing API-Calls sind CSRF-geschützt. Implementierung via SameSite=Strict Cookie + Origin-Header-Validierung.
+
+**Test Scenarios:**
+1. **Happy Path:** Request mit korrektem Origin-Header + SameSite=Strict Cookie → wird akzeptiert.
+2. **Edge Case:** Request ohne Origin-Header → Zugriff verweigert.
+3. **Edge Case:** Request mit falschem Origin-Header → Zugriff verweigert.
+
+**Akzeptanzkriterium:** SameSite=Strict Cookie für alle Auth-Cookies; Origin-Header-Validierung; nur GET/HEAD/OPTIONS sind exempt.
+
+---
+
+### F-SEC-02: XSS-Schutz & Input-Sanitization [v1]
+**Anforderung:** Alle User-Eingaben werden sanitized. HTML in Eingabefeldern wird escaped, nicht gerendert.
+
+**Test Scenarios:**
+1. **Happy Path:** User gibt Script-Tag in Notizfeld → wird als Text gespeichert, nicht ausgeführt.
+2. **Edge Case:** User gibt HTML in Name-Feld → wird escaped in Listen-Ansicht und Detail-Seite.
+3. **Integration:** API-Response enthält keine ungefilterten HTML-Tags aus User-Eingaben.
+
+**Akzeptanzkriterium:** Output-Encoding im Frontend; serverseitige Validierung strippt gefährliche Eingaben; CSP-Header gesetzt.
+
+---
+
+### F-SEC-03: Session-Timeout [v1]
+**Anforderung:** Session läuft nach 8h ab. User wird nach Ablauf zur Login-Seite geleitet.
+
+**Test Scenarios:**
+1. **Happy Path:** Session gültig <8h → alle Requests funktionieren.
+2. **Edge Case:** Session nach 8h → API verweigert Zugriff, Frontend leitet zur Login-Seite.
+3. **Integration:** User aktiv → Session kann optional verlängert werden (Refresh optional für v1).
+
+**Akzeptanzkriterium:** Session-Timeout=8h; abgelaufene Session → Redirect zur Login-Seite.
+
+---
+
+### F-INFRA-01: Health-Check Endpoint [v1]
+**Anforderung:** Health-Check-Endpoint gibt Status zurück, wenn App + DB erreichbar. Kein Auth erforderlich.
+
+**Test Scenarios:**
+1. **Happy Path:** App läuft, DB verbunden → Health-Check gibt „healthy" zurück.
+2. **Edge Case:** DB nicht erreichbar → Health-Check gibt „unhealthy" zurück.
+3. **Integration:** Coolify nutzt Endpoint für Health-Check → Auto-Restart bei „unhealthy".
+
+**Akzeptanzkriterium:** Health-Check-Endpoint ohne Auth; Status zeigt App + DB; von Monitoring nutzbar.
+
+---
+
+### F-INFRA-02: Backup & Restore [v1]
+**Anforderung:** DB-Backup wird täglich erstellt. Restore-Prozess dokumentiert.
+
+**Test Scenarios:**
+1. **Happy Path:** Backup-Job läuft täglich → Backup-Datei existiert im Backup-Volume.
+2. **Integration:** Restore: Backup-Datei einspielen → DB hat Stand vom Backup-Zeitpunkt.
+3. **Edge Case:** Backup schlägt fehl → Alert wird ausgelöst.
+
+**Akzeptanzkriterium:** Tägliches DB-Backup; Restore-Dokumentation vorhanden; Alert bei Backup-Fehler.
+
+---
+
+### F-INFRA-03: Logging [v1]
+**Anforderung:** App-Logs werden strukturiert ausgegeben (JSON-Format). Error-Logs mit Stacktrace.
+
+**Test Scenarios:**
+1. **Happy Path:** API-Request wird geloggt (Method, Path, Status, Duration).
+2. **Edge Case:** Exception → Error-Log mit Stacktrace, Request-Kontext.
+3. **Integration:** Logs sind in Container-Logs sichtbar.
+
+**Akzeptanzkriterium:** Strukturierte JSON-Logs; Log-Level konfigurierbar; Error-Logs mit Stacktrace.
+
+---
+
+### F-INFRA-04: Monitoring & Alerting [v1]
+**Anforderung:** Basis-Monitoring: Health-Check, Response-Zeit, DB-Connection-Pool. Alerts bei Ausfall.
+
+**Test Scenarios:**
+1. **Happy Path:** App gesund → Monitoring zeigt grün.
+2. **Edge Case:** App down → Alert wird ausgelöst.
+3. **Integration:** DB-Connection-Pool erschöpft → Warning-Alert.
+
+**Akzeptanzkriterium:** Monitoring nutzt Health-Check; Alerts bei Ausfall; Response-Zeit überwacht.
+
+---
+
+### F-MIG-01: CSV-Import [v1]
+**Anforderung:** User kann CSV-Datei mit Firmen oder Kontakten importieren. Feld-Mapping beim Import.
+
+**Test Scenarios:**
+1. **Happy Path:** User lädt CSV mit 50 Firmen hoch → Feld-Mapping wird angezeigt → Import → 50 Firmen in DB.
+2. **Edge Case:** CSV mit ungültiger E-Mail in Zeile 3 → Zeile wird übersprungen, Fehler-Report zeigt Zeile 3.
+3. **Integration:** CSV mit Kontakt + Firmen-Name → Firma wird gesucht/erstellt, Kontakt wird zugeordnet.
+
+**Akzeptanzkriterium:** CSV-Import mit Feld-Mapping; Fehler-Report pro Zeile; Auto-Erkennung von Firmen bei Kontakt-Import.
+
+---
+
+### F-INT-01: E-Mail-Integration (Passwort-Reset) [v1]
+**Anforderung:** App kann E-Mails versenden (mindestens für Passwort-Reset). SMTP-Konfiguration via Env-Vars.
+
+**Test Scenarios:**
+1. **Happy Path:** User fordert Reset an → E-Mail wird versendet, im Postfach sichtbar.
+2. **Edge Case:** SMTP nicht konfiguriert → Fehler wird geloggt, User sieht „E-Mail konnte nicht gesendet werden".
+3. **Integration:** Reset-Link in E-Mail ist klickbar → führt zur Reset-Seite.
+
+**Akzeptanzkriterium:** SMTP-Config via Env-Vars; E-Mail-Templates für Reset; Versand funktioniert in Dev + Prod.
+
+---
+
+### F-INT-02: Session-Auth / API-Keys [v1]
+**Anforderung:** API-Endpunkte sind via Session-Cookie authentifiziert. Optional: API-Key für externe Integrationen (post-MVP).
+
+**Test Scenarios:**
+1. **Happy Path:** Request mit gültigem Session-Cookie → Zugriff erlaubt.
+2. **Edge Case:** Request ohne Session → Zugriff verweigert.
+3. **Edge Case:** Request mit abgelaufener Session → Zugriff verweigert, Frontend leitet zur Login-Seite.
+
+**Akzeptanzkriterium:** Session-Auth auf allen Endpoints außer Health-Check und Auth-Endpunkten.
+
+---
+
+### F-TEST-01: Testing-Strategie [v1]
+**Anforderung:** Backend: pytest mit >80% Coverage. Frontend: Vitest/Jest mit Component-Tests. E2E: Playwright für Critical Paths.
+
+**Test Scenarios:**
+1. **Happy Path:** Test-Suite läuft → Coverage >80% Backend.
+2. **Integration:** Playwright-Test: Login → Firma anlegen → Kontakt zuordnen → Export → Logout.
+3. **Edge Case:** Test-Suite läuft in CI → bei Fehlschlag wird Build blockiert.
+
+**Akzeptanzkriterium:** pytest + httpx für API-Tests; Vitest für Frontend; Playwright für E2E; Coverage-Report in CI.
+
+---
+
+### F-ENV-01: Environments & Secrets [v1]
+**Anforderung:** Dev-Environment lokal, Prod auf Coolify. Env-Vars für DB, SMTP, Session-Secret. Secrets nicht im Code.
+
+**Test Scenarios:**
+1. **Happy Path:** Lokale Dev mit `.env` → App startet, DB verbunden.
+2. **Integration:** Prod auf Coolify mit Env-Vars → App startet, DB verbunden, SMTP funktioniert.
+3. **Edge Case:** Fehlende Secret-Env-Var → App startet nicht mit klarem Fehler.
+
+**Akzeptanzkriterium:** `.env.example` dokumentiert alle Vars; keine Secrets im Git-Repo; Coolify Env-Vars konfiguriert.
+
+---
+
+### F-DOC-01: Dokumentation [v1]
+**Anforderung:** README mit Setup-Anleitung, API-Doku (OpenAPI/Swagger auto-gen), Admin-Doku (Deploy, Backup, Restore).
+
+**Test Scenarios:**
+1. **Happy Path:** Neue Developer klonen Repo → folgen README → App läuft lokal.
+2. **Integration:** Swagger-UI auto-generiert → alle Endpunkte sichtbar mit Schemas.
+3. **Edge Case:** Admin liest Restore-Doku → kann Backup einspielen ohne Entwickler-Hilfe.
+
+**Akzeptanzkriterium:** README mit Setup; Swagger/OpenAPI auto-gen; Admin-Guide für Deploy/Backup/Restore.
+
+---
+
+### F-PERF-01: Performance [v1]
+**Anforderung:** API-Response <500ms für List-Endpunkte bei 200k Datensätzen. DB-Indizes auf Such-/Filter-Feldern. Lazy Loading im Frontend.
+
+**Test Scenarios:**
+1. **Happy Path:** List-Endpunkt bei 200k Kontakten → Response <500ms.
+2. **Integration:** Such-Query bei 200k Kontakten → Response <500ms (mit DB-Index).
+3. **Edge Case:** Export von 200k Kontakten → als Background-Job oder Streaming-Response.
+
+**Akzeptanzkriterium:** DB-Indizes auf Such-/Filter-Felder; API-Pagination verhindert Full-Table-Scan; Response <500ms bei 200k.
+
+---
+
+### F-SCHED-01: Background-Jobs (Export, Backup) [v1]
+**Anforderung:** Lange laufende Operationen (großer Export, DB-Backup) als Background-Job. Status-Polling oder Notification bei Fertigstellung.
+
+**Test Scenarios:**
+1. **Happy Path:** User startet Export von 200k Kontakten → Background-Job startet → User bekommt Notification bei Fertigstellung.
+2. **Integration:** Backup-Job läuft nachts → Audit-Log zeigt Backup-Completion.
+3. **Edge Case:** Background-Job schlägt fehl → User bekommt Error-Notification.
+
+**Akzeptanzkriterium:** Background-Task-Queue; Job-Status abfragbar; Notification bei Erfolg/Fehler; Retry bei Fehlern.
+
+---
+
+### F-AI-01: KI-Copilot mit voller API-Kontrolle [v1]
+**Anforderung:** KI-Copilot von Anfang an einplanen. Der Copilot hat Zugriff auf die volle API und soll alles steuern können — Daten abfragen, erstellen, bearbeiten, löschen, Aktionen auslösen, Workflows triggern. Der Copilot respektiert das Rollen-/Rechte-System inkl. Feld-Ebene-Granularität: er kann nur das sehen und tun, was die Rolle des zugehörigen Users erlaubt. Architektur muss KI-Integration von vornherein unterstützen (API-First-Design, siehe F-CORE-06).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User fragt Copilot „Zeige mir alle Firmen in Berlin" → Copilot ruft API auf → Ergebnisse werden angezeigt, respektiert Tenant- und Rollen-Filter.
+2. **Edge Case:** User mit Rolle „viewer" bittet Copilot, eine Firma zu löschen → Copilot verweigert (RBAC wird durchgesetzt).
+3. **Integration:** Copilot erstellt neuen Kontakt und verknüpft mit Firma → Kontakt erscheint in Firmen-Detail.
+
+**Akzeptanzkriterium:**
+- Vollständige API-Schnittstelle definiert und dokumentiert
+- Copilot kann alle CRUD-Operationen über die API ausführen
+- Copilot kann Workflows und Aktionen triggern
+- Rechte-System wird durchgesetzt: Copilot sieht/bearbeitet nur Felder, die die User-Rolle erlaubt
+- API-First-Design: alle Features sind über die API nutzbar, nicht nur über die UI
+
+---
+
+### F-WF-01: Hybrid-Workflow-Engine [v1]
+**Anforderung:** Logik ins System einbauen — Hybrid-Ansatz: Code-Engine für Kern-Workflows + konfigurierbare Workflow-Regeln für User-definierte Prozesse. Mehrstufige Prozesse abbildbar (z.B. Genehmigungs-Ketten, Verkaufs-Pipeline, Onboarding).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin definiert Workflow „Angebots-Genehmigung" mit 3 Stufen → Angebot wird erstellt → durchläuft Stufen → wird genehmigt.
+2. **Edge Case:** Genehmiger lehnt ab → Workflow stoppt, Initiator bekommt Notification.
+3. **Integration:** Workflow nutzt Daten aus Firmen und Kontakten →条件和 basieren auf Firmen-Branche.
+
+**Akzeptanzkriterium:** Workflow-Engine kann Prozesse definieren (Schritte, Bedingungen, Übergänge); Code-basierte Kern-Workflows sind hartkodiert; User-Workflows sind konfigurierbar; Workflows können Daten aus allen Modulen nutzen.
+
+---
+
+### F-SEARCH-01: Globale Suche [v1]
+**Anforderung:** Eine globale Suche über alle Entitäten (Firmen, Kontakte, Dateien, Termine, Mails, Tags). Suchfeld in der Top-Bar, Ergebnisse in Dropdown oder separater Seite. Performant auch bei 200k+ Datensätzen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User gibt „ACME" ein → Ergebnisse aus Firmen, Kontakten und (falls Plugins aktiv) Dateien/Terminen/Mails erscheinen.
+2. **Edge Case:** Suche ohne Treffer → Empty-State „Keine Ergebnisse".
+3. **Integration:** Klick auf Ergebnis → Detail-Ansicht öffnet sich.
+
+**Akzeptanzkriterium:** Suchbegriff eingeben → Ergebnisse aus allen Modulen erscheinen; Klick öffnet Detail-Ansicht; Suche ist performant bei 200k+ Datensätzen.
+
+---
+
+### F-NAV-01: Navigation — Linke Sidebar [v1]
+**Anforderung:** Linke Sidebar mit Navigation zu allen Modulen: Dashboard, Firmen, Kontakte, Kalender, Dateien, E-Mail, Benutzer, Audit-Log, Einstellungen. Plugin-Module erscheinen dynamisch in der Sidebar.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt „Firmen" in Sidebar → Firmen-Liste wird geladen, „Firmen" ist aktiv hervorgehoben.
+2. **Edge Case:** User klappt Sidebar ein → mehr Platz für Content, Burger-Menu öffnet sie wieder.
+3. **Integration:** Plugin wird aktiviert → neuer Menüeintrag erscheint automatisch in Sidebar.
+
+**Akzeptanzkriterium:** Sidebar einklappbar; alle Module erreichbar; aktives Modul hervorgehoben; mobile Hamburger-Navigation; Plugin-Menüeinträge dynamisch.
+
+---
+
+### F-SET-01: Einstellungen als Baum-Menü [v1]
+**Anforderung:** Einstellungen-Seite mit Baumansicht (Tree-View) links für Navigation, rechts die jeweiligen Einstellungen. Sortiert nach Modul oder Themengebieten. Plugins können eigene Settings-Seiten registrieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klappt „Auth" auf → sieht User-Verwaltung, Rollen → klickt „Rollen" → Rollen-Editor erscheint rechts.
+2. **Edge Case:** Plugin registriert Settings-Seite → erscheint im Baum unter eigener Kategorie.
+3. **Edge Case:** User ohne Admin-Rechte → sieht nur persönliche Einstellungen (Profil, Sprache, Theme).
+
+**Akzeptanzkriterium:** Baum-Menü mit aufklappbaren Kategorien; rechte Seite zeigt jeweilige Einstellungsformulare; Plugins können Settings registrieren.
+
+---
+
+### F-PLUGIN-01: Plugin-System für Module [v1]
+**Anforderung:** Die Module sollen als Plugins realisiert sein, sodass das CRM später durch Plugins erweitert werden kann. Module können Daten untereinander tauschen. Die Module Mail, Kalender, Dateien (DMS) und Tags werden als Plugins implementiert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin aktiviert Plugin „Kalender" → Kalender-Modul erscheint in Sidebar, Kalender-Funktionen verfügbar.
+2. **Edge Case:** Admin deaktiviert Plugin „DMS" → Dateien-Modul verschwindet aus Sidebar, Firmen/Kontakte bleiben unberührt.
+3. **Integration:** Plugin „Mail“ kann auf Firmen/Kontakt-Daten zugreifen (Daten-Austausch funktioniert).
+
+**Akzeptanzkriterium:** Plugin-Schnittstelle definiert; Module (Mail, Kalender, Dateien, Tags) sind Plugins; Plugins können Daten austauschen; Plugins können aktiviert/deaktiviert werden.
+
+---
+
+### F-PLUGIN-02: Plugin-Schnittstellen-Definition [v1]
+**Anforderung:** Das Plugin-System braucht eine definierte Schnittstelle: API-Contract, Daten-Austausch zwischen Plugins, Lifecycle-Hooks (install, activate, deactivate, uninstall), Plugin-Manifest, Abhängigkeiten.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin wird installiert → Lifecycle-Hook `install` wird aufgerufen → Plugin erscheint als „deaktiviert".
+2. **Integration:** Plugin wird aktiviert → Lifecycle-Hook `activate` wird aufgerufen → Plugin-Menüeinträge erscheinen, API-Endpunkte verfügbar.
+3. **Edge Case:** Plugin deklariert Abhängigkeit auf Plugin „DMS" → „DMS" ist nicht aktiv → Aktivierung wird verweigert mit Hinweis.
+
+**Akzeptanzkriterium:** Plugin-Manifest-Format definiert; API-Schnittstelle dokumentiert; Plugins können Daten austauschen; Lifecycle-Hooks funktionieren; Plugins können Abhängigkeiten deklarieren.
+
+---
+
+### F-CORE-01: Event Bus [v1]
+**Anforderung:** Core-Event-System (Event Bus). Core und Plugins können Events emitten und subscribieren. Events sind typisiert, haben Payload, und werden asynchron verarbeitet. Plugins registrieren Listener beim Aktivieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Firma wird erstellt → `company.created` Event wird emittiert → Mail-Plugin-Listener empfängt und verarbeitet.
+2. **Edge Case:** Plugin wird deaktiviert → dessen Listener werden abgemeldet, keine Events mehr empfangen.
+3. **Integration:** `contact.deleted` Event → DMS-Plugin entfernt verknüpfte Datei-Links.
+
+**Akzeptanzkriterium:** Event-Bus implementiert; Events können gepublished und subscribed werden; Listener werden bei Event-Feuerung aufgerufen; Events sind typisiert mit Payload; asynchrone Verarbeitung.
+
+---
+
+### F-CORE-02: Tenant-Isolation auf Datenebene [v1]
+**Anforderung:** Jede Datentabelle hat ein Tenant-ID-Feld. Alle Queries werden automatisch pro Tenant gefiltert. Ein Tenant kann die Daten eines anderen Tenants nicht sehen. Plugins, die eigene Tabellen erstellen, müssen ebenfalls Tenant-ID unterstützen. Tenant-Switch in der UI wechselt den aktiven Scope.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User in Tenant A erstellt Firma → Firma hat tenant_id=A → User in Tenant B kann Firma nicht sehen.
+2. **Edge Case:** Query ohne Tenant-Filter → ORM fügt automatisch tenant_id hinzu → Cross-Tenant-Access verweigert.
+3. **Integration:** Plugin erstellt eigene Tabelle → muss tenant_id haben → Daten sind pro Tenant isoliert.
+
+**Akzeptanzkriterium:** tenant_id auf allen Core-Tabellen; ORM filtert automatisch; Cross-Tenant-Access verweigert; Plugin-Tabellen müssen tenant_id haben; Tenant-Switch funktioniert in UI.
+
+---
+
+### F-CORE-03: Plugin-Datenbank-Migration [v1]
+**Anforderung:** Plugins können eigene Datenbank-Tabellen erstellen und migrieren. Plugin-Migrationen sind versioniert und werden beim Installieren/Aktualisieren automatisch ausgeführt. Beim Deinstallieren werden Plugin-Tabellen optional entfernt (User-Choice). Migrationen laufen im Tenant-Kontext.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin wird installiert → Migrationen werden ausgeführt → Tabellen werden erstellt mit tenant_id-Spalte.
+2. **Edge Case:** Plugin wird aktualisiert → neue Migration wird automatisch ausgeführt → Schema wird erweitert.
+3. **Integration:** Plugin wird deinstalliert → User-Dialog: „Tabellen entfernen?" → User wählt „Ja" → Tabellen werden gelöscht.
+
+**Akzeptanzkriterium:** Plugin kann Schema definieren; Migrationen werden beim Install ausgeführt; Versionierung funktioniert; Deinstall bietet Tabellen-Entfernung an; Migrationen unterstützen tenant_id.
+
+---
+
+### F-CORE-04: UI-Plugin-Framework [v1]
+**Anforderung:** Plugins können UI-Komponenten registrieren: eigene Routen (Seiten), Menu-Einträge in der Sidebar, Widgets auf Dashboards, Tabs in Detail-Ansichten. UI-Komponenten folgen dem Core-Design-System. Plugins können Settings-Seiten registrieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin „Kalender" registriert Sidebar-Eintrag → erscheint in Navigation.
+2. **Integration:** Plugin „DMS" registriert Tab in Firmen-Detail → „Dateien"-Tab erscheint neben „Kontakte".
+3. **Edge Case:** Plugin wird deaktiviert → alle registrierten UI-Komponenten verschwinden.
+
+**Akzeptanzkriterium:** Plugin kann Route, Menu-Eintrag, Dashboard-Widget, Detail-Tab, Settings-Seite registrieren; Design folgt Core-Design-System; Deaktivierung entfernt alle UI-Komponenten.
+
+---
+
+### F-CORE-05: Service Container / Dependency Injection [v1]
+**Anforderung:** Core-Services (DB, Cache, Event Bus, Auth, Config, Logger) sind über einen Service Container verfügbar. Plugins bekommen benötigte Services injiziert (Dependency Injection). Service-Container verhindert direkte Instanziierung und sorgt für Testbarkeit.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin requestet DB-Service → bekommt gültige DB-Verbindung über DI.
+2. **Edge Case:** Plugin deklariert nicht deklarierte Abhängigkeit → Fehler „Service nicht verfügbar".
+3. **Integration:** In Tests: Mock-Service wird injiziert → Plugin funktioniert ohne echte DB.
+
+**Akzeptanzkriterium:** Service Container implementiert; Core-Services registriert; Plugins können Services anfordern; DI funktioniert; Abhängigkeiten im Manifest deklariert; Mocking für Tests möglich.
+
+---
+
+### F-CORE-06: API-First Architecture [v1]
+**Anforderung:** Alle Core-Features und Plugin-Features sind primär über die API nutzbar. Die UI ist ein API-Client. API-Endpunkte sind versioniert und dokumentiert (OpenAPI/Swagger). Der KI-Copilot (F-AI-01) nutzt dieselbe API. Plugins müssen eigene API-Endpunkte registrieren können.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Firma über UI → gleiche API wird intern aufgerufen → API-Response kommt zurück.
+2. **Integration:** KI-Copilot ruft API auf → gleiche Endpunkte wie UI → RBAC und Tenant-Isolation werden durchgesetzt.
+3. **Edge Case:** Plugin registriert eigenen API-Endpunkt → erscheint in Swagger, ist authentifiziert.
+
+**Akzeptanzkriterium:** OpenAPI-Schema generiert; alle Features über API nutzbar; API versioniert; Plugin-API-Endpunkte registrierbar; KI-Copilot nutzt API; UI ist API-Client.
+
+---
+
+### F-CORE-07: Async Job Queue [v1]
+**Anforderung:** Core-Infrastruktur für Background-Jobs: Queue-System für asynchrone Tasks. Core nutzt Queue für Exports, Backups, Mail-Versand, Event-Verarbeitung. Plugins können eigene Jobs enqueue-en. Jobs haben Status, Retry-Logic, und sind im UI sichtbar.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Export-Job wird enqueued → Job läuft asynchron → Status wechselt auf „success" → User bekommt Notification.
+2. **Edge Case:** Job schlägt fehl → Retry wird ausgeführt → bei wiederholtem Fehlschlag → Dead-Letter-Queue.
+3. **Integration:** Plugin enqueue-t eigenen Job → Job erscheint in Job-Liste im UI → Status sichtbar.
+
+**Akzeptanzkriterium:** Queue-Infrastruktur läuft; Core-Tasks werden asynchron ausgeführt; Plugins können Jobs enqueue-en; Job-Status im UI sichtbar; Retry bei Fehlern; Dead-Letter-Queue.
+
+---
+
+### F-CORE-08: Caching-Strategie [v1]
+**Anforderung:** Cache-Backend für Sessions, Query-Cache, Plugin-Data. Core cached häufige Queries. Plugins können Cache-Keys registrieren. Cache-Invalidierung bei Datenänderung (Event-basiert). TTL-basiertes Caching als Fallback.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Firmen-Liste wird geladen → aus Cache → Response <50ms → bei Datenänderung wird Cache invalidiert.
+2. **Edge Case:** Cache-Miss → Query wird ausgeführt → Result wird gecacht → nächste Anfrage aus Cache.
+3. **Integration:** Plugin registriert eigenen Cache-Key → wird bei Event invalidiert.
+
+**Akzeptanzkriterium:** Cache-Backend angebunden; Session-Cache aktiv; Query-Cache für Core-Queries; Plugins können cachen; Cache-Invalidierung bei Events; TTL konfigurierbar.
+
+---
+
+### F-CORE-09: User-Profile und Preferences [v1]
+**Anforderung:** Jeder User hat ein persönliches Profil mit Preferences: Sprache, Zeitzone, Theme (Light/Dark), Standard-Ansicht (Tabelle/Karten/Liste), Standard-Sortierung, Dashboard-Konfiguration. Preferences sind pro User gespeichert und werden beim Login geladen. Plugins können eigene Preference-Felder registrieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User stellt Sprache auf Englisch, Theme auf Dark → Preferences werden gespeichert → beim nächsten Login sind sie aktiv.
+2. **Edge Case:** User hat keine Preferences gesetzt → Default-Werte werden verwendet.
+3. **Integration:** Plugin registriert Preference „Mail-Signatur“ → erscheint in User-Settings.
+
+**Akzeptanzkriterium:** User-Profile existiert; Preferences speicherbar und ladbar; Sprache/Zeitzone/Theme umschaltbar; Dashboard konfigurierbar; Plugins können Preferences registrieren.
+
+---
+
+### F-CORE-10: Storage-Backend [v1]
+**Anforderung:** File-Storage-Service als Core-Feature. Unterstützt S3-kompatibles Storage und lokales Volume. Konfigurierbar pro Deployment. Plugins nutzen den Storage-Service vom Core, kein direkter Dateizugriff. Storage-Service bietet Upload, Download, Delete, Presigned-URLs, und Metadata.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin lädt Datei hoch → Storage-Service speichert Datei → gibt Metadaten zurück.
+2. **Edge Case:** Storage-Backend nicht konfiguriert → Fehler „Storage nicht verfügbar".
+3. **Integration:** Presigned-URL wird generiert → Client kann Datei direkt herunterladen ohne Plugin-Code.
+
+**Akzeptanzkriterium:** Storage-Backend konfigurierbar (S3 oder lokales Volume); Upload/Download/Delete funktionieren; Presigned-URLs; Plugins nutzen Service; Metadata speicherbar.
+
+---
+
+### F-CORE-11: Generic Import/Export Service [v1]
+**Anforderung:** Core-Service für generischen Import und Export von Daten. Unterstützt CSV und Excel. Plugins können Import/Export-Definitionen registrieren (Felder, Mapping, Validierung). Import mit Preview, Fehler-Reporting, und Dry-Run. Export mit Feld-Auswahl und Filterung.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User importiert CSV mit Kontakten → Preview zeigt Mapping → Import → 50 Kontakte in DB.
+2. **Edge Case:** Dry-Run → zeigt was importiert würde, ohne zu speichern.
+3. **Integration:** Plugin „Kalender“ registriert eigene Export-Definition → Termine können als CSV exportiert werden.
+
+**Akzeptanzkriterium:** CSV/Excel-Import/Export funktioniert; Plugins können Definitionen registrieren; Import-Preview mit Fehler-Reporting; Export mit Feld-Auswahl; Dry-Run für Import.
+
+---
+
+### F-CORE-12: PDF/Document Generation Service [v1]
+**Anforderung:** Core-Service für PDF-Generierung aus Templates. Plugins können Document-Templates registrieren. Core generiert PDF aus Template + Daten. Templates unterstützen Variablen, Conditional Blocks, und Tabellen. Generierte PDFs werden im Storage-Backend gespeichert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Plugin ruft `generate_pdf(template_id, data)` → PDF wird generiert, im Storage gespeichert, URL zurückgegeben.
+2. **Edge Case:** Template mit unbekannter Variable → Variable wird als leer gerendert, kein Fehler.
+3. **Integration:** Template mit Tabelle (5 Zeilen) → PDF enthält Tabelle mit allen Zeilen.
+
+**Akzeptanzkriterium:** Template-Engine implementiert; PDF-Generierung aus Template + Daten; Platzhalter und Conditionals; Tabellen in PDF; PDF wird im Storage gespeichert; Plugins können Templates registrieren und PDFs generieren.
+
+---
+
+### F-CORE-13: Notification Service [v1]
+**Anforderung:** Zentraler Notification-Service im Core. Plugins und Core-Module können Notifications auslösen. Notifications haben Typ (info, warning, error, success), Titel, Body, und Ziel-User/Rolle. Channels: In-App (Bell-Icon, Dropdown-List), E-Mail. User kann Notification-Preferences einstellen. Notifications sind pro Tenant isoliert. Ungelesene Notifications werden im UI angezeigt (Badge-Zähler). Plugins registrieren Notification-Typen beim Aktivieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Background-Job fertig → Notification „Export abgeschlossen" → User sieht Badge-Zähler +1, klickt Bell-Icon → Notification-Liste.
+2. **Edge Case:** User deaktiviert E-Mail-Channel für „info"-Notifications → bekommt nur In-App.
+3. **Integration:** Plugin sendet Notification → erscheint in User-Bell → Tenant-Isolation funktioniert.
+
+**Akzeptanzkriterium:** Notification-Service implementiert; In-App-Notifications mit Bell-Icon; E-Mail-Channel; Preferences pro User; Tenant-Isolation; Badge-Zähler; Plugins können Notifications auslösen; Notification-Typen registrierbar; Historie einsehbar.
+
+---
+
+## 4b. Plugin-Requirements
+
+> **Hinweis:** Die folgenden Features werden als Plugins innerhalb des Plugin-Systems (F-PLUGIN-01, F-PLUGIN-02) implementiert. Sie nutzen Core-Infrastruktur (Event Bus, Tenant-Isolation, Storage-Backend, Service Container, etc.) gemäß F-CORE-01 bis F-CORE-13.
+
+---
+
+### F-FILE-01: Datei-Explorer [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Echter Datei-Explorer wie im Betriebssystem. Folder-Tree in Sidebar, Grid/List-View Toggle, Breadcrumbs, Toolbar (back/forward/up/new/upload/search), große Datei-Icons in Grid-View.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User navigiert durch Ordnerstruktur → Inhalte werden geladen, Breadcrumbs zeigen aktuellen Pfad.
+2. **Edge Case:** Ordner ist leer → Empty-State mit Upload-Button.
+3. **Integration:** User wechselt von Grid zu List → Darstellung ändert sich, Inhalt bleibt gleich.
+
+**Akzeptanzkriterium:** Navigation durch Ordnerstruktur, Upload, Download, Ordner erstellen, Dateien suchen, Breadcrumbs zeigen aktuellen Pfad.
+
+---
+
+### F-FILE-02: Datei-Sharing [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Eigene Ordner und Dateien können mit anderen Usern oder User-Gruppen geteilt werden.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User teilt Datei mit User B (Schreibrecht) → User B sieht Datei, kann sie bearbeiten.
+2. **Edge Case:** User teilt mit Lese-Recht → Empfänger kann ansehen aber nicht bearbeiten.
+3. **Edge Case:** User entzieht Zugriff → Empfänger sieht Datei nicht mehr.
+
+**Akzeptanzkriterium:** Share-Dialog pro Datei/Ordner; Auswahl von Usern oder Gruppen; Berechtigung (read/write/admin).
+
+---
+
+### F-FILE-03: PDF-Preview [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** PDF-Dateien können direkt im Browser in einem Preview-Viewer angezeigt werden.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt auf PDF → Inline-Viewer öffnet sich, Seiten-Navigation, Zoom.
+2. **Edge Case:** Korrupte PDF → Fehler-Toast „PDF konnte nicht geladen werden".
+3. **Edge Case:** PDF mit Passwortschutz → Dialog zur Passwort-Eingabe.
+
+**Akzeptanzkriterium:** Klick auf PDF → Inline-Viewer; Seiten-Navigation und Zoom; Fehler-Handling bei korrupten/passwortgeschützten PDFs.
+
+---
+
+### F-FILE-04: OnlyOffice-Integration [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Integration von OnlyOffice für die Bearbeitung von Office-Dokumenten (DOCX, XLSX, PPTX) direkt im CRM.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt auf Office-Datei → OnlyOffice-Editor öffnet sich inline → Änderungen werden gespeichert.
+2. **Edge Case:** OnlyOffice-Server nicht erreichbar → Fehler „Editor konnte nicht geladen werden".
+3. **Integration:** Zwei User bearbeiten gleichzeitig → Co-Authoring funktioniert.
+
+**Akzeptanzkriterium:** Klick auf Office-Datei → Editor öffnet sich inline; Änderungen werden gespeichert; Co-Authoring unterstützt.
+
+---
+
+### F-DMS-01: Ordner-Struktur verwalten (Freie Hierarchie) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können Ordner und Unterordner frei erstellen, umbenennen, verschieben und löschen — analog zu Nextcloud. Es gibt keine Beschränkung der Verschachtelungstiefe (empfohlen max. 10 Level).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Ordner „Verträge" im Root → Ordner erscheint in der Liste. User erstellt Unterordner „2026" darin → Unterordner erscheint unter „Verträge".
+2. **Edge Case:** User versucht, einen Ordner in sich selbst zu verschieben → Fehler „Ordner kann nicht in sich selbst verschoben werden".
+3. **Edge Case:** User löscht Ordner mit Unterordnern und Dateien → Bestätigungsdialog zeigt Anzahl → nach Bestätigung werden alle rekursiv (Soft-Delete) gelöscht.
+
+**Akzeptanzkriterium:** Ordner erstellen, umbenennen, verschieben, löschen funktioniert; Zirkuläre Verschiebung wird serverseitig verhindert; rekursiver Soft-Delete mit Bestätigungsdialog.
+
+---
+
+### F-DMS-02: Datei-Upload (alle Dateitypen, Drag & Drop) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können Dateien beliebigen Typs hochladen. Upload per Drag & Drop in den aktuellen Ordner oder per Datei-Auswahl-Dialog. Max. Dateigröße konfigurierbar (Default 100 MB).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User draggt PDF-Datei (2 MB) in den Datei-Browser → Upload startet, Progress wird angezeigt, Datei erscheint nach Fertigstellung im Ordner.
+2. **Edge Case:** User lädt Datei >100 MB hoch → Fehler „Datei überschreitet maximale Größe von 100 MB".
+3. **Edge Case:** Upload wird während des Übertragens abgebrochen → Datei wird nicht als vollständig gespeichert, Temp-Datei wird bereinigt.
+
+**Akzeptanzkriterium:** Drag & Drop Upload funktioniert; Progress-Anzeige; Max-Size-Validierung; Abbruch-Behandlung mit Cleanup.
+
+---
+
+### F-DMS-03: Datei-Operationen (Umbenennen, Verschieben, Löschen) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können Dateien umbenennen, in andere Ordner verschieben und löschen (Soft-Delete mit Wiederherstellung).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User verschiebt Datei von Ordner „Drafts" nach „Verträge/2026" → Datei erscheint im Zielordner, nicht mehr im Quellordner.
+2. **Edge Case:** User benennt Datei in einen Namen um, der im gleichen Ordner bereits existiert → Fehler „Datei mit diesem Namen existiert bereits".
+3. **Edge Case:** User löscht Datei → Soft-Delete → Datei ist im Papierkorb wiederherstellbar.
+
+**Akzeptanzkriterium:** Umbenennen, Verschieben, Löschen (Soft-Delete) funktionieren; Wiederherstellung aus Papierkorb; Duplikat-Schutz im gleichen Ordner.
+
+---
+
+### F-DMS-04: PDF-Preview im Browser [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** PDF-Dateien können direkt im Browser ohne Download angezeigt werden. In-Viewer-Navigation (Seiten, Zoom).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt auf PDF-Datei → PDF-Viewer öffnet sich inline, zeigt erste Seite, User kann durch Seiten navigieren und zoomen.
+2. **Edge Case:** Korrupte oder leere PDF-Datei → Fehler-Toast „PDF konnte nicht geladen werden".
+3. **Edge Case:** PDF mit Passwortschutz → Dialog zur Passwort-Eingabe, bei korrektem Passwort wird PDF angezeigt.
+
+**Akzeptanzkriterium:** PDF wird inline angezeigt; Seiten-Navigation und Zoom; Fehler-Handling bei korrupten/passwortgeschützten PDFs; Nicht-PDF → Fehler.
+
+---
+
+### F-DMS-05: OnlyOffice Integration (Online-Bearbeitung) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Office-Dokumente (DOCX, XLSX, PPTX) können direkt im Browser mit OnlyOffice bearbeitet werden. Gleichzeitige Bearbeitung durch mehrere User (Co-Authoring) wird unterstützt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt auf DOCX-Datei → OnlyOffice-Editor öffnet sich im Browser → User ändert Text → Änderung wird gespeichert → Datei auf Server ist aktualisiert.
+2. **Edge Case:** Zwei User bearbeiten gleichzeitig die gleiche XLSX-Datei → Co-Authoring funktioniert, Änderungen werden in Echtzeit synchronisiert.
+3. **Edge Case:** OnlyOffice-Server nicht erreichbar → Fehler „Editor konnte nicht geladen werden, Bitte später erneut versuchen".
+
+**Akzeptanzkriterium:** OnlyOffice-Editor öffnet sich inline; Änderungen werden gespeichert; Co-Authoring unterstützt; Fehler-Handling bei Server-Ausfall.
+
+---
+
+### F-DMS-06: Datei-Metadaten [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Jede Datei zeigt Metadaten: Dateiname, Größe (human-readable: KB/MB/GB), Upload-Datum, letzte Änderung, MIME-Type, Uploader (User).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User lädt Datei hoch → Metadaten werden nach Upload korrekt angezeigt (Größe, Upload-Datum, Uploader).
+2. **Edge Case:** Datei wird umbenannt → modified_at wird aktualisiert, Upload-Datum bleibt unverändert.
+3. **Edge Case:** Metadaten-Panel zeigt korrekte human-readable Größe bei verschiedenen Größen (500 KB, 15.3 MB, 1.2 GB).
+
+**Akzeptanzkriterium:** Metadaten (Name, Größe, MIME-Type, Upload-Datum, modified_at, Uploader) werden korrekt angezeigt; Größe wird human-readable formatiert.
+
+---
+
+### F-DMS-07: Datei-Suche im DMS [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können nach Dateinamen innerhalb des gesamten DMS oder innerhalb eines spezifischen Ordners (inkl. Unterordner) suchen. Suche ist Case-Insensitive und unterstützt Wildcards.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User sucht nach „vertrag" → alle Dateien/Ordner mit „vertrag" im Namen werden gelistet, unabhängig von Groß-/Kleinschreibung.
+2. **Edge Case:** Suche in spezifischem Ordner → nur Ergebnisse aus diesem Ordner und Unterordnern werden angezeigt.
+3. **Edge Case:** Suche ohne Treffer → Empty-State „Keine Dateien gefunden".
+
+**Akzeptanzkriterium:** Datei-Suche nach Namen; Case-Insensitive; Wildcard-Support; Suche in spezifischem Ordner oder global; Empty-State bei keinen Treffern.
+
+---
+
+### F-LINK-01: Dateien/Ordner mit Firmen verknüpfen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Dateien und Ordner lassen sich mit einer oder mehreren Firmen verknüpfen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User wählt Datei → Aktion „Mit Firma verknüpfen" → wählt Firma → Verknüpfung wird erstellt.
+2. **Edge Case:** User versucht, die gleiche Datei mit der gleichen Firma erneut zu verknüpfen → Idempotent, kein Duplikat.
+3. **Edge Case:** Datei wird gelöscht (Soft-Delete) → Verknüpfungen bleiben in DB, werden aber in Firmen-Detail nicht mehr angezeigt.
+
+**Akzeptanzkriterium:** Datei/Ordner mit Firma verknüpfen; Idempotent (keine Duplikate); Soft-Delete-Datei wird nicht mehr angezeigt.
+
+---
+
+### F-LINK-02: Dateien/Ordner mit Kontakten verknüpfen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Dateien und Ordner lassen sich mit einer oder mehreren Kontaktpersonen verknüpfen. Gleiche Mechanik wie F-LINK-01.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User verknüpft Datei mit Kontakt → Verknüpfung wird erstellt, in Kontakt-Detail sichtbar.
+2. **Edge Case:** Kontakt wird gelöscht (Soft-Delete) → Verknüpfung bleibt in DB, wird aber nicht mehr in Datei-Detail angezeigt.
+3. **Integration:** Datei ist mit Firma UND Kontakt verknüpft → beide Verknüpfungen unabhängig vorhanden, beide sichtbar.
+
+**Akzeptanzkriterium:** Datei/Ordner mit Kontakt verknüpfen; Idempotent; Soft-Delete-Kontakt wird nicht mehr angezeigt.
+
+---
+
+### F-LINK-03: Verknüpfte Dateien in Firmen-Detail anzeigen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** In der Firmen-Detail-Ansicht wird ein Bereich „Verknüpfte Dateien" angezeigt. Listet alle verknüpften Dateien/Ordner mit Name, Typ, Größe und Link zum Öffnen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Firma hat 3 verknüpfte Dateien → Bereich „Verknüpfte Dateien" zeigt alle 3 mit Name, Größe, Datum.
+2. **Edge Case:** Firma hat keine verknüpften Dateien → Empty-State „Keine Dateien verknüpft" mit Button.
+3. **Edge Case:** User klickt auf verknüpfte Datei → Datei-Preview oder Download wird geöffnet.
+
+**Akzeptanzkriterium:** Verknüpfte Dateien werden in Firmen-Detail angezeigt; Empty-State bei keinen Dateien; Klick öffnet Preview/Download.
+
+---
+
+### F-LINK-04: Verknüpfte Dateien in Kontakt-Detail anzeigen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** In der Kontakt-Detail-Ansicht wird ein Bereich „Verknüpfte Dateien" angezeigt. Analog zu F-LINK-03.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Kontakt hat 2 verknüpfte Dateien → Bereich zeigt beide mit Metadaten.
+2. **Edge Case:** Kontakt hat keine verknüpften Dateien → Empty-State mit Verknüpfen-Button.
+3. **Edge Case:** Verknüpfte Datei wurde gelöscht (Soft-Delete) → erscheint nicht mehr in der Liste.
+
+**Akzeptanzkriterium:** Verknüpfte Dateien werden in Kontakt-Detail angezeigt; Empty-State bei keinen Dateien; Soft-Delete-Dateien ausgeblendet.
+
+---
+
+### F-LINK-05: Reverse-Verknüpfung (Datei zeigt verknüpfte Entitäten) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** In der Datei-Detail-Ansicht wird angezeigt, mit welchen Entitäten (Firmen, Kontakte) die Datei verknüpft ist. Verknüpfungen können hier auch gelöst werden.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Datei ist mit 2 Firmen und 1 Kontakt verknüpft → Datei-Detail zeigt alle 3 Entitäten mit Name und Typ.
+2. **Edge Case:** User löst Verknüpfung → Verknüpfung wird entfernt, Entität verschwindet aus der Liste.
+3. **Edge Case:** Datei hat keine Verknüpfungen → Empty-State mit Button „Mit Entität verknüpfen".
+
+**Akzeptanzkriterium:** Datei-Detail zeigt verknüpfte Entitäten; Verknüpfungen können gelöst werden; Empty-State bei keinen Verknüpfungen.
+
+---
+
+### F-LINK-06: Mehrfach-Verknüpfung (Datei mit mehreren Entitäten) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Eine Datei/Ordner kann mit mehreren Entitäten gleichzeitig verknüpft sein (N:M). Es gibt keine Beschränkung der Anzahl an Verknüpfungen pro Datei.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Datei wird mit 5 Firmen und 3 Kontakten verknüpft → alle 8 Verknüpfungen sind in DB, alle sichtbar in Datei-Detail.
+2. **Edge Case:** User verknüpft Ordner mit Firma → Ordner-Verknüpfung funktioniert, alle Dateien im Ordner werden in Firmen-Detail als „verknüpft über Ordner" angezeigt.
+3. **Edge Case:** Bulk-Verknüpfung: User wählt 10 Dateien und verknüpft alle mit einer Firma → 10 Relationen werden erstellt.
+
+**Akzeptanzkriterium:** N:M-Verknüpfung ohne Beschränkung; Ordner-Verknüpfung funktioniert; Bulk-Verknüpfung unterstützt.
+
+---
+
+### F-TAG-01: Tags auf Entitäten anwenden [v2-Plugin]
+**Plugin:** Tags
+**Anforderung:** Tags können auf Dateien, Ordner, Firmen und Kontakte angewendet werden. Tags sind global (zentral verwaltet, nicht pro User). Mehrere Tags pro Entität möglich.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User taggt Firma mit „Wichtig" und „Kunde" → beide Tags erscheinen in Firmen-Detail und Firmen-Liste.
+2. **Edge Case:** User taggt Datei mit bereits zugewiesenen Tag → Idempotent, kein Duplikat.
+3. **Edge Case:** User entfernt Tag von Entität → Tag wird entfernt, andere Entitäten mit gleichen Tag bleiben unberührt.
+
+**Akzeptanzkriterium:** Tags können auf Entitäten angewendet werden; Idempotent; Entfernen eines Tags beeinflusst andere Entitäten nicht.
+
+---
+
+### F-TAG-02: Tag-Verwaltung (CRUD + Farbe) [v2-Plugin]
+**Plugin:** Tags
+**Anforderung:** Tag-Verwaltungs-Seite unter Einstellungen. Tags können erstellt, umbenannt, gelöscht und mit einer Farbe versehen werden. Tags sind global — Änderungen wirken sich auf alle Entitäten aus.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin erstellt Tag „VIP" mit Farbe → Tag erscheint in Tag-Liste, kann auf Entitäten angewendet werden.
+2. **Edge Case:** Admin löscht Tag → Tag wird von allen Entitäten entfernt (Cascade Delete), Bestätigungsdialog zeigt Anzahl betroffener Entitäten.
+3. **Edge Case:** Non-Admin versucht Tag zu erstellen → Zugriff verweigert (nur Admin kann Tags verwalten).
+
+**Akzeptanzkriterium:** Tag-CRUD durch Admin; Farbe zuweisbar; Cascade Delete bei Tag-Löschung; Non-Admin hat keinen Zugriff.
+
+---
+
+### F-TAG-03: Tag-Filterung in allen Listen [v2-Plugin]
+**Plugin:** Tags
+**Anforderung:** In allen Listen-Ansichten (Firmen, Kontakte, Dateien, Ordner) kann nach Tags gefiltert werden. Mehrere Tags können kombiniert werden (AND / OR Filter).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User filtert Firmen-Liste nach Tag „Kunde" → nur Firmen mit Tag „Kunde" werden angezeigt.
+2. **Integration:** User filtert nach Tags „Kunde" AND „Wichtig" → nur Firmen mit beiden Tags werden angezeigt.
+3. **Edge Case:** User filtert nach Tag, der auf keine Entität angewendet wurde → Empty-State „Keine Ergebnisse".
+
+**Akzeptanzkriterium:** Tag-Filter in allen Listen; AND/OR-Kombination; Empty-State bei keinen Treffern.
+
+---
+
+### F-TAG-04: Tag-Cloud / Tag-Sidebar zur schnellen Navigation [v2-Plugin]
+**Plugin:** Tags
+**Anforderung:** Eine Tag-Sidebar (oder Tag-Cloud) zeigt alle verfügbaren Tags mit der Anzahl zugewiesener Entitäten. Klick auf ein Tag filtert die aktuelle Liste. Größere Tags = mehr Zuweisungen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Tag-Sidebar zeigt „Kunde (15)", „Wichtig (3)", „VIP (1)" → Klick auf „Kunde" → Liste wird gefiltert.
+2. **Edge Case:** Tag mit 0 Zuweisungen → wird ausgegraut oder ausgeblendet (konfigurierbar).
+3. **Edge Case:** Tag-Sidebar ist in allen Listen-Ansichten sichtbar.
+
+**Akzeptanzkriterium:** Tag-Sidebar mit Counts; Klick filtert Liste; Tags mit 0 Zuweisungen ausblendbar; sichtbar in allen Listen.
+
+---
+
+### F-PERM-01: Persönlicher Root-Ordner pro User [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Jeder User hat einen persönlichen Root-Ordner („Mein Bereich"), der nur für ihn sichtbar ist. Andere User haben keinen Zugriff darauf, außer es wird explizit geteilt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Neuer User wird angelegt → persönlicher Root-Ordner wird automatisch erstellt → User sieht nur seinen eigenen Bereich.
+2. **Edge Case:** User A versucht, auf persönlichen Ordner von User B zuzugreifen → Zugriff verweigert.
+3. **Edge Case:** Admin kann alle persönlichen Ordner einsehen (Admin hat Leserecht auf alles).
+
+**Akzeptanzkriterium:** Persönlicher Ordner wird bei User-Anlage automatisch erstellt; Ownership-Check verhindert Cross-User-Access; Admin hat Leserecht.
+
+---
+
+### F-PERM-02: Gemeinsame Root-Ordner für Teams/Abteilungen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Admin kann gemeinsame Root-Ordner für Teams oder Abteilungen erstellen. Mitglieder der entsprechenden Gruppe haben Lese- oder Schreibzugriff.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin erstellt gemeinsamen Ordner „Vertrieb" und weist Gruppe „Sales" mit Schreibrecht zu → alle Sales-Mitglieder sehen und können hochladen.
+2. **Edge Case:** User ohne Gruppen-Zugehörigkeit zu „Sales" → kann Ordner nicht sehen → Zugriff verweigert.
+3. **Edge Case:** Admin ändert Berechtigung von „Schreib" auf „Lese" → Sales-Mitglieder können noch sehen, aber nicht mehr hochladen.
+
+**Akzeptanzkriterium:** Gemeinsame Ordner mit Gruppen-Berechtigung (read/write); Nicht-Mitglieder haben keinen Zugriff; Änderung der Berechtigung wirkt sofort.
+
+---
+
+### F-PERM-03: Datei/Ordner mit einzelnen Usern teilen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können einzelne Dateien oder Ordner mit spezifischen Usern teilen, mit Lese- oder Schreib-Rechten. Der Empfänger sieht die geteilte Datei in einem „Geteilt mit mir"-Bereich.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User A teilt Datei mit User B (Schreibrecht) → User B sieht Datei unter „Geteilt mit mir", kann sie bearbeiten.
+2. **Edge Case:** User A teilt mit Lese-Recht → User B kann Datei ansehen aber nicht bearbeiten.
+3. **Edge Case:** User A entzieht Zugriff → User B sieht Datei nicht mehr unter „Geteilt mit mir".
+
+**Akzeptanzkriterium:** Teilen mit einzelnen Usern (read/write); „Geteilt mit mir"-Bereich; Zugriff entziehbar.
+
+---
+
+### F-PERM-04: Datei/Ordner mit User-Gruppen teilen [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können Dateien oder Ordner mit User-Gruppen teilen (Lese- oder Schreib-Rechte). Alle Gruppen-Mitglieder erhalten den Zugriff.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User teilt Ordner mit Gruppe „Marketing" (Lese) → alle Marketing-Mitglieder sehen den Ordner und dessen Inhalt.
+2. **Edge Case:** Neues Mitglied wird Gruppe hinzugefügt → erhält automatisch Zugriff auf alle mit der Gruppe geteilten Dateien.
+3. **Edge Case:** Schreibrecht für Gruppe, aber einzelnes Mitglied soll nur Lesen → Individual-Permission überschreibt Gruppen-Permission (Deny vor Allow).
+
+**Akzeptanzkriterium:** Teilen mit Gruppen (read/write); automatischer Zugriff bei Gruppen-Beitritt; Individual-Permission überschreibt Group-Permission.
+
+---
+
+### F-PERM-05: Share-Links (öffentlich, mit Passwort, mit Ablaufdatum) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können öffentliche Share-Links für Dateien oder Ordner erstellen. Optionen: Passwortschutz, Ablaufdatum, Download-Only oder Preview+Download.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Share-Link für PDF ohne Passwort → Link ist öffentlich zugänglich, PDF wird im Browser angezeigt.
+2. **Edge Case:** Share-Link mit Passwort → externer Besucher muss Passwort eingeben → bei korrektem Passwort Zugriff, bei falschem → verweigert.
+3. **Edge Case:** Share-Link mit Ablaufdatum in der Vergangenheit → Link ist nicht mehr verfügbar.
+
+**Akzeptanzkriterium:** Öffentliche Share-Links; Passwortschutz optional; Ablaufdatum optional; Download-Only oder Preview+Download wählbar; Public-Endpoint ohne Auth.
+
+---
+
+### F-PERM-06: Berechtigungs-Anzeige (Wer hat Zugriff?) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** In der Datei-/Ordner-Detail-Ansicht wird eine Berechtigungs-Übersicht angezeigt: welcher User hat welchen Zugriff (Lese/Schreib), welche Gruppe, welche Share-Links existieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Datei wurde mit 2 Usern und 1 Gruppe geteilt → Berechtigungs-Panel zeigt alle 3 Einträge mit Name und Recht.
+2. **Edge Case:** Datei hat keine Shares → Panel zeigt „Nur Owner" mit Owner-Name.
+3. **Edge Case:** Owner sieht alle Share-Links mit Status (aktiv/abgelaufen/passwortgeschützt).
+
+**Akzeptanzkriterium:** Berechtigungs-Panel zeigt Owner, Shares (User/Gruppe), Share-Links mit Status; bei keinen Shares → „Nur Owner".
+
+---
+
+### F-FILEUI-01: Datei-Browser (Baum-Ansicht + Grid/List) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Datei-Browser mit zweigeteilter Ansicht: Sidebar mit Baum-Ansicht (Ordner-Hierarchie) und Hauptbereich mit Grid- oder List-Ansicht der Dateien des aktuell ausgewählten Ordners. Toggle zwischen Grid und List möglich.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User klickt Ordner in Baum-Ansicht → Hauptbereich zeigt Dateien/Unterordner im gewählten Modus (Grid oder List).
+2. **Edge Case:** Ordner ist leer → Empty-State „Dieser Ordner ist leer" mit Upload-Button.
+3. **Edge Case:** User wechselt von Grid zu List → Darstellung ändert sich, Inhalt bleibt gleich.
+
+**Akzeptanzkriterium:** Baum-Ansicht für Ordner-Hierarchie; Grid/List-Toggle; Empty-State bei leeren Ordnern.
+
+---
+
+### F-FILEUI-02: Breadcrumb-Navigation [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Breadcrumb-Leiste zeigt den aktuellen Pfad (Root > Verträge > 2026). Jedes Segment ist klickbar und navigiert zum entsprechenden Ordner.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User navigiert 3 Level tief → Breadcrumb zeigt „Root > Verträge > 2026", Klick auf „Verträge" navigiert dorthin.
+2. **Edge Case:** Sehr tiefe Verschachtelung (>5 Level) → Breadcrumb zeigt erste 2 + „..." + letzte 2 Segmente, Hover zeigt vollen Pfad.
+3. **Edge Case:** Klick auf „Root" → navigiert zum Root-Ordner des Users.
+
+**Akzeptanzkriterium:** Breadcrumb mit klickbaren Segmenten; tiefe Verschachtelung wird abgekürzt; Root-Klick navigiert zum User-Root.
+
+---
+
+### F-FILEUI-03: Kontext-Menü (Rechtsklick) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Rechtsklick auf Datei/Ordner öffnet Kontext-Menü mit Aktionen: Öffnen, Umbenennen, Verschieben, Löschen, Verknüpfen, Teilen, Tags, Download, Link kopieren. Mobile: Long-Press statt Rechtsklick.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User rechtsklickt auf Datei → Kontext-Menü erscheint mit allen Aktionen → Klick „Umbenennen" → Rename-Dialog öffnet sich.
+2. **Edge Case:** User rechtsklickt auf Ordner → Kontext-Menü zeigt Ordner-spezifische Aktionen.
+3. **Edge Case:** User hat nur Lese-Recht → Kontext-Menü zeigt nur Lese-Aktionen (Öffnen, Download), keine Schreib-Aktionen.
+
+**Akzeptanzkriterium:** Kontext-Menü mit dynamischen Items basierend auf Typ (file/folder) und Permission (read/write); Mobile: Long-Press.
+
+---
+
+### F-FILEUI-04: Bulk-Aktionen (Mehrere Dateien auswählen) [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** User können mehrere Dateien/Ordner per Checkbox oder Shift-Klick auswählen und Bulk-Aktionen ausführen: Verschieben, Löschen, Taggen, Verknüpfen, Download (als ZIP).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User wählt 5 Dateien per Checkbox → klickt „Verschieben" → wählt Zielordner → alle 5 Dateien werden verschoben.
+2. **Edge Case:** User wählt Dateien aus unterschiedlichen Ordnern → Bulk-Delete mit Bestätigungsdialog → alle werden soft-deleted.
+3. **Edge Case:** Bulk-Tag: User wählt 10 Dateien → weist Tag „Archiviert" zu → alle 10 Dateien erhalten den Tag.
+
+**Akzeptanzkriterium:** Multi-Select per Checkbox/Shift-Klick; Bulk-Verschieben, Löschen, Taggen, Verknüpfen, Download (ZIP); Bestätigungsdialog bei destruktiven Aktionen.
+
+---
+
+### F-FILEUI-05: Upload-Progress-Anzeige [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Beim Upload wird ein Progress-Bar pro Datei angezeigt (Prozent, übertragene Bytes / Gesamt-Bytes). Bei mehreren gleichzeitigen Uploads wird eine Upload-Queue mit Gesamt-Progress angezeigt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User lädt 5 MB Datei hoch → Progress-Bar steigt von 0% auf 100%, bei 100% → „Fertig"-Meldung, Datei erscheint in Liste.
+2. **Edge Case:** 3 gleichzeitige Uploads → Queue zeigt 3 Progress-Bars + Gesamt-Progress „2 von 3 fertig".
+3. **Edge Case:** Upload fehlerhaft → Progress-Bar wird rot, Fehler-Toast, Retry-Button.
+
+**Akzeptanzkriterium:** Progress-Bar pro Datei; Upload-Queue für mehrere Uploads; Retry bei Fehlern.
+
+---
+
+### F-FILEUI-06: Drag & Drop zwischen Ordnern [v2-Plugin]
+**Plugin:** DMS
+**Anforderung:** Dateien und Ordner können per Drag & Drop in andere Ordner verschoben werden. Drag-Quelle ist Datei/Ordner, Drop-Ziel ist ein Ordner in der Baum-Ansicht oder im Hauptbereich.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User draggt Datei auf Ordner in Baum-Ansicht → Datei wird in Ordner verschoben, verschwindet aus aktueller Ansicht.
+2. **Edge Case:** User draggt Ordner in anderen Ordner → Ordner wird verschoben inkl. aller Unterordner und Dateien.
+3. **Edge Case:** User draggt Datei auf Ordner mit nur Lese-Recht → Drop wird abgelehnt, Toast „Keine Schreibberechtigung für Zielordner".
+
+**Akzeptanzkriterium:** Drag & Drop funktioniert; visuelles Feedback (grün erlaubt, rot verboten); Permission-Check client- und serverseitig.
+
+---
+
+### F-CAL-01: Kalender-Ansichten (Monat, Woche, Tag) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Kalender-Modul mit drei Ansichten: Monatsansicht (Grid mit Tagen als Zellen, Einträge als Blöcke), Wochenansicht (7-Spalten-Grid mit Stunden-Skala), Tagesansicht (Stunden-Skala mit Eintrag-Blöcken). Toggle zwischen Ansichten. Navigation: Vor/Zurück, „Heute"-Button. Termine (appointment) werden als zeitliche Blöcke angezeigt; Aufgaben (task) werden als Badges/Marker am Fälligkeitsdatum angezeigt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User öffnet Kalender → Monatsansicht wird geladen, aktueller Monat, „Heute" ist hervorgehoben. User klickt „Woche" → Wochenansicht mit 7 Spalten und Stunden-Skala wird angezeigt. Ein Termin 14:00–15:00 als Block, ein Task fällig um 10:00 als Badge.
+2. **Edge Case:** Monatsansicht mit 0 Einträgen → Zellen sind leer, kein Fehler.
+3. **Edge Case:** User navigiert 3 Monate vor → Kalender zeigt korrekten Monat mit Wochentagen. Klick „Heute" → springt zurück zum aktuellen Monat.
+
+**Akzeptanzkriterium:** Drei Ansichten (Monat/Woche/Tag) mit Toggle; Navigation (Vor/Zurück/Heute); Termine als Blöcke, Aufgaben als Badges; Empty-State bei 0 Einträgen.
+
+---
+
+### F-CAL-02: Kanban-Zeitraum-Ansicht [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Zusätzliche Kalender-Ansicht als Kanban-Board: Spalten = Tage oder Zeiträume (konfigurierbar: diese Woche, nächste 2 Wochen, dieser Monat). Sowohl Termine (appointment) als auch Aufgaben (task) erscheinen als Karten in der Spalte ihres Datums. Karten zeigen Titel, Zeit/Fälligkeit, Typ-Farbe, verknüpfte Entität. Für task-Karten wird zusätzlich Priorität und Status angezeigt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User wählt Zeitraum „Diese Woche" → Kanban zeigt 7 Spalten (Mo–So). Ein Termin am Mi 14:00 und ein Task fällig Fr erscheinen als Karten in ihren jeweiligen Spalten.
+2. **Edge Case:** User wählt „Nächste 2 Wochen" → 14 Spalten werden angezeigt (horizontal scrollbar), Einträge korrekt zugeordnet.
+3. **Edge Case:** Tag ohne Einträge → Spalte ist leer, zeigt Datum nur.
+
+**Akzeptanzkriterium:** Kanban-Board mit konfigurierbaren Zeiträumen; Termine und Aufgaben als Karten; horizontales Scroll bei langen Zeiträumen; leere Spalten zeigen Datum.
+
+---
+
+### F-CAL-03: Kalender-Eintrag erstellen (Termin oder Aufgabe) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** User kann Kalender-Einträge erstellen. Beim Erstellen wird der Typ gewählt:
+- **Typ `appointment`:** Titel (Pflicht), Beschreibung, Start (Datum+Zeit), Ende (Datum+Zeit), Ganztägig-Option, Ort, Teilnehmer (Kontakte und/oder User)
+- **Typ `task`:** Titel (Pflicht), Beschreibung, Fälligkeitsdatum (due_date, Datum — optional mit Uhrzeit), Priorität (hoch/mittel/niedrig), Status (Default: offen)
+
+Beide Typen unterstützen: Verknüpfung mit Entitäten, Erinnerungen, Wiederholung, Kalender-Zuweisung.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (appointment):** User erstellt Termin „Meeting mit ACME" von 14:00–15:00, Ort „Büro", Teilnehmer: Kontakt „Max Mustermann" → Termin wird gespeichert, im Kalender sichtbar.
+2. **Happy Path (task):** User erstellt Aufgabe „Angebot vorbereiten" mit Fälligkeit morgen, Priorität „hoch" → Aufgabe wird gespeichert, erscheint im Kalender als Badge am Fälligkeitsdatum und im Kanban-Board.
+3. **Edge Case (appointment):** Ende liegt vor Start → Validierungsfehler „Ende muss nach Start liegen".
+4. **Edge Case (task):** Aufgabe ohne Fälligkeitsdatum → wird gespeichert, im Kalender ohne Datum angezeigt.
+5. **Edge Case (both):** Eintrag ohne Titel → Validierungsfehler „Titel ist Pflichtfeld".
+
+**Akzeptanzkriterium:** Erstellen von Terminen und Aufgaben; Pflichtfeld-Validierung (Titel); End > Start bei Terminen; Aufgaben ohne Fälligkeit möglich; beide Typen unterstützen Verknüpfung, Erinnerung, Wiederholung, Kalender-Zuweisung.
+
+---
+
+### F-CAL-04: Kalender-Einträge mit Entitäten verknüpfen [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Kalender-Einträge (sowohl Termine als auch Aufgaben) lassen sich mit Firmen, Kontakten und (zukünftigen) Deals verknüpfen. Mehrfach-Verknüpfung möglich. In Firmen-Detail und Kontakt-Detail wird ein Bereich „Anstehende Termine & Aufgaben" angezeigt. Aufgaben erscheinen dort als „Offene Aufgaben", Termine als „Anstehende Termine".
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (appointment):** User erstellt Termin und verknüpft mit Firma „ACME" und Kontakt „Max" → Termin erscheint in Firmen-Detail unter „Anstehende Termine" und in Kontakt-Detail.
+2. **Happy Path (task):** User erstellt Aufgabe und verknüpft mit Firma „ACME" → Aufgabe erscheint in Firmen-Detail unter „Offene Aufgaben".
+3. **Edge Case:** User verknüpft Eintrag mit 3 verschiedenen Entitäten → alle Verknüpfungen werden gespeichert, alle Detail-Ansichten zeigen den Eintrag.
+4. **Edge Case (task):** Aufgabe wird als erledigt markiert → verschwindet aus „Offene Aufgaben", bleibt in historischer Ansicht.
+5. **Edge Case:** Eintrag wird gelöscht → Verknüpfungen werden entfernt (Cascade Delete).
+
+**Akzeptanzkriterium:** Mehrfach-Verknüpfung mit Firmen/Kontakten; Detail-Ansichten zeigen anstehende Termine und offene Aufgaben; erledigte Aufgaben verschwinden aus „Offene"; Cascade Delete bei Eintrag-Löschung.
+
+---
+
+### F-CAL-05: Drag & Drop im Kalender (Termine + Kanban) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Termine können im Kalender per Drag & Drop verschoben werden. Ziehen verschiebt Start und Ende um den gleichen Delta. In Wochen-/Tagesansicht: vertikales Ziehen ändert Uhrzeit, horizontales Ziehen ändert Tag. Resize-Griff ändert Dauer. Im Kanban-Board: Drag & Drop von Task-Karten zwischen Status-Spalten (Offen → In Bearbeitung → Erledigt → Abgebrochen) ändert den Status.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (appointment):** User draggt Termin von 14:00 auf 16:00 → Termin wird auf 16:00–17:00 verschoben, Kalender aktualisiert sich sofort.
+2. **Happy Path (kanban):** User draggt Task-Karte von „Offen" nach „In Bearbeitung" → Status ändert sich, Karte erscheint in neuer Spalte.
+3. **Edge Case (appointment):** User draggt Termin auf anderen Tag → Start- und Enddatum ändern sich, Uhrzeit bleibt gleich.
+4. **Edge Case (kanban):** User draggt Task nach „Erledigt" → Status wird gesetzt, Fälligkeitsdatum wird farblich markiert (rechtzeitig=grün, überfällig=rot).
+5. **Edge Case (appointment):** User resized Termin-Block von 1 Stunde auf 3 Stunden → End-Zeit wird aktualisiert, nur dieser Termin betroffen.
+
+**Akzeptanzkriterium:** Drag & Drop verschiebt Termine (Zeit und Tag); Resize ändert Dauer; Kanban-Drag ändert Task-Status; Optimistic Update mit Rollback bei Fehler.
+
+---
+
+### F-CAL-06: Farbcodierung nach Eintrags-Typ [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Kalender-Einträge haben einen Typ, der die Farbe bestimmt: Termin (blau), Aufgabe (gelb), Follow-up (orange), Privat (grau). Farbe wird im Kalender als Block-/Badge-Hintergrund angezeigt. Typ ist bei Erstellung wählbar, nachträglich änderbar. Der grundlegende Typ (appointment/task) bestimmt die Grundfarbe, das Subtyp-Feld (follow_up, private) kann die Farbe weiter differenzieren.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Termin mit Subtyp „Follow-up" → Block im Kalender ist orange. User ändert Subtyp auf „Privat" → Block wird grau.
+2. **Edge Case:** Task wird erstellt → automatisch gelb (Typ „Aufgabe"), ohne manuelle Zuweisung. Subtyp follow_up ändert auf orange.
+3. **Edge Case:** Alle Einträge einer Woche haben unterschiedliche Subtypen → Block-Farben entsprechen Zuweisung, Legende zeigt Farb-Bedeutung.
+
+**Akzeptanzkriterium:** Grundfarbe durch entry_type (appointment=blau, task=gelb); Subtyp-Differenzierung (follow_up=orange, private=grau); Farbe im Kalender sichtbar; Legende vorhanden.
+
+---
+
+### F-CAL-07: Erinnerungen/Alerts (für Termine und Aufgaben) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Pro Kalender-Eintrag kann eine Erinnerung konfiguriert werden: X Minuten/Stunden/Tage vorher. Für Termine: vor Start-Zeit. Für Aufgaben: vor Fälligkeitsdatum. Erinnerung wird als In-App-Notification angezeigt. Optional E-Mail-Reminder. Default: 15 Minuten (Termine) bzw. 1 Tag (Aufgaben).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (appointment):** User erstellt Termin in 30 Minuten, setzt Erinnerung auf „15 Minuten vorher" → nach 15 Minuten erscheint In-App-Notification „Termin in 15 Minuten: Meeting".
+2. **Happy Path (task):** Task mit Fälligkeit morgen, Erinnerung „1 Tag vorher" → heute erscheint In-App-Notification „Aufgabe fällig morgen: Angebot vorbereiten".
+3. **Edge Case (task):** Task ist überfällig (due_date in Vergangenheit, Status≠erledigt) → tägliche Erinnerung „Überfällig: X Tage" bis erledigt.
+4. **Edge Case:** Eintrag ohne Erinnerung → keine Notification wird gesendet.
+
+**Akzeptanzkriterium:** Erinnerung pro Eintrag konfigurierbar (Wert + Einheit + Channel); In-App-Notification bei Fälligkeit; überfällige Aufgaben erinnern täglich; Default-Werte für Termine (15min) und Aufgaben (1 Tag).
+
+---
+
+### F-CAL-08: Wiederkehrende Kalender-Einträge (Termine + Aufgaben) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Sowohl Termine als auch Aufgaben können als wiederkehrend definiert werden: täglich, wöchentlich, monatlich, jährlich, oder custom (z.B. jeden 2. Dienstag). Termine generieren Instanzen bis zu einem Enddatum (max. 2 Jahre). Aufgaben generieren die nächste Instanz bei Erledigung (nicht on-the-fly, sondern Post-Completion).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (appointment):** User erstellt wöchentlichen Termin „Team-Meeting" jeden Mi 10:00, Enddatum in 3 Monaten → 13 Instanzen werden im Kalender angezeigt.
+2. **Happy Path (task):** User erstellt wöchentliche Aufgabe „Weekly Report" fällig jeden Freitag → nach Erledigung am Freitag wird automatisch neue Aufgabe für nächsten Freitag generiert.
+3. **Edge Case (appointment):** User ändert eine einzelne Instanz → nur diese Instanz ändert sich, andere bleiben unverändert.
+4. **Edge Case (task):** User markiert wiederkehrende Aufgabe als „abgebrochen" → keine neue Instanz wird generiert.
+5. **Edge Case (task):** Wiederkehrende Aufgabe überfällig → alte Aufgabe bleibt offen, neue Instanz wird nicht generiert bis alte erledigt ist.
+
+**Akzeptanzkriterium:** Wiederkehrende Termine generieren Instanzen bis Enddatum; wiederkehrende Aufgaben generieren nächste Instanz bei Erledigung; Exception-Handling für einzelne Instanzen; Abbruch stoppt Generierung; keine Duplikate bei überfälligen Aufgaben.
+
+---
+
+### F-CAL-09: Kalender-Feeds (ICS-Export/Import) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** User können ihre Kalender als ICS-Feed exportieren (public URL, authentifiziert oder mit Token). Import von ICS-Dateien erstellt Einträge. ICS-Feed ist lesbar von externen Kalendern (Google Calendar, Apple Calendar, Outlook). Export pro Kalender (nicht global).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User kopiert ICS-Feed-URL für Kalender „Persönlich" → fügt in Google Calendar ein → Termine erscheinen in Google Calendar.
+2. **Edge Case:** User importiert ICS-Datei mit 10 Terminen → alle 10 werden als neue Einträge angelegt, Duplikate (gleicher Titel+Zeit) werden erkannt und übersprungen.
+3. **Edge Case:** ICS-Feed ohne Token → Zugriff verweigert; mit Token → Zugriff erlaubt.
+
+**Akzeptanzkriterium:** ICS-Export pro Kalender mit Token-Auth; ICS-Import mit Duplikat-Erkennung; kompatibel mit Google Calendar, Apple Calendar, Outlook.
+
+---
+
+### F-CAL-10: Ressourcen-Booking (Räume, Equipment) [v2-Plugin — später]
+**Plugin:** Kalender
+**Anforderung:** Ressourcen (Räume, Equipment) können verwaltet und für Termine gebucht werden. Konflikt-Erkennung: Doppelbuchungen werden verhindert. Optional für später (post-v2).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Termin und bucht Ressource „Konferenzraum A" → Ressource ist für diesen Zeitraum gebucht, andere User sehen Konflikt-Warnung.
+2. **Edge Case:** Zweiter User versucht, „Konferenzraum A" im gleichen Zeitraum zu buchen → Fehler „Ressource bereits gebucht".
+3. **Edge Case:** Ressource wird gelöscht → alle Buchungen werden als „Ressource nicht mehr verfügbar" markiert, Termine bleiben erhalten.
+
+**Akzeptanzkriterium:** Ressourcen-Verwaltung (Admin); Buchung für Termine; Konflikt-Erkennung bei Doppelbuchung; Priorität: später (post-v2).
+
+---
+
+### F-CAL-11: Mehrere Kalender erstellen/verwalten [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** User können mehrere Kalender erstellen und verwalten. Jeder Kalender hat: Name, Farbe, Typ (persönlich/team/projekt/firma). Ein persönlicher Kalender wird bei User-Anlage automatisch erstellt. Admin kann Team-/Firmen-Kalender anlegen. Jeder Kalender-Eintrag wird genau einem Kalender zugewiesen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Kalender „Projekt Alpha" (Farbe: lila, Typ: projekt) → Kalender erscheint in Kalender-Liste, User kann Einträge darin erstellen.
+2. **Edge Case:** Neuer User wird angelegt → persönlicher Kalender „Mein Kalender" wird automatisch erstellt (Default-Farbe: blau).
+3. **Edge Case:** Admin erstellt Firmen-Kalender „ACME Events" → alle User sehen den Kalender in ihrer Liste, können ihn abonnieren.
+
+**Akzeptanzkriterium:** Kalender-CRUD mit Name, Farbe, Typ; persönlicher Kalender wird bei User-Anlage automatisch erstellt; Firmen-Kalender für alle User sichtbar; Einträge werden genau einem Kalender zugewiesen.
+
+---
+
+### F-CAL-12: Kalender abonnieren/anzeigen (ein/ausschalten) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** User können mehrere Kalender gleichzeitig anzeigen. Jeder Kalender kann ein-/ausgeschaltet werden (Toggle). Die Farbe des Kalenders wird für die Einträge übernommen (sofern kein Subtyp-Override). Sichtbare Kalender werden in der Kalender-Sidebar aufgelistet.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User hat 3 Kalender → schaltet „Team" aus → nur noch Einträge aus „Persönlich" und „Projekt Alpha" werden im Kalender angezeigt.
+2. **Edge Case:** User schaltet alle Kalender aus → Kalender ist leer, Hinweis „Keine Kalender ausgewählt".
+3. **Edge Case:** User schaltet Kalender „Projekt Alpha" ein → Einträge erscheinen in der Farbe des Kalenders.
+
+**Akzeptanzkriterium:** Toggle-Switches pro Kalender; Sichtbarkeit clientseitig gefiltert; Sichtbarkeit pro User persistiert; leere Auswahl zeigt Hinweis.
+
+---
+
+### F-CAL-13: Kalender teilen (mit Usern/Gruppen) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Kalender können mit einzelnen Usern oder User-Gruppen geteilt werden (Lese- oder Schreib-Rechte). Owner kann Kalender freigeben und Rechte verwalten.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User A teilt Kalender „Projekt Alpha" mit User B (Schreibrecht) → User B sieht Kalender, kann Einträge erstellen/bearbeiten.
+2. **Edge Case:** User A teilt mit Lese-Recht → User B kann Einträge sehen, aber nicht erstellen/bearbeiten.
+3. **Edge Case:** User A entzieht Zugriff → User B sieht Kalender nicht mehr in seiner Liste.
+
+**Akzeptanzkriterium:** Teilen mit Usern/Gruppen (read/write); Schreib-Zugriff ermöglicht Eintrag-Erstellung; Zugriff entziehbar.
+
+---
+
+### F-CAL-14: Default-Kalender für neue Einträge [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Beim Erstellen eines neuen Eintrags wird der Default-Kalender vorausgewählt. User kann einen Default-Kalender in den Einstellungen definieren. Wenn kein Default gesetzt ist, wird der persönliche Kalender verwendet.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User hat Default-Kalender auf „Projekt Alpha" gesetzt → beim Erstellen eines neuen Eintrags ist „Projekt Alpha" vorausgewählt.
+2. **Edge Case:** User hat keinen Default-Kalender gesetzt → persönlicher Kalender wird vorausgewählt.
+3. **Edge Case:** Default-Kalender wurde gelöscht → System fällt auf persönlichen Kalender zurück, Setting wird zurückgesetzt.
+
+**Akzeptanzkriterium:** User-Setting für Default-Kalender; Fallback auf persönlichen Kalender; gelöschter Default → Reset auf Fallback.
+
+---
+
+### F-CAL-15: Aufgaben-Zuweisung (Zuständiger) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Aufgaben (task-Einträge) können einem User zugewiesen werden („Zuständiger"). Nur ein User pro Aufgabe. User sieht zugewiesene Aufgaben in „Meine Aufgaben"-View. Bei Erstellung kann User sich selbst oder anderen User zuweisen. Zuständiger erhält In-App-Notification bei Zuweisung.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin weist Aufgabe User „Leon" zu → Leon sieht Aufgabe unter „Meine Aufgaben", bekommt In-App-Notification.
+2. **Edge Case:** Aufgabe ohne Zuständigen → erscheint in „Nicht zugewiesen"-Filter, kein User bekommt Notification.
+3. **Edge Case:** Zuweisung wird geändert (Leon → Anna) → Leon sieht Aufgabe nicht mehr unter „Meine Aufgaben", Anna bekommt Notification.
+
+**Akzeptanzkriterium:** Ein User pro Aufgabe zuweisbar; „Meine Aufgaben"-View; In-App-Notification bei Zuweisung; Änderung aktualisiert beide User.
+
+---
+
+### F-CAL-16: Sub-Tasks (Checkliste innerhalb einer Aufgabe) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Innerhalb einer Aufgabe (task-Eintrag) können Sub-Tasks als Checkliste hinzugefügt werden. Sub-Task: Titel + erledigt-Flag. Fortschrittsanzeige: „3 von 5 erledigt". Parent-Aufgabe gilt nicht automatisch als erledigt, wenn alle Sub-Tasks erledigt sind (User muss manuell erledigen).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User fügt 3 Sub-Tasks zu Aufgabe hinzu → Checkliste erscheint in Detail-Ansicht, User hakt erste ab → „1 von 3 erledigt" wird angezeigt.
+2. **Edge Case:** Alle Sub-Tasks abgehakt → Progress zeigt „3 von 3 erledigt", Parent-Task-Status bleibt „offen" (keine Auto-Erledigung).
+3. **Edge Case:** Sub-Task wird gelöscht → Fortschrittsanzeige aktualisiert sich.
+
+**Akzeptanzkriterium:** Sub-Tasks als Checkliste; Fortschrittsanzeige (X von Y erledigt); keine Auto-Erledigung des Parent-Tasks; Sub-Task löschbar.
+
+---
+
+### F-CAL-17: Aufgaben-Filter, Sortierung & Liste (DataTable + Kanban) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** Aufgaben (task-Einträge) können in zwei Ansichten betrachtet werden:
+1. **Kanban-Board:** 4 Spalten (Offen, In Bearbeitung, Erledigt, Abgebrochen) mit Drag & Drop. Karten sortiert nach Priorität (hoch oben).
+2. **DataTable-Liste:** Spalten: Titel, Status, Priorität, Fälligkeit, Zuständiger, Verknüpfte Entität. Sortierung nach jeder Spalte. Pagination. Export als CSV.
+
+Filter für beide Ansichten: nach Zuständigem, Priorität, Status, Fälligkeitsdatum (heute, diese Woche, überfällig, ohne Datum). Filter kombinierbar.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path (kanban):** User öffnet Kanban-Board → 4 Spalten, Tasks als Karten mit Titel, Priorität-Badge, Fälligkeit, Zuständiger-Avatar.
+2. **Happy Path (liste):** User sortiert nach Fälligkeitsdatum aufsteigend → älteste/fälligste Tasks oben.
+3. **Edge Case (filter):** User filtert nach Status „Offen" + Priorität „hoch" → nur offene hoch-priorisierte Tasks.
+4. **Edge Case (filter):** User filtert nach „Überfällig" → nur Tasks mit due_date < heute und Status ≠ erledigt/abgebrochen.
+5. **Edge Case (export):** User exportiert gefilterte Task-Liste als CSV → Download startet, CSV enthält genau die gefilterten Tasks.
+
+**Akzeptanzkriterium:** Kanban-Board (4 Spalten) und DataTable-Liste; Filter kombinierbar (Zuständiger, Priorität, Status, Fälligkeit); Sortierung nach jeder Spalte; Pagination; CSV-Export der gefilterten Liste.
+
+---
+
+### F-CAL-18: Bulk-Aktionen (mehrere Aufgaben) [v2-Plugin]
+**Plugin:** Kalender
+**Anforderung:** User können mehrere Aufgaben gleichzeitig auswählen und Bulk-Aktionen ausführen: Status ändern, neu zuweisen, Fälligkeitsdatum setzen, löschen.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User wählt 5 offene Tasks → klickt „Status: Erledigt" → alle 5 werden auf erledigt gesetzt.
+2. **Edge Case:** User wählt 3 Tasks und weist alle User „Anna" zu → alle 3 Tasks werden Anna zugewiesen, Anna bekommt 1 Sammel-Notification.
+3. **Edge Case:** User wählt 0 Tasks und klickt Bulk-Aktion → Button ist deaktiviert.
+
+**Akzeptanzkriterium:** Multi-Select mit Checkbox; Bulk-Status-Änderung, Zuweisung, Fälligkeit, Löschung; Button deaktiviert bei 0 Auswahl; Sammel-Notification bei Zuweisung.
+
+---
+
+### F-MAIL-01: Standard-Ordner (Posteingang, Postausgang, Entwürfe, Spam) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** System stellt Standard-Ordner bereit, die mit IMAP-Server-Ordnern synchronisiert werden. User sieht Posteingang, Postausgang, Entwürfe und Spam. Jede Mail wird genau einem Ordner zugeordnet. IMAP-Flags werden bidirektional synchronisiert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Neue Mail trifft im IMAP-INBOX ein → Mail erscheint innerhalb von 5 Sekunden im Posteingang, ist als ungelesen markiert.
+2. **Edge Case:** User markiert Mail als gelesen im leocrm → Mail erscheint auf anderen IMAP-Clients als gelesen.
+3. **Integration:** User verschiebt Mail von Posteingang nach Spam → Mail verschwindet aus Posteingang, erscheint in Spam, Server wird synchronisiert.
+
+**Akzeptanzkriterium:** Standard-Ordner (Posteingang, Postausgang, Entwürfe, Spam); bidirektionale IMAP-Sync; neue Mails innerhalb von 5 Sekunden sichtbar.
+
+---
+
+### F-MAIL-02: E-Mail schreiben, antworten, weiterleiten (HTML-Editor) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann neue E-Mails schreiben, auf Mails antworten (Reply/Reply-All) und Mails weiterleiten (Forward). HTML-Editor mit Rich-Text-Funktionen (Fett, Kursiv, Links, Listen, Bilder inline). Empfänger-Feld mit Autovervollständigung aus Kontakten. CC/BCC-Felder. SMTP-Versand über konfiguriertes Postfach.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User schreibt neue Mail an kontakt@firma.de mit Betreff „Angebot" und HTML-Body → Mail wird per SMTP gesendet, erscheint im Postausgang.
+2. **Edge Case:** User antwortet auf Mail → Original-Mail wird als Zitat eingefügt, Empfänger wird vorausgefüllt, Betreff bekommt „Re:"-Präfix.
+3. **Edge Case:** User weiterleitet Mail → Original-Mail inkl. Anhänge wird weitergeleitet, Betreff bekommt „Fwd:"-Präfix.
+4. **Edge Case:** SMTP-Fehler (Server nicht erreichbar) → Fehler-Toast, Mail bleibt im Entwürfe-Ordner gespeichert.
+
+**Akzeptanzkriterium:** Neue Mail schreiben, Reply, Reply-All, Forward; HTML-Editor mit Rich-Text; Autovervollständigung aus Kontakten; CC/BCC; SMTP-Versand; Fehler-Behandlung mit Entwurf-Speicherung.
+
+---
+
+### F-MAIL-03: Volltext-Suche über alle Mails, Ordner, Anhänge [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann über alle Mails suchen (Absender, Empfänger, Betreff, Body, Anhänge-Namen). Ergebnisse sind nach Relevanz sortiert. Filter nach Ordner, Datum-Range, Absender möglich.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User sucht nach „Angebot" → alle Mails mit „Angebot" in Betreff/Body werden gelistet, Highlight im Ergebnis.
+2. **Edge Case:** User sucht nach Anhang-Namen „vertrag.pdf" → Mail mit diesem Anhang wird gefunden.
+3. **Edge Case:** Suche ohne Ergebnis → Empty-State „Keine Mails gefunden".
+4. **Edge Case:** User filtert Suche nach Ordner „Posteingang" + Datum „letzte 7 Tage" → nur Mails aus Posteingang der letzten 7 Tage.
+
+**Akzeptanzkriterium:** Volltext-Suche über Mails und Anhang-Namen; Relevanz-Sortierung; Filter nach Ordner, Datum, Absender; Empty-State bei keinen Treffern; performant bei 10.000 Mails.
+
+---
+
+### F-MAIL-04: Anhänge (hochladen, herunterladen, inline anzeigen) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** E-Mails können Anhänge enthalten. Beim Senden werden Anhänge mitversendet. Beim Empfang werden Anhänge extrahiert und im DMS gespeichert. Inline-Bilder (Content-ID) werden im HTML-Body angezeigt. User kann Anhänge herunterladen. Attachment-Preview für PDF/Bilder im Browser.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User sendet Mail mit PDF-Anhang → Empfänger erhält Mail mit Anhang, Anhang erscheint in empfangener Mail als Download-Link.
+2. **Edge Case:** User empfängt Mail mit inline-Bild → Bild wird im HTML-Body an der richtigen Position angezeigt.
+3. **Edge Case:** User lädt Anhang herunter → Datei wird heruntergeladen, Dateigröße stimmt mit Original überein.
+4. **Edge Case:** Anhang größer als 25 MB → Fehler „Anhang zu groß (max 25 MB)".
+
+**Akzeptanzkriterium:** Anhänge senden und empfangen; Inline-Bilder korrekt positioniert; Download funktioniert; Max-Size-Validierung (25 MB pro Anhang, 50 MB pro Mail); Anhänge werden im DMS gespeichert.
+
+---
+
+### F-MAIL-05: Threading (Konversationen gruppieren) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** Mails werden als Konversationen (Threads) gruppiert. Gruppierung basiert auf Mail-Headern (References, In-Reply-To). User kann zwischen Thread-Ansicht (gruppiert) und Listen-Ansicht (flach) umschalten. In Thread-Ansicht: aufklappbare Konversationen mit allen Antworten.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User sendet Mail, erhält Antwort, antwortet erneut → alle 3 Mails erscheinen als eine Konversation in Thread-Ansicht, aufklappbar.
+2. **Edge Case:** Mail ohne References-Header → erscheint als eigener Thread.
+3. **Edge Case:** User schaltet von Thread- zu Listen-Ansicht → alle Mails werden flach gelistet, chronologisch sortiert.
+4. **Edge Case:** Thread mit 20 Mails → Thread-Anzeige zeigt „20 Nachrichten", aufklappen zeigt alle.
+
+**Akzeptanzkriterium:** Thread-Gruppierung basierend auf Mail-Headern; Toggle zwischen Thread- und Listen-Ansicht; aufklappbare Konversationen; große Threads werden zusammengefasst.
+
+---
+
+### F-MAIL-06: Vorlagen/Templates (wiederverwendbare E-Mails) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann E-Mail-Vorlagen erstellen: Betreff + HTML-Body mit Platzhaltern (z.B. Kontakt-Vorname, Firmen-Name, User-Signatur). Vorlagen sind pro User privat oder pro Organisation geteilt. Beim Schreiben kann User Vorlage auswählen → Platzhalter werden mit Kontakt/Firma-Daten ersetzt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Vorlage „Angebot Template" mit Platzhalter für Firmen-Name → wählt Vorlage beim Schreiben an ACME GmbH → Platzhalter wird durch „ACME GmbH" ersetzt.
+2. **Edge Case:** User wählt Vorlage ohne verknüpften Kontakt → Platzhalter für Kontakt-Vorname bleibt leer oder zeigt Hinweis.
+3. **Edge Case:** Admin erstellt geteilte Vorlage → alle User sehen Vorlage in ihrer Liste.
+
+**Akzeptanzkriterium:** Vorlagen mit Platzhaltern (private + geteilte); Platzhalter werden mit Entitäts-Daten ersetzt; private vs. geteilt unterscheidbar.
+
+---
+
+### F-MAIL-07: Filter/Regeln (automatische Sortierung) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann Regeln erstellen, die eingehende Mails automatisch sortieren: Bedingung (Absender enthält, Betreff enthält, Empfänger enthält) → Aktion (in Ordner verschieben, Label setzen, als gelesen markieren, weiterleiten). Regeln werden in Reihenfolge ausgeführt. Erste zutreffende Regel wird angewendet.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Regel „Absender enthält @spam.de → Spam" → neue Mail von @spam.de → Mail wird automatisch in Spam-Ordner verschoben.
+2. **Edge Case:** User hat 2 Regeln: erste trifft zu → wird angewendet, zweite wird nicht ausgeführt.
+3. **Edge Case:** Regel ohne Bedingung → Fehler „Bedingung erforderlich".
+
+**Akzeptanzkriterium:** Regeln mit Bedingungen und Aktionen; sequenzielle Ausführung (erste Treffer gewinnt); Validierung: Bedingung erforderlich.
+
+---
+
+### F-MAIL-08: Abwesenheitsnotiz (Auto-Reply) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann Abwesenheitsnotiz aktivieren: Betreff + Body. System sendet automatisch Antwort auf eingehende Mails (einmal pro Absender, um Mail-Loops zu vermeiden). Zeitraum konfigurierbar (Start- und End-Datum). Auto-Reply wird nicht auf Mailinglisten oder No-Reply-Adressen gesendet.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User aktiviert Abwesenheitsnotiz → Mail von kunde@firma.de kommt an → Auto-Reply wird gesendet. Zweite Mail von kunde@firma.de → kein zweites Auto-Reply (einmal pro Absender).
+2. **Edge Case:** Abwesenheitsnotiz Zeitraum abgelaufen → neue Mail → kein Auto-Reply.
+3. **Edge Case:** Mail von noreply@service.de → kein Auto-Reply (No-Reply-Erkennung).
+
+**Akzeptanzkriterium:** Auto-Reply einmal pro Absender; Zeitraum konfigurierbar; No-Reply-Erkennung; Auto-Reply wird nicht auf Mailinglisten gesendet.
+
+---
+
+### F-MAIL-09: Labels/Flags (Wichtig, Stern, Kategorien) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann Mails mit Labels/Flags markieren: Stern (Flagged), Wichtig (High Priority), eigene Kategorien. Labels sind farbig. IMAP-Flags werden synchronisiert. Custom Labels sind leocrm-spezifisch (nicht IMAP-synced).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User markiert Mail mit Stern → Stern-Icon erscheint, Mail erscheint auch in anderen IMAP-Clients als flagiert.
+2. **Edge Case:** User weist Label „Vertrieb" zu → Mail-Badge zeigt Tag. Mehrere Labels pro Mail möglich.
+3. **Edge Case:** User filtert nach Label → nur Mails mit diesem Label werden angezeigt.
+
+**Akzeptanzkriterium:** Stern/Flagged mit IMAP-Sync; eigene Kategorien mit Farbe; mehrere Labels pro Mail; Filter nach Label.
+
+---
+
+### F-MAIL-10: Kontakt-Verknüpfung (E-Mail-Historie pro Kontakt/Firma) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** Jede Mail wird automatisch mit Kontakten und Firmen verknüpft, basierend auf Absender-/Empfänger-E-Mail-Adressen. In Kontakt-Detail-Seite wird E-Mail-Historie angezeigt (chronologisch). In Firmen-Detail-Seite werden alle Mails aller zugeordneten Kontakte angezeigt. Verknüpfung kann manuell ergänzt oder korrigiert werden.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Mail von max@firma.de kommt an → System erkennt Kontakt „Max Mustermann" → Mail wird verknüpft, erscheint in Kontakt-Detail-Seite unter „E-Mail-Historie".
+2. **Edge Case:** Mail von unbekannter Adresse → keine automatische Verknüpfung. User kann manuell Kontakt zuweisen.
+3. **Integration:** Firmen-Detail-Seite zeigt alle Mails aller Kontakte der Firma → chronologisch sortiert.
+
+**Akzeptanzkriterium:** Auto-Verknüpfung basierend auf E-Mail-Adressen; E-Mail-Historie in Kontakt-Detail; Firmen-Detail zeigt alle Mails aller Kontakte; manuelle Verknüpfung möglich.
+
+---
+
+### F-MAIL-11: Kalender-Integration (Termin aus E-Mail erstellen) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann aus einer E-Mail heraus einen Kalender-Eintrag erstellen. Mail-Inhalt wird in Termin-Beschreibung übernommen. Mail-Absender wird als Teilnehmer hinzugefügt. Termin wird im Default-Kalender erstellt.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User öffnet Mail → klickt „Termin erstellen" → Dialog mit Datum/Zeit, Absender als Teilnehmer, Mail-Body als Beschreibung → speichert Termin.
+2. **Edge Case:** Mail ohne erkennbares Datum → Termin-Dialog öffnet sich leer, User füllt manuell aus.
+3. **Integration:** Termin wird erstellt → Link zur Original-Mail in Termin-Beschreibung sichtbar.
+
+**Akzeptanzkriterium:** Termin aus Mail heraus erstellbar; Mail-Body als Beschreibung; Absender als Teilnehmer; Link zur Original-Mail.
+
+---
+
+### F-MAIL-12: Verschlüsselung (PGP) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann Mails PGP-verschlüsselt senden und entschlüsseln. Public-Key-Verwaltung: User kann eigenen PGP-Key importieren und Public-Keys von Kontakten speichern. Senden: Mail-Body wird mit Empfänger-Public-Key verschlüsselt. Empfang: verschlüsselte Mails werden mit eigenem Private-Key entschlüsselt (Passphrase-Eingabe). S/MIME ist post-MVP.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User hat PGP-Key konfiguriert, Kontakt hat Public-Key hinterlegt → User sendet verschlüsselte Mail → Mail-Body ist verschlüsselt, nur Empfänger kann entschlüsseln.
+2. **Edge Case:** User empfängt verschlüsselte Mail → System erkennt PGP-Block → fragt nach Passphrase → Mail wird entschlüsselt angezeigt.
+3. **Edge Case:** User sendet verschlüsselte Mail an Kontakt ohne Public-Key → Fehler „Kein Public-Key für Empfänger vorhanden".
+
+**Akzeptanzkriterium:** PGP-Verschlüsselung beim Senden; PGP-Entschlüsselung beim Empfang mit Passphrase; Public-Key-Verwaltung für Kontakte; Fehler bei fehlendem Public-Key.
+
+---
+
+### F-MAIL-13: Signaturen (pro Benutzer, pro Postfach) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann mehrere Signaturen verwalten. Jede Signatur: Name + HTML-Content (inkl. Bildern). Default-Signatur pro Postfach zuweisbar. Beim Schreiben wird Default-Signatur automatisch eingefügt. User kann beim Schreiben zwischen Signaturen wechseln.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User hat 2 Signaturen → wählt beim Schreiben „Geschäftlich" → Signatur wird am Ende des Mail-Bodys eingefügt.
+2. **Edge Case:** User hat Postfach info@firma.de mit Default-Signatur → neue Mail von info@firma.de → Signatur wird automatisch eingefügt.
+3. **Edge Case:** User hat keine Signatur → keine wird eingefügt, kein Fehler.
+
+**Akzeptanzkriterium:** Mehrere Signaturen pro User; Default-Signatur pro Postfach; Auto-Einfügen beim Schreiben; Wechsel zwischen Signaturen im Composer.
+
+---
+
+### F-MAIL-14: Mehrere Postfächer (pro User konfigurierbar) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann mehrere Mail-Postfächer konfigurieren. Jedes Postfach: IMAP-Server, SMTP-Server, Auth. Postfächer werden in Sidebar aufgelistet. User kann zwischen Postfächern wechseln. Default-Postfach für neue Mails einstellbar.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User konfiguriert 2 Postfächer → beide erscheinen in Sidebar, User kann zwischen ihnen wechseln.
+2. **Edge Case:** User wählt ein Postfach als Default → neue Mail wird von diesem Postfach gesendet.
+3. **Edge Case:** IMAP-Verbindung zu einem Postfach schlägt fehl → Fehler-Badge am Postfach, andere Postfächer funktionieren.
+
+**Akzeptanzkriterium:** Mehrere Postfächer pro User konfigurierbar; Sidebar-Liste mit Unread-Badge; Default-Postfach einstellbar; Verbindungsfehler werden angezeigt.
+
+---
+
+### F-MAIL-15: Geteilte Postfächer (Gruppen-Postfach) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** Admin kann Gruppen-Postfächer erstellen (z.B. info@, vertrieb@). Gruppen-Postfach wird mehreren Usern zugeordnet. Alle zugewiesenen User sehen die Mails im Gruppen-Postfach. Wer eine Mail liest/antwortet, wird für andere sichtbar markiert (Seen-By-Tracking).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin erstellt info@firma.de als Gruppen-Postfach, weist User A + B zu → beide sehen Mails im info@-Postfach.
+2. **Edge Case:** User A liest Mail → Mail wird für User B als „gelesen von User A" markiert.
+3. **Edge Case:** User C ist nicht zugewiesen → sieht info@-Postfach nicht in Sidebar.
+
+**Akzeptanzkriterium:** Gruppen-Postfächer durch Admin erstellbar; mehrere User zugewiesen; Seen-By-Tracking; Nicht-Zugewiesene sehen Postfach nicht.
+
+---
+
+### F-MAIL-16: Stellvertretung (Zugriff delegieren) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann anderen Usern Zugriff auf sein persönliches Postfach delegieren (Vollzugriff oder nur Lesen). Delegierter User sieht das Postfach in seiner Sidebar. Bei Vollzugriff kann delegierter User Mails lesen, beantworten, versenden „als" den Postfach-Inhaber.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User A delegiert Vollzugriff an User B → User B sieht A's Postfach in Sidebar, kann Mails lesen und beantworten.
+2. **Edge Case:** User A delegiert nur Lesezugriff → User B kann Mails lesen, aber nicht antworten/versenden.
+3. **Edge Case:** User A entzieht Zugriff → User B sieht Postfach nicht mehr.
+
+**Akzeptanzkriterium:** Delegation mit Vollzugriff oder Lesezugriff; delegiertes Postfach in Sidebar sichtbar; Senden „als" bei Vollzugriff; Zugriff entziehbar.
+
+---
+
+### F-MAIL-17: Sende-Berechtigungen (wer darf als Gruppe senden) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** Für geteilte Postfächer definiert der Admin, welche User Mails als Gruppen-Adresse senden dürfen. Ohne Berechtigung kann User nur im Namen der eigenen Adresse senden.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** Admin erteilt User A Send-Berechtigung für info@firma.de → User A kann „Von: info@firma.de" beim Schreiben auswählen.
+2. **Edge Case:** User B hat keine Send-Berechtigung → „Von:"-Dropdown enthält info@firma.de nicht.
+3. **Edge Case:** User B versucht Send via API → Zugriff verweigert.
+
+**Akzeptanzkriterium:** Admin vergibt Send-Berechtigungen; nur berechtigte User können als Gruppen-Adresse senden; „Von:"-Dropdown zeigt nur berechtigte Postfächer.
+
+---
+
+### F-MAIL-18: Postfach-Konfiguration (IMAP/SMTP Server-Einstellungen) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User/Admin kann IMAP- und SMTP-Server-Einstellungen pro Postfach konfigurieren: Host, Port, SSL/TLS/STARTTLS, Auth-Methode, Benutzername, Passwort. Verbindungstest beim Speichern. Passwörter werden verschlüsselt gespeichert.
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User gibt Server-Einstellungen ein → klickt „Testen" → Verbindung erfolgreich → speichern.
+2. **Edge Case:** Falsches Passwort → Test schlägt fehl → Fehler „Authentifizierung fehlgeschlagen", Speichern blockiert.
+3. **Edge Case:** Server nicht erreichbar → Test schlägt fehl → Fehler „Server nicht erreichbar (Timeout)".
+
+**Akzeptanzkriterium:** Server-Einstellungen pro Postfach konfigurierbar; Verbindungstest vor Speichern; Passwörter verschlüsselt gespeichert; Fehlermeldungen spezifisch.
+
+---
+
+### F-MAIL-19: Mail-Ordner verwalten (Erstellen, Umbenennen, Löschen) [v2-Plugin]
+**Plugin:** Mail
+**Anforderung:** User kann eigene Ordner erstellen, umbenennen und löschen. Ordner werden mit IMAP-Server synchronisiert. Custom Ordner können verschachtelt werden (Sub-Ordner). Ordnern können Farben/Icons zugewiesen werden (leocrm-spezifisch, nicht IMAP).
+
+**Test Scenarios (Pflicht):**
+1. **Happy Path:** User erstellt Ordner „Projekt Alpha" → Ordner erscheint in Sidebar, wird mit Server synchronisiert.
+2. **Edge Case:** User benennt Ordner um → Ordner wird mit Server synchronisiert, Mails bleiben im Ordner.
+3. **Edge Case:** User löscht Ordner mit Mails → Bestätigungs-Dialog → Mails werden gelöscht (auch vom Server).
+
+**Akzeptanzkriterium:** Ordner-CRUD mit IMAP-Sync; Verschachtelung (Sub-Ordner); Farben/Icons zuweisbar (leocrm-spezifisch); Bestätigungsdialog bei Löschung mit Inhalten.
+
+---
+
+---
+
+## 6. Annahmen (Assumptions)
+
+1. **Multi-Tenant:** v1 ist Multi-Tenant (Multi-Company) — eine Installation, mehrere Organisationen/Tenants mit Datenisolation.
+2. **PostgreSQL:** PostgreSQL 16 als Datenbank (bei 200k Kontakten + Multi-User + Concurrent Writes).
+3. **SPA-Frontend:** Client-side rendering mit React SPA (bestätigt durch genehmigten Prototyp leocrm-prototype-x7k2p9).
+4. **Max 10 concurrent Users pro Tenant:** v1 ist für kleine Teams, nicht für Enterprise.
+5. **E-Mail-Versand:** SMTP via externem Provider (z.B. Mailtrap für Dev, Production-SMTP für Prod).
+6. **Soft-Delete als Default:** Firmen und Kontakte werden soft-deleted (recoverable), außer DSGVO-Löschung (hard delete).
+7. **Rollensystem v1:** 3 Rollen: admin, editor, viewer. Weitere Rollen können später hinzugefügt werden.
+8. **Export-Limit:** Export von >50k Datensätzen als Background-Job, <50k als direkter Download.
+9. **i18n-Default:** Deutsch ist Default-Sprache, Englisch ist zweites Locale.
+10. **Python 3.12:** Aktuelle stabile Python-Version.
+11. **Plugin-System:** Mail, Kalender, DMS, Tags sind Plugins (nicht Core-Features). Plugin-System ist v1-Feature.
+12. **Session-basierte Auth:** Authentifizierung ist Session-basiert (Cookie). API-Token für API-Zugang separat.
+13. **KI-Copilot:** KI-Copilot ist v1-Feature. Lead-Scoring und Auto-Enrichment sind Non-Goals.
+
+---
+
+## 7. Non-Goals (nicht in v1)
+
+1. **Self-Registration:** User können sich nicht selbst registrieren — nur Admin legt User an.
+2. **Sales Pipeline / Deals:** Keine Opportunity/Pipeline-Verwaltung in v1.
+3. **Kampagnen-Management:** Keine Marketing-Kampagnen in v1.
+4. **Mobile App (Native):** Responsive Web-UI, keine native iOS/Android App.
+5. **Offline-Support:** Keine Offline-Funktionalität in v1.
+6. **AI Lead-Scoring / Auto-Enrichment:** Kein KI-basiertes Lead-Scoring oder Auto-Enrichment in v1. KI-Copilot ist v1.
+7. **Real-time Collaboration:** Keine gleichzeitige Bearbeitung mit Live-Updates (wie Google Docs) in v1.
+8. **Webhooks für externe Systeme:** Keine Webhook-Integration in v1.
+9. **Multi-Currency:** Keine Währungsumrechnung in v1.
+10. **Advanced Analytics/Dashboards:** Keine BI-Dashboards in v1. Basis-Listen-Ansicht reicht.
+11. **SSO/OAuth:** Kein Single Sign-On in v1. Nur E-Mail/Passwort.
+12. **Custom Fields:** Keine benutzerdefinierten Felder in v1. Standard-Felder sind fest definiert.
+13. **Two-Factor Auth:** Kein 2FA in v1. Post-MVP.
+14. **PWA:** Keine Progressive Web App in v1.
+15. **Nummernkreise/Sequenzen:** Keine zentralen Sequenz-Generatoren. Plugins verwalten eigene Nummernkreise.
+16. **State Machine Engine:** Keine zentrale State-Machine-Engine. Plugins implementieren eigene Status-Logik.
+17. **Document Versioning:** Kein zentrales Document-Versioning-System. Ergibt sich aus Implementierung.
+18. **Rate Limiting:** Kein zentrales Rate-Limiting in v1.
+19. **S/MIME:** S/MIME-Verschlüsselung ist post-MVP. Nur PGP in v2-mail.
+20. **Mail-Server-Hosting:** leocrm hostet keine Mail-Server. Es verbindet sich mit externen IMAP/SMTP-Servern.
+21. **Mailinglisten-Management:** Keine Verwaltung von Mailinglisten oder Verteilerlisten.
+22. **Newsletter-Tool:** Keine Newsletter/Mass-Mail-Funktionalität.
+23. **Mail-to-Ticket:** Keine automatische Ticket-Erstellung aus Mails.
+24. **OCR für Anhänge:** Volltext-Suche durchsucht Anhang-Namen, aber kein OCR der Anhang-Inhalte.
+25. **Kalender-Einladungen per Mail (iMIP):** Keine Verarbeitung von iCalendar-Einladungen in Mails in v2-mail.
+26. **JMAP:** Keine Unterstützung für JMAP-Protokoll. Nur IMAP.
+27. **Push-Benachrichtigungen (Web Push):** Keine Browser-Push-Notifications für neue Mails. Nur In-App-Anzeige.
+28. **Google/Microsoft API:** Keine Gmail API oder Microsoft Graph API Integration. Nur direkte IMAP/SMTP.
+
+---
+
+## 8. Discovery-Checkliste (21 Kategorien — alle beantwortet)
+
+| # | Kategorie | Status | Bemerkung |
+|---|-----------|--------|----------|
+| 1 | Auth | ✅ ja | Login, Logout, RBAC, Passwort-Reset, Admin-only User-Verwaltung, Session-basiert |
+| 2 | Daten | ✅ ja | Validierung, Pagination, Search+Filter, Sortierung, Soft-Delete, Multi-Tenant-Isolation |
+| 3 | Fehler | ✅ ja | Error-Pages, Toast-Notifications, strukturiertes Logging |
+| 4 | Skalierung | ✅ ja | DB-Connection-Pooling, PostgreSQL, Pagination |
+| 5 | Sicherheit | ✅ ja | CSRF, XSS, Input-Sanitization, bcrypt, Session-Cookies, CSP-Header, Plugin-Sandboxing |
+| 6 | UX | ✅ ja | Loading-States, Empty-States, Confirmation-Dialogs, Responsive |
+| 7 | Infrastruktur | ✅ ja | Health-Check, Backup/Restore, Logging, Monitoring/Alerting |
+| 8 | Multi-User | ✅ ja | RBAC mit 3 Rollen, Concurrent Access via PostgreSQL MVCC |
+| 9 | Migration | ✅ ja | CSV-Import, CSV+Excel-Export, Feld-Mapping beim Import |
+| 10 | Mobile | ✅ ja | Responsive Design, Touch-Events, Breakpoints für Handy/Tablet |
+| 11 | Integration | ✅ ja | E-Mail (SMTP), Session-Cookie-Auth, API-Token, Plugin-System |
+| 12 | Compliance | ✅ ja | DSGVO: Right to be Forgotten, Audit-Log, Löschkonzept |
+| 13 | Performance | ✅ ja | <500ms bei 200k Datensätzen, DB-Indizes, Lazy Loading |
+| 14 | i18n | ✅ ja | Deutsch + Englisch, Sprachwahl persistiert, Datumsformate |
+| 15 | Accessibility | ✅ ja | WCAG 2.1 AA, Keyboard-Nav, ARIA, Kontrast |
+| 16 | Analytics/Tracking | ✅ ja | Audit-Log für schreibende Aktionen; Error-Tracking via Logs |
+| 17 | Environments | ✅ ja | Dev lokal, Prod auf Coolify, Env-Vars, `.env.example` |
+| 18 | Dokumentation | ✅ ja | README, OpenAPI auto-gen, Admin-Guide |
+| 19 | Testing | ✅ ja | pytest >80% Coverage, Vitest Frontend, Playwright E2E |
+| 20 | Naming/Branding | ✅ ja | Projektname: leocrm, Branding/Farben im UI-Design definiert |
+| 21 | Scheduling | ✅ ja | Background-Jobs für Export + Backup, Job-Status-Polling, Async Job Queue |
+
+---
+
+## 9. Open Questions
+
+1. ~~SQLite → PostgreSQL~~ **GELÖST** — PostgreSQL 16 bestätigt.
+2. ~~Frontend-Framework~~ **GELÖST** — React SPA bestätigt durch Prototyp.
+3. **SMTP-Provider:** Welcher SMTP-Provider für Production? → Deployment-Phase.
+4. **Backup-Strategie:** Coolify Docker Volume Backup oder pg_dump + S3? → Deployment-Phase.
+5. ~~Color-Branding~~ **GELÖST** — Color Scheme definiert und bestätigt durch Prototyp.
+6. ~~Plugin-System vs Core-Feature~~ **GELÖST** — Mail/Kalender/DMS/Tags sind Plugins. Plugin-System ist v1.
+7. ~~Multi-Tenant vs Single-Tenant~~ **GELÖST** — Multi-Tenant (Multi-Company) ist v1.
+8. ~~Auth-Terminologie~~ **GELÖST** — Session-basiert (Cookie). API-Token für API-Zugang separat.
+
+---
+
+## 10. Feature-Zusammenfassung
+
+### Core-Features (v1)
+
+| Bereich | IDs | Anzahl |
+|---------|-----|--------|
+| Auth | F-AUTH-01–F-AUTH-08 | 8 |
+| Companies | F-COMP-01–F-COMP-08 | 8 |
+| Contacts | F-CONT-01–F-CONT-07 | 7 |
+| Data | F-DATA-01–F-DATA-04, F-DATA-06 | 5 |
+| UI | F-UI-01–F-UI-06, F-UI-08 | 7 |
+| Accessibility | F-A11Y-01–F-A11Y-03 | 3 |
+| Security | F-SEC-01–F-SEC-03 | 3 |
+| Infrastruktur | F-INFRA-01–F-INFRA-04 | 4 |
+| Migration | F-MIG-01 | 1 |
+| Integration | F-INT-01–F-INT-02 | 2 |
+| Testing | F-TEST-01 | 1 |
+| Environments | F-ENV-01 | 1 |
+| Dokumentation | F-DOC-01 | 1 |
+| Performance | F-PERF-01 | 1 |
+| Scheduling | F-SCHED-01 | 1 |
+| AI | F-AI-01 | 1 |
+| Workflow | F-WF-01 | 1 |
+| Search | F-SEARCH-01 | 1 |
+| Navigation | F-NAV-01 | 1 |
+| Settings | F-SET-01 | 1 |
+| Core-Infrastructure | F-CORE-01–F-CORE-13 | 13 |
+| Plugin-System | F-PLUGIN-01–F-PLUGIN-02 | 2 |
+
+### Plugin-Features (v2-Plugin)
+
+| Plugin | IDs | Anzahl |
+|--------|-----|--------|
+| File | F-FILE-01–F-FILE-04 | 4 |
+| DMS | F-DMS-01–F-DMS-07 | 7 |
+| Links | F-LINK-01–F-LINK-06 | 6 |
+| Tags | F-TAG-01–F-TAG-04 | 4 |
+| Permissions | F-PERM-01–F-PERM-06 | 6 |
+| File-UI | F-FILEUI-01–F-FILEUI-06 | 6 |
+| Kalender | F-CAL-01–F-CAL-18 | 18 |
+| Mail | F-MAIL-01–F-MAIL-19 | 19 |
+
+**Total Core-Features:** 73
+**Total Plugin-Features:** 70
+**Total:** 143
+**Features mit Test-Szenarien:** 143/143
+**Test-Coverage:** 100%
+
+---
+
+DISCOVERY_CHECK_FINAL: categories=21/21, features_with_ids=143/143, test_scenarios=143/143, constraints=Y, non_goals=Y, domain=Y, ready_for_ui=Y (v1 core + v2 plugins — bereinigt von Implementierungs-Details — Plugin-System als v1-Feature bestätigt)
+
+---
+
+## Appendix A: Historische Anforderungen v0.1 (archiviert)
+
+> **Status:** VERALTET — durch v0.3 Feature-IDs (F-AUTH-*, F-COMP-*, etc.) ersetzt.
+> **Zweck:** Nachvollziehbarkeit der ursprünglichen v0.1-Anforderungen.
+> **Archiviert in:** `specs/v0.1-historical/requirements.md`
+
+### F-1: Login (historisch, ersetzt durch F-AUTH-01)
+- Login-Formular, Session-Cookie, Redirect auf `/`
+
+### F-2: Logout (historisch, ersetzt durch F-AUTH-02)
+- Logout löscht Session, Redirect auf Login-Seite
+
+### F-3: Auth-Schutz (historisch, in F-AUTH-04 RBAC integriert)
+- Alle Seiten außer Login und Health erfordern Session
+
+### F-4: Dashboard (historisch, in F-UI-01 integriert)
+- Dashboard zeigt Anzahl Companies, Contacts, letzte Änderungen
+
+### F-5/F-6/F-7/F-8/F-9: Company CRUD (historisch, ersetzt durch F-COMP-01..04)
+- Tabelle mit Name, Stadt, Land, Contact-Count; Volltextsuche
+- Anlegen, Detail anzeigen, Bearbeiten, Löschen (mit Cascade für Contacts)
+
+### F-10/F-11/F-12/F-13: Contact CRUD (historisch, ersetzt durch F-CONT-01..04)
+- Anlegen mit FK auf Company, Detail, Bearbeiten, Löschen (Company bleibt)
+
+### F-14: JSON-API parallel zu HTML (historisch, in API-First integriert)
+- Jede HTML-Aktion hat äquivalenten JSON-Endpoint für headless Tests
+
+### F-15: Health-Endpoint (historisch, ersetzt durch F-INFRA-01)
+- Health-Endpoint liefert Status und DB-Verfügbarkeit
+
+### F-16: Demo-Seed (historisch, in F-AUTH-03 integriert)
+- Beim ersten Start: 1 Admin, 2 Firmen, 3 Kontakte
+
+### v0.1 Tech-Stack (historisch, ersetzt durch v0.3)
+- ~~Backend: FastAPI~~ → FastAPI (bestätigt)
+- ~~DB: SQLite~~ → PostgreSQL 16
+- ~~Templates: Jinja2~~ → React 18 SPA
+- ~~Server: Uvicorn / Gunicorn~~ → Uvicorn (async)
+- ~~Deployment: 1 Container~~ → Multi-Container
+
+### v0.1 Nicht-Ziele (historisch — jetzt in v0.3 implementiert)
+- ~~Multi-User / Rollen-Rechte~~ → F-AUTH-04 RBAC
+- ~~Audit-Log, Soft-Delete~~ → F-COMP-07, F-COMP-08
+- ~~E-Mail-Versand~~ → F-MAIL-* (Mail-Plugin)
+- ~~Datei-Upload~~ → F-DMS-* (DMS-Plugin)
+- ~~Internationalisierung~~ → F-UI-02 (DE + EN)
+- ~~Import/Export~~ → F-DATA-01, F-DATA-02, F-MIG-01
+
+---
+
+## Changelog (Bereinigung 2026-06-28)
+
+### Was wurde geändert:
+1. **Plugin vs Core aufgelöst:** F-DMS/FILE/CAL/MAIL/TAG als `v2-Plugin` markiert. Plugin-System (F-PLUGIN-01/02) bleibt als v1-Core-Feature.
+2. **Implementierungs-Details entfernt:** HTTP-Endpunkte, DB-Schema-Typen (VARCHAR, TIMESTAMP etc.), Farbcodes, RFC-Referenzen, Protokoll-Details (IMAP-Port, STARTTLS), Frontend-Komponenten-Namen, SQL-Ausdrücke, Algorithmus-Details aus requirements.md entfernt. Diese Details werden in architecture.md dokumentiert.
+3. **Auth-Terminologie vereinheitlicht:** Session-basiert (Cookie) als einheitliche Terminologie. API-Token für API-Zugang separat dokumentiert.
+4. **Multi-Tenant-Kontext hinzugefügt:** tenant_id-Kontext zu frühen Requirements (F-AUTH-01 bis F-CONT-07) hinzugefügt, wo sinnvoll.
+5. **Annahmen aktualisiert:** Single-Tenant → Multi-Tenant, Plugin-System als Annahme hinzugefügt, KI-Copilot als Annahme hinzugefügt.
+6. **Non-Goals aktualisiert:** Multi-Tenant entfernt (ist jetzt v1), AI Lead-Scoring spezifiziert (KI-Copilot ist v1), Nummernkreise/State Machine/Document Versioning als Non-Goals hinzugefügt.
+7. **DISCOVERY_CHECK aktualisiert:** 143 Features (73 Core + 70 Plugin), 21 Kategorien, 100% Test-Coverage.
+8. **F-CORE-01 bis F-CORE-13:** Als Core-Infrastructure-Requirements ohne Implementierungs-Details belassen.
+9. **Feature-Zusammenfassung neu strukturiert:** Core-Features und Plugin-Features getrennt gezählt.
+10. **Appendix A bereinigt:** HTTP-Status-Codes und Implementierungs-Details aus historischen Anforderungen entfernt.
+
+### Was entfernt und nach extracted-architecture-details.md verschoben wurde:
+- HTTP-Endpunkt-Spezifikationen (POST /api/..., GET /api/...)
+- DB-Schema-Definitionen (Feld-Tabellen mit Typen)
+- Technologie-Wahlen (Celery, Redis, MinIO, DOMPurify, python-gnupg)
+- Farbcodes (Hex-Werte)
+- SQL-Ausdrücke
+- Algorithmus-Details (PGP-Verschlüsselung Schritt für Schritt)
+- Frontend-Komponenten-Namen (CompanyTable.vue etc.)
+- RFC-Referenzen (RFC 5322, RFC 3501 etc.)
+- Protokoll-Details (IMAP-Port 993, STARTTLS etc.)
diff --git a/extracted-architecture-details.md b/extracted-architecture-details.md
new file mode 100644
index 0000000..621a0e5
--- /dev/null
+++ b/extracted-architecture-details.md
@@ -0,0 +1,1006 @@
+# LeoCRM — Extracted Architecture Details
+
+**Zweck:** Implementierungs-Details, die aus der bereinigten `requirements.md` entfernt wurden. Für den Solution Architect als Referenz.
+**Quelle:** Original `requirements.md` (git HEAD, 1956 Zeilen) vs. bereinigte Version (2105 Zeilen)
+**Datum:** 2026-06-28
+
+---
+
+## 1. Tech-Stack (vollständige Spezifikation)
+
+### Original Tech-Stack-Tabelle (entfernt)
+
+| Komponente | Entscheidung | Bemerkung |
+|------------|-------------|----------|
+| Backend | FastAPI + SQLAlchemy 2.0 | Python 3.12 |
+| Datenbank | PostgreSQL (empfohlen) | Siehe DB-Empfehlung unten |
+| Frontend | React SPA | Client-side rendering, i18n (bestätigt durch Prototyp) |
+| Deployment | Coolify (Docker) | Bestätigt |
+| Linting | ruff + black | Python-Standard |
+| Testing | pytest + Vitest/Jest | Backend + Frontend |
+
+### DB-Empfehlung: PostgreSQL statt SQLite
+
+Ursprünglich war SQLite spezifiziert. Bei 200.000 Kontakten + mehreren Usern + Concurrent Writes ist SQLite limitiert:
+
+- **SQLite:** File-Level Locking, nur 1 Writer gleichzeitig, ~15 Updates/Sekunde bei Concurrent Writes (StackOverflow Benchmark)
+- **PostgreSQL:** True Concurrent Writers, ~1.500 Updates/Sekunde, MVCC-Architektur (tableone.dev Benchmark)
+- **Fazit:** Bei 200k Datensätzen + Multi-User + gleichzeitige Schreibzugriffe → PostgreSQL
+
+### v0.1 Historischer Tech-Stack (archiviert)
+- ~~Backend: FastAPI (Python 3.11+)~~ → Python 3.12
+- ~~DB: SQLite (Datei `leocrm.db`)~~ → PostgreSQL 16
+- ~~Templates: Jinja2 (HTML)~~ → React 18 SPA
+- ~~Server: Uvicorn / Gunicorn~~ → Uvicorn (async)
+- ~~Deployment: 1 Container Docker Compose~~ → Multi-Container (Backend + Frontend + PostgreSQL + OnlyOffice + Worker)
+
+---
+
+## 2. Domain Knowledge (entfernte Referenzen)
+
+**Domain:** Customer Relationship Management (CRM)
+
+Standard-Entitäten in CRMs (Referenz: Zoho CRM, HubSpot, Salesforce):
+- **Accounts (Firmen):** Name, Adresse, Industrie, Employees, Revenue, Owner, Phone, Website, Billing/Shipping Address
+- **Contacts (Kontaktpersonen):** Name, Email, Phone, Mobile, Title, Department, Mailing Address, Reports To, Description
+- **Beziehungen:** N:M (ein Kontakt kann mehreren Firmen zugeordnet sein)
+
+Quellen:
+- Zoho CRM Standard Fields Accounts: https://help.zoho.com/portal/en/kb/crm/sales-force-automation/accounts/articles/standard-fields-accounts
+- Zoho CRM Standard Fields Contacts: https://help.zoho.com/portal/en/kb/crm/sales-force-automation/contacts/articles/standard-fields-contacts
+- Encore Business Solutions — 30 CRM Custom Account Fields
+- Bitrix24 Standard fields in CRM
+
+---
+
+## 3. HTTP-Endpunkt-Spezifikationen
+
+### F-AUTH-01: Login
+- **Endpoint:** POST `/api/auth/login`
+- **Akzeptiert:** E-Mail + Passwort
+- **Response:** Session-Cookie (HttpOnly+Secure+SameSite=Strict) oder 401
+
+### F-AUTH-02: Logout
+- **Clientseitig:** Token wird entfernt
+- **Server:** Token-Blacklist optional für v1
+
+### F-AUTH-03: User-Verwaltung
+- **Endpoint:** POST `/api/users`
+- **Auth:** Admin-Token erforderlich
+- **Response:** 201 (erstellt) oder 403 (ohne Admin-Token)
+
+### F-AUTH-04: RBAC
+- **Jeder API-Endpoint prüft Rolle:** falsche Rolle → 403; korrekte Rolle → 200/201
+- **Beispiele:** POST `/api/users` → 403 (editor); POST `/api/companies` → 403 (viewer), GET `/api/companies` → 200 (viewer)
+
+### F-AUTH-05: Passwort-Reset
+- **Request:** POST `/api/auth/password-reset/request` → sendet E-Mail
+- **Confirm:** POST `/api/auth/password-reset/confirm` mit Token + neuem Passwort → aktualisiert Passwort
+
+### F-COMP-01: Firma anlegen
+- **Endpoint:** POST `/api/companies`
+- **Response:** 201 Created (valide Daten); 422 Validation Error (ohne Name)
+
+### F-COMP-02: Firma anzeigen
+- **Endpoint:** GET `/api/companies/{id}`
+- **Response:** 200 mit Firmendaten + Kontakte-Array; 404 (nicht-existent)
+
+### F-COMP-03: Firma bearbeiten
+- **Endpoint:** PUT/PATCH `/api/companies/{id}`
+- **Response:** 200 mit aktualisierten Daten; 422 (Validierungsfehler)
+
+### F-COMP-04: Firma löschen (Soft-Delete)
+- **Endpoint:** DELETE `/api/companies/{id}?cascade=true|false`
+- **Response:** 200; Firma wird als `deleted_at = NOW()` markiert
+- **Cascade:** bei cascade=true auch Kontakte soft-deleted
+
+### F-COMP-05: Firmen-Liste mit Pagination
+- **Endpoint:** GET `/api/companies?page=2&page_size=25&sort_by=name&sort_order=desc`
+- **Response:** 200 mit `{items, total, page, page_size}`
+
+### F-COMP-06: Firmen-Suche & Filter
+- **Endpoint:** GET `/api/companies?search=Tech&industry=IT&country=Germany`
+- **Response:** 200 mit gefilterten Ergebnissen
+
+### F-COMP-07: Audit-Log
+- **Tabelle:** `audit_log`
+- **Mechanismus:** Middleware/Decorator loggt schreibende Aktionen
+- **Endpoint:** GET `/api/audit-log` (Admin, paginiert)
+
+### F-COMP-08: DSGVO / Right to be Forgotten
+- **Endpoint:** DELETE `/api/contacts/{id}?gdpr=true` → harte Löschung
+- **Tabelle:** separate `deletion_log` Tabelle (unveränderlich)
+
+### F-CONT-01: Kontaktperson anlegen
+- **Endpoint:** POST `/api/contacts`
+- **Response:** 201 (valide Daten); 422 (ohne last_name)
+- **N:M:** mit company_ids → N:M-Verknüpfungen erstellt
+
+### F-CONT-02: Kontaktperson anzeigen
+- **Endpoint:** GET `/api/contacts/{id}`
+- **Response:** 200 mit Kontaktdaten + Firmen-Array; 404
+
+### F-CONT-03: Kontaktperson bearbeiten
+- **Endpoint:** PUT/PATCH `/api/contacts/{id}`
+- **Response:** 200; Änderung an company_ids → N:M-Tabelle aktualisiert
+
+### F-CONT-04: Kontaktperson löschen (Soft-Delete)
+- **Endpoint:** DELETE `/api/contacts/{id}`
+- **Response:** 200; `deleted_at` gesetzt; N:M-Einträge gelöscht; Firmen unberührt
+
+### F-CONT-05: Kontakt-Liste mit Pagination
+- **Endpoint:** GET `/api/contacts?page=1&page_size=25&sort_by=last_name&sort_order=asc`
+- **Response:** 200 mit paginierten Ergebnissen
+- **Performance:** Response-Zeit <500ms bei 200k Datensätzen (mit DB-Index)
+
+### F-CONT-06: Kontakt-Suche & Filter
+- **Endpoint:** GET `/api/contacts?search=Müller&company_id=5`
+- **Response:** 200 mit gefilterten Ergebnissen
+
+### F-CONT-07: N:M Firmen-Kontakt-Zuordnung
+- **Tabelle:** `company_contacts` (N:M-Verknüpfungstabelle)
+- **Zuordnung:** POST `/api/companies/{id}/contacts/{contact_id}`
+- **Entfernung:** DELETE `/api/companies/{id}/contacts/{contact_id}`
+
+### F-DATA-01: CSV-Export
+- **Endpoint:** GET `/api/companies/export?format=csv&filters=...`
+- **Response:** 200 mit `Content-Type: text/csv`, Datei-Download
+
+### F-DATA-02: Excel-Export
+- **Endpoint:** GET `/api/companies/export?format=xlsx&filters=...`
+- **Response:** 200 mit `Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`
+
+### F-DATA-03: Daten-Validierung
+- **Technologie:** Pydantic-Schemas für alle Entities
+- **Response:** ungültige Eingaben → 422 mit detailiertem Fehler-Objekt
+
+### F-DATA-06: ARIA-Rollen auf DataTable
+- **ARIA-Rollen:** `role="table"`, `role="row"`, `role="columnheader"`, `role="cell"`
+- **Sortierung:** `aria-sort="ascending|descending|none"`
+- **Label:** beschreibendes `aria-label`
+- **Testing:** NVDA und axe DevTools
+
+### F-UI-01: Responsive Design
+- **Breakpoints:** Mobile-First; Touch-Targets min 44px
+- **Testing:** Chrome DevTools (375px, 768px, 1920px)
+
+### F-UI-02: Internationalisierung
+- **Library:** react-i18next
+- **Locale-Files:** JSON-Locale-Files für DE/EN
+- **Persistenz:** Sprachwahl persistiert in User-Settings
+
+### F-UI-03: Error-Handling & Toast-Notifications
+- **Komponente:** Toast-Komponente (success/error/warning/info)
+- **Routen:** dedizierte 404/500-Routen im Frontend
+
+### F-UI-04: Loading-States
+- **Komponenten:** Loading-State-Komponenten; Skeleton-Loader
+- **State:** API-Loading-State im Frontend-Store; Button-Disabled-State während Pending
+
+### F-UI-05: Empty-States
+- **Komponente:** Empty-State-Komponenten mit Icon + Text + CTA
+
+### F-UI-06: Confirmation-Dialogs
+- **Komponente:** Modal-Dialog-Komponente
+- **Regel:** alle DELETE-Operationen erfordern Bestätigung
+
+### F-SEC-01: CSRF-Schutz
+- **Implementierung:** SameSite=Strict Cookies + Origin-Header-Validierung
+- **Kein Double-Submit-Token**
+- **Middleware:** Origin-Header-Validierung-Middleware
+- **Exempt:** nur GET/HEAD/OPTIONS
+
+### F-SEC-02: XSS-Schutz & Input-Sanitization
+- **Frontend:** Output-Encoding
+- **Backend:** Pydantic-Validierung strippt gefährliche Eingaben
+- **Header:** CSP-Header gesetzt
+
+### F-SEC-03: Session-Timeout
+- **Timeout:** 8h
+- **Interceptor:** 401-Interceptor im Frontend → Redirect zur Login-Seite
+- **Refresh:** Refresh-Token optional für v1
+
+### F-INFRA-01: Health-Check Endpoint
+- **Endpoint:** GET `/api/health`
+- **Response:** 200 `{status: "healthy", db: "connected"}` oder 503 `{status: "unhealthy", db: "disconnected"}`
+- **Auth:** kein Auth erforderlich
+- **Coolify:** nutzt Endpoint für Health-Check
+
+### F-INFRA-02: Backup & Restore
+- **Backup:** Docker-Volume-Backup konfiguriert
+- **Doku:** Restore-Dokumentation in README
+
+### F-INFRA-03: Logging
+- **Format:** Python `logging` mit JSON-Formatter
+- **Konfiguration:** Log-Level konfigurierbar via Env-Var
+- **Inhalt:** Method, Path, Status, Duration; Error-Logs mit Stacktrace
+
+### F-INFRA-04: Monitoring & Alerting
+- **Monitoring:** Coolify-Built-in-Monitoring nutzt `/api/health`
+- **Optional:** externes Monitoring-Tool
+
+### F-MIG-01: CSV-Import
+- **Endpoint:** POST `/api/import` mit CSV-Datei + Entity-Type
+- **Response:** Import-Job mit success/skipped/failed counts
+
+### F-INT-01: E-Mail-Integration (Passwort-Reset)
+- **Config:** SMTP via Env-Vars (SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS)
+- **Templates:** E-Mail-Templates für Reset
+
+### F-INT-02: API-Keys / Token-Auth
+- **Auth:** Session-Auth-Middleware auf allen Endpoints außer `/api/health` und `/api/auth/*`
+- **Optional:** API-Key für externe Integrationen (post-MVP)
+
+### F-TEST-01: Testing-Strategie
+- **Backend:** pytest + httpx für API-Tests; Coverage >80%
+- **Frontend:** Vitest für Component-Tests
+- **E2E:** Playwright für Critical Paths
+- **CI:** Coverage-Report in CI; bei Fehlschlag wird Build blockiert
+
+### F-ENV-01: Environments & Secrets
+- **Env-Vars:** `LEOCRM_SECRET_KEY` (Session-Secret, min 32 Zeichen)
+- **Datei:** `.env.example` dokumentiert alle Vars
+- **Secrets:** keine Secrets im Git-Repo
+- **Coolify:** Env-Vars konfiguriert
+
+### F-DOC-01: Dokumentation
+- **README:** `README.md` mit Setup-Anleitung
+- **API-Doku:** `/docs` (Swagger/OpenAPI) auto-gen via FastAPI
+- **Admin-Doku:** `docs/admin-guide.md` für Deploy/Backup/Restore
+
+### F-PERF-01: Performance
+- **Response-Zeit:** <500ms für List-Endpunkte bei 200k Datensätzen
+- **DB-Indizes:** last_name, first_name, email, company.name, company.industry, company.country
+- **Pagination:** verhindert Full-Table-Scan
+- **Export:** >50k Datensätze als Background-Job oder Streaming-Response
+
+### F-A11Y-01: Accessibility (WCAG 2.1 AA)
+- **CSS-Utility:** `.sr-only` CSS-Klasse (visual-hidden pattern)
+- **Kontrast:** >4.5:1
+- **Testing:** axe DevTools
+
+### F-A11Y-02: prefers-reduced-motion
+- **CSS:** `@media (prefers-reduced-motion: reduce)` Block in globalen Styles
+- **Properties:** alle `transition` und `animation` auf `none` oder `0.01ms`
+- **Testing:** Chrome DevTools (Rendering → Emulate CSS prefers-reduced-motion: reduce)
+
+### F-A11Y-03: 44px Touch-Targets
+- **CSS-Regel:** `min-height: 44px; min-width: 44px;` für alle interaktiven Elemente
+- **Alternative:** `::after` Pseudo-Element mit 44px Touch-Bereich
+- **Testing:** Chrome DevTools (375px Breite, Touch-Emulation)
+
+### F-SCHED-01: Background-Jobs
+- **Queue:** Background-Task-Queue (Celery, ARQ, oder FastAPI BackgroundTasks für v1)
+- **Status:** Job-Status-Endpoint
+- **Export-Limit:** >50k Datensätze als Background-Job, <50k als direkter Download
+
+---
+
+## 4. DB-Schema-Definitionen (Feld-Tabellen)
+
+### F-COMP-01: Company-Felder
+
+| Feld | Typ | Pflicht | Bemerkung |
+|------|-----|---------|-----------|
+| name | String(100) | ✅ | Firmenname |
+| account_number | String(40) | ❌ | Interne Referenznummer |
+| industry | Picklist | ❌ | IT, Finance, Manufacturing, etc. |
+| account_type | Picklist | ❌ | Customer, Partner, Prospect, etc. |
+| ownership | Picklist | ❌ | Public, Private, Government, etc. |
+| employees | Integer | ❌ | Anzahl Mitarbeiter |
+| annual_revenue | Decimal | ❌ | Jahresumsatz |
+| phone | String(30) | ❌ | Haupttelefon |
+| fax | String(30) | ❌ | Fax |
+| email | Email | ❌ | Allgemeine E-Mail |
+| website | URL | ❌ | Website |
+| rating | Picklist | ❌ | Hot, Warm, Cold |
+| parent_account_id | FK→Company | ❌ | Muttergesellschaft |
+| billing_street | String(250) | ❌ | Rechnungsadresse Strasse |
+| billing_city | String(100) | ❌ | Rechnungsadresse Stadt |
+| billing_state | String(100) | ❌ | Rechnungsadresse Bundesland |
+| billing_postal_code | String(20) | ❌ | Rechnungsadresse PLZ |
+| billing_country | String(100) | ❌ | Rechnungsadresse Land |
+| shipping_street | String(250) | ❌ | Besuchsadresse Strasse |
+| shipping_city | String(100) | ❌ | Besuchsadresse Stadt |
+| shipping_state | String(100) | ❌ | Besuchsadresse Bundesland |
+| shipping_postal_code | String(20) | ❌ | Besuchsadresse PLZ |
+| shipping_country | String(100) | ❌ | Besuchsadresse Land |
+| description | Text(32000) | ❌ | Notizfeld |
+| sic_code | String(10) | ❌ | Standard Industrial Classification |
+| ticker_symbol | String(30) | ❌ | Börsenkürzel |
+| account_site | String(80) | ❌ | Standort-Name (z.B. Headquarters) |
+
+### F-CONT-01: Contact-Felder
+
+| Feld | Typ | Pflicht | Bemerkung |
+|------|-----|---------|-----------|
+| first_name | String(50) | ❌ | Vorname |
+| last_name | String(50) | ✅ | Nachname |
+| salutation | Picklist | ❌ | Herr, Frau, Dr., etc. |
+| email | Email | ❌ | Haupt-E-Mail |
+| secondary_email | Email | ❌ | Zweit-E-Mail |
+| phone | String(30) | ❌ | Bürotelefon |
+| mobile | String(30) | ❌ | Mobiltelefon |
+| home_phone | String(30) | ❌ | Privattelefon |
+| fax | String(30) | ❌ | Fax |
+| title | String(100) | ❌ | Jobtitel (CEO, Manager, etc.) |
+| department | String(100) | ❌ | Abteilung |
+| reports_to | FK→Contact | ❌ | Vorgesetzter |
+| date_of_birth | Date | ❌ | Geburtsdatum |
+| assistant | String(50) | ❌ | Assistent-Name |
+| assistant_phone | String(30) | ❌ | Assistent-Telefon |
+| mailing_street | String(250) | ❌ | Postadresse Strasse |
+| mailing_city | String(100) | ❌ | Postadresse Stadt |
+| mailing_state | String(100) | ❌ | Postadresse Bundesland |
+| mailing_postal_code | String(20) | ❌ | Postadresse PLZ |
+| mailing_country | String(100) | ❌ | Postadresse Land |
+| other_street | String(250) | ❌ | Andere Adresse Strasse |
+| other_city | String(100) | ❌ | Andere Adresse Stadt |
+| other_state | String(100) | ❌ | Andere Adresse Bundesland |
+| other_postal_code | String(20) | ❌ | Andere Adresse PLZ |
+| other_country | String(100) | ❌ | Andere Adresse Land |
+| skype_id | String(50) | ❌ | Skype |
+| linkedin | URL | ❌ | LinkedIn-Profil |
+| twitter | String(50) | ❌ | Twitter-Handle |
+| description | Text(32000) | ❌ | Notizfeld |
+| company_ids | [FK→Company] | ❌ | N:M-Zuordnung (0..n Firmen) |
+
+### Implizite DB-Tabellen (aus Akzeptanzkriterien extrahiert)
+
+- `company_contacts` — N:M-Verknüpfungstabelle (company_id ↔ contact_id)
+- `audit_log` — Tabelle für Audit-Log-Einträge (user, action, entity, entity_id, timestamp)
+- `deletion_log` — Unveränderliche Tabelle für DSGVO-Löschungen
+- `users` — User-Tabelle (email, name, role, password_hash)
+- `companies` — Firmen-Tabelle (siehe Feld-Tabelle oben, + `deleted_at` TIMESTAMP für Soft-Delete)
+- `contacts` — Kontakt-Tabelle (siehe Feld-Tabelle oben, + `deleted_at` TIMESTAMP für Soft-Delete)
+
+---
+
+## 5. Nicht-funktionale Anforderungen (vollständige Tabelle)
+
+| ID | Kategorie | Anforderung | Metrik |
+|----|-----------|-------------|--------|
+| NF-01 | Performance | API-Response <500ms bei 200k Datensätzen | 95th Percentile <500ms |
+| NF-02 | Skalierung | DB-Connection-Pooling (SQLAlchemy Pool size=10) | Keine Connection-Erschöpfung bei 10 concurrent Users |
+| NF-03 | Sicherheit | Alle Passwörter bcrypt-gehashed (cost=12) | Keine Plain-Text-Passwörter in DB |
+| NF-04 | Sicherheit | Session-Secret via Env-Var, min 32 Zeichen | App startet nicht ohne Secret |
+| NF-05 | Verfügbarkeit | Health-Check für Coolify Auto-Restart | Auto-Restart bei 503 |
+| NF-06 | Wartbarkeit | Code-Struktur: `api/`, `models/`, `schemas/`, `services/`, `tests/` | Klare Trennung |
+| NF-07 | Wartbarkeit | Linting: ruff + black, pre-commit-hook | CI blockt bei Lint-Fehlern |
+| NF-08 | Testbarkeit | pytest Coverage >80% Backend | Coverage-Report in CI |
+| NF-09 | i18n | DE + EN, Sprachwahl persistiert | Alle UI-Texte übersetzt |
+| NF-10 | Accessibility | WCAG 2.1 AA | axe-Check: 0 Violations |
+| NF-11 | Logging | Strukturierte JSON-Logs | `docker logs` zeigt JSON-Einträge |
+| NF-12 | Deployment | Docker-Container auf Coolify | `docker-compose.yml` + `Dockerfile` |
+
+---
+
+## 6. Annahmen (entfernte Details)
+
+1. **Multi-Tenant (Multi-Company):** v1 ist Multi-Tenant (Multi-Company) — mehrere Organisationen, mehrere User.
+2. **PostgreSQL statt SQLite:** Bei 200k Kontakten + Multi-User + Concurrent Writes wird PostgreSQL empfohlen. SQLite limitiert auf ~15 concurrent updates/sec vs PostgreSQL ~1500/sec.
+3. **SPA-Frontend:** Client-side rendering mit React SPA (bestätigt durch genehmigten Prototyp leocrm-prototype-x7k2p9, v7).
+4. **Max 10 concurrent Users:** v1 ist für kleine Teams, nicht für Enterprise.
+5. **E-Mail-Versand:** SMTP via externem Provider (Mailtrap für Dev, Production-SMTP für Prod).
+6. **Soft-Delete als Default:** Firmen und Kontakte werden soft-deleted (recoverable), außer DSGVO-Löschung (hard delete).
+7. **Rollensystem v1:** 3 Rollen: admin, editor, viewer.
+8. **Export-Limit:** Export von >50k Datensätzen als Background-Job, <50k als direkter Download.
+9. **i18n-Default:** Deutsch ist Default-Sprache, Englisch ist zweites Locale.
+10. **Python 3.12:** Aktuelle stabile Python-Version.
+
+---
+
+## 7. Technologie-Wahlen (Alle Module)
+
+### Core-Stack
+| Technologie | Verwendung |
+|-------------|-----------|
+| FastAPI | Backend-Framework |
+| SQLAlchemy 2.0 | ORM |
+| PostgreSQL 16 | Datenbank |
+| React 18 SPA | Frontend |
+| Uvicorn (async) | ASGI-Server |
+| ruff + black | Linting |
+| pytest + httpx | Backend-Tests |
+| Vitest | Frontend-Tests |
+| Playwright | E2E-Tests |
+| Pydantic | Input-Validierung |
+| bcrypt (cost=12) | Passwort-Hashing |
+| Celery / ARQ / FastAPI BackgroundTasks | Background-Jobs |
+| react-i18next | i18n-Frontend |
+| Docker Compose | Multi-Container-Deployment |
+| Coolify | Deployment-Plattform |
+
+### DMS-Modul
+| Technologie | Verwendung |
+|-------------|-----------|
+| PDF.js | PDF-Preview im Browser |
+| OnlyOffice Document Server | Online-Bearbeitung (separater Container) |
+
+### Mail-Modul
+| Technologie | Verwendung |
+|-------------|-----------|
+| IMAP4rev1 (RFC 3501) | Mail-Empfang |
+| IMAP IDLE (RFC 2177) | Real-time Push für neue Mails |
+| SMTP Submission (RFC 6409) | Mail-Versand |
+| DOMPurify | HTML-Sanitization (XSS-Schutz) |
+| python-gnupg | PGP-Verschlüsselung (OpenPGP, RFC 4880) |
+| PostgreSQL Full-Text Search (tsvector) | Volltext-Suche über Mails |
+| AES-256 | Passwort-Verschlüsselung für IMAP/SMTP-Credentials |
+
+---
+
+## 8. Farbcodes (Hex-Werte)
+
+### Kalender-Modul (F-CAL-06)
+
+| Eintrags-Typ | Subtyp | Farbe (Hex) |
+|-------------|-------|-------------|
+| appointment | normal | `#3B82F6` (blau) |
+| task | normal | `#F59E0B` (gelb) |
+| * | follow_up | `#F97316` (orange) |
+| * | private | `#9CA3AF` (grau) |
+
+### Tag-System (F-TAG-02)
+- Tags können mit Farbe versehen werden, z.B. `#FF0000` für „VIP"
+
+---
+
+## 9. Protokoll-Details (Mail-Modul)
+
+### IMAP
+- **Protokoll:** IMAP4rev1 (RFC 3501)
+- **IDLE:** RFC 2177 für Push, Fallback: Polling alle 5 Min
+- **Port:** 993 (SSL/TLS)
+- **Auth:** PLAIN/LOGIN
+- **MOVE:** RFC 6851 (Fallback: COPY + STORE \\Deleted + EXPUNGE)
+- **Flags:** `\\Seen`, `\\Flagged`, `\\Answered`, `\\Draft`, `$Spam`
+- **Kompatibilität:** Getestet mit Dovecot, Courier IMAP
+
+### SMTP
+- **Protokoll:** SMTP Submission (RFC 6409)
+- **Port 587:** mit STARTTLS
+- **Port 465:** mit SSL
+- **Auth:** PLAIN/LOGIN mit Benutzername+Passwort
+
+### PGP
+- **Standard:** OpenPGP (RFC 4880)
+- **Library:** python-gnupg
+- **Private Key:** verschlüsselt gespeichert (AES-256 + Passphrase)
+- **Passphrase:** nicht gespeichert, nur im Session-Cache
+- **Public Key:** pro Kontakt speicherbar
+- **S/MIME:** post-MVP
+
+### Attachment-Storage
+- Anhänge werden lokal gespeichert (Dateisystem oder S3)
+- Nicht im IMAP-Server belassen (Caching)
+- Mail-Body wird in PostgreSQL gespeichert
+- Anhänge bei Bedarf vom IMAP-Server nachgeladen
+- Max: 25 MB pro Anhang, 50 MB pro Mail
+
+### Passwort-Speicherung
+- IMAP/SMTP-Passwörter AES-256 verschlüsselt
+- Key via Env-Var `MAIL_ENCRYPTION_KEY`
+
+### Ordner-Mapping
+- INBOX → Posteingang
+- Sent → Postausgang
+- Drafts → Entwürfe
+- Spam/Junk → Spam
+
+### Threading
+- Basierend auf `References`- und `In-Reply-To`-Headern (RFC 5322)
+
+### HTML-Rendering
+- Sanitization mit DOMPurify (XSS-Schutz)
+- Inline-Styles erlaubt, Scripts/IFrames entfernt
+- Plain-Text-Fallback
+
+---
+
+## 10. RFC-Referenzen (alle)
+
+| RFC | Titel | Verwendung |
+|-----|-------|-----------|
+| RFC 3501 | IMAP4rev1 | Mail-Empfang |
+| RFC 2177 | IMAP IDLE | Real-time Push |
+| RFC 6851 | IMAP MOVE | Mail verschieben |
+| RFC 6409 | SMTP Submission | Mail-Versand |
+| RFC 4880 | OpenPGP | PGP-Verschlüsselung |
+| RFC 5322 | Internet Message Format | Threading (References/In-Reply-To) |
+| RFC 5545 | iCalendar | Recurrence Rules (RRULE) für wiederkehrende Termine |
+| RFC 6047 | iMIP | (Non-Goal: nicht in v2-mail) |
+| RFC 8620 | JMAP | (Non-Goal: nicht unterstützt) |
+
+---
+
+## 11. DMS-Modul: HTTP-Endpunkte & Architektur-Details
+
+### F-DMS-01: Ordner-Struktur
+- **Create:** POST `/api/dms/folders` → 201
+- **Rename/Move:** PATCH `/api/dms/folders/{id}` → 200
+- **Delete:** DELETE `/api/dms/folders/{id}` → 200 (Soft-Delete)
+- **Zirkuläre Verschiebung:** serverseitig verhindert → 422
+
+### F-DMS-02: Datei-Upload
+- **Endpoint:** POST `/api/dms/files/upload` (multipart) → 201 mit Datei-Metadaten
+- **Max-Size:** 413 bei Überschreitung (Default 100 MB)
+- **Status:** WebSocket oder Polling
+
+### F-DMS-03: Datei-Operationen
+- **Rename:** PATCH `/api/dms/files/{id}` → 200
+- **Move:** PATCH `/api/dms/files/{id}` mit `folder_id` → 200
+- **Delete:** DELETE `/api/dms/files/{id}` → 200 (Soft-Delete)
+- **Restore:** POST `/api/dms/files/{id}/restore` → 200
+
+### F-DMS-04: PDF-Preview
+- **Endpoint:** GET `/api/dms/files/{id}/preview` → 200 mit `Content-Type: application/pdf`
+- **Frontend:** PDF.js
+- **Non-PDF:** 415 Unsupported Media Type
+
+### F-DMS-05: OnlyOffice Integration
+- **Server:** OnlyOffice Document Server als separater Container (Coolify)
+- **Endpoint:** POST `/api/dms/files/{id}/edit-session` → 200 mit OnlyOffice-URL
+- **Formate:** DOCX, XLSX, PPTX
+
+### F-DMS-06: Datei-Metadaten
+- **Endpoint:** GET `/api/dms/files/{id}` → 200 mit `{name, size, mime_type, uploaded_at, modified_at, uploaded_by}`
+- **Größe:** serverseitig in Bytes, clientseitig formatiert
+
+### F-DMS-07: Datei-Suche
+- **Endpoint:** GET `/api/dms/search?q=vertrag&folder_id={id}` → 200 mit `{items: [{type, name, path, ...}]}`
+- **Global:** ohne `folder_id` → gesamte DMS
+
+### F-LINK-01: Dateien mit Firmen verknüpfen
+- **Endpoint:** POST `/api/dms/files/{id}/link` mit `{entity_type: "company", entity_id: N}` → 201
+- **Delete:** DELETE `/api/dms/files/{id}/link?entity_type=company&entity_id=N` → 204
+- **Unique Constraint:** Duplikate serverseitig verhindert
+
+### F-LINK-02: Dateien mit Kontakten verknüpfen
+- **Endpoint:** POST `/api/dms/files/{id}/link` mit `{entity_type: "contact", entity_id: N}` → 201
+
+### F-LINK-03: Verknüpfte Dateien in Firmen-Detail
+- **Response:** GET `/api/companies/{id}` enthält `linked_files: [{id, name, size, mime_type, modified_at}]`
+
+### F-LINK-04: Verknüpfte Dateien in Kontakt-Detail
+- **Response:** GET `/api/contacts/{id}` enthält `linked_files: [{id, name, size, mime_type, modified_at}]`
+
+### F-LINK-05: Reverse-Verknüpfung
+- **Response:** GET `/api/dms/files/{id}` enthält `linked_entities: [{entity_type, entity_id, entity_name}]`
+- **Delete:** DELETE `/api/dms/files/{id}/link?entity_type=company&entity_id=N` → 204
+
+### F-LINK-06: Mehrfach-Verknüpfung
+- **Bulk:** POST `/api/dms/files/bulk-link` mit `{file_ids: [...], entity_type: "company", entity_id: N}` → 201
+- **Ordner:** POST `/api/dms/folders/{id}/link`
+
+### F-TAG-01: Tags anwenden
+- **Assign:** POST `/api/tags/assign` mit `{entity_type, entity_id, tag_id}` → 201
+- **Remove:** DELETE `/api/tags/assign?entity_type=...&entity_id=...&tag_id=...` → 204
+- **Unique Constraint:** (entity_type, entity_id, tag_id)
+
+### F-TAG-02: Tag-Verwaltung
+- **Create:** POST `/api/tags` (Admin) → 201
+- **Update:** PATCH `/api/tags/{id}` → 200
+- **Delete:** DELETE `/api/tags/{id}` → 204 mit Cascade Delete auf `tag_assignments`
+- **Non-Admin:** → 403
+
+### F-TAG-03: Tag-Filterung
+- **Endpoint:** GET `/api/companies?tag_ids=1,2&tag_mode=and` → 200
+- **Modi:** `tag_mode=or` → OR-Verknüpfung
+- **Gleiche Parameter** für `/api/contacts`, `/api/dms/files`
+
+### F-TAG-04: Tag-Cloud
+- **Endpoint:** GET `/api/tags?with_counts=true` → 200 mit `[{id, name, color, count}]`
+
+### F-PERM-01: Persönlicher Root-Ordner
+- **User-Creation:** automatisch `personal_folder_id` gesetzt
+- **Ownership-Check:** GET `/api/dms/folders/{id}` prüft Ownership → 403 bei fremdem Ordner (außer Admin)
+
+### F-PERM-02: Gemeinsame Root-Ordner
+- **Create:** POST `/api/dms/folders` mit `shared_with_group_id` → 201
+- **Permissions:** `folder_permissions` Tabelle (folder_id, group_id, permission: read|write)
+
+### F-PERM-03: Datei/Ordner mit Usern teilen
+- **Share:** POST `/api/dms/files/{id}/share` mit `{user_id, permission: "read|write"}` → 201
+- **Remove:** DELETE `/api/dms/files/{id}/share?user_id=N` → 204
+- **Shared-with-me:** GET `/api/dms/shared-with-me` → 200
+
+### F-PERM-04: Datei/Ordner mit Gruppen teilen
+- **Share:** POST `/api/dms/files/{id}/share` mit `{group_id, permission: "read|write"}` → 201
+- **Resolution:** Individual > Group > Default (Deny vor Allow)
+- **Remove:** DELETE `/api/dms/files/{id}/share?group_id=N` → 204
+
+### F-PERM-05: Share-Links
+- **Create:** POST `/api/dms/files/{id}/share-link` mit `{password?, expires_at?, download_only?}` → 201 mit `{url}`
+- **Public:** GET `/api/public/share/{token}` → 200 (oder 401 bei Passwort, 410 bei abgelaufen)
+- **Public-Endpoint:** braucht keine Auth
+
+### F-PERM-06: Berechtigungs-Anzeige
+- **Endpoint:** GET `/api/dms/files/{id}/permissions` → 200 mit `{owner: {id, name}, shares: [{user_id?, group_id?, name, permission}], share_links: [{id, url, has_password, expires_at, is_active}]}`
+
+### F-FILEUI-01: Datei-Browser
+- **Komponenten:** `FileBrowser` mit `SidebarTree` + `MainView` (Grid/List Toggle)
+- **State-Management:** für aktiven Ordner
+
+### F-FILEUI-02: Breadcrumb-Navigation
+- **Komponente:** `Breadcrumb` mit klickbaren Segmenten
+- **Pfad:** aus `folder.path` (Materialized Path oder rekursive Abfrage) generiert
+
+### F-FILEUI-03: Kontext-Menü
+- **Komponente:** `ContextMenu` mit dynamischen Items basierend auf `entity_type` (file/folder) und `permission` (read/write)
+- **Mobile:** Long-Press statt Rechtsklick
+
+### F-FILEUI-04: Bulk-Aktionen
+- **Move:** POST `/api/dms/files/bulk-move` mit `{file_ids: [...], target_folder_id}` → 200
+- **Delete:** POST `/api/dms/files/bulk-delete` → 200
+- **Tag:** POST `/api/tags/bulk-assign` → 201
+
+### F-FILEUI-05: Upload-Progress
+- **Komponente:** `UploadProgress` mit pro-Datei Progress
+- **Upload:** via `XMLHttpRequest` (für Progress-Events) oder WebSocket
+
+### F-FILEUI-06: Drag & Drop
+- **Frontend:** HTML5 Drag & Drop API
+- **Drop-Target:** validiert Permission clientseitig (grün = erlaubt, rot = verboten)
+- **Server:** PATCH `/api/dms/files/{id}` mit `folder_id` → Permission-Check → 200 oder 403
+
+---
+
+## 12. Kalender-Modul: HTTP-Endpunkte & Architektur-Details
+
+### Architektur-Hinweis
+
+Ein Kalender-Eintrag (`CalendarEntry`) hat einen `entry_type`:
+- **`appointment`** — Termin mit Start/Ende (Datum+Zeit), optional Ganztägig, Ort, Teilnehmer
+- **`task`** — Aufgabe mit Fälligkeitsdatum (due_date), Priorität, Status, Sub-Tasks, Zuständiger — keine feste Uhrzeit
+
+Beide Typen teilen sich die gleichen Verknüpfungs-, Erinnerungs-, Wiederholungs- und Anzeige-Mechanismen.
+
+### F-CAL-01: Kalender-Ansichten
+- **Frontend:** `CalendarView` Komponente mit `mode: month|week|day`
+- **Endpoint:** GET `/api/calendar/entries?from=2026-06-01&to=2026-06-30` → 200 mit Entry-Array
+
+### F-CAL-02: Kanban-Zeitraum-Ansicht
+- **Frontend:** `KanbanCalendar` Komponente mit `period: this_week|next_2_weeks|this_month|custom`
+- **Endpoint:** GET `/api/calendar/kanban?period=this_week` → 200 mit `{columns: [{date, appointments: [...], tasks: [...]}]}`
+
+### F-CAL-03: Kalender-Eintrag erstellen
+- **Endpoint:** POST `/api/calendar/entries` → 201
+- **Fields appointment:** `entry_type`, `title`, `description?`, `start_at`, `end_at`, `all_day?`, `location?`, `attendees?`
+- **Fields task:** `entry_type`, `title`, `description?`, `due_date?`, `priority: "high|medium|low"`, `status?: "open"`
+- **Validierung:** end_at > start_at (außer all_day=true); title nicht leer
+
+### F-CAL-04: Einträge mit Entitäten verknüpfen
+- **Link:** POST `/api/calendar/entries/{id}/link` mit `{entity_type: "company|contact|deal", entity_id: N}` → 201
+- **Response companies:** GET `/api/companies/{id}` enthält `upcoming_events: [...]` und `open_tasks: [...]`
+
+### F-CAL-05: Drag & Drop im Kalender
+- **Frontend:** HTML5 Drag & Drop auf Kalender-Zellen (appointments) und Kanban-Spalten (tasks)
+- **Update:** PATCH `/api/calendar/entries/{id}` mit neuem `start_at`/`end_at` (appointment) oder `status` (task) → 200
+- **Optimistic Update** mit Rollback bei Fehler
+
+### F-CAL-06: Farbcodierung
+- **Fields:** `entry_type: appointment|task` und `subtype: normal|follow_up|private`
+- **Color Map:** `{appointment+normal: "#3B82F6", task+normal: "#F59E0B", *+follow_up: "#F97316", *+private: "#9CA3AF"}`
+- **Update:** PATCH `/api/calendar/entries/{id}` mit `subtype` → 200
+
+### F-CAL-07: Erinnerungen/Alerts
+- **Field:** `reminder: {value: N, unit: "minutes|hours|days", channel: "in_app|email"}`
+- **Background-Job:** prüft fällige Erinnerungen (Cron, minütlich)
+- **Notification:** POST `/api/notifications` bei Fälligkeit
+- **Überfällig-Check:** täglicher Cron-Job
+
+### F-CAL-08: Wiederkehrende Einträge
+- **Field:** `recurrence: {pattern: "daily|weekly|monthly|yearly|custom", custom_rule?, end_date?, exceptions?: [dates]}`
+- **Appointments:** Server generiert Instanzen via RRULE (RFC 5545)
+- **Tasks:** bei Status-Wechsel auf `done` → POST `/api/calendar/entries` mit neuem `due_date`
+- **Status `cancelled`:** keine Generierung
+
+### F-CAL-09: Kalender-Feeds (ICS)
+- **Export:** GET `/api/calendar/{calendar_id}/ics-feed?token={user_token}` → 200 mit `Content-Type: text/calendar` (RFC 5545 konform)
+- **Import:** POST `/api/calendar/import` (multipart ICS, optional calendar_id) → 201 mit `{imported: N, skipped: M}`
+- **Auth:** Token-basierte Auth für Feed-URL
+
+### F-CAL-10: Ressourcen-Booking
+- **Create Resource:** POST `/api/resources` (Admin) → 201
+- **Book:** POST `/api/calendar/entries/{id}/book-resource` mit `{resource_id}` → 201 oder 409 bei Konflikt
+- **Bookings:** GET `/api/resources/{id}/bookings?from=...&to=...` → 200
+
+### F-CAL-11: Mehrere Kalender
+- **Create:** POST `/api/calendars` mit `{name, color, type: "personal|team|project|company"}` → 201
+- **Auto-Create:** bei User-Anlage automatisch POST `/api/calendars` mit `{name: "Mein Kalender", type: "personal"}`
+- **List:** GET `/api/calendars` → 200 mit sichtbaren Kalendern
+- **Delete:** DELETE `/api/calendars/{id}` → 204 (Cascade auf Einträge)
+
+### F-CAL-12: Kalender abonnieren
+- **Frontend:** `CalendarSidebar` mit Toggle-Switches pro Kalender
+- **Endpoint:** GET `/api/calendar/entries?calendar_ids=1,3,5` → 200
+- **State:** persistiert pro User (`user_calendar_visibility` Tabelle)
+
+### F-CAL-13: Kalender teilen
+- **Share:** POST `/api/calendars/{id}/share` mit `{user_id?, group_id?, permission: "read|write"}` → 201
+- **Remove:** DELETE `/api/calendars/{id}/share?user_id=N` → 204
+- **Permissions:** GET `/api/calendars/{id}/permissions` → 200 mit `{owner, shares}`
+
+### F-CAL-14: Default-Kalender
+- **Setting:** `default_calendar_id` (User-Setting)
+- **Update:** PATCH `/api/users/me/settings` mit `{default_calendar_id: N}` → 200
+- **Fallback:** persönlicher Kalender bei keinem Setting
+
+### F-CAL-15: Aufgaben-Zuweisung
+- **Field:** `assigned_to: user_id` (nur für entry_type=task)
+- **Update:** PATCH `/api/calendar/entries/{id}` mit `assigned_to` → 200, sendet Notification
+- **Query:** GET `/api/calendar/entries?entry_type=task&assigned_to={user_id}` → 200
+
+### F-CAL-16: Sub-Tasks
+- **Create:** POST `/api/calendar/entries/{id}/subtasks` mit `{title}` → 201 (nur für entry_type=task)
+- **Update:** PATCH `/api/calendar/entries/{id}/subtasks/{sub_id}` mit `{completed: true}` → 200
+- **Response:** GET `/api/calendar/entries/{id}` enthält `subtasks: [{id, title, completed}]` und `progress: {completed, total}`
+
+### F-CAL-17: Aufgaben-Filter & Liste
+- **Query:** GET `/api/calendar/entries?entry_type=task&assigned_to={id}&priority=high&status=open&due_filter=overdue&page=1&page_size=25&sort_by=due_date&sort_order=asc` → 200 mit `{items, total, page, page_size}`
+- **Export:** GET `/api/calendar/entries/export?format=csv&entry_type=task&status=open` → 200 mit CSV-Download
+- **Frontend:** `TaskKanban` (4 Spalten) und `TaskList` (DataTable) Komponenten
+
+### F-CAL-18: Bulk-Aktionen
+- **Endpoint:** POST `/api/calendar/entries/bulk` mit `{entry_ids: [...], action: "status|assign|due_date|delete", value: ...}` → 200 mit `{updated: N}`
+
+---
+
+## 13. Mail-Modul: HTTP-Endpunkte & Architektur-Details
+
+### F-MAIL-01: Standard-Ordner
+- **Endpoint:** GET `/api/mail/folders` → 200 mit `{folders: [{id, name, type: "inbox|sent|drafts|spam|custom", unread_count, total_count}]}`
+- **IMAP IDLE-Listener:** läuft als Background-Task, neue Mails innerhalb von 5 Sekunden
+- **Bidirektionale Flag-Sync:** \\Seen, \\Flagged, \\Answered, \\Draft, $Spam
+
+### F-MAIL-02: E-Mail schreiben
+- **Send:** POST `/api/mail/send` mit `{to: [...], cc: [...], bcc: [...], subject, body_html, in_reply_to?, attachments: [...]}` → 201
+- **Draft:** POST `/api/mail/drafts` → speichert Entwurf
+- **Reply:** POST `/api/mail/{id}/reply` → erstellt Reply mit vorausgefüllten Feldern
+- **Forward:** POST `/api/mail/{id}/forward` → erstellt Forward
+- **HTML-Sanitization:** DOMPurify
+
+### F-MAIL-03: Volltext-Suche
+- **Endpoint:** GET `/api/mail/search?q=angebot&folder=inbox&date_from=...&date_to=...` → 200 mit `{items: [{id, subject, from, date, snippet, folder}], total}`
+- **Index:** PostgreSQL tsvector-Index über `mail_body_tsv` und `mail_subject_tsv`
+- **Performance:** <500ms bei 10.000 Mails
+
+### F-MAIL-04: Anhänge
+- **Send:** POST `/api/mail/send` mit multipart-Form-Data für Anhänge
+- **Download:** GET `/api/mail/{id}/attachments/{att_id}` → 200
+- **Content-Disposition:** `attachment` für Downloads, `inline` für inline-Bilder
+- **Max:** 25 MB pro Anhang, 50 MB pro Mail
+
+### F-MAIL-05: Threading
+- **Endpoint:** GET `/api/mail/threads?folder=inbox` → 200 mit `{items: [{thread_id, subject, participants, message_count, last_date, messages: [{id, from, date, snippet}]}]}`
+- **Basis:** `In-Reply-To`/`References`-Header (RFC 5322)
+- **Frontend:** `ThreadView` Komponente
+
+### F-MAIL-06: Vorlagen/Templates
+- **Create:** POST `/api/mail/templates` mit `{name, subject, body_html, shared: false}` → 201
+- **List:** GET `/api/mail/templates?scope=me|shared` → 200
+- **Compose:** POST `/api/mail/compose?template_id=N&contact_id=M&company_id=K` → 200 mit aufgelösten Platzhaltern
+- **Syntax:** `{{entity.field}}`
+
+### F-MAIL-07: Filter/Regeln
+- **Create:** POST `/api/mail/rules` mit `{name, conditions: [{field, operator, value}], actions: [{type, value}]}` → 201
+- **Evaluation:** Background-Worker nach IMAP-IDLE-Trigger
+- **List:** GET `/api/mail/rules` → 200
+- **Delete:** DELETE `/api/mail/rules/{id}` → 204
+
+### F-MAIL-08: Abwesenheitsnotiz
+- **Endpoint:** POST `/api/mail/vacation` mit `{active: true, subject, body, start_date, end_date}` → 201
+- **Background-Worker:** prüft eingehende Mails, `vacation_sent_log` Tabelle (einmal pro Absender)
+- **No-Reply-Erkennung:** Absender enthält „noreply", „no-reply", „donotreply"
+
+### F-MAIL-09: Labels/Flags
+- **Flag:** PATCH `/api/mail/{id}/flags` mit `{starred: true}` → 200, setzt IMAP \\Flagged
+- **Label:** POST `/api/mail/{id}/labels` mit `{label_id: N}` → 201
+- **Filter:** GET `/api/mail?label=vertrieb` → 200
+- **Label-Verwaltung:** POST `/api/mail/labels` mit `{name, color}`
+
+### F-MAIL-10: Kontakt-Verknüpfung
+- **Contact-Mails:** GET `/api/contacts/{id}/emails` → 200 mit `{items: [{id, subject, from, date, direction: "in|out", thread_id}]}`
+- **Company-Mails:** GET `/api/companies/{id}/emails` → 200
+- **Auto-Verknüpfung:** Background-Job matcht Absender/Empfänger gegen `contacts.email`-Feld
+- **Manual:** POST `/api/mail/{id}/link` mit `{contact_id, company_id}`
+
+### F-MAIL-11: Kalender-Integration
+- **Endpoint:** POST `/api/mail/{id}/create-event` mit `{date, time, duration, calendar_id?, title?}` → 201
+- **Defaults:** Titel = Mail-Betreff, Beschreibung = Mail-Body (plain text), Teilnehmer = Mail-Absender
+- **Link:** `calendar_entry.source_mail_id = mail.id`
+
+### F-MAIL-12: PGP-Verschlüsselung
+- **Import Private Key:** POST `/api/mail/pgp/keys` mit `{private_key, passphrase}` → 201 (verschlüsselt gespeichert)
+- **Import Public Key:** POST `/api/contacts/{id}/pgp-key` mit `{public_key}` → 201
+- **Encrypt Send:** POST `/api/mail/send` mit `{encrypt: true}` → python-gnupg Verschlüsselung
+- **Decrypt:** GET `/api/mail/{id}` → erkennt PGP-Block, entschlüsselt bei vorhandener Passphrase (Session-Cache)
+
+### F-MAIL-13: Signaturen
+- **Create:** POST `/api/mail/signatures` mit `{name, body_html}` → 201
+- **Assign Default:** PATCH `/api/mail/accounts/{id}` mit `{default_signature_id: N}` → 200
+- **Compose:** POST `/api/mail/compose?account_id=N` → Response enthält `signature`-Feld
+
+### F-MAIL-14: Mehrere Postfächer
+- **Create:** POST `/api/mail/accounts` mit `{name, imap_host, imap_port, imap_ssl, smtp_host, smtp_port, smtp_ssl, username, password}` → 201 (Passwort verschlüsselt)
+- **List:** GET `/api/mail/accounts` → 200
+- **Default:** PATCH `/api/users/me/settings` mit `{default_mail_account_id: N}`
+
+### F-MAIL-15: Geteilte Postfächer
+- **Create:** POST `/api/mail/accounts` mit `{type: "shared", name: "info@firma.de", ...}` → 201
+- **Assign Users:** POST `/api/mail/accounts/{id}/users` mit `{user_ids: [1, 2, 3]}` → 200
+- **List:** GET `/api/mail/accounts/shared` → 200
+- **Seen-By:** `mail_seen_by` Tabelle (mail_id, user_id, seen_at)
+
+### F-MAIL-16: Stellvertretung
+- **Delegate:** POST `/api/mail/accounts/{id}/delegates` mit `{delegate_user_id, permission: "read|full"}` → 201
+- **Remove:** DELETE `/api/mail/accounts/{id}/delegates?user_id=N` → 204
+- **List:** GET `/api/mail/accounts?include_delegated=true` → 200 mit `delegated: true` Markierung
+
+### F-MAIL-17: Sende-Berechtigungen
+- **Grant:** POST `/api/mail/accounts/{id}/send-permissions` mit `{user_ids: [...]}` → 200
+- **List:** GET `/api/mail/accounts/{id}/send-permissions` → 200
+- **Send-Check:** POST `/api/mail/send` mit `{from_account_id: N}` → prüft, 403 wenn nicht
+
+### F-MAIL-18: Postfach-Konfiguration
+- **Create:** POST `/api/mail/accounts` mit `{imap_host, imap_port, imap_ssl: true, smtp_host, smtp_port, smtp_starttls: true, username, password}`
+- **Validierung:** IMAP-Login + SMTP-Login, 422 bei Fehler
+- **Verschlüsselung:** AES-256, Key via Env-Var `MAIL_ENCRYPTION_KEY`
+- **Maskierung:** GET `/api/mail/accounts/{id}` → Passwort-Feld ist `***`
+
+### F-MAIL-19: Mail-Ordner verwalten
+- **Create:** POST `/api/mail/folders` mit `{name, parent_id?}` → 201, führt IMAP CREATE aus
+- **Rename:** PATCH `/api/mail/folders/{id}` mit `{name}` → 200, führt IMAP RENAME aus
+- **Delete:** DELETE `/api/mail/folders/{id}` → 204, führt IMAP DELETE aus
+
+---
+
+## 14. Mail-Modul: Technische Constraints (vollständige Tabelle)
+
+| Constraint | Beschreibung |
+|-----------|-------------|
+| IMAP-Protokoll | IMAP4rev1 (RFC 3501) — Server muss IMAP IDLE (RFC 2177) für Push unterstützen |
+| SMTP-Protokoll | SMTP Submission (RFC 6409) — Port 587 mit STARTTLS oder Port 465 mit SSL |
+| Auth | SMTP: PLAIN/LOGIN mit Benutzername+Passwort; IMAP: PLAIN/LOGIN |
+| Attachment-Storage | Anhänge lokal gespeichert (DMS-Integration), nicht im IMAP-Server belassen (Caching) |
+| IMAP IDLE | Real-time Push; Fallback: Polling alle 5 Min |
+| Volltext-Suche | PostgreSQL Full-Text Search (tsvector) über Mail-Body + Anhang-Namen (OCR optional post-MVP) |
+| HTML-Rendering | Sanitization mit DOMPurify (XSS-Schutz); Plain-Text-Fallback |
+| Verschlüsselung | PGP (OpenPGP, RFC 4880) via python-gnupg; S/MIME post-MVP |
+| Mail-Sync | Bidirektionale Sync: IMAP-Flags (Seen/Flagged) synchronisiert |
+| Ordner-Mapping | INBOX→Posteingang, Sent→Postausgang, Drafts→Entwürfe, Spam/Junk→Spam |
+| Passwort-Speicherung | IMAP/SMTP-Passwörter AES-256 verschlüsselt, Key via Env-Var MAIL_ENCRYPTION_KEY |
+| Max Anhang-Größe | 25 MB pro Anhang, 50 MB pro Mail |
+
+---
+
+## 15. Mail-Modul: Annahmen
+
+1. **IMAP-Server-Kompatibilität:** IMAP4rev1 (RFC 3501), getestet mit Dovecot, Courier IMAP.
+2. **SMTP-Auth:** SMTP-Server muss Authentifizierung unterstützen (PLAIN/LOGIN). Kein Open-Relay.
+3. **IMAP IDLE:** Server muss RFC 2177 unterstützen. Fallback: Polling alle 5 Minuten.
+4. **IMAP MOVE:** Server muss RFC 6851 unterstützen. Fallback: COPY + STORE \\Deleted + EXPUNGE.
+5. **Attachment-Storage:** Lokal (Dateisystem oder S3), Caching in PostgreSQL.
+6. **Maximale Anhang-Größe:** 25 MB pro Anhang, 50 MB pro Mail.
+7. **Passwort-Speicherung:** AES-256 verschlüsselt, Key via `MAIL_ENCRYPTION_KEY`.
+8. **HTML-Sanitization:** DOMPurify, Inline-Styles erlaubt, Scripts/IFrames entfernt.
+9. **Multi-Tenant (Multi-Company):** Mail-Modul ist Multi-Tenant (Multi-Company).
+10. **PGP-Key-Verwaltung:** Private Keys verschlüsselt (AES-256 + Passphrase). Passphrase nicht gespeichert, nur Session-Cache.
+
+---
+
+## 16. Implizite DB-Tabellen (aus allen Akzeptanzkriterien extrahiert)
+
+| Tabelle | Modul | Zweck |
+|---------|-------|-------|
+| `users` | Core | User (email, name, role, password_hash, default_calendar_id, default_mail_account_id) |
+| `companies` | Core | Firmen (siehe Feld-Tabelle + deleted_at, created_at) |
+| `contacts` | Core | Kontakte (siehe Feld-Tabelle + deleted_at, created_at) |
+| `company_contacts` | Core | N:M-Verknüpfung (company_id, contact_id) |
+| `audit_log` | Core | Audit (user, action, entity, entity_id, timestamp) |
+| `deletion_log` | Core | Unveränderliche DSGVO-Lösch-Logs |
+| `dms_folders` | DMS | Ordner (id, name, parent_id, owner_id, deleted_at) |
+| `dms_files` | DMS | Dateien (id, name, folder_id, size, mime_type, uploaded_at, modified_at, uploaded_by, deleted_at) |
+| `file_links` | DMS | Verknüpfung (file_id, entity_type, entity_id) — Unique Constraint |
+| `tags` | DMS | Tags (id, name, color) |
+| `tag_assignments` | DMS | Zuordnung (entity_type, entity_id, tag_id) — Unique Constraint |
+| `folder_permissions` | DMS | (folder_id, group_id, permission: read|write) |
+| `file_shares` | DMS | (file_id, user_id?, group_id?, permission) |
+| `share_links` | DMS | (file_id, token, password?, expires_at?, download_only?) |
+| `calendar_entries` | Kalender | (id, entry_type, title, description, start_at?, end_at?, due_date?, all_day?, location?, priority?, status?, assigned_to?, calendar_id, subtype, reminder, recurrence) |
+| `calendars` | Kalender | (id, name, color, type, owner_id) |
+| `calendar_entry_links` | Kalender | (entry_id, entity_type, entity_id) |
+| `calendar_shares` | Kalender | (calendar_id, user_id?, group_id?, permission) |
+| `user_calendar_visibility` | Kalender | (user_id, calendar_id, visible) |
+| `subtasks` | Kalender | (entry_id, title, completed) |
+| `resources` | Kalender | (id, name, type) — später |
+| `resource_bookings` | Kalender | (resource_id, entry_id, from, to) — später |
+| `mail_accounts` | Mail | (id, user_id, name, imap_host, imap_port, imap_ssl, smtp_host, smtp_port, smtp_ssl/starttls, username, password_encrypted, type) |
+| `mails` | Mail | (id, account_id, folder_id, subject, body_html, body_text, from, to, cc, bcc, date, in_reply_to, references, thread_id, seen, flagged, has_attachments) |
+| `mail_attachments` | Mail | (mail_id, filename, mime_type, size, dms_file_id) |
+| `mail_folders` | Mail | (id, account_id, name, type, parent_id, unread_count, total_count) |
+| `mail_labels` | Mail | (id, name, color) |
+| `mail_label_assignments` | Mail | (mail_id, label_id) |
+| `mail_rules` | Mail | (id, account_id, name, conditions, actions, priority) |
+| `mail_templates` | Mail | (id, user_id, name, subject, body_html, shared) |
+| `mail_signatures` | Mail | (id, user_id, name, body_html) |
+| `vacation_sent_log` | Mail | (account_id, sender_address, sent_at) |
+| `mail_seen_by` | Mail | (mail_id, user_id, seen_at) |
+| `mail_account_delegates` | Mail | (account_id, delegate_user_id, permission) |
+| `mail_account_send_permissions` | Mail | (account_id, user_id) |
+| `pgp_keys` | Mail | (user_id, private_key_encrypted, public_key) |
+| `contact_pgp_keys` | Mail | (contact_id, public_key) |
+| `notifications` | Core | (id, user_id, type, title, body, created_at, read_at) |
+
+---
+
+## 17. Historische v0.1 Endpoints (archiviert)
+
+| Endpoint | Historisch | Aktuell |
+|----------|-----------|--------|
+| POST `/login` | F-1 | POST `/api/auth/login` |
+| POST `/logout` | F-2 | POST `/api/auth/logout` |
+| GET `/companies` | F-5 | GET `/api/companies` |
+| POST `/companies` | F-5 | POST `/api/companies` |
+| DELETE `/companies/{id}` | F-8 | DELETE `/api/companies/{id}` |
+| POST `/contacts` | F-10 | POST `/api/contacts` |
+| GET `/api/health` | F-15 | GET `/api/health` |
+
+### v0.1 Demo-Seed
+- Beim ersten Start: 1 Admin (`admin`/`admin`), 2 Firmen, 3 Kontakte
+- Frische DB → Seed-Daten vorhanden
+- DB bereits befüllt → Seed überspringt
+
+---
+
+## 18. Non-Goals (alle Module, vollständig)
+
+### v1 Non-Goals
+1. Self-Registration (nur Admin legt User an)
+2. ~~Multi-Tenant (Single-Tenant in v1)~~ — Multi-Tenant (Multi-Company) ist v1-Feature
+3. Sales Pipeline / Deals
+4. Kampagnen-Management
+5. Mobile App (Native) — nur Responsive Web-UI
+6. Offline-Support
+7. AI-Features (Lead-Scoring, Auto-Enrichment)
+8. Real-time Collaboration (Google Docs-style)
+9. Webhooks für externe Systeme
+10. Multi-Currency
+11. Advanced Analytics/Dashboards (BI)
+12. SSO/OAuth (nur E-Mail/Passwort)
+13. Custom Fields (Standard-Felder fest definiert)
+14. Two-Factor Auth (post-MVP)
+15. PWA
+
+### v2 DMS Non-Goals
+1. Versionierung (History, Diff)
+2. Volltext-Suche in Dokumenten (kein OCR, kein Volltext-Index)
+3. Eigene Office-Suite (nur OnlyOffice)
+4. E-Mail-Attachment aus DMS
+5. Externes Sync (WebDAV/Nextcloud)
+6. Watermarking
+
+### v2 Kalender Non-Goals
+1. Ressourcen-Booking (nur optional markiert)
+2. Time-Tracking
+3. Task-Templates
+4. Automatisierte Task-Erstellung aus Triggern
+5. Gantt-Diagramm
+6. Öffentliche Kalender-Sync (außer ICS)
+
+### v2 Mail Non-Goals
+1. Google/Microsoft API (nur direkte IMAP/SMTP)
+2. S/MIME (nur PGP in v2-mail)
+3. Mail-Server-Hosting (nur Client)
+4. Mailinglisten-Management
+5. Newsletter-Tool
+6. Mail-to-Ticket
+7. OCR für Anhänge
+8. Kalender-Einladungen per Mail (iMIP, RFC 6047)
+9. JMAP (RFC 8620)
+10. Push-Benachrichtigungen (Web Push) — nur In-App
+
+---
+
+**Ende der extrahierten Architektur-Details.**
diff --git a/quality-gate-phase1.md b/quality-gate-phase1.md
new file mode 100644
index 0000000..f874bf8
--- /dev/null
+++ b/quality-gate-phase1.md
@@ -0,0 +1,172 @@
+# Quality Gate Review — Phase 1 → Phase 2 (Re-Review)
+
+**Datum:** 2026-06-28
+**Dateien:** requirements.md (2142 Zeilen), extracted-architecture-details.md (1006 Zeilen)
+**Vorherige Findings:** 6 Fixes angewendet
+
+---
+
+## Prüfkriterien & Ergebnisse
+
+### 1. Vollständigkeit: 143 Features (73 Core + 70 Plugin)
+**Status: ✅ PASS**
+
+Verifikation:
+- Active feature headings (exkl. historisch): 143
+- `[v1]`-Features (Core): 73
+- `[v2-Plugin]`-Features (Plugin): 70
+- `[v1-Plugin]`-Features: 0 (alle konvertiert)
+- Summary-Tabelle: 73 Core + 70 Plugin = 143
+- DISCOVERY_CHECK_FINAL: `features_with_ids=143/143`
+
+### 2. Konsistenz: Plugin vs Core Trennung
+**Status: ✅ PASS**
+
+Verifikation:
+- F-FILE-01–04: alle `[v2-Plugin]` (vorher `[v1-Plugin]`)
+- F-DMS-01–07: alle `[v2-Plugin]`
+- F-LINK-01–06: alle `[v2-Plugin]`
+- F-TAG-01–04: alle `[v2-Plugin]`
+- F-PERM-01–06: alle `[v2-Plugin]`
+- F-FILEUI-01–06: alle `[v2-Plugin]`
+- F-CAL-01–18: alle `[v2-Plugin]` (F-CAL-10 = `[v2-Plugin — später]`)
+- F-MAIL-01–19: alle `[v2-Plugin]`
+- F-PLUGIN-01/02: `[v1]` (Plugin-System ist Core)
+- F-CORE-04 (UI-Plugin-Framework): `[v1]` (Core-Infrastruktur)
+- Summary-Header: `### Core-Features (v1)` und `### Plugin-Features (v2-Plugin)`
+
+### 3. Keine Implementierungs-Details in requirements.md
+**Status: ✅ PASS**
+
+Verifikation:
+- Keine HTML-Tags (``, ``, `