**Version:** Juni 2026 (Rev. 2) **Datum:** 12.06.2026 **Status:** Abgestimmt – bereit zur Integration ins Konzept-/Decision-Log **Scope:** Definition von Boost und Veröffentlichungsnachweis (Launch), des Magic-Link-Zugangs- und Änderungsprozesses sowie der Phase-2-Funktionen (Vorab-Prüfung/Redigieren, Prüfzähler, höheres Prüfkontingent, kostenpflichtige Änderungspfade). **Änderungen Rev. 2:** KI bei E/F entfernt (Admin-Panel statt KI-Check); A nutzt Algorithmus-Diff statt KI; Bremsen-/Limit-Spalte für alle Pfade ergänzt. **Änderungen Rev. 3:** A & B als Launch bestätigt; Boost-Preisstaffel (12/20/35) und PDF-Preis (3 Credits) festgelegt; G Depublizieren = 25 Credits. **Änderungen Rev. 4:** Extra-PM ergänzt – tier-gestaffelt (19/15/12/10/8 Credits); Cross-Portal-Veröffentlichung als kein Thema vermerkt (Portale getrennt). --- ## 1. Kontext Dieses Update definiert die credit-nahen Funktionen und den Änderungsprozess für bestehende Pressemitteilungen. Leitlinie: kleiner, ehrlicher Launch-Umfang; alles, was an die volle Credit-/Prüf-Mechanik gekoppelt ist, wandert kontrolliert in Phase 2. Gesetzlich verpflichtende Pfade bleiben unabhängig davon ab Launch erreichbar. **Grundprinzip Kostenkontrolle:** Jeder Vorgang, der einen KI-Call oder Admin-Arbeit auslöst, braucht ein Limit. Daraus folgen zwei Strategien: 1. **Kosten vermeiden statt deckeln** – wo ein billiger Algorithmus die Arbeit erledigt (z. B. Tippfehler-Diff), wird kein KI-Call ausgelöst. Das Limit schützt dann nur noch gegen Missbrauch, nicht gegen Kosten. 2. **Bezahlung als Selbstbremse** – kostenpflichtige Pfade (C/D/G) sind selbstbegrenzend: Wer zahlt, missbraucht nicht. Harte Limits braucht es nur bei den kostenlosen Pfaden (A/B/E/F). --- ## 2. Launch-Funktionen ### 2.1 Extra-Pressemitteilung (Kontingent-Nachkauf) Die Brücke zwischen Tarif-Kontingent und Credit-Wallet: Ist das monatliche PM-Kontingent voll, kann eine einzelne weitere PM über die Wallet nachgekauft werden – ohne Zwang zum nächsthöheren Tarif. Das ist die faire Alternative zum erzwungenen Upgrade und der genau gewünschte Fall „ich brauche _einmalig_ eine PM mehr". **Preis ist tier-gestaffelt** (Treuevorteil: höheres Abo = günstigere Extra-PM): |Situation|Extra-PM|Inkl. PM-Preis|Logik| |---|---|---|---| |Kein Abo (Einzel)|19 Credits|19,00 €|voller Satz = Einzel-PM-Preis| |Starter|15 Credits|9,67 €|günstiger als Einzel, mild über inkludiert| |Business|12 Credits|4,90 €|–| |Pro|10 Credits|3,96 €|–| |Agency|8 Credits|3,32 €|–| **Mechanik:** Der Extra-PM-Preis wird **zur Kaufzeit aus dem aktiven Abo abgeleitet**, nicht statisch gespeichert. Reicht das Wallet-Guthaben nicht, greift der kontextuelle Mini-Checkout („Kostet 15 Credits, du hast 8" → Paket nachladen). Der Volumenrabatt steckt bereits in den Credit-Paketen – **keine** separaten Extra-PM-Bündel nötig (eine Wallet, ein tier-abhängiger Preis). **Design-Entscheidung (bewusst):** Der prozentuale Aufschlag ggü. dem inkludierten PM-Preis ist bei Starter am mildesten (+55 %), bei den oberen Tiers höher (~140–150 %). Das ist gewollt: Die gelegentliche 4. PM eines Starter-Kunden wird _nicht_ bestraft, um künstlichen Upgrade-Druck zu erzeugen – passt zur „fair bleiben, kein Zwang"-Linie. Wer dauerhaft viel veröffentlicht, wandert ohnehin in höhere Tiers. **Tageslimit gilt auch hier:** Nachgekaufte Extra-PMs unterliegen demselben Tageslimit wie das Kontingent (kein „Spam freikaufen"; höherer Tagesdurchsatz = Enterprise-Fall). ### 2.2 Boost (Platzierung) - **Was:** bezahlte Hervorhebung einer PM – Platzierung auf Startseite und Branchen-/Kategorieseite - **Gate:** nur **grüne** PMs sind boostbar; gelb/rot nicht - **Mechanik:** nachträglich kaufbar, sobald die PM live und grün ist - **Umfang:** ein Boost = Featured auf Startseite **und** Branchenseite (eine Stufe, nur die Dauer variiert – bewusst kein getrenntes Pricing pro Platzierung) - **Bezahlung:** über die Credit-Wallet (kleine Wallet ist Launch-Bestandteil) **Preisstaffel (1 Credit = 1 €):** |Dauer|Credits|Pro Tag| |---|---|---| |7 Tage|12|1,71 €| |14 Tage|20|1,43 €| |30 Tage|35|1,17 €| Moderate Staffel: Pro-Tag-Preis sinkt mit der Dauer, der Einstieg (7 Tage / 12) bleibt unter dem PM-Preis von 19 – ein Boost wirkt nie teurer als das Veröffentlichen selbst. Passt zur „Nische besetzen statt abschöpfen"-Linie (Volumen statt Einzelmarge). ### 2.3 Veröffentlichungsnachweis / PDF - **Was:** generiertes PDF „PM XY wurde am … auf … veröffentlicht" inkl. URL, Datum, Vorschau - **Zweck:** Reporting an Vorgesetzte/Kunden – klassische PR-Mitnahme - **Preis:** **3 Credits**, pauschal pro PM – Impulskauf, keine Abwägung (kostet die Plattform praktisch nichts: keine KI, on-demand aus vorhandenen Daten) - **Generierung:** on-demand aus vorhandenen PM-Daten - **Phase-2-Option:** in Business/Pro/Agency später ggf. **inklusive** als kleiner Tarif-Perk; zum Launch einheitlich 3 Credits --- ## 3. Magic-Link: Zugang & Änderungsprozess ### 3.1 Zugangsmodell – eine Verwaltung, zwei Eintrittswege **Grundsatz:** Die Verwaltung bestehender Pressemitteilungen ist **ein und dieselbe** Funktion im pressekonto. Es gibt nur zwei Wege hinein: 1. **Registrierter Account** → normaler Login → verwaltet seine PMs direkt im pressekonto. 2. **Pressekontakt ohne Account** → **Magic-Link** → loggt sich zu den PMs ein, die mit seiner hinterlegten E-Mail verknüpft sind, und nimmt dort Änderungen vor. Der Magic-Link ist also **kein eigenes System**, sondern die Zugangsbrücke für Pressekontakte bzw. Firmen, deren E-Mail-Adressen im System hinterlegt sind, die aber noch nicht direkt registriert sind. Die dahinterliegende Verwaltungsoberfläche und die Änderungspfade sind identisch zum eingeloggten Account. **Account-Konvertierung:** Aus dem Magic-Link-Zugang heraus kann der Pressekontakt jederzeit „Permanenten Account anlegen" wählen (Passwort vergeben). Danach läuft der Zugang über den regulären Login – der Magic-Link wird für ihn überflüssig. **Authentifizierung (Sicherheit):** - Auf jeder PM dezenter Link „Sie sind als Pressekontakt hinterlegt? Pressemitteilung verwalten →" - E-Mail-Eingabe + Captcha; **identische Antwort unabhängig vom Match** (verhindert User-Enumeration) - Bei Match: Magic-Link-Mail mit 30-Min-Token → authentifizierte Session - Dashboard listet alle PMs mit dieser E-Mail als Pressekontakt (über mehrere Firmen/Jahre) ### 3.2 Änderungs- & Lösch-Pfade (A–G) Kein wahlloses Ändern/Löschen – Friction nach Anliegen. Alle Pfade laufen über dieselbe Verwaltung (Login **oder** Magic-Link). |Pfad|Anliegen|KI / Admin|Kosten|Bremse|Phase|Public Hint| |---|---|---|---|---|---|---| |**A**|Tippfehler/Grammatik|Algorithmus-Diff, KI nur im Graubereich|kostenfrei|1 Einreichung/PM/24 h, gebündelt + Account-Tages-Cap|**Launch**|nein| |**B**|Pressekontakt-Daten ändern|keine|kostenfrei|normales Rate-Limit|**Launch**|nein| |**C**|Inhaltliche Korrektur (sachlicher Fehler)|KI|kostenpflichtig|Bezahlung = Bremse|**Phase 2**|ja| |**D**|Update/Ergänzung (neue Information)|KI|kostenpflichtig|Bezahlung = Bremse|**Phase 2**|ja| |**E**|DSGVO-Anonymisierung|**Admin-Panel** (keine KI)|kostenfrei|1 offene Anfrage/PM gleichzeitig|**Launch (Pflicht)**|nein| |**F**|Persönlichkeitsrechtsverletzung|**Admin-Panel** (keine KI)|kostenfrei|1 offene Anfrage/PM gleichzeitig|**Launch (Pflicht)**|je nach Outcome| |**G**|Depublizieren|KI|25 Credits + Bedenkzeit|Bezahlung + 24–48 h Bedenkzeit|**Phase 2**|Tombstone| A & B sind als Launch-Bestandteil bestätigt: kostenfrei, credit-unabhängig und sie senken sofort das unautorisierte Mail-Aufkommen. C/D/G folgen mit dem Credit-/Prüf-System in Phase 2. **Pfad-Details (Kurzfassung):** - **A Tippfehler:** Inline-Editor mit Diff. **Kein KI-Call im Normalfall** – ein lokaler Zeichen-Diff (Levenshtein) entscheidet: Änderung klein **und** keine Zahlen/Namen/Eigennamen berührt → automatisch übernommen (0 KI, 0 Admin). Nur im Graubereich (größere Änderung oder sensible Tokens berührt) → KI-Check **oder** Umleitung zu Pfad C. Nutzer korrigiert idealerweise alle Tippfehler gebündelt und reicht **einmal** ein = ein Vorgang. - **B Kontaktdaten:** Formular, direkt übernommen, Versionierung im Hintergrund - **C Korrektur:** Editor + Pflichtfeld „Was war falsch / was ist korrekt?"; KI erlaubt Fakt-Korrektur (Zahl/Datum/Name), blockiert Umschreibung der Aussage; PM erhält Korrektur-Hinweis - **D Update:** Ergänzung wird unten mit Datum angehängt, Original bleibt unverändert; KI-Check auf Spam/Werbung - **E DSGVO:** Aufklärung (Art. 85 DSGVO, Medienprivileg → keine Volllöschung, aber kostenfreie Entfernung personenbezogener Daten); Checkbox-Auswahl (Name, Durchwahl, persönliche E-Mail, Freitext). **Keine KI** – die Anfrage geht als Benachrichtigung ins Admin-Panel, manuelle Sichtung. In Phase 2/3 automatisierbar. - **F Persönlichkeitsrecht:** Pflichtfelder (betroffene Stelle, Art, Begründung, Belege). **Keine KI** – Benachrichtigung ins Admin-Panel, manuelle Sichtung; Outcomes: Anonymisierung, Anpassung, Tombstone, Ablehnung mit Begründung. In Phase 2/3 automatisierbar. - **G Depublizieren:** Aufklärungsseite → Begründungspflicht (KI lenkt „veraltet" → D, „falsch/peinlich" → C) → kostenpflichtige Bestätigung → 24–48 h Bedenkzeit mit Widerrufslink → Tombstone (`noindex`, raus aus Listen/Suche, URL bleibt) ### 3.3 Compliance-Minimum zum Launch (E & F) **E und F können nicht auf Phase 2 warten.** Sobald PMs live sind, besteht ein gesetzliches Recht auf Anonymisierung personenbezogener Daten (E) und auf Meldung von Persönlichkeitsrechtsverletzungen (F). Beide müssen ab Tag 1 erreichbar sein – zur Not als einfaches Formular/manueller Prozess statt vollem Wizard. Beide sind **kostenfrei** (eine legitime Rechtsanfrage darf nie hinter einer Gebühr stehen) und damit unabhängig vom Phase-2-Credit-Build. **Abwicklung über Admin-Panel (keine KI):** E und F lösen keinen KI-Call aus. Die Anfrage erzeugt eine Benachrichtigung im Admin-Panel, die Sichtung erfolgt manuell. Das spart KI-Kosten und gibt bei Rechtsthemen die bessere Kontrolle. Eine Automatisierung ist für Phase 2/3 vorgesehen. **Limit – nicht „einmalig", sondern „eine offene Anfrage pro PM":** Eine gesetzliche Anfrage darf nie hart gesperrt werden (jemand kann legitim ein zweites Mal eine Anonymisierung brauchen, etwa wenn über ein Update neue personenbezogene Daten hinzukommen). Die saubere Bremse: Solange für eine PM eine Anfrage offen ist, kann keine neue gestellt werden (verhindert Spam-Duplikate); nach Abschluss geht wieder eine. Das deckelt Missbrauch ohne Rechtsrisiko. ### 3.4 Missbrauchsschutz, Edge Cases & Standard-Antwort - **Pfad A (Tippfehler):** Algorithmus-Diff spart im Normalfall jeden KI-Call → Limit schützt nur gegen Missbrauch, nicht gegen Kosten. Bremse: 1 Korrektur-Einreichung pro PM / 24 h (gebündelt), plus Account-Tages-Cap gegen den pathologischen Fall (ein Account bearbeitet hunderte PMs) - **Rate-Limit** auf Magic-Link-Anfragen pro E-Mail/IP; Cooldown nach Depublizierung (Widerruf-Fenster); Audit-Log mit IP/User-Agent je Edit-Aktion - **Keine valide E-Mail** (alte connektar-PMs): Fallback „Verifikation per Domain-Inhaberschaft / Impressums-Match", manuelle Prüfung - **E-Mail geändert / Person verlässt Firma:** manuelle Anfrage mit Bestätigung über `info@`/Impressum - **Massenanträge:** Bulk möglich, Friction (Gebühr, Bedenkzeit) wird **pro PM** angewendet - **Standard-Antwort auf unautorisierte Lösch-Mails:** „Änderungen an Pressemitteilungen sind ausschließlich über das Verwaltungs-Portal der jeweiligen PM möglich." → beendet das wahllose „löscht das mal eben"-Mailaufkommen ab Launch ### 3.5 Abgrenzung zum öffentlichen „Melden"-Button ||„Melden" (öffentlich)|Änderungs-Flow (autorisiert)| |---|---|---| |Wer|jeder Dritte|nur Pressekontakt (Login/Magic-Link)| |Auth|keine|Login oder Magic-Link| |Use Case|Urheberrecht, Verleumdung, Spam|eigene PM ändern| |Outcome|Quarantäne, Prüfung|siehe Pfade A–G| Treffpunkt: Eine über „Melden" angezeigte Persönlichkeitsrechtsverletzung läuft in dieselbe Queue wie Pfad F. --- ## 4. Phase 2 (nachgelagert) Diese Funktionen entstehen gemeinsam, weil sie alle die Re-Check-/Credit-Mechanik voraussetzen. ### 4.1 Vorab-Prüfung / Redigieren Erzeugt erst die Situation „prüfen, ohne (noch) zu veröffentlichen" und den Edit→Neu-Prüfen-Loop. Damit werden auch die kostenpflichtigen Pfade C/D technisch real. ### 4.2 Prüfzähler - **Eigener Zähler**, getrennt von der Credit-Wallet → „Prüfungen inklusive" bleibt sauberes Versprechen - **Aggregiert pro Account/Monat** gedeckelt (nicht pro PM) → löst Klon-Abuse ohne Klon-Erkennung - **Prüf-Tageslimit** als Burst-Schutz (~10/Tag) - **Overflow:** Zähler leer → weitere Prüfungen ziehen 1 Credit/Prüfung aus der Wallet ### 4.3 Höheres Prüfkontingent (Tier-gestaffelt) |Tier|Freie Prüfungen/Monat| |---|---| |Einzel|4| |Starter|12| |Business|30| |Pro|60| |Agency|120| Schnitt ~3–4 Prüfungen pro inkludierter PM; ehrlicher Normalfall (≈2 Prüfungen) stößt nie an. Dies sind die früheren „Bonus-Credit"-Zahlen, umgewidmet zum Prüf-Kontingent. ### 4.4 Kostenpflichtige Magic-Link-Pfade (C / D / G) Kosten-Anker bei 1 Credit = 1 € (zu bestätigen): |Pfad|Aktion|Anker| |---|---|---| |C|Inhaltliche Korrektur|≈ 8 Credits (zu bestätigen)| |D|Update/Ergänzung|≈ 4 Credits (zu bestätigen)| |G|Depublizieren|**25 Credits** + 24–48 h Bedenkzeit (festgelegt)| Depublizieren bewusst am teuersten und mit Bedenkzeit, weil irreversibelste Aktion. --- ## 5. Anti-Zombie-Check (dieser Stand) - ✅ Gesetzliche Anfragen (E/F) immer kostenfrei, ab Launch erreichbar und nie hart gesperrt (1 offene Anfrage/PM statt „einmalig") - ✅ Kosten nur bei echtem Mehraufwand (Korrektur, Update, Depublizierung), nicht bei Pflicht-Rechten - ✅ Kostenlose Pfade bleiben echt kostenlos: Tippfehler laufen über Algorithmus-Diff statt KI, Limits schützen gegen Missbrauch – nicht als versteckte Kostenbremse - ✅ Eine Verwaltung, zwei Eintrittswege – keine künstliche Trennung registrierter/unregistrierter Nutzer - ✅ Prüf-Kontingent großzügig genug, dass der Normalfall nie ansteht - ✅ Depublizierung mit Aufklärung + Bedenkzeit statt Hard-Delete – schützt den Kunden vor sich selbst --- **Bewusst nicht im Scope – Cross-Portal-Veröffentlichung:** Die beiden Portale (presseecho.de, businessportal24.com) sind optisch, inhaltlich und systemisch vollständig getrennt; im Relaunch laufen sie lediglich auf einem gemeinsamen Backend zusammen. Eine PM auf beiden Portalen gleichzeitig zu veröffentlichen ist **kein Feature** – wer in beiden präsent sein will, bucht zwei getrennte Einträge (zwei Slots / zwei Extra-PMs). Das vermeidet Duplicate-Content über die eigenen Domains und passt zur getrennten Zielgruppen-Logik. Kein Phase-2-Punkt, sondern bewusst ausgeschlossen. Noch mal ein wichtiger Hintergrund, der noch dokumentiert werden muss. Das sollte auch zukünftig gegebenenfalls geprüft werden. **In Rev. 3 abgeschlossen:** A/B-Launch ✓ · Boost-Staffel 12/20/35 ✓ · PDF 3 Credits ✓ · G Depublizieren 25 Credits ✓ **In Rev. 4 abgeschlossen:** Extra-PM tier-gestaffelt (19/15/12/10/8) ✓ · Cross-Portal ausgeschlossen ✓ --- ## 6. Umsetzungsstand (Stand 17.06.2026) Die credit-nahe Mechanik ist technisch umgesetzt. Single Source of Truth für alle Preise/Staffeln: `config/credits.php` (1 Credit = 1 €). Ableitung zentral im `CreditPricingService`. **Fundament** - **Credit-Wallet + Ledger:** `credit_wallets` (denormalisierter Saldo) + `credit_transactions` (append-only). Einziger Schreibpfad: `CreditWalletService` (atomar, Row-Lock). Zu wenig Guthaben → `InsufficientCreditsException` mit `required/available/shortfall` (treibt den kontextuellen Mini-Checkout). - **Tier:** `Tier`-Enum + `User::currentTier()` (kein Abo = `Einzel`). - **Wallet-Topup:** Credit-Pakete mit Bonus-Staffel (10→10, 25→27, 50→55, 100→115). Stripe-Ad-hoc-Charge (`checkoutCharge`, **keine** Stripe-Preis-IDs nötig); Gutschrift idempotent im Webhook über `credit_topup_id`. **Launch-Funktionen** - **§2.1 Extra-PM:** `ExtraPmPurchaseService` zieht den tier-abgeleiteten Preis aus der Wallet und verbucht einen `SinglePurchase(ExtraPm, paid)` → greift in die bestehende Kontingent-/Slot-Mechanik. - **§2.2 Boost:** `BoostService` + `boosts`-Tabelle. Gate: nur veröffentlichte, grüne PMs. Mehrfachkauf verlängert. `PressRelease::scopeBoosted()` als Basis für die Featured-Platzierung (Frontend-Anbindung offen). - **§2.3 Veröffentlichungsnachweis:** `ProofPdfService` (3 Credits, einmalig je PM) + `ProofPdfRenderer` (on-demand PDF), Download unter `/admin/me/press-releases/{id}/nachweis` (Policy + Kauf-Gate). - **UI:** Customer-Bereich „Buchungen & Add-ons" (Wallet-Hub, Paket-Topup, Extra-PM, Preisliste, USt.-Bestätigungs-Modal vor Stripe) und Add-ons direkt an der veröffentlichten PM (Boost/Nachweis). - **Submit-Gate (§5.1):** `BILLING_ENFORCE_BOOKING`. Ohne Buchung erscheint im Entwurf/Submit-Modal der Hinweis „Noch keine Buchung" mit Link zur Buchungsseite — der Entwurf wird dabei **immer zuerst gespeichert** (kein Datenverlust beim Sprung). **Phase 2 (Mechanik vorbereitet, UI bewusst noch nicht aktiv)** - **Prüfzähler/Prüfkontingent (§4.2/§4.3):** `review_checks` + `ReviewCheckService` vollständig (Tageslimit hart → Monats-Freikontingent tier-gestaffelt 4/12/30/60/120 → Credit-Overflow). Anzeige im Kundenbereich ausgeblendet, bis die Vorab-Prüfung (§4.1) steht. - **Kostenpflichtige Magic-Link-Pfade C/D/G:** Preise liegen in `config/credits.php` (`paths.correction` 8, `paths.update` 4, `depublish` 25); Flows folgen mit dem Re-Check-/Vorab-Prüfungs-System. **Noch offen / nächste Schritte** - Featured-Platzierung geboosteter PMs im öffentlichen Web-Feed. - Vorab-Prüfung/Redigieren (§4.1) als Voraussetzung für Prüfzähler-UI und Pfade C/D/G. ## 7. Launch-Vorbereitung (Stand 18.06.2026) Aufsetzend auf dem Credit-Stand aus §6 wurden weitere Launch-Punkte umgesetzt: **Status-Widget (immer verfügbarer Buchungsüberblick)** - Header-Dropdown oben rechts (Desktop) bzw. im Mobile-Header, für alle Kunden-Panel-User: aktuelle Buchung/Tarif (+ Intervall), verbleibendes PM-Kontingent (oder ∞), Credit-Guthaben. Ohne aktive Buchung Hinweis + Link zur Buchungsseite. - `CustomerStatusSummary` bündelt die Anzeige-Werte über die öffentliche `User`-API (Gating bleibt Single Source of Truth im Modell); Anzeige via `x-customer.status-menu`. Kompakte Topbar (`min-h-0`), kein Leerraum. **WS-8 Code-Optimierung** - `User::currentPlan()` und `hasUnlimitedPressReleaseQuota()` pro Request memoisiert (Status-Widget fragt sie auf jeder Seite ab); `fresh()` setzt den Cache zurück. - Detailseite: `getMyPR()` war nicht memoisiert und lief bis zu 7× pro Request mit voller Eager-Load-Query → memoisiert; Firmen-Kennzahlen per `withCount()` statt nachträglichem `loadCount()`. - Dedup: `PressRelease::scopeAccessibleBy(User)` (Kunden-PM-Zugriff), `Contact::scopeForCompany()`, `BillingAddress::REQUIRED_FIELDS`/`completenessPercent()`, Trait `InteractsWithPressReleaseTags` (create/edit). **Paket-Vorteile (dynamisch, admin-pflegbar)** - `plans.benefits` (JSON-Spalte, Cast, `Plan::benefitsList()`). Im Admin „Tarife & Pakete" zeilenweise pflegbar; angezeigt auf der In-App-Buchungsseite UND der öffentlichen Preise-Seite (eine Datenquelle). DB-Vorteile sind admin-redaktioneller Klartext (unter `/en` nicht auto-übersetzt — bewusst). **i18n (Internationalisierungs-Readiness)** - Default-Locale auf `de` (`APP_LOCALE`/`APP_FALLBACK_LOCALE`): Backend rendert Deutsch nativ als Schlüssel; `en` ist der spätere Umschalter. Frontend nutzt bereits URL-Prefix `/de`–`/en` (`SetEdition`) + strukturierte `lang/de|en/*.php`. - Alle Backend-Views sind `__()`-gewrappt (Auth-Strecke als letzter Rest nachgezogen). Leeres `lang/en.json` als Gerüst. - **Bewusst offen:** Backend-Sprachumschalter (Middleware liest `user->language`) und die EN-Übersetzungen (~2743 Strings) — erst beim tatsächlichen EN-Launch. **Bekannter Bugfix** - Legacy-/importierte PMs (Plaintext mit `\n`) verloren beim Laden in den HTML-Editor die Umbrüche → `PressReleaseHtmlSanitizer::toEditorHtml()` wandelt sie beim Bearbeiten in `

`/`
`. **Noch offen / nächster Schritt** - End-to-End-Flow-Durchlauf mit Test­buchungen (Detail-/Optikkorrekturen, Stripe-Testmodus) — QA als letzter Launch-Schritt.