presseportale/docs/weiteres/Decision-Update Phase-2-Funktionen & Magic-Link-Änderungsprozess.md

**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 `<p>`/`<br>`.

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