mitai-jinkendo/docs/issues/PHASE_PLAN_RESPONSIVE_UI.md

Phasenplan: Responsive UI (Desktop Sidebar + Mobile/PWA)

Gitea: #30 – Responsive UI
Spec: .claude/docs/functional/RESPONSIVE_UI.md
Breakpoint: <1024px = Mobile (Bottom-Nav, bestehendes Verhalten), ≥1024px = Desktop (Sidebar 220px)
Letzte Plan-Aktualisierung: 2026-04-05 (P7 Admin-Shell umgesetzt; Doku GUI_IA_ADMIN_NAV_2026-04-05.md; P8 ausstehend)

---

Fortschritt (kurz)

Phase	Titel	Status	Datum / Notiz
P0	Vorbereitung & Baseline	☑ erledigt	Spec RESPONSIVE_UI.md bereinigt
P1	App-Shell: Sidebar + Breakpoint + gemeinsame Navigation	☑ erledigt	DesktopSidebar, config/appNav.js, Admin /admin/*-Highlight
P2	Globales Layout & Content-Bereich (CSS)	☑ erledigt	Desktop: Header aus, Content max 1200px; Mobile unverändert Bottom-Nav
P3	Dashboard (Desktop-Grid)	☑ erledigt	4-spaltige Kennzahlen; Begrüßung; Ernährung/Aktivität 2-spaltig
P4	Verlauf (Tabs links / Content rechts)	☑ erledigt	History.jsx + .history-* in app.css; Tab-State bei location.state.tab
P5	Analyse (Prompts links / Ergebnis rechts)	☑ erledigt	Analysis.jsx + .analysis-split* in app.css
P6	Erfassung / Capture & Formularseiten	☑ erledigt	.capture-page + --capture-content-max (eine Desktop-Breite); CaptureShell-Navigation
P7	Admin & restliche Vollbreiten-Seiten	☑ erledigt (Kern)	2026-04-05: AdminShell + Hub-Routen + adminNav; Tabellen/„volle Breite“ weiter iterativ laut Spec §5.5
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

Stand 2026-04-05: Admin nutzt dedizierte Shell mit Gruppen-Navigation und Hubs (AdminShell, adminNav.js, RequireAdmin) — IA- und Routing-Grundlage erledigt. Tabellen „mehr Breite“ / feinere Layout-Tuning gemäß §5.5 können weiterlaufen ohne Shell-Refactor. Doku: GUI_IA_ADMIN_NAV_2026-04-05.md.

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.