79 lines
4.4 KiB
Markdown
79 lines
4.4 KiB
Markdown
# 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].
|
|
- [x] **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:
|
|
KAS-Hosting kündigen/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.
|
|
|
|
## 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).
|