From dc4e3978bc09607fc2d9de18fe75ff1f1fb541ac Mon Sep 17 00:00:00 2001 From: Kevin Adametz Date: Fri, 19 Jun 2026 13:25:22 +0000 Subject: [PATCH] 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) --- dev/optimize/entwicklungsplan.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/dev/optimize/entwicklungsplan.md b/dev/optimize/entwicklungsplan.md index 15b2e7a4..c90b661b 100644 --- a/dev/optimize/entwicklungsplan.md +++ b/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): ``, ``, `` usw. — je Component erst die Komponente bauen (Muster: bestehende ``), 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 + ``/``/``/``. +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.