Empfang V4: Auth, Praxis-Tenant, Cockpit, Caddy-Rewrite

Made-with: Cursor

AzA march 2026/project_status.json

@@ -33,7 +33,7 @@
     "HANDOVER-REGEL – Sicherheitsblock: Diesen Sicherheits-Benchmark NICHT jedes Mal neu diskutieren. Bei Sicherheits-/Architekturfragen auf dieses Zielbild zurueckgreifen statt neu zu improvisieren. Keine ueberzoegenen Aussenbehauptungen zu HIN/EPD/ISO ohne tatsaechliche Zertifizierung/Integration.",
     "ARCHITEKTUR – Medikamenten-Quellenlogik: Inhaltsquelle und Originallink getrennt (FIX-11). Inhaltsquellen: _fetch_doccheck_info (Standard) und _fetch_pharmawiki_info (Fallback), benutzerwaehlbar ueber _MED_CONTENT_QUELLEN / med_content_quelle. Originallink: _MED_QUELLEN / medikament_quelle (CH=Compendium, AT=BASG, DE=BfArM) unveraendert. _MEDICATION_FACTS als Offline-Fallback. Deckt alle auf DocCheck + PharmaWiki verfuegbaren Medikamente ab. Spaetere Marktprofile (DE/AT) separat.",
     "ZUKUNFTSBLOCK – Internationalisierung / Laender- und Quellenprofile: NICHT fuer jetzt. Erst DACH sauber stabilisieren (CH/DE/AT), Produkt erfolgreich machen, Go-Live sichern. Danach pruefen: Mehrsprachigkeit, laenderspezifische med. Quellenprofile. Profillogik vorsehen: app_language, market_region, med_source_profile, dx_source_profile, therapy_source_profile + manueller Override durch Benutzer/Praxis. Handelsnamen, Zulassungen, Fachinfos und Verfuegbarkeit sind laenderspezifisch – deshalb spaeter Quellenprofile pro Markt statt Einheitslogik.",
-    "ARCHITEKTURZIEL – AZA Praxis-Chat (VERBINDLICH, 2026-04-18): AZA Praxis-Chat wird strukturell in Richtung Softros entwickelt (Benutzer, Gruppen, Direktchat, Verlauf, Status), aber im Design ruhig, modern, medizinisch und AZA-konform umgesetzt. Softros ist FUNKTIONSVORBILD (Benutzerliste, Gruppen, Direktchat, Status, schnelle Interaktion), NICHT Designvorbild (kein 90er-Windows-Look). Zielstruktur: 3-Panel-Layout (Sidebar links mit Benutzern/Kanaelen/Status, Hauptchat mitte mit Inline-Eingabe, Aufgaben rechts). NICHT in rein kartenartige Einzelloesung zurueckfallen. Phase 1: Frontend 3-Panel-Layout + Inline-Chat + Archiv-Tab (kein Backend-Umbau). Phase 2: Backend-Kanaele + Presence + Direktchat-Routing. Phase 3: Multi-Tenant + WebSocket + Auth + Push. Oeffentliche Subdomain: empfang.aza-medwork.ch (DNS + Caddy vorbereitet)."
+    "ARCHITEKTURZIEL – AZA Praxis-Tenant-Chat Architektur (VERBINDLICH, 2026-04-18): Praxis/Organisation ist oberste Einheit (Mandant/Tenant). NICHT 'eine Lizenz = ein Chat', sondern: Lizenzen haengen an der Praxis, mehrere Lizenzen speisen denselben Praxisraum. Kerndatenmodell: practice_id, user_id, device_id, role, channel_id, task_id, session_id. Rollen: Practice Admin (einladen, Rollen/Geraete verwalten), Arzt, MPA, Empfang. Geraeteverwaltung: Admin sieht/erlaubt/sperrt/loescht Geraete. Mobilgeraet-Kopplung per QR-Code (Variante A verbindlich). Browser-Zugang von zuhause nur mit eingeladenem Konto + vertrautem Geraet + gueltiger Session. Chat-Kanaele pro Praxis: Allgemein, Empfang, Aerzte, MPA, Labor, Administration, Direktchats. Aufgaben als erstklassiges serverseitiges Objekt (task_id, practice_id, assigned_to, status, due_at, audit_log). Sicherheitsbasis: practice_id in JEDER Abfrage, serverseitige Rollenpruefung, Geraetebindung, Audit-Log, Session-Timeout, keine Trennung nur ueber Namen. Mobile-Strategie: kurzfristig Browser+Desktop, mittelfristig echte Mobile-App, spaeter Apple Watch nur leichte Funktionen. Phase 1: Frontend-Layout + Benutzer-Sync (aktuell). Phase 2: Backend practice_id + JWT + Kanaele + serverseitige Aufgaben + Geraeteverwaltung. Phase 3: Multi-Tenant produktiv + WebSocket + Mobile-App + QR-Kopplung + 2FA."
   ],
   "auth_contract": {
     "api_token_env": "MEDWORK_API_TOKEN",