# Weitere Phasen — Outline > Übersicht über Phasen 2–6. Diese werden detailliert ausgearbeitet, > sobald Phase 0+1 abgenommen sind. Jede Phase bekommt ein eigenes > `0X-PHASE-N-NAME.md`, wenn sie aktiv wird. --- ## Phase 2 — Customer-Dashboard auf Mockup-Stil **Status**: ✅ **abgeschlossen** (de facto in Phase 1 + verfeinert in 4J) · **Aufwand**: ~½ Tag · **Risiko**: niedrig > Während der Phase-1-Migration wurden Page-Header, KPI-Reihe, > 2-Spalten-Grids, ``, > `` und Brand-Bridge-Dark-Card bereits > umgesetzt. Phase 4J hat die Recent-PM-Liste mit Portal-Pills > + PM-ID-Sub auf den finalen 4H/4I-Pattern-Stand gebracht. > Match zum Mockup ≥ 95 %. ### Ziel `livewire/customer/dashboard.blade.php` matched das Mockup `User Dashboard presseportale.html` zu ≥ 90 %. ### Bausteine - **Page-Header** mit „Mein Dashboard" + Begrüßung + Firma-zugeordnet-Pille - **KPI-Reihe** (4 Stat-Cards mit linkem Farb-Strip) - Gesamt (Hub-Blau-Strip) - Veröffentlicht (Grün-Strip, `is-ok`) - In Prüfung (Bernstein-Strip, `is-warn`) - Entwürfe (Grau-Strip, `is-muted`) - **2-Spalten-Grid**: - Links: Empty-State / Liste „Meine letzten Pressemitteilungen" - Rechts: „Datenqualität" mit Progress-Bars (Profil-Vollständigkeit, Rechnungsadresse) - **Unten**: - Links: Firmen-Slots - Rechts: Brand-Bridge-Dark-Card (presseecho + businessportal24) ### Neue Blade-Components - `` — Stat-Card mit Slot + Strip-Variante - `` — Datenqualitäts-Hint mit Icon + Progress-Bar - `` — Dunkle Brand-Bridge-Card → Diese landen in `resources/views/components/portal/`. --- ## Phase 3 — Admin-Dashboard konsistent **Status**: ✅ **abgeschlossen** (in Phase 1 + 4J) · **Aufwand**: ~½ Tag · **Risiko**: niedrig > Admin-Dashboard nutzt seit Phase 1 dasselbe Vokabular wie > das Customer-Dashboard: Page-Header, 5-KPI-Reihe mit > ``, 2-Spalten-Grid (Recent + Pending > Reviews), Newsletter `panel-warm`, Quick-Actions-Grid, > Footer. Phase 4J hat Portal-Pills, PM-ID-Sub und > Inline-Action „Prüfen →" mit `is-row-warn`-Tinting für > die Review-Queue ergänzt. --- ## Phase 4 — Listen-/Detail-Pages durchgehen **Status**: ✅ **komplett abgeschlossen** (4A–4J) · **Aufwand**: ~3–5 Tage gesamt · **Risiko**: niedrig > Alle 10 Sub-Päckchen (4A–4J) sind grün, Build + Pint > sauber, alle relevanten Tests bestehen > (230/231 gesamt — der eine Fail ist der pre-existing > `ApiDocumentationTest` ohne Bezug zur UI-Migration). > Das gesamte Backend (Admin + Customer) nutzt damit > dieselbe Design-Sprache: Page-Header mit > Eyebrow/Badge/Subtitle, ``-KPI-Reihen, > `article.panel` als Container, `flux:table` mit Hub-Padding > + Sortierung, `flux:card` nur wo Test-Verträge sie noch > brauchen, sowie die Mockup-Patterns aus 4H/4I/4J > (Saved-Views-Tabs, Active-Chips, Portal-Pills, > Inline-Actions, Row-Tinting, 3-stufige Empty-States). ### Ziel Alle Volt-Pages im Admin- und Customer-Bereich nutzen denselben Hub-Stil. ### Vorgehen - Pro Page: 15–30 min - In Päckchen geteilt: - **4A** = Press-Releases Listen (Admin + Customer) — ✅ **abgeschlossen** siehe `07-PHASE-4A-PRESS-RELEASES-LISTEN.md` - **4B** = Press-Releases Detail/Show (Admin + Customer) — ✅ **abgeschlossen** siehe `08-PHASE-4B-PRESS-RELEASES-DETAIL.md` - **4C** = Press-Releases Forms (create/edit, Admin + Customer) — ✅ **abgeschlossen** siehe `09-PHASE-4C-PRESS-RELEASES-FORMS.md` - **4D** = Companies (`admin.companies.*`) — ✅ **abgeschlossen** siehe `10-PHASE-4D-COMPANIES.md` - **4E** = Profile/Settings (`settings.*`, `customer.profile`, `customer.security`) — ✅ **abgeschlossen** siehe `11-PHASE-4E-PROFILE-SETTINGS.md` - **4F** = Restliche Admin-Bereiche (contacts, categories, presets, footer-codes, users, roles, newsletter, reports, invoices, coupons, payments, portal-switcher) — ✅ **abgeschlossen** siehe `13-PHASE-4F-ADMIN-REST.md` - **4G** = Restliche Customer-Bereiche (invoices, tokens, bookings, company-switcher, me/press-kits/*) — ✅ **abgeschlossen** siehe `12-PHASE-4G-CUSTOMER-PORTAL.md` - **4H** = Customer „Meine Pressemitteilungen" auf Mockup-Stil (Counter-Strip, Saved-Views-Tabs, Filter-Chips, Active-Chips, Portal-Pills, Inline-Actions, Row-Tint, 3-fach-Empty-State, Status-Aktionen-Legende) — ✅ **abgeschlossen** siehe `14-PHASE-4H-PRESS-RELEASES-MOCKUP.md` - **4I** = Admin „Pressemitteilungen" — Mockup-Patterns übertragen (Saved-Views-Tabs, Active-Chips, Portal-Pills, Row-Tint, Inline-Actions als Modal-Trigger, reduzierte Spalten, 2-stufiger Empty-State) — ✅ **abgeschlossen** siehe `15-PHASE-4I-ADMIN-PRESS-RELEASES.md` - **4J** = Dashboard-PM-Listen mit 4H/4I-Patterns (Portal-Pills, PM-ID-Sub, Customer + Admin Dashboard, Inline-Action „Prüfen →" für Admin-Review-Queue mit `is-row-warn` Tinting) — ✅ **abgeschlossen** siehe `16-PHASE-4J-DASHBOARD-LISTS.md` ### Was geändert wird - Page-Header-Struktur (Eyebrow + H1 + Subtitle + Aktions-Bar) - Filter-Bars werden Hub-konform gestylt - `flux:table`-Header bekommen Eyebrow-Optik - Form-Felder bleiben FluxUI, aber mit Hub-Tokens ### Was nicht geändert wird - Logik / Volt-Methoden - Datenbank / Models --- ## Phase 5 — Dark Mode konsistent **Status**: ✅ **abgeschlossen** · **Aufwand**: ~½ Tag (Großteil der Arbeit war Vorbereitung in Phase 0–4) · **Risiko**: niedrig > Tokens, Switcher und alle Custom-CSS-Komponenten waren > bereits token-basiert vorbereitet — `shared/design-tokens.css` > hat einen kompletten `.dark { … }`-Block (Z. 182–248) mit allen > Surfaces, Hub/Bernstein-Akzenten, Ink-Skala, Status-Farben, > Schatten und `color-scheme: dark`. `hub-components.css` ist > zu 100 % token-basiert und schaltet automatisch um. FluxUI's > `@fluxAppearance` ist in beiden Head-Partials integriert, > Switcher liegt im User-Menü (Desktop + Mobile) sowie in > `settings/appearance.blade.php`. Bei der Inventur fiel nur > ein latenter Bug auf (`--color-ink-deep`-Token existiert > nicht, in `customer/tokens.blade.php` auf > `--color-panel-dark-2` umgestellt). QR-Code in > `customer/security.blade.php` behält bewusst `bg-white` in > beiden Modi (Scan-Tauglichkeit), klarstellender Kommentar > ergänzt. > > Siehe `17-PHASE-5-DARK-MODE.md` für Details. ### Quelle `dev/frontend/tailwind_v3/User Dashboard presseportale Dark.html` hat alle Dark-Tokens bereits vorgegeben — alle Werte sind in `design-tokens.css` übernommen. ### Was geliefert wird - Settings → Erscheinung → „Dunkel" schaltet Portal um - Settings → Erscheinung → „System" folgt OS-Präferenz - Switcher zusätzlich direkt im User-Menü (Sidebar + Mobile) - Sidebar, Topbar, Dashboards, Listen, Forms — alles schaltet automatisch über Token-Cascade um - `panel-dark` bleibt KONSTANT dunkel (Brand-Bridge-Card) - `--color-accent-warm` bleibt KONSTANT Bernstein (Hint-Cards) - Hub-Landing und Hub-Auth bleiben Light (kein `@fluxAppearance` im Web-Build) --- ## Phase 6 — Auth-Cleanup **Status**: ✅ **abgeschlossen** · **Aufwand**: ~30 min · **Risiko**: niedrig > Hub-Auth bleibt eigenständig (auf Web-Build mit dem `pressekonto`-Layout), > weil Hub-Atmosphäre + Light-Bundle als Trade-off bewusst gewollt sind. > Die ungenutzten Starter-Kit-Layouts wurden entfernt: `auth/simple`, > `auth/split`, `auth/card`, der Wrapper `auth.blade.php`, das alternative > `app/header.blade.php` sowie die Debug-Views `livewire/auth/login-simple` > und `test-simple`. Damit gibt es keine hardcoded `class="dark"`-Reste > mehr, die Phase 5 hätten torpedieren können. Doku-Beispiel in > `_docs/FORTIFY-SANCTUM-SETUP.md` auf `components.layouts.auth.pressekonto` > umgestellt. CSS-Bundle ist dabei sogar ~2.4 KB kleiner geworden. > > Siehe `18-PHASE-6-AUTH-CLEANUP.md` für die Inventur. ### Optional für später (NICHT Teil von Phase 6) Eine echte **Auth-Konsolidierung** (Hub-Auth-CSS in den Portal-Build ziehen, Web-Build nur für die Landing-Pages behalten) wäre denkbar, aber: - Hub-Atmosphäre (Konzentrische Kreise, Hub-Grid) ist visuell stark - Hub-Auth ist leichtgewichtig (kein FluxUI im Bundle) - Aktueller Stand funktioniert sauber → keine Action notwendig, bleibt offen. --- ## Gesamt-Status (Stand 2026-05-20) | Phase | Inhalt | Status | |---|---|---| | 0 | Hub-Auth (Login/Register) im Hub-Stil | ✅ | | 1 | Portal-Migration (Tokens, FluxUI-Overrides, Sidebar/Topbar, App-Shell, Dark-Switch im User-Menü) | ✅ | | 2 | Customer-Dashboard auf Mockup-Stil | ✅ (in P1, verfeinert in 4J) | | 3 | Admin-Dashboard konsistent | ✅ (in P1, verfeinert in 4J) | | 4 | Listen/Detail durchgehen (4A–4J) | ✅ **komplett** | | 5 | Dark Mode konsistent | ✅ **abgeschlossen** | | 6 | Auth-Cleanup | ✅ **abgeschlossen** | ### Phase 4 — Sub-Päckchen im Detail | ID | Bereich | Plan-Doc | |---|---|---| | 4A | Press-Releases Listen (Admin + Customer) | `07-PHASE-4A-…` | | 4B | Press-Releases Detail/Show | `08-PHASE-4B-…` | | 4C | Press-Releases Forms (create/edit) | `09-PHASE-4C-…` | | 4D | Companies (Admin) | `10-PHASE-4D-…` | | 4E | Profile/Settings (Admin + Customer) | `11-PHASE-4E-…` | | 4F | Restliche Admin-Bereiche (contacts, categories, presets, footer-codes, users, roles, newsletter, reports, invoices, coupons, payments, portal-switcher) | `13-PHASE-4F-…` | | 4G | Restliche Customer-Bereiche (invoices, tokens, bookings, company-switcher, press-kits) | `12-PHASE-4G-…` | | 4H | Customer „Meine Pressemitteilungen" Mockup-Stil (Counter-Strip, Saved-Views, Filter-/Active-Chips, Portal-Pills, Inline-Actions, Row-Tint, 3-stufiger Empty-State, Aktionen-Legende) | `14-PHASE-4H-…` | | 4I | Admin „Pressemitteilungen" — Mockup-Patterns übertragen | `15-PHASE-4I-…` | | 4J | Dashboard-PM-Listen mit 4H/4I-Patterns | `16-PHASE-4J-…` | ### Nächste sinnvolle Schritte (Priorität) > Die hub-flux-Roadmap ist mit Phase 6 **vollständig** abgeschlossen. > Alle weiteren Themen sind eigene Initiativen. **🟡 In Planung — Phase 7 (Press-Release-Form-Refactor):** Mockup `User Neue Mitteilung presseportale.html` wird auf den Customer-Create/Edit-Flow übertragen. Plan-Doc: `19-PHASE-7-PRESS-RELEASE-FORM.md`. Päckchen 7A (Migrations) → 7B (flux:editor + Sanitizer) → 7C (Customer-Create-UI) → 7D (Customer-Edit-UI) → 7E (Anhänge-Manager) → 7F (Scheduling/Embargo, optional). 1. **Manueller Dark-Mode Smoke-Test**: Im Browser User-Menü → Erscheinung → „Dunkel" und durch die Hauptseiten klicken (Dashboard, Listen, Detail, Security mit QR, Tokens). Erwartung: Lesbar + konsistent. Kleine Polish-Runde, falls visuelle Auffälligkeiten. 2. **PM-Form-Wizard-Refactor**: Mockup `User Neue Mitteilung presseportale.html` auf den bestehenden Press-Release-Create/Edit-Flow übertragen. Größere Aktion mit eigener Phase. 3. **Web-Frontend-Block** (eigenständig, NICHT Teil von Phase 1–6): Die noch ungenutzten Mockups `Startseite Tailwind.html`, `Startseite presseecho Tailwind.html`, `Branchenseite Tailwind.html`, `Detailseite Tailwind.html`, `Veröffentlichen Tailwind.html` sind Public-Facing-Pages der beiden Portale (businessportal24 + presseecho), nicht Portal/Backend. Würde eine **eigene Roadmap** bekommen, weil andere Build-Pipeline (`vite.web.config.js`), andere Komponenten und ein ganz anderer Stil-Stack (Source-Serif-Headlines, Brand-orange für businessportal24).