# CLAUDE.md — OMSORG Business Controls Pro (Monorepo-Root)

Diese Datei gilt für das gesamte Repository. Jedes Teilprojekt hat zusätzlich eine eigene `CLAUDE.md` mit projektspezifischen Details — bei Arbeit in einem Unterordner gilt dessen `CLAUDE.md` zusätzlich zu dieser hier.

## Was das hier ist

Ein Monorepo für die OMSORG-Plattform, einer Software für ein Pflege-Zeitarbeitsunternehmen. Vier Ebenen, drei Teilprojekte (Core+Engine bilden ein Backend, siehe unten):

| Verzeichnis | Rolle | Stack | Ist-Stand |
|---|---|---|---|
| `omsorgWeb/` | Öffentliche Website + **OMSORG Connect** (Mitarbeiter-App für Außendienst) | PHP, MySQL, vanilla JS, PWA | ✅ produktiv im Einsatz |
| `omsorgapp/` | **OMSORG Desktop** — Software für Büromitarbeiter (Sabina, Malik, Sabrina, Sascha) | Electron + React + Vite | 🔶 frühes Grundgerüst (Release 0.1.1), lokale JSON-Datenhaltung |
| `omsorgCore/` | **OMSORG Backend** — gemeinsame Datenbasis + Automatisierung (Core + Engine als eine Komponente) | C# / .NET 8, ASP.NET Core (Controller), PostgreSQL/EF Core, JWT-Auth | 🔶 Grundgerüst steht (Domain/Application/Infrastructure/Engine/Api, Rechtesystem, Auth, Employee-Endpoint end-to-end verifiziert); noch keine Anbindung von `omsorgWeb`/`omsorgapp`, DB-Migration noch nicht gegen echte Postgres getestet |

Leitdokumente:
- `omsorg.md` — Kurzvision (Rohnotizen)
- `omsorgapp/docs/OMSORG-BLUEPRINT.md` — vollständige Vision/Architektur (20 Kapitel, verbindliche Arbeitsgrundlage)
- `REQUIREMENTS.md` — daraus abgeleitete, nummerierte funktionale/nicht-funktionale Anforderungen (FR-IDs, NFR-IDs) mit Ist-Status je Requirement

**Immer zuerst `REQUIREMENTS.md` konsultieren**, bevor an einem Modul gearbeitet wird — dort steht, was bereits existiert (✅), teilweise existiert (🔶) oder noch offen ist (⬜), inklusive Verweis auf die konkreten Dateien.

## Zentrales Architekturprinzip

**Jede Information wird nur einmal gespeichert.** Die sechs Core-Objekte (Mitarbeiter, Einrichtung, Vertrag, Auftrag, Zeiterfassung, Rechnung) leben in genau einer Datenquelle — `omsorgCore` — und werden von Desktop, Connect und allen Auswertungen gemeinsam genutzt. Aktuell ist das **noch nicht der Fall**: `omsorgWeb` hat eine eigene MySQL-DB, `omsorgapp` eine eigene lokale JSON-DB. Das ist der bekannte Hauptmangel der aktuellen Architektur (siehe `REQUIREMENTS.md` Abschnitt 2 und 10) — keine neue Insellösung schaffen, sondern auf die Zusammenführung hinarbeiten.

OMSORG Core (Datenschicht) und OMSORG Engine (ereignisgesteuerte Automatisierung) sind **eine** Backend-Komponente mit zwei internen Schichten, kein separates Deployable für die Engine.

## Rollen (gelten repoweit)

| Rolle | Zugriff |
|---|---|
| Sabina, Malik (Geschäftsführung) | Vollzugriff, inkl. Gewinn/Margen |
| Sabrina (Disposition/Buchhaltung) | fast alles außer vollständigem Gewinn/Gesamtmargen |
| Sascha (Recruiting) | Recruiting/CRM, kein Zugriff auf Rechnungen/Zahlungen/Gewinn/Controlling |
| Außendienst | nur über OMSORG Connect, nur eigene Daten |

Jede neue Funktion muss serverseitig gegen diese Rechte prüfen, nicht nur im UI verstecken.

## Arbeitsweise

- Kleine, überprüfbare Schritte: eine Datei/Funktion bearbeiten, testen, Fehler beheben, committen.
- Keine doppelt gepflegten Daten, keine isolierten Insellösungen, wiederverwendbare Komponenten.
- Sicherheit und Datenschutz (DSGVO) sind Grundvoraussetzung, keine spätere Zusatzfunktion.
- Branding/Design vom fachlichen Kern trennen (langfristiges White-Label-Ziel, siehe Blueprint Kap. 14) — aktuell nicht umgesetzt, aber bei neuem Code nicht zusätzlich verfestigen.

## Wo was steht

- Detaillierte technische Konventionen je Teilprojekt → `omsorgWeb/CLAUDE.md`, `omsorgapp/CLAUDE.md`, `omsorgCore/CLAUDE.md`.
- Requirements/Akzeptanzkriterien → `REQUIREMENTS.md`.
- Produktvision/Roadmap → `omsorgapp/docs/OMSORG-BLUEPRINT.md`.
- Backend-Konfigurationswerte (was einstellbar ist, Defaults, Env-Var-Overrides) → `omsorgCore/CONFIGURATION.md`.