aza/backup backup backup backup/backup 24.2.26 - Kopie (61)/project_handover.md

AZA - Master Handover / Operational Runbook

Working Mode Rules

• User does not tinker or manually edit files.
• Always provide 1:1 Composer patches (usually Opus).
• One step at a time.

CURRENT PROJECT PHASE (2026-03-24)

Phase: Pre-Go-Live / Produktisierung / letzte technische Haertung

Honest Assessment:

• A: Desktop app is far advanced and fundamentally usable
• B: There are still individual critical remaining issues / productization blocks
• C: We are NOT in the idea phase anymore
• D: We are also NOT yet at "roll out broadly without final checks"
• E: Work phase = Pre-Go-Live / Productization / final technical hardening

CURRENT PRIORITY ORDER

1. Purchase / Download / Installation / Activation – make the first real customer journey stable
2. Remaining critical bugs – fix targeted, one at a time
3. Windows Signing / Customer delivery – secure before customer release
4. Update improvements / Update comfort – DEFERRED, NOT current priority

IMPORTANT:

• Update comfort is NOT the top priority right now
• No separate updater as current main block
• First, the real customer journey must be stable: Purchase → Download → Installer → Activation → First Start → Productive Basic Operation

NEXT MAIN BLOCK

WooCommerce basic configuration in WordPress admin (7 steps) + test purchase.

Desktop prerequisites done (2026-03-24):

• Activation key bridge: valid AZA key → license_mode=active (full mode)
• Trial dialog: user sees activation status clearly on first start (trial active / days remaining / key entry)
• Activation window UX: 540x520, resize grip, DPI-robust

Goal: Execute 7 admin steps in WordPress/WooCommerce:

1. General settings: country=Switzerland, currency=CHF
2. Create missing pages: Checkout + My Account
3. Install plugins: WooCommerce Stripe Gateway + Flexible Subscriptions
4. Configure Stripe test mode (pk_test_ + sk_test_)
5. Delete 9 demo products
6. Create AZA product (Subscription, monthly + yearly, installer as download)
7. Configure email sender (AZA MedWork / info@aza-medwork.ch) → Then test purchase in Stripe test mode possible.

First customer workflow (manual, before Hetzner deploy):

1. Customer buys via WooCommerce/Stripe
2. WooCommerce delivers download link (email + My Account)
3. Customer installs → trial dialog appears (21 days, key entry possible)
4. Developer generates AZA key: python aza_activation.py 2027-03-31
5. Key sent via email → customer enters it → full mode

Blocker Rule: If open desktop blockers actually prevent the customer journey, they may be fixed beforehand – but only as targeted blocker fixes, not as a new wave of construction sites.

CUSTOMER JOURNEY ANALYSIS (2026-03-24)

Step	Status	Detail
Purchase (WooCommerce)	IN PROGRESS	Docs ready, 7 admin steps in WordPress admin to execute
Download	PARTIAL	Mechanism exists, WooCommerce upload missing (part of step 6)
Installer	FUNCTIONALLY COMPLETE	No code signing (SmartScreen warning)
Activation	BRIDGE + TRIAL DIALOG	AZA key sets full mode, trial dialog shows status
First Start	PARTIAL	OpenAI key is biggest customer hurdle

OPEN FOCUS BLOCKS

Priority	Block	Description
HIGHEST	FB-A: Configure WooCommerce	WordPress admin: currency CHF, Stripe, Subscription Plugin, AZA product, test purchase
HIGH	FB-B: Critical Bugs	Only targeted, one at a time. Root-cause-first. No monster patches.
MEDIUM	FB-C: Signing	Signing readiness prepared. Productive signing still open.
DEFERRED	FB-D: Update Comfort	Only after stable customer journey. Not current main block.

PRODUCT NAME – CURRENT DIRECTION

Current favorite: AZA Office

Preferred long form:

• AZA Office – Ihr medizinischer KI-Arbeitsplatz fuer die Praxis

Second good variant:

• AZA Office – Die KI-Assistenz fuer medizinische Dokumentation

Status: Current preferred naming direction. Not yet legally/brand-strategically finalized. Use for WooCommerce/website/download/Go-Live/product presentation.

Earlier shortlist (AZA Desktop): Documented in project_roadmap.json and project_plan.json. Superseded by AZA Office.

WORKING PRINCIPLES FOR NEXT CHATS

