Block 3 — Sichtbarkeit, Löschung, Cache, Eingaben
F04: withoutGlobalScopes() ohne Argument entfernte neben dem PortalScope
auch den Soft-Delete-Filter. Öffentliche, Kunden-, API-, Vorschau- und
Medienpfade sowie die PressRelease-Helfer schreiben jetzt
withoutGlobalScope(PortalScope::class). Zwei Stellen, die der Audit nicht
kannte: die öffentliche Meldungsseite zeigte gelöschte Firmenkontakte mit
Name, Mail und Telefon; das Pressefach listete gelöschte Kontakte weiter
und ließ sie bearbeiten. Ein Architekturtest friert die 39 bewusst
verbliebenen Stellen (Admin, Importer, Befehle, Slug-Eindeutigkeit) ein.
Der Vorschau-Test prüfte bisher forceDelete statt delete.
F22: LOWER(email) machte auf companies (110k Zeilen) bei jedem Login einen
Vollscan; die Kollation ist ohnehin case-insensitiv. EmailQuery vergleicht
auf MySQL direkt über den Index, auf SQLite (Tests) weiter per LOWER.
Neuer Index contacts_email_idx.
F13: Firmen-Observer verwirft die öffentlichen Seiten-Caches bei
Löschung, Wiederherstellung und is_active-Wechsel auf jedem Weg; die
Newsroom-Seite prüft Sichtbarkeit vor dem Cache-Treffer; Kontakt-
Änderungen im Pressefach flushen. Der Tombstone-Test wärmte den Cache
vorher nicht und traf den Fehler nie.
F12: Gemeldete URLs werden über Host, Ausgabe und Slug aufgelöst
(ReportedUrlResolver); fremde Hosts zählen nicht, bei Doppelveröffentlichung
gewinnt die Erstquelle.
F11: per_page 1–100, status als Enum, language nur de/en, Kategorie muss
aktiv sein und zum Ziel-Portal passen. Legacy-Aliasse behalten ihren
Vertrag.
F23: Rückgabewert von put() wird geprüft; Logo erst speichern, dann
Datenbank, dann altes Logo löschen. Fehler enden als Feldfehler, nicht
als verlorenes Logo.
Block 4 — KI-Prüfung und Scheduler
F07: Klassifikation und Score tragen die Prüfsumme des Inhalts bei
Einplanung. Weicht sie beim Speichern ab, wird das Ergebnis verworfen
(ki_audits.discarded_at) und ein neuer Lauf eingeplant. Der Scheduler
veröffentlicht keine Meldung, deren jüngste Klassifikation nicht zum
aktuellen Text passt, sondern plant eine Prüfung mit Routing ein.
F18: Kontingent an den Kalendermonat gebunden (users.press_release_quota_period).
Verbrauch aus einem früheren Monat zählt null, auch ohne Reset-Cron; der
Reset ist idempotent und lässt den laufenden Monat in Ruhe.
F20: Der Publikations-Scheduler liefert bei technischen Fehlern einen
Fehler-Exit-Code, damit der Failure-Hook greift.
F17: KI-Jobs mit $timeout = 120, retry_after 150; Runbook ergänzt.
F19: Aggregation der Aufrufe unter einem Cache-Lock für alle Einstiege.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Stand: 20.07.2026 — das System ist live (pressekonto.com, presseecho.de,
businessportal24.com). Die Struktur trennt aktive Betriebs-/Planungsdoku von
abgeschlossenen Phasen (Archiv).
Aktiv
Pfad
Inhalt
betrieb/deploy-runbook.md
Deploy- und Betriebs-Runbook (SFTP-Deploy-Checkliste, Worker, Scheduler, Stripe-Webhook, Rollback) — erste Anlaufstelle für alles Operative
betrieb/api-legacy-paritaet.md
Verhaltens-Referenz der Legacy-API-Kompatibilitätsschicht (/service/…) — lebendes Dokument, solange Alt-Integrationen (Connektar) die Pfade nutzen
betrieb/umami.md
Umami-Analytics-Snippets je Domain
roadmap.md
Offene Punkte und nächste Entwicklungen/Optimierungen
Lokal / gitignored (bleiben liegen, nicht committen)
Pfad
Inhalt
migration/
Medien-Staging der Legacy-Migration (~7 GB Uploads beider Altportale) — Quelle für legacy:migrate-media; behalten, bis das Alt-System endgültig abgeschaltet und ein Server-Backup gezogen ist
api/
Postman-Collection (enthält API-Keys!) und Activity-Log-Auswertungen der Alt-APIs
archive/migration-2026/sql/
Legacy-DB-Dumps (Snapshots vom 23.04.2026)
Archiv (archive/)
Abgeschlossene Phasen, als Historie/Referenz erhalten:
optimize/ — System-Optimierungsphasen 0–6 und das Cutover-Runbook der
Legacy-Migration (erledigt 20.07.2026; enthält weiterhin die Anleitung für
--since-Delta-Läufe, falls das Alt-System noch einmal Daten liefert)
Kevin Adametz
72432fdb82