Abschnitt 6 'Umsetzungsstand 17.06.2026': Fundament (Wallet/Ledger/Tier/Topup),
Launch-Funktionen (Extra-PM/Boost/Nachweis/UI/Gate), Phase-2-vorbereitet
(Pruefzaehler, Pfade C/D/G), offene Punkte. Nachzug zu dd5a937 (Dateiname
mit NFD-Umlaut wurde beim ersten Commit verfehlt).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bug: Im Submit-Modal navigierte 'Buchung auswaehlen' per wire:navigate direkt
zur Buchungsseite, OHNE vorher zu speichern -> im Erstellen ging die ganze PM
verloren, im Bearbeiten die ungespeicherten Aenderungen.
- Submit-Modal: neuer Prop booking-action; ist er gesetzt, speichert der Button
ueber eine Livewire-Aktion zuerst und navigiert erst danach
('Speichern & Buchung auswaehlen'). Fallback-href nur dort, wo bereits
gespeichert ist (Detailansicht).
- create/edit: Persistenz in persistDraft()/persistEdit() extrahiert;
saveDraftAndChooseBooking() speichert den Entwurf bzw. die Aenderungen und
leitet erst dann zur Buchung (Edit reklassifiziert bei Inhaltsaenderung).
- Beide Submit-Modals mit booking-action verdrahtet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- PM-Detailseite (Entwurf/Ueberarbeiten): ist kein Buchungs-Gate erfuellt,
erscheint statt 'Zur Pruefung einreichen' der Hinweis 'Noch keine Buchung'
mit Link zur Buchungsseite ('Buchung waehlen'). Entwurf speichern bleibt frei.
- phpunit pinnt BILLING_ENFORCE_BOOKING=false, damit der Gate in Tests
deterministisch bleibt (Tests, die ihn brauchen, setzen ihn per config)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
End-to-end-Aufladung der Credit-Wallet, spiegelt den Einzel-PM-Fluss:
- Paket-Staffel mit Bonus in config/credits.php (10->10, 25->27, 50->55,
100->115 Credits; price_cents netto, Stripe Tax ergaenzt USt.)
- credit_topups (Pending->Paid) + CreditTopupService: startTopup legt den
Pending-Kauf an, fulfill() schreibt die Wallet idempotent gut (credited_at)
- StripeCheckoutService::forCreditTopup via checkoutCharge + credit_topup_id
Metadata; ProcessStripeWebhook schreibt bei checkout.session.completed gut
- Checkout-Route /admin/me/checkout/credits/{pack} mit Rechnungsadress-Gate
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- ProofPdfService: Veroeffentlichungsnachweis 3 Credits pauschal, einmal pro
PM (Zweitdownload kostenfrei); ProofPdfRenderer erzeugt das PDF on-demand
aus vorhandenen PM-Daten (kein externer Renderer); GET-Download-Endpoint
/admin/me/press-releases/{id}/nachweis hinter downloadProof-Policy + Kauf-Gate
- ExtraPmPurchaseService: tier-gestaffelter Nachkauf (19/15/12/10/8) aus der
Wallet; verbucht als bezahlter SinglePurchase(ExtraPm) und greift damit in
die bestehende Kontingent-/Slot-Mechanik. InsufficientCreditsException
liefert das Mini-Checkout-Signal (required/available/shortfall)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eigener Pruef-Zaehler, getrennt von der Credit-Wallet (Paragraph 4.2/4.3):
- review_checks Ledger (eine Zeile je Pruefung, source free|credit,
charged_credits), aggregiert pro Account/Monat statt pro PM
- ReviewCheckService: Tageslimit (harte Bremse, nicht freikaufbar) ->
Monats-Freikontingent (tier-gestaffelt 4/12/30/60/120) -> Overflow
zieht 1 Credit/Pruefung aus der Wallet
- ReviewLimitException fuer das erreichte Tageslimit
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- published_at = Legacy-created_at (Publikationsdatum, Frontend-Sortier-
schlüssel) statt updated_at, das bei Alt-Daten oft den Massen-/Migrations-
stempel trägt und ein falsches "frisches" Datum erzeugte.
- created_at/updated_at per forceFill direkt im Import gesetzt (waren nicht
fillable, wurden still verworfen) – Import allein ist jetzt datumssauber.
- legacy:fix-timestamps korrigiert zusätzlich published_at (status=published).
- PM-UUID bleibt beim Re-Import/Delta-Lauf erhalten (kein Neu-Würfeln).
- MIGRATION-STEPS auf Zwei-Phasen-Strategie umgestellt: migrate, Phase 1 mit
--force, Phase 2 (Delta) ohne --force, Grandfather-Re-Run, Idempotenz-Tabelle.
- Tests: LegacyPressReleaseDateImportTest (published_at-Quelle, Entwurf,
Force-Re-Import erhält UUID + Datum).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kompakte Go-Live-Checkliste (Live-.env, Migrationen, einmalige Setups,
Stripe-Webhook, Cache-Warmup, Scheduler/Worker, Post-Deploy-Kontrollen).
WS-6 (Auth/Verifizierung/Google) und WS-7 im Detailplan als erledigt
markiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Das Abo-/Bestandsschutz-Gate (User::hasActiveBooking, BookingRequiredException,
Submit-Modal, API 402/422) war bereits implementiert und getestet. Ergänzt wird
die proaktive Block-UX:
- Kunden-Dashboard zeigt bei scharfem Gate (billing.enforce_booking=true) und
fehlender aktiver Buchung einen Banner "Buchung erforderlich, um zu
veröffentlichen" mit Link zur Buchungsseite. Bestandskunden (grandfathered)
sehen den Hinweis nicht; bei offenem Gate bleibt er unsichtbar.
- Tests: Banner aus (Gate offen) / an (Gate scharf, keine Buchung) /
Ausnahme für grandfathered.
Launch-Flip bleibt env-gesteuert (BILLING_ENFORCE_BOOKING), Dev-Default false –
.env.example und Detailplan (WS-5 ✅) dokumentieren den Schalter.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
/admin/me/buchungen-add-ons: Bestandsschutz raus aus dem gedrängten
"Aktueller Tarif"-Panel, eigener prominenter Paket-Block:
- Portal-Badge (fehlte bisher), Schild-Icon, Akzentleiste, Rahmen (ring)
- größere Typo, Netto-Preis + Intervall, Feature-Liste (unbegrenzte PMs,
Konditionen unverändert, nächste Rechnung), Bündel-Hinweis bei mehreren Posten
- Helper legacyPortalLabel()/legacyIntervalLabel() im Volt-Component
- BookingsPageTest auf die neue Darstellung + Portal-Anzeige aktualisiert
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
E/F/Melden/Queue erledigt (95007da); B über WS-2-Firmen-Scope abgedeckt;
A (Tippfehler an veröffentlichten PMs) bewusst nach Phase 2/Pfad C zurückgestellt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Live-Portal-Domain ist pressekonto.com (nicht .de) – Callback-URL in
.env.example und Deployment-Doku entsprechend gesetzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- .env.example: GOOGLE_REDIRECT_URI explizit auf die Portal-Callback-URL statt
${APP_URL}; Hinweis, dass Google keine .test-Domains akzeptiert.
- Deployment-Doku (§6c): exakte Prod-Callback-URL (pressekonto.de, nicht .com),
lokaler Round-Trip via localhost/https-Tunnel, sonst über gemockte Tests.
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>
RoleAwareLoginResponse gab bei wantsJson() sofort 204 zurück – VOR den
Sicherheitschecks. Ein XHR/JSON-Login eines verifiziert-inaktiven Accounts
erhielt damit eine Session ohne Logout. Checks laufen jetzt zuerst:
verifiziert-inaktiv → Logout + Session-Invalidate + 403 (JSON) bzw. Login mit
Fehler (HTML); unverifiziert → 204 (JSON) bzw. Notice (HTML); danach der
Erfolgsfall.
Tests: JSON-Login eines inaktiven Accounts (403, guest), JSON-Login eines
aktiven Users (204, authentifiziert).
Co-Authored-By: Claude Fable 5 <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>
- Magic-Link-Versand im Login rate-limited (E-Mail+IP 3/h und IP-only 15/h);
verhindert Mail-Fluten und das Entwerten aktiver Links.
- Inaktive (aber verifizierte) User werden beim Passwort-Login zentral
blockiert (Auth::logout + Fehler) – sichert nur-auth/verified-Routen ab.
- Rollensicherer Login-Redirect: gemerkte intended-Admin-URLs schicken einen
Customer nicht mehr in den 403, sondern auf das rollengerechte Ziel.
- ContactAccess prüft is_active vor jeder Mutation: deaktivierte Bestands-
Accounts werden durch eine Anfrage weder verändert noch angemailt.
- Magic-Link-Verbrauch atomar (UPDATE … whereNull(consumed_at)) – Single-Use
auch bei parallelen Requests.
- Sicherheits-Doku um diese Härtungen + Captcha-Empfehlung ergänzt.
Tests: Rate-Limit, intended-Admin-URL für Customer, inaktiver Login,
ContactAccess ohne Mutation inaktiver Accounts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dokumentiert die deployment-kritischen und sicherheitsrelevanten Punkte der
Auth-Phase: Reihenfolge der Migrationen (Verifizierungs-Backfill gegen Lockout,
Legacy-editor→customer-Downgrade), der Sicherheits-Fix der Editor-Über-
berechtigung (65.950 Legacy-User hatten Admin-Zugriff), die Firmen-Scope-
Verhaltensänderung bei PMs und der Magic-Link-Kontaktzugang. PROGRESS-Log-
Eintrag (16.06.) und README-Index ergänzt.
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>
Ergänzt web-master.blade.php um <link rel="canonical">, OpenGraph- und
Twitter-Card-Tags. Self-Canonical-Default wird portal-getrennt aus der
Portal-URL ($domainUrl) + Request-Pfad gebaut – bewusst nicht aus
url()->current(), da URL::forceRootUrl sonst alle Portale fälschlich auf
pressekonto.test kanonisieren würde. Seiten können canonical/meta_description/
og_type/og_image per @section überschreiben; release-detail als article
ausgezeichnet. Erfüllt die Canonical-Hygiene aus dem Duplicate-Content-Update §5.
Tests: tests/Feature/Web/CanonicalMetaTest.php (inkl. Cross-Portal-Negativtest).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bündelt die Launch-Anteile der beiden Decision-Updates (Phase-2/Magic-Link,
Duplicate-Content) mit den Merkliste-Notizen zu einem Plan (WS-1 bis WS-8) inkl.
empfohlener Reihenfolge und Anti-Zombie-Check. Verbindliche Entscheidungen
(15.06.): Legacy-Posten bleiben ungemappt, Pflicht-E-Mail-Verifizierung bei
Registrierung (Ausnahme Magic-Link/Google), Laravel Socialite freigegeben.
README-Index um den Plan ergänzt; Merkliste (Wochenend-Notizen) als Quelle
mit aufgenommen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Stripe Tax verlangt eine gültige Kundenadresse. Beide Checkout-Sessions
erfassen jetzt die Rechnungsadresse verpflichtend und speichern sie am
Stripe-Customer (customer_update address/name = auto; Name ist Pflicht
bei aktivierter USt-ID-Abfrage). Zusätzlich liefert User::stripeAddress()
die lokale Rechnungsadresse bei der Customer-Anlage mit (Cashier-Hook).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Aktueller-Tarif-Card erscheint erst mit vorhandener Buchung; die
Kontingent-Kachel zeigt nur noch echte Zahlen (kein irreführendes
"Unbegrenzt" vor dem Launch-Schalter)
- Tarif-Cards plakativer: Icon je Tarif, größerer Preis, Trennlinie vor
den Leistungen, mehr Abstand zum größeren Buchen-Button
- "Prüfung und Veröffentlichung inklusive" statt "KI-Prüfung"
- "Aktive Buchungen"-Panel entfernt (redundant zum Tarif-Panel);
Verlauf als eigene, durch Trennlinie abgegrenzte Sektion
- Tests angepasst; Suite 519 passed / 4 skipped
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
