presseportale/dev/2026-09-01/umsetzung-protokoll.md

Umsetzungsprotokoll — Abarbeitung von bestandsaufnahme-code.md, Abschnitt 7

Stand: 01.09.2026 Bezug: bestandsaufnahme-code.md (Befund-Nummern H1–H4, M1–M9, P1, L1–L9)

Jeder Abschnitt hält fest: was war der Befund, was wurde geändert, wie ist es abgesichert. Abweichungen von der ursprünglich vorgeschlagenen Reihenfolge oder Lösung sind ausdrücklich vermerkt.

---

Ausgangsstand

Prüfung	vorher
php artisan test	1479 grün, 1 übersprungen
vendor/bin/pint --test	passed
vendor/bin/phpstan analyse	390 Fehler außerhalb der Baseline

---

Block A — vor dem nächsten Deploy

Schritt 1 — H1: Suchausfall im Deploy-Fenster

Befund: PressReleaseSearchIndex::isAvailable() cachte seine Antwort eine Minute. Stand dort false, während die Migration die Volltext-Indizes von press_releases entfernte, setzte der Rückfallpfad sein MATCH() weiter auf die Tabelle ab, an der es keinen Index mehr gab → MySQL-Fehler 1191, 500er auf jeder Suche der Web-Seite und der Admin-PM-Liste.

Geändert

• app/Models/PressReleaseSearchIndex.php
  • Cache-Key als Konstante AvailabilityCacheKey herausgezogen.
  • isAvailable() cacht die beiden Antworten unterschiedlich lange: true (Dauerzustand nach dem Umstieg) 60 s, false (gilt nur während des Umstiegs) 5 s. Die Prüflogik steckt jetzt in resolveAvailability().
  • Neu: forgetAvailability().
• database/migrations/…_create_press_release_search_table.php und …_drop_fulltext_indexes_from_press_releases.php rufen forgetAvailability() in up() und down() auf. Das ist der eigentliche Fix; die kurze TTL ist das Netz für einen Eingriff von Hand.

Abweichung vom Vorschlag: Der Bericht schlug zusätzlich vor, den Rückfallpfad gegen QueryException abzusichern. Nicht umgesetzt — constrain() baut die Abfrage nur auf, ausgeführt wird sie später vom Aufrufer. Ein try/catch an dieser Stelle könnte den Fehler gar nicht sehen. Die Cache-Invalidierung in der Migration deckt den Fall vollständig ab.

Abgesichert: drei neue Tests in tests/Feature/PressReleaseSearchIndexTest.php (kurze TTL bei false, lange bei true, Wirkung von forgetAvailability()).

---

Schritt 2 — H2: Cache-Flush in der Schleife

Befund: CompanyRemovalService::markGone($company, includePressReleases: true) lud alle Mitteilungen der Firma per get() und rief je Zeile PressReleaseService::markGone(), das jedes Mal sämtliche Seiten- und Sitemap-Caches verwarf. Bei 300 Meldungen: 301 Vollinvalidierungen auf einen Admin-Klick, dazu die unbegrenzte Ergebnismenge im Speicher.

Geändert

• PressReleaseService::markGone() / restoreFromGone() bekommen bool $flushPublicPages = true. Das Standardverhalten bleibt unverändert.
• CompanyRemovalService::markGone() iteriert mit chunkById(200) statt get() und übergibt flushPublicPages: false. Der eine Flush am Ende der Methode bestand bereits und genügt.

Abgesichert: GoneTombstoneTest → „cascading a newsroom removal flushes the page cache once, not per release" (drei Mitteilungen, Generations-Zähler steigt um genau 1).

---

Schritt 3 — H3 + H4: Umkehrbarkeit von gone_at

Befund: markGone() überschrieb companies.is_active (→ false) und press_releases.no_export (→ true), ohne den Vorzustand zu sichern. Das Aufheben setzte beide pauschal auf den Normalzustand zurück. Eine Firma, die schon vorher deaktiviert war, stand danach öffentlich in Newsroom-Übersicht und Sitemap; eine Mitteilung blieb dauerhaft als „kein Export" markiert. Die Oberfläche verspricht an beiden Stellen ausdrücklich Umkehrbarkeit.

Geändert

• Neue Migration 2026_09_01_090000_add_gone_restore_state_to_companies_and_press_releases_tables.php: companies.is_active_before_gone und press_releases.no_export_before_gone, beide boolean nullable. null = nicht entfernt bzw. bereits zurückgenommen. Idempotent über Schema::hasColumn().
• Company und PressRelease: $fillable + casts() ergänzt.
• CompanyRemovalService::markGone() sichert is_active, restoreFromGone() stellt es wieder her (?? true als einzige mögliche Annahme für Altfälle ohne Merker).
• PressReleaseService::markGone()/restoreFromGone() analog für no_export. Fehlt der Merker, bleibt der aktuelle Wert stehen — raten wäre schlechter als nichts zu tun.

Zur Kostenfrage der Migration: Auf press_releases ist das ADD COLUMN seit dem Entfernen der Volltext-Indizes ein ALGORITHM=INSTANT. companies trägt seinen FULLTEXT-Index weiterhin und wird kopiert — bei 70 MB wenige Sekunden, wie in CLAUDE.md als vertretbar festgehalten. Die Migration ist bewusst nach drop_fulltext_indexes_from_press_releases datiert.

Verworfene Alternative: is_active in markGone() gar nicht anzufassen und stattdessen überall auf gone_at zu filtern. Dafür hätten 12 Abfragen in app/Services/Web/, SitemapController und AuthorizesPressReleaseMediaAccess angefasst werden müssen — eine übersehene Stelle hätte einen entfernten Newsroom öffentlich gelassen. Der Merker ist die kleinere Angriffsfläche.

Abgesichert: drei neue Tests in GoneTombstoneTest (inaktive Firma bleibt nach dem Aufheben inaktiv; no_export wird zurückgesetzt; ein vorher gesetztes no_export bleibt bestehen).

---

Schritt 4 — M5: Watermark-Migration umging den AppSetting-Cache

Befund: Die Migration schrieb die Wasserstandsmarke per Query Builder, AppSetting::getValue() cacht aber dauerhaft (rememberForever). Lief der Scheduler-Task im Deploy-Fenster schon einmal, hielt der Cache die alte, niedrigere Marke — der nächste Lauf hätte die Ereignisse dazwischen ein zweites Mal auf press_releases.hits addiert.

Geändert

• AppSetting::forgetCached(string $key) als öffentliche Methode; setValue() benutzt sie jetzt selbst.
• …_seed_press_release_view_watermark.php ruft sie in up() und down() auf.

---

Block B — Werkzeug

Schritt 5 — P1: Statische Analyse wieder in Betrieb

Befund: 390 Fehler außerhalb der Baseline, davon der größte Teil Falschmeldungen: Larastan löste keinen einzigen Cast auf, weil alle 49 Models ihre Casts über die casts()-Methode deklarieren (Laravel-11-Stil) und Larastans Schalter parseModelCastsMethod per Default false ist. $pressRelease->status galt als string, jeder Enum-Vergleich als „immer falsch". Zusätzlich: Baseline seit dem 12.05.2026 unverändert, composer analyse in keiner Pipeline.

Geändert

1. phpstan.neon: parseModelCastsMethod: true, mit Begründung im Kommentar. Wirkung: 390 → 266 Meldungen.
2. 102 Relations-Annotationen in app/Models/*.php ergänzt — jede BelongsTo/HasMany/HasOne/BelongsToMany/MorphTo-Methode hat jetzt ihr @return …<Related, $this>. Das war die zweite Sammelursache: Ohne Generics landete PHPStan auf Illuminate\…\Model und meldete jede Modell-Eigenschaft und jeden Scope als unbekannt. Wirkung: 266 → 169, property.notFound von 84 auf 12. Nebeneffekt: dieselbe Verbesserung in der IDE-Vervollständigung.
3. Aufräum-Funde vorgezogen (siehe Schritt 5b).
4. Baseline neu erzeugt: 166 Einträge / 188 Meldungen (vorher 127 Einträge plus 390 ungefasste Meldungen). vendor/bin/phpstan analyse meldet jetzt No errors.
5. .github/workflows/tests.yml: neuer Schritt „Run Static Analysis" vor den Tests. Ohne Gate driftet die Baseline erneut.

Was bewusst in der Baseline bleibt und warum

Anzahl	Art	Grund
66	property.notFound	withCount-Aliasse (recent_releases_count) und Closure-Parameter, die als blankes Builder typisiert sind. Behebbar nur mit @param Builder<PressRelease> an jeder Closure — viel Rauschen für keinen Erkenntnisgewinn.
34	nullsafe.neverNull	?-> auf Werten, die seit der Cast-Auflösung nachweislich nicht null sind. Stilfrage, kein Fehler.
18	method.notFound	Eigene Scopes (forPortalValues(), visibleInArchive()) auf denselben blanken Closure-Buildern.
10	trait.unused	Falschmeldung: app/Livewire/Concerns/* wird ausschließlich aus Volt-Single-File-Komponenten in resources/views/livewire/**.blade.php eingebunden, die PHPStan nicht analysiert. Nachgeprüft, die Traits sind in Benutzung.
9	class.notFound	Legacy-Migrationsmodelle (App\Models\Legacy\…) und Laravel\Cashier\Concerns\Stripe\TaxId.
5+2+2	instanceof.alwaysTrue / property.onlyWritten / method.unused in ProcessStripeWebhook	Falschmeldungs-Kaskade: Cashier typisiert findBillable() gegen den Trait Billable. PHPStan kann den nicht mit User vereinbaren, hält deshalb if (! $user instanceof User) return; für immer wahr und alles danach für unerreichbar — inklusive der Stellen, an denen $this->activityLog und $this->numbers gelesen werden. Die Laufzeitprüfung ist richtig und bleibt.

Korrektur zur Bestandsaufnahme: Befund L6 („ProcessStripeWebhook: $numbers und $activityLog injiziert, nie gelesen") war falsch. Beide werden in den Zeilen 123, 149, 257 und 293 verwendet; die Meldung ist ein Folgefehler der oben beschriebenen Cashier-Kaskade. Nichts entfernt.

---

Schritt 5b — Aufräum-Funde L1–L5 und M7 (vorgezogen)

Warum vorgezogen: Diese Funde stammen aus der statischen Analyse. Hätte ich die Baseline vor ihrer Behebung erzeugt, wären sie zugedeckt gewesen — und ihre spätere Behebung hätte die Baseline sofort wieder ungültig gemacht (ignore.unmatched). Sie gehören deshalb vor den Baseline-Neuaufbau, nicht in Schritt 9.

Fund	Datei	Änderung
L1	ProofPdfRenderer::renderOverview()	if ($embed === null || $image === null) → if ($embed === null). $embed ist bereits null, wenn $image null ist.
L3	ManualInvoiceService::invoiceFor()	Prüfung current_period_end === null entfernt — die Spalte ist date() NOT NULL.
L4	Company::logoUrl()	if ($legacyPortal && filled($logoFilename)) → if (filled($logoFilename)). $legacyPortal fällt auf $this->portal->value zurück und ist damit immer gesetzt.
L5	RecordMailActivity::recordSent()	getTo() ?? [] → getTo(). Die Symfony-Methode liefert immer ein Array.
—	PressReleasePreviewController	$magicLink->expires_at && …->isPast() → …->isPast(). magic_links.expires_at ist NOT NULL.
—	RetireAgencyCompanyType	if (! $isNewsroom && $isProtected) → if (! $isNewsroom). Der Zweig darüber endet für den Gegenfall immer mit continue.
—	MigrateLegacyMedia::selectedTypes()	@return list<'company-logos'|'press-release-images'> ergänzt. Damit ist das match ohne default nachweislich vollständig statt nur faktisch.

M7 — Legacy-API konnte portal = null schreiben (ebenfalls vorgezogen, weil derselbe Sachverhalt):

• ResolvesRequestedPortal::resolveRequestedPortal() gibt jetzt ein nicht-nullbares Portal zurück; letzte Stufe ist Portal::Both — exakt der Default, den beide portal-Spalten ohnehin tragen. Vorher konnte die Methode null liefern, was als SQL-Fehler und damit als 500er beim Alt-Client gelandet wäre; PressReleaseController:53 hätte sogar einen Fatal Error ausgelöst, weil es das Ergebnis direkt mit ->value weiterreicht.
• LegacyPressReleaseController und LegacyCompanyController: ?->value → das Enum bzw. ->value direkt.
• PressRelease::publicPortalLinks(): der unerreichbare null =>-Arm im match entfällt.
• PressRelease::booted() und LegacyPressReleaseController weisen jetzt das Enum statt des Rohwerts zu — die Spalten sind darauf gecastet.

Bewusst NICHT geändert: ProofPdfRenderer:946 ($width < 1 || $height < 1 nach imagesx()/imagesy()). Laut PHPStan-Stub tot, zur Laufzeit eine Schutzprüfung in der Bildverarbeitung des Rechtsnachweis-PDFs. Für null funktionalen Gewinn wird dort keine Absicherung entfernt — Meldung baseliniert.

---

Block C — Voraussetzungen für die Roadmap

Schritt 6 — M9: Bounce-Suppression vervollständigt

Befund: newsletter:import-bounces erfasste ausschließlich users und protokollierte alles Übrige als „ohne User-Konto". Die zweite Empfängerliste newsletter_subscriptions — die öffentliche Anmeldung auf den Portalen, mit eigenem unsubscribed_at und eigener Synchronisierung nach außen — blieb unberührt. Die meisten Einträge dort haben gar kein Konto, wurden also gar nicht erreicht. Die Roadmap macht „Bounce-Suppression produktiv" zum Blocker für 1b.6, 1d.3 und 3.2.

Geändert (app/Console/Commands/ImportNewsletterBounces.php)

• Aufgeteilt in suppressUsers() und suppressSubscriptions(); beide melden zurück, ob die Adresse in ihrer Liste stand.
• „Ohne User-Konto" gilt jetzt erst, wenn die Adresse in keiner der beiden Listen steht.
• Anmeldungen werden scope-frei über alle Portale gesucht (der CLI-Lauf hat keinen Portal-Kontext, eine Adresse kann auf beiden Portalen stehen), bekommen unsubscribed_at, laufen durch NewsletterSyncService (damit die Abmeldung auch beim externen Versender ankommt) und landen mit method: bounce im Aktivitäts-Verlauf.
• Eigene Ergebniszeile für die Anmeldungen; --dry-run deckt beide Listen ab.
• L9 gleich mit erledigt: Der Vergleich läuft über whereRaw('LOWER(email) = ?') wie in User::findByEmail(). Bounce-Listen kommen aus dem Mailserver-Log und geben die Adresse so wieder, wie der Absender sie geschrieben hat.

Abgesichert: vier neue Tests (Anmeldung ohne Konto wird abgemeldet; Idempotenz beim zweiten Lauf; alle Portale einer Adresse; Dry-Run; Groß-/Kleinschreibung).

---

Schritt 7 — M4: Aufbewahrung press_release_events

Befund: Die Tabelle nimmt seit dem Umbau des Aufruf-Zählers jeden Seitenaufruf auf (Bestand knapp eine Million) und war als einzige Log-Tabelle des Systems ohne Bereinigung.

Geändert

• Neu config/press_releases.php: events.retention_days, Default 395 Tage (13 Monate), überschreibbar per PRESS_RELEASE_EVENTS_RETENTION_DAYS.
• Neu app/Console/Commands/PurgePressReleaseEvents.php mit --days, --chunk, --dry-run.
• Scheduler: täglich 03:20, withoutOverlapping(), mit Betriebs-Alert.
• .env.example ergänzt.

Zwei Sicherungen, beide zwingend und getestet

1. Gelöscht wird ausschließlich unterhalb der Wasserstandsmarke von press-releases:aggregate-views. Alles darüber ist noch nicht in hits verbucht und wäre sonst dauerhaft verloren. Fehlt die Marke, bricht der Lauf mit Exit-Code 1 ab, statt zu raten.
2. Gelöscht wird in Blöcken — ein DELETE über Millionen Zeilen hielte die Sperre über die gesamte Laufzeit.

⚠ Offene Entscheidung: Die 13 Monate sind meine Festlegung, nicht deine. Gewählt, weil damit der Vorjahresmonats-Vergleich möglich bleibt. Der Wert bestimmt zugleich, wie weit die Verlaufsanzeige der geplanten Absenderansicht (Roadmap 1c.1) zurückreicht — wer dort mehr Historie zeigen will, muss ihn vor dem ersten Lauf erhöhen. Einmal gelöschte Ereignisse kommen nicht zurück. Der Zusammenhang steht als Kommentar in config/press_releases.php.

Abgesichert: fünf Tests in tests/Feature/PurgePressReleaseEventsTest.php.

---

Schritt 8 — Index auf companies.email

Befund: companies hatte nur (portal, slug), (portal, is_active), (created_at, id) und einen FULLTEXT über (name, email, slug). Ein FULLTEXT-Index beantwortet kein WHERE email = ? — jede Suche über die Firmen-E-Mail war ein voller Tabellendurchlauf. Roadmap 1a schlüsselt die Newsroom-Konsolidierung ausdrücklich darüber, 1a.4 bei jeder eingehenden API-Meldung.

Geändert: Migration 2026_09_01_091000_add_email_index_to_companies_table.php.

Warum nur email und nicht (portal, email): Die Adresse ist hochselektiv, die Portal-Einschränkung kostet danach nichts mehr — und derselbe Index trägt zusätzlich die portalübergreifende Gruppierung des Trockenlauf-Berichts (1a.1), was ein zusammengesetzter Index nicht könnte.

Kosten: ADD INDEX läuft bei InnoDB auch mit vorhandenem FULLTEXT-Index INPLACE — anders als ADD COLUMN. Bei 70 MB Sekunden.

---

Block D — Schritt 9: laufende Aufräumarbeiten

M1 — Generations-Zähler prozessweit eingefroren

WebPageCache::$generation wurde mit ??= einmal je Prozess gefüllt. Unter PHP-FPM stimmt das; ein Queue-Worker lebt aber über beliebig viele Jobs hinweg und hätte dauerhaft mit dem Stand seines ersten Zugriffs gearbeitet — konkret hätte BoostService::forgetPlacementCaches() die Keys einer alten Generation gelöscht, während der aktuelle Eintrag bis zum TTL-Ablauf stehen bleibt.

• Neu: WebPageCache::resetMemo().
• AppServiceProvider::boot() registriert Queue::looping(…), verwirft die Merkung also zwischen zwei Jobs. Die Merkung selbst bleibt — sie war als Ersparnis gedacht und ist es weiterhin, nur eben mit definierter Lebensdauer. Ein späterer Octane-Betrieb bräuchte denselben Reset auf RequestReceived; das steht als Hinweis am Feld.

M2 — Zähler lag im Namensraum, den er invalidiert

web.generation → page-cache.generation. Der Zähler ist der eine Eintrag, der eine Verwerfung des web.-Namensraums überleben muss.

Deploy-Hinweis: Die Umbenennung setzt den Zähler einmalig auf 0 zurück. Unkritisch, solange sie zusammen mit dem übrigen noch nicht committeten Block ausgeliefert wird — die Generations-Nummer existiert auf dem Live-System noch gar nicht. Wird sie später einzeln nachgezogen, vorher einmal php artisan cache:clear einplanen.

M3 — Wasserstandsmarke nur chunkweise idempotent

AggregatePressReleaseViews: increment()-Schleife und AppSetting::setValue() laufen jetzt in einer DB::transaction() je Durchgang. Vorher war nur der Durchgang wiederanlaufsicher, nicht der Abbruch darin — ein Absturz mitten im Chunk hätte einen Teil der Zähler erhöht, die Marke aber nicht bewegt, und der nächste Lauf hätte genau diese Aufrufe doppelt verbucht. Der Klassenkommentar, der Idempotenz behauptete, ist präzisiert.

M6 — #[Locked] auf $companyId

resources/views/livewire/admin/companies/edit.blade.php: public int $companyId hat jetzt #[Locked], wie das Pendant $id der PM-Bearbeitung. save(), deleteCompany(), markGone() und restoreGone() arbeiten alle auf diesem Wert; ohne das Attribut konnte der Client ihn im Livewire-Payload austauschen, sodass die Aktion eine andere Firma träfe als die im Formular angezeigte.

M8 — pt-osc-Passwort nicht maskiert

OnlineSchemaChange::writeDefaultsFile() schreibt Benutzer und Passwort jetzt über quoteOptionValue() in doppelten Anführungszeichen mit escaptem \ und ". In einer my.cnf beginnt ein # sonst einen Kommentar und umschließende Leerzeichen fallen weg — ein Passwort mit Raute wäre abgeschnitten bei pt-osc angekommen und der Lauf an einem Authentifizierungsfehler gescheitert, dessen Ursache nirgends sichtbar ist.

L7 — max_allowed_packet beim Erstlauf des Reindex

ReindexPressReleaseSearch: Klassenkommentar um den Hinweis ergänzt, dass ein Durchgang --chunk vollständige Textkörper in einem upsert schreibt und beim erstmaligen Indizieren des Bestands im Zweifel --chunk=100 zu wählen ist.

L8 — Blade-Codestil

admin/press-releases/index.blade.php: fn($inner) → fn ($inner). Pint erfasst Blade-Dateien nicht, deshalb war die Abweichung durchgerutscht.

L9

Zusammen mit Schritt 6 erledigt, siehe dort.

---

Endstand

Prüfung	vorher	nachher
php artisan test	1479 grün, 1 übersprungen	1495 grün, 1 übersprungen (6517 Assertions)
vendor/bin/pint --test	passed	passed
vendor/bin/phpstan analyse	390 Fehler außerhalb der Baseline	No errors (Baseline 166 Einträge / 188 Meldungen)

16 neue Tests, verteilt auf PressReleaseSearchIndexTest (3), GoneTombstoneTest (4), ImportNewsletterBouncesTest (4) und das neue PurgePressReleaseEventsTest (5).

Neue Dateien

Datei	Zweck
app/Console/Commands/PurgePressReleaseEvents.php	Aufbewahrung des Ereignis-Logs (M4)
config/press_releases.php	Aufbewahrungszeitraum, konfigurierbar
database/migrations/2026_09_01_090000_add_gone_restore_state_…	Vorzustand der 410-Entfernung (H3/H4)
database/migrations/2026_09_01_091000_add_email_index_to_companies_table.php	Voraussetzung Roadmap 1a
tests/Feature/PurgePressReleaseEventsTest.php	Absicherung M4

Reihenfolge beim Deploy

1. php artisan migrate --force — die neuen Migrationen laufen nach drop_fulltext_indexes_from_press_releases (auf press_releases damit INSTANT, auf companies ein Kopiervorgang von wenigen Sekunden).
2. Danach einmal php artisan press-releases:aggregate-views, damit die Wasserstandsmarke gesetzt ist, bevor der neue Aufräum-Task um 03:20 das erste Mal läuft. Ohne Marke bricht er von selbst ab — es geht also nichts verloren, der erste Lauf wäre nur wirkungslos.
3. php artisan config:cache (neue Konfigurationsdatei).

Was offen bleibt

Thema	Status
Aufbewahrung des Ereignis-Logs: 395 Tage	Meine Festlegung, deine Entscheidung. Bestimmt die Tiefe von Roadmap 1c.1 und ist nur vor dem ersten Lauf frei wählbar.
Die 166 Baseline-Einträge	Kein Fehler, aber auch keine Sichtprüfung wert — Zusammensetzung und Begründung siehe Schritt 5. Wer sie weiter senken will, fängt bei den Closure-Generics in app/Services/Web/ an.
Roadmap-Entscheidungen E1–E6	Unberührt — das sind fachliche Fragen, keine Code-Befunde.

---

Teil 2 — Roadmap Block 0 (Messbarkeit)

0.1 und 0.2 — Basiswerte

Zwei Auswertungen als Artisan-Befehle, Ergebnisse und Ableitungen in basiswerte-block0.md.

php artisan press-releases:view-distribution   [--months=3] [--from=] [--to=] [--json]
php artisan press-releases:rejection-rate      [--months=3] [--from=] [--to=] [--json]

Zwei Befunde, die den Plan verändert haben:

1. Der Gesamtmedian taugt nicht als Basiswert. hits ist ein mitlaufender Zähler, und die Aufrufe wachsen nach der Veröffentlichung wochenlang weiter (⌀ 75 → 128 → 179 → 231 in den ersten vier Wochen, ohne Plateau). Über ein Drei-Monats-Fenster misst man damit die Altersmischung, nicht die Reichweite. Der Report weist deshalb zusätzlich Alterskohorten aus; der Basiswert ist die Kohorte „28–55 Tage", nicht die Gesamtzahl.
2. openPR ist keine zweite Quelle. Es ist der Presse-API-Verteiler von connektar, also derselbe Zulauf. In den Daten hat genau ein API-Token je einen Zugriff gemacht. Roadmap-Text korrigiert.

E2 ist damit entschieden: Rohzahlen. Begründung in basiswerte-block0.md. Kurzfassung: kein Bodensatz (unter 25 Aufrufen liegen 2 % bzw. 0 %), Verteilungen nahezu symmetrisch, und eine Einordnung gegen den Portaldurchschnitt wäre wegen der Wachstumskurve sogar falsch.

---

0.3 bis 0.7 — Konversionsleiter

Warum eine eigene Tabelle statt Umami

Die zu messende Strecke führt über zwei Domains und einen Magic Link. Ein cookiefreies Analytics-Tool verliert die Sitzung genau an der Stelle, an der die Konversion passiert. Claim, Registrierung und Buchung sind außerdem keine Seitenaufrufe, sondern Zustandsänderungen in der Datenbank, bei denen die Identität ohnehin bekannt ist.

Rollenteilung bleibt: Ereignistabelle für den Trichter (Block 1), Umami für Seitenaufrufe und Suchbegriffe (Block 2). Keine Vermischung.

0.3 — conversion_events

Spalten: type, source, company_id, press_release_id, created_at. Keine Personen, keine Klartextadressen, keine IP, kein User-Agent. Der rote Faden durch den Trichter ist die Firma, nicht der Mensch — für „an welcher Stufe bricht es ab" reicht das vollständig.

Die Leiter als Enum ConversionEventType, mit Stufe und Diagnose am Fall:

#	Stufe	Ein Abbruch hier bedeutet
1	Mail-Link geklickt	Betreff oder Anlass trägt nicht
2	Magic Link eingelöst	Der Verwaltungszugang wird nicht verstanden
3	Newsroom bearbeitet	Kein Anreiz, das Profil zu pflegen
4	Konto angelegt	Der Nutzen des Kontos ist nicht erkennbar
5	Erste Buchung	Preis oder Angebot passt nicht

0.4 — Herkunft auf dem Token

Neue Spalte magic_links.source (bewusst eine Spalte statt eines Eintrags in payload: Die Herkunft wird gruppiert und gefiltert, nicht nur gelesen). MagicLinkGenerator::createLoginLink() nimmt sie entgegen.

Die Mail-Links tragen ?src=<Herkunft>&pr=<Meldung>. ConversionSource::parse() fällt bei unbekannten Werten auf organic zurück statt zu scheitern — der Parameter steht in fremder Hand.

Zur Meldungs-ID im Klartext: Sie ist fälschbar. Vertretbar, weil sie nichts freischaltet, sondern ein Ereignis in der internen Statistik einer Firma zuordnet; wer sie fälscht, verfälscht nur die eigene Auswertung. Sobald der Verwaltungszugang über Magic Link steht (1b.2), tragen die Mail-Links ein Token, das Herkunft und Meldung fälschungssicher mitführt — der pr-Parameter entfällt dann.

0.5 — Schreibstellen

Stufe	Wo
1	RecordMailLinkClick — globale Middleware. Bewusst global statt je Route: Die Mail-Links zeigen auf Hub, Spokes und öffentliche Detailseiten, eine vergessene Route wäre eine unsichtbare Lücke. Nur mail_*-Herkünfte lösen aus, nur GET.
2	MagicLinkConsumeController, Herkunft vom Token
3	Enum und Auswertung stehen, Schreibstelle folgt mit 1b.3 (abgesprochen)
4	RecordAuthActivity::recordRegistered()
5	ProcessStripeWebhook an beiden Zahlungspfaden (mirrorPaidInvoice, fulfillSinglePurchase), dedupliziert über recordOnce() je Firma

Zwei Regeln für alle Schreibstellen: Fehler werden geschluckt (die Messung begleitet einen Vorgang, sie ist nicht der Vorgang) und kein Personenbezug.

0.6 — Auswertung

php artisan conversion:funnel [--months=3] [--from=] [--to=] [--json]

Zählt je Stufe die eindeutigen Firmen, nicht die Ereignisse: Ein doppelter Klick ist kein doppelter Interessent, und nur mit derselben Einheit auf allen Stufen ist ein Übergang überhaupt eine Quote. Ereignisse ohne Firmenbezug stehen in einer eigenen Spalte daneben statt im Nenner.

0.7 — Aufbewahrung

395 Tage, derselbe Horizont wie beim Aufruf-Ereignis-Log (Entscheidung 01.09.2026). config/conversion.php, Befehl conversion:purge-events, täglich 03:25 im Scheduler.

Offen und bewusst nicht von mir geschrieben: Der Absatz in der Datenschutzerklärung. Rechtstext gehört nicht aus einer Codeänderung heraus formuliert. Inhaltlich zu führen ist: Zweck (interne Reichweiten- und Konversionsstatistik), Umfang (Ereignistyp, Herkunft, Firmen- und Meldungsbezug — kein Personenbezug, keine IP), Aufbewahrung (395 Tage), Rechtsgrundlage.

Angepasster Bestandstest

EmailBrandingTest verglich die Mail-URL roh gegen das gerenderte HTML. Die Links tragen jetzt zwei Parameter, Blade escapt das trennende & korrekt zu & — der Vergleich läuft nun über e(). Verhalten unverändert richtig, nur die Erwartung war zu eng.

---

Teil 3 — Roadmap Block 1a (Newsroom-Konsolidierung)

1a.1 — Trockenlauf-Bericht

php artisan companies:merge-report [--threshold=] [--limit=15] [--json]

Live-Ergebnis vom 11.09.2026, Schwellwert 3, nach der Tippfehler-Korrektur:

Klasse	Adressen	Firmen	fällt weg	davon mit PM
Dublette	12.812	27.832	15.020	14.633
Namensvariante	1.615	4.540	2.925	1.087
Vorschlag	3.632	9.907	–	2.211
Sammeladresse	1.085	6.706	–	1.072
nie veröffentlicht	23	5.965	–	0

17.945 Firmen würden automatisch zu bestehenden Newsrooms verschmelzen — 16 % des Bestands von 111.646.

Drei Befunde aus den Live-Läufen mit Schwellwert 2, 3 und 4:

1. Die Klasse „nie veröffentlicht" fehlte im Regelwerk. 23 Adressen mit 5.965 Firmen und null Veröffentlichungen, angeführt von yahoo@yahoo.com (4.376 Firmen). Dahinter steht keine Firma und keine Agentur. Hätte 1a.3 ohne diesen Trockenlauf gebaut, wären 4.376 Unbeteiligte zu einem Newsroom verschmolzen — der teuerste Fehler dieses Blocks, nicht sauber rückabwickelbar. Die Namensanzahl allein trennt diese Adressen NICHT von großen Agenturen (pr@deutsche-stadtauskunft.ag: 133 Namen, 134 Firmen mit Meldungen); trennscharf ist erst die Veröffentlichung.
2. Tippfehler galten als verschiedene Firmen. info@js-research.de stand mit 204 Firmen an zweiter Stelle der Agenturliste — eine Firma, siebzehnmal leicht anders geschrieben. Normalisierte Namen werden jetzt zu Ähnlichkeitsclustern zusammengefasst (Levenshtein ≤ 2 bzw. 15 %, oder drei gemeinsame Anfangswörter). Namensvarianten stiegen dadurch von 730 auf 1.615 Adressen, Sammeladressen sanken von 1.430 auf 1.085.
3. „& Co. KG" passte nie. Rechtsformen wurden nach dem Entfernen der Satzzeichen abgeglichen — „gmbh & co kg" traf nie auf „gmbh co kg". Jetzt wortweise vom Ende her gestrippt.

E1 entschieden: Schwellwert 3. Bei 2 wird jede zweite Schreibweise zur „Agentur" (ProCoReX, Welcon — je eine Firma mit Rechtsformwechsel). Bei 4 wandern 768 echte Mehrkunden-Adressen wie presse@agentur-zb.de in die Handarbeit. Konfiguriert in config/newsroom.php.

Zu 3.3: 1.085 Sammeladressen mit 6.706 Firmen, davon 1.072 mit Meldungen — namentlich benannte PR-Agenturen. Das Agenturmodell ist kein Zukunftsfeature, sondern ein vorhandenes Datenproblem.

1a.2 — Persistierte Klassifizierung

php artisan companies:classify-addresses [--threshold=] [--dry-run]

Tabelle company_email_groups, eine Zeile je Adresse — die Klassifizierung ist eine Eigenschaft der Adresse, nicht der Firma. Bewusst eigene Tabelle statt Spalten auf companies (FULLTEXT → jedes ADD COLUMN ein Rebuild).

Die Klassifizierungslogik liegt in CompanyAddressClassifier und wird von Bericht und Persistierung benutzt — beide müssen dieselbe Antwort geben, sonst zeigt der Bericht etwas anderes, als die Zusammenführung später tut.

manual_classification übersteuert die berechnete Klasse und überlebt jede Neuberechnung. Nötig für Grenzfälle, die nur ein Mensch entscheiden kann: presse@pr4you.de ist eine echte Agentur, sieht in den Daten aber aus wie eine Wegwerfadresse. CompanyEmailGroup::effectiveClassification() ist die einzige Stelle, die 1a.3/1a.4 fragen dürfen. Wer über eine Adresse entscheidet, liest nie die berechnete Spalte direkt.

Wiederholbar: Adressen, unter denen nur noch eine Firma steht, fallen beim nächsten Lauf heraus — außer sie tragen eine Handentscheidung.

Laufzeit: 3,2 s über den ganzen Bestand. Die Ähnlichkeitsprüfung ist quadratisch und bei 25 Repräsentanten gedeckelt — ab da steht die Klasse fest, und yahoo@yahoo.com hätte sonst neun Millionen Levenshtein-Aufrufe gekostet.

Deploy: migrate --force, config:cache, dann einmal companies:classify-addresses. Der Befehl gehört vorerst nicht in den Scheduler — die Klassifizierung soll sich nicht über Nacht ändern, während jemand im Admin darüber entscheidet. Nach 1a.4 neu bewerten.

Live-Trockenlauf vom 11.09.2026 (nach Migration, Schwellwert 3):

Klasse	Adressen	zusammenführbar
Dublette	12 812	ja
Namensvariante	1 615	ja
Vorschlag	3 632	nein
Sammeladresse	1 085	nein
nie veröffentlicht	23	nein
gesamt	19 167

Deckungsgleich mit dem Bericht aus 1a.1 — Bericht und Persistierung rechnen dieselbe Logik. 14 427 Adressen (75 %) sind zusammenführbar; hinter ihnen stehen die 17 945 Firmen aus 1a.1. Der scharfe Lauf am selben Tag schrieb dieselben 19 167 Zeilen nach company_email_groups — die Tabelle ist auf Live gefüllt, 1a.3 kann darauf filtern.

Korrektur: „veröffentlicht" heißt „jemals veröffentlicht"

Die 23 Nie-veröffentlicht-Adressen von Live hatten alle exakt null Firmen mit Meldung — darunter pr4you (65 Firmen), Blödorn PR (35), Crossover Point (31), GCE (48). Sieben Agenturen, die nie etwas veröffentlicht haben sollen, sind kein Befund, sondern ein Messfehler.

Nachgeprüft in der Dev-DB (Kopie des Bestands):

Adresse	Meldungen	Status	davon mit Aufrufen	Zeitraum
presse@pr4you.de	199	rejected	199	2008–2011
h.ballwanz@pr4you.de	473	rejected	473	2006–2011
info@bloedorn-pr.de	194	rejected	193	2006–2011
info@gce-agency.com	328	rejected	328	2009–2011
press@crossoverpoint.de	149	rejected	148	2009–2011
yahoo@yahoo.com	5 176	rejected	0	2015–2019
hcgdietinsight4@gmail.com	73	rejected	0	2011–2012

Ursache: Das Altsystem hat 2009–2018 rund 126 000 Meldungen auf rejected gesetzt (gegenüber 31 000 published); 83 000 davon tragen Aufrufe. Eine abgelehnte Meldung wird nie aufgerufen — die waren online und sind später pauschal offline genommen worden. rejected im Altbestand bedeutet „offline", nicht „redaktionell abgelehnt". Der Importer hat den Status korrekt übernommen; nur die Deutung war falsch.

Fix in CompanyAddressClassifier::classifyAll(): eine Firma gilt als veröffentlicht, wenn sie eine Meldung mit status = published oder hits > 0 hat. Zwei Tests halten beide Seiten fest (Agentur mit alten Offline-Meldungen → Sammeladresse; abgelehnte Meldungen ohne einen Aufruf → nie veröffentlicht). Laufzeit unverändert (2,6 s).

Wirkung (Dev-DB, Stand etwas älter als Live): 23 → 7 nie veröffentlicht, 16 wandern zur Sammeladresse. Die übrigen Klassen sind unberührt — das Veröffentlichungssignal entscheidet nur zwischen „nie veröffentlicht" und Sammeladresse. Die Sieben, die bleiben: yahoo@yahoo.com, pr@getarticlesdone.com, hcgdietinsight4@gmail.com, zhangmh@itecheasy.com, andrewkarvert112@gmail.com, kontakt@pr-vertretung.de (159 Firmen, 1 mit Aufruf), bukmaier@prdienst.de (28 Firmen, keine einzige Meldung). Letztere ist die einzige mit Agentur-Namen — sie kann bei Bedarf per manual_classification umgestellt werden.

Nebenbefund für spätere Auswertungen: Jede Statistik, die status = rejected über den Altbestand als Ablehnung liest, misst falsch. Die Ablehnungsquote aus 0.2 ist nicht betroffen (sie läuft über die Statuslogs des neuen Systems).

Deploy: Nach dem Deploy companies:classify-addresses erneut laufen lassen — die 16 Adressen werden dabei umklassifiziert, Handentscheidungen bleiben.

1a.3 — Zusammenführung im Bestand

php artisan companies:merge   [--dry-run] [--limit=] [--email=] [--json]
php artisan companies:unmerge --merge=ID | --batch=UUID | --email=  [--dry-run]

Der Fakt, der den Entwurf bestimmt hat

Die meisten „Dubletten" sind dieselbe Firma auf zwei Portalen: Das Altsystem hat jede Firma je Portal einmal angelegt.

	Gruppen
Adressgruppen gesamt (Dev-DB)	18 860
davon mit Firmen auf beiden Portalen	14 519 (77 %)
Zweiergruppen	15 754
davon exakt PE + B24	12 605
davon zusätzlich mit identischem Slug	12 037

Portal::Both existiert im Code — Newsroom-Controller, PortalScope und Slug-Auflösung behandeln es —, aber keine Firma trug es. Die Zusammenführung ist also weniger „Dubletten löschen" als „zwei Portalhälften zu einer Firma machen": Der Überlebende bekommt both, die Meldungen behalten ihr Portal, der Newsroom zeigt auf jedem Portal die Meldungen dieses Portals.

Entscheidungen (15.09.2026, A/A/A + both)

1. Es bleibt die Firma mit den meisten jemals veröffentlichten Meldungen (published oder hits > 0), bei Gleichstand die ältere. Leere Stammdatenfelder (Website, Telefon, Fax, Adresse, Land, Logo, Boilerplate, Inhaber) füllt sie aus den wegfallenden Firmen; belegte bleiben. Ist der Überlebende inaktiv und eine wegfallende Firma aktiv, wird er aktiv.
2. Meldungen, Kontakte, KI-Erklärungen, Konversionsereignisse wandern per company_id. company_user und Zahlungsoptionen werden zur Vereinigung; ein Nutzer, der schon am Überlebenden stand, wird nicht doppelt — sein alter Eintrag fällt weg und ist als dropped mit Rolle protokolliert. Jede Bewegung steht in company_merge_moves; der Vorgang in company_merges (Batch-ID, Überlebender, sein Portal vorher).
3. Die wegfallende Firma wird soft-deleted. Ihr alter Slug führt per 301 zum Überlebenden (NewsroomDetailPageData::mergedInto()), sofern der Slug abweicht — bei gleichem Slug findet die Auflösung den both- Überlebenden direkt. Kein 410: Die Firma gibt es noch, nur woanders.

Slug-Kollision: Wird der Überlebende both, muss sein Slug auf dem anderen Portal frei sein (die öffentliche Auflösung fragt portal IN (eigenes, both)). Ist der Erstkandidat blockiert, kommt der nächste dran; ist keiner frei, wird die Adresse übersprungen und aufgelistet. Nicht umbenannt — die URL ist öffentlich. Vorab geschätzt 664 Gruppen, tatsächlich 5 — die Kollisionen sind fast immer einseitig (Alt-Slugs sind je Portal durchnummeriert), und die andere Hälfte ist frei.

410-entfernte Firmen bleiben außen vor: Ihre Meldungen in den Überlebenden zu heben, würde bewusst entfernte Inhalte wieder sichtbar machen.

Keine Schema-Änderung an bestehenden Tabellen. Kein merged_from_company_id auf press_releases (1 GB, einmaliger Vorgang), kein merged_into_company_id auf companies (FULLTEXT) — beides kommt aus den zwei neuen Tabellen. press_release_search enthält keine Firmendaten; das Umhängen per Query-Builder braucht keinen Reindex.

Nebenbefund und Fix: Slug-Eindeutigkeit kannte both nicht

HasUniqueSlug prüft bei Firmen nur portal = X. Eine neue PE-Firma hätte denselben Slug wie eine both-Firma bekommen können — und die Newsroom-URL hätte zwei Firmen gefunden. Company::slugExists() prüft jetzt portal IN (X, both), und eine both-Firma braucht den Slug überall frei. Test in HasUniqueSlugTest.

Lauf auf der Dev-DB (Kopie des Bestands)

Adressen zusammengeführt	14 142
Firmen im Überlebenden aufgegangen	16 194
Meldungen gewandert	13 297
Firmen jetzt both	12 926
Kontakte gewandert	8 038
Nutzer-Verknüpfungen weggefallen (schon am Überlebenden)	15 467
Stammdatenfelder aufgefüllt	1 819
übersprungen (Slug-Kollision)	5
Laufzeit merge / unmerge	2:00 min / 1:15 min

Nach companies:unmerge --batch=… stimmten Portalverteilung (42 287 / 66 892), company_user (107 663) und Soft-Deletes (2 155) wieder exakt mit dem Stand davor überein. Die Rückabwicklung ist verifiziert.

Zwei Performance-Punkte beim Bau: Die Kollisionsprüfung mit portal != ? kostete 24 ms je Adresse (kein Index) — mit portal IN (…) greift der Unique-Index (portal, slug), 0 ms. Und wegfallende Firmen werden per Query-Builder soft-deleted, nicht per $company->delete(): Der Observer würde je Firma den Admin-Cache leeren; der Lauf leert einmal am Ende.

Prüfen: companies:merges --batch=<ID> listet je Vorgang den Überlebenden mit seinen Newsroom-URLs auf beiden Portalen, die aufgegangenen Firmen und deren alte URLs, die per 301 weiterführen. Nachgerüstet nach dem ersten Live-Lauf mit --limit=50 — der scharfe Lauf zeigte nur die Batch-ID, und die Frage „welche 50 sind das?" war berechtigt. Der scharfe Lauf zeigt seither auch die ersten 30 Vorgänge als Tabelle.

Deploy: migrate --force, dann companies:merge --dry-run, dann companies:merge --limit=50 und die 50 im Admin ansehen, dann ohne Limit. Erledigte Adressen zählen beim zweiten Lauf nicht gegen das Limit. Danach companies:classify-addresses — die zusammengeführten Adressen fallen aus company_email_groups, weil nur noch eine Firma darunter steht.

Live-Trockenlauf vom 15.09.2026 (nach Migration): 14 422 Adressen, 18 096 Firmen gehen auf, 14 545 Meldungen wandern, 13 296 Firmen werden both, 7 Slug-Kollisionen übersprungen (pizza.de, x84.de, 2× eposso-energy, anzeiger24, togev, afan.academy). Gegenüber der Dev-DB rund 280 Adressen mehr — der laufende API-Zulauf: Unter 301@seo-manager.info stehen vier Firmen mit IDs ab 111 999, alle aus September, je Meldung eine. Genau das, was 1a.4 abstellt.

Auffällig: Bei 1@schlotterimmobilienplus.de bleibt #112132, eine dieser neuen API-Kopien, weil die drei älteren Firmen keine veröffentlichte Meldung tragen — Regel 1 greift wie entschieden, die alte URL führt per 301 auf die neue. Wer den alten Slug behalten will, entscheidet das vor dem Lauf von Hand (--email= einzeln, oder die Gruppe per manual_classification aussparen).

Live-Läufe vom 15.09.2026: Batch 4e1a7235… (--limit=50, 60 Firmen, 33 Meldungen, 48× both), danach Batch af3fb304… über den Rest — die 50 erledigten Adressen wurden dabei als „nichts zusammenzuführen" übersprungen, wie vorgesehen. Zwei Beobachtungen aus der Tabelle:

• a.hezel@serviceplan.com: Es bleibt #52565 „serviveplan public relations" (Tippfehler im Namen), weil sie mehr Meldungen trägt als #18934 „serviceplan public relations". Regel 1 entscheidet nach Inhalt, nicht nach Schreibweise — der Name wird im Admin korrigiert, die URL bleibt.
• a.helf@ubc-collection.com: acht Firmen, sieben davon mit IDs ab 112 698 aus den letzten Tagen, je eine Meldung — der API-Zulauf, den 1a.4 abstellt.

Kompletter Live-Lauf, 15.09.2026 (Batch a0e38bbd…): 14 356 Adressen, 18 013 Firmen aufgegangen, 14 496 Meldungen gewandert, 13 236 Firmen jetzt both, 6 Slug-Kollisionen übersprungen. Zusammen mit den beiden 50er-Batches davor: ~14 450 Adressen, ~18 100 Firmen, ~14 550 Meldungen.

companies:classify-addresses danach: 4 749 Adressen — Dublette 4, Namensvariante 3 (die Slug-Kollisionen plus API-Zulauf seit dem Lauf), Vorschlag 3 633, Sammeladresse 1 102, nie veröffentlicht 7. Der Bestand ist konsolidiert; was jetzt noch zusammenführbar ist, entsteht laufend neu — das ist 1a.4.

Offen: die 6 Slug-Kollisionen einzeln ansehen (pizza.de, x84.de, 2× eposso-energy, anzeiger24, togev). Möglich ist, die fremde Firma mit dem blockierenden Slug zu prüfen — oft ist das dieselbe Firma unter anderer Adresse (Vorschlag-Klasse) — und danach mit --email= nachzuziehen.

1a.4 — Laufende Zuordnung neuer API-Meldungen

Der Alt-Vertrag der API legt vor jeder Meldung eine Firma an: connektar schickt je Meldung POST /service/users/me/companies und dann die Meldung mit der zurückgegebenen ID. Deshalb entstand je Meldung ein Newsroom — a.helf@ubc-collection.com hatte sieben aus einer Woche.

ApiNewsroomAssignment prüft jetzt VOR dem Anlegen, ob unter derselben Firmen-E-Mail schon eine Firma mit demselben Namen steht — „derselbe Name" ist CompanyAddressClassifier::namesMatch(), also exakt die Regel der Klassifizierung (Rechtsform, Tippfehler, gemeinsamer Anfang). Bei Treffer bekommt der Aufrufer deren ID zurück. Der Vertrag bleibt: 201 + Location. connektar merkt nichts davon, außer dass die ID eine alte ist.

Regeln:

• Kein Treffer bei abweichendem Namen → neue Firma wie bisher. Das ist der Agenturfall: neuer Kunde unter der Sammeladresse.
• Nie-veröffentlicht-Adresse (company_email_groups, Handentscheidung übersteuert) → nie zuordnen.
• 410-entfernte und aufgegangene (soft-deleted) Firmen werden nicht getroffen — der Überlebende schon.
• Anderes Portal: Die Firma wird both, die neue Meldung bekommt das angefragte Portal, die alten behalten ihres. Ist der Slug auf dem anderen Portal fremd belegt, bleibt es beim alten Verhalten (neue Firma) — dieselbe Kollisionsregel wie in 1a.3, jetzt als Company::slugTakenOnOtherPortals() an einer Stelle.
• Der API-Nutzer wird als member an die Firma gehängt, sonst dürfte er dort keine Meldung anlegen. Jede Zuordnung steht im Aktivitätsverlauf („API-Firma … dem bestehenden Newsroom #… zugeordnet").

Folgeänderung in LegacyPressReleaseController: both ist kein Ziel-Portal für eine Meldung. Fällt die Portal-Auflösung auf das Portal der Firma zurück und das ist both, entscheidet das Portal des API-Nutzers. Vorher hätte eine Meldung ohne Parameter und Domain-Kontext both bekommen.

Tests: tests/Feature/Api/ApiNewsroomAssignmentTest.php (9).

Messung: companies:classify-addresses nach ein, zwei Wochen — Dublette und Namensvariante müssen bei den 7 aus den Slug-Kollisionen bleiben. Steigt die Zahl, trifft die Zuordnung nicht; companies:merges und der Aktivitätsverlauf zeigen, was zugeordnet wurde.

---

Teil 4 — Block 1b: Newsroom als Produkt (15.09.2026)

1b.1 / 1b.5 — Sichtbarkeitsregel und Rückbau

Die Regel bestand bereits: Detailseite 404 ohne veröffentlichte Meldung, Verzeichnis, Sitemap und Hub-Zähler nur mit einer. Der Rückbau war aber unvollständig: depublish() und markGone() leerten den Seiten-Cache, archive(), changeStatusFromAdmin() (weg von published) und deleteFromAdmin() einer veröffentlichten Meldung nicht — der Newsroom stand nach der letzten Meldung bis zu eine Stunde weiter im Cache. Jetzt leeren alle fünf Wege. Drei Tests in NewsroomPageTest halten den Rückbau fest.

1b.2 — Verwaltungszugang über Magic Link

GET/POST  /{edition}/newsroom/{slug}/verwalten

Der allgemeine Anmeldelink (/anmeldelink auf pressekonto, WS-2) bestand: Wer eine E-Mail eingibt, die an einer Firma oder einem Pressekontakt steht, bekommt lazy ein Konto mit Firmen-Scope. Was fehlte, war der Weg vom Newsroom aus, ohne dass der Besucher eine Adresse kennt oder eingibt — und unabhängig davon, ob der Newsroom überhaupt schon öffentlich ist.

NewsroomClaimService + NewsroomClaimController:

• Die Seite zeigt Firmenname und die maskierte Empfängeradresse (i***@muster.de). Ein Klick schickt den Anmeldelink dorthin. Kein Eingabefeld → kein Enumerationsproblem, keine fremde Adresse.
• Empfänger: die Firmen-E-Mail; fehlt sie, die Pressekontakte. Bewusst nicht beides — ein Klick eines Fremden soll nicht fünf Postfächer treffen.
• Erreichbar für jede Firma mit Slug, auch ohne veröffentlichte Meldung und auch deaktiviert (das ist der Punkt von 1b.2). 410-entfernte bleiben Tombstone, aufgegangene (1a.3) führen per 301 zum Überlebenden — dieselbe Auflösung wie die Newsroom-Seite, jetzt in MergedNewsroomLookup.
• Konto, Zuordnung (responsible) und Versand laufen durch ContactAccessService::requestMagicAccess() — kein zweites Zugangssystem. Neu dort: Herkunft und Ziel-Firma werden durchgereicht.
• Herkunft profile_claim auf dem Token — Stufe 2 der Konversionsleiter misst damit, wie viele Newsrooms über diesen Weg beansprucht werden.
• Landung: Der Login führt direkt auf die Firmenseite im Kundenbereich (me.press-kits.show), nicht aufs Dashboard — company_id liegt im payload des Tokens, kein Schema-Eingriff.
• Drosselung: 3 Links je Newsroom und Tag (config/newsroom.php, NEWSROOM_CLAIM_LINKS_PER_DAY), 15 je IP und Stunde, Honeypot.

Tests: tests/Feature/Web/NewsroomClaimTest.php (7).

Noch nicht verlinkt. Die Seite existiert, aber weder die Newsroom-Seite noch die Veröffentlichungsmail zeigen darauf — das ist 1b.4 und hängt an E4 (ein Element pro Mail: Magic-Link-Hinweis oder Infoseite).

Zu 1b.3 vorab: Die Firmenseite im Kundenbereich kann heute Name, Adresse, E-Mail, Telefon, Website, Land, Logo und Pressekontakte pflegen. Was 1b.3 ergänzt: Beschreibungstext (durch die Rot-Ebene), Bilder (mit KI-Deklaration und Audit-Log), und die Leitplanke, dass Links im Profiltext systemseitig gesetzt werden.

1b.4 — Hinweise (E4 entschieden 15.09.2026)

E4: Die Veröffentlichungsmail trägt den Magic-Link-Hinweis — am Ende, als Hinweis, nicht als Angebot. Damit bekommt der Link auf die Infoseite (1d.2) keinen Platz in dieser Mail (ein Element pro Mail).

• Newsroom-Seite: eine Zeile unter dem Firmenprofil („Sie vertreten …? Profil, Logo und Pressekontakte lassen sich kostenlos pflegen. Diesen Newsroom verwalten"), rel="nofollow", 12 px, ink-3.
• Veröffentlichungsmail: ein Absatz vor dem Hilfe-Hinweis, in derselben grauen Kleinschrift wie der bestehende Login-Hinweis. Link auf /newsroom/{slug}/verwalten des Portals, auf dem die Meldung erschien (bei beiden: presseecho), getaggt mit src=mail_publish&pr=. Kein Hinweis ohne Firma oder bei 410-entfernter Firma.
• Herkunft läuft durch: Die Claim-Seite reicht src aus dem Mail-Link per verstecktem Feld weiter; das Token trägt dann mail_publish statt profile_claim. Stufe 1 (Klick) zeichnet die globale Middleware beim Aufruf der Claim-Seite ohnehin auf. So unterscheidet die Leiter „aus der Mail beansprucht" von „auf der Seite entdeckt".

Tests: drei weitere in NewsroomClaimTest (Seite, Mail, Herkunft).

1b.3 — Kostenlose Profilpflege (Entscheidung 15.09.2026: Bilder zurückgestellt)

Die Firmenseite im Kundenbereich konnte Name, Adresse, Kontakt, Website, Land, Logo und Pressekontakte. Neu:

• Beschreibung (companies.boilerplate, max. 2 000 Zeichen) als Textarea. Erscheint im Newsroom und unter jeder Meldung als „Über das Unternehmen". Beim Speichern wird der Seiten-Cache geleert.
• Rot-Ebene: Der Text läuft durch dieselbe Klassifikation wie eine Meldung (CompanyProfileCheck: KI-Treiber, bei Ausfall deterministische Blacklist — das Muster der Spur-D-Vorprüfung). Rot → Validierungsfehler, nichts wird gespeichert. Gelb ist für ein Firmenprofil kein Grund.
• Leitplanke Links: Reiner Text. strip_tags beim Speichern, escaped beim Rendern — es gibt im Profiltext keine Links, die man auszeichnen müsste. Die Website ist das eine Link-Feld und trägt bereits nofollow. Damit ist die Leitplanke durch Weglassen erfüllt statt durch eine Policy.
• Bilder: zurückgestellt, bis die Bild-Kennzeichnung angepasst ist. Im Formular als „Bilder im Newsroom — BALD — Funktion folgt" sichtbar, nicht weggelassen (Roadmap-Leitplanke).
• Stufe 3 der Konversionsleiter (newsroom_edited) wird hier geschrieben — die letzte offene Schreibstelle aus Block 0. Einmal je Firma; Herkunft ist die des zuletzt eingelösten Magic Links des Kontos (so zählt „aus der Mail beansprucht, dann Beschreibung geschrieben" für die Mail), sonst organic.

Tests: tests/Feature/NewsroomProfileTest.php (4).

1b.6 — Bounce-Suppression (Schritte 1 und 2, 15.09.2026)

Grundlage ist das Konzept bounce-mails-2026-09-15.md (eigenes Postfach als Return-Path, X-Pk-Ref-Header, IMAP-Abholung mit eigenem DSN-Parser, SMTP-Ablehnung als zweiter Pfad, Circuit Breaker). Zwei Korrekturen daran: Der Return-Path muss auf der From-Domain liegen (bounce@pressekonto.com, nicht presseecho.de — SPF-Ausrichtung für DMARC), und nicht jede 5xx ist ein Empfängerproblem: 554-Spam-Pattern des Relays sperrt sonst gesunde Adressen.

Schritt 1 — Liste und Gate

• email_bounces (Ereignis-Log, idempotent über message_id) und email_suppressions (Zustand je Adresse: Grund, Zähler, suppressed_at, released_at). Hart → sofort gesperrt; weich → ab dem dritten in sieben Tagen (config/bounces.php). Freigabe setzt released_at, der nächste Bounce löscht sie wieder.
• EmailSuppressionService — die eine Stelle, die „nicht erreichbar" heißt.
• GateOutgoingMail am MessageSending-Event: streicht gesperrte Empfänger aus jeder ausgehenden Mail, verwirft sie ganz, wenn keiner bleibt (mit Eintrag im Aktivitätsverlauf, Typ „Mail-Sperre"), setzt den Return-Path (MAIL_RETURN_PATH). Eine Stelle für Magic Links, Benachrichtigungen, Newsletter und alles Künftige.
• X-Pk-Ref auf Veröffentlichungs-, Ablehnungs- und Magic-Link-Mail (pm:ID:company:ID, user:ID).
• API-Meldungen: Ist der Pressekontakt gesperrt, geht die Mail an die Firmen-E-Mail; ist die auch gesperrt, an niemanden — nie an den API-Einlieferer.
• newsletter:import-bounces schreibt jetzt zuerst in die zentrale Liste — damit erreicht die Handliste auch Pressekontakte und Firmen ohne Konto.

Schritt 2 — SMTP-Pfad und Circuit Breaker

• RecordSmtpFailure am JobFailed-Event: SmtpFailureClassifier deutet die TransportException. 5.1.x mit Adresse → harter Bounce, 4.x.x → weicher, alles andere (5.7.x, 554, Verbindung) → Relay-Ablehnung.
• MailCircuitBreaker: ab 5 Relay-Ablehnungen in 15 Minuten wird der Versand 30 Minuten angehalten, ein Betriebs-Alert. Im Worker schlagen Mails dann fehl (nachholbar mit queue:retry all), im Web-Kontext werden sie verworfen und protokolliert; Betriebs-Alerts gehen immer durch. php artisan mail:circuit [--reset] zeigt bzw. hebt die Pause auf.

Tests: tests/Feature/EmailSuppressionTest.php (11).

Deploy: migrate --force, config:cache, dann in der .env MAIL_RETURN_PATH=bounce@pressekonto.com — erst, wenn das Postfach existiert. Danach einmal newsletter:import-bounces laufen lassen, damit die bisherige Handliste in die zentrale Sperre kommt.

Offen: Schritt 3 (IMAP-Abholung, webklex/laravel-imap, freigegeben 15.09.2026) und Schritt 4 (Markierung im Admin, Claim-Seite, Freigabe).