29 KiB
29 KiB
Roadmap
Stand: 13.10.2026 · Release v1.9.1 · Live seit 20.07.2026 (pressekonto.com, presseecho.de, businessportal24.com)
Diese Datei ist die einzige laufende Liste offener Punkte. Sie fasst alle
Pläne, Audits und Protokolle unter dev/ zusammen (Abgleich gegen Code und
Git am 09.10.2026). Die Einzeldokumente bleiben als Begründung und Historie
erhalten und sind je Punkt verlinkt. Neue offene Punkte kommen hierher, nicht
in die Einzeldokumente; erledigte Punkte werden durchgestrichen und mit Datum
oder Release versehen.
| Aufwand | Bedeutung |
|---|---|
| S | eine Stunde bis ein halber Tag |
| M | ein bis drei Tage |
| L | länger oder abhängig von Dritten |
[EXTERN] = liegt beim Betreiber, Anwalt, Steuerberater oder Partner, nicht im Code. [LIVE] = einmaliger Nachweis bzw. Handgriff auf dem Server.
0. Lage
- Seit Go-Live erledigt: Roadmap Nutzergewinnung Block 0–2 und RSS (3.1), Audit 11.09. mit Blöcken 1–10 (live als v1.1.0), Bildrechte Deploy 1, 1b, 2, 2b (28.09.), Git-Deploy (v1.1.3), Volt entfernt (v1.2.0), Rechnungsversand, Betriebsüberwachung Phase 1 und externer Monitor, Sicherheitsaudit 07.10. S-01 bis S-06 (v1.4.0–v1.6.0), Spamschutz (v1.7.0), Löschfristen und Wortwahl (v1.8), Boost-Kennzeichnung (v1.9), Anwaltspaket versandfertig (13.10.).
- Was offen ist: die Antwort des Anwalts (danach Deploy 3), einige Nachweise auf Live, der Dev-Container (1.3) und der Wachstumsteil: Changelog (6.6), Spitze (6.14), Agenturmodell (6.3), Monitoring Phase 2/3.
- Wachstum messen: Abbruchbedingungen für Block 1–3 stehen seit 13.10.2026 (6.1); vorher müssen die Messfehler im Trichter raus (6.16).
Releases seit Go-Live
| Release | Datum | Inhalt |
|---|---|---|
| v1.0.0 | 21.07. | Go-Live |
| v1.1.0 | 05.10. | Audit-Blöcke 1–10, Betriebsüberwachung Phase 1 (letzter SFTP-Deploy) |
| v1.1.1–v1.1.3 | 06.10. | GlitchTip-Fixes, Git-Deploy live |
| v1.2.0 | 06.10. | Volt entfernt, Livewire-4-Single-File-Components |
| v1.3.0–v1.3.2 | 06.10. | Rechnungsversand, fehlgeschlagene Anmeldungen, Worker-Prüfung im Deploy |
| v1.4.0/v1.4.1 | 07.10. | Sicherheitsaudit S-01–S-06, Passkeys, Zweitfaktor-Pflicht für Admins |
| v1.5.0 | 08.10. | Proxy-Vertrauen, HSTS, API-Zugang endet mit der Buchung |
| v1.6.0/v1.6.1 | 08.10. | Andere Geräte abmelden, IP-Login-Limit, Passwortregeln, CSP im Melde-Modus, Imagick |
| v1.7.0 | 09.10. | Spamschutz mit Cloudflare Turnstile |
| v1.8.0/v1.8.1 | 12.10. | Sicherheitsseite „Geräte und Anmeldungen“, Breadcrumbs ohne Daten, Löschfristen Aktivitätsverlauf/API-Protokoll, Newsletter-API 410, Wortwahl „automatisierte Prüfung“ |
| v1.9.0/v1.9.1 | 13.10. | Boost als „Gebuchte Platzierung“ mit Erklärung, „Aktuell“ statt „Top-Auswahl“, Admin-Aktion „Boost beenden“, audit:admins |
| v1.10.0 | 13.10. | Trichter misst Verwaltungsseite, Anforderung und Firma bei der Einlösung; Admin ▸ Reports ▸ Wachstum; Umami-Anbindung (umami:report, growth:report) |
| v1.11.0 | (Deploy offen) | Newsroom-Seite mit Kasten „Diesen Newsroom verwalten“; Firmenseiten „Firma & Newsroom“ mit Link zum öffentlichen Newsroom |
1. Sofort — Altlasten mit Personenbezug und Zugangsdaten
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
commit-map-2026-10-09.txt), Force-Push auf origin und NAS, Server abgeglichen, Speicherbereinigung in Forgejo und auf dem NAS, keine weiteren Klone. Vorgehen für künftige Fälle: git-deploy.md, Abschnitt G. |
Release-Plan R6.2 | — | |
.mcp.json, Git-Historie) und das lokale MySQL-Root-Passwort (Git-Historie). |
optimize 14.07. K2, Sicherheitsplan | — | |
| 1.3 | Dev-Container neu erstellen. docker-compose.yml ist bereinigt, im laufenden Container sind DB_CONNECTION … DB_PASSWORD aber weiter als Umgebungsvariablen gesetzt — genau die Ursache des Datenverlusts vom 07.10. Danach lokalen APP_KEY reparieren (33 statt 44 Zeichen, ungültig) und Cloudflare-Testkeys in die lokale .env. Context7-Schlüssel und lokales MySQL-Root-Passwort rotieren (beide in der Git-Historie). |
Sicherheitsplan, Spamschutz | S |
dev/migration/ (7,4 GB), dev/archive/migration-2026/sql/ (905 MB), dev/api/, dev/newsletter/, dev/2026-10/, storage/app/private/restore-company-user-auto-2026-10-07.sql. |
dev/README | — | |
| 1.5 | Alte Backups auf dem Server löschen: ~/deploy-v1.1.0.tgz, ~/backup-vor-v1.1.0.tgz, ~/backup-vor-git.tgz, ~/vor-git/. |
git-deploy.md | S [LIVE] |
2. Termine und Wiedervorlagen
| Fällig | Punkt | Quelle |
|---|---|---|
| ab 15.10.2026 | CSP-Meldungen aus storage/logs/csp-*.log auswerten, dann scharf schalten (Report-Only seit v1.6.0). Nonce statt unsafe-inline/unsafe-eval später (L). |
Sicherheitsplan |
| ab 16.10.2026 | Spamschutz auswerten: Spam-Filter der Kontakt-Queue, storage/logs/spam-*.log, Missbrauch des Fail-open-Wegs → ggf. TURNSTILE_FAIL_OPEN=false. Die rund 130 nicht erkannten Altanliegen per Sammelaktion in die Quarantäne. |
Spamschutz |
| nächstes Release | SessionRevocation::legacyCachedMark() samt Test entfernen; Liste „Aktive Sessions“ reparieren (liest sessions-Tabelle, Live speichert in Redis → immer leer). |
Sicherheitsplan |
| Oktober 2026 | connektar: ai_declaration wird Pflicht — Stand bei connektar erfragen, Auswirkung auf den Alt-Vertrag prüfen (heute setzt der Legacy-Controller die Bestätigung selbst). |
Roadmap Nutzergewinnung |
| Ende Oktober | Google News / Publisher Center (2.2): Ergebnis in der Search Console prüfen (4–6 Wochen nach Einrichtung). Zwischenstand 13.10. (Umami): Businessportal24 bekam seit 17.09. 431 Besuche von news.google.com, Presseecho keine. |
Protokoll Teil 7 |
| frühestens 26.10.2026 | Bildrechte Block I (C2PA) möglich — Bedingung: vier Wochen Deploy 1b ohne Auffälligkeiten und Testkorpus echter KI-Dateien. | Bildrechte-Plan |
| Decision-Update Spitze ohne Partner | ||
| laufend | 1c.5/E8: Kundenansicht des Google-Index (GSC_CUSTOMER_VISIBLE) — tägliche Prüfung seit 17.09.; entscheiden, sobald die Verteilung direkt/API belastbar ist. |
Anhang 1 |
| Frühjahr 2027 | Basiswert 0.1 neu erheben (Kohorte 28–55 Tage, Vergleich 122 / 314). | Basiswerte |
3. Rechtstexte und Freigaben — ein Anwaltspaket [EXTERN]
Mehrere Datenverarbeitungen laufen bereits, ohne dass die Datenschutzerklärung sie nennt. Das ist der größte offene Block und am besten ein Paket an den Anwalt. Überarbeiteter Entwurf: Anwaltspaket vom 12.10.2026. Vor Versand die Korrekturen, Antworten und den Umsetzungsauftrag einarbeiten: Ist-/Zielstand, Aufbewahrungsmatrix, Vertragsübergang, Beweisarchiv und Aufgaben RP-01 bis RP-12. Diese Ergänzung ist die führende technische Arbeitsgrundlage für die dort berichtigten Punkte, keine rechtliche Freigabe.
Arbeitsordner (Stand 13.10.2026): dev/rechtliches/ enthält nur noch die
Versandfassung, ihre Anlagen (Interessenabwägung, Live-Rechtstexte, Klärung,
Kontext Löschanfragen) und die Korrekturen mit RP-01 bis RP-12 und BN-01 bis
BN-09. Belege sammelt rechtliches/nachweise/
mit Checkliste; Vorfassungen, Codeauswertung, To-do-Liste und Rückfragen liegen
in archive/rechtliches-2026-10/. Hub-Analyse
mit Nutzerkennung, KI-Bildprüfung und Newsletter bleiben bis zu ihren eigenen
Aktivierungspaketen ausgeschaltet.
Versandfertig seit 13.10.2026: Anschreiben mit Lesereihenfolge und
Dateiliste (rechtliches/anschreiben-anwalt-2026-10-13.md),
Nachweise vor dem Versand vollständig (BN-01, BN-02, BN-06, BN-07, BN-08,
Screenshots). Live: v1.9.1 mit „Gebuchte Platzierung“. Offen bis Deploy 3:
BN-03 Backups, BN-05 Instanzfristen, danach BN-04/BN-09 mit RP-04.
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
| 3.1 | DSE-Lücken, Verarbeitung läuft bereits: Bild-Originale, Bestätigungsprotokoll und IP-HMAC (seit Deploy 1b, 28.09.; laut Decision-Update sollte der Minimalabsatz mitgehen), GlitchTip (Server und Browser), fehlgeschlagene Anmeldungen (90 Tage), Rückläufer-Protokoll email_bounces (395 Tage, E27), activity_events/api_usage_logs. |
Decision-Update Bildrechte, Monitoring-Plan, Entwicklungsplan Audit, Block 9 E | S + Freigabe |
| 3.2 | DSE 6a (Turnstile) ist als Vorschlag live — juristisch freigeben. | Spamschutz | S |
| 3.3 | Deploy 3 Bildrechte: AGB v0.7 (§ 8a, § 9), DSE v0.4 (9a, 9b, 13, Template-Variablen), img-confirm-v3, LEGAL_ACCEPTANCE_GATE=true. Vorher: Interessenabwägung (DU 4.4) als Dokument ablegen, Restore-Übung (5.1) als Beleg für 9b. |
Bildrechte-Plan | S (2 Tage nach Antwort) |
| 3.4 | Anwaltsagenda A1–A7 (Screenshots Formular und Nachweiszeile), Art. 50 KI-VO, Syndikationsvertrag als Standarddokument (3.5), Boost-Slot-Note. | Decision-Update Bildrechte, Changelog O8 | [EXTERN] |
| 3.5 | AVV mit OpenAI → danach KI-Vorab-Check für Bilder einschalten (IMAGE_PRECHECK, Stufe 1, nach einer Woche Stufe 2), Schwellen nachjustieren. |
Bildrechte-Plan K.6 | S |
| 3.6 | Nach DSE-Freigabe: UMAMI_PORTAL_ENABLED, UMAMI_IDENTIFY_USERS einschalten. |
Monitoring-Plan | S |
AutomatedCheckWordingTest. Die AGB-Stellen folgen mit v0.7 (3.3). |
Bildrechte-Plan | — | |
| 3.8 | Geschäftliche Entscheidungen festschreiben: Refund-Policy (heute faktisch Stripe-Dashboard), Steuerberater-Abnahme Rechnungs-PDF/USt, Pro-Tarif nach Streichung des Prüfversprechens, Preisfreigabe R1.4 formal abhaken. | Release-Plan | S [EXTERN] |
4. Nächstes Release (v1.8) — kleine technische Punkte
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
legacyCachedMark() entfernt (Test umgedreht: alte Cache-Marke wirkt nicht mehr); Sicherheitsseite zeigt statt der leeren Redis-Liste „Dieses Gerät“ und die letzten fünf Anmeldungen mit Anmeldeweg aus dem Aktivitätsverlauf (ohne IP), Kachel „Anmeldungen in 30 Tagen“. |
Sicherheitsplan | — | |
activity_events 395 Tage, api_usage_logs 90 Tage (config/monitoring.php → retention, MONITORING_ACTIVITY_RETENTION_DAYS/MONITORING_API_USAGE_RETENTION_DAYS), täglich 04:05 per model:prune. Beim ersten Lauf auf Live fällt bei api_usage_logs alles vor Mitte Juli weg. |
Monitoring-Plan Phase 3 | — | |
POST api/v1/newsletter/subscribe antwortet mit 410 (seit Go-Live kein Aufruf, kein Abo); die Spezifikation versprach ein Double-Opt-in, das es nicht gab. Ability nicht mehr für neue Tokens wählbar. Anmeldung mit Double-Opt-in kommt mit 6.4. |
QA-Checkliste | — | |
| 4.4 | Turnstile in die übrigen öffentlichen Formulare: Widerruf, Kündigung, Meldeformular, PM-Meldung, Rechtsanfrage, „Newsroom verwalten“ (B5). | Spamschutz | M |
| 4.5 | Login-Härtung entscheiden: POST /login nur auf dem Hub oder Turnstile im Login (IP-Limit seit v1.6.0). |
Monitoring-Plan | S–M |
| 4.6 | Referer-Redirect ohne Whitelist im Portal- und Firmen-Switcher (N2); url:http,https für Backlink- und Pressefach-URLs (N3); CORS explizit (N9). |
optimize 14.07. | S |
| 4.7 | Bildrechte aufräumen: Flag IMAGE_RIGHTS_V2, alte press-release-images-manager-Komponente und Alt-Tests entfernen. |
Bildrechte-Plan B.3 | S |
| 4.8 | Strukturierte Daten ImageObject mit creditText/copyrightNotice für Pressebilder (nie eingeplant oder verworfen). |
Bildkennzeichnung 6.3 | S–M |
ErrorReportScrubber entfernt die Daten aller Breadcrumbs und bereinigt die Nachrichten. Bestandsprüfung in GlitchTip (lesend, 09.10.): 96 von 176 Ereignissen mit Livewire-Daten, nur in den Scanner-Einträgen 38/39 und nur language, paginators, portal, timeframe — keine Formular- oder Passwortdaten. |
Faktenblatt DSE | — | |
| 4.10 | IP-Adressen im Klartext ohne Löschfrist: users.last_login_ip, contact_messages.requester_ip (auch Nicht-Spam), legal_requests.requester_ip, withdrawal_requests.requester_ip, termination_requests.requester_ip, booking_confirmations.ip, newsletter_subscriptions.ip_address. Frist je Tabelle festlegen (z. B. IP nach 90 Tagen leeren, Vorgang bleibt) oder als HMAC speichern wie bei Bildbestätigungen; Kontaktanfragen außerhalb der Quarantäne ebenfalls ohne Frist. Außerdem email_suppressions bewusst ohne Frist und IMAP-Ordner Processed/Ignored/Unparsed des Bounce-Postfachs ohne Bereinigung. |
Faktenblatt DSE | M |
5. Betriebsnachweise auf Live [LIVE]
Einmalig abnehmen und hier abhaken. Vieles davon ist vermutlich erledigt, aber nirgends belegt.
| # | Punkt | Quelle |
|---|---|---|
| 5.1 | Restore-Übung in isolierter Umgebung (DB alt/Disk neu, Disk alt/DB neu, beide alt), danach Entscheidung über ein externes Ziel für den Tombstone-Export (E16, Storage Box/S3). Voraussetzung für DSE 9b. | Runbook §9, Audit 02.10. §5 |
| 5.2 | Upload 13–15 MiB über das Formular, PHP- und nginx-Grenzen ≥ 16 MiB, Laufzeit der Bildprüfung mit großem Bild. | Bildrechte-Plan E.7 |
| 5.3 | Passkey im echten Browser, Smoke-Test der Admin-Bestätigung; PASSKEYS_USER_HANDLE_SECRET in der Live-.env (fehlt auch in .env.example). |
Sicherheitsplan |
| 5.4 | Tastatur/Screenreader: Fokusführung Login-Modal (7.6), Bild-Overlay (D.2). | Entwicklungsplan Audit, Bildrechte-Plan |
| 5.5 | Uptime Kuma: Alarmtest mit falschem Token; zweite Ebene (z. B. UptimeRobot auf /up). |
Monitoring-Plan |
| 5.6 | Bounce-Postfach, MAIL_RETURN_PATH, BOUNCE_IMAP_* bestätigen; optional DMARC-Report-Postfach. |
Bounce-Konzept |
| 5.7 | Prod-DB-Benutzer mit minimalen Rechten (N10), offene Punkte aus dem Sicherheitsaudit (Firewall, DB/Redis-Erreichbarkeit, Betriebssystem, Backups). | Sicherheitsaudit |
| 5.8 | Go-Live-Nachlauf vom 20.07., Stand unbekannt: Go-Live-Mails, API-Kunden-Mailing (/docs/api/v1, Token-Migration), Stripe-Test-Artefakte bereinigen, MONITORING_ALERT_EMAIL, Permission api:immediate-publication für connektar. |
Go-Live-Roadmap, API-Parität |
| 5.9 | MAN-Rechnungen: blockierte Vereinbarungen ohne Rechnungsadresse sichten, ersetzende MAN-Rechnung aus dem Protokoll vom 21.09. auf „offen“ prüfen, Rechnungsadressen von Bestandskunden nachpflegen. | Legacy-Rechnungen |
| 5.10 | Die 6 Slug-Kollisionen aus der Newsroom-Zusammenführung einzeln ansehen. | Protokoll Teil 3 |
| 5.11 | GlitchTip: behandelte Einträge auflösen (nur Betreiber), Eintrag 10 „[object Object]“ beobachten. | GlitchTip |
| 5.12 | Slow-Request-Auswertung mit Live-Daten (Command und Report-Seite existieren). | Migration 11 |
| Anwaltspaket |
6. Produkt und Wachstum
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
| Roadmap Nutzergewinnung, Basiswerte | — | ||
| 6.2 | 2.6 Zuschriften an Portalübersichten (PR-Gateway-Korrektur, höchstens acht Kontakte). | Anhang 1 §5 | [EXTERN], in Arbeit |
| 6.3 | 3.3 Agenturmodell: mehrere Firmen unter einem Konto, abgeleitet aus den 1.102 Sammeladressen. Danach 3.4 gezielte Ansprache kleiner Agenturen. | Roadmap Nutzergewinnung | L |
| 6.4 | 3.2 Branchen-Digest mit Double-Opt-in (löst auch 4.3). | Roadmap Nutzergewinnung | M |
| 6.5 | Newsletter-Kampagnenmodul: U05–U07 umsetzen, bevor NEWSLETTER_SENDING_ENABLED eingeschaltet wird. |
Entwicklungsplan Audit E9/E23 | M |
| 6.6 | Changelog-Pipeline — als Nächstes. Entscheidungen O1–O13 und E19–E21 getroffen (09.10.). Zuerst Stufen 1–3: Seite /changelog mit RSS, Entwurf aus deploy.sh nach up (nicht als Ploi-Hook), Freigabe im Admin, „Neu“-Hinweis im Admin (E11), Backfill seit Go-Live (O7). Stufen 4/5 (Artikel) brauchen das Bild-Template (O6, Betreiber); Social-Kanäle (O9, O10) erst nach dem ersten Artikel. Achtung E20: Die Trailer Changelog:/Public: fehlen in allen 31 Commits seit v1.7.0 — v1.8.0 bis v1.9.1 kommen beim Backfill aus dem Protokoll in git-deploy.md; ab jetzt jeder nutzersichtbare Commit mit Trailer. |
Decision-Update Changelog | L |
| 6.7 | Betriebsüberwachung Phase 2 (Validierungsfehler, Schritt-Tracking, Umami-Events, „Problem melden“, Geschäftstrichter) und Phase 3 (Kennzahlen, Alarme bei ausbleibender Aktivität, Seite „Betrieb & Nutzung“, Morgenmail). Entscheidungen M4–M9 bestätigen. | Monitoring-Plan | L |
| 6.8 | Bildrechte: Block I C2PA (ab 26.10.), I.5 XMP in Varianten, Block J Bilder im Newsroom (Kontingent-Entscheidung), I.6 Re-Sync-Sperre erst wenn ein API-Partner Bilder liefert. | Bildrechte-Plan | L |
| 6.9 | API v1: Rückkanal bei Ablehnung (Status-Feld oder Webhook, S6). | API-Parität | M–L |
| 6.10 | Legacy-Rechnungen Phase 4: --send, Erinnerungs-Task, tägliche Überfällig-Notiz (nach einigen Wochen Handbetrieb). |
Legacy-Rechnungen | S |
| 6.11 | Kontakterreichbarkeit Stufe 3 (Veröffentlichungssperre ohne zustellbare Adresse) — bewusst zurückgestellt, nach Beobachtung entscheiden. | Kontakterreichbarkeit | M–L |
| 6.12 | Spamschutz-Ideen: Limit je /24-Netz, tägliche Sammelmail, Wegwerf-Domains, KI-Klassifizierung. | Spamschutz §5 | je S–M |
| 6.13 | Ausbau aus dem Release-Plan, bewusst vertagt: EN-Übersetzung der Langseiten (FAQ, Hilfe, API, Veröffentlichen), EN-Rechtstexte und öffentliche Versionshistorie, DSA-Queue, Coupons, Regionen-Seiten, Blacklist-Admin, Bulk-Publish/-Reject, In-App-Benachrichtigungen, Hero-Slider, Boost als Zeitraum. | Release-Plan, Boost | je M |
| 6.14 | Spitze ohne Partner („beste Pressemitteilungen“): Auszeichnung ab einer festen, öffentlich bekannten Schwelle auf Basis des Scorings, keine Quote, kein Ermessen, nie käuflich; getrennt von „Aktuell“ und von „Gebuchte Platzierung“. Reihenfolge verbindlich: (1) Spitze + Infoseite mit Kriterienkategorien, (2) Werkzeuge als Weg zur Spitze, (3) Zufluss (connektar) schärfer filtern, erst wenn Direktkunden tragen. Offen: Name, Schwellenwert (konservativ, nach Nullmessung justieren), Wortlaut der maschinellen Kurzbegründung, Schwelle je Portal. Nullmessung vor dem Start. | Decision-Update Spitze ohne Partner, Konzept Rubrik | L |
| 6.15 | Partnervorlage (Gutscheine, Kontingent gegen Naturalleistung, Provision mit Codes, Interessenkonflikt-Kennzeichnung, Pilot 6 Monate mit Nullmessung) für künftige Partner bereithalten — kein Code, bis ein Partner konkret wird. | Decision-Update Spitze ohne Partner §6 | [EXTERN] |
growth:report mit den Bedingungen aus 6.1; Umami nur lesend über UMAMI_API_*, Befehl umami:report. Deploy-Notiz: archive/betrieb/deploy-v1.10.0.md. |
Abgleich 13.10.2026 | — | |
| 6.17 | Klarheit des Verwaltungszugangs. Kunden übersehen, dass sie sich mit der Adresse, an die die Mail ging, selbst anmelden und ihre Meldung ändern können (wiederholt, zuletzt 13.10.2026). Erledigt mit v1.11.0: Newsroom-Seite mit eigenem Kasten statt grauer Zeile (erster Messwert nach v1.10.0: 7 Firmen öffneten die Verwaltungsseite, 1 forderte an); Kunden- und Admin-Firmenseite „Firma & Newsroom“ mit Link zum öffentlichen Newsroom (Entscheidung: Backend sagt weiter „Firma“). Offen: Veröffentlichungs- und Ablehnungsmail auf einen klaren nächsten Schritt prüfen (aus der Mail öffnete bisher niemand die Verwaltungsseite); Wirkung über die Stufen 2 und 3 messen. | Betreiber 13.10.2026 | S |
7. Technische Schuld (bei Gelegenheit)
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
| 7.1 | Sitemap ohne Index/Chunking lädt das Archiv mit ->get() — noch unter 50k, wächst. |
optimize N7 | M |
| 7.2 | orderByDesc('hits') ohne Index (durch Cache abgemildert; Online-DDL auf press_releases). |
optimize N8 | S–M |
| 7.3 | Landingpages web/presseecho und web/businessportal24 zusammenführen (M15), toter Code (test.css, kaputtes @source, leere Domain-Gruppen, N6). |
optimize | S |
| 7.4 | CompanyType und companies.type entfernen (A6, jetzt machbar). |
Agentur-Attribution | M |
| 7.5 | Große Komponenten zerlegen: admin.users.edit (1.242 Zeilen), Kontakte-Tab in companies.show; UserManagementTest (1.312 Zeilen) aufteilen. Larastan erfasst Single-File-Components nicht — große Komponenten ggf. per livewire:convert in Klassen. |
Migration 11, Go-Live-Roadmap | M |
| 7.6 | MySQL-/Worker-Integrationstests als zweite CI-Stufe (6.6), arch()-Tests, PHPStan-Baseline (143 Einträge). |
Entwicklungsplan Audit | L |
| 7.7 | API-Autorisierung über Policies (M14), Checkout-Guard (N11), Form Requests (N12), Kleinkram (session()->flash, CurrentPortalContext, E-Mail-Normalisierung). |
optimize, Migration 12 | M |
| 7.8 | Mobil-Feinschliff: Pagination- und Modal-Close-Buttons ~36 px (< 44 px), Stat-Strips, Hero 21/9. | Frontend-Protokoll | S |
| 7.9 | Redis als Cache/Queue erst bei Last — Achtung E18: die Idempotenz der Ablaufmail setzt die DB-Queue voraus. Cache-Warmer nur bei Bedarf. ReleaseDetailPageData cachen, wenn Newsroom-Traffic steigt. |
Go-Live-Roadmap, Entwicklungsplan Audit E18 | M |
| 7.10 | CLASSIFICATION_GREEN_DELAY (Wartezeit vor KI-Auto-Publish, Default 0) prüfen — deckt die Score-Logik das inzwischen ab? |
Release-Plan | S |
8. Doku-Pflege
| # | Punkt | Aufwand |
|---|---|---|
| 8.1 | betrieb/deploy-runbook.md überarbeiten (Stand 09.07.): SFTP-Checkliste, „npm auf dem Server“ und FULLTEXT auf press_releases (§3a) sind überholt; pressekonto.de statt .com (auch Stripe-Webhook-URL); Scheduler-Tabelle ohne users:prune-bot-registrations, monitoring:heartbeat, queue:prune-failed, model:prune, sanctum:prune-expired; systemd statt Supervisor/Ploi; Chat-Reste und KAS-rsync in §7. Deploy-Ablauf nur noch in git-deploy.md. |
M |
| 8.2 | CLAUDE.md nennt pressekonto.de als Live-Domain — live ist pressekonto.com. |
S |
| 8.3 | Kopfzeilen nachziehen: monitoring-plan.md (SFTP, externer Monitor offen), git-deploy.md, glitch-tip/README.md (Protokoll ohne Einträge 18, 23, 38, 39), Bildrechte-Plan („Deploy offen“, Deploy 1–2b und 1b sind live), Sicherheitsaudit Z. 276. |
S |
| 8.4 | api-legacy-paritaet.md: S5/S7/Abschnitt 5 schließen, Umami-Snippets am Ende entfernen. |
S |
| 8.5 | Changelog-Decision-Update: Antworten aus den rohen #…-Zeilen in eine Spalte „Entscheidung“ übertragen. |
S |
| 8.6 | git-deploy-monitoring/ ist ein projektunabhängiger Baukasten und liegt mit jedem Checkout auch auf dem Server — in ein eigenes Repository auslagern. |
S |
| 8.7 | Im Archiv liegen ~78 MB getrackte Mockups und Prototypen (frontend/claude-design/ 57 MB, frontend/tailwind_v3/ 15 MB, _old/ 4 MB) — löschen, wenn sie nicht mehr gebraucht werden (verkleinert das Repo erst zusammen mit 1.1). |
S |