open.md/CLAUDE.md: Phase-5-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), 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_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), Phase 4 (admin dashboard: account lock/unlock/soft-delete-with-archival/subscription-grant, audit log, DSGVO export), and Phase 5 (global subscription gate, § 14 UStG invoicing, changelog system) are done as of 2026-07-19; remaining phases start at Phase 6 (Pflegetagebuch, Dokumente, Kalender). 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. **Real bug found and fixed in Phase 5**: Gunicorn's multiple worker processes each run the FastAPI `lifespan` startup handler independently, so the changelog dev-seed sync (`app/changelog.py: sync_changelog()`) executed concurrently on first boot and inserted a duplicate row — no unique constraint existed on `changelog_eintraege.version` to prevent it. Fixed with a DB-level `UNIQUE` constraint plus `INSERT ... ON CONFLICT DO NOTHING` (Postgres dialect insert) instead of a Python-side "check existing, then insert missing" pattern, which is not safe under concurrent execution. Worth remembering for any future startup-time sync/seed logic in this app: assume it runs from more than one process at once.
 - **`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,7 +45,7 @@ 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-4 erledigt)*
+- [ ] **6. ⚠️ Separates Grossvorhaben: Migration zu React + PostgreSQL** *(läuft, Phase 0-5 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).
@@ -53,4 +53,5 @@ Reihenfolge unten nach Abhängigkeit/Aufwand sortiert (nicht nach ursprüngliche
   - ~~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.
-  - Noch offen: Phase 5 (Abo/Zahlung + Rechnung + Changelog) bis Phase 7 (Feinschliff + Deployment) – Details im Architekturplan.
+  - ~~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.
+  - Noch offen: Phase 6 (Pflegetagebuch + Dokumente + Kalender) und Phase 7 (Feinschliff + Deployment) – Details im Architekturplan.