presseportale/dev/roadmap.md

Roadmap / Offene Punkte

Stand: 20.07.2026 (Go-Live-Tag). Kurzfristiges zuerst; Details zu erledigten Phasen im Archiv (dev/archive/).

Hinweis 29.09.2026: Die laufende Planung steht in dev/2026-09-01/roadmap-2026.md, der Entwicklungsstand in dev/2026-09-11-audit/ENTWICKLUNGSPLAN.md und im jüngsten Umsetzungsaudit. Die Punkte unten stammen vom Go-Live-Tag; ihr Stand ist dort nicht nachgeführt und wird im Umsetzungsaudit vom 29.09. (Abschnitt 6.4) als „auf Live zu bestätigen" geführt.

Nachlauf Go-Live (kurzfristig)

• Go-Live-Mails an Bestandskunden: erst php artisan auth:send-go-live-mails --dry-run (Anzahl prüfen), dann scharf. Massenversand läuft über die Queue → Worker-Status vorher grün, Betriebsüberwachung während des Versands im Blick.
• API-Kunden-Mailing (Connektar & Co.) mit Hinweis auf neue Doku (/docs/api/v1) und Token-Migration — Texte [EXTERN].
• Git-Hygiene (R6.5): erledigt 20.07. — fix/zeitzone-europe-berlin nach main gemerged (7b27ec5), Release-Tag v1.0.0, beides auf origin. Künftig Feature-Branches von main.
• Stripe-Test-Artefakte bereinigen: Test-stripe_id am Testuser, Test-Subscription-Zeilen, STR-Testrechnungen — damit die Rechnungsnummern-Sequenz sauber ist.
• Monitoring scharf: MONITORING_ALERT_EMAIL gesetzt? Cron/Scheduler + Queue-Worker in Ploi überwacht?
• Umami-Snippets je Domain einbinden (dev/betrieb/umami.md).
• Connektar-API-Keys rotieren (mittelfristig — die Legacy-Keys sind über diverse Test-Kanäle gelaufen; Rotation über /customer/tokens).
• Alt-System endgültig abschalten, sobald ein paar Tage stabil: Webspace und Alt-DBs auf dem KAS stilllegen; vorher letztes Backup der Alt-DBs und Alt-Uploads sichern. Danach kann auch dev/migration/ (7 GB lokales Medien-Staging) auf ein Backup-Medium und vom Arbeitsrechner runter. Das KAS-Hosting selbst bleibt (E-Mail-Postfächer, Stand 06.10.2026); der SSH-Zugang des Altsystems ist geändert und deaktiviert.

Beobachten (erste Wochen)

• Betriebsüberwachung täglich: failed_jobs, Worker, Medien-Privatisierung.
• storage/logs/laravel.log auf neue Fehlermuster.
• Search Console: Indexierung der neuen Domains + 301-Ketten der Legacy-URLs (www-Redirects, .html-Redirects, presskit→Newsroom).
• MySQL-Auslastung (die Filesort-Spirale ist behoben; bei neuen Slow-Queries → Slow-Query-Log).

Nächste Entwicklungen / Optimierungen (Ideen-Backlog)

• Volt entfernen, auf Livewire-4-Single-File-Components umstellen (Betreiber, 05.10.2026). Seit Livewire 4 sind Single-File-Components eingebaut, mit derselben Syntax wie Volts Klassenkomponenten — Volt ist damit überflüssig. Umfang (Stand v1.1.0): 83 Komponenten unter resources/views/livewire (nur klassenbasiert, keine funktionale Volt-API, kein @volt), 73 Volt::route(), 549 Volt::test() in 80 Testdateien. Schritte nach dem offiziellen Upgrade-Leitfaden (livewire.laravel.com/docs/4.x/upgrading, „Upgrading Volt“): Livewire\Volt\Component → Livewire\Component; Volt::route() → Route::livewire(); Volt::test()/LivewireVolt::test() → Livewire::test(); VoltServiceProvider löschen und aus bootstrap/providers.php nehmen; composer remove livewire/volt. Livewire 4 findet resources/views/livewire standardmäßig (component_locations); config/livewire.php stammt noch aus v3 und sollte bei der Gelegenheit abgeglichen werden. Danach CLAUDE.md und die Boost-Richtlinien (Volt-Abschnitt, Skill volt-development) anpassen und prüfen, ob Larastan die Komponenten jetzt erfasst (offener Punkt aus dem Umsetzungsaudit 02.10., 5.6). Mechanische Umstellung, aber großflächig — als eigener Branch mit voller Suite, nicht nebenbei in einem Fach-Block.

• Frontend-Audit-Reste aus dev/archive/frontend-audits/ frontend-optimize-protokoll.md sichten — P2/P3-Punkte, die bewusst liegen geblieben sind.

• Offene [EXTERN]-Entscheidungen aus dem Release-Plan prüfen (dev/archive/release/entwicklungsplan-release.md): Preisfreigabe, Refund-Policy.

• Cache-Warmer im Scheduler (Startseite + Top-Kategorien alle 5 Min vorbauen), falls Kaltaufbauten nach Deploys stören — Option B aus der Performance-Session vom 20.07.; aktuell nicht nötig.

• Redis als Cache-/Queue-Store erwägen, wenn die Last wächst (aktuell database-Store, läuft stabil).