dev: Bestandsaufnahme und Umsetzungsprotokoll zum Code-Durchgang 01.09.

Vollständige Prüfung von app/, den Migrationen und dem gesamten bis dahin nicht
committeten Arbeitsstand: gefundene Fehler nach Schwere, die Ursachenanalyse
zur unbrauchbar gewordenen statischen Analyse, und die Voraussetzungen, die die
Roadmap braucht und die noch fehlten.

Das Umsetzungsprotokoll hält je Befund fest, was geändert wurde, welche
Vorschläge abgewandelt oder verworfen wurden und warum — darunter zwei
Falschbefunde meiner eigenen Bestandsaufnahme, die beim Beheben aufgefallen
sind.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

dev/2026-09-01/bestandsaufnahme-code.md

@@ -0,0 +1,375 @@
+# Bestandsaufnahme Code — Stand 01.09.2026
+
+**Zweck:** Ausgangslage vor der Umsetzung von `roadmap-2026.md`. Was ist gesund,
+was ist kaputt, was muss vor dem ersten Roadmap-Arbeitspaket geradegezogen
+werden.
+
+**Prüfumfang:** 348 PHP-Dateien / ~33.900 Zeilen in `app/`, 108 Migrationen,
+201 Testdateien, dazu der gesamte noch nicht committete Arbeitsstand
+(41 geänderte + 22 neue Dateien aus den Blöcken „Suchtabelle/FULLTEXT-Umzug",
+„410-Tombstone", „API-Portal-Zuordnung", „Bounce-Import").
+
+> **Bearbeitungsstand 01.09.2026:** Abschnitt 7 ist vollständig abgearbeitet.
+> Was genau geändert wurde, welche Vorschläge abgewandelt oder verworfen wurden
+> und welche Entscheidung noch offen ist, steht in
+> **[`umsetzung-protokoll.md`](umsetzung-protokoll.md)**.
+>
+> **Eine Korrektur an diesem Bericht:** Befund **L6** war falsch — siehe unten.
+
+---
+
+## 1 Werkzeugstand
+
+| Prüfung | Befehl | Ergebnis |
+|---|---|---|
+| Tests | `php artisan test --compact` | **1479 grün**, 1 übersprungen, 6472 Assertions, 121 s |
+| Codestil | `vendor/bin/pint --test` | **passed** |
+| Statische Analyse | `vendor/bin/phpstan analyse` | **fehlgeschlagen — 390 Fehler außerhalb der Baseline** |
+
+Die Testabdeckung ist gut und der neue Arbeitsstand ist mitgetestet
+(`GoneTombstoneTest`, `PressReleaseSearchIndexTest`, `ApiPortalResolutionTest`,
+`FixApiPortalDuplicatesTest`, `ImportNewsletterBouncesTest`,
+`OnlineSchemaChangeCommandTest`). Die statische Analyse dagegen ist faktisch
+außer Betrieb — siehe P1, das ist der Befund mit dem größten Hebel.
+
+---
+
+## 2 Werkzeug & Prozess
+
+### P1 — Statische Analyse liefert seit Monaten nur noch Rauschen
+
+**Symptom:** 390 Fehler außerhalb der Baseline. Darunter Dutzende Meldungen der
+Art „Strict comparison using === between string and
+`App\Enums\PressReleaseStatus::Published` will always evaluate to false"
+(u. a. `app/Models/PressRelease.php:507`, `app/Services/PressRelease/BoostService.php:45`,
+`app/Listeners/ProcessStripeWebhook.php:424`). Zur Laufzeit funktioniert dieser
+Code — die Meldungen sind falsch.
+
+**Ursache:** Larastan löst **überhaupt keine Casts auf**. Nachgewiesen mit
+`PHPStan\dumpType()`:
+
+```
+$pressRelease->status        → string          (erwartet: PressReleaseStatus)
+$pressRelease->portal        → string          (erwartet: Portal)
+$pressRelease->published_at  → string|null     (erwartet: Carbon|null)
+```
+
+Grund: Alle 49 Models deklarieren ihre Casts über die `casts()`-**Methode**
+(Laravel-11-Stil). Laravel führt diese Methode erst zur Laufzeit mit
+`$this->casts` zusammen (`HasAttributes.php:206`), Larastan instanziiert Models
+aber mit `newInstanceWithoutConstructor()` und sieht deshalb nichts. Für genau
+diesen Fall gibt es den Schalter `parseModelCastsMethod`, dessen Larastan-Default
+`false` ist (`vendor/larastan/larastan/extension.neon:34`) und der in
+`phpstan.neon` nicht gesetzt ist.
+
+**Nachgewiesene Wirkung des Schalters:** mit `parseModelCastsMethod: true`
+lösen alle drei Typen oben korrekt auf, die Fehlerzahl fällt von 390 auf 266.
+
+**Zweitursache:** Die Baseline (`phpstan-baseline.neon`, 127 Einträge) ist seit
+dem 12.05.2026 unverändert — knapp vier Monate Drift. 39 ihrer Einträge greifen
+inzwischen ins Leere (`ignore.unmatched`).
+
+**Drittursache:** `composer analyse` existiert, läuft aber in keiner Pipeline.
+`.github/workflows/lint.yml` ruft nur Pint auf, `tests.yml` nur die Tests. Nichts
+hält die Analyse grün.
+
+**Schritte**
+
+1. `parseModelCastsMethod: true` in `phpstan.neon` setzen.
+2. Der Rest der 266 Meldungen ist überwiegend echtes Rauschen ohne Codefehler:
+   84 × `property.notFound` (`withCount`-Aliasse wie `recent_releases_count`,
+   Relationen ohne Generic), 50 × `method.notFound` (eigene Scopes wie
+   `forPortalValues()`, `visibleInArchive()` ohne `@method`-Annotation),
+   35 × `nullsafe.neverNull`. Das lässt sich mit `@method`-Annotationen auf den
+   Scopes und `/** @return Builder<static> */` an den Scope-Methoden
+   substanziell senken, ohne eine Zeile Logik anzufassen.
+3. Baseline **danach** neu erzeugen, nicht vorher — sonst zementiert sie die
+   falschen Cast-Meldungen.
+4. `composer analyse` in `tests.yml` aufnehmen. Ohne Gate driftet die Baseline
+   binnen weniger Wochen erneut.
+
+---
+
+## 3 Befunde — hoch
+
+### H1 — Deploy-Fenster: bis zu 60 s SQL-Fehler in der Suche
+
+`app/Models/PressReleaseSearchIndex.php:75` — `isAvailable()` cacht die Antwort
+eine Minute:
+
+```php
+return Cache::remember('press-release-search.available', now()->addMinute(), …);
+```
+
+Solange `false` gecacht ist, greift der Rückfallpfad
+(`PressReleaseSearchIndex.php:110`) und setzt `whereFullText()` **auf
+`press_releases`** ab. Läuft in diesem Fenster die Migration
+`drop_fulltext_indexes_from_press_releases`, existiert der Index dort nicht mehr
+→ MySQL-Fehler 1191 („Can't find FULLTEXT index matching the column list") →
+500er auf jeder Suche der Web-Seite und der Admin-PM-Liste, bis der Cache-
+Eintrag abläuft.
+
+**Fix:** In `up()` beider Such-Migrationen (`create_press_release_search_table`
+und `drop_fulltext_indexes_from_press_releases`)
+`Cache::forget('press-release-search.available')` aufrufen. Ergänzend den
+Rückfallpfad in `constrain()` gegen `QueryException` absichern und im Fehlerfall
+auf die Suchtabelle umschalten.
+
+### H2 — Newsroom-Entfernung flusht den kompletten Seiten-Cache N-mal
+
+`app/Services/Company/CompanyRemovalService.php:61-71` lädt **alle**
+Pressemitteilungen der Firma mit `->get()` in den Speicher und ruft je Zeile
+`PressReleaseService::markGone()`. Diese Methode flusht in
+`PressReleaseService.php:495` über `WebCaches::forgetPublicPages()` jedes Mal:
+
+* `WebPageCache::flush()` → Generations-Zähler +1 → **sämtliche** `web.`-Seiten-Caches verworfen,
+* `WebCaches::forgetSitemaps()` → alle Sitemap-Caches je Host.
+
+Bei einer Firma mit 300 Meldungen sind das 300 vollständige Cache-Invalidierungen
+in einer Schleife, gefolgt von einer 301. in Zeile 73. Jede davon zwingt die
+gesamte öffentliche Seite in den Neuaufbau — ein selbst ausgelöster
+Cache-Stampede auf einer Aktion, die aus dem Admin heraus mit einem Klick kommt.
+Dazu der unbegrenzte `->get()`.
+
+**Fix:** `markGone()`/`restoreFromGone()` um einen Parameter erweitern, der den
+Flush unterdrückt (oder eine interne `markGoneWithoutFlush()`), über
+`chunkById()` statt `get()` iterieren und **einmal** am Ende flushen. Zeile 73
+macht das ohnehin schon.
+
+### H3 — `restoreFromGone()` aktiviert Firmen, die vorher deaktiviert waren
+
+`app/Services/Company/CompanyRemovalService.php:90-93` setzt beim Aufheben
+bedingungslos `is_active = true`. `markGone()` (Zeile 46-49) setzt vorher
+bedingungslos `is_active = false`, ohne den Ausgangswert zu sichern.
+
+War die Firma **vor** der 410-Entfernung bereits deaktiviert — im Bestand der
+Normalfall bei Karteileichen —, ist sie nach dem Aufheben aktiv und taucht in
+Newsroom-Übersicht und Sitemap auf. Die UI verspricht ausdrücklich
+Umkehrbarkeit; das ist keine.
+
+**Fix:** Ausgangszustand mitschreiben (z. B. Flag in `activity_log`-Meta oder
+eine Spalte `was_active_before_gone`) und beim Aufheben zurücksetzen. Minimal:
+`is_active` beim Aufheben gar nicht anfassen und den Redakteur entscheiden
+lassen.
+
+### H4 — `no_export` bleibt nach dem Aufheben einer PM-Entfernung stehen
+
+`PressReleaseService::markGone()` (Zeile 480-490) setzt `no_export = true`.
+`restoreFromGone()` (Zeile 511-519) setzt nur `gone_at` zurück. Die Mitteilung
+ist danach zwar wieder freigegeben, bleibt aber dauerhaft aus allen Exporten
+ausgeschlossen — ohne dass das irgendwo sichtbar wäre. Dieselbe Asymmetrie wie
+H3, im selben Arbeitspaket.
+
+**Fix:** Entweder `no_export` mit zurücksetzen (dann den Vorzustand sichern, weil
+die Spalte auch redaktionell gesetzt sein kann) oder `no_export` in `markGone()`
+gar nicht setzen — `gone_at` filtert bereits über `scopeVisibleInArchive()`.
+
+---
+
+## 4 Befunde — mittel
+
+### M1 — Generations-Zähler wird prozessweit eingefroren
+
+`app/Support/WebPageCache.php:74`
+
+```php
+return self::$generation ??= (int) Cache::get(self::GenerationKey, 0);
+```
+
+Unter PHP-FPM stimmt das (ein Prozess = ein Request). In langlebigen Prozessen —
+`queue:work`, ein späterer Octane-Betrieb — wird der Wert beim ersten Aufruf
+eingefroren und nie wieder gelesen. Konkrete Folge:
+`BoostService::forgetPlacementCaches()` (Zeile 230-240) baut seine
+`Cache::forget()`-Keys über `WebPageCache::key()`. Läuft das in einem Worker mit
+veralteter Generation, löscht es Keys einer alten Generation, während der
+aktuelle Eintrag stehen bleibt — die Boost-Platzierung erscheint bis zum
+TTL-Ablauf nicht.
+
+**Fix:** Memoisierung an die Request-/Job-Lebensdauer binden (Reset in einem
+`JobProcessing`-Listener) oder ganz streichen und pro Aufruf lesen — bei Redis
+ist das ein GET.
+
+### M2 — Der Generations-Zähler liegt im Namensraum, den er invalidiert
+
+`WebPageCache::GenerationKey = 'web.generation'` (Zeile 39). Der Zähler ist genau
+der eine `web.`-Key, der einen Flush überleben muss. Der Code fängt einen Verlust
+zwar ab (Zeile 88-94), aber nur innerhalb desselben Prozesses. Umbenennen auf
+etwas außerhalb des Präfixes, z. B. `page-cache:generation`.
+
+### M3 — Wasserstandsmarke ist nur chunkweise idempotent
+
+`app/Console/Commands/AggregatePressReleaseViews.php:90-101`: erst laufen alle
+`increment()` des Chunks, danach wird die Marke geschrieben. Bricht der Prozess
+dazwischen ab (OOM, Deploy, `kill`), sind die bereits verbuchten Releases beim
+nächsten Lauf **ein zweites Mal** dran. Der Klassenkommentar (Zeile 26-27)
+behauptet ausdrücklich das Gegenteil („ein doppelter Lauf zählt nichts doppelt").
+
+**Fix:** Increments und `AppSetting::setValue()` je Chunk in eine
+`DB::transaction()`. Kommentar entsprechend präzisieren.
+
+### M4 — `press_release_events` wächst unbegrenzt
+
+Die Tabelle ist seit dem Umbau die Quelle jedes Seitenaufrufs (`PressRelease::recordDeferredView()`),
+liegt laut Migrationskommentar bei knapp einer Million Zeilen und wächst mit
+jedem Request weiter. Im Scheduler (`routes/console.php`) gibt es Aufräum-Tasks
+für Magic Links, Snapshots und Entwürfe — für dieses Log keinen.
+
+Nach der Aggregation werden die Aufruf-Ereignisse nur noch für die geplante
+Absenderansicht (Roadmap 1c.1, „Aufrufe im Verlauf") gebraucht. Das legt einen
+Aufbewahrungszeitraum nahe, keine Ewigkeit.
+
+**Fix:** Retention festlegen (Vorschlag: 13 Monate, damit Vorjahresvergleiche
+möglich bleiben) und einen `press-releases:purge-events`-Task ergänzen, der
+ausschließlich Ereignisse **unterhalb der Wasserstandsmarke** löscht. Diese
+Entscheidung gehört vor 1c.1 — sie bestimmt, wie weit die Verlaufsansicht
+zurückreicht.
+
+### M5 — Migration umgeht den AppSetting-Cache
+
+`database/migrations/2026_08_25_120000_seed_press_release_view_watermark.php`
+schreibt mit `DB::table('app_settings')->updateOrInsert()` und räumt den
+`rememberForever`-Eintrag `app-setting.press_release_views.aggregated_through_id`
+nicht ab. Lief der Scheduler-Task im Deploy-Fenster einmal vor der Migration, hält
+der Cache die alte, niedrigere Marke und der nächste Lauf zählt das Fenster
+dazwischen doppelt. Ein `Cache::forget()` am Ende von `up()` genügt.
+
+### M6 — `$companyId` in der Firmen-Bearbeitung ist nicht `#[Locked]`
+
+`resources/views/livewire/admin/companies/edit.blade.php:19` —
+`public int $companyId;` ohne Attribut, obwohl das Gegenstück in
+`admin/press-releases/edit.blade.php:34` `#[Locked] public int $id` verwendet.
+`save()`, `deleteCompany()` und die neuen `markGone()`/`restoreGone()` arbeiten
+alle auf diesem vom Client manipulierbaren Wert. Die `authorize('companies:write')`-
+Prüfung greift, das Ausmaß ist also begrenzt — aber die Aktion trifft dann eine
+andere Firma als die im Formular angezeigte, und die Inkonsistenz zum
+PM-Formular ist unnötig. `#[Locked]` ergänzen.
+
+### M7 — Legacy-API kann `portal = null` schreiben
+
+`app/Http/Controllers/Api/Legacy/LegacyPressReleaseController.php:111`
+
+```php
+$pressRelease->portal = $this->resolveRequestedPortal(…)?->value;
+```
+
+`resolveRequestedPortal()` (`app/Http/Controllers/Api/Concerns/ResolvesRequestedPortal.php:20`)
+gibt `null` zurück, wenn weder Parameter noch Portal-Kontext noch
+`$company->portal` greifen. Die Spalte ist ein `ENUM … NOT NULL DEFAULT 'both'`
+(`create_press_releases_table.php:19-22`) — das Ergebnis ist ein SQL-Fehler und
+damit ein 500er statt einer verwertbaren Fehlermeldung für den Alt-Client.
+Praktisch schwer zu erreichen, aber der `?->`-Operator sagt, dass der Autor den
+Fall für möglich hält. Entweder auf `Portal::Both` defaulten oder mit 422
+antworten.
+
+### M8 — Passwort in der pt-osc-Optionsdatei ist nicht maskiert
+
+`app/Console/Commands/OnlineSchemaChange.php:192-196` schreibt
+
+```php
+sprintf("[client]\nuser=%s\npassword=%s\n", …)
+```
+
+In einer my.cnf beginnt `#` einen Kommentar, führende/abschließende Leerzeichen
+werden verschluckt. Ein DB-Passwort mit `#` wird an dieser Stelle abgeschnitten
+und pt-osc scheitert mit einem Authentifizierungsfehler, dessen Ursache man
+nirgends sieht. Wert in doppelte Anführungszeichen setzen und `"`/`\` escapen.
+
+Die Umgehung der Kommandozeile (Zeile 81-83) ist ansonsten richtig gelöst,
+ebenso `tempnam()` + `chmod(0600)` vor dem Schreiben.
+
+### M9 — Bounce-Suppression erfasst nur `users`, nicht `newsletter_subscriptions`
+
+`app/Console/Commands/ImportNewsletterBounces.php:58` sucht ausschließlich über
+`User::query()->where('email', …)` und protokolliert alles Übrige als „Kein
+User-Konto". Die Tabelle `newsletter_subscriptions` führt eine eigene
+Empfängerliste mit eigenem `unsubscribed_at` und bleibt unberührt.
+
+Die Roadmap macht „Bounce-Suppression produktiv" zum harten Blocker für 1b.6,
+1d.3 und 3.2. Solange die zweite Liste nicht mitgeführt wird, ist diese
+Voraussetzung nicht erfüllt — mit unmittelbarer Wirkung auf die
+Absender-Reputation und damit auf die Zustellbarkeit der Magic Links, die die
+Roadmap selbst als das eigentliche Risiko benennt.
+
+**Fix:** `newsletter_subscriptions` in denselben Lauf aufnehmen und ein
+gemeinsames Suppression-Konzept festlegen (eigene Tabelle oder gemeinsames
+Merkmal), bevor Block 1b/1d gebaut wird.
+
+---
+
+## 5 Befunde — niedrig / Aufräumen
+
+| Nr. | Fundstelle | Befund |
+|---|---|---|
+| L1 | `app/Services/PressRelease/ProofPdfRenderer.php:211` | `$image === null` ist immer falsch — `$embed` ist bereits null, wenn `$image` null ist |
+| L2 | `app/Services/PressRelease/ProofPdfRenderer.php:946` | `$width < 1 \|\| $height < 1` nach `imagesx()`/`imagesy()` immer falsch |
+| L3 | `app/Services/Billing/ManualInvoiceService.php:78` | `current_period_end === null` — laut Schema nicht nullable, Prüfung tot |
+| L4 | `app/Models/Company.php:178` | linke Seite von `&&` immer wahr |
+| L5 | `app/Models/PressRelease.php:415` | `null`-Arm im `match ($this->portal)` unerreichbar (Spalte NOT NULL) |
+| ~~L6~~ | `app/Listeners/ProcessStripeWebhook.php:56-57` | **FALSCHER BEFUND.** Beide werden in den Zeilen 123, 149, 257 und 293 gelesen. Die PHPStan-Meldung ist ein Folgefehler: Cashier typisiert `findBillable()` gegen den *Trait* `Billable`, PHPStan hält `if (! $user instanceof User) return;` deshalb für immer wahr und alles danach — inklusive der Lesezugriffe — für unerreichbar. Nichts entfernt. |
+| L7 | `app/Console/Commands/ReindexPressReleaseSearch.php:66` | `upsert()` mit 500 `mediumText`-Zeilen kann `max_allowed_packet` reißen — `--chunk` beim Erstlauf niedriger ansetzen oder im Kommentar vermerken |
+| L8 | `resources/views/livewire/admin/press-releases/index.blade.php:301` | `fn($inner)` statt `fn ($inner)` — Pint erfasst Blade nicht, deshalb unbemerkt |
+| L9 | `app/Console/Commands/ImportNewsletterBounces.php:58` | Adressen werden kleingeschrieben verglichen; unter MySQL (`utf8mb4_*_ci`) egal, unter SQLite im Test nicht — verdeckt mögliche Lücken |
+
+Positiv und ausdrücklich erwähnt: keine Roh-SQL-Stelle nimmt Nutzereingaben
+entgegen (alle `selectRaw`/`whereRaw` sind parametrisiert oder erhalten
+Literale), alle `{!! !!}`-Ausgaben in `resources/views/web/` speisen sich aus
+Sprachdateien oder laufen über `PressReleaseHtmlSanitizer::render()`, und die
+neuen Admin-Aktionen prüfen durchgängig `authorize()`.
+
+---
+
+## 6 Voraussetzungen, die die Roadmap braucht und die noch fehlen
+
+Reine Feststellungen aus dem Code, keine neuen Arbeitspakete.
+
+1. **`companies.email` hat keinen B-Tree-Index.** Vorhanden sind nur
+   `(portal, slug)`, `(portal, is_active)`, `(created_at, id)` und ein
+   FULLTEXT über `(name, email, slug)`. Block 1a schlüsselt die
+   Newsroom-Konsolidierung ausdrücklich über die Firmen-E-Mail, und 1a.4 will
+   diesen Lookup bei **jeder** eingehenden API-Meldung ausführen. Ohne Index ist
+   das ein Full Scan über 70 MB pro Einreichung. Der Index selbst ist billig:
+   `ADD INDEX` läuft auch mit vorhandenem FULLTEXT-Index `INPLACE` — nur
+   `ADD COLUMN` erzwingt den COPY-Rebuild.
+2. **Aufbewahrung von `press_release_events` ist offen** (M4). Sie bestimmt, wie
+   weit die Verlaufsansicht aus 1c.1 zurückreicht, und muss vor 0.3
+   („Bestandsaufnahme Aufrufzahlen: Median und Verteilung der letzten drei
+   Monate") entschieden sein.
+3. **Bounce-Suppression ist unvollständig** (M9) — harter Blocker für 1b.6, 1d.3
+   und 3.2.
+4. **Der `gone_at`-Pfad ist nicht sauber umkehrbar** (H3, H4). Roadmap 1b.5
+   („fällt ein Newsroom auf null Meldungen, verschwindet die öffentliche Seite
+   mit") baut direkt darauf auf.
+5. **`ReleaseDetailPageData` ist ungecacht, `NewsroomDetailPageData` gecacht**,
+   und der Newsroom zahlt seit dem 410-Umbau einen zusätzlichen Slug-Lookup
+   **vor** dem Cache (`NewsroomDetailPageData.php:34-40`). Das ist bewusst so
+   entschieden und im Code begründet; sobald 1b/1c den Newsroom zum Produkt
+   machen und die Aufrufzahlen steigen, gehört die Entscheidung noch einmal auf
+   den Tisch — eine gecachte Menge entfernter Slugs mit kurzer TTL erreicht
+   dasselbe ohne Query pro Aufruf.
+
+---
+
+## 7 Empfohlene Reihenfolge
+
+**Vor dem nächsten Deploy** (betrifft laufenden Betrieb):
+
+1. H1 — `Cache::forget()` in die beiden Such-Migrationen. Sonst kostet der
+   FULLTEXT-Umzug eine Minute 500er auf jeder Suche.
+2. H2 — Flush aus der Schleife holen, `chunkById()` statt `get()`.
+3. H3 + H4 — Umkehrbarkeit von `gone_at` geradeziehen, jeweils mit Test.
+4. M5 — `Cache::forget()` in die Watermark-Migration.
+
+**Direkt danach** (Werkzeug, größter Hebel auf alles Weitere):
+
+5. P1 — `parseModelCastsMethod: true`, Scope-Annotationen, Baseline neu,
+   `composer analyse` ins CI.
+
+**Vor dem ersten Roadmap-Arbeitspaket:**
+
+6. M9 — Bounce-Suppression vervollständigen (Blocker für 1b.6/1d.3/3.2).
+7. M4 — Aufbewahrung `press_release_events` entscheiden (blockiert 0.3/1c.1).
+8. Index auf `companies.email` (Voraussetzung für 1a).
+
+**Laufend, ohne Eile:**
+
+9. M1, M2, M3, M6, M7, M8 sowie L1–L9.

dev/2026-09-01/roadmap-2026.md

@@ -0,0 +1,205 @@
+# Roadmap Nutzergewinnung und Rückgewinnung
+
+**Stand:** 01.09.2026
+**Gültig für:** presseecho.de, businessportal24.com, Hub pressekonto.com
+**Zweck:** Reihenfolge, Abhängigkeiten und Abbruchbedingungen für den Ausbau nach dem Relaunch
+
+---
+
+## Ausgangsbefund
+
+Das Portal hat Traffic, aber der Traffic besteht überwiegend aus Lesern fremder Meldungen. Zwischen "Meldung wird gelesen" und "jemand bucht" existiert keine Strecke. Alles, was den Trichter oben verbreitert, wirkt erst, wenn er unten geschlossen ist.
+
+Der größte ungenutzte Bestand liegt bereits im System: Firmen, deren Meldungen über connektar und openPR eingehen und die kein Konto haben. Sie sind erfasst, ihre Kontaktadresse liegt vor, sie werden bereits transaktional benachrichtigt, und die Magic-Link-Verifikation dieser Adresse ist gebaut.
+
+**Grundsatz für die Reihenfolge:** erst messen, dann den Trichter unten schließen, dann oben verbreitern, dann Partner.
+
+---
+
+## Aufwandsskala
+
+| Kürzel | Bedeutung |
+|---|---|
+| S | ein Abend bis ein Tag |
+| M | mehrere Tage, in Etappen lieferbar |
+| L | mehrere Wochen oder abhängig von Dritten |
+
+---
+
+## Block 0 — Messbarkeit
+
+Ohne definierte Konversionspunkte ist keiner der folgenden Blöcke bewertbar.
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 0.1 | Konversionspunkte festlegen: Claim eines Newsrooms, Registrierung, erste Buchung, Wiedereinreichung nach Ablehnung | S | keine |
+| 0.2 | Umami-Ziele einrichten, getrennt nach Herkunft (Veröffentlichungsmail, Ablehnungsmail, organisch) | S | 0.1 |
+| 0.3 | Bestandsaufnahme Aufrufzahlen: Median und Verteilung der letzten drei Monate je Portal | S | keine |
+| 0.4 | Ablehnungsquote je Quelle (connektar, openPR, direkt) als wiederkehrende Auswertung | S | keine |
+
+**Warum 0.3 vor Block 1 steht:** Die Sichtbarkeitsansicht macht öffentlich, was bisher nicht belegt werden musste. Fällt die Verteilung schwach aus, werden Rohzahlen zum Nachteil und es braucht eine Einordnung gegen den Portaldurchschnitt. Diese Entscheidung muss vor dem Bau fallen.
+
+**Abbruchbedingung:** keine. Block 0 ist Voraussetzung, nicht Wette.
+
+---
+
+## Block 1 — Konversion aus Bestand
+
+Der Kern. Wandelt vorhandenen Zulauf in Konten und Kunden, ohne neuen Traffic zu benötigen.
+
+### 1a Newsroom-Konsolidierung
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 1a.1 | Trockenlauf-Bericht: wie viele Firmen fallen bei Zusammenführung über die Firmen-E-Mail zusammen, welche Adressen tragen mehrere Firmennamen | S | keine |
+| 1a.2 | Sammeladressen-Erkennung: Adresse mit mehr als [Schwellwert] abweichenden Firmennamen wird markiert und von der automatischen Zusammenführung ausgenommen | S | 1a.1 |
+| 1a.3 | Zusammenführung im Bestand mit gespeicherter Ursprungszuordnung, rückabwickelbar | M | 1a.2 |
+| 1a.4 | Laufende Zuordnung neuer API-Meldungen zu bestehendem Newsroom über die Firmen-E-Mail | M | 1a.2 |
+
+**Regelwerk Zusammenführung**
+
+| Signal | Folge |
+|---|---|
+| Gleiche E-Mail, gleicher oder ähnlicher Firmenname | automatisch zusammenführen |
+| Gleiche E-Mail, deutlich abweichende Firmennamen | nicht zusammenführen, als Sammeladresse markieren |
+| Abweichende E-Mail, gleicher Firmenname und Ort | Vorschlag im Admin, keine automatische Aktion |
+
+Schlüssel ist die **Firmen-E-Mail**, nicht die Pressekontaktadresse. Der Pressekontakt ist der Firma untergeordnet und wechselt; die Firmenidentität darf nicht an einer Person hängen. Der Magic Link kann trotzdem an beide gehen, das ist eine Berechtigungs- und keine Identitätsfrage.
+
+Für selbst angelegte Firmendaten trägt der Nutzer die Verantwortung. Für die rückwirkende Zusammenführung im Altbestand trägt sie das Portal, weil dort nicht angelegt, sondern verschmolzen wird. Deshalb 1a.1 vor 1a.3.
+
+### 1b Newsroom als Produkt
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 1b.1 | Sichtbarkeitsregel: Newsroom öffentlich erst ab der ersten veröffentlichten Meldung, sonst nur Datensatz | S | keine |
+| 1b.2 | Verwaltungszugang über Magic Link, unabhängig von der öffentlichen Sichtbarkeit | M | 1a.4 |
+| 1b.3 | Kostenlose Profilpflege: Beschreibung, Logo, Bilder, Pressekontakte | M | 1b.2 |
+| 1b.4 | Hinweis "Diesen Newsroom verwalten" auf der Profilseite und in der Veröffentlichungsmail | S | 1b.2 |
+| 1b.5 | Rückbau: fällt ein Newsroom durch Löschung oder Depublizierung auf null Meldungen, verschwindet die öffentliche Seite mit | S | 1b.1 |
+| 1b.6 | Nicht erreichbare Newsrooms aus der Bounce-Suppression im Admin markieren, nicht beanspruchbar, aus allen Mailstrecken ausgenommen | S | Bounce-Suppression live |
+
+**Leitplanken Profilpflege**
+
+- Externe Links im Profiltext werden systemseitig gesetzt wie in Meldungen, nicht kundenseitig wählbar. Sonst wird das Profil ein Backlink-Automat.
+- Beschreibungstext läuft mindestens durch die Rot-Ebene der bestehenden Prüfung.
+- Bilder im Newsroom unterliegen derselben KI-Deklaration und demselben Audit-Log wie Bilder in Meldungen. Logos sind unkritisch, fotorealistische Motive nicht.
+- Verwaltungszugang öffnet Profildaten. Veröffentlichte Meldungen bleiben in den bestehenden Änderungspfaden. Kein Bearbeitungszugriff auf Meldungen über den Umweg Profilverwaltung.
+
+### 1c Sichtbarkeit belegen
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 1c.1 | Absenderansicht je Meldung: Aufrufe im Verlauf, Indexierungsstatus, Einordnung gegen Portaldurchschnitt | M | 0.3 |
+| 1c.2 | Zugang zur Ansicht über Magic Link, auch ohne Konto | S | 1b.2 |
+| 1c.3 | Newsroom-Übersicht mit allen Meldungen der Firma und Summenwerten | M | 1a.3, 1c.1 |
+
+### 1d Infoseite und Prüfwerkzeug
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 1d.1 | Hilfeseite ohne kommerziellen Anteil: was eine gute Pressemitteilung ausmacht, wie geprüft wird, was sich verbessern lässt, Abschnitt zu Pressebildern | S | keine |
+| 1d.2 | Textbaustein in die Ablehnungsmail, Verlinkung auf 1d.1 | S | 1d.1 |
+| 1d.3 | Abmeldemöglichkeit für Benachrichtigungen, Status in der Suppression-Logik geführt | S | Bounce-Suppression live |
+| 1d.4 | Prüfwerkzeug: eingefügter Text wird bewertet, Ausgabe als benannte Stufe mit konkreten Hebeln | M | 1d.1 |
+| 1d.5 | Bewertung einer bestehenden Meldung über Magic Link | S | 1d.4, 1b.2 |
+| 1d.6 | Partnerbereich am Seitenende, vorerst als "BALD" ohne Namen und Logos | S | 1d.1 |
+
+**Offenlegungsgrenze**
+
+| Ebene | Nach außen | Begründung |
+|---|---|---|
+| Rot-Kriterien | nur als Kategorie, ohne Detail | wer weiß, wie er durchrutscht, rutscht durch |
+| Content-Dimensionen (Aufbau, Konkretheit, Anlass, Zitat, Substanz) | offen erklärbar | Optimierung auf diese Dimensionen ist tatsächliche Verbesserung |
+| Gewichtung, Schwellen, Kalibrierung | nie | Rekonstruierbarkeit des Gates |
+
+**Qualitätsstufen statt Punktzahl**
+
+| Stufe | Bedeutung für den Autor |
+|---|---|
+| Nicht veröffentlichbar | verletzt eine Grundbedingung, muss neu geschrieben werden |
+| Veröffentlichbar, schwach | erscheint, wird kaum wirken, Hauptschwäche wird benannt |
+| Solide | erfüllt die Anforderungen, zwei bis drei konkrete Hebel |
+| Stark | trägt von selbst |
+
+Die Stufe sieht der Autor, nicht der Leser der Meldung. Kein öffentliches Qualitätssiegel auf Meldungen, weil es die Meldungen zahlender Kunden entwertet, sobald eine davon nur "solide" ist. Die portalseitige Konsequenz aus der Qualität besteht bereits über Boost-Fähigkeit und Platzierung.
+
+**Kostenmodell Prüfwerkzeug:** [Anzahl] kostenlose Prüfung je Meldung und [Zeitraum], danach über Credits. Der kostenlose Weg muss echt und ausreichend sein. Die Prüfung ist vom Veröffentlichungsvorgang entkoppelt, verbraucht keinen Slot und ändert keinen Status; die Entscheidung gegen einen Re-Check-Loop in Phase 2 bleibt davon unberührt.
+
+**Nebeneffekt:** Prüfläufe erzeugen Divergenzdaten für `scoring:divergence-report` und schärfen die Rubrik.
+
+**Abbruchbedingung Block 1:** Wenn nach [Zeitraum] weniger als [Schwellwert] Newsrooms beansprucht wurden und keine Wiedereinreichung nach Ablehnung messbar ist, trägt die Konversion aus dem Bestand nicht. Dann Block 1 einfrieren und Gewicht auf Block 3 verlagern.
+
+---
+
+## Block 2 — Organische Sichtbarkeit
+
+Verbreitert den Trichter oben. Sinnvoll erst, wenn Block 1 unten geschlossen ist.
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 2.1 | NewsArticle-Schema auf allen Meldungen, Organization-Schema auf Newsrooms | M | 1b.1 |
+| 2.2 | Aufnahme in Google News und Publisher Center prüfen und beantragen | M | 2.1 |
+| 2.3 | Branchen- und Kategorie-Landingpages aus dem Archivbestand | M | keine |
+| 2.4 | Transparenzseiten: Preisvergleich, ohne Abo veröffentlichen, ohne Mindestlaufzeit | S | keine |
+| 2.5 | Konsolidierung der bestehenden Ratgeberseiten unter `/de/presse/` gegen 1d.1 und 2.4 prüfen | S | 1d.1 |
+| 2.6 | Outreach an Betreiber von Presseportal-Listen und Vergleichsartikeln | M | 2.4 |
+| 2.7 | Auffindbarkeit für KI-Systeme: strukturierte Daten, klare Entitätszuordnung, `llms.txt` | M | 2.1 |
+
+**Formulierungsgrenze bei 2.7:** Die technischen Voraussetzungen zu beschreiben ist haltbar. Eine Nennung in KI-Antworten zu versprechen ist es nicht. Vor Veröffentlichung auf einer Preisseite sauber formulieren.
+
+**Abbruchbedingung Block 2:** Wenn nach [Zeitraum] die Transparenzseiten und der Listen-Outreach keine messbaren Registrierungen erzeugen, bleibt Block 2 auf dem technischen Teil (2.1 bis 2.3) beschränkt und der Marketing-Teil wird nicht weiter ausgebaut.
+
+---
+
+## Block 3 — Reichweite und Partner
+
+Braucht Betreuungszeit und ist teilweise von Dritten abhängig.
+
+| Nr. | Arbeitspaket | Aufwand | Abhängigkeit |
+|---|---|---|---|
+| 3.1 | RSS-Feeds je Branche | S | 2.3 |
+| 3.2 | Opt-in E-Mail-Digest je Branche, Double-Opt-in | M | 3.1, Bounce-Suppression live |
+| 3.3 | Agenturmodell: mehrere Firmen unter einem Konto, aus den Sammeladressen aus 1a.2 abgeleitet | L | 1a.2 |
+| 3.4 | Gezielte Ansprache kleiner PR-Agenturen und freier Texter | L | 3.3 |
+| 3.5 | Syndikationsvertrag als Standarddokument fertigstellen | M | Anwaltstermin |
+| 3.6 | IMKIS: Pilot nach Treffen am 01.10., Partnerplatzierung erst nach ausgehandelter Gegenleistung | L | 1d.6 |
+
+**Zur Reihenfolge von 3.3:** Der Trockenlauf 1a.1 sagt, wie viele Sammeladressen im Bestand liegen. Ist die Zahl hoch, rückt das Agenturmodell nach vorn, weil es dann kein Zukunftsfeature ist, sondern ein vorhandenes Datenproblem.
+
+**Abbruchbedingung Block 3:** Wenn der Leser-Layer nach [Zeitraum] unter [Schwellwert] Abonnenten je Branche bleibt, wird er nicht als Verkaufsargument verwendet und nicht weiter ausgebaut.
+
+---
+
+## Feste Abhängigkeiten außerhalb der Blöcke
+
+| Vorgang | Blockiert | Grund |
+|---|---|---|
+| Bounce-Suppression produktiv | 1b.6, 1d.3, 3.2, jede weitere Mailwelle | Zustellbarkeit; ein beschädigter Absenderruf trifft zuerst die Magic Links |
+| connektar `ai_declaration` verpflichtend, ~Oktober 2026 | nichts direkt | Termin steht, gehört in die Planung |
+| Anwaltstermin, Fünf-Punkte-Agenda | 3.5 | Syndikationsvertrag und Art. 50 Abs. 4 |
+
+---
+
+## Offene Entscheidungen
+
+| Nr. | Frage | Betrifft |
+|---|---|---|
+| E1 | Schwellwert, ab wie vielen abweichenden Firmennamen eine Adresse als Sammeladresse gilt | 1a.2 |
+| E2 | Zeigt die Absenderansicht Rohzahlen oder Einordnung gegen den Portaldurchschnitt | 1c.1 |
+| E3 | Anzahl kostenloser Prüfläufe und Preis der weiteren in Credits | 1d.4 |
+| E4 | Trägt die Veröffentlichungsmail den Magic-Link-Hinweis oder den Link auf die Infoseite; ein Element pro Mail | 1b.4, 1d.2 |
+| E5 | Werden die bestehenden Ratgeberseiten konsolidiert oder ergänzt | 2.5 |
+| E6 | Bleibt die Ablehnungsstrecke dauerhaft frei von kommerziellen Angeboten | 1d.1, 1d.6 |
+
+---
+
+## Leitplanken, die für alle Blöcke gelten
+
+- Benachrichtigungen bleiben transaktional. Der Charakter der Mail wird rückwirkend von der Zielseite bestimmt: wird die Seite überwiegend Angebot, wird die Mail zur Anbahnung.
+- Kein kostenpflichtiges Angebot im Moment der Ablehnung.
+- Kostenpflichtige Inhaltsänderung nicht für syndizierte Meldungen, solange connektar write-once bleibt und kein kostenfreier Alternativweg existiert.
+- Kein Verweis auf connektar als kostenfreier Änderungsweg.
+- Bewertungslogik: Kategorien erklären, Gewichtungen und Schwellen nie.
+- Noch nicht verfügbare Angebote werden als "BALD" gekennzeichnet, nicht weggelassen.
+- Jede Maßnahme wird gegen die sieben Anti-Zombie-Zusagen geprüft, bevor sie live geht.

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

@@ -0,0 +1,425 @@
+# 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. |