- dev/roadmap.md neu: alle offenen Punkte aus Plänen, Audits und Protokollen, gegen Code und Git abgeglichen (Stand v1.7.0) - Abgeschlossenes ins Archiv: 2026-09-01 → archive/2026-09-nutzergewinnung, 2026-09-11-audit → archive/2026-09-audit, lagacy-rechnungen → archive/legacy-rechnungen, Deploy-Protokoll v1.1.0, Umami-Snippets, Go-Live-Roadmap vom 20.07. - Aktiv bleiben eigene Ordner bildrechte/ (Plan Fassung 2, Decision-Update) und changelog/ (Decision-Update Changelog) - dev/README.md als Ordnerkarte neu, Verweise und zwei Code-Kommentare auf die neuen Pfade Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.5 KiB
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 indev/2026-09-11-audit/ENTWICKLUNGSPLAN.mdund 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-berlinnachmaingemerged (7b27ec5), Release-Tag v1.0.0, beides auf origin. Künftig Feature-Branches vonmain. - Stripe-Test-Artefakte bereinigen: Test-
stripe_idam Testuser, Test-Subscription-Zeilen, STR-Testrechnungen — damit die Rechnungsnummern-Sequenz sauber ist. - Monitoring scharf:
MONITORING_ALERT_EMAILgesetzt? 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.logauf 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 — erledigt 06.10.2026 (Branch
technik/volt-entfernen). 83 Komponenten aufLivewire\Component, 73 Routen aufRoute::livewire(), 88 Testdateien aufLivewire::test()/Livewire::actingAs();VoltServiceProvidergelöscht,livewire/voltentfernt (sonst keine Paketänderung).config/livewire.phpauf v4-Schlüssel:component_layout,component_placeholder,component_locations,make_command(SFC ohne ⚡). Befund dabei: Der alte Schlüssellayoutwar wirkungslos, Livewire 4 legte seinen Standardlayouts::appdarüber; alle 73 gerouteten Komponenten setzen ihr Layout aber selbst. CLAUDE.md, AGENTS.md,boost.json,.cursorrulesund der Skillvolt-developmentangepasst bzw. entfernt (von Hand —boost:updatehätte nebenbei alle Skills auf eine neue Boost-Fassung gehoben, das ist ein eigener Schritt). Suite 2.325 grün, einer übersprungen; Larastan und Pint ohne Meldung. Larastan erfasst die Komponenten weiterhin nicht: Es analysiert nur.php-Dateien, Single-File-Komponenten sind Blade-Dateien. Abhilfe wäre die Umwandlung einzelner großer Komponenten in Klassen-Komponenten (php artisan livewire:convert), kein Muss. -
Frontend-Audit-Reste aus
dev/archive/frontend-audits/ frontend-optimize-protokoll.mdsichten — 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).