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

• 1. KI-Claude-API-Block aus dem Backend entfernen (erledigt)

  • Der gesamte "KI – Claude API"-Kartenblock in den Backend-Einstellungen (Karte, Eingabefeld, zugehöriger Code/Route) soll komplett verschwinden – wird nicht genutzt.

• 2. Backend "Betrieb"-Karte durch Rechtstexte ersetzen (Impressum, Datenschutz, Nutzungsbedingungen) (erledigt, mit einer Abweichung)

  • Stattdessen: drei bearbeitbare Rechtstexte-Seiten (Impressum, Datenschutzerklärung, Nutzungsbedingungen), die der Admin im Backend pflegen kann.
  • Alle drei Seiten müssen für den Kunden (Nutzer) per 1-Klick erreichbar sein – am besten als fester Link-Block unten in der Sidebar.
  • Abweichung: die "Betrieb"-Karte wurde nicht entfernt, da Firmenname/Logo/Adresse dort aktiv für Sidebar-Branding und die Fußzeile generierter PDFs (Musterbrief, Widerspruch, Pflegetagebuch, Patientenakte) verwendet werden – das Entfernen hätte eine echte Funktion ersatzlos gestrichen. Die Rechtstexte-Karte kam stattdessen in den frei gewordenen Slot der KI-Claude-API-Karte. Bei Bedarf bitte Rückmeldung, falls die Betrieb-Karte trotzdem weg soll (dann bräuchte die Branding-Pflege einen neuen Platz).
  • Umsetzung: 3 neue einstellungen-Schlüssel (rechtstext_impressum/_datenschutz/_agb), öffentlich abrufbar (kein Login nötig, wie bei Impressumspflicht üblich), Sidebar-Fußzeile mit 3 Links, von der Abo-Sperre ausgenommen.

• 3. Nutzerverwaltung reparieren & Admin-Dashboard auf Nutzerverwaltung fokussieren (erledigt)

  • Bug: bei einem manuell angelegten Test-Konto lassen sich aktuell keine Aktionen ausführen. Ursache gefunden: Sperren/Löschen/Freimonate gab es nur im separaten Admin-Dashboard, nicht in der einfacheren "Nutzerverwaltung"-Karte im Backend, in der vermutlich nachgeschaut wurde – jetzt hat das Admin-Dashboard zusätzlich einen "Bearbeiten"-Button, damit dort alles an einem Ort ist.
  • Für die Rolle Admin sind Leistungskatalog, Formulare & Recht usw. in der Sidebar irrelevant. Sidebar blendet diese Bereiche für Admin jetzt aus, Admin landet nach Login direkt auf dem Admin-Dashboard.
  • Nutzerverwaltung um zusätzliche Informationen je Konto erweitern. Registriert-am, Letzter Login und IP-Adresse sind jetzt in der Konten-Tabelle sichtbar (Zahlungsstatus gab es über "Abo bis"/"abgelaufen"/"kein Zugang" schon vorher).

• 4. Rechnungsanschrift & Rechnungserstellung (erledigt, erweitert um Registrierung)

  • Admin braucht in der Nutzerverwaltung Einsicht in die hinterlegte Rechnungsanschrift jedes Kontos. Teil des neuen "Bearbeiten"-Modals im Admin-Dashboard.
  • Admin muss auf Kundenwunsch eine Rechnung für ein Konto erstellen können (PDF). Neuer "Rechnung"-Button pro Konto, erzeugt clientseitig ein PDF (gleiche Technik wie Musterbrief/Widerspruch).
  • Registrierungs-Button auf dem Login-Bildschirm umgesetzt: "Noch kein Konto? Jetzt registrieren" öffnet ein Formular (Name, Zugangsdaten, Pflichtfeld Rechnungsanschrift), Konto wird direkt eingeloggt.
  • Nach der Registrierung ist Lesen/Ansehen sofort möglich, aber Briefe/Widersprüche, Leistungen-Zuweisung und Kalender-Einträge sind gesperrt, bis ein Abo vorliegt (unabhängig vom globalen Zahlungspflicht-Schalter) – Admin kann über "Freischalten" manuell freigeben.
  • Den Standard-Zugangsdaten-Hinweis (admin/admin) von der Login-Seite entfernt.

