# LeoCRM — Codebase vs Requirements Analysis

**Datum:** 2026-06-28
**Prüfer:** Codebase Explorer (Agent Zero)
**Methode:** Read-only-Inspektion der bestehenden Codebase gegen bereinigte `requirements.md`

---

## 1. Bestehende Architektur-Übersicht

### Stack

| Komponente | Code-Realität | Requirements | Status |
|------------|-------------|-------------|--------|
| Backend | FastAPI 0.115.6 | FastAPI | ✅ kompatibel |
| Python | 3.11+ (pyproject.toml) | 3.12 (Annahme 10) | ⚠️ Minor-Abweichung |
| Datenbank | **SQLite** (WAL mode) | **PostgreSQL 16** | ❌ KONFLIKT |
| ORM | SQLAlchemy 2.0.36 | (offen — architecture.md) | ✅ kompatibel |
| Frontend | **Jinja2 Templates** (server-side) | **React SPA** (client-side) | ❌ KONFLIKT |
| Auth | Starlette SessionMiddleware (Cookie) | Session-basiert (Cookie) | ✅ kompatibel |
| Deployment | Docker (single container) | Coolify (Docker) | ⚠️ Single-Container vs Multi-Container |
| Testing | pytest (backend only) | pytest + Vitest + Playwright | ⚠️ Backend-only |

### Projekt-Struktur

```
app/
├── main.py              — FastAPI app, lifespan, middleware, router wiring
├── config.py            — Pydantic Settings (env: LEOCRM_*)
├── deps.py              — Auth dependencies (get_current_user, require_admin)
├── db/
│   ├── models.py        — 862 Zeilen, 15 SQLAlchemy-Modelle (alle Core, keine Plugins)
│   ├── session.py       — SQLite-Engine, SessionLocal, get_db dependency
│   └── init_db.py       — Table creation + demo seed (admin/admin)
├── routes/
│   ├── api_routes.py    — JSON auth endpoints (/api/auth/login, /api/auth/logout)
│   ├── html_routes.py   — HTML auth endpoints (/login, /logout — Jinja2)
│   ├── company_routes.py— JSON API /api/companies (CRUD, search, export)
│   ├── contact_routes.py— JSON API /api/contacts (CRUD, search)
│   ├── dms_routes.py    — JSON API /api/dms/* (folders, files, search, links, bulk)
│   ├── tag_routes.py    — JSON API /api/tags (CRUD, assign, bulk-assign)
│   ├── calendar_routes.py— JSON API /api/calendars, /api/entries (CRUD, shares, subtasks, attendees, links)
│   ├── notification_routes.py — JSON API /api/notifications
│   ├── import_routes.py — JSON API /api/companies/import, /api/contacts/import (CSV)
│   ├── public_routes.py — Public share links /api/public/share/{token}
│   └── health_routes.py — /api/health
├── services/
│   ├── auth_service.py       — bcrypt password hashing, authenticate_user
│   ├── company_service.py   — Company CRUD logic
│   ├── contact_service.py   — Contact CRUD logic
│   ├── dms_service.py       — DMS file/folder operations (26KB, größte Service-Datei)
│   ├── tag_service.py       — Tag CRUD + assignment
│   ├── calendar_service.py  — Calendar/entry/subtask/attendee/notification logic (21KB)
│   ├── permission_service.py— DMS permissions + share links
│   ├── import_service.py    — CSV import for companies/contacts
│   └── export_service.py    — CSV/XLSX export for companies
├── schemas/               — Pydantic schemas (auth, company, contact, dms, tag, calendar, common)
└── templates/             — Jinja2 HTML templates (login, register, dashboard, company_form, contact_form, contact_list, base)
```

### Patterns

- **Monolith:** Single FastAPI app, alle Module fest eingebaut
- **Dual-Interface:** HTML routes (Jinja2) + JSON API routes parallel
- **Service-Layer:** Business-Logik in `services/`, Routes sind dünn
- **SQLAlchemy 2.0:** DeclarativeBase, Mapped types, mapped_column
- **Soft-Delete:** `deleted_at` auf Company, Contact, Folder, File
- **N:M Junctions:** CompanyContact, TagAssignment, FileEntityLink, EntryLink, CalendarShare
- **RBAC:** 3 Rollen (admin, editor, viewer) — hardcoded in `require_admin` dependency
- **Demo-Seed:** init_db() erstellt admin/admin + 2 Firmen + 3 Kontakte