• Root-cause-first instead of blind patching
• One clear block at a time
• No 10 construction sites simultaneously
• Weight real installed builds higher than code assertions
• Don't declare "done" too early
• Distinguish Desktop into:
  1. Dev code
  2. Newly built installer
  3. Real behavior in installed build

Key Commands

Local start:

cd "C:\Users\surov\Documents\AZA\backup 24.2.26"
powershell -ExecutionPolicy Bypass -File .\deploy\local_reset_and_start.ps1

Tests:

powershell -ExecutionPolicy Bypass -File .\deploy\authorized_status.ps1
powershell -ExecutionPolicy Bypass -File .\deploy\smoke_suite.ps1
powershell -ExecutionPolicy Bypass -File .\deploy\docker_smoke.ps1

Desktop UX Block (2026-03-18)

• Benutzerdaten bei Deinstallation erhalten (Inno Setup, Standard: Nein)
• Signatur-UI: Haekchen "Profilname verwenden" + abweichender Signaturname in Einstellungen
• Rechtsklick-Haekchen im Minifenster (synchronisiert)
• Kommentare-Fenster (TEILWEISE: Grundstruktur, Detailmodus + Live-Update offen)
• Briefstil-Lernen (DOCX-Upload, Stilprofil-Analyse, Profilauswahl, Integration)
• Briefstil-Profile Fix: KISIM/Klinisch als feste Systemprofile, vereinheitlichtes Stilprofil-UI im Brief-Bereich
• Autotext Root-Cause-Fix (_is_admin NameError, Listener-Revert)
• Persistenz-Patch: Erststart-Consent, Profil+Code, Kommentare-Toggle, Einstellungs-Gruppierung
• Uebersetzer-Stabilitaetsfix: Toplevel-Embedded statt Tkinter-in-Thread
• Briefprofile: KISIM Bericht + Klinischer Bericht als vordefinierte Profile

AZA Clean Uninstall / Reset Tool

Per Doppelklick: AZA_Deinstallieren.bat

Per PowerShell:

powershell -ExecutionPolicy Bypass -File .\tools\aza_clean_uninstall.ps1

• Modus 1: Nur App entfernen, Benutzerdaten behalten
• Modus 2: Vollstaendig zuruecksetzen (App + Benutzerdaten)
• Kein Neustart noetig (Standardfall)
• Danach direkt Neuinstallation moeglich

Do-Not-Break Rules

1. Do not change existing API response formats (especially /license/status).
2. Do not modify auth/security mechanisms.
3. Do not log or print secrets/tokens/keys.
4. Signature fallback: profile name used when no explicit signature set.
5. User data in %APPDATA%\AZA Desktop NOT deleted on uninstall by default.
6. Style learning from old letters: only style/structure, NEVER copy patient data or old content.

Correction Patch (FIX-01) – 2026-03-19

1. Translator label: "Fachuebersetzer" renamed to "Uebersetzer" everywhere
2. Comments window: auto-open checkbox (persistent), live-update on KG change, clickable diagnosis headings with detail popups
3. Correction window: scrollbar for saved corrections list
4. Style profile live application: brief regenerated immediately on profile change/toggle
5. "Profil anwenden" button in style profile management dialog
6. KG creation writes directly to main window (no popup)
7. Persistence: dokumente_collapsed now properly saved/loaded
8. Main window centering: robust delayed centering after widget build via self.after()

FIX-02 Nachschaerfungs-Patch (2026-03-19)

1. Style profile dialog: now management-only (status display, learn, delete). Active selection exclusively in brief window.
2. Comments window: auto-opens after KG creation when checkbox is active (not just refreshes existing window).
3. Logo separation: Wassertropfen (logo.ico) for EXE/desktop/installer/title bar icon. Original logo (logo.png) for internal branding (bottom-left).

Files: basis14.py, aza_text_windows_mixin.py, aza_desktop.spec, logo.png, logo.ico

FIX-09/10/11 Quellenstrenge Kommentarlogik – Inhaltsquelle / Originallink Trennung (2026-03-22)