• 5. 🔒 Sicherheits-Audit beheben (vor Live-Gang auf der Testbench) (erledigt, ausser Session-Cookie-Punkt)

  • Ergebnis eines Code-Reviews von app.py + templates/index.html am 2026-07-19, am 2026-07-19 direkt im Anschluss auch behoben und verifiziert (Server-Start, Login, Admin-Nutzerliste, Rate-Limit-Test).

  • Kritisch:

    • python app.py (Direktstart) lief mit debug=True und host="0.0.0.0" – RCE-Risiko übers Netz. Fix: host="127.0.0.1". start.py/Docker unverändert (Gunicorn nutzt den __main__-Block nie).

  • Hoch:

    • Kein Datei-Typ-Whitelist beim Brief-Upload (api_brief_speichern) – jetzt gleiche .pdf-Prüfung wie beim Dokumenten-Upload.
    • Ungeschätzte IP-Adresse im Admin-Dashboard (Stored-XSS über X-Forwarded-For) – Frontend jetzt escH(n.letzte_ip||''); zusätzlich serverseitig eine neue Hilfsfunktion _client_ip() (app.py), die den Header vor dem Speichern auf [0-9a-fA-F.:] beschränkt und auf 45 Zeichen kappt (IPv4/IPv6-safe), genutzt in api_auth_login und api_auth_registrieren.

  • Mittel:

    • Keine Rate-Limits auf Login/Registrierung – einfaches In-Memory-Rate-Limiting ergänzt (_rate_limited() in app.py, pro IP+Zweck): Login max. 10 Versuche/5 Min, Registrierung max. 5/10 Min, sonst HTTP 429. Bewusst ohne neue Abhängigkeit (kein flask-limiter), da nur ein einzelner Gunicorn-Prozess mit wenigen Workern läuft und ein einfacher Zähler reicht; Limit gilt pro Worker, nicht global über alle Worker hinweg – für die aktuelle Grössenordnung ausreichend.
    • Keine Security-Header – neuer @app.after_request-Hook _security_headers() setzt X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Content-Security-Policy: frame-ancestors 'self'. Bewusst kein script-src/volles CSP, da templates/index.html durchgehend Inline-<script> ohne Nonce/Hash verwendet – ein strengeres CSP hätte die App sofort zerschossen.
    • Freemium-Sperre umgehbar über /api/antraege – POST/PUT /api/antraege sind jetzt Teil der Freemium-Sperrliste in global_auth_check().

  • Niedrig:

    • Admin-angelegte Konten ohne Passwort-Mindestlänge – gleiche 6-Zeichen-Prüfung jetzt auch in POST /api/nutzer und (zusätzlich, war im Audit nicht explizit erwähnt aber gleiche Lücke) beim Passwort-Ändern in PUT /api/nutzer/<uid>.
    • .svg beim Firmenlogo-Upload erlaubt – aus der Whitelist in /api/admin/logo entfernt.
    • Session-Cookie ist weiterhin nicht Secure – bewusst nicht behoben, wie im Audit vermerkt erst relevant sobald TLS/Reverse-Proxy vor der Testbench steht (siehe SESSION_COOKIE_SECURE in CLAUDE.md unter "Docker deployment").
    • Toter Code admin_password/session["admin_pw"] – entfernt aus api_admin_get/api_admin_save, kein Frontend-Bezug vorhanden (geprüft).
    • Unbenutzter urllib.request/urllib.error-Import – Import-Zeile bereinigt.