---

## 2. Konflikte: Requirements vs Code-Realität

### K1: Multi-Tenant (F-AUTH-07, F-CORE-02) — KRITISCH

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| tenant_id | Auf allen Core-Tabellen | **Nirgendwo vorhanden** |
| Tenant-Isolation | ORM filtert automatisch | **Keine Filterung** |
| User-Tenant-Zuordnung | User kann zu mehreren Tenants gehören | **Nicht implementiert** |
| Tenant-Switch UI | Wechsel aktiver Tenant | **Nicht vorhanden** |
| Plugin-Tabellen | Müssen tenant_id haben | **N/A (keine Plugins)** |

**Evidence:**
- `models.py` Zeile 42: `class User(Base):` docstring sagt explizit `"Login account for LeoCRM (single-tenant)."`
- Keine `tenant_id`-Spalte auf Company, Contact, Folder, File, Tag, Calendar, CalendarEntry, Notification, Permission, ShareLink
- `deps.py`: Session speichert nur `user_id`, kein `tenant_id`-Kontext
- Keine Tenant-Modell-Klasse existiert

**Impact:** Fundamentale Architektur-Veränderung erforderlich. Jede Tabelle braucht tenant_id, ORM-Queries müssen tenant-gefiltert sein, User-Tenant-Mapping-Tabelle nötig.

---

### K2: Plugin-System (F-PLUGIN-01, F-PLUGIN-02) — KRITISCH

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Plugin-Architektur | Core-Feature v1 | **Nicht existent** |
| DMS/Kalender/Tags/Mail | Als Plugins implementiert | **Fest im Core eingebaut** |
| Plugin-Manifest | Definiertes Format | **Nicht vorhanden** |
| Lifecycle-Hooks | install/activate/deactivate/uninstall | **Nicht vorhanden** |
| Plugin-API-Endpunkte | Plugins registrieren eigene Routes | **Nicht vorhanden** |
| Plugin-DB-Migration | Eigene Migrationen | **Nicht vorhanden** |
| Plugin-Abhängigkeiten | Deklarierbar | **Nicht vorhanden** |

**Evidence:**
- `grep -rn 'plugin\|Plugin\|manifest\|lifecycle\|activate\|deactivate' app/` → **0 Treffer**
- DMS: `models.py` Folder/File/FileEntityLink + `dms_service.py` (26KB) + `dms_routes.py` — alles fest im Core
- Kalender: `models.py` Calendar/CalendarShare/CalendarEntry/Attendee/EntryLink/SubTask + `calendar_service.py` (21KB) + `calendar_routes.py` — fest im Core
- Tags: `models.py` Tag/TagAssignment + `tag_service.py` + `tag_routes.py` — fest im Core
- Keine Plugin-Registry, kein Plugin-Loader, kein Manifest-Format

**Impact:** Komplette Plugin-Architektur muss neu gebaut werden. Bestehende DMS/Kalender/Tag-Module müssen in Plugins umgewandelt werden.

---

### K3: Datenbank — SQLite vs PostgreSQL — KRITISCH

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| DB-Engine | PostgreSQL 16 | **SQLite** |
| Connection-Pooling | PostgreSQL MVCC | **SQLite WAL, check_same_thread=False** |
| Concurrent Writes | Multi-User fähig | **SQLite limitiert** |

**Evidence:**
- `config.py`: `db_path: str = Field(default=str(Path("/data/leocrm.db")))` → SQLite-Datei
- `config.py`: `database_url` property → `f"sqlite:///{self.db_path}"` 
- `session.py`: SQLite-spezifische PRAGMAs (`PRAGMA foreign_keys = ON`, `PRAGMA journal_mode = WAL`)
- `session.py`: `connect_args={"check_same_thread": False}` — SQLite-only
- `pyproject.toml`: Keine `psycopg2`/`asyncpg`/`psycopg`-Dependency

**Impact:** DB-Layer muss auf PostgreSQL umgestellt werden. Session-Engine, PRAGMAs, connect_args müssen angepasst werden.

---

### K4: Frontend — Jinja2 vs React SPA — KRITISCH

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Frontend | React SPA (client-side) | **Jinja2 Templates (server-side)** |
| i18n | DE + EN, Sprachwahl persistiert | **Nicht implementiert** |
| UI-Plugin-Framework | Plugins registrieren UI-Komponenten | **Nicht vorhanden** |

