# Browser-AZA MVP – First Implementation Slice

Stand: 2026-03-08  
Status: verbindliche Bauvorlage für den ersten echten Code-Patch von Step 22

---

## Zweck dieses Slices

Dieser erste Slice baut **noch nicht die komplette Browser-App**, sondern nur den ersten klaren, risikoarmen Kern:

- eine einzelne MVP-Hauptseite
- Fachrichtungsauswahl
- Audio-Datei-Auswahl
- Upload-Button
- Ergebnisbereich
- Copy-Button Platzhalter bzw. Zielbereich
- sichtbare Support-/Privacy-/Terms-Links

Der Fokus ist:

**Struktur und Flow sichtbar machen, ohne den bestehenden Backend-Contract zu brechen.**

---

## Ziel des ersten Code-Patches

Nach dem ersten Code-Patch soll es im Projekt eine klar erkennbare Browser-MVP-Oberfläche geben, die:

1. eine Hauptseite rendert
2. einen Eingabebereich besitzt
3. einen Ergebnisbereich besitzt
4. den späteren Upload-Flow logisch vorbereitet

---

## In Scope für den ersten Code-Patch

- eine einzelne Browser-Seite / Web-Shell
- Überschrift / Produktbereich
- kurze Beschreibung
- Fachrichtungsauswahl
- Dateiauswahl für Audio
- primärer Upload-Button
- Ergebnisbox für Transkript
- Copy-Button als UI-Element
- Bereich für Fehlermeldung / Status
- Footer oder Linkbereich mit:
  - Support
  - Privacy
  - Terms

---

## Nicht in Scope für den ersten Code-Patch

- fertige Login-/Account-Logik
- Deployment
- HTTPS-Konfiguration
- Billing
- Admin-Funktionen
- Refactor bestehender Backend-Strukturen
- Änderungen am Auth-Contract
- Änderungen an `/license/status`

---

## Erwartete Seitenstruktur

### Kopfbereich
- Produktname: AZA
- Kurztext: medizinische Transkription

### Eingabebereich
- Dropdown oder Auswahlfeld für Fachrichtung
- Datei-Input für Audio
- Upload-Button

### Status-/Fehlerbereich
- Platz für:
  - Ladehinweis
  - Fehlermeldung
  - Erfolgshinweis

### Ergebnisbereich
- grosse Text-/Ergebnisbox
- Copy-Button

### Footer-/Linkbereich
- Support
- Privacy
- Terms

---

## Technische Leitplanken

- keine Änderung an `X-API-Token`
- keine Bearer-Umstellung
- keine Secrets im Frontend ausgeben
- keine unnötigen Refactors
- keine Breaking Changes

---

## Ergebnis nach diesem Slice

Wenn dieser Slice umgesetzt ist, muss ein Nutzer bereits sehen können:

- was Browser-AZA ist
- wo Fachrichtung gewählt wird
- wo Audio ausgewählt wird
- wo Upload ausgelöst wird
- wo später das Transkript erscheint

Auch wenn der echte End-to-End Upload-Flow erst im nächsten Slice komplett verdrahtet wird.

---

## Danach folgt im nächsten Slice

Nach diesem ersten UI-Slice kommt:

1. Upload-Handler
2. Request an `/v1/transcribe`
3. Ergebnisanzeige aus echter Backend-Antwort
4. Copy-Funktion aktiv

---

## Abnahmekriterien für diesen ersten Slice

Der Slice ist erfüllt, wenn:

1. die Browser-Seite sichtbar rendert
2. Fachrichtung auswählbar ist
3. Audio-Datei auswählbar ist
4. Upload-Button sichtbar ist
5. Ergebnisbereich sichtbar ist
6. Support/Privacy/Terms sichtbar sind
7. keine bestehenden Contracts verletzt werden