Felix KemmlerandClaude Sonnet 5
598dfcd38a
- omsorgapp: drop Electron, run as a plain Vite/React browser app; refresh token moves to an HttpOnly cookie (omsorgCore), CORS added for the new browser origin, document download/preview switched to Blob-based browser APIs. - Add Dockerfiles for omsorgCore, omsorgapp, and omsorgWeb, a docker-compose.yml wiring Postgres/MySQL/all three apps together, and a Gitea Actions workflow that builds and pushes images to the repo's container registry on push to main and on version tags. 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), als Browser-Tab genutzt (kein Electron) | React + Vite | 🔶 frühes Grundgerüst (Release 0.1.1), Daten kommen bereits über omsorgCore (kein lokaler Datenspeicher mehr) |
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.