Doku: Stand & Wiedereinstieg-Abschnitt im Entwicklungsplan

Klarer Status (Phasen 0-4 + 5.1 fertig, 5.2/5.3 teilweise) und konkrete
Reihenfolge fuer den Wiedereinstieg in die verbleibende Blade-Component-Arbeit
(visuelle QA noetig, eine Component pro Commit). Hinweise zu ausgeschlossenen
User-Dateien (sidebar, web/**) festgehalten.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

dev/optimize/entwicklungsplan.md

@@ -3,6 +3,25 @@
 > Konsolidiert aus `system-optimierung-analyse-codex.md` und `system-optimierungen-analyse-claude.md` (Stand 18.06.2026).
 > Reihenfolge nach **Risiko/Nutzen**: erst Korrektheit & Security, dann risikoarme Deduplikation, dann größere Extraktionen.
 
+---
+
+## Stand & Wiedereinstieg (zuletzt: 19.06.2026)
+
+**Fertig:** Phasen **0, 1, 2, 3, 4** vollständig · **5.1** vollständig · **5.2 Teil 1** (Form-Rules-Concern) · **5.3 Teil 1+2** (`Contact::displayName()`, `Category::localizedName()`).
+Gesamttest-Suite zuletzt grün (**818 passed, 1 skipped**), Pint sauber. Jeder Schritt ist ein eigener Commit (`git log` Präfix „Optimierung X.Y").
+
+**Hier geht es weiter** — der gesamte Rest ist **Blade-Component-Extraktion** und braucht **visuelle Kontrolle im Browser** (die automatischen Tests prüfen nur Text-Präsenz, keine Optik). Empfehlung: **eine Component pro Commit**, danach im Browser gegenchecken (`vendor/bin/sail npm run dev`). Reihenfolge des Wiedereinstiegs:
+
+1. **5.4 Seiten-Struktur-Components** (risikoärmster UI-Einstieg, rein additiv): `<x-portal.page-header>`, `<x-portal.table-panel>`, `<x-portal.empty-state>` usw. — je Component erst die Komponente bauen (Muster: bestehende `<x-portal.stat-card>`), dann eine Admin-Seite umstellen und visuell prüfen, dann die übrigen.
+2. **5.3 Rest** (Badges/Formatierung): zuerst die Call-Sites von `portalBadgeColor()` klären (in `companies/index`, `companies/show`, `contacts/index` definiert — Aufruf-Stellen wirken teils tot, vor `Portal::badgeColor()` prüfen, ob die Methoden überhaupt noch gerendert werden); dann `PressReleaseStatus`-Badge-Methode + `<x-portal.portal-badge>`/`<x-portal.status-badge>`/`<x-portal.money>`/`<x-portal.datetime>`.
+3. **5.2 Rest**: gemeinsamer `UserUpsertService`/`SaveUserAction` (Achtung: Anlegen vs. Bearbeiten divergieren stark — Bearbeiten trägt zusätzlich Profil/Kontakte/Passwort/2FA; nur den wirklich gemeinsamen Persistenz-Kern ziehen) + Blade-Feld-Components (`billing-fields`, `company-link-picker`, `role-checkboxes`, `contact-fields`).
+4. **5.5 Flash/Auth-Components**.
+5. **Phase 6** (Web-Frontend) — separat, dem User gehörend, vor jedem Löschen bestätigen lassen.
+
+**Wichtig beim Wiedereinstieg:** `resources/views/components/layouts/app/sidebar.blade.php` gehört dem User und bleibt aus allen Commits ausgeschlossen (`git reset -q -- …` vor jedem `git add`). `resources/views/web/**` und `components/web/**` erst in Phase 6.
+
+---
+
 ## Arbeitsregeln (für jeden Schritt)
 
 - **Test-First bei Korrektheits-/Verhaltensänderungen** (Phase 0): erst einen Pest-Test schreiben, der das Soll-Verhalten festschreibt, dann ändern.