**Evidence:**
- `app/templates/`: 7 Jinja2-HTML-Templates (login, register, dashboard, company_form, contact_form, contact_list, base)
- `html_routes.py`: Jinja2Templates, TemplateResponse
- Keine `package.json`, keine `.tsx`/`.jsx`-Dateien, kein React/Vite-Setup
- `pyproject.toml`: `jinja2==3.1.5` als Dependency
- Requirements Annahme 3: "SPA-Frontend: Client-side rendering mit React SPA (bestätigt durch genehmigten Prototyp leocrm-prototype-x7k2p9)"

**Impact:** Komplettes Frontend muss als React SPA neu gebaut werden. Jinja2-Templates und HTML-Routes werden obsolet. UI-Plugin-Framework (F-CORE-04) muss in React integriert werden.

---

### K5: F-CORE-01 — Event Bus — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Event Bus | Core-Feature v1 | **Nicht implementiert** |
| Events emit/subscribe | Typisiert, Payload, asynchron | **Nicht vorhanden** |
| Plugin-Listener | Registrieren beim Aktivieren | **N/A** |

**Evidence:** `grep -rn 'event.bus\|EventBus\|event_bus\|emit\|subscribe\|listener' app/` → **0 Treffer**

---

### K6: F-CORE-05 — Service Container / DI — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Service Container | Core-Services über Container | **Nicht implementiert** |
| DI für Plugins | Services injiziert | **N/A** |
| Mocking für Tests | Mock-Services injizierbar | **Nur DB-Session override** |

**Evidence:** Services werden direkt importiert (`from app.services import company_service`), nicht über Container. FastAPI `Depends()` ist das einzige DI-Muster, aber nur für Request-Scoped dependencies (DB-Session, Current-User).

---

### K7: F-CORE-06 — API-First Architecture — TEILWEISE

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Alle Features über API | API-First | **Teilweise** — API routes existieren für alle Module |
| UI ist API-Client | UI nutzt API | **❌ Jinja2 rendert server-side** |
| API versioniert | z.B. /api/v1/ | **❌ Keine Versionierung** |
| OpenAPI/Swagger | Auto-gen, dokumentiert | **⚠️ FastAPI auto-gen existiert, aber nicht explizit konfiguriert** |
| Plugin-API-Endpunkte | Registrierbar | **N/A** |
| KI-Copilot nutzt API | Gleiche Endpunkte | **Nicht implementiert** |

**Evidence:**
- API routes: `/api/companies`, `/api/contacts`, `/api/dms/*`, `/api/tags/*`, `/api/calendars`, `/api/entries`, `/api/notifications`, `/api/auth/*`
- Kein `/api/v1/` Prefix — alle routes sind unversioniert
- FastAPI generiert automatisch OpenAPI unter `/openapi.json`, aber nicht explizit konfiguriert oder dokumentiert
- HTML routes existieren parallel (`/login`, `/` dashboard) — UI ist NICHT API-Client

---

### K8: F-CORE-07 — Async Job Queue — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Queue-System | Background-Jobs asynchron | **Nicht implementiert** |
| Retry-Logic | Automatische Retries | **Nicht vorhanden** |
| Dead-Letter-Queue | Bei wiederholtem Fehlschlag | **Nicht vorhanden** |
| Job-Status UI | Sichtbar im UI | **Nicht vorhanden** |

**Evidence:** `grep -rn 'celery\|Celery\|queue\|Queue\|async_job\|background_job\|job_queue' app/` → **0 Treffer**

---

### K9: F-CORE-08 — Caching-Strategie — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Cache-Backend | Sessions, Query-Cache, Plugin-Data | **Nicht implementiert** |
| Cache-Invalidierung | Event-basiert | **N/A** |
| TTL-Caching | Fallback | **Nur `@lru_cache` für Settings** |

**Evidence:** `grep -rn 'cache\|Cache\|redis\|Redis' app/` → nur `functools.lru_cache` in `config.py` für Settings-Caching. Kein Redis, kein Query-Cache.

---

### K10: F-CORE-09 — User-Profile und Preferences — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| User-Profile | Profil mit Preferences | **Nicht implementiert** |
| Sprache/Zeitzone/Theme | Umschaltbar | **Nicht vorhanden** |
| Dashboard-Konfiguration | Konfigurierbar | **Nicht vorhanden** |
| Plugin-Preferences | Eigene Felder registrierbar | **N/A** |

