aza/AzA march 2026 - Kopie/project_status.json

{
  "project": "AZA Medical AI Assistant",
  "phase": "B1 Backend-Sprint – Serverseitige OpenAI-Architektur (Variante B verbindlich)",
  "current_step": "B1",
  "last_completed": 17,
  "next_step": "B1",
  "last_update": "ARCHITEKTURENTSCHEIDUNG VARIANTE B verbindlich getroffen (2026-03-25). OpenAI-Key AUSSCHLIESSLICH serverseitig. Desktop-App spricht NUR mit eigenem AZA-Backend, AZA-Backend spricht mit OpenAI. Kein OpenAI-Key in der Client-App. Kein eigener OpenAI-Key pro Kunde. Kein Shared-Key. Hetzner wird als Server-/Backend-Pfad ernsthaft einbezogen. Hostpoint bleibt fuer Website/WooCommerce. Naechster Hauptblock: Backend Chat Proxy Endpoint (POST /v1/chat).",
  "updated_at": "2026-03-25",
  "workspace": {
    "project_root": "C:\\Users\\surov\\documents\\aza",
    "current_working_folder": "C:\\Users\\surov\\documents\\aza\\backup 24.2.26",
    "note": "All commands and scripts should assume this root unless explicitly changed."
  },
  "notes": [
    "Browser-basiertes AZA ist Kern des Projekts und nicht optional.",
    "Step 22 wird verbindlich nach browser_aza_mvp_spec.md umgesetzt.",
    "Kongress/CSE Thema ist geparkt (Google CSE 403 / DDG volatil). Fokus jetzt: Go-Live.",
    "Preismodell: Subscription (monatlich + Jahreslizenz 17% guenstiger). KEIN Einmalkauf.",
    "PRODUKTNAME – AKTUELLE RICHTUNG: AZA Office. Bevorzugte Langform: 'AZA Office – Ihr medizinischer KI-Arbeitsplatz fuer die Praxis'. Zweite gute Variante: 'AZA Office – Die KI-Assistenz fuer medizinische Dokumentation'. Noch nicht zwingend final juristisch/brand-strategisch entschieden, aber aktuelle bevorzugte Naming-Richtung fuer WooCommerce/Website/Download/Go-Live/Produktdarstellung. FRUEHERE SHORTLIST (AZA Desktop): (1) Die KI-Loesung fuer medizinische Dokumentation, (2) KI-gestuetzte Praxisdokumentation fuer Aerzte, (3) Ihre Plattform fuer medizinische KI-Dokumentation, (4) Ihr medizinischer KI-Arbeitsplatz fuer die Praxis, (5) Die KI-Assistenz fuer medizinische Dokumentation, (6) Medizinische KI fuer Aerzte und Praxen. KRITISCH: 'von Aerzten' eher nicht verwenden.",
    "Architektur: Hostpoint = Website/Marketing/WordPress/Kadence/WooCommerce. Hetzner = AZA-Backend/API/OpenAI-Proxy/Browser-AZA (JETZT RELEVANT, nicht mehr spaeter).",
    "Do-not-break: /license/status Format bleibt exakt. Keine Auth-Aenderungen ohne Auftrag. Keine Secrets loggen. Keine unnoetige API-Contract-Aenderungen.",
    "Do-not-break: Keine riskanten DNS-/Domain-Aenderungen an aza-medwork.ch ohne klare Pruefung. Website-Chaos durch vorschnelle Umschaltung war ein Fehler.",
    "Do-not-break: OpenAI-Key NIEMALS hardcoded in App einbauen. NIEMALS Shared-Key an Kunden ausliefern. Lokale Key-Eingabe wird bei Produktivauslieferung entfernt (Variante B). Secrets NIEMALS loggen.",
    "Do-not-break: Audioaufnahme IMMER als M4A (AAC via ffmpeg-Pipe). NIEMALS auf WAV zurueckaendern. WAV nur als Fallback wenn ffmpeg fehlt. Diese Entscheidung ist ENDGUELTIG – wurde bereits einmal faelschlich rueckgaengig gemacht.",
    "ARCHITEKTURENTSCHEIDUNG VARIANTE B (VERBINDLICH, 2026-03-25): OpenAI-Key AUSSCHLIESSLICH serverseitig im AZA-Backend. Desktop-App und spaetere Browser-App sprechen NUR mit AZA-Backend. AZA-Backend spricht mit OpenAI. KEIN OpenAI-Key in der Client-App. KEIN eigener OpenAI-Key pro Kunde als Pflicht. KEIN gemeinsamer OpenAI-Key clientseitig. KEINE halben Uebergangsloesung. KEINE Shared-Key-Bastelei. Lokale Key-Eingabe wird bei Produktivauslieferung entfernt. Hetzner wird als Server-/Backend-Pfad ernsthaft einbezogen.",
    "ARCHITEKTUR – Audio: Aufnahme direkt als M4A (AAC 64kbps via ffmpeg stdin-Pipe). Kein WAV-Zwischenschritt. Deutlich kleinere Dateien, schnellerer Upload, Aufnahmen ueber 1 Stunde moeglich. Chunking in 10-Minuten-Segmente bei Bedarf.",
    "Hostpoint-Website bleibt Haupt-Website. Hetzner NICHT fuer Haupt-Website verwenden.",
    "Workspace root path fixed: C:\\Users\\surov\\documents\\aza",
    "SICHERHEITS-ZIELBILD – HIN-nahe Schutzprinzipien als Benchmark fuer Browser-AZA: AZA ist NICHT HIN-zertifiziert und NICHT ISO-zertifiziert. Es handelt sich um ein Sicherheits-Zielbild / Benchmark / Architekturleitlinie, KEINE Marketingbehauptung. Folgende Prinzipien gelten als Orientierung: geschlossener Vertrauensraum, verifizierte digitale Identitaet (eID), Zwei-Faktor-Authentisierung (2FA), asymmetrische Verschluesselung, S/MIME-Verschluesselung, TLS-Transportverschluesselung, digitale Signatur, technische und organisatorische Massnahmen (TOM), ISMS nach ISO/IEC 27001 als Zielbild, EPD-/IdP-nahe Vertrauens- und Identitaetslogik als Orientierung. Browser-AZA ist Kern des Projekts und soll langfristig ein hohes Schutz- und Vertrauensniveau erreichen. Sicherheitsarchitektur orientiert sich an etablierten Schweizer Gesundheitswesen-Prinzipien.",
    "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."
  ],
  "auth_contract": {
    "api_token_env": "MEDWORK_API_TOKEN",
    "header_name": "X-API-Token",
    "important_endpoints": [
      "/license/status",
      "/api/project/status",
      "/v1/transcribe"
    ],
    "notes": [
      "Healthcheck und Dev Tools müssen MEDWORK_API_TOKEN verwenden.",
      "Token wird im Header X-API-Token gesendet.",
      "NICHT Authorization: Bearer verwenden.",
      "Keine Tokens loggen."
    ]
  },
  "project_phase_assessment": {
    "phase": "B1 Backend-Sprint – Serverseitige OpenAI-Architektur (Variante B)",
    "status_A": "Desktop-App ist weit fortgeschritten und grundsaetzlich benutzbar",
    "status_B": "ARCHITEKTURENTSCHEIDUNG: Variante B gewaehlt – OpenAI-Key nur serverseitig",
    "status_C": "WooCommerce/Stripe-Pfad laeuft parallel weiter (Hostpoint)",
    "status_D": "Hetzner-Backend wird jetzt ernsthaft als Server-Pfad aufgebaut",
    "status_E": "Arbeitsphase = Backend-Zielarchitektur + Produktisierung parallel"
  },
  "go_live_sprint": {
    "title": "B1 Backend-Sprint – Serverseitige OpenAI-Architektur (4 Wochen)",
    "goal": "AZA-Backend als OpenAI-Proxy verkaufsfaehig machen. Kein OpenAI-Key mehr beim Kunden.",
    "start": "2026-03-25",
    "target": "ca. 2026-04-22",
    "architekturentscheidung": "VARIANTE B verbindlich: Desktop-App → AZA-Backend → OpenAI. Key nur serverseitig.",
    "operative_plattform": "Hetzner (Backend/API/OpenAI-Proxy). Hostpoint bleibt fuer Website/WooCommerce.",
    "wochenplan": {
      "woche_1": "Backend Chat Proxy Endpoint (POST /v1/chat) + Auth + Rate Limiting",
      "woche_2": "Desktop-App umstellen: alle OpenAI-Calls ueber Backend statt direkt",
      "woche_3": "Hetzner Deploy: Docker/Caddy/HTTPS + Production-Env + Smoke-Tests",
      "woche_4": "E2E-Test Desktop→Backend→OpenAI + Kundenweg ohne OpenAI-Key + Go-Live-Freigabe"
    }
  },
  "priority_order": {
    "description": "B1 Backend-Sprint Prioritaeten – Variante B verbindlich",
    "1_hoechste": "Backend Chat Proxy Endpoint POST /v1/chat (Woche 1)",
    "2_hoch": "Desktop-App von direktem OpenAI auf Backend umstellen (Woche 2)",
    "3_mittel": "Hetzner Deploy: Docker/Caddy/HTTPS/Production-Env (Woche 3)",
    "4_hoch": "E2E-Test Desktop→Backend→OpenAI + Go-Live-Freigabe (Woche 4)",
    "5_parallel": "WooCommerce/Stripe/Kauf-Weg laeuft parallel weiter (Hostpoint)",
    "explizit_nachrangig": [
      "Update-Komfort / separater Auto-Updater",
      "Browser-AZA Web-App (nach Backend-Architektur)",
      "Grosse Refactors / Architektur-Spielereien die nicht direkt Variante B dienen"
    ],
    "hostpoint_vs_hetzner": "Hostpoint bleibt fuer Website/WooCommerce. Hetzner ist JETZT der Backend-Pfad fuer OpenAI-Proxy/API. Beides laeuft parallel, nicht gegeneinander."
  },
  "working_principles": {
    "description": "Verbindliche Arbeitsweise fuer die naechsten Chats",
    "rules": [
      "Root-cause-first statt blindem Nachpatchen",
      "Ein klarer Block nach dem anderen",
      "Keine 10 Baustellen gleichzeitig",
      "Reale installierte Builds staerker gewichten als Code-Behauptungen",
      "Nicht zu frueh 'fertig' sagen",
      "Desktop unterscheiden in: 1. Dev-Code, 2. neu gebauter Installer, 3. reales Verhalten im installierten Build"
    ]
  },
  "next_main_block": {
    "title": "B1-W1: Backend Chat Proxy Endpoint (POST /v1/chat)",
    "goal": "Neuen Endpunkt POST /v1/chat in backend_main.py erstellen. Desktop-App kann Chat-Anfragen ueber das Backend an OpenAI senden. OpenAI-Key liegt NUR serverseitig.",
    "status": "in_arbeit",
    "sprint_context": "Teil des B1 Backend-Sprints (Variante B). Grundstein fuer serverseitige OpenAI-Architektur.",
    "warum_dieser_block_zuerst": "Ohne /v1/chat kann die Desktop-App nicht von direkten OpenAI-Calls auf Backend-Calls umgestellt werden. Muster existiert bereits bei /v1/transcribe. Alles andere (Hetzner-Deploy, Key-Entfernung) haengt davon ab.",
    "scope": [
      "POST /v1/chat Endpoint in backend_main.py",
      "Auth via X-API-Token + X-Device-Id (bestehendes Muster)",
      "Request entgegennehmen: model, messages, temperature etc.",
      "Serverseitig OpenAI-Client mit OPENAI_API_KEY aus Umgebung",
      "Response an Desktop-App zurueckgeben",
      "Rate Limiting pro Token/Device",
      "Keine Secrets loggen, kein PHI in Logs"
    ],
    "prerequisite_done": [
      "/v1/transcribe existiert bereits als Muster (Backend→OpenAI)",
      "Auth-Contract (X-API-Token) ist etabliert",
      "Docker/Caddy Deployment-Stack existiert",
      "Aktivierungsschluessel-Bridge implementiert"
    ]
  },
  "customer_journey_analysis": {
    "date": "2026-03-24",
    "kauf": {
      "status": "offen",
      "detail": "WooCommerce-Doku komplett (WORDPRESS_GOLIVE.md), aber in WordPress NICHT konfiguriert. Waehrung USD, Land US, kein Stripe Gateway, kein Subscription Plugin, Demo-Produkte vorhanden.",
      "next": "WooCommerce gemaess WORDPRESS_GOLIVE.md konfigurieren (User-Aufgabe in WordPress-Admin)"
    },
    "download": {
      "status": "teilweise",
      "detail": "Download-Mechanik vorhanden (version.json, download.html). Fuer WooCommerce: Installer als Produkt-Download hochladen. URL-Inkonsistenz download vs downloads in publish-release.ps1.",
      "next": "Installer-EXE in WooCommerce-Produkt hochladen"
    },
    "installer": {
      "status": "funktional_fertig",
      "detail": "Inno Setup komplett, Build-Scripts funktionsfaehig. Kein Code-Signing (SmartScreen-Warnung bei Kunden).",
      "next": "Code-Signing-Zertifikat beschaffen (vor breiter Auslieferung)"
    },
    "aktivierung": {
      "status": "bridge_implementiert",
      "detail": "Kritischer Bruch behoben: Aktivierungsschluessel setzt jetzt Vollmodus. Erster Kundenweg: Entwickler generiert AZA-Key, sendet per E-Mail, Kunde gibt ein. DEMO_MAX_DICTATIONS=9999 entschaerft kurzfristig.",
      "next": "Fuer spaetere Automatisierung: Hetzner-Backend mit Stripe-Webhooks deployen"
    },
    "erster_start": {
      "status": "in_umbau_variante_b",
      "detail": "Funktional, aber OpenAI-API-Key ist groesste Kundenhuerde. VARIANTE B gewaehlt: Kein eigener Key mehr fuer Kunden. App spricht mit Backend.",
      "next": "B1 Backend-Sprint: POST /v1/chat Endpoint → Desktop-App umstellen → Hetzner Deploy → Kein Key-Setup mehr noetig"
    }
  },
  "first_customer_workflow": {
    "description": "Ziel-Kundenweg mit Variante B (nach B1 Backend-Sprint)",
    "steps": [
      "1. Kunde kauft ueber WooCommerce/Stripe auf aza-medwork.ch",
      "2. WooCommerce liefert Download-Link (E-Mail + Mein-Konto-Seite)",
      "3. Kunde laedt aza_desktop_setup.exe herunter und installiert",
      "4. App startet mit 21-Tage-Testphase (kein Key noetig)",
      "5. Aktivierung ueber AZA-Key oder Stripe-Webhook (spaeter automatisch)",
      "6. App laeuft im Vollmodus – KEIN OpenAI-Key noetig",
      "7. Alle KI-Funktionen laufen ueber AZA-Backend auf Hetzner",
      "8. OpenAI-Key liegt NUR auf dem Server, Kunde sieht ihn nie"
    ],
    "uebergangsloesung_aktuell": [
      "Bis B1 fertig: Kunde muss noch OpenAI-Key einrichten (groesste Huerde)",
      "Nach B1 Woche 1+2: Desktop-App nutzt Backend fuer Chat – kein Key mehr noetig",
      "Nach B1 Woche 3: Backend auf Hetzner deployed – produktionsbereit"
    ],
    "manual_steps_by_developer": [
      "Key generieren: python aza_activation.py 2027-03-31",
      "Key per E-Mail an Kunden senden",
      "Spaeter automatisieren via Hetzner-Backend + Stripe-Webhooks"
    ]
  },
  "open_focus_blocks": [
    {
      "id": "FB-A",
      "title": "Kauf-/Download-/Installationsweg sauber festziehen",
      "description": "WooCommerce / Stripe / Download / Installer / Aktivierung – End-to-End aus Kundensicht",
      "priority": "HOECHSTE"
    },
    {
      "id": "FB-B",
      "title": "Kritische Desktop-Restfehler nur gezielt und einzeln behandeln",
      "description": "Keine neuen Monsterpatches. Root-cause-first. Installierten Build hoeher gewichten als Code-Behauptungen.",
      "priority": "HOCH"
    },
    {
      "id": "FB-C",
      "title": "Windows-Kundenauslieferung absichern",
      "description": "Signing-Readiness vorbereitet. Produktives Signing vor Kundenauslieferung noch offen. Smart App Control / Reputation / Publisher-Konsistenz beachten.",
      "priority": "MITTEL"
    },
    {
      "id": "FB-D",
      "title": "Update-Verbesserungen bewusst nachgelagert",
      "description": "Erst nach stabilem Kauf-/Download-/Installationspfad. Kein aktueller Hauptblock.",
      "priority": "NACHGELAGERT"
    }
  ],
  "current_focus": {
    "title": "Kauf / Download / Installation / Aktivierung – erster echter Kundenweg End-to-End",
    "goal": "AZA Desktop als Subscription-Produkt (monatlich + Jahreslizenz) ueber aza-medwork.ch (Hostpoint WordPress + WooCommerce + Stripe) verkaufen. Der gesamte Weg von Kauf bis produktivem Grundbetrieb muss aus Kundensicht stabil sein. Bestehende Website NICHT beschaedigen.",
    "in_progress_items": [
      "Kauf-/Download-/Installationsweg End-to-End pruefen und festziehen",
      "WooCommerce-Produkt + Stripe-Integration sauber machen",
      "Installer-Datei als WooCommerce-Download hochladen",
      "Testkauf im Stripe-Testmodus (monatlich + jaehrlich)",
      "Download → Installation → Aktivierung → erster Start verifizieren",
      "Stripe auf Live-Modus umschalten",
      "Produktseite auf Home verlinken"
    ],
    "completed_items": [
      "Desktop-App als EXE gebaut",
      "Lokales Backend startet automatisch mit der Desktop-App",
      "Lokaler Desktop-Smoke-Test ist gruen",
      "Installer/Packaging mit Inno Setup gebaut",
      "Desktop Runtime Secret Provisioning eingefuehrt",
      "Default Opacity auf 1.0 korrigiert",
      "Praxiscomputer-Testpaket erstellt (Installer, Anleitung, Checkliste, Rueckmeldebogen)",
      "Update-Check gegen release/version.json verdrahtet",
      "APPDATA-Persistence-Fix: Benutzerdaten unter %APPDATA%\\AZA Desktop statt Program Files",
      "Release-Pipeline nach APPDATA-Fix erneut validiert (Build+Smoke+Installer gruen)",
      "Praxiscomputer-Testpaket mit neuem Installer aktualisiert",
      "AZA-Startseite/Launcher mit Modulauswahl und Auto-Open eingefuehrt",
      "Launcher auf 6 Module erweitert (KI, KG, Audio-Notizen, Uebersetzer, MedWork Chat, Praxis Chat)",
      "Woechentliches Login statt taeglich",
      "App-Ablaufdatum 30.04.2026 eingebaut",
      "Aktivierungsschluessel-System fuer Geraetesteuerung (aza_activation.py)",
      "Praxiscomputer-Testpaket auf neuen Stand aktualisiert (6 Module, Aktivierung, Wochenlogin)",
      "OpenAI-Key-Einrichtung professionalisiert: Setup-Helfer als Standardweg, Fallback auf Config-Datei",
      "Premium-UI: Launcher und Setup-Dialog im Medizinprodukt-Design, keine technischen Begriffe in Nutzerdialogen",
      "Uebersetzer-Modul: Tkinter-Threading-Bug behoben (eigener Tk-Mainloop im Hauptthread statt Thread)",
      "Audio-Notizen-Modul: identischer Fix (direkter Start im Hauptthread)",
      "Integrierter Systemstatus/Selbsttest: 12 Pruefpunkte, Diagnose-Kopieren, Praxiscomputer-Validierung",
      "Praxiscomputer-Testpaket: Systemstatus in Anleitung, Checkliste und Rueckmeldung nachgezogen",
      "Windows-Firewall-Fix: Installer legt minimale Regel (localhost:8000) an, Nutzerhinweis bei Backend-Fehler",
      "Release-Pipeline erneut validiert (Build+Smoke+Installer gruen, Firewall-Regel im ISS, Publish-Bundle sauber)",
      "Praxiscomputer-Testpaket auf finalen Stand aktualisiert (Installer, paketinfo, Checkliste, Rueckmeldung)",
      "Firewall-Regel-Pruefung im integrierten Systemstatus (check_firewall_rule in aza_firewall.py)",
      "Systemstatus Backend-Erkennung gefixt: Fallback auf lokale URL (127.0.0.1:8000) wie desktop_backend_autostart",
      "Systemstatus Lizenz-Fix: X-Device-Id Header mitsenden (fehlte, daher device_enforcement=denied)",
      "Systemstatus Aktivierung-Fix: check_app_access() gibt Tuple zurueck, nicht Dict",
      "Systemstatus Lizenz-Token-Pfad-Fix: Im frozen Build _internal statt exe_dir durchsuchen (wie basis14.py)",
      "Hauptfenster UX-Feinschliff: Tooltips fuer alle Toolbar-Buttons, Backend-Status entechnisiert, Beschriftungen professionalisiert",
      "Launcher-Icons: Canvas-gezeichnete Vektor-Icons (Sparkle, Clipboard, Mikrofon, Dokumente, Netzwerk, Chat)",
      "Kauf-zu-Download-Flow: Success-Seite, Landing-Page mit Pricing/Checkout, Download-Seite, reale Domain-URLs",
      "Live-Deployment-Readiness: CORS-Middleware, Dockerfile backend_main:app, Caddyfile Static+API, Stripe-URLs produktionsreif, PRODUCTION_CONFIG.md",
      "Deploy-Stack lokal verifiziert: 7/7 Routen gruen (Health, Download-API, Success, Cancel, Landing, Download-Page, version.json), CORS-Preflight OK",
      "v1.0.0 Produktdefinition erstellt (deploy/PRODUCT_V1.md)",
      "Version auf 1.0.0 gesetzt (aza_version.py, version.json)",
      "Hard-Expiry auf 2027-03-31 verlaengert",
      "Changelog und Installationsanleitung erstellt",
      "v1.0.0 Installer gebaut und getestet (Build+Smoke+Installer gruen)",
      "Signing-Readiness: sign_release.ps1 erstellt, Release-Pipeline mit optionalem Signing-Schritt, Artefakt-Report mit Signatur-Status, SIGNING_READINESS.md mit Checkliste und Zertifikats-Empfehlung",
      "Publisher-/Namenskonsistenz geprueft: 3 Namensformen (AZA MedWork=Firma, AZA Desktop=Produkt, AZA Medical AI Assistant=interner Projektname). Nur AZA MedWork ist signing-kritisch. Vor Zertifikatskauf HR-Name pruefen und AppPublisher abstimmen.",
      "WooCommerce-Produkttexte vorbereitet (deploy/WOOCOMMERCE_PRODUCT.md)",
      "Infrastruktur-Analyse: Hostpoint WordPress+Kadence+WooCommerce online (deploy/INFRA_STATUS.md)",
      "Autotext Root-Cause-Fix: _is_admin NameError behoben, Listener auf bewaehrten Stand (Kopie 13) zurueckgesetzt",
      "Deinstallation: Inno Setup fragt bei Deinstallation ob Benutzerdaten geloescht werden sollen (Standard: Nein, Daten bleiben erhalten)",
      "Signaturlogik: load_signature_name() faellt automatisch auf Profilname zurueck wenn kein expliziter Signaturname gesetzt ist",
      "Rechtsklick-Haekchen im Minifenster: gleiche Option wie im Hauptfenster, synchronisiert",
      "Kommentare-Fenster: Grundstruktur implementiert (TEILWEISE – Detailmodus und Live-Aktualisierung noch offen)",
      "Kommentarlogik quellenstreng: Inhaltsquelle und Originallink sauber getrennt. Inhaltsquelle (Detailinhalt): DocCheck Flexikon Standard, PharmaWiki Fallback, benutzerwaehlbar + persistent. Originallink: CH=Compendium, AT=BASG, DE=BfArM unveraendert. Kuratierte Fakten als Offline-Fallback. Inline nur Indikation. Therapien separat.",
      "Signatur-UI in Einstellungen: Haekchen 'Profilname verwenden' + Feld fuer abweichenden Signaturnamen",
      "Briefstil-Lernen: DOCX-Upload, GPT-Stilanalyse, persistente Stilprofile, Integration vor Briefgenerierung (TEILWEISE – Erweiterungen offen)",
      "Persistenz-Patch: KI-Einwilligung beim Erststart, Profil+Code persistent, Kommentare-Toggle, Einstellungen gruppiert, Deinstallations-Frage erweitert",
      "Uebersetzer-Stabilitaetsfix: Root Cause Tkinter-in-Thread behoben, jetzt Toplevel-Embedded-Modus statt Threading",
      "Vordefinierte Briefprofile: KISIM Bericht + Klinischer Bericht als auswaehlbare Berichtsprofile im Brief-Fenster",
      "AZA Clean Uninstall/Reset Tool: PowerShell-Script fuer saubere Deinstallation/Reset ohne Neustart (tools/aza_clean_uninstall.ps1, AZA_Deinstallieren.bat)",
      "Briefstil-Profile Fix+Nachschaerfung: KISIM/Klinischer Bericht als feste Systemprofile immer sichtbar, praezise medizinische Prompt-Definitionen, vereinheitlichtes Stilprofil-System (Haekchen+Dropdown+Standard fuer Arztbriefe) direkt im Brief-UI",
      "Nachschaerfungs-Patch FIX-02: Stilprofil-Dialog nur Verwaltung (keine aktive Auswahl mehr im Dialog, nur Status+Lernen+Loeschen), Kommentare-Fenster oeffnet automatisch nach KG-Erstellung wenn Haekchen aktiv, Logo-Trennung (Wassertropfen=EXE/Desktop/Installer-Icon, originales Logo=internes Branding unten links)"
    ],
    "non_goals_right_now": [
      "Update-Komfort / separater Updater (bewusst nachgelagert, erst nach stabilem Kundenweg)",
      "Browser-AZA Web-App (Step 22, nach Go-Live, aber verbindlich geplant)",
      "Admin-Konsole",
      "Weitere Desktop-UX-Aenderungen (keine Feature-Patches, nur Blocker-Fixes)",
      "Hetzner-Server konfigurieren (erst wenn Browser-AZA dran ist)",
      "Internationalisierung / Mehrsprachigkeit / Laender- und Quellenprofile (erst nach DACH-Stabilitaet und Produkterfolg)",
      "Monsterpatches oder breite Umbauaktionen"
    ],
    "architecture": {
      "hostpoint": "Oeffentliche Website, Marketing, WordPress, Kadence, WooCommerce, Stripe-Checkout, Download-Auslieferung",
      "hetzner": "AZA-Backend/API/OpenAI-Proxy (JETZT AKTIV). Docker/Caddy/HTTPS. Subdomain api.aza-medwork.ch oder app.aza-medwork.ch.",
      "variante_b": "VERBINDLICH: Desktop-App → AZA-Backend (Hetzner) → OpenAI. Key nur serverseitig. Kein OpenAI-Key beim Kunden.",
      "rule": "Hostpoint bleibt Haupt-Website. Hetzner ist der Backend-Pfad. Keine DNS-Aenderungen ohne klare Pruefung."
    }
  },
  "step_22_deliverables": [
    "browser_aza_mvp_spec.md",
    "Browser-Seite mit Upload-Bereich",
    "Fachrichtungsauswahl vor Upload",
    "Request-Flow an /v1/transcribe unter Beibehaltung von X-API-Token",
    "Ergebnisansicht fuer Transkript",
    "Copy-Button fuer Transkript",
    "Support/Privacy/Terms sichtbar"
  ],
  "step_22_acceptance_checks": [
    "Seite laedt im Browser",
    "Fachrichtung kann ausgewaehlt werden",
    "Audio kann hochgeladen werden",
    "Backend /v1/transcribe antwortet erfolgreich",
    "Transkript wird sichtbar angezeigt",
    "Copy-Button funktioniert",
    "Keine Secrets/Tokens im UI oder Log"
  ],
  "phases": [
    {
      "id": 1,
      "title": "Core Desktop + Backend",
      "items": [
        { "title": "Step 13: Smoke Suite PASS", "status": "done" },
        { "title": "Step 14: Docker/Compose Smoke PASS", "status": "done" }
      ]
    },
    {
      "id": 2,
      "title": "Live Congress Search (PARKED)",
      "items": [
        { "title": "CSE JSON API Zugriff stabil", "status": "paused" },
        { "title": "Backend Live-Suche in Kongress-UI", "status": "paused" },
        { "title": "Filter/UX News & Kongresse", "status": "paused" }
      ],
      "why_paused": [
        "Google CSE: 403 not authorized / Access/Billing unklar",
        "DDG scraping volatil (Bot block / 0 results / Response-Laenge sehr kurz)"
      ]
    },
    {
      "id": 3,
      "title": "Go-Live / Productization",
      "items": [
        { "title": "Step 15: Caddy/HTTPS + Reverse Proxy Vorbereitung", "status": "done" },
        { "title": "Step 17: Desktop-App + Installer + Kauf-/Download-Flow (Code-komplett)", "status": "done" },
        { "title": "Step 16: Go-Live extern (VPS, DNS, Stripe, Secrets, Deploy)", "status": "in_progress" },
        { "title": "Step 22: Browserbasiertes AZA (MVP) - nach Go-Live", "status": "open" },
        { "title": "Step 18: Website/Landing + Download-Page + Rechnungen/Belege (Billing/Invoice Flow)", "status": "done" },
        { "title": "Step 19: Support/Telemetry minimal (ohne PHI), Crashlogs optional", "status": "done" },
        { "title": "Step 20: Final Security pass (rate limit, request caps, audit)", "status": "done" }
      ]
    },
    {
      "id": 4,
      "title": "Sell-Ready Pack",
      "items": [
        { "title": "Step 21: Steps/Status/Roadmap/To-Dos konsolidiert", "status": "done" },
        { "title": "Step 23: Billing & Legal sell-ready", "status": "open" },
        { "title": "Step 24: Ops/Monitoring/Runbook final", "status": "open" },
        { "title": "Step 25: Go-Live Cutover", "status": "open" }
      ]
    }
  ],
  "next_actions": [
    "ERLEDIGT: Aktivierungsschluessel-Bridge implementiert (AZA-Key → Vollmodus)",
    "ERLEDIGT: Trial-Dialog zeigt Aktivierungsstatus klar beim ersten Start",
    "ERLEDIGT: Aktivierungsfenster-UX gefixt (540x520, Resize-Griff, DPI-robust)",
    "ENTSCHEIDUNG: Variante B gewaehlt – OpenAI-Key nur serverseitig (2026-03-25)",
    ">>> AKTUELLER BLOCK: B1-W1 Backend Chat Proxy Endpoint <<<",
    "B1-W1-1: POST /v1/chat Endpoint in backend_main.py erstellen",
    "B1-W1-2: Auth via X-API-Token + X-Device-Id (bestehendes Muster von /v1/transcribe)",
    "B1-W1-3: OpenAI chat.completions.create serverseitig ausfuehren",
    "B1-W1-4: Rate Limiting pro Token/Device",
    "B1-W1-5: Lokaler Test mit Docker",
    "DANACH B1-W2: Desktop-App call_chat_completion() auf Backend umstellen",
    "DANACH B1-W3: Hetzner Deploy (Docker/Caddy/HTTPS)",
    "DANACH B1-W4: E2E-Test + Go-Live-Freigabe Backend-Pfad",
    "PARALLEL: WooCommerce/Stripe-Konfiguration (Hostpoint) laeuft weiter"
  ],
  "todos": [
    {
      "id": "A-01",
      "priority": "SOFORT",
      "status": "in Arbeit",
      "group": "A – Go-Live extern",
      "title": "Hostpoint-Website stabil lassen",
      "description": "Keine riskanten Domain-/DNS-Experimente. Bestehende WordPress/Kadence-Seite bleibt Haupt-Website auf Hostpoint.",
      "area": ["ops", "infra"]
    },
    {
      "id": "A-02",
      "priority": "SOFORT",
      "status": "offen",
      "group": "A – Go-Live extern",
      "title": "Stripe Live-Setup sauber fertigstellen",
      "description": "Stripe-Keys (Live) in WooCommerce eintragen, Webhooks konfigurieren, Zahlungsmethoden aktivieren.",
      "area": ["billing", "ops"]
    },
    {
      "id": "A-03",
      "priority": "SOFORT",
      "status": "offen",
      "group": "A – Go-Live extern",
      "title": "Live-Secrets pruefen",
      "description": "deploy/.env: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, MEDWORK_API_TOKEN. Keine Secrets in Code oder Logs.",
      "area": ["security", "ops"]
    },
    {
      "id": "A-04",
      "priority": "SOFORT",
      "status": "offen",
      "group": "A – Go-Live extern",
      "title": "Deploy-Stack finalisieren",
      "description": "Docker Compose, Caddy, Backend auf Hetzner fuer spaeteren App-Betrieb. Haupt-Website bleibt auf Hostpoint.",
      "area": ["ops", "infra"]
    },
    {
      "id": "A-05",
      "priority": "SOFORT",
      "status": "offen",
      "group": "A – Go-Live extern",
      "title": "Testkauf Ende-zu-Ende durchfuehren",
      "description": "Stripe-Testmodus: Subscription monatlich + jaehrlich kaufen, Download-Link pruefen, E-Mail pruefen, Mein-Konto pruefen.",
      "area": ["product", "billing"]
    },
    {
      "id": "A-06",
      "priority": "SOFORT",
      "status": "offen",
      "group": "A – Go-Live extern",
      "title": "Download-/Lizenzfluss live validieren",
      "description": "Installer herunterladen, installieren, Aktivierung, Lizenzpruefung, Backend-Anbindung – alles End-to-End.",
      "area": ["product", "release"]
    },
    {
      "id": "B-01",
      "priority": "HOCH",
      "status": "offen",
      "group": "B – Verkauf / Subscription",
      "title": "Subscription in Website/Checkout konsistent abbilden",
      "description": "Monatlich CHF 89 + Jahreslizenz CHF 886 (17% guenstiger). WooCommerce Subscriptions Plugin oder Stripe Billing. Pricing auf Produktseite, Checkout, E-Mails konsistent.",
      "area": ["product", "billing"]
    },
    {
      "id": "B-02",
      "priority": "HOCH",
      "status": "erledigt",
      "group": "B – Verkauf / Subscription",
      "title": "Pricing-Texte und Lizenztexte festziehen",
      "description": "deploy/PRODUCT_V1.md und deploy/WOOCOMMERCE_PRODUCT.md auf Subscription-Modell aktualisiert. Nicht mehr aendern, sondern verwenden.",
      "area": ["product", "legal"]
    },
    {
      "id": "B-03",
      "priority": "HOCH",
      "status": "offen",
      "group": "B – Verkauf / Subscription",
      "title": "Billing / Invoices / VAT / Stripe-Rechnungslogik",
      "description": "Rechnungen mit CHF, MwSt-Hinweis, korrekte Absenderadresse. Stripe Invoice-Einstellungen. AGB mit Subscription-Hinweisen.",
      "area": ["billing", "legal"]
    },
    {
      "id": "C-01",
      "priority": "HOCH",
      "status": "erledigt",
      "group": "C – Download-Produkt",
      "title": "Stabile Basisversion als erste verkaufbare Version definieren",
      "description": "v1.0.0 definiert, Installer gebaut und getestet. 6 Module, Systemstatus, Launcher, Firewall-Fix.",
      "area": ["release", "desktop"]
    },
    {
      "id": "C-02",
      "priority": "HOCH",
      "status": "erledigt",
      "group": "C – Download-Produkt",
      "title": "Release-/Update-Strategie sauber machen",
      "description": "Versionierung (v1.0.x / v1.x / v2.0), Update-Lieferung ueber WooCommerce-Account, Changelog als Website-Seite.",
      "area": ["release", "product"]
    },
    {
      "id": "C-03",
      "priority": "MITTEL",
      "status": "offen",
      "group": "C – Download-Produkt",
      "title": "Signierte Downloads / Versionierung / Changelog vervollstaendigen",
      "description": "Code-Signing nach erstem Live-Kauf. Changelog-Seite auf Website. version.json mit korrekter Download-URL.",
      "area": ["release", "security"]
    },
    {
      "id": "D-01",
      "priority": "HOCH",
      "status": "offen",
      "group": "D – Browser-AZA",
      "title": "Nach Go-Live Step 22 verbindlich starten",
      "description": "Browser-AZA ist Kern des Projekts. Wird nach Go-Live sofort gestartet, nicht optional.",
      "area": ["web", "product"]
    },
    {
      "id": "D-02",
      "priority": "HOCH",
      "status": "offen",
      "group": "D – Browser-AZA",
      "title": "Browser-AZA MVP nach Spec umsetzen",
      "description": "browser_aza_mvp_spec.md: Upload-Bereich, Fachrichtungsauswahl, /v1/transcribe, Ergebnisansicht, Copy-Button.",
      "area": ["web", "frontend", "backend"]
    },
    {
      "id": "D-03",
      "priority": "HOCH",
      "status": "offen",
      "group": "D – Browser-AZA",
      "title": "Minimaler Zugangsschutz ohne Breaking Change",
      "description": "Auth fuer Browser-AZA, ohne /license/status oder X-API-Token Contract zu brechen.",
      "area": ["security", "backend"]
    },
    {
      "id": "D-04",
      "priority": "HOCH",
      "status": "offen",
      "group": "D – Browser-AZA",
      "title": "Upload-Flow / Result-Flow / Specialty-Auswahl bauen",
      "description": "Audio-Upload, Fachrichtungsauswahl, Transkript-Anzeige, Copy-Button. Keine PHI in Logs.",
      "area": ["web", "frontend"]
    },
    {
      "id": "E-01",
      "priority": "SPAETER",
      "status": "offen",
      "group": "E – Ops / Spaeter",
      "title": "Observability",
      "description": "Logging, Metriken, Alerting. Kein PHI in Logs. Uptime-Monitoring.",
      "area": ["ops"]
    },
    {
      "id": "E-02",
      "priority": "SPAETER",
      "status": "offen",
      "group": "E – Ops / Spaeter",
      "title": "Admin-/Support-Tools",
      "description": "Admin-Panel, Support-Workflows, Nutzer-Management.",
      "area": ["ops", "product"]
    },
    {
      "id": "E-03",
      "priority": "SPAETER",
      "status": "offen",
      "group": "E – Ops / Spaeter",
      "title": "Runbook final",
      "description": "Backups, Log-Rotation, Incident-Playbook, Token-Rotation.",
      "area": ["ops"]
    },
    {
      "id": "E-04",
      "priority": "SPAETER",
      "status": "offen",
      "group": "E – Ops / Spaeter",
      "title": "Go-Live Cutover final",
      "description": "Finale Checkliste, Rollback-Plan, DNS-Cutover fuer Browser-AZA (app.aza-medwork.ch).",
      "area": ["ops", "product"]
    }
  ]
}