277 lines
12 KiB
Markdown
277 lines
12 KiB
Markdown
# 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-25)
|
||
|
||
**Phase:** 4-Week Go-Live Sprint (Goal: ready for sale by approx. April 22, 2026)
|
||
|
||
**Honest Assessment:**
|
||
- Desktop app is far advanced and fundamentally usable
|
||
- There are still productization blocks, but no longer in idea phase
|
||
- Work phase = 4-week sprint with clear sales target
|
||
|
||
## 4-WEEK GO-LIVE SPRINT
|
||
|
||
| Week | Approx. Dates | Focus |
|
||
|------|--------------|-------|
|
||
| **1** | Mar 25 – Apr 01 | WooCommerce / Stripe / Product / Checkout / Download / Test Purchase |
|
||
| **2** | Apr 02 – Apr 08 | Installer / Activation / First Start – make clean |
|
||
| **3** | Apr 09 – Apr 15 | Product page / Images / Copy / Email flow / Signing decision |
|
||
| **4** | Apr 16 – Apr 22 | End-to-End test / final blockers / Go-Live approval |
|
||
|
||
## CURRENT PRIORITY ORDER (4-Week Sprint)
|
||
|
||
1. **Purchase / WooCommerce / Stripe / Checkout / Download** (Week 1)
|
||
2. **Installer / Activation / First Start** (Week 2)
|
||
3. **Product page / Images / Copy / Signing decision** (Week 3)
|
||
4. **End-to-End test purchase / Go-Live approval** (Week 4)
|
||
5. Critical desktop blockers ONLY targeted if they actually prevent customer journey
|
||
|
||
**EXPLICITLY DEFERRED / NOT NOW:**
|
||
- Update comfort / separate auto-updater
|
||
- Large web app / backend expansion
|
||
- Hetzner as required block for this Go-Live
|
||
- Large refactors / architecture experiments
|
||
|
||
**HOSTPOINT vs. HETZNER:**
|
||
- Hostpoint remains the primary operational path for this 4-week sales launch
|
||
- Hetzner is NOT the critical main block for this Go-Live
|
||
- Do not open a new Hetzner construction site if it delays the sales start
|
||
|
||
## NEXT MAIN BLOCK (WEEK 1)
|
||
|
||
**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
|
||
- Activation window UX: 540x520, resize grip, DPI-robust
|
||
|
||
**Week 1 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-25)
|
||
|
||
| 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).
|