Rebrand Hub+Flux

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

@@ -8,7 +8,15 @@
 
 ## Phase 2 — Customer-Dashboard auf Mockup-Stil
 
-**Status**: ⚪ später · **Aufwand**: ~½ Tag · **Risiko**: niedrig
+**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
@@ -40,26 +48,36 @@
 
 ## Phase 3 — Admin-Dashboard konsistent
 
-**Status**: ⚪ später · **Aufwand**: ~½ Tag · **Risiko**: niedrig
+**Status**: ✅ **abgeschlossen** (in Phase 1 + 4J)
+· **Aufwand**: ~½ Tag · **Risiko**: niedrig
 
-### Ziel
-`resources/views/admin/dashboard.blade.php` nutzt dasselbe Vokabular wie
-Customer-Dashboard.
-
-### Heutiger Stand
-Reines Tailwind mit `zinc-*`-Klassen, **keine** FluxUI-Komponenten,
-visuell aus der Zeit gefallen.
-
-### Schritte
-- KPI-Karten als `<x-portal.stat-card>`
-- Wenn Charts vorhanden: über `flux:chart` umsetzen (FluxUI Pro)
-- Recent-Activity-Liste in `flux:card` mit Hub-Akzenten
+> 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**: 🚧 iterativ · **Aufwand**: ~3–5 Tage gesamt · **Risiko**: niedrig
+**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.
@@ -73,9 +91,20 @@ Alle Volt-Pages im Admin- und Customer-Bereich nutzen denselben Hub-Stil.
     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.*`) — ⚪ pending
-  - **4E** = Profile/Settings (`settings.*`, `me.profile`, `me.security`) — ⚪ pending
-  - **4F** = Restliche Admin-Bereiche — ⚪ pending
+  - **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)
@@ -91,72 +120,125 @@ Alle Volt-Pages im Admin- und Customer-Bereich nutzen denselben Hub-Stil.
 
 ## Phase 5 — Dark Mode konsistent
 
-**Status**: ⚪ später · **Aufwand**: ~½ Tag · **Risiko**: niedrig
+**Status**: ✅ **abgeschlossen** · **Aufwand**: ~½ Tag (Großteil
+der Arbeit war Vorbereitung in Phase 0–4) · **Risiko**: niedrig
 
-### Ziel
-Dark Mode funktioniert sauber im Portal, **ohne doppelte UI-Pflege**.
+> 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.
+`dev/frontend/tailwind_v3/User Dashboard presseportale Dark.html`
+hat alle Dark-Tokens bereits vorgegeben — alle Werte sind in
+`design-tokens.css` übernommen.
 
-### Schritte
-1. In `shared/design-tokens.css` Dark-Werte ergänzen:
-   ```css
-   @media (prefers-color-scheme: dark) {
-       @theme {
-           --color-bg: #0E1218;
-           --color-bg-elev: #14181F;
-           --color-hub: #5A78C2;
-           --color-accent: #D9A560;
-           /* … */
-       }
-   }
-   .dark {
-       /* gleiche Werte für expliziten Switch */
-   }
-   ```
-2. `class="dark"` wird **nicht** mehr hardcoded gesetzt
-3. Flux Appearance-Switcher (`settings/appearance.blade.php`) steuert
-   `.dark` auf `<html>`
-4. Hub-Frontend bleibt erstmal Light-Only (so wie heute)
-
-### Erwartung
-- Settings → Appearance → „Dark" schaltet Portal um
-- Settings → Appearance → „System" folgt OS-Präferenz
-- Sidebar, Topbar, Dashboards, Listen, Forms — alles funktioniert
-- Hub-Landing und Hub-Auth bleiben Light
+### 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-Konsolidierung (optional)
+## Phase 6 — Auth-Cleanup
 
-**Status**: ⚪ optional · **Aufwand**: 0–1 Tag · **Risiko**: mittel
+**Status**: ✅ **abgeschlossen** · **Aufwand**: ~30 min · **Risiko**: niedrig
 
-### Frage
-Bleibt der Hub-Login (`auth/pressekonto`-Layout, Web-Build) so wie er ist?
-Oder konsolidieren wir auf den Portal-Build?
+> 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.
 
-### Pro Konsolidierung
-- Ein Build weniger
-- Konsistente Komponenten-Sprache
+### 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
 
-### Pro Beibehaltung (heutiger Stand)
-- Hub-Atmosphäre der Auth-Seiten (Konzentrische Kreise, Hub-Grid) ist
-  visuell sehr stark — würde verloren gehen
-- Hub-Auth ist **leichtgewichtig** (kein FluxUI im Bundle)
-- Vorlage `Login pressekonto A3 Tailwind.html` ist bewusst minimalistisch
+→ keine Action notwendig, bleibt offen.
 
-### Entscheidung
-Vermutlich **beibehalten**. Aber: Die alten Auth-Layouts
-`auth/simple.blade.php`, `auth/split.blade.php`, `auth/card.blade.php` aus
-dem Starter-Kit können vermutlich gelöscht werden, sobald geprüft ist,
-dass keine Komponente sie noch verwendet.
+---
 
-### Schritte (wenn konsolidiert)
-- Hub-Auth-CSS in `portal.css` ziehen (mit `@source` für die Tokens)
-- `auth/pressekonto`-Layout auf Portal-Build umstellen
-- Hub-Auth-Klassen (`.auth-card`, `.auth-grid`, `.auth-btn-primary`)
-  bleiben — laufen nur jetzt aus dem Portal-Bundle
-- `theme-pressekonto.css` aus dem Web-Build entfernen (oder behalten
-  für die Landing)
+## 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).