Launch-pflichtiger Compliance-Slice: öffentliche Anfrage zu einer PM speist eine
manuelle Admin-Queue (keine KI).
- Migration legal_requests + Model + Enums (Type: dsgvo/personal_rights/report,
Status: open/in_progress/resolved/rejected) + Factory.
- Öffentliches Formular /release/{slug}/rechtliches (LegalRequestController +
web/legal-request.blade.php): typ-abhängiger Hinweistext (Alpine), E-Mail bei
DSGVO/Persönlichkeitsrecht erforderlich, zwei versteckte Honeypot-Felder,
Rate-Limit + Bremse "1 offene Anfrage pro PM/Typ". Regeltexte als Entwurf mit
TODO für rechtliche Finalisierung markiert.
- Routen bewusst in eigener routes/legal.php (entkoppelt vom laufenden Web-Umbau),
host-agnostisch via domains.php eingebunden.
- Admin-Bereich "Recht & Compliance": Sidebar-Nav mit Offen-Zähler, Volt-Queue
index/show (in Bearbeitung/erledigt/abgelehnt/wieder öffnen + interne Notiz).
- Tests: je Typ, Honeypots (Dataset), Bremse, Admin-Queue + Status-Übergänge.
- Doku: Detailplan WS-3-Status + Deployment-Migrationsreihenfolge ergänzt.
Hinweis: Der "Melden"-/E&F-Button auf der PM-Detailseite (release-detail.blade.php)
wird mit dem separaten Web-Frontend-Commit verdrahtet; Ziel ist legal-request.create.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Magic-Link und Pressekontakt-Zugang zu einer Seite (/anmeldelink) zusammengeführt;
altes Login-Modal entfernt, /pressekontakt-zugang leitet weiter.
- ContactAccessService deckt jetzt Firmen-E-Mail UND Pressekontakt-E-Mail ab,
portalübergreifend (ohne PortalScope). Eine E-Mail mehrfach hinterlegt → genau
ein Account, dem alle Firmen + Kontakte zugeordnet werden.
- Zugeordnete Firmen erhalten Pivot-Rolle 'responsible' (Schreibzugriff auf
Stammdaten, Kontakte, Pressemitteilungen) statt nur 'member'; bestehende
Lese-Pivots werden hochgestuft, Owner bleiben unangetastet.
- Neuer Login-Listener (SyncCompanyMembershipsOnLogin) frischt die Zuordnungen
bei JEDEM Login (Magic-Link, Passwort, Google) auf – auch nachträglich (API)
hinzugekommene Firmen/Kontakte mit gleicher E-Mail greifen.
- Auth-Bereich erzwingt Hellmodus: aus dem Portal übernommene .dark-Klasse wird
am <html> entfernt (Login war im Dark Mode hängengeblieben).
- Tests: Firmen-E-Mail-Login, Multi-Firmen-Aggregation, Schreibzugriff/Upgrade,
Per-Login-Re-Sync, Auth-Hellmodus. Sicherheits-Doku aktualisiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Befund (Review 16.06.): Der Volt-Login machte direkt Auth::attempt() und umging
Fortifys 2FA-Pipeline (2FA-Bypass); zusätzlich existierte der Fortify-POST /login
parallel mit schwächeren Post-Login-Regeln.
Fix (Volt-nativ):
- Volt-Login prüft Credentials ohne sofortiges Login; bei aktivem 2FA wird der
Session-Vertrag login.id/login.remember gesetzt und auf eine neue Volt-
2FA-Challenge-Seite (/two-factor-challenge) geleitet, die an Fortifys
bestehenden Controller postet (TOTP + Recovery-Code).
- Gemeinsame Post-Login-Logik in App\Support\LoginRedirect (rollengerechtes
Home + 403-sicherer intended-Redirect), genutzt von Volt-Login UND Response.
- RoleAwareLoginResponse implementiert jetzt LoginResponse UND
TwoFactorLoginResponse und erzwingt einheitlich: unverifiziert → Notice,
verifiziert-inaktiv → Logout+Fehler, sonst 403-sicherer Redirect. Damit ist
auch der direkte Fortify-POST-Pfad gehärtet.
Tests: 2FA-Übergabe, Challenge-Guard, voller TOTP-Flow, Fortify-POST blockt
inaktive User und hält Customer aus dem Admin-Bereich.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Firmen-Scope (Fundament):
- PM-Zugriff war hart an user_id (Autor) gebunden. Jetzt additiv: Autor ODER
Mitglied der zugeordneten Firma (Owner via owner_user_id oder company_user-
Pivot). Geändert in PressReleasePolicy (canManage) sowie den Queries der
Listen-, Show- und Edit-Komponenten. Helfer User::accessibleCompanyIds()/
canAccessCompany(). Solo-Owner unverändert; Firmenmitglieder sehen/bearbeiten
alle PMs ihrer Firma.
Magic-Link-Zugang für Pressekontakte (ContactAccessService):
- Öffentliches, enumeration-sicheres Formular (/pressekontakt-zugang) mit
Honeypot + Rate-Limit. Eine hinterlegte Kontakt-E-Mail führt zu einem lazy
angelegten, de-duplizierten customer-Account (aktiv, verifiziert über den
Magic-Link-Kanal), der den Firmen seiner Kontakte als Mitglied zugeordnet
wird. Versand über den bestehenden Login-Magic-Link (Generator + Consume
wiederverwendet) – keine Schema-Änderung, kein paralleles System.
- Dezenter Einstiegslink von der Login-Seite (PM-Frontend-Wiring später).
Tests: PressReleaseCompanyScopeTest (3), ContactAccessTest (6, inkl. De-Dup,
Enumeration-Sicherheit, Honeypot).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
E-Mail-Verifizierung (Entscheidung 15.06.):
- User implementiert MustVerifyEmail; Registrierung legt inaktives, rollenloses
Konto an und leitet auf die Danke-/Notice-Seite; Registered-Event versendet die
Verifizierungsmail. Bestätigter Link aktiviert das Konto + vergibt customer-Rolle
(ActivateUserAfterVerification). Backfill-Migration setzt email_verified_at für
alle Bestands-User (sonst würde die verified-Middleware ~59k aktive Legacy-User
aussperren). Seeder-User verifiziert.
Auth-Flow-Korrekturen:
- Magic-Link-Consume: rollensicherer Redirect ohne intended() (Customer landete
sonst per stale intended=/dashboard im 403-Admin-Bereich).
- Guest-Redirect (bootstrap/app.php) rollen-/verifizierungsbewusst statt fix
/dashboard – schließt die 403-Sackgasse auf /login und /register.
- Logout auf der Notice-Seite via echtes POST-Formular statt Livewire-Action
(behebt 419 beim Session-Invalidate).
- Magic-Link-Anforderung über eigenes Modal mit separater E-Mail-Eingabe.
- Unverifizierte Login-Versuche landen auf der Notice-Seite.
Sicherheitsfix Legacy-Rollen:
- UserImporter mappte Alt-Gruppe 2 (Self-Publisher) auf editor (= Admin-Zugriff).
Mapping auf customer korrigiert; Daten-Migration stuft die 65.950 fälschlichen
Legacy-Editoren auf customer herab. Echte admin/api-only bleiben unberührt.
Tests: Registration, EmailVerification, Authentication (Guest-Redirect),
MagicLinkLogin (Modal/Redirect/Regression), Legacy-Import (Gruppen-Mapping).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Tarif-Datenmodell (Decision-Update):
- plans: Starter/Business/Pro/Agency mit Monats-/Jahrespreis (Jahres =
10 x Monat), PM-Kontingent, Tageslimit, Stripe-IDs; idempotenter Seeder
- single_purchases: Einzel-PM, Extra-PM, Boost, PDF-Nachweis mit
Status-Lifecycle und Stripe-Checkout-Referenzen
- laravel/cashier ^16.5 installiert (freigegeben); User ist Billable,
Cashier-Migrationen published + ausgefuehrt; lokale invoices()-Relation
ueberschreibt bewusst die Cashier-Methode
Hybride Rechnungskreise (Entscheidung 12.06.2026):
- invoice_number_sequences + InvoiceNumberGenerator: atomare fortlaufende
Nummern pro Kreis (STR- fuer den neuen Stripe-Shop, MAN- fuer den
manuellen Legacy-Kreis); Alt-Archiv legacy_invoices bleibt unveraendert
- ManualInvoiceService + billing:generate-manual-invoices (Scheduler
taeglich 04:30): prueft aktive/grandfathered user_payment_options ohne
Stripe-Subscription auf erreichtes Periodenende, friert die
Rechnungsadresse als Snapshot ein, stellt die MAN-Rechnung aus
(Zahlungsziel billing.manual_due_days) und schaltet die Periode weiter;
Konditions-Overrides via legacy_conditions, sonst Netto-Preis +
billing.vat_rate; nicht abrechenbare Faelle werden geloggt und
beim naechsten Lauf erneut geprueft
Submit-Gate:
- User::hasActiveBooking() prueft jetzt echt (hinter
billing.enforce_booking): Cashier-Abo, bezahlter Einzel-/Extra-PM-Kauf
oder laufende Legacy-Vereinbarung (MAN-Kreis)
Suite: 468 passed, 4 skipped (17 neue Billing-Tests). Pint clean.
Offen fuer 9E: Stripe-Checkout/Webhooks, STR-Spiegelung, Slot-Logik auf
Plan-Kontingent, Migration der aktiven Legacy-Zahlungen in
user_payment_options.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Umbenennung presseportale → pressekonto in Domains, Themes und Dokumentation.
Design-Tokens, Portal-Shell, Customer-Dashboard, Auth- und Admin-PM-Views.
Artisan-Befehl migrate:legacy-media mit Tests und Hub-Flux-Entwicklungsdocs.
Co-authored-by: Cursor <cursoragent@cursor.com>
