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`](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
`&amp;` — 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.