Root Cause (FIX-09): LLM generated medication info purely from model knowledge. Root Cause (FIX-10): PharmaWiki regex wrong (used h2/h3 instead of span#subtitle). Compendium.ch is SPA (not scrapable). Root Cause (FIX-11): Content source and external link were mixed in one dropdown/dict.

Fix (FIX-11): Clean separation of content source and external link:

CONTENT SOURCE (what is shown in detail window):

• _fetch_doccheck_info(med_name): DocCheck Flexikon (default) – server-rendered, h2/h3 headings
• _fetch_pharmawiki_info(med_name): PharmaWiki (fallback) – span#subtitle headings
• User-selectable via "Inhaltsquelle:" dropdown, persistent in med_content_quelle
• New dict _MED_CONTENT_QUELLEN (DocCheck, PharmaWiki)
• Curated _MEDICATION_FACTS as offline fallback

EXTERNAL LINK ("Originalquelle oeffnen" button):

• CH = Compendium, AT = BASG, DE = BfArM – UNCHANGED
• Still via _MED_QUELLEN / medikament_quelle – NOT modified

Therapies/procedures: separate handling via DocCheck/PharmaWiki (unchanged). Candidate logic (Dermowarte→Dermovate etc.): untouched.

Files: basis14.py

ARCH-MED: Medication Source Architecture (2026-03-22)

Architecture (implemented):

1. Detect medication in KG text (existing tagging + validation)
2. Fetch content from DocCheck Flexikon (default) or PharmaWiki (user choice/fallback)
3. Inject source text into LLM prompt (strict: only use provided data)
4. Curated facts list as offline fallback
5. External link always country-based (CH/AT/DE)
6. Omit anything not from the source

Coverage: All medications available on DocCheck Flexikon + PharmaWiki.

Next steps:

1. Caching strategy (cache fetched content locally)
2. Robustness against HTML structure changes
3. Long-term: Compendium API / HCI Solutions data license evaluation

Later market profiles (DE: BfArM, AT: BASG) separately.

Zukunftsblock – Internationalisierung / Laender- und Quellenprofile (GEPARKT)

Status: Zukunftsthema – NICHT fuer jetzt. Erst nach DACH-Stabilitaet und Produkterfolg.

Voraussetzung: DACH (CH/DE/AT) stabil, Go-Live gesichert, Produkt erfolgreich.

Zielbild:

• UI/Sprache, Medikamenten-/Diagnose-/Therapiequellen pro Markt anpassbar
• Profil-Felder: app_language, market_region, med_source_profile, dx_source_profile, therapy_source_profile
• Manueller Override durch Benutzer/Praxis
• Nicht hart nach Herkunftsland schalten – saubere Profil-Logik
• Handelsnamen/Zulassungen/Fachinfos sind laenderspezifisch → Quellenprofile pro Markt

Kein aktueller Implementierungsblock. Erst nach Go-Live und DACH-Erfolg relevant.

Windows Code-Signing / Smart App Control Readiness (2026-03-23)

Problem: Windows Smart App Control blockiert unsignierte Apps bei Kunden.

Status: Signing-Readiness vorbereitet, noch NICHT produktiv aktiviert.

Vorbereitet:

• sign_release.ps1 – signiert EXE + DLLs/PYDs + Installer (DryRun-Modus verfuegbar)
• build_and_test_release.ps1 – Signing-Schritt integriert (optional, graceful skip)
• build_release_artifacts.ps1 – Artefakt-Report mit Signatur-Status
• SIGNING_READINESS.md – Vollstaendige Dokumentation

Signing-Reihenfolge: DLLs/PYDs → EXE → Installer-Build → Installer signieren → Artefakt-Report

Vor Kundenauslieferung noch offen:

1. EV Code-Signing-Zertifikat beschaffen
2. signtool.exe installieren (Windows SDK)
3. Publisher-Name abstimmen (Zertifikat ↔ AppPublisher ↔ Handelsregister)
4. Produktiver Signierlauf + Test auf Windows-PC mit Smart App Control

Publisher-/Namenskonsistenz (Analyse 2026-03-23):

3 Namensformen im Projekt – beabsichtigt, keine Inkonsistenz:

• AZA MedWork = Firma/Publisher → SIGNING-KRITISCH (Installer, Legal, Consent, E-Mail-Absender)
• AZA Desktop = Produktname → konsistent, kein Handlungsbedarf
• AZA Medical AI Assistant = interner Projektname → nicht signing-relevant

Vor Zertifikatskauf: HR-Name pruefen, AppPublisher auf Zertifikats-Subject abstimmen. Falls HR-Name abweicht: alle signing-relevanten Stellen gemeinsam anpassen (Liste in handover.md). Nach Festlegung: Publisher-Name NICHT mehr wechseln (SmartScreen-Reputation).