• 6. ⚠️ Separates Grossvorhaben: Migration zu React + PostgreSQL (läuft, Phase 0-6 erledigt)

  • Vollständiger Technologiewechsel weg von Flask/vanilla-JS/SQLite — deutlich grösserer Umfang als die Punkte oben, keine Nebenbei-Aufgabe
  • Entscheidung: kompletter Parallel-Neubau in pflegepilot_v3/ (neuer Ordner im selben Repo), alte App (pflegepilot_alpha_v2/) bleibt unverändert online. Keine Datenmigration – frische Postgres-DB, Demo-Daten, Admin-Zugang gemeinsam interaktiv angelegt. Stack: FastAPI + PostgreSQL + Next.js. Architekturplan mit 8 Phasen liegt in C:\Users\Daniel\.claude\plans\cheerful-shimmying-pnueli.md.
  • Phase 0 – Grundgerüst (erledigt): Docker-Setup (3 Services: db/api/web, eigene Ports 5532/8100/3100, kein Konflikt mit der alten App), 11 Postgres-Tabellen per Alembic-Migration, Auth Ende-zu-Ende (Login/Registrierung/Logout/Demo-Login, Rate-Limiting, Security-Header), WeasyPrint-PDF-Smoke-Test, Next.js-Grundgerüst mit Login-Overlay. Admin-Konto gemeinsam mit dem Betreiber angelegt (nicht hartkodiert).
  • Phase 1 – Patienten-CRUD + Isolation + Dashboard (erledigt): get_owned_patient/scoped_patienten_query als FastAPI-Dependencies (typsicherer Ersatz der alten SQL-String-Helper), Patienten-CRUD mit 3er-Cap pro Konto, Notizen mit Änderungshistorie, Pflegegrad-Patch, Dashboard-Route. Frontend: ResponsiveTable/DateWheelPicker/BentoGrid als wiederverwendbare Bausteine, Patientenliste mit Suche/Filter, Patientenakte-Detailseite, Kurzformular für neue Patienten (der volle Interview-Wizard folgt in Phase 2). Isolation Ende-zu-Ende mit zwei echten Konten getestet: keines sieht/erreicht die Patienten des anderen (404), Admin sieht weiterhin alles. Docker-Setup um Bind-Mounts erweitert (kein Rebuild mehr nötig bei Code-Änderungen, nur Neustart).
  • Phase 2 – Interview-Wizard (erledigt): kompletter 6-Schritte-Wizard (Persönliche Daten → Kontakt & Adresse → Krankenversicherung mit Autocomplete → Pflegesituation als verschachtelter Sub-Wizard mit Auto-Advance → regelbasierte Pflegegrad-Einschätzung → Übersicht) als useReducer-State-Maschine. Die Schätzlogik (5 Fragen, nicht KI-gestützt) lebt zentral im Backend (pflegegrad_regeln.py + POST /api/pflegegrad/schaetzen), 1:1 aus der alten App portiert, statt im Frontend dupliziert zu werden. Krankenkassen-Stammdaten (~86 Versicherer DE/AT/CH) ebenfalls 1:1 portiert.
  • Phase 3 – Katalog, Rechner, Anträge, Widerspruch & Musterbrief (erledigt): Leistungskatalog (82 Einträge) + Leistungsrechner-Tabelle 1:1 portiert. Wichtigste Architektur-Änderung: PDF-Erzeugung läuft jetzt komplett serverseitig (WeasyPrint) statt client-seitig (html2pdf.js) – Brieftext-Logik für Widerspruch/Musterbrief 1:1 aus der alten App portiert (briefe_text.py), WGRUENDE-Rechtsgrund-Bausteine (28 Einträge) ebenso. PDFs liegen unter app/uploads/briefe/<pid>/ und sind nur über eine get_owned_patient-geschützte Download-Route erreichbar (Verbesserung gegenüber dem offen gemounteten static/ der alten App) – mit zwei Konten verifiziert, dass fremde PDFs 404 liefern. require_paid_access als erste scharf geschaltete Freemium-Sperre (Anträge/Widerspruch/Musterbrief) – mit frisch registriertem Konto ohne Abo verifiziert (402).
  • Phase 4 – Admin-Dashboard, Audit-Log, DSGVO-Export (erledigt): Nutzerverwaltung (Basis-CRUD + Sperren/Entsperren/Soft-Delete-mit-Archivierung/Abo-Freischalten), 1:1 aus der alten App portiert (_archiviere_patient/_add_monate → archivierung.py). "Löschen" bleibt bewusst Soft-Delete (§ 630f BGB), zusätzlich durch die ON DELETE RESTRICT-FK aus Phase 0 strukturell abgesichert. Jede Admin-Aktion verlangt eine Begründung und wird unveränderlich im Audit-Log protokolliert. DSGVO-Export bündelt alle Patientendaten + Dateien als ZIP. Mit echten Kontenlebenszyklen verifiziert: Sperren blockt Login sofort, Selbstsperrung/-löschung verboten, Hard-Delete nur ohne zugeordnete Patienten möglich.
  • Phase 5 – Abo-Gate, Rechnung, Changelog (erledigt): Globales Abo-Gate (require_active_access) auf allen fachlichen Routern scharf geschaltet, aber wirkungslos solange abo_pflicht (Default AUS) nicht aktiviert ist – mit echtem Ein/Aus-Test verifiziert. Rechnung nach § 14 UStG mit race-sicherem fortlaufendem Zähler, serverseitige PDF-Erzeugung, Netto/USt-Aufschlüsselung oder § 19-Kleinunternehmer-Hinweis. Changelog-System 1:1 portiert. Dabei einen echten Bug gefunden und behoben: Gunicorn startet 2 Worker-Prozesse, die beim ersten Boot beide gleichzeitig die Startup-Sync ausführen – ohne Unique-Constraint entstand ein doppelter Changelog-Eintrag (Race Condition, reproduziert und mit mehreren Neustarts verifiziert). Fix: UNIQUE-Constraint + ON CONFLICT DO NOTHING statt eines Python-seitigen Vorab-Checks.
  • Phase 6 – Pflegetagebuch, Dokumente, Aufgaben & Kalender (erledigt): Pflegetagebuch-CRUD, Dokumenten-Upload mit Extension-Whitelist über eine autorisierte Download-Route (statt offen gemountetem static/, gleiches Muster wie die Briefe-PDFs aus Phase 3), Aufgaben-CRUD (bisher nur lesend im Dashboard), Kalender-Aggregation (offene Aufgaben, Widerspruchsfristen, MDK-Gutachtertermine, Archivierungsfristen, Pflegetagebuch-Erinnerungen) – 1:1-Logik-Port aus der alten App, mit Mandantentrennung auch bei Datei-Download verifiziert.
  • Noch offen: Phase 7 (Feinschliff + Deployment, u.a. Responsive-Durchgang, CSP verschärfen, SESSION_COOKIE_SECURE+TLS sobald Deploy-Ziel feststeht) – Details im Architekturplan. Damit ist der volle Funktionsumfang der alten App im Neubau erreicht.