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	35 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 35 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.