# 12 – Nächste Schritte (Roadmap)

**Stand:** 2026-05-04
**Quellen:** [`03-MIGRATION-PLAN.md`](./03-MIGRATION-PLAN.md), [`08-PROGRESS.md`](./08-PROGRESS.md), [`11-NOCH-ZU-TUN-OPTIMIERUNGEN.md`](./11-NOCH-ZU-TUN-OPTIMIERUNGEN.md), [`09-REVIEW-QUALITAET.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
1. **Externe Abhängigkeit klären** (siehe §2): Stripe-Keys + Grandfathering-Kriterien vom Auftraggeber.
2. **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.
3. **PM-Veröffentlichung abrunden**: Inline-Edit durch Admin, Bulk-Aktionen, In-App-Notifications (Bell-Icon).
4. **Newsletter wieder aufnehmen** (P3.7 + P5.3 – aktuell vertagt).
5. **Phase 8 (Stripe-Billing)** als größter Brocken – sobald Stripe-Daten da sind.
6. **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
1. P6.5d Source-Audit: Legacy-Rechnungstabellen, Statuswerte, benötigte PDF-Daten und User-Mapping geprüft
2. `legacy:archive-invoices` zu vollständigem, idempotentem Import-/Report-Skript ausgebaut
3. DB-Vorbereitung mit `pdf_payload` + `pdf_generated_at` nachgezogen
4. Customer-PDF-Abruf auf DB-basierte Legacy-PDF-Erzeugung abgesichert

### Tranche B – PM-Block abrunden (~1 Tag, sofort möglich)
5. `pm-x1` Inline-Edit + „Speichern & Veröffentlichen" im Admin
6. `pm-x2` Bulk-Aktionen im Admin-Index
7. `pm-x3` In-App-Notifications (Bell-Icon)
8. `rev-1` `gdpr_consent_at` im Registrierungsflow (DSGVO)

### Tranche C – Newsletter-Wiederaufnahme (~1 Tag)
9. P5.3 `NewsletterService` (Subscribe/Confirm/Unsubscribe mit Token)
10. P3.7 Admin-Newsletter-UI (Subscriber-Liste + CSV)

### Tranche D – Service-Härtung & Test-Coverage (~1 Tag)
11. P5.4 `CompanyService`
12. P5.7 Domain-Events einführen
13. P10.1 Coverage auf 70 % heben
14. P10.2 `arch()`-Tests

### Tranche E – Performance-Polishing (~0.5 Tage, optional)
15. `opt-1` + `opt-2` Echte Slow-Reports auswerten + EXPLAIN
16. `opt-3` `admin.users.edit` aufteilen

### Tranche F – Wartet auf Auftraggeber: P8 Stripe (~2.5–3 Tage)
17. Sobald Stripe-Daten vorliegen: P8 komplett (8.1 – 8.10)
18. P3.8 + P3.10 (Invoices/Payments-Admin echt anbinden)
19. P4.2 + P4.4 (Customer-Dashboard + neue Rechnungen)

### Tranche G – Phase 9 + 10 + 11 (~2–3 Tage)
20. P9.1 – 9.3 Queue/Scheduler/Alerting
21. P10.4 + 10.5 QA-Checkliste + Security-Review
22. P11.1 – 11.3 Staging-Deployment + Rehearsal
23. P11.4 + 11.5 Mailings versenden
24. 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.