**Evidence:** `User`-Modell hat nur: id, username, password_hash, role, personal_folder_id, default_calendar_id, created_at. Keine Preferences, keine Sprache, keine Zeitzone.

---

### K11: F-CORE-10 — Storage-Backend — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| S3-kompatibel | Konfigurierbar | **Nicht implementiert** |
| Lokales Volume | Alternative | **Lokales Dateisystem** |
| Presigned-URLs | Download ohne Plugin-Code | **Nicht vorhanden** |
| Storage-Service | Core-Service für Plugins | **Direkter Dateizugriff** |

**Evidence:**
- `config.py`: `dms_storage_path: str = Field(default="/data/dms")` — lokales Verzeichnis
- `dms_service.py`: Direkter Dateizugriff via `open()`, `Path`-Operationen
- Keine S3/MinIO/boto3-Integration
- `grep -rn 's3\|S3\|boto3\|storage_backend\|presigned' app/` → **0 Treffer**

---

### K12: F-CORE-11 — Generic Import/Export Service — TEILWEISE

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| CSV-Import | Mit Preview, Dry-Run, Fehler-Reporting | **⚠️ Nur direkter Import ohne Preview/Dry-Run** |
| Excel-Export | Feld-Auswahl, Filterung | **⚠️ CSV + XLSX Export, aber begrenzte Feld-Auswahl** |
| Plugin-Definitionen | Registrierbar | **N/A** |

**Evidence:**
- `import_service.py`: `import_companies_csv()`, `import_contacts_csv()` — direkter Import, kein Preview, kein Dry-Run
- `export_service.py`: `export_companies_csv()`, `export_companies_xlsx()` — Export funktioniert, aber nicht generisch/plugin-fähig
- Import/Export ist hardcoded für Companies/Contacts, nicht generisch

---

### K13: F-CORE-12 — PDF/Document Generation Service — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| PDF-Generierung | Aus Templates | **Nicht implementiert** |
| Template-Engine | Variablen, Conditionals, Tabellen | **Nicht vorhanden** |
| Storage-Integration | PDFs im Storage gespeichert | **N/A** |

**Evidence:** `grep -rn 'pdf\|PDF\|weasyprint\|reportlab\|pdfkit' app/` → nur DMS-Preview (stream existing PDFs), keine Generierung

---

### K14: F-CORE-13 — Notification Service — TEILWEISE

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| In-App-Notifications | Bell-Icon, Badge-Zähler | **⚠️ DB-Modell existiert, keine UI** |
| E-Mail-Channel | Notifications per Mail | **Nicht implementiert** |
| Preferences | Pro User konfigurierbar | **Nicht vorhanden** |
| Tenant-Isolation | Pro Tenant isoliert | **N/A (single-tenant)** |
| Plugin-Notification-Typen | Registrierbar | **N/A** |

**Evidence:**
- `models.py`: `Notification`-Modell existiert (id, user_id, type, title, body, related_entry_id, is_read, created_at)
- `notification_routes.py`: API für List/Mark-Read existiert
- Keine E-Mail-Integration, keine Preferences, kein Badge-Zähler in UI (Jinja2-Templates haben kein Notification-UI)

---

### K15: F-AUTH-01 — Login mit E-Mail — KONFLIKT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Login-Feld | **E-Mail** + Passwort | **Username** + Passwort |
| Session-Cookie | HttpOnly, Secure, SameSite=Strict | SameSite=**lax**, https_only conditional |

**Evidence:**
- `auth_service.py`: `authenticate_user(db, username, password)` — verwendet `username`, nicht `email`
- `models.py`: `User.username: Mapped[str]` — kein `email`-Feld auf User
- `deps.py`: Session speichert `user_id`, kein Tenant-Kontext
- `main.py`: `same_site="lax"` (requirements sagen Strict), `https_only=settings.is_production` (requirements sagen Secure)

---

### K16: F-AUTH-03 — User-Verwaltung durch Admin — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Admin legt User an | E-Mail, Name, Rolle, Passwort | **Nicht implementiert** |
| User-Tenant-Zuordnung | User wird Tenant zugeordnet | **N/A** |
| Keine Self-Registration | Admin-only | **⚠️ Register-Template existiert** |

