**Allgemein:** Kein Pflicht-E2E-Framework im Repo; Abnahme primär **manuell** nach Checklisten unten. Optional später: Playwright-Smoke (`viewport`-Wechsel).
---
## Phase P0 – Vorbereitung & Baseline
### Ziel
Risikoarm starten: Ist-Stand dokumentieren, Spec bereinigen, keine funktionale UI-Änderung.
### Aufgaben
- [ ] Bekannte Artefakte am Ende von `.claude/docs/functional/RESPONSIVE_UI.md` entfernen (Zeilen `EOF` / `echo …`), falls noch vorhanden.
- [ ] Kurz notieren: aktuelle `app-shell`/`max-width:600px` in `app.css` ist die Mobile-Baseline (siehe Code-Review).
### Abnahmekriterien
- Spec-Datei endet mit den „Offenen Fragen“; keine Shell-Zeilenduplikate aus Fremdkopien.
- Plan-Datei (dieses Dokument) ist im Repo und verlinkt (optional in Gitea #30 kommentieren).
### Tests (P0)
| Test | Schritt | Erwartung |
|------|---------|-----------|
| P0-T1 | `RESPONSIVE_UI.md` öffnen | Letzte sinnvolle Zeile ist Frage 4 oder Abschnittsende; kein `echo`/`EOF` |
| P0-T2 | `npm run build` im `frontend/` | Exit 0 |
Desktop: feste **Sidebar 220px** links gemäß Spec; Mobile: **unverändert** Bottom-Nav. **Eine** Navigationsdefinition (Routes/Labels/Icons) für beide Darstellungen. Öffentliche Auth-Routen (`/register`, `/verify`, …) **nicht** in Sidebar/Bottom-Nav einbinden (wie heute).
### Aufgaben (technisch orientierend)
- [ ] Nav-Items aus `App.jsx` (`Nav`-Komponente) in **eine** exportierbare Struktur (z. B. `navItems` Array + `admin`-Eintrag nur bei `role === 'admin'`), von **Desktop-Sidebar** und **Mobile `Nav`** gemeinsam genutzt.
- [ ] Neue Komponente z. B. `DesktopSidebar.jsx` (oder `AppSidebar.jsx`): Logo/Branding, gleiche Links wie Bottom-Nav, unten Nutzerbereich (Avatar, Name/Tier laut Spec – Daten aus `useProfile`/`useAuth` wo möglich).
- [ ]`AppShell`: bei `≥1024px` Sidebar sichtbar, **Bottom-Nav ausgeblendet**; bei `<1024px`**umgekehrt**.
- [ ] Aktiver Route-State: `NavLink`/`active` in Sidebar **gleiche Semantik** wie Bottom-Nav (`end` bei `/` beachten).
- [ ]**Kein**`resize`-Listener pflichtig; primär **CSS** (`@media (min-width: 1024px)`) für Sichtbarkeit; falls nötig nur für Edge-Cases.
### Abnahmekriterien
- Unter **1024px**: UI wirkt **wie vor P1** (Bottom-Nav sichtbar, Sidebar unsichtbar); PWA-Start auf iPhone unverändert nutzbar.
| P1-T3 | T-H3: Breite 1023→1024 wechseln | Sidebar erscheint / Bottom verschwindet ohne Reload; kein „Flackern“-Loop |
| P1-T4 | T-H4: PWA | Login, Hauptflows kurz (Dashboard, Erfassung) – Bottom-Nav ok |
| P1-T5 | Admin-User T-H1 | Admin-Eintrag in Sidebar; Nicht-Admin ohne Admin |
---
## Phase P2 – Globales Layout & Content-Bereich
### Ziel
Desktop-**Content** rechts von der Sidebar: Spec **margin-left 220px**, Padding **24px 32px**, **max-width 1200px** zentriert im verbleibenden Raum. Mobile: beibehaltene Abstände (**16px**, **80px** bottom für Nav).
### Aufgaben
- [ ]`app.css`: `.app-shell`**nicht** mehr global `max-width: 600px` für Desktop; Mobile beibehalten oder per Media Query trennen.
- [ ]`.app-main` Padding/Bottom: Mobile `calc(nav + 16px)`; Desktop **ohne** Bottom-Nav-Padding (oder nur safe-area falls nötig).
- [ ] Optional Desktop: **Top-Header** (`app-header`) redundant mit Sidebar-Branding –**vereinheitlichen** (z. B. Header auf Desktop ausblenden oder auf kompakte Toolbar reduzieren), damit keine doppelte Logo-Zeile.
### Abnahmekriterien
- Desktop: Content nutzt **sichtbar mehr** horizontalen Raum als heute (max 1200px Inhalt, zentriert).
- Mobile: **kein** zusätzliches horizontales Scrollen der Gesamtseite durch P1/P2.
- Keine Überlappung Sidebar/Content.
### Tests (P2)
| Test | Schritt | Erwartung |
|------|---------|-----------|
| P2-T1 | T-H1: lange Seite scrollen | Nur Main-Area scrollt; Sidebar bleibt sichtbar (fixed) |
| P2-T2 | T-H2 | Weiterhin nutzbarer unterer Rand für Bottom-Nav |
| P2-T3 | T-H1: sehr breiter Monitor | Content max ~1200px, optisch zentriert rechts von Sidebar |
---
## Phase P3 – Dashboard (Desktop-Grid)
### Ziel
Spec **§5.1**: Desktop mehrspaltige Karten (z. B. 4 Spalten für Kennzahlen-Zeile); Mobile Karten untereinander.
### Aufgaben
- [ ]`Dashboard.jsx`: Layout in **CSS Grid** o. ä. mit `@media (min-width: 1024px)` für 4-Spalten-Zeile(n) laut Wireframe; Mobile unveränderte Reihenfolge.
- [ ] Charts/„volle Breite“-Blöcke unter den Karten laut Spec.
### Abnahmekriterien
- Mobile Dashboard **visuell vergleichbar** zum Stand vor P3 (keine funktionalen Regressionen).
- Desktop: klar erkennbares **Grid**; keine übermäßigen Lücken bei typischer Viewport-Höhe.
Spec **§5.4**: Desktop Formulare **zentriert**, **max-width ~600px** im Content-Bereich; Mobile volle Breite wie heute.
### Aufgaben
- [ ]`CaptureHub` und relevante Seiten (`WeightScreen`, …) unter Desktop-Wrapper; wo sinnvoll **gemeinsame** Klasse `.capture-form-desktop` in `app.css`.
### Abnahmekriterien
- Mobile: keine Verschlechterung der Eingabe.
- Desktop: Formulare nicht „volle 1200px“, sondern **lesbar begrenzt**.
### Tests (P6)
| Test | Schritt | Erwartung |
|------|---------|-----------|
| P6-T1 | T-H2: Gewicht erfassen | Vollbreite ok |
Spec **§5.5**: Admin-Tabellen nutzen auf Desktop **mehr Breite**; Mobile weiterhin horizontales Scrollen wo nötig.
### Aufgaben
- [ ]`Admin*Page.jsx` und ähnliche Tabellen-Seiten: unnötige `max-width`-Erbe von Mobile entfernen; **nicht** jede Admin-Seite einzeln zerstören – priorisiert häufig genutzte.
### Abnahmekriterien
- Keine regressiven Auth-Schutz-Änderungen.
- Desktop: **mehr sichtbare Spalten** bei typischen Admin-Tabellen.
### Tests (P7)
| Test | Schritt | Erwartung |
|------|---------|-----------|
| P7-T1 | T-H1: z. B. Admin Training Types | Tabelle nutzt Breite; horizontales Scrollen nur bei Bedarf |
| P7-T2 | T-H2: gleiche Seite | Weiter bedienbar mit Scroll |
- [ ] Resize ohne JavaScript-Zwang stabil (CSS-first).
- [ ]**PWA iPhone** weiterhin funktionsfähig (Kernflows).
### Tests (P8 – Smoke-Checkliste)
| Route | T-H2 | T-H1 |
|-------|------|------|
| `/` | ☐ | ☐ |
| `/capture` | ☐ | ☐ |
| `/history` | ☐ | ☐ |
| `/analysis` | ☐ | ☐ |
| `/settings` | ☐ | ☐ |
| 1× Admin (falls verfügbar) | ☐ | ☐ |
| T-H4 PWA kurz | ☐ | n/a |
---
## Parallelität (Canvas / Workflow)
- Während **P1–P2** möglichst **keine** parallelenden Änderungen an `App.jsx` / globalem `app.css` ohne Absprache.
- Neue **Workflow-/Canvas-Routen**: nur innerhalb von `<main>`; Sidebar- und Breakpoint-**Kontrakt** einhalten (`margin-left`, keine zweite globale Spalte).
---
## Planpflege
Änderungen an Phasen, Kriterien oder Status: **dieses File** anpassen und kurz „Letzte Plan-Aktualisierung“ oben datieren. Bei größeren Scope-Änderungen Gitea #30 kommentieren.
