Plan: R0 komplett + R1.1/R1.3 erledigt

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Kevin Adametz 2026-07-03 08:08:45 +00:00
parent 54a2e64698
commit 1e9c2f96ed

View file

@ -6,6 +6,13 @@
---
## Stand & Wiedereinstieg (zuletzt: 03.07.2026)
**Phase R0 komplett; R1 bis auf [EXTERN]-Punkte fertig.** Erledigt: R0.1–R0.5 (Variant-Routen raus, gdpr_consent_at in allen drei Registrierungspfaden, Newsletter-Binding config-aware + fail-fast, Seeder produktionssicher inkl. PlanSeeder + Dev-User-Guard, Fehlerseiten 403/404/419/500/503 self-contained) · R1.1 (Gate safe-by-default `true`, Legacy-/Grandfathered-Pfade per Test festgeschrieben, Scope-Logik war korrekt) · R1.3 (Quota-Reset als finales Tarif-Modell-Verhalten dokumentiert).
Offen in R1 (alle [EXTERN]): R1.2 Stripe-Live-Sync, R1.4 Preisfreigabe, R1.5 Refund-Entscheidung. Suite nach R1: 857 passed.
---
## Ausgangslage (Stand 03.07.2026)
- **Testsuite komplett grün:** 838 passed, 1 skipped (3.678 Assertions, ~70 s).
@ -30,26 +37,26 @@
## Phase R0 — Korrektheit & kaputte Pfade (klein, sofort, Test-First)
- [ ] **R0.1 Variant-Routen reparieren** — `routes/web.php:211-227`: `/variant-1` + `/variant-2` verweisen für die Businessportal-Domain auf `web.businessportal24-variant-float-glow` / `-glass-gradient` — **diese Views existieren nicht** → 500. Entscheidung: Routen entfernen (Design-Experimente sind abgeschlossen) oder auf `web.businessportal24` zurückfallen. Regressionstest.
- [ ] **R0.2 `gdpr_consent_at` im Registrierungsflow befüllen** — Feld existiert (Model-Cast + Migration), wird aber **nirgends geschrieben** (verifiziert 03.07.). Bei Registrierung (Fortify `CreateNewUser`), Magic-Link-/Social-Provisioning (`CustomerAccountProvisioner`) setzen. DSGVO-relevant. Test-First. *(= rev-1 aus migration-Doku)*
- [ ] **R0.3 Newsletter-Sync-Binding ehrlich machen** — `AppServiceProvider.php:47` bindet `NewsletterSyncClient` **unconditional** an `NullNewsletterSyncClient`; `NEWSLETter_SYNC_ENABLED=true` bewirkt nichts, das Admin-UI (`admin/newsletter/sync`) suggeriert aber eine funktionierende Sync. Fürs Release: No-Op bleibt (echte Sync ist nachgelagert), aber Binding config-aware machen und im Admin-UI den Placeholder-Status sichtbar ausweisen. Test.
- [ ] **R0.4 Seeder produktionssicher machen** —
- [x] **R0.1 Variant-Routen reparieren** — `routes/web.php:211-227`: `/variant-1` + `/variant-2` verweisen für die Businessportal-Domain auf `web.businessportal24-variant-float-glow` / `-glass-gradient` — **diese Views existieren nicht** → 500. Entscheidung: Routen entfernen (Design-Experimente sind abgeschlossen) oder auf `web.businessportal24` zurückfallen. Regressionstest.
- [x] **R0.2 `gdpr_consent_at` im Registrierungsflow befüllen** — Feld existiert (Model-Cast + Migration), wird aber **nirgends geschrieben** (verifiziert 03.07.). Bei Registrierung (Fortify `CreateNewUser`), Magic-Link-/Social-Provisioning (`CustomerAccountProvisioner`) setzen. DSGVO-relevant. Test-First. *(= rev-1 aus migration-Doku)*
- [x] **R0.3 Newsletter-Sync-Binding ehrlich machen** — `AppServiceProvider.php:47` bindet `NewsletterSyncClient` **unconditional** an `NullNewsletterSyncClient`; `NEWSLETter_SYNC_ENABLED=true` bewirkt nichts, das Admin-UI (`admin/newsletter/sync`) suggeriert aber eine funktionierende Sync. Fürs Release: No-Op bleibt (echte Sync ist nachgelagert), aber Binding config-aware machen und im Admin-UI den Placeholder-Status sichtbar ausweisen. Test.
- [x] **R0.4 Seeder produktionssicher machen** —
- `PlanSeeder` (Starter/Business/Pro/Agency) wird von `DatabaseSeeder` **nicht** aufgerufen → in den Produktions-Seed-Pfad aufnehmen (eigener `ProductionSeeder` oder Aufnahme + Guard).
- `PaymentOptionSeeder` schreibt Platzhalter (`prod_placeholder_monthly`, `price_placeholder_monthly`, …) → echte IDs via `billing:sync-stripe-plans` bzw. Seed anpassen (R1.2-Abhängigkeit).
- Test-User (`admin@pressekonto.test`, `test@example.com`, Passwort `password`) in `DatabaseSeeder` nur noch in `local`/`testing` anlegen.
- [ ] **R0.5 Fehlerseiten erstellen** — `resources/views/errors/` existiert nicht → 404/500/503 (mind. 404 + 503 theme-/domain-aware fürs Web, neutrale Variante fürs Portal). Render-Tests.
- [x] **R0.5 Fehlerseiten erstellen** — `resources/views/errors/` existiert nicht → 404/500/503 (mind. 404 + 503 theme-/domain-aware fürs Web, neutrale Variante fürs Portal). Render-Tests.
---
## Phase R1 — Backend-Release-Entscheidungen (Billing/Gates)
- [ ] **R1.1 Buchungs-/Tarif-Gate prüfen & bereinigen (User-Vorgabe 03.07.)** — Das Gate muss vollständig geprüft und bereinigt werden; **Legacy-Buchungen müssen funktionieren** (Bestandskunden mit Alt-Abo/Grandfathering dürfen veröffentlichen). Ist-Stand beim Testen: ohne gebuchtes Paket keine Veröffentlichung möglich (Gate lokal scharf via `.env`: `BILLING_ENFORCE_BOOKING=true`) — Soll-Verhalten bestätigt. Teilschritte:
- [x] **R1.1 Buchungs-/Tarif-Gate prüfen & bereinigen (User-Vorgabe 03.07.)** — Das Gate muss vollständig geprüft und bereinigt werden; **Legacy-Buchungen müssen funktionieren** (Bestandskunden mit Alt-Abo/Grandfathering dürfen veröffentlichen). Ist-Stand beim Testen: ohne gebuchtes Paket keine Veröffentlichung möglich (Gate lokal scharf via `.env`: `BILLING_ENFORCE_BOOKING=true`) — Soll-Verhalten bestätigt. Teilschritte:
- Alle Gate-Pfade durchgehen: `User::hasActiveBooking()`, `hasUnlimitedPressReleaseQuota`, `openSinglePurchaseCount()`, `UserPaymentOption::scopeActiveNow()`/`scopeGrandfatheredNow()`, Submit-Gate im `PressReleaseService`.
- **Legacy-Buchungen end-to-end testen:** migrierter User mit Alt-Abo (grandfathered, gültiges `grandfathered_until`) kann einreichen/veröffentlichen; abgelaufener Bestandsschutz wird korrekt geblockt (`NULL = abgelaufen`, Entscheidung 19.06.).
- Config-Default absichern: `config/billing.php` default `false` — bei vergessenem Prod-Env-Key liefert `hasActiveBooking()` für **alle** `true` → Default auf `true` drehen oder Runbook-Pflichtkey; `.env.example` korrigieren.
- Suite + manueller Submit-Flow (mit/ohne Buchung, mit Legacy-Buchung) gegengetestet.
- [ ] **R1.2 Stripe produktiv vorbereiten** — `billing:sync-stripe-plans` gegen **Live-Mode** ausführen (bislang nur Test-Mode); `STRIPE_PRICE_SINGLE_PM` setzen (sonst ist Einzel-PM-Checkout stumm deaktiviert, `CheckoutController.php:58`); Plan-`stripe_price_id_monthly/_yearly` gepflegt (sonst Abo-Checkout deaktiviert). Danach Checkout-Smoke-Test inkl. Webhook. **[EXTERN: Live-Stripe-Zugang]**
- [ ] **R1.3 Quota-Reset-Provisorium festschreiben** — `ResetMonthlyPressReleaseQuota` ist als „temporärer Stub bis zum echten Tarif-/Credit-Modul" markiert, läuft aber monatlich per Scheduler. Prüfen ob das Verhalten fürs Release korrekt ist (Zusammenspiel mit Credit-Wallet/Add-ons); Doc-Kommentar aktualisieren oder Logik ersetzen.
- [x] **R1.3 Quota-Reset-Provisorium festschreiben** — `ResetMonthlyPressReleaseQuota` ist als „temporärer Stub bis zum echten Tarif-/Credit-Modul" markiert, läuft aber monatlich per Scheduler. Prüfen ob das Verhalten fürs Release korrekt ist (Zusammenspiel mit Credit-Wallet/Add-ons); Doc-Kommentar aktualisieren oder Logik ersetzen.
- [ ] **R1.4 Preise/Lineup final abstimmen** — `PreisePageData.php:44` TODO („Lineup/Preise hängen am Bookings-/Magic-Link-Rework"): öffentliche Preisseite (correction/update/depublish-Pfade) gegen finale Preisliste prüfen. **[EXTERN: Preisfreigabe]**
- [ ] **R1.5 Refund-Workflow: Entscheidung** — laut hub-flux offen. Empfehlung: nachgelagert (Refunds initial direkt im Stripe-Dashboard), Entscheidung dokumentieren.