**Evidence:**
- Keine User-Management-Routes (kein `/api/users`, kein Admin-User-CRUD)
- `app/templates/register.html` existiert — Self-Registration-Template (widerspricht Non-Goal #1)
- `init_db.py`: Demo-Seed erstellt nur admin/admin

---

### K17: F-AUTH-05 — Passwort-Reset — FEHLT

| Aspekt | Requirements | Code-Realität |
|---------|-------------|---------------|
| Reset-Flow | E-Mail mit Reset-Link | **Nicht implementiert** |
| Reset-Link | Gültig 24h | **Nicht vorhanden** |

**Evidence:** Keine Reset-Routes, keine Reset-Templates, keine Token-Generierung.

---

### K18: F-AUTH-07 — Multi-Tenant — FEHLT (siehe K1)

Bereits in K1 abgedeckt. Keine Tenant-Modelle, keine User-Tenant-Mapping-Tabelle.

---

### K19: DMS/Calendar/Tags als Core vs Plugin — ARCHITEKTUR-KONFLIKT

| Modul | Requirements | Code-Realität |
|-------|-------------|---------------|
| DMS | v2-Plugin (F-FILE/F-DMS/F-LINK/F-PERM) | **Core: 3 Modelle + 26KB Service + eigene Routes** |
| Kalender | v2-Plugin (F-CAL-01..18) | **Core: 6 Modelle + 21KB Service + eigene Routes** |
| Tags | v2-Plugin (F-TAG-01..04) | **Core: 2 Modelle + 8KB Service + eigene Routes** |
| Mail | v2-Plugin (F-MAIL-01..19) | **Nicht implementiert** |

**Evidence:** Alle Module sind direkt in `models.py`, `services/`, `routes/` integriert. Keine Plugin-Grenzen, keine Plugin-Schnittstellen.

**Hinweis:** Requirements sagen Plugin-System ist v1-Core-Feature, aber die Module selbst sind v2-Plugins. Das bedeutet: In v1 muss das Plugin-System gebaut werden, aber DMS/Kalender/Tags können als v2-Plugins nachgezogen werden. Die bestehenden Implementierungen können als Referenz dienen, müssen aber auf Plugin-Architektur umgebaut werden.

---

## 3. Kompatibel — Was bereits passt

### ✅ Session-basierte Auth (F-AUTH-01/02, Annahme 12)
- Starlette `SessionMiddleware` mit signed Cookie
- `session_cookie="leocrm_session"`, `max_age` konfigurierbar
- Login setzt `request.session[SESSION_USER_ID_KEY] = user.id`
- Logout cleared session
- **Kompatibel** mit Requirements (Session-basiert, Cookie-basiert)

### ✅ RBAC Grundgerüst (F-AUTH-04/06)
- 3 Rollen: admin, editor, viewer
- `require_admin` dependency prüft `user.role == "admin"`
- `get_current_user` dependency für auth-geschützte Routes
- **Kompatibel** mit Requirements (3 Rollen v1)

### ✅ Company/Contact CRUD (F-COMP-01..06, F-CONT-01..07)
- Company: 27 Felder (Name, Adresse, Industrie, Revenue, etc.)
- Contact: 29 Felder (Name, Email, Phone, Title, etc.)
- N:M Junction: `CompanyContact`
- Soft-Delete: `deleted_at` auf beiden
- Pagination, Search, Filter, Sort in Routes
- **Kompatibel** mit Requirements

### ✅ Data-Features (F-DATA-01..04)
- Pagination: `PageResponse` schema
- Search: Query-Parameter in company/contact routes
- Sort: Sortier-Parameter
- Soft-Delete: `deleted_at` + restore functionality
- **Kompatibel** mit Requirements

### ✅ Health-Check (F-INFRA-01)
- `/api/health` endpoint, prüft DB, gibt Status + Version
- Nicht auth-geschützt (für Coolify/LB)
- **Kompatibel** mit Requirements

### ✅ Import/Export Grundgerüst (F-MIG-01, F-DATA-01/02)
- CSV-Import für Companies/Contacts
- CSV + XLSX Export für Companies
- **Teilweise kompatibel** — fehlt Preview, Dry-Run, generische Service-Architektur

### ✅ DMS-Features (als Referenz für späteres Plugin)
- Folder-Tree mit materialized path
- File-Upload, Preview (PDF), Soft-Delete, Restore
- Entity-Links (N:M zu Companies/Contacts)
- Permissions (Individual/Group/Default)
- Share-Links mit Password + Expiry
- OnlyOffice-Edit-Session
- **Vollständig implementiert** — kann als Plugin-Referenz dienen

### ✅ Calendar-Features (als Referenz für späteres Plugin)
- Calendar CRUD, Sharing, Visibility-Toggle
- Entries: Events/Tasks/Reminders, Kanban-Status
- Subtasks, Attendees, Entry-Links
- Notifications für Reminders/Invites/Shares
- **Vollständig implementiert** — kann als Plugin-Referenz dienen

### ✅ Tag-System (als Referenz für späteres Plugin)
- Tag CRUD (admin-only), Color, Assignment
- Bulk-Assign, Entity-Type polymorphic
- **Vollständig implementiert** — kann als Plugin-Referenz dienen

### ✅ Testing-Setup (F-TEST-01)
- pytest mit 20+ Test-Dateien
- conftest.py mit Fixtures
- Coverage-Messung konfiguriert
- **Teilweise kompatibel** — fehlt Vitest (Frontend) und Playwright (E2E)

---

## 4. F-CORE-Feature-Matrix

| F-CORE-ID | Feature | Status im Code | Anmerkung |
|-----------|--------|---------------|----------|
| F-CORE-01 | Event Bus | ❌ Nicht implementiert | Keine Event-Infrastruktur |
| F-CORE-02 | Tenant-Isolation | ❌ Nicht implementiert | Kein tenant_id, single-tenant |
| F-CORE-03 | Plugin-DB-Migration | ❌ Nicht implementiert | Kein Plugin-System |
| F-CORE-04 | UI-Plugin-Framework | ❌ Nicht implementiert | Jinja2, keine Plugin-UI |
| F-CORE-05 | Service Container / DI | ❌ Nicht implementiert | Direkte Imports, nur FastAPI Depends |
| F-CORE-06 | API-First Architecture | ⚠️ Teilweise | API routes existieren, aber HTML parallel, keine Versionierung |
| F-CORE-07 | Async Job Queue | ❌ Nicht implementiert | Keine Queue-Infrastruktur |
| F-CORE-08 | Caching-Strategie | ❌ Nicht implementiert | Nur lru_cache für Settings |
| F-CORE-09 | User-Profile/Preferences | ❌ Nicht implementiert | User hat nur username/role |
| F-CORE-10 | Storage-Backend | ❌ Nicht implementiert | Lokales Dateisystem, kein S3 |
| F-CORE-11 | Generic Import/Export | ⚠️ Teilweise | CSV/XLSX funktioniert, nicht generisch, kein Preview/Dry-Run |
| F-CORE-12 | PDF Generation | ❌ Nicht implementiert | Keine PDF-Generierung |
| F-CORE-13 | Notification Service | ⚠️ Teilweise | DB-Modell + API existiert, keine UI, kein E-Mail-Channel |

**Bilanz:** 0/13 vollständig implementiert, 3/13 teilweise, 10/13 fehlen komplett.

---

## 5. Empfehlung: Was vor Phase 2 angepasst werden muss

### Priorität 1 — Fundamentale Architektur (vor allem anderen)

1. **Datenbank-Migration: SQLite → PostgreSQL**
   - `config.py`: `database_url` auf PostgreSQL umstellen
   - `session.py`: SQLite-PRAGMAs entfernen, PostgreSQL-Engine konfigurieren
   - `pyproject.toml`: `psycopg[binary]` oder `asyncpg` hinzufügen
   - `docker-compose.yml`: PostgreSQL-Service hinzufügen

2. **Multi-Tenant-Architektur**
   - Neues `Tenant`-Modell + `UserTenant`-Mapping-Tabelle
   - `tenant_id`-Spalte auf ALLE Core-Tabellen (Company, Contact, Folder, File, Tag, Calendar, etc.)
   - ORM-Query-Filter: automatische tenant_id-Filterung (SQLAlchemy Event oder Query-Wrapper)
   - Session-Kontext: aktiver tenant_id in Session speichern
   - Tenant-Switch-Endpoint + UI

3. **Frontend-Wechsel: Jinja2 → React SPA**
   - React-Projekt-Setup (Vite + React + TypeScript)
   - API-Client-Layer (fetch/axios gegen /api/* Endpunkte)
   - Jinja2-Templates und html_routes.py werden obsolet
   - i18n-Integration (DE + EN)
   - UI-Plugin-Framework vorbereiten (F-CORE-04)

### Priorität 2 — Core-Infrastructure (F-CORE)

4. **Service Container / DI (F-CORE-05)**
   - Zentralen Service-Container implementieren
   - Core-Services registrieren: DB, Cache, Event Bus, Auth, Config, Logger
   - Plugin-Schnittstelle für Service-Requests definieren

5. **Event Bus (F-CORE-01)**
   - Event-Publish/Subscribe-System implementieren
   - Typisierte Events mit Payload
   - Asynchrone Verarbeitung (ggf. via Job Queue)

6. **Plugin-System (F-PLUGIN-01/02)**
   - Plugin-Manifest-Format definieren
   - Lifecycle-Hooks: install, activate, deactivate, uninstall
   - Plugin-Registry + Loader
   - Plugin-API-Endpunkt-Registrierung
   - Plugin-DB-Migration (F-CORE-03)
   - Plugin-Abhängigkeiten

7. **API-Versionierung (F-CORE-06)**
   - `/api/v1/` Prefix für alle API-Routes
   - OpenAPI/Swagger explizit konfigurieren und dokumentieren
   - HTML-Routes entfernen (UI wird React SPA = API-Client)

### Priorität 3 — Weitere Core-Infrastructure

8. **Async Job Queue (F-CORE-07)** — Queue-System für Background-Jobs
9. **Caching (F-CORE-08)** — Redis-Anbindung, Query-Cache, Cache-Invalidierung
10. **Storage-Backend (F-CORE-10)** — S3-kompatibler Storage-Service
11. **User-Profile/Preferences (F-CORE-09)** — Profil-Erweiterung, Preferences
12. **Notification Service (F-CORE-13)** — E-Mail-Channel, Preferences, Badge-UI
13. **PDF Generation (F-CORE-12)** — Template-Engine, PDF-Generierung
14. **Generic Import/Export (F-CORE-11)** — Generischer Service, Preview, Dry-Run

### Priorität 4 — Auth-Ergänzungen

15. **Login auf E-Mail umstellen (F-AUTH-01)** — username → email
16. **User-Verwaltung durch Admin (F-AUTH-03)** — Admin-CRUD für User, Tenant-Zuordnung
17. **Passwort-Reset (F-AUTH-05)** — Reset-Flow mit E-Mail
18. **Register-Template entfernen** — Self-Registration ist Non-Goal
19. **Cookie-Security anpassen** — SameSite=Strict, Secure immer

### Was beibehalten werden kann

- **Backend-Services** (company_service, contact_service, etc.) — Business-Logik ist solide
- **Pydantic-Schemas** — Können für API-Validierung weiterverwendet werden
- **DB-Modelle** — Felder/Beziehungen sind korrekt, müssen nur tenant_id ergänzt werden
- **Test-Suite** — pytest-Tests können erweitert werden
- **DMS/Calendar/Tag-Implementierungen** — Als Referenz für spätere Plugin-Entwicklung behalten

---

## 6. Zusammenfassung

| Kategorie | Anzahl | Status |
|-----------|--------|--------|
| Kritische Konflikte | 4 | Multi-Tenant, Plugin-System, DB, Frontend |
| F-CORE fehlend | 10/13 | Event Bus, Tenant-Isolation, Plugin-Migration, UI-Plugin, Service Container, Job Queue, Caching, User-Profile, Storage, PDF |
| F-CORE teilweise | 3/13 | API-First, Import/Export, Notification |
| F-CORE vollständig | 0/13 | — |
| Auth-Konflikte | 4 | Login (username vs email), User-Verwaltung, Passwort-Reset, Cookie-Security |
| Kompatibel | 7+ | Session-Auth, RBAC, Company/Contact CRUD, Data-Features, Health, DMS/Calendar/Tags (als Referenz) |

**Fazit:** Die bestehende Codebase ist eine funktionsfähige v0.1-Implementierung (Single-Tenant, SQLite, Jinja2), die den bereinigten v1-Requirements in 4 kritischen Bereichen nicht entspricht: Multi-Tenant, Plugin-System, PostgreSQL, React SPA. 10 von 13 F-CORE-Features fehlen komplett. Die bestehende Business-Logik (Services, Schemas, Modelle) ist jedoch solide und kann als Basis für den Umbau dienen. Der Aufwand für Phase 2 ist erheblich — es handelt sich um eine Architektur-Migration, nicht um inkrementelle Erweiterungen.