# 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-30)

**Phase:** Stripe/License Live Path PROVEN + Admin Control Panel v2 LIVE – Next Block: WooCommerce/Production Sales Path

**STATUS: TECHNICAL FOUNDATION FULLY ESTABLISHED (2026-03-30)**

**1. Stripe/License Live Path PROVEN:**
- Complete license lifecycle technically proven: Purchase → License active → Cancel/Refund → License canceled → Desktop test mode
- Real live test purchase executed and cleanly neutralized
- Desktop correctly respects canceled status and falls back to test mode
- B1-W1 through B1-W5 all successfully completed
- Three bugs patched in `stripe_routes.py` (COALESCE fix, cancel_at_period_end, sync_subscription)

**2. Admin Monitor v1 + Control Panel v2 LIVE:**
- 8 internal admin endpoints, protected via X-Admin-Token / AZA_ADMIN_TOKEN
- v1: system_status, licenses_overview, backup_status, billing_overview
- v2: license_customer_map, revenue_overview, alerts, dashboard_summary
- Verified: without token → 401, wrong token → 401, correct token → data

**3. Backup/Storage Monitor ACTIVE:**
- Daily backup script configured (/root/aza-backups/backup_aza.sh, cron)
- /host_backups read-only mounted in container
- backup_status correctly detects backups
- ~137 GB free, ~4-5% used – no acute storage pressure

**4. Solved Root Causes / Lessons Learned (2026-03-27 – 2026-03-30):**
- Sandbox and live must be strictly separated
- missing_lookup_key resolved with _lookup_key_from_price fallback
- Live context in container verified with sk_live_
- license_debug initially wrong due to old active sandbox row + new canceled live row without customer_email
- Operative hotfix: DB backup created, canceled row linked with customer_email, old incorrect active record removed

**Hetzner Backend is LIVE (2026-03-26)**
- Production API path: `https://api.aza-medwork.ch`
- DNS: `api.aza-medwork.ch` → `178.104.51.177`
- Repo on Hetzner: `/root/aza-app`
- Deploy directory: `/root/aza-app/deploy`
- Running services: `aza-api` + `aza-caddy`
- Variant B technically proven end-to-end

**ARCHITECTURE DECISION VARIANT B (mandatory, 2026-03-25):**
- NO OpenAI key in the desktop app
- NO per-customer OpenAI key requirement
- NO shared OpenAI key client-side
- Instead: AZA Office talks ONLY to own AZA backend
- Only the AZA backend talks to OpenAI
- The OpenAI key resides EXCLUSIVELY server-side
- NO half-measures, NO shared-key hacks

**Successful Proofs (2026-03-26):**
- `curl https://api.aza-medwork.ch/health` → successful
- `curl -X POST https://api.aza-medwork.ch/v1/chat` with valid `X-API-Token` → success:true, content:OK
- Proven: Hetzner backend runs, Caddy/HTTPS runs, server-side OpenAI access works, Variant B works end-to-end

**Root Causes Solved During Deploy:**
1. Wrong git remote (`naswinterthur`) was unsuitable
2. Uploading only `deploy/` was wrong – `docker-compose.yml` expects repo root context (`context: ..`, `dockerfile: deploy/Dockerfile`)
3. Host `nginx` blocked port 80
4. Caddy DNS/ACME issues due to resolver `127.0.0.53` → Fix: explicit DNS `1.1.1.1` + `8.8.8.8` in caddy service

**Final Hetzner State:**
- Services: `aza-api` + `aza-caddy`
- Compose runs from `/root/aza-app/deploy`
- `.env` is production-relevant there
- `AZA_DOMAIN=api.aza-medwork.ch`
- `ACME_EMAIL=info@aza-medwork.ch`
- `MEDWORK_API_TOKENS` is set productively
- `OPENAI_API_KEY` is set server-side

## B1 BACKEND SPRINT (4 Weeks)

| Week | Approx. Dates | Focus |
|------|--------------|-------|
| **1** | Mar 25 – Apr 01 | Backend Chat Proxy Endpoint (POST /v1/chat) + Auth + Rate Limiting |
| **2** | Apr 02 – Apr 08 | Desktop app: all OpenAI calls via backend instead of direct |
| **3** | Apr 09 – Apr 15 | Hetzner Deploy: Docker/Caddy/HTTPS + Production Env + Smoke Tests |
| **4** | Apr 16 – Apr 22 | E2E Test Desktop→Backend→OpenAI + Customer journey without OpenAI key + Go-Live |

## CURRENT PRIORITY ORDER (B1 Backend Sprint)

1. **Backend Chat Proxy POST /v1/chat** (Week 1) – Foundation of architecture
2. **Desktop app migration to backend** (Week 2) – Migrate all OpenAI calls
3. **Hetzner Deploy** (Week 3) – Set up production server
4. **E2E Test + Go-Live backend path** (Week 4) – Customer journey without OpenAI key
5. WooCommerce/Stripe purchase path runs IN PARALLEL (Hostpoint)

**EXPLICITLY DEFERRED / NOT NOW:**
- Update comfort / separate auto-updater
- Browser-AZA web app (after backend architecture)
- Large refactors not serving Variant B

**HOSTPOINT vs. HETZNER:**
- Hostpoint remains for website/marketing/WooCommerce/Stripe
- Hetzner is NOW the backend path for OpenAI proxy/API
- Both run in parallel, not against each other

## DONE: B1-W1 Backend Chat Proxy Endpoint (2026-03-26)

**POST /v1/chat – IMPLEMENTED AND VERIFIED.**

| Aspect | Detail |
|---|---|
| Auth | `require_api_token` (X-API-Token header, existing pattern) |
| Rate Limiting | `default_ip_limiter` + `default_token_limiter` |
| Request Schema | `ChatRequest`: model, messages[], temperature?, max_tokens?, top_p? |
| Message Schema | `ChatMessage`: role (system/user/assistant), content |
| Model Whitelist | gpt-5.2, gpt-5-mini, gpt-5-nano, gpt-4o, gpt-4o-mini, gpt-4o-mini-search-preview |
| Input Limits | Max 64 messages, max 100k chars/message |
| OpenAI Call | `_get_openai().chat.completions.create(**params)` server-side |
| Response Schema | `{success, content, finish_reason, model, usage, request_id, duration_ms, error}` |
| Secret Scrubbing | `sk-`, `sk-proj-`, `org-` in error texts are replaced |
| Tests | 7/7 green (auth, model, validation, OpenAI proxy, /license/status, schema) |

**File:** `backend_main.py` (~100 lines added)

## DONE: B1-W2 Desktop Chat Migration (2026-03-26)

**Desktop app: Chat completions now routed through backend POST /v1/chat.**

**Migrated:**
1. `call_chat_completion()` in basis14.py – central wrapper -> `_backend_chat_completion()`
2. News search – direct `self.client` call -> `_backend_chat_completion()`
3. Comments – own `OpenAI()` client -> `_backend_chat_completion()`
4. Med detail short info – own `OpenAI()` client -> `_backend_chat_completion()`
5. Letter style analysis in `aza_text_windows_mixin.py` -> `_backend_chat_completion()`

**New architecture in basis14.py:**
- `_BackendChatResponse` – wrapper class, OpenAI-interface compatible (.choices[0].message.content, .usage)
- `_backend_chat_completion(**kwargs)` – POST /v1/chat using existing token mechanism (get_backend_url/get_backend_token)
- `call_chat_completion(**kwargs)` – consent/capacity check, then `_backend_chat_completion()`
- Timeout: 5s connect, 120s read
- Errors: RuntimeError with readable message, no secrets

**Remaining for later blocks:** translate.py, congress_window.py, aza_email.py (standalone modules)

**7/7 tests green:** Health, Auth, Model validation, E2E Desktop->Backend->OpenAI, Response schema, /license/status OK.

## DONE: B1-W3 Hetzner Deploy (2026-03-26)

**Hetzner backend is LIVE.**

| Aspect | Detail |
|---|---|
| Domain | `https://api.aza-medwork.ch` |
| DNS | `api.aza-medwork.ch` → `178.104.51.177` (A record) |
| Repo on Hetzner | `/root/aza-app` |
| Deploy directory | `/root/aza-app/deploy` |
| Running services | `aza-api` + `aza-caddy` |
| Compose | runs from `/root/aza-app/deploy` |
| `.env` production | `AZA_DOMAIN=api.aza-medwork.ch`, `ACME_EMAIL=info@aza-medwork.ch`, `MEDWORK_API_TOKENS` set, `OPENAI_API_KEY` set server-side |

## DONE: B1-W4 Server E2E Test (2026-03-26)

**Server-side Variant B proven end-to-end:**
- `curl https://api.aza-medwork.ch/health` → successful
- `curl -X POST /v1/chat` with valid `X-API-Token` → success:true, content:OK

## DONE: B1 Desktop Finalization (Code Patches, 2026-03-27)

**All code patches for Variant B in the desktop app are verified and correct:**

| Patch | Status | Detail |
|---|---|---|
| `ensure_ready()` | CORRECT | Remote backend counts as ready (no local OpenAI key needed) |
| OpenAI key setup dialog | CORRECT | Dialog suppressed when remote backend configured |
| `backend_url.txt` | CORRECT | Points to `https://api.aza-medwork.ch` |
| `backend_token.txt` | CORRECT | Primary local token source, prioritized by app |
| `start_all.bat` guard | CORRECT | Variant B protection: does not overwrite URL for live backend |
| `start_backend_autoport.bat` guard | CORRECT | Variant B protection: does not overwrite URL for live backend |
| Chat/text path | CORRECT | Routes through `POST {backend_url}/v1/chat` |

**Token priority (confirmed):** `backend_token.txt` > Env `MEDWORK_API_TOKENS` > Env `MEDWORK_API_TOKEN`

**Backend URL priority (confirmed):** Env `MEDWORK_BACKEND_URL` > `backend_url.txt`

**Unchanged side paths (do NOT block main test):**
- `translate.py`, `aza_email.py`, `apps/diktat/diktat_app.py` still have local OpenAI clients → side paths only
- `kongress2_window.py` has hardcoded URL → congress feature is parked

## DONE: B1-W5 Local Desktop Live Test (2026-03-27)

**Desktop → Hetzner → OpenAI successfully tested in the real app.**

- `backend_url.txt` points to `https://api.aza-medwork.ch`
- `backend_token.txt` locally present, accepted by live backend
- `basis14.py` started locally and successfully tested against live backend
- No local OpenAI key needed
- No OpenAI key dialog appears
- Chat/text path routes through Hetzner backend

**Desktop-specific notes (for future chats):**
- `ensure_ready()` is correctly patched for remote backend
- OpenAI key dialog suppressed when remote backend configured
- Do NOT use local starters for live test (`start_all.bat`, `RUN_AZA_ONECLICK.bat`, `START_AZA.bat`, `start_backend_autoport.bat`) – they set env to localhost
- Preferred start method: `python basis14.py` directly

## DONE: Desktop License Path Against Live Backend (2026-03-30)

Desktop app correctly interprets backend license status:
- `canceled` / `inactive` → test mode / DEMO
- `active` → full mode
- Relevant code: `check_license_status()` in `basis14.py`, `compute_license_decision()` in `aza_license_logic.py`
- Activation key fallback only applies when no remote backend configured

## DONE: Admin Monitor v1 + Control Panel v2 (2026-03-30)

**File:** `admin_routes.py` (mounted in `backend_main.py` with `prefix="/admin"`)

**Security:** X-Admin-Token / AZA_ADMIN_TOKEN (require_admin_token from aza_security.py)

**v1 endpoints:** system_status, licenses_overview, backup_status, billing_overview
**v2 endpoints:** license_customer_map, revenue_overview, alerts, dashboard_summary

**Key files on Hetzner:**
- `/root/aza-app/admin_routes.py`
- `/root/aza-app/stripe_routes.py`
- `/root/aza-app/backend_main.py`
- `/root/aza-app/deploy/docker-compose.yml`
- `/root/aza-app/deploy/.env`
- `/root/aza-backups/backup_aza.sh` + `/root/aza-backups/daily/` (cron)

## CURRENT MAIN BLOCK: WooCommerce / Production Sales Path

**Goal:** Make AZA Office production-ready for sale via aza-medwork.ch (Hostpoint WordPress + WooCommerce + Stripe).

**Option 1 (preferred): WooCommerce / Shop Admin**
1. Create products in WooCommerce
2. Checkout / My Account / Download / Email
3. Billing/Legal/Invoices (CHF, VAT, Terms)
4. End-to-end test purchase
5. Verify bank payouts

**Option 2 (technical): License/Customer Logic**
1. Clean customer/license lifecycle
2. Later team/practice logic
3. Better local persistence / status consistency

**Stripe/Webhook/Admin Monitor foundation is ESTABLISHED. Focus moves forward.**

## CURRENT SUBSCRIPTION PRICES (2026-03-27)

| Plan | Monthly | Yearly |
|---|---|---|
| **1 User (Basic)** | CHF 59 | CHF 590 |
| **2 Users (Team)** | CHF 89 | CHF 890 |

**Stripe Lookup Keys and Price IDs:**

| Lookup Key | Price ID | Amount |
|---|---|---|
| `aza_basic_monthly` | `price_1T53xHL5lREAW68VbuK43lmz` | CHF 59 |
| `aza_basic_yearly` | `price_1T542BL5lREAW68VNLQGCKWZ` | CHF 590 |
| `aza_team_monthly` | `price_1T544tL5lREAW68VkmnmZ21Q` | CHF 89 |
| `aza_team_yearly` | `price_1T545RL5lREAW68VLbIh73AN` | CHF 890 |

**OPEN REQUIRED DOCUMENTATION – Stripe Account:**
- Active Stripe account (login / email): NOT YET DOCUMENTED
- Test mode or live mode currently active: NOT YET DOCUMENTED
- Bank account for payouts configured: NOT YET DOCUMENTED
- Webhook active and URL: NOT YET DOCUMENTED
- Leading success/cancel URLs: NOT YET DOCUMENTED
These items must be documented before the first real customer purchase.

## DONE: Stripe Webhook + Live Test COMPLETE (2026-03-30)

**Status:** Webhook functional. Sandbox AND live purchase processed. Live test purchase successfully neutralized (canceled + refunded). `license_debug` shows `status=canceled`.

**Solved problems (chronological):**
1. **StripeObject vs dict:** `.get(...)` on raw Stripe objects → Fix: `event = json.loads(body)`
2. **`.to_dict_recursive()` does not exist** → Never use it
3. **Double prefix 404:** → Fix: `@router.post("/webhook")` only
4. **Email lookup:** `customer_email` null → Cascade: `customer_email` → `customer_details.email` → `Customer.retrieve(id)`
5. **Container env trap:** `restart` not enough → `up -d --build --force-recreate`
6. **Decimal serialization:** `str(StripeObject)` fails with Decimal → Fix: `_stripe_to_dict()` + `_decimal_default()`
7. **Idempotency bug:** `_mark_processed()` ran after error → Fix: only after success inside try block
8. **Silent exits:** Missing data → 200 OK without log → Fix: comprehensive logging
9. **Sandbox API key mix:** Sandbox webhook + live secret key → Fix: BOTH sk_test_ + whsec_ for sandbox
10. **missing_lookup_key:** Sandbox omits `price.lookup_key` → Fix: `_lookup_key_from_price()` fallback
11. **customer_email loss on updates (Bug A, 2026-03-30):** `_upsert_license` overwrote `customer_email` with NULL → Fix: COALESCE in SQL
12. **cancel_at_period_end ignored (Bug B, 2026-03-30):** Webhook wrote `status=active` despite cancellation intent → Fix: explicit check
13. **sync_subscription too restrictive (Bug C, 2026-03-30):** Only searched `WHERE status='active'` → Fix: search most recent regardless of status

**NEVER AGAIN – Stripe Webhook Rules:**
- Never use `.to_dict_recursive()`
- Never use `.get(...)` on raw StripeObjects
- After signature verification: `event = json.loads(body)`
- Use `_stripe_to_dict()` for Subscription/Customer objects (not `json.loads(str(...))`)
- Prefix routing: with `prefix="/stripe"`, decorator must be `@router.post("/webhook")`
- For `.env` changes: `docker compose up -d --build --force-recreate aza-api`
- Sandbox and live strictly separated: BOTH `sk_test_` + `whsec_` for sandbox
- After sandbox tests: restore live keys in `deploy/.env`
- `license_debug` is suitable for operational quick check
- After license anomalies: always check DB assignment first (licenses table, customer_email, subscription_id, status)

**Operational reference Hetzner:**
- Current file: `/root/aza-app/stripe_routes.py`
- Working backup: `/root/aza-app/stripe_routes.py.working_lookup_fallback_ok`
- SQLite DB: `/root/aza-app/data/stripe_webhook.sqlite`
- DB backup (after sandbox): `/root/aza-app/data/stripe_webhook.sqlite.backup_after_sandbox_success`
- DB backup (before email fix): `/app/data/stripe_webhook.sqlite.before_email_fix_1774895539`
- Logs: `docker logs -f --tail 20 aza-api`
- Event log: `tail -n 20 /root/aza-app/data/stripe_events.log.jsonl`
- Debug: `curl https://api.aza-medwork.ch/stripe/license_debug?email=admin@aza-medwork.ch`
- Sync: `curl -X POST https://api.aza-medwork.ch/stripe/sync_subscription`
- Live Stripe currently set in `/root/aza-app/deploy/.env`

## EXPLICITLY DEFERRED (Polish Phase)

- Autotext fix
- Window sizes adjustment
- Button sizes / layout for online presentation
- General UI polish
- Clean up direct OpenAI side paths in secondary modules (translate.py, aza_email.py, diktat_app.py)

**Blocker Rule:** One clear block at a time.

## CUSTOMER JOURNEY ANALYSIS (2026-03-25)

| Step | Status | Detail |
|---|---|---|
| Purchase (WooCommerce) | NEXT MAIN BLOCK | WooCommerce product setup, checkout, download, email, billing/legal |
| Download | PARTIAL | Mechanism exists, WooCommerce upload missing |
| Installer | FUNCTIONALLY COMPLETE | No code signing (SmartScreen warning) |
| Activation | STRIPE LIVE PATH PROVEN (2026-03-30) | Complete lifecycle: purchase → active → cancel/refund → canceled → test mode |
| First Start | VARIANT B LIVE (2026-03-27) | Desktop → Hetzner → OpenAI works. Desktop respects canceled status correctly. |
| Admin/Ops | CONTROL PANEL V2 LIVE (2026-03-30) | 8 endpoints, backup/storage/revenue/alerts/dashboard. X-Admin-Token protected. |

## FOCUS BLOCKS

| Priority | Block | Description |
|---|---|---|
| DONE | B1-W1: Backend /v1/chat | Chat Proxy Endpoint – foundation of Variant B |
| DONE | B1-W2: Desktop migration | All OpenAI calls in basis14.py + mixin via backend |
| DONE | B1-W3: Hetzner Deploy | Backend LIVE on api.aza-medwork.ch |
| DONE | B1-W4: Server E2E | /health + /v1/chat successful, Variant B server-side proven |
| DONE | B1-W5: Desktop Live Test | basis14.py locally tested against live backend (2026-03-27) |
| DONE | Stripe Live Webhook | Webhook 200 OK, license entry in DB, StripeObject/routing/env traps solved (2026-03-27) |
| DONE | STRIPE-W2-LIVE: Live Test Purchase | Real live purchase + cancel + refund, license_debug=canceled, 3 bugs patched (2026-03-30) |
| DONE | Desktop License Path | canceled → test mode, active → full mode correctly (2026-03-30) |
| DONE | Admin Monitor v1 | system_status, licenses_overview, backup_status, billing_overview (2026-03-30) |
| DONE | Control Panel v2 | license_customer_map, revenue_overview, alerts, dashboard_summary (2026-03-30) |
| DONE | Backup/Storage Monitor | Daily backup, /host_backups mounted, ~137 GB free (2026-03-30) |
| **CURRENT** | WooCommerce / Production Sales Path | Products, checkout, download, email, billing/legal |
| NEXT | License/Customer Logic | Clean lifecycle, team/practice logic |
| DEFERRED | UI Polish | Autotext fix, window sizes, buttons, layout |
| DEFERRED | FB-C: Signing | Signing readiness prepared |
| DEFERRED | FB-D: Update Comfort | Only after stable customer journey |

## 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

**COMMUNICATION NOTE (2026-03-30):**

Do NOT reopen / consider ESTABLISHED:
- Hetzner deploy – live and working
- DNS/Caddy/nginx/TLS – completed
- Variant A/B debate – Variant B is mandatory and productive
- Stripe webhook stabilization – all root causes solved
- Stripe live test – completed and neutralized (purchase + cancel + refund)
- Desktop license path – validated, canceled/active correct
- Admin Monitor v1 + Control Panel v2 – LIVE and functional
- Backup/Storage Monitor – ACTIVE
- Stripe/Webhook/License/Admin foundation is TECHNICALLY PROVEN – do not restart from basics

Current focus:
1. WooCommerce / Production sales path (products, checkout, download, email, billing/legal)
2. End-to-end test purchase validation
3. Then: License/customer logic professionalization or UI polish

Continuity that MUST NOT be lost:
- User does not tinker – only exact commands or complete Composer prompts
- Root-cause-first, no monster patches
- Hostpoint remains main website, Hetzner is backend/API
- Desktop talks to backend, OpenAI key stays server-side
- Backend license status is authoritative (not activation key)
- Admin Control Panel is foundation for operator view
- Backup/Storage monitor is active

## Current Local Workspace

**CURRENT PATH (from 2026-03-27):**
```
C:\Users\surov\Documents\AZA_GIT\aza\AzA march 2026
```

**OLD PATH (HISTORICAL, do not use):**
```
C:\Users\surov\Documents\AZA\backup 24.2.26
```

## Key Commands

**Preferred start method for live test against Hetzner backend:**
```
cd "C:\Users\surov\Documents\AZA_GIT\aza\AzA march 2026"
python basis14.py
```

**DO NOT use for live test (set env to localhost):**
- `start_all.bat`, `RUN_AZA_ONECLICK.bat`, `START_AZA.bat`, `start_backend_autoport.bat`

**Local dev start (only for local development with own backend):**
```
cd "C:\Users\surov\Documents\AZA_GIT\aza\AzA march 2026"
powershell -ExecutionPolicy Bypass -File .\deploy\local_reset_and_start.ps1
```

**Tests:**
```
cd "C:\Users\surov\Documents\AZA_GIT\aza\AzA march 2026"
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).