Felix KemmlerandClaude Haiku 4.5
e1fbfadd17
- Backend (omsorgCore): CreateFacilityRequest um Konditionen- und CRM-Status-Felder erweitert, identisch mit UpdateFacilityRequest - FacilitiesController.Create: Gleiche Validierung wie Update (CrmStatus-Allowlist, FollowUp-Logik, Konditions-Wertebereich), aber ohne Transition-Check (kein Vorzustand beim Anlegen) - Gemeinsame Validierungslogik in ValidateCrmStatusAndFollowUpAsync extrahiert, um Code-Duplizierung zu vermeiden - omsorgCore/CLAUDE.md aktualisiert: Konditionen sind jetzt auch beim Anlegen setzbar - API-Clients neu generiert (TypeScript und PHP) - Frontend (omsorgapp): FacilityForm.jsx: includeCrmStatus-Flag entfernt, Konditionen und CRM-Status immer sichtbar - CreateFacilityDialog.jsx: CRM-Status-Auswahl + FollowUpDaysDialog-Workflow (analog zu Edit-Dialog) - EditFacilityDialog.jsx: vereinfacht (includeCrmStatus-Prop entfernt) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Omsorg Business Controls Pro – Release 0.1.1 Foundation
Stabile lokale Electron/React-Basis ohne native SQLite-Abhängigkeit.
Warum 0.1.1?
Release 0.1.0 nutzte better-sqlite3. Auf macOS/Electron kann dieses native Modul Versionsprobleme verursachen.
Release 0.1.1 speichert Daten zuerst in einer lokalen JSON-Datenbank im Benutzerordner.
Start
cd ~/Desktop/omsorg-business-controls-pro-release-0.1.1
npm install
npm run dev
Lokale Daten
Die App legt Ordner unter ~/Documents/Omsorg Business Controls Pro an:
- database/omsorg-local-db.json
- documents/employees
- documents/customers
- backups
Nächster Sprint
SQLite wird später sauber über eine entkoppelte Persistenzschicht eingebaut.