Kevin Adametz
8e3554bf91
- dev/roadmap.md neu: alle offenen Punkte aus Plänen, Audits und Protokollen, gegen Code und Git abgeglichen (Stand v1.7.0) - Abgeschlossenes ins Archiv: 2026-09-01 → archive/2026-09-nutzergewinnung, 2026-09-11-audit → archive/2026-09-audit, lagacy-rechnungen → archive/legacy-rechnungen, Deploy-Protokoll v1.1.0, Umami-Snippets, Go-Live-Roadmap vom 20.07. - Aktiv bleiben eigene Ordner bildrechte/ (Plan Fassung 2, Decision-Update) und changelog/ (Decision-Update Changelog) - dev/README.md als Ordnerkarte neu, Verweise und zwei Code-Kommentare auf die neuen Pfade Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
21 KiB
21 KiB
Roadmap
Stand: 09.10.2026 · Release v1.7.0 · 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).
- Was offen ist: vor allem Rechtstexte und Freigaben (ein Anwaltspaket), einige Nachweise auf Live, zwei Altlasten mit Personenbezug (SQL-Dumps in der Git-Historie, nicht rotierte Schlüssel) und der Wachstumsteil (Block 3, Changelog, Monitoring Phase 2/3).
- Was fehlt, um Wachstum zu bewerten: Die Abbruchbedingungen der Roadmap-Blöcke 1–3 tragen weiterhin Platzhalter für Zeitraum und Schwellwert (Punkt 6.1).
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 |
1. Sofort — Altlasten mit Personenbezug und Zugangsdaten
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
| 1.1 | Produktiv-SQL-Dumps in der Git-Historie. dev/migration 2026/sql/*.sql (Snapshot 23.04., ~290 MB, Kundendaten) wurde am 12.05. committet (5b8bdf4) und am 06.07. nur enttrackt (b53af92). Die Blobs sind von main erreichbar und liegen auf beiden Remotes (origin, NAS) und in jedem Klon, also vermutlich auch im Git-Deploy-Checkout auf dem Server. Entscheidung: Historie mit git filter-repo bereinigen und force-pushen (alle Klone neu, Server-Checkout neu) oder bewusst belassen und dokumentieren. |
Release-Plan R6.2 | M |
| 1.2 | Schlüssel rotieren, deren Rotation nirgends belegt ist: OpenAI, Google OAuth, Mail-Zugang (K2 vom 14.07.), Context7 (stand in .mcp.json, Git-Historie), Connektar-API-Keys (Legacy-Keys liefen über Test-Kanäle), MySQL-Root lokal (Git-Historie). |
optimize 14.07. K2, Deploy v1.1.0 F, Sicherheitsplan | S [EXTERN] |
| 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. |
Sicherheitsplan, Spamschutz | S |
| 1.4 | Lokale Dateien mit Personenbezug sichern bzw. löschen (alle gitignored): dev/archive/migration-2026/sql/ (905 MB Dumps), dev/migration/ (7,4 GB Medien-Staging; nach Backup), dev/2026-10/laravel.log (Produktions-Log 08.10., Fehler in v1.6.1 behoben), dev/newsletter/mail-address.md (47 Bounce-Adressen; nach bestätigtem Import), dev/api/ (Postman mit API-Keys, Activity-Logs der Alt-APIs bis 10.07.), storage/app/private/restore-company-user-auto-2026-10-07.sql. |
dev/README | S |
| 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). | 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 |
| offen | IMKIS: Pilot nach dem Treffen am 01.10. — Ergebnis nachtragen (3.6). | Roadmap Nutzergewinnung |
| 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.
| # | 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 |
| 3.7 | Wortwahl „automatisierte Prüfung“ (D.6/S10) ist nur teilweise umgesetzt: „Qualitätsgeprüft“ steht noch in lang/de/web.php (Meta-Beschreibung beider Startseiten), lang/de/static.php, Kunden-Dashboard und EN-Pendants; Preisseite sagt „Inhaltsprüfung“. |
Bildrechte-Plan | S |
| 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 |
|---|---|---|---|
| 4.1 | Sessions: legacyCachedMark() entfernen, „Aktive Sessions“ für Redis (siehe Abschnitt 2). |
Sicherheitsplan | S–M |
| 4.2 | Löschfristen für activity_events und api_usage_logs (heute keine; model:prune nur für Anmeldezähler und Kontaktanliegen). |
Monitoring-Plan Phase 3 | S |
| 4.3 | POST api/v1/newsletter/subscribe legt Abos ohne Double-Opt-in an (kein Bestätigungsweg) — abschalten oder mit dem Branchen-Digest (6.4) koppeln. |
QA-Checkliste | S |
| 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 |
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 |
6. Produkt und Wachstum
| # | Punkt | Quelle | Aufwand |
|---|---|---|---|
| 6.1 | Abbruchbedingungen festlegen (Zeitraum, Schwellwert) für Block 1 bis 3 — ohne sie ist keine Wachstumsmaßnahme bewertbar. Block 1 läuft seit 17.09. ohne Vergleichspunkt. | Roadmap Nutzergewinnung, Basiswerte | S (Entscheidung) |
| 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 (Stufen 1–5, nicht begonnen). Offene Entscheidungen: O3 Schwelle Monatsrückblick, O5 englische Fassung, O6 Bild-Template, O7 Backfill aus den Tags, O9 Social-Accounts, O10 n8n/Buffer, O11 Opt-in, O12 wer beantwortet Rückfragen, O13 Impressum in Profilen. Andocken in deploy.sh, nicht als Ploi-Hook. |
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 |
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 |