open.md/CLAUDE.md: Phase-4-Fortschritt beim Neubau nachgetragen

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -7,7 +7,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 This is not a single project but a working directory with one active app plus reference/planning material:
 
 - **`pflegepilot_alpha_v2/pflegepilot/`** — the current production codebase (Flask + SQLite web app). Still the live app; keep maintaining it (bugfixes, security, small features) independently of the rewrite below.
-- **`pflegepilot_v3/`** — the in-progress full rewrite (FastAPI + PostgreSQL + Next.js), built as a complete parallel rebuild alongside the still-running `pflegepilot_alpha_v2` app, not a migration of it — no code is shared and no data is migrated (fresh DB, demo data, an admin account created interactively together with the operator). Backend: `pflegepilot_v3/backend/app/` (routers, SQLAlchemy models, Alembic migrations under `migrations/`). Frontend: `pflegepilot_v3/frontend/src/app/` (Next.js App Router, route groups `(marketing)` public/SSR and `(app)` client-side behind a login overlay). Own `docker-compose.yml` with independent ports (db 5532, api 8100, web 3100) so it never conflicts with the old app's Docker setup. The full 8-phase architecture plan (schema translation, cross-cutting patterns, phase-by-phase scope) lives at `C:\Users\Daniel\.claude\plans\cheerful-shimmying-pnueli.md` — read it before continuing this work. Phase 0 (project skeleton, auth end-to-end), Phase 1 (patient CRUD, tenant isolation, dashboard), Phase 2 (6-step non-AI interview wizard, rule-based Pflegegrad estimation ported to `pflegegrad_regeln.py`, Krankenkassen autocomplete), and Phase 3 (Leistungskatalog, Leistungsrechner, Anträge, Widerspruch- and Musterbrief-generation) are done as of 2026-07-19; remaining phases start at Phase 4 (admin dashboard). Note the architecture shift in Phase 3: unlike the old app's client-side `html2pdf.js`, PDFs here are rendered server-side with WeasyPrint (`app/pdf.py` + Jinja2 templates under `app/pdf_templates/`) and served only through an authorization-checked download route rather than an openly mounted `static/` folder — see the plan file for the full rationale.
+- **`pflegepilot_v3/`** — the in-progress full rewrite (FastAPI + PostgreSQL + Next.js), built as a complete parallel rebuild alongside the still-running `pflegepilot_alpha_v2` app, not a migration of it — no code is shared and no data is migrated (fresh DB, demo data, an admin account created interactively together with the operator). Backend: `pflegepilot_v3/backend/app/` (routers, SQLAlchemy models, Alembic migrations under `migrations/`). Frontend: `pflegepilot_v3/frontend/src/app/` (Next.js App Router, route groups `(marketing)` public/SSR and `(app)` client-side behind a login overlay). Own `docker-compose.yml` with independent ports (db 5532, api 8100, web 3100) so it never conflicts with the old app's Docker setup. The full 8-phase architecture plan (schema translation, cross-cutting patterns, phase-by-phase scope) lives at `C:\Users\Daniel\.claude\plans\cheerful-shimmying-pnueli.md` — read it before continuing this work. Phase 0 (project skeleton, auth end-to-end), Phase 1 (patient CRUD, tenant isolation, dashboard), Phase 2 (6-step non-AI interview wizard, rule-based Pflegegrad estimation ported to `pflegegrad_regeln.py`, Krankenkassen autocomplete), Phase 3 (Leistungskatalog, Leistungsrechner, Anträge, Widerspruch- and Musterbrief-generation), and Phase 4 (admin dashboard: account lock/unlock/soft-delete-with-archival/subscription-grant, audit log, DSGVO export) are done as of 2026-07-19; remaining phases start at Phase 5 (subscription/payment scaffolding, invoicing, changelog). Note the architecture shift in Phase 3: unlike the old app's client-side `html2pdf.js`, PDFs here are rendered server-side with WeasyPrint (`app/pdf.py` + Jinja2 templates under `app/pdf_templates/`) and served only through an authorization-checked download route rather than an openly mounted `static/` folder — see the plan file for the full rationale. The admin router in Phase 4 (`app/routers/admin.py`) demonstrates the Phase 0 architectural decision concretely: it's declared as `APIRouter(dependencies=[Depends(require_admin)])` so every route is protected by construction, not by a maintained list.
 - **`pflegepilot_alpha/`** — superseded v1. Source files have been deleted; only a stale `__pycache__` remains. Do not develop here.
 - **`pflegepilot_erp.html`** — a standalone static HTML mockup/prototype, not wired to the Flask app. Not part of the running system.
 - **`Anleitung.md`, `Leistungen.md`, `Leistungen2.md`, `Pflegegrad.md`, `Musterbrief.md`** — German-language domain reference notes (care-benefits catalog research, sample letters, project rationale) used as source material for `katalog.py` and the letter generators. Not code.

open.md

@@ -45,11 +45,12 @@ Reihenfolge unten nach Abhängigkeit/Aufwand sortiert (nicht nach ursprüngliche
     - ~~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-3 erledigt)*
+- [ ] **6. ⚠️ Separates Grossvorhaben: Migration zu React + PostgreSQL** *(läuft, Phase 0-4 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).
-  - Noch offen: Phase 4 (Admin-Dashboard) bis Phase 7 (Feinschliff + Deployment) – Details im Architekturplan.
+  - ~~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.
+  - Noch offen: Phase 5 (Abo/Zahlung + Rechnung + Changelog) bis Phase 7 (Feinschliff + Deployment) – Details im Architekturplan.