pflegefuchs/open.md

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 anlegen
  • Demo-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 ist
  • Isolierung 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.txt in pflegepilot_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. .env enthält SECRET_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/.env hinterlegt, 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 (erledigt)

  • 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, damit die App weiß, "was ist neu seit dem letzten Login"
  • Umsetzung: changelog.py (neues, statisches Datenmodul wie katalog.py) enthält die Liste aller Einträge, neueste zuerst; die App-Version wird automatisch aus dem obersten Eintrag abgeleitet – für ein Release reicht ein neuer Eintrag ganz oben, sonst nichts. Jedes Konto merkt sich (nutzer.letzte_gesehene_version), was es schon gesehen hat; nach Login erscheint einmalig ein Modal mit allem Neuen seit dem letzten Stand, mit "Gelesen"-Button. Neu angelegte Konten starten bewusst "auf aktuellem Stand" (kein Rückblick auf Änderungen, die sie nie erlebt haben), bestehende Konten sehen bei einem echten Update korrekt den neuen Hinweis. Zusätzlich ein dauerhafter Sidebar-Eintrag "Was ist neu?" mit Verlaufsansicht und rotem Punkt bei Ungelesenem. Details siehe CLAUDE.md, Abschnitt "Update-Benachrichtigung / Changelog". Getestet: Modal nach Login, Badge verschwindet nach "Gelesen", Verlaufsseite, neu angelegtes Konto sieht keinen Hinweis, funktioniert identisch lokal und im Docker-Container (inkl. Upgrade-Fall mit bestehendem Volume).

• 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)