Lars
dc59596f01
Backend (Mini-Backend 1-2h): - Migration 016: ai_prompts.graph_data JSONB column - workflow_executor: graph_data parameter support (backward-compatible) - prompt_executor: execute_workflow_prompt uses graph_data Frontend (Main effort 25-35h): - WorkflowCanvas: React Flow wrapper component - 5 Custom Nodes: Start, End, Analysis, Logic, Join - 4 Config Panels: QuestionAugmentation, LogicExpression, Fallback, Join - workflowValidation: Structural + logical validation - workflowSerializer: Canvas ↔ JSONB conversion - WorkflowEditorPage: Main orchestration (420 LOC) - Route: /workflow-editor/:id - CSS: workflowEditor.css (300 LOC) Architecture: - Option B: ai_prompts.type='workflow' (not separate table) - panels/ subdirectory for clean separation - WorkflowCanvas reusable component - User GUI identical (Workflows = Prompts) - Backward-compatible (type='pipeline' unchanged) Version: v0.9m → v0.9n (Phase 5 complete) Module: workflow 0.5.0 → 0.6.0 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
265 lines
12 KiB
Markdown
265 lines
12 KiB
Markdown
# Phasenplan: Responsive UI (Desktop Sidebar + Mobile/PWA)
|
||
|
||
> **Gitea:** [#30 – Responsive UI](http://192.168.2.144:3000/Lars/mitai-jinkendo/issues/30)
|
||
> **Spec:** `.claude/docs/functional/RESPONSIVE_UI.md`
|
||
> **Breakpoint:** `<1024px` = Mobile (Bottom-Nav, bestehendes Verhalten), `≥1024px` = Desktop (Sidebar 220px)
|
||
> **Letzte Plan-Aktualisierung:** 2026-04-04
|
||
|
||
---
|
||
|
||
## Fortschritt (kurz)
|
||
|
||
| Phase | Titel | Status | Datum / Notiz |
|
||
|-------|--------|--------|----------------|
|
||
| P0 | Vorbereitung & Baseline | ☐ pending | |
|
||
| P1 | App-Shell: Sidebar + Breakpoint + gemeinsame Navigation | ☐ pending | |
|
||
| P2 | Globales Layout & Content-Bereich (CSS) | ☐ pending | |
|
||
| P3 | Dashboard (Desktop-Grid) | ☐ pending | |
|
||
| P4 | Verlauf (Tabs links / Content rechts) | ☐ pending | |
|
||
| P5 | Analyse (Prompts links / Ergebnis rechts) | ☐ pending | |
|
||
| P6 | Erfassung / Capture & Formularseiten | ☐ pending | |
|
||
| P7 | Admin & restliche Vollbreiten-Seiten | ☐ pending | |
|
||
| P8 | Abschluss, Regression, Spec-Pflege | ☐ pending | |
|
||
|
||
**Status-Legende:** `☐ pending` · `◐ in Arbeit` · `☑ erledigt` · `⏸ blockiert`
|
||
|
||
---
|
||
|
||
## Testumgebung (für alle Phasen)
|
||
|
||
| ID | Umgebung | Verwendung |
|
||
|----|-----------|------------|
|
||
| T-H1 | Chromium Desktop, Fenster **≥1280px** | Desktop-Layout, Sidebar |
|
||
| T-H2 | Chromium, DevTools **375×812** (o. ä.) | Mobile-Layout, Bottom-Nav |
|
||
| T-H3 | Chromium, Breite **1023px** vs **1024px** | Breakpoint-Grenze |
|
||
| T-H4 | **iPhone** (Safari), installierte **PWA** | Regression Mobile/PWA |
|
||
| T-H5 | optional: iPad quer (**≥1024px**) | Desktop-Sidebar auf Tablet quer |
|
||
|
||
**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 |
|
||
|
||
---
|
||
|
||
## Phase P1 – App-Shell: Sidebar + Breakpoint + gemeinsame Navigation
|
||
|
||
### Ziel
|
||
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.
|
||
- Ab **1024px**: Sidebar sichtbar, fixed links, ~220px; Bottom-Nav **nicht** sichtbar.
|
||
- Admin-Link nur für Admins in **beiden** Navs.
|
||
- Abmelden erreichbar (Spec: im Sidebar-Footer; falls Mobile weiter nur im Header: ** dokumentieren als Abweichung** oder gleich ziehen).
|
||
|
||
### Tests (P1)
|
||
| Test | Schritt | Erwartung |
|
||
|------|---------|-----------|
|
||
| P1-T1 | T-H2: einloggen, alle 5 Haupt-Routen antippen | Bottom-Nav aktiv, kein Layout-Bruch |
|
||
| P1-T2 | T-H1: gleiche Routen | Nur Sidebar-Navigation sichtbar, korrekte Aktiv-Markierung |
|
||
| 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.
|
||
|
||
### Tests (P3)
|
||
| Test | Schritt | Erwartung |
|
||
|------|---------|-----------|
|
||
| P3-T1 | T-H2 Dashboard | Karten untereinander, lesbar |
|
||
| P3-T2 | T-H1 Dashboard | Mehrspaltigkeit wie Spec; kein horizontaler Overflow |
|
||
| P3-T3 | Daten mit/ohne Werte | Keine Layout-Crashes (leere Zustände) |
|
||
|
||
---
|
||
|
||
## Phase P4 – Verlauf (`History.jsx`)
|
||
|
||
### Ziel
|
||
Spec **§5.2**: Desktop **Tabs vertikal links**, Chart/Tabelle **rechts** (volle restliche Breite); Mobile Tabs oben wie heute.
|
||
|
||
### Aufgaben
|
||
- [ ] Tab-Steuerung refaktorieren oder per CSS **ohne** doppelte State-Logik.
|
||
- [ ] Desktop: flex/grid `240–280px` Tab-Spalte + flex 1 Chart-Bereich (feinjustierbar).
|
||
|
||
### Abnahmekriterien
|
||
- Alle bisherigen Verlauf-**Tabs** funktionieren (Gewicht, KF, Umfänge, … – wie im aktuellen Code).
|
||
- Mobile UX **unverändert** vom Nutzergefühl her (Tabs oben).
|
||
- Desktop: klar **zwei Spalten**; Chart nutzt rechte Fläche.
|
||
|
||
### Tests (P4)
|
||
| Test | Schritt | Erwartung |
|
||
|------|---------|-----------|
|
||
| P4-T1 | T-H2: Tab wechseln | Wie bisher |
|
||
| P4-T2 | T-H1: jeder Tab | Linke Liste + rechter Chart-Bereich sichtbar |
|
||
| P4-T3 | Langes Tab-Label / viele Tabs | Kein Layout-Bruch (Scroll in Tab-Spalte falls nötig) |
|
||
|
||
---
|
||
|
||
## Phase P5 – Analyse (`Analysis.jsx`)
|
||
|
||
### Ziel
|
||
Spec **§5.3**: Desktop **Prompt-Liste links (~300px)**, Ergebnis **rechts**; Mobile untereinander.
|
||
|
||
### Aufgaben
|
||
- [ ] Layout splitten; Pipeline/Prompt-Bereiche so umbauen, dass Lesbarkeit und Scroll-Verhalten stimmen.
|
||
|
||
### Abnahmekriterien
|
||
- KI-Ausführung, Platzhalter-Tabelle, Experten-Modus: weiter bedienbar.
|
||
- Desktop: Ergebnisbereich hat **deutlich mehr** Breite als Mobile.
|
||
|
||
### Tests (P5)
|
||
| Test | Schritt | Erwartung |
|
||
|------|---------|-----------|
|
||
| P5-T1 | T-H2: Analyse ausführen | Flow wie bisher |
|
||
| P5-T2 | T-H1: langes Ergebnis | Rechte Spalte scrollbar, linke Prompt-Liste fix oder eigen-scroll |
|
||
| P5-T3 | Kleines Fenster knapp unter 1024px | Kein „mittendrin“ kaputtes Layout |
|
||
|
||
---
|
||
|
||
## Phase P6 – Erfassung / Capture & Formularseiten
|
||
|
||
### Ziel
|
||
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 |
|
||
| P6-T2 | T-H1: gleiche Seite | Schmale, zentrierte Spalte |
|
||
| P6-T3 | Capture-Hub Kacheln | Umbruch auf Desktop ordentlich |
|
||
|
||
---
|
||
|
||
## Phase P7 – Admin & übrige Seiten
|
||
|
||
### Ziel
|
||
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 |
|
||
|
||
---
|
||
|
||
## Phase P8 – Abschluss, Regression, Dokumentation
|
||
|
||
### Ziel
|
||
Release-tauglich machen; Spec und Issue aktualisieren.
|
||
|
||
### Aufgaben
|
||
- [ ] Alle Phasen P1–P7 in Fortschrittstabelle auf ☑ setzen.
|
||
- [ ] Vollständiger **Regression-Pass** (Routenliste aus `App.jsx`).
|
||
- [ ] Gitea #30: Abschlusskommentar mit **Screenshots** (optional) + Hinweis auf diesen Plan.
|
||
- [ ] `REVIEW_OPEN_ISSUES_2026-04-04.md` oder Nachfolger: #30 auf DONE setzen, wenn aus eurer Sicht erledigt.
|
||
|
||
### Abnahmekriterien (Gesamt gem. #30 / Spec)
|
||
- [ ] Desktop **≥1024px**: Sidebar links, Bottom-Nav aus.
|
||
- [ ] Mobile **<1024px**: Bottom-Nav unten, Sidebar aus.
|
||
- [ ] Aktive Route in beiden Navs korrekt.
|
||
- [ ] Dashboard / Verlauf / Analyse / Erfassung / Admin gemäß Spec umgesetzt.
|
||
- [ ] 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.
|