Felix KemmlerandClaude Sonnet 5
598dfcd38a
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 23s
Docker-Images bauen und veröffentlichen / build (VITE_OMSORG_CORE_URL=${{ vars.OMSORG_CORE_PUBLIC_URL }}, omsorgapp/Dockerfile, omsorgapp) (push) Failing after 2s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Failing after 39s
- 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>
52 lines
4.0 KiB
Markdown
52 lines
4.0 KiB
Markdown
# 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`.
|