Kevin Adametz
1cd4d8e33a
Kriterien vom Auftraggeber (12.06.2026): Quelle der Aktiv-Erkennung ist
ausschliesslich das read-only Rechnungsarchiv legacy_invoices (D-12).
Legacy-Rechnungen bleiben Archiv; neue manuelle Rechnungen entstehen im
MAN-Rechnungskreis.
- Aktiv-Regel: juengste Rechnung pro (Portal, Legacy-Vereinbarung) mit
payment_option.type=recurring und user_payment_option.status=active;
next_due_date max. --grace-months (Default 12) ueberfaellig, sonst
stale -> bleibt reines Archiv. Einmal-Kaeufe werden nie uebernommen.
- Uebernahme als grandfathered in user_payment_options:
current_period_end = next_due_date, Betraege/Intervall der letzten
Legacy-Rechnung in legacy_conditions -> der taegliche MAN-Lauf
(billing:generate-manual-invoices) fakturiert zum gewohnten
jaehrlichen Rhythmus weiter. Versteckte Katalog-Platzhalter
LEGACY-{PE|BP}-{Artikel} in payment_options.
- Replay-faehig (D-18): Re-Runs aktualisieren anhand der Legacy-IDs in
legacy_conditions statt zu duplizieren — die Kern-Migration laeuft
kurz vor dem Relaunch erneut.
- Optionen: --dry-run, --as-of, --grace-months, --no-report; JSON-Report
nach storage/app/migration/. Dry-Run gegen Test-Snapshot: 22 aktive
jaehrliche Vereinbarungen, davon 4 sofort faellig, 0 stale.
- Doku: MIGRATION-STEPS.md (Runbook-Reihenfolge nach archive-invoices),
05-DATABASE-MERGE §5.6, 12-NAECHSTE-SCHRITTE 6.6, 08-PROGRESS,
PHASE-9-Plan + Checkliste.
Tests: GrandfatherLegacySubscriptionsTest (7, inkl. End-to-End
Migration -> MAN-Rechnung mit Legacy-Betraegen). Suite: 475 passed,
4 skipped. Pint clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
16 KiB
16 KiB
12 – Nächste Schritte (Roadmap)
Stand: 2026-05-04
Quellen: 03-MIGRATION-PLAN.md, 08-PROGRESS.md, 11-NOCH-ZU-TUN-OPTIMIERUNGEN.md, 09-REVIEW-QUALITAET.md
Dieses Dokument bündelt alles, was laut Entwicklungsplan noch offen ist, in einer einzigen Übersicht – nach Priorität und Phase sortiert. Stand der Test-Suite: 180 Tests grün, 3 geskippt, 0 Fehler.
Legende: 🔴 hoch · 🟡 mittel · 🟢 niedrig · ⏸️ vertagt · ⬜ offen · 🔄 in Arbeit
1. Schnell-Status
Was ist fertig
- Phase 0 – Vorbereitung (bis auf Stripe-Daten vom Auftraggeber)
- Phase 1 – Fundament (Schema, Models, Factories, Seeder, Migrations grün)
- Phase 2 – Auth & Tenancy (Magic-Link, Portal-Scope, Portal-Switcher, Roll-Aware-Login-Redirect)
- Phase 3 – Admin-UI (Press Releases, Categories, Footer-Codes, Companies, Contacts, Users, Roles alle real angebunden)
- Phase 4 – Customer-Portal (jetzt als „Mein Bereich" unter
/admin/me/*ins Admin-Panel konsolidiert) - Phase 5 (teilweise) – PressReleaseService inkl. Reject-Reason + Audit-Log, BlacklistService, ImageService, HasUniqueSlug-Trait
- Phase 6 – Daten-Migration: Kern komplett (Users/Companies/Contacts/PMs/Bilder, idempotent, Bilder-Sync); Legacy-Rechnungen brauchen einen Vollimport-Nachziehschritt
- Phase 7 – API v1 vollständig (Endpunkte, Sanctum, Rate-Limit, OpenAPI, Tests, Legacy-Cut, Kundenreport)
Was steht als Nächstes an
- Externe Abhängigkeit klären (siehe §2): Stripe-Keys + Grandfathering-Kriterien vom Auftraggeber.
- Legacy-Rechnungen vollständig importieren (siehe §8): DB-Struktur prüfen/erweitern, Import-Skript finalisieren, Status + User-Zuordnung erhalten, PDF-Erzeugung aus Legacy-Daten beim Abruf.
- PM-Veröffentlichung abrunden: Inline-Edit durch Admin, Bulk-Aktionen, In-App-Notifications (Bell-Icon).
- Newsletter wieder aufnehmen (P3.7 + P5.3 – aktuell vertagt).
- Phase 8 (Stripe-Billing) als größter Brocken – sobald Stripe-Daten da sind.
- Phase 10 (Härtung) + 11 (Deployment) – Security-Review, Coverage-Ziel, Staging-Rehearsal, DNS-Cutover.
2. Externe Blocker (Auftraggeber liefert)
Diese Punkte können wir nicht selbst anstoßen – ohne sie blockt P8 und teilweise P11.
| # | Aufgabe | Plan-Ref | Wirkung |
|---|---|---|---|
| ⬜ 0.5 | Stripe-Test-Account + API-Keys | 03-MP §0 | P8 komplett blockiert |
| ⬜ 0.6 | Liste der neuen Stripe-Produkte (Preisliste) | 03-MP §0 | P8.2 blockiert |
| ⬜ 0.7 | Liste der aktiven Alt-Abos (oder Kriterien) für Grandfathering | 03-MP §0 | P6.6 + P8.8 blockiert |
| ⬜ 11.4 | Finale Texte fürs Go-Live-Mailing (Passwort-Reset/Sicherheitshinweis) | 03-MP §11 | Versand am Go-Live blockiert; Command + Mailable selbst sind fertig |
| ⬜ 11.5 | Freigabeliste + operative Mailtexte für API-Kunden-Migration | 03-MP §11 | Versand blockiert; Kundenreport selbst ist fertig |
Empfehlung: Diese fünf Punkte als kompakte Mail/Liste an den Auftraggeber – ohne sie kann der Go-Live-Pfad nicht abgeschlossen werden.
3. Pressemitteilungs-Block: Nice-to-Have-Erweiterungen
Der Kern (Erstellen → Submit → Review → Publish/Reject mit Reason + Audit-Log) ist fertig. Diese Erweiterungen würden den Workflow noch runder machen:
| # | Aufgabe | Priorität | Aufwand |
|---|---|---|---|
| ⬜ pm-x1 | Inline-Edit + „Speichern & Veröffentlichen" auf einer Seite im Admin – heute zwei separate Schritte | 🟡 | 0.25 d |
| ⬜ pm-x2 | Bulk-Aktionen im Admin-Index: mehrere PMs auf einmal Veröffentlichen/Ablehnen (mit gemeinsamer Begründung) |
🟡 | 0.5 d |
| ⬜ pm-x3 | In-App-Notifications (Bell-Icon in der Sidebar) für Customer: „PM veröffentlicht/abgelehnt" – ergänzt heutige Mail | 🟡 | 0.5–1 d |
| ⬜ pm-x4 | Permission-Granularität: press-releases:review (lesen + freigeben) vs. press-releases:publish (final veröffentlichen) trennen, falls Editor nicht direkt veröffentlichen soll |
🟢 | 0.25 d |
4. Phase 1 – Restarbeiten
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 1.8 | DefaultAdminUserSeeder + SalutationTranslationSeeder ergänzen |
🟢 | 🔄 |
| 1.10 | Zentrale Factory-Smoke-Suite (alle Factories erzeugen valide Models) | 🟢 | 🔄 |
5. Phase 3 – Admin-UI: Restarbeiten
| # | Bereich | Aufgabe | Priorität | Status |
|---|---|---|---|---|
| 3.7 | Newsletter | Subscriber-Liste + CSV Im-/Export | 🟡 | ⏸️ vertagt 2026-05-04 |
| 3.8 | Invoices (neu) | Liste, Detail, Stripe-Status, PDF-Download | 🔴 | ⬜ wartet auf P8 |
| 3.9 | Legacy-Invoices Admin | Admin-Spiegel zur Customer-Sicht finalisieren | 🟡 | ✅ Übersicht mit Filtern, Mapping-Hinweisen und PDF-Download umgesetzt; Navigation heißt Legacy Rechnungen |
| 3.10 | Payments | Liste + Detail | 🔴 | ⬜ wartet auf P8 |
6. Phase 4 – Customer-Portal: Restarbeiten
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 4.2 | Customer-Dashboard: aktive Abos + offene neue Rechnungen | 🟡 | 🔄 wartet auf P8 |
| 4.4 | Neue Rechnungen einsehen & PDF-Download | 🔴 | 🔄 wartet auf P8 |
7. Phase 5 – Domain-Services: Restarbeiten
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 5.3 | NewsletterService neu (Subscribe / Confirm / Unsubscribe mit Token) |
🟡 | ⏸️ vertagt 2026-05-04 |
| 5.4 | CompanyService (Aktivierung, Logo-Upload, Footer-Code-Management) |
🟡 | ⬜ |
| 5.7 | Domain-Events + Listeners (PressReleasePublished → SendPublishNotification etc.) |
🟢 | 🔄 nur Mailables, keine echten Events |
| 5.8 | Vollständige Service-Test-Suite (Coverage > 70 %) | 🟡 | 🔄 |
Hinweis:
ImageService(5.5) hat noch einen offenen Restpunkt: Legacy-Thumbnail-Redirect – kein Blocker, aber nice für SEO-Kontinuität alter Bild-URLs.
8. Phase 6 – Daten-Migration: Restarbeiten
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 6.5d | Legacy-Rechnungen Vollimport: alle bestehenden Rechnungen aus den Legacy-DBs inkl. Status, Beträgen, Datum, Zahlart, vollständigem Raw-Snapshot und User-Zuordnung importieren; legacy:archive-invoices schreibt Import-Report + PDF-Payload; PDF-Erzeugung bleibt DB-basiert/on-demand statt Datei-Migration |
🔴 | ✅ umgesetzt 2026-05-04; Rehearsal gegen Produktiv-Snapshot bleibt P6.10 |
| 6.6 | legacy:grandfather-subscriptions (aktive Alt-Abos übernehmen) |
🔴 | ✅ umgesetzt 2026-06-12 (Kriterien vom Auftraggeber: Quelle ist das Rechnungsarchiv — jüngste Rechnung pro Vereinbarung mit recurring + active; Übernahme als grandfathered mit current_period_end = next_due_date, MAN-Kreis fakturiert weiter; Replay-fähig, Rehearsal bleibt P6.10) |
| 6.10 | Rehearsal-Lauf gegen produktiven Snapshot auf Staging | 🔴 | ⬜ |
Wichtig für 6.5d: legacy:archive-invoices importiert jetzt Rechnungsdaten, Billing-Adress-Snapshot und User-Payment-Snapshot in legacy_invoices.raw_snapshot/pdf_payload, zählt unzugeordnete Legacy-User im Report und lässt diese Rechnungen trotzdem im Archiv. Für Legacy-Rechnungen bleibt die bestehende Logik erhalten: Rechnung liegt als Datenbankdatensatz vor und das PDF wird bei Bedarf auf Knopfdruck aus diesen Daten erzeugt. Neue Stripe-Rechnungen werden separat in P8 geplant. Der finale Nachweis der Vollständigkeit erfolgt weiterhin im Staging-Rehearsal mit aktuellem Produktiv-Snapshot.
9. Phase 8 – Stripe-Billing (komplett offen, größter Brocken)
Hängt komplett an §2 (Stripe-Account + Produktliste).
| # | Aufgabe | Priorität | Aufwand |
|---|---|---|---|
| 8.1 | Stripe-Setup (.env, Cashier vs. raw stripe-php) |
🔴 | 0.25 d |
| 8.2 | PaymentOption-Admin + Sync zu Stripe Products/Prices (stripe:sync-products) |
🔴 | 0.5 d |
| 8.3 | Checkout-Flow im Customer-Portal (Stripe Checkout Session + Rückkehr-URL) | 🔴 | 0.5 d |
| 8.4 | Webhook-Controller /webhooks/stripe + Event-Handler (checkout-session-completed, invoice-paid, invoice-payment-failed, subscription-deleted) |
🔴 | 0.5 d |
| 8.5 | InvoiceNumberGenerator ({YYYY}{MM}-{seq}) |
🟡 | 0.25 d |
| 8.6 | PDF-Blade + InvoiceService |
🟡 | 0.25 d |
| 8.7 | Mahnwesen vereinfacht (invoices:remind für Stripe-Fails) |
🟡 | 0.25 d |
| 8.8 | Grandfathering-Handler (ExpireGrandfatheredSubscriptions-Scheduler + Customer-Mail) |
🔴 | 0.25 d |
| 8.9 | Legacy-Rechnungen Archiv-UI im Admin finalisieren + DB-basierte Legacy-PDF-Erzeugung absichern | 🟡 | ✅ |
| 8.10 | Tests mit Stripe-Test-Mode (Fake-Webhooks) | 🔴 | 0.25 d |
Gesamt P8: ~2.5–3 Manntage netto, sobald Stripe-Daten vorliegen.
10. Phase 9 – Scheduler & Queues
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 9.1 | Supervisor/Queue-Worker-Setup dokumentieren (Dev + Prod) | 🟡 | ⬜ |
| 9.2 | Cron-Jobs für invoices:remind, grandfather:expire, newsletter:campaign-digest (optional) ergänzen |
🟡 | 🔄 (magic-links:purge + press-releases:purge-drafts da, P8/P5-Jobs fehlen) |
| 9.3 | Failure-Alerting (Log-Channel + Mail bei fehlgeschlagenen Jobs) | 🟡 | ⬜ |
11. Phase 10 – Testing & Härtung
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 10.1 | Coverage-Ziel 70 % auf app/Services und app/Actions |
🔴 | ⬜ |
| 10.2 | Architecture-Tests (Pest arch()) – z. B. „kein Volt-Volt darf direkt Mail::send aufrufen" |
🟡 | ⬜ |
| 10.3 | php artisan test --parallel grün |
🟡 | ⬜ |
| 10.4 | Manuelle QA-Checkliste durchgehen (siehe 06-FEATURES-SCOPE.md §15) |
🔴 | ⬜ |
| 10.5 | Security-Review: CSRF, CORS, Rate-Limits, File-Uploads, Magic-Link-TTL | 🔴 | ⬜ |
12. Phase 11 – Deployment
| # | Aufgabe | Priorität | Status |
|---|---|---|---|
| 11.1 | Produktiv-DB-Server provisionieren + Backups konfigurieren | 🔴 | ⬜ |
| 11.2 | Staging-Deployment + Smoke-Tests | 🔴 | ⬜ |
| 11.3 | Produktiv-Import-Rehearsal gegen aktuellen Legacy-Snapshot | 🔴 | ⬜ |
| 11.4 | Go-Live-Mailing (Passwort-Reset + Sicherheitshinweis) versenden | 🔴 | 🔄 (Code fertig, Texte/Versand offen) |
| 11.5 | API-Kunden-Kommunikation (Token-Migration) versenden | 🔴 | 🔄 (Report fertig, Texte/Versand offen) |
| 11.6 | DNS-Cutover-Plan: pressekonto.de auf neuen Server |
🔴 | ⬜ |
| 11.7 | Read-Only-Modus auf Legacy-Systemen während Final-Import | 🔴 | ⬜ |
| 11.8 | Abschalten der alten Symfony-Server (nach Review-Periode) | 🟡 | ⬜ |
13. Performance-Optimierungen (aus 11-NOCH-ZU-TUN)
Nicht zwingend für Go-Live nötig, aber fürs Polishing:
| # | Aufgabe | Priorität | Quelle |
|---|---|---|---|
| ⬜ opt-1 | Slow-Admin-Reports mit echten Daten füllen + auswerten | 🔴 | 11-NOCH §1 |
| ⬜ opt-2 | EXPLAIN auf Top-Slow-Queries laufen lassen, Indexe nachziehen | 🔴 | 11-NOCH §2 |
| ⬜ opt-3 | admin.users.edit aufteilen (Profil-Partial → BillingAddress-Partial → Volt-Komponente company-links → Volt-Komponente contact-links) |
🟡 | 11-NOCH §3.1 |
| ⬜ opt-4 | admin.companies.show – Kontakte-Tab als eigene Volt-Komponente isolieren |
🟡 | 11-NOCH §4 |
| ⬜ opt-5 | Listen weiter splitten (nur bei messbarer Langsamkeit, nicht prophylaktisch) | 🟢 | 11-NOCH §5 |
| ⬜ opt-6 | Billing-Dummy-Views durch echte Implementierung ersetzen | 🔴 | 11-NOCH §6 (= P3.8/3.10/3.11 in P8) |
| ⬜ opt-7 | Rollen-Index nur bei Bedarf optimieren (Pagination/Cache) | 🟢 | 11-NOCH §7 |
| ⬜ opt-8 | Slow-Requests zusätzlich in DB persistieren (Trends über Releases) | 🟢 | 11-NOCH §8 |
| ⬜ opt-9 | Report-UI erweitern (CSV-Export, Zeitraum-Schnellfilter, Vergleichsmodi) | 🟢 | 11-NOCH §9 |
14. Restpunkte aus dem Qualitätsreview (09-REVIEW)
Die kritischen Punkte aus §2 sind durchgängig behoben. Aus §3/§4 stehen noch aus:
| # | Aufgabe | Priorität | Quelle |
|---|---|---|---|
| ⬜ rev-1 | gdpr_consent_at im Registrierungsflow befüllen |
🔴 | 09-REVIEW §3 / §4.6 |
| ⬜ rev-2 | UserManagementTest.php (820 Zeilen) in tests/Feature/Admin/UserCrudTest.php, CompanyCrudTest.php, ContactCrudTest.php, FilterPresetTest.php aufteilen |
🟡 | 09-REVIEW §3.5 |
| ⬜ rev-3 | session()->flash() in inline Volt-Aktionen (ohne Redirect) durch $this->dispatch('notify', ...) ersetzen |
🟡 | 09-REVIEW §3.6 |
| ⬜ rev-4 | 04-DATA-MODEL.md um contact_user-Pivot ergänzen (Doku-Lücke) |
🟢 | 09-REVIEW §3.4 |
| ⬜ rev-5 | Drei user_filter_presets-Migrations zu einer zusammenführen (Hygiene vor Go-Live) |
🟢 | 09-REVIEW §3.2 |
| ⬜ rev-6 | ENUM → VARCHAR mit Enum-Cast prüfen, falls beim Rehearsal Lock-Probleme auf großen Tabellen auftreten | 🟢 | 09-REVIEW §3.7 |
15. Empfohlene Reihenfolge der nächsten Sessions
Folgende Tranchen-Reihenfolge priorisiert das Erreichen der Produktionsreife:
Tranche A – Legacy-Rechnungen Vollimport ✅ erledigt 2026-05-04
- P6.5d Source-Audit: Legacy-Rechnungstabellen, Statuswerte, benötigte PDF-Daten und User-Mapping geprüft
legacy:archive-invoiceszu vollständigem, idempotentem Import-/Report-Skript ausgebaut- DB-Vorbereitung mit
pdf_payload+pdf_generated_atnachgezogen - Customer-PDF-Abruf auf DB-basierte Legacy-PDF-Erzeugung abgesichert
Tranche B – PM-Block abrunden (~1 Tag, sofort möglich)
pm-x1Inline-Edit + „Speichern & Veröffentlichen" im Adminpm-x2Bulk-Aktionen im Admin-Indexpm-x3In-App-Notifications (Bell-Icon)rev-1gdpr_consent_atim Registrierungsflow (DSGVO)
Tranche C – Newsletter-Wiederaufnahme (~1 Tag)
- P5.3
NewsletterService(Subscribe/Confirm/Unsubscribe mit Token) - P3.7 Admin-Newsletter-UI (Subscriber-Liste + CSV)
Tranche D – Service-Härtung & Test-Coverage (~1 Tag)
- P5.4
CompanyService - P5.7 Domain-Events einführen
- P10.1 Coverage auf 70 % heben
- P10.2
arch()-Tests
Tranche E – Performance-Polishing (~0.5 Tage, optional)
opt-1+opt-2Echte Slow-Reports auswerten + EXPLAINopt-3admin.users.editaufteilen
Tranche F – Wartet auf Auftraggeber: P8 Stripe (~2.5–3 Tage)
- Sobald Stripe-Daten vorliegen: P8 komplett (8.1 – 8.10)
- P3.8 + P3.10 (Invoices/Payments-Admin echt anbinden)
- P4.2 + P4.4 (Customer-Dashboard + neue Rechnungen)
Tranche G – Phase 9 + 10 + 11 (~2–3 Tage)
- P9.1 – 9.3 Queue/Scheduler/Alerting
- P10.4 + 10.5 QA-Checkliste + Security-Review
- P11.1 – 11.3 Staging-Deployment + Rehearsal
- P11.4 + 11.5 Mailings versenden
- P11.6 – 11.8 DNS-Cutover + Legacy-Read-Only + Abschaltung
16. Aufwandsschätzung Rest
| Block | Aufwand | Abhängigkeiten |
|---|---|---|
| Tranche A (Legacy-Rechnungen Vollimport) | ✅ erledigt | Produktiv-Snapshot-Rehearsal bleibt P6.10 |
| Tranche B (PM-Polishing) | ~1 d | – |
| Tranche C (Newsletter) | ~1 d | – |
| Tranche D (Service-Härtung) | ~1 d | – |
| Tranche E (Performance) | ~0.5 d | – |
| Tranche F (Stripe + Billing) | ~3 d | Stripe-Daten ⬜ |
| Tranche G (Deployment) | ~2.5 d | Tranche F + Auftraggeber-Texte |
| Σ Restaufwand | ~9.5–10 Manntage | – |
Der Endspurt zum Go-Live (Tranche F + G) ist davon ~5.5 Tage und hängt komplett am Auftraggeber-Input.
17. Zusammenfassung: Was kann heute ohne externen Input passieren?
- Tranche B (PM-Polishing) – 1 Tag
- Tranche C (Newsletter) – 1 Tag
- Tranche D (Service-Härtung & Tests) – 1 Tag
- Tranche E (Performance-Polishing) – 0.5 Tage
- Restpunkte aus §14 (Quality-Review-Cleanup) – 0.5 Tage
= ~4 Manntage produktive Arbeit, bevor wir auf Stripe-/Go-Live-Daten vom Auftraggeber warten müssen.