Felix KemmlerandClaude Sonnet 5
b6c1389c55
Consolidates the previously separate omsorgapp and omsorgCore repos (each had their own nested .git with GitHub history) plus the old root-level website/mitarbeiter-app into a single monorepo, matching the structure already documented in the root CLAUDE.md. Also moves the PHP employee app aside as omsorgWeb/mitarbeiter-app-legacy/ to serve as a template for a ground-up rewrite. Fixes .gitignore in the same pass: the config-secrets/uploads/data patterns were unanchored (relative to repo root, not depth-agnostic), so they silently stopped matching once the app moved under omsorgWeb/. Patterns are now **/-prefixed and cover both mitarbeiter-app and mitarbeiter-app-legacy, keeping DB/SMTP credentials and uploaded employee documents out of version control. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.0 KiB
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.