crm-system/docs/worklog.md

## 2026-06-03T18:06:03 - CRM Build gestartet

- Plan Mode beendet, Implementation Mode aktiv
- User-Freigabe: CRM bauen, alle Sub-Agents testen
- Library konsultiert: Suche nach CRM-Patterns
- Nächste Schritte: requirements_analyst -> 01-requirements.md

## 2026-06-03T18:09:10 - Library-Consultation abgeschlossen

- 7 FTS5-Queries (Backend, CRM, Migration, Auth, Frontend, Deploy, Contact)
- 0 Patterns insgesamt gefunden
- Detaillierte Findings: /a0/.a0/library_findings.json
- Nächster Schritt: search_engine (MANDATORY per Solution Memory)

## 2026-06-03T18:10:13 - Library-Inventar verarbeitet
- 29 Patterns total in DB (architecture_decision, best_practice, error_solution)
- 15 unique patterns extracted via FTS5 (fastapi, sqlalchemy, crm, customer, alembic, docker, jwt, alpine, react, pipeline)
- Detaillierte Findings: /a0/.a0/library_findings.json
- Nächster Schritt: search_engine für 2026 Best Practices (MANDATORY)

## 2026-06-03T18:51 - Phase 1 (Requirements) abgeschlossen
- requirements_analyst Sub-Agent geliefert
- /a0/.a0/01-requirements.md (392 Zeilen, 11 Sek., 8 FRs, 53 Endpoints, 40 Akzeptanzkrit., 10 Entities, 24 Story-Mappings)
- 3 offene Fragen geklärt: Single-Tenant, JWT-localStorage, Coolify localhost (uuid lw80w8scs4044gwcw084s00s4, healthy + usable)
- 4 Risiken dokumentiert (R-1 Multi-Tenant-Migration, R-2 Polymorphic-FKs, R-5 JWT-XSS, OP-2 SMTP, OP-5 DSGVO)
- User-Approval für Phase 2

## 2026-06-03T20:14 - Phase 2 (Architecture) abgeschlossen
- solution_architect Sub-Agent geliefert
- /a0/.a0/02-architecture.md (585 Zeilen, 12 Sek., 6 ADRs, 4 Architektur-Risiken)
- /a0/.a0/03-task-graph.json (442 Zeilen, 10 Phasen, 50 Deliverables, 5 Approval-Gates, 990 min total)
- Stack: FastAPI async + SQLAlchemy 2.0 + Alembic + Pydantic v2 + Alpine.js + Tailwind CDN + Docker + Coolify
- Pattern-Referenz: wochenplaner-Repo (FastAPI+SQLite+bcrypt, deployed via Coolify, project-uuid urmddibnyooglc8ei314tseu, service-uuid v100oc23yok921ue26q8epei, domain reinigung.media-on.de)
- 1 Blocker: Coolify-Domain für CRM (A-1) - jetzt klären empfohlen
- 4 ADRs kritisch: ADR-1 async, ADR-2 Service-Layer, ADR-3 JWT+localStorage+CSP, ADR-5 Single-Tenant+org_id, ADR-6 Dual-DB
- User-Approval für Phase 3

## 2026-06-03T22:16 - Phase 3 (Codebase Exploration) START
- codebase_explorer Sub-Agent startet
- Auftrag: wochenplaner-Repo (Forgejo, leopoldadmin) + rentman-clone-Repo analysieren
- Deliverable: /a0/.a0/03a-patterns-summary.md mit wiederverwendbaren Patterns für CRM-Implementation
- Hinweis: rentman-clone nutzt React 19 + FastAPI 0.115+, NICHT Alpine.js → nur bedingt relevant

## 2026-06-03T22:29 - Phase 3 (Codebase Exploration) DONE
- codebase_explorer Sub-Agent liefert /a0/.a0/03a-patterns-summary.md (616 Zeilen, 27.6 KB)
- 5 Sektionen (A, B, C, D, E) vollständig: 12 Patterns in A, 17 CRM-Task-Mappings in C, 10 Risiken/Lessons in D, Empfehlung in E
- Wochenplaner-Repo via forgejo-API gelesen (Branch master, 6 Dateien analysiert)
- Rentman-clone NICHT gefunden (2 Such-Queries leer)
- **WICHTIGE KORREKTUR zu 02-architecture.md Section 7:**
  - Domain: 'https://crm.media-on.de:443' (Port im URL PFLICHT für Coolify-Let's-Encrypt-SSL, korrigiert nach User-Auftrag 'port in Domain Feld nicht vergessen')
  - Interner App-Port: 8000 (FastAPI, nicht extern sichtbar)
  - Coolify-Traefik-Proxy macht SSL-Termination auf 443, Proxy-Pass zu App:8000
- Architektur-Korrektur: wochenplaner ist MULTI-CONTAINER (backend+frontend+nginx), NICHT Single-Container
  - 02-architecture.md wird in Phase 4a angepasst (kleinere Korrektur im Deployment-Section)
- JWT-Lib: python-jose[cryptography]==3.3.0 (NICHT PyJWT) im wochenplaner
- Sync vs Async: wochenplaner ist sync SQLAlchemy, CRM-Migration auf async erfordert Neuschreiben
- Fehlend in wochenplaner: Alembic, pytest, Service-Layer, async-Support
- Security-Issues in wochenplaner-Pattern dokumentiert (Default-User, CORS-Wildcard, JWT-Fallback) → CRM MUSS diese vermeiden
- 4 offene Punkte für User-Entscheidung vor Phase 4b (blockieren NICHT 4a):
  1. python-jose beibehalten (wochenplaner-konsistent) oder PyJWT (moderner)?
  2. SQLite-only-Dev oder parallel PostgreSQL-Dev?
  3. CSP-Header in nginx.conf oder FastAPI-Middleware?
  4. LoginAttempt-Tabelle in v1 oder erst v1.1?
- Sub-Agent-Empfehlung: GO für Phase 4a (mit den 4 Punkten vor 4b zu klären)

## 2026-06-03T22:36 - Phase-3-Decisions-Lockdown + Phase 4a START
- User: 'alle Defaults mach dann weiter' → Defaults gelockt, Phase 4a startet
- 4 Defaults in 02-architecture.md Section 13 verankert:
  - JWT-Lib: python-jose[cryptography]==3.3.0 (wochenplaner-konsistent, Pattern-Reuse)
  - DB-Setup: SQLite-only-Dev (aiosqlite), PostgreSQL erst in Prod
  - CSP-Header: FastAPI-Middleware (zentral, app-aware)
  - LoginAttempt: v1.1 (Brute-Force-Schutz kommt später)
- 4 Security-Hardening-Constraints (aus patterns-summary Risiken 3, 4, 5, 8):
  - KEIN Default-User (admin/admin) - explizite Registrierung
  - CORS-Whitelist via CORS_ORIGINS ENV-Var (kein '*')
  - KEIN JWT-Secret-Fallback (Hard-Fail wenn AUTH_SECRET fehlt)
  - PostgreSQL in Prod (Coolify-Service), KEIN SQLite in Prod
- Library-Pinning festgelegt (16 Libs, siehe 02-architecture.md Section 13.6)
- Async-Pflicht durchgängig (Routers, Services, DB-Operations, Tests, Alembic)
- implementation_engineer Sub-Agent startet Phase 4a (Backend-Skeleton + Auth + Health, 8 Deliverables, review_block_after: true)
- Output-Pfad: /a0/.a0/crm-system/

## 2026-06-03T22:53 - Phase 4a (Backend-Skeleton + Auth + Health) DONE
- implementation_engineer Sub-Agent liefert /a0/.a0/crm-system/ (39 Files committed)
- Git-Commit: 955607f7309bcb299dc582dcd35612543d1a0698 (verifiziert)
- 25 Tests passed in 6.22s (alle grün)
- 12 Tests in test_auth.py (alle 9 FR-1 Akzeptanzkriterien + 3 Bonus-Tests)
- 4 Tests in test_health.py (/health, /api/v1/health, no-auth, security-headers)
- 9 Tests in test_users_me.py (current-user, profile-update, admin-only, refresh, logout)
- Alle 8 Phase-4a-Deliverables komplett:
  1. backend-skeleton (Layout, requirements.txt, pyproject.toml, .env.example, .gitignore)
  2. core-modules (config.py, db.py, security.py, deps.py)
  3. models-base (base.py mit Mixins, org.py, user.py)
  4. alembic-init (env.py async, 0001_init.py mit orgs+users, alembic.ini)
  5. auth-routes (auth.py, users.py, schemas, services)
  6. health-route (/health + /api/v1/health mit DB-Check)
  7. main-app (FastAPI-Init, CORS-Whitelist, CSP-Middleware, Exception-Handler)
  8. tests-foundation (conftest.py mit in-memory SQLite pro Test, alle 9 FR-1 Tests)
- Architecture-Decisions-Lockdown (Section 13) zu 100% eingehalten
- Live-Smoke-Test grün: curl /health → 200, JWT-Auth funktioniert, OpenAPI-3.1 generiert
- 9 Offene Punkte dokumentiert (CSP unsafe-inline, LoginAttempt-v1.1, Refresh-Token-Rotation, etc.)
- MANDATORY Test-Checkliste: alle 7 Punkte ✅
- Empfehlung: GO für Phase 4b (Business-Logic) + Phase 4c (Frontend) parallel
- review_block_after aktiv → User-Approval für 4b+4c erforderlich

## 2026-06-04T00:22 - Phase 4d (Deployment) DONE
- runtime_devops_engineer Sub-Agent liefert 6 neue Files + 1 erweitertes .gitignore
- Git-Commit: d68d385 (6 files changed, 499 insertions)
- Files: Dockerfile (74 Z., multi-stage python:3.12-slim, appuser UID 1000, HEALTHCHECK 30s/10s/3 retries/15s start-period), prestart.sh (28 Z., ausführbar, set -e + alembic upgrade head + exec uvicorn --workers 1), docker-compose.yml (88 Z., postgres:16-alpine + crm-app mit build: .), .env.docker.example (39 Z. Template), COOLIFY_SETUP.md (269 Z., komplette UI-Walkthrough + Domain-Format https://crm.media-on.de:443 prominent dokumentiert), runbook-restore.md (369 Z. in /a0/.a0/, 9 Abschnitte: Architektur, Health-Checks, Migration-Strategie, Rollback, Log-Inspektion, Backup, Secret-Rotation, 7 Common-Issues-Fixes, Eskalation)
- Tests: 118 passed in 49.98s (kein Backend-Code angefasst, alle grün)
- Docker-Build-Test: NICHT lokal ausführbar (kein dockerd in sandbox) - stattdessen Strukturprüfung 13/13 + SH-Syntax + YAML-Validierung
- Image-Größe: erwartet ~250-350 MB (slim-base + libpq5 + curl + deps)
- AUTH_SECRET ≥ 32 Zeichen + Generierungsbefehl an 3 Stellen dokumentiert
- Domain-Format https://crm.media-on.de:443 prominent dokumentiert (Bug-Fix verhindert)
- Sub-Agent-Empfehlung: GO für Phase 5 (test_debug_engineer)
- ORCHESTRATOR-PFLICHT: Forgejo-Repo-Push (Code liegt nur lokal) + DOMAIN-CONFLICT mit Saltcorn-CRM-Instanz (siehe unten)

## WICHTIGE Memory-Conflict-Warnung
- Memory sagt: 'User's project is a Kontakt-CRM app built with Saltcorn on Coolify. Domain: crm.media-on.de. Coolify deployment: project CRM-App (UUID av56jojgafc1dtz4e2m1qpj6), service crm-saltcorn (UUID om3m70qs17d3rr5ueh613l0h) on localhost server (UUID lw80w8scs444gwcw084s00s4)'
- Aktuelles Projekt: FastAPI-CRM (gebuilt seit 4h), Domain crm.media-on.de:443 geplant
- **CONFLICT: 2 CRM-Projekte mit demselben Domain-Namen! Saltcorn-CRM ist möglicherweise schon deployed auf crm.media-on.de**
- User-Klärung erforderlich vor Phase 8 (Coolify-Deploy):
  - Option A: Saltcorn-CRM ersetzen → FastAPI-CRM übernimmt crm.media-on.de (Saltcorn vorher deinstallieren)
  - Option B: FastAPI-CRM auf andere Domain (z.B. crm2.media-on.de:443, fastapi-crm.media-on.de:443)
  - Option C: Saltcorn-CRM ist veraltet/vergessen → crm.media-on.de ist frei

## Forgejo-Push-Plan
- Code liegt nur lokal in /a0/.a0/crm-system/.git
- Coolify-Server kann Code nicht direkt ziehen (nur über Git-Repo)
- Forgejo-Instanz verfügbar: forgejo.media-on.de (laut Memory)
- Plan:
  1. Forgejo-Repo 'crm-system' anlegen via API (POST /api/v1/user/repos mit Token)
  2. git remote add origin https://TOKEN@forgejo.media-on.de/leopoldadmin/crm-system.git
  3. git push -u origin master
- Dokumentiert in COOLIFY_SETUP.md § 1
- Sub-Agent-Empfehlung: GO für Phase 5 (test_debug_engineer)
- implementation_engineer Sub-Agent liefert 26 neue Files (13 HTML, 1 CSS, 9 JS, 3 Tests) in /a0/.a0/crm-system/app/webui/
- Git-Commit: 0f11e4a (Frontend) + 86dac33 (Static-Mount)
- 60 neue Frontend-Tests, GESAMT 118 passed in 49.54s (alle grün)
- 13 HTML-Pages: index, app, dashboard, accounts, accounts-detail, contacts, contacts-detail, pipeline, activities, settings-profile, settings-users, settings-org, 404
- 5 Alpine-Components: app-shell, account-list, deal-kanban (HTML5-Drag-and-Drop), activity-list, dashboard-kpis
- Foundation: api.js (fetch-Wrapper mit JWT), auth.js, store.js (Alpine-Stores für auth + notifications), notifications.js, app.css
- CSP-Header in Live-Response verifiziert: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none';
- R-5-Check: KEIN x-html in irgendeiner HTML-Datei ✅
- MANDATORY Frontend-Test-Checklist: 13 HTML-Pages existieren, Auth-Gate implementiert, alle Tests grün, alle Commits clean
- 6 Offene Punkte dokumentiert: Static-Mount fehlt (vom Orchestrator integriert), Org-Edit-Endpoint fehlt (v1.1), Dashboard dupliziert (Multi-Page-Pragmatik), Tailwind via CDN, keine Client-Side-Tests, ES-Modules im Browser
- **ORCHESTRATOR-INTEGRATION (Static-Mount):**
  - app/main.py gepatched: StaticFiles-Import + app.mount("/", StaticFiles(directory=app/webui, html=True))
  - Git-Commit: 86dac33 (1 file changed, 12 insertions)
  - Live-Test verifiziert:
    - /health → 200
    - /api/v1/health → 200
    - / (index.html) → 200, text/html
    - /index.html → 200, text/html
    - /dashboard.html → 200, text/html
    - /api/v1/users/me (no auth) → 401 (Auth funktioniert, Router matched vor Static-Mount)
    - CSP-Header korrekt in allen Responses
- Empfehlung: GO für Phase 4d (Deployment: Dockerfile, docker-compose, Coolify-Config, Runbook)