adminandClaude Sonnet 5
960bcd6dbf
Dockerfile, docker-compose.yml, requirements.txt und .env (gitignored) fuer pflegepilot_alpha_v2/pflegepilot ergaenzt. Ein App-Service ueber Gunicorn, Isolation der Daten ueber zwei benannte Volumes (db, static) statt eines separaten DB-Containers, da SQLite eingebettet ist. Secret-Key kommt jetzt aus der Umgebungsvariable SECRET_KEY (lokaler Fallback bleibt fuer "python start.py" ohne Docker erhalten), Host-Port und Worker-Anzahl sind ueber .env konfigurierbar. Bewusst keine Domain hinterlegt, da die DynDNS-Domain erst spaeter auf die Testbench gelegt wird. Dabei einen Bug in der DB-Migrationsreihenfolge gefunden und behoben: die nutzer-Tabelle wurde zu spaet angelegt und liess auf einer komplett leeren Datenbank (z.B. frisches Docker-Volume) mehrere Spalten fehlen, was den Demo-Konto-Bootstrap zum Absturz brachte. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.7 KiB
3.7 KiB
offene Aufgaben: sortiere die Aufgaben nach korrekter Reihenfolge, schreibe nach dieser zeile um für KI-Lesbarkeit, fertige aufgaben durchstreichen und als erledigt markieren.
Reihenfolge unten nach Abhängigkeit/Aufwand sortiert (nicht nach ursprünglicher Nummerierung). Punkt "Docker" wurde in zwei getrennte Aufgaben aufgeteilt, da "in Docker packen" und "Migration zu React+Postgres" völlig unterschiedlicher Umfang sind und nicht als ein Task behandelt werden sollten.
-
1. Demo-Login für Vorführungen(erledigt)Eigener Login, zeigt eine erfundene/fiktive Person als "Familienmitglied"Nutzer kann im Demo-Modus eine Test-Person anlegenDemo-Inhalte müssen komplett vorausgefüllt sein (nicht leer)Demo-Datenbestand setzt sich automatisch alle 6 Stunden zurück- Umsetzung:
nutzer.ist_demo-Konto "demo"/"demo", "Demo ausprobieren"-Button auf dem Login-Screen, "Demo-Modus"-Badge in der Topbar, vorausgefüllte fiktive Patientin "Grete Musterfrau" (Antrag, 2 Leistungen, 2 Aufgaben, Pflegetagebuch), Lazy-Reset alle 6h bei Login/Request (kein Cron/Thread nötig), E-Mail-Versand im Demo-Konto gesperrt (403), Demo-Konto von der Abo-Zahlungspflicht ausgenommen. Details siehe CLAUDE.md.
-
2. Docker-Containerisierung der aktuellen App (Flask + SQLite, kein Rewrite)(erledigt)App als Docker-Image/Compose-Setup lauffähig machen, so wie sie heute istIsolierung zwischen App-Container und Datenbank (getrennte Services/Volumes)Keine Secrets/Env-Werte in der docker-compose.yml selbst — eigene .env-Datei dafür (keine .env.example nötig, Solo-Projekt)Ports müssen über Variablen konfigurierbar sein, nicht hart codiert- Umsetzung:
Dockerfile+docker-compose.yml+.env(gitignored) +requirements.txtinpflegepilot_alpha_v2/pflegepilot/. Ein Service (SQLite ist eingebettet, kein eigener DB-Server nötig/sinnvoll ohne Postgres-Rewrite); Isolation stattdessen über zwei benannte Docker-Volumes (pflegepilot_db,pflegepilot_static), die App-Container-Rebuilds überleben..enventhältSECRET_KEY(zufällig generiert),APP_PORT(Host-Port, Default 5050),GUNICORN_WORKERS— läuft produktiv über Gunicorn statt Flask-Dev-Server. Bewusst keine Domain im Code/.envhinterlegt, da die DynDNS-Domain erst nachträglich auf die Testbench gelegt wird — der Container kennt nur seinen Port. Nebenbei einen echten Bug in der DB-Migrationsreihenfolge gefunden und behoben (nutzer-Tabelle wurde zu spät angelegt, fiel nur auf einer wirklich leeren DB auf — z.B. frisches Docker-Volume). Details siehe CLAUDE.md, Abschnitt "Docker deployment". Getestet: Build, Start, Login (admin+demo), Neustart mit Datenpersistenz über die Volumes, sauberer Boot auf komplett leerer DB.
-
3. Update-Benachrichtigung / Changelog-System
- Nach dem ersten Login nach einem Update: kurzer anklickbarer Hinweis, was sich geändert hat
- Ein Klick auf "Gelesen" reicht, um den Hinweis zu schließen
- Optional: dauerhaftes Icon in der Sidebar, um alle vergangenen Changelogs als Historie nachzulesen
- Setzt eine einfache Versionierung des Deployments voraus (siehe Punkt 4 unten), damit die App weiß, "was ist neu seit dem letzten Login"
-
4. ⚠️ Separates Grossvorhaben: Migration zu React + PostgreSQL
- Vollständiger Technologiewechsel weg von Flask/vanilla-JS/SQLite — deutlich grösserer Umfang als die Punkte oben, keine Nebenbei-Aufgabe
- Braucht eine eigene Versionierungs-/Update-Strategie, da die App online ist und nicht für immer im jetzigen Stack bleiben wird
- Bevor hier irgendetwas beginnt: eigene Planungsrunde nötig (Umfang, Reihenfolge der Migration, ob schrittweise oder Neubau, Datenmigration aus der bestehenden SQLite-DB)