presseportale/dev/frontend/hub-flux/03-WEITERE-PHASEN.md

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, <x-portal.stat-card>, <x-portal.hint-card> 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

• <x-portal.stat-card> — Stat-Card mit Slot + Strip-Variante
• <x-portal.hint-card> — Datenqualitäts-Hint mit Icon + Progress-Bar
• <x-portal.bridge-card> — 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 <x-portal.stat-card>, 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, <x-portal.stat-card>-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.

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).