Technical Debt & Refactoring-Plan
Systematische Erfassung von Technical Debt, Legacy-Code, Laravel-Best-Practice-Verstößen und Flux UI Pro Migrationspotenzial. Zuletzt aktualisiert: 2026-03-10.
Übersicht
| Dokument | Inhalt |
|---|
| Refactoring-Plan (Phasen 1–5) | Durchnummerierter Refactoring-Plan: Quick Wins, Flux UI Migration, Component-Splitting, Template-Cleanup, Code-Qualität |
| Bestehende Technical Debt | Deprecated Code, deaktivierte Features, bekannte Einschränkungen, Architektur-Entscheidungen |
| Audit-Ergebnis & erledigte Items | Gesamtergebnis des Codebase-Audits über 10+ Kategorien + erledigte Items |
| Bekannte Test-Failures | 35 SQLite-Inkompatibilitäten, Rector-Erkenntnisse |
| Video Trends & Video Charts | Erweiterungsideen für Video Trends + Video-Statistiken-Diagramme |
| DB-Monitoring Dashboard | Erweiterungsideen für PostgreSQL-Monitoring |
| Error Monitor | Erweiterungsideen für Error-Monitor-Charts |
| Newsletter-System | Erweiterungsideen für Newsletter-Feature |
| Queue & Circuit Breaker | No-Release-Pattern, Monitoring-Dashboard, Alerting |
| Security Audit | CSP, Rate Limiting, Session Cookies, HTML Purifier |
| Laravel Codex Audit | Service-Extraktion, Turnstile-Duplication, Job-Timeouts, Return-Types |
| Test-Audit | Coverage-Lücken (Jobs, Commands, Middleware, Mail, Models) + kritische Findings |
| Explore-Bestandsentwicklung | Sparklines, Wöchentlicher Vergleich, Churn-Analyse |
| Public Explorer | Sitemap, Caching, Trending-Sektion, Country-Filter, OG-Images |
| Compare-Mode | Zeitraum-Selector, Share-Link, Export, AI Insights |
| Onboarding & Pipeline Monitor | Onboarding-Toast, Pipeline E-Mail-Digest, Alerting |
| Related Channels / Profiles | Bulk-Command, Prioritäts-Sortierung |
| Unified Feedback-Widget | Floating Button auf allen öffentlichen Seiten, Widget auf CMS-Seiten |
| AI-Enhancer: Manual Override | Batch-Edit, Fine-Tuning Export, Contact-Link-Context, Tag-Propagation, Vision, Re-Evaluation, Übernahme-Dropdown |
| AI-Enhancer: Mehrsprachigkeit | Keyword-Übersetzung, Beschreibungs-Regenerierung, Frontend-Mehrsprachigkeit, Kategorie-Übersetzungen, Backfill-Monitoring |
| Deep Audit 2026-03-04 (inline unten) | Security: CMS-XSS, CSP-Header, shell_exec. Code Quality: R2-Tests, Index-Prüfung, Config-Werte |
| Matomo Admin-Statistiken (Audit 2026-03-06, inline unten) | E2 Echtzeit-Details, E3 Page Performance, E7 Export, E9 Workspace-Stats |
| R2 Metrics Langzeitspeicherung (Audit 2026-03-06, inline unten) | E4 CSV-Export, E5 Vergleichs-Modus, E6 Dashboard-Widget |
| Video-Statistiken-Tracking (Audit 2026-03-07, inline unten) | Drill-Down-Modal, QuotaGuard-Integration, Trend-Pfeile |
| Cloudflare AI Crawl Analytics (Audit 2026-03-07, inline unten) | Bot-Blockierung-Alerts, Matomo-Vergleich, Realtime-Widget, Bot Management Config |
| Mehrsprachigkeit / i18n (Audit 2026-03-10, inline unten) | Zahlenformatierung, Queued-Mail-Locale, weitere Sprachen |
| Collector Idle Bonus Scraping (Audit 2026-03-20, inline unten) | Adaptive Limits, Smart-Priorisierung, TikTok, Cross-Platform, History |
| Collector API Fail-Statistik & Token-Schutz (Audit 2026-03-20, inline unten) | Per-Collector Tageslimit, Webhook-Alarme, Geo-Analyse, Fehler-Trends-Widget |
| AI-Enhancer Queue System (Audit 2026-04-01, inline unten) | JSONB-Indexes, ConsolidateTagChunk Queue/Unique, Forge Worker --tries, Correlated Subquery |
Zusammenfassung Refactoring-Plan
| Phase | Items | Priorität | Geschätzter Aufwand |
|---|
| Phase 1: Kritische Fixes | 3 | Hoch–Mittel | ~1 Stunde |
| Phase 2: Flux UI Migration | 3 | Mittel–Niedrig | ~1-2 Stunden |
| Phase 3: Component-Refactoring | 5 | Hoch–Mittel | ~8-12 Stunden |
| Phase 4: Template-Cleanup | 2 | Mittel–Niedrig | ~2-3 Stunden |
| Phase 5: Code-Qualität | 3 | Mittel–Niedrig | ~3-4 Stunden |
| Gesamt | 16 Items | | ~15-22 Stunden |
Empfohlene Reihenfolge: Phase 1 → Phase 2 → Phase 3.1 (Dashboard) → Phase 3.2 (Watchers/Index) → Rest nach Bedarf.
Erweiterungsideen: Optimierte Profilbilder (Audit 2026-02-22)
| Item | Beschreibung | Priorität |
|---|
<picture> Element mit WebP/AVIF Fallback | <x-profile-image> Component um <picture>-Tag mit <source> für AVIF/WebP und JPEG-Fallback erweitern | Niedrig (96%+ Browser-Support für WebP) |
| Redis-Cache für LQIP Data URIs | LQIP Base64-Strings in Redis cachen statt bei jedem Seitenaufruf aus DB zu laden | Mittel |
| Queued Variant Generation | Varianten-Erzeugung als Queued Job statt synchron im Request — für Bulk-Import-Szenarien mit vielen Bildern gleichzeitig | Mittel |
| Aggressive Cache-Header für Varianten | Cache-Control: public, max-age=31536000, immutable für _md.webp/_sm.webp Dateien — Hash-basierte Dateinamen ermöglichen lange Cache-TTL | Mittel |
| CDN-Integration für optimierte Bilder | Varianten über CloudFront/Bunny CDN ausliefern statt direkt vom Storage-Server | Niedrig |
| Scheduled Cleanup-Job | images:cleanup-orphaned als wöchentlichen Scheduled Task einplanen | Niedrig |
| Imagick als Production-Default | GD → Imagick auf Forge-Server, bessere Qualität bei gleicher Dateigröße, schnellere Verarbeitung | Mittel |
Erweiterungsideen: Admin API Management (Audit 2026-02-22)
| Item | Beschreibung | Prioritaet |
|---|
| E3: Audit-Log fuer Token-Aktionen | Alle Token-Aktionen (erstellen, revozieren, loeschen, IP-Aenderung) in Audit-Tabelle protokollieren mit Admin-User, Timestamp und Aktion | Mittel |
| E6: Token-Rotation | "Token rotieren" Funktion: neuen Token generieren, alten automatisch revozieren. Uebergangsphase konfigurierbar (alter Token fuer X Minuten gueltig) | Niedrig |
Erweiterungsideen: Postbox Score V2 (Audit 2026-02-23)
| Item | Beschreibung | Priorität |
|---|
| Plattform-spezifische Gewichtungen | Growth/Momentum/Consistency/Engagement Gewichte pro Plattform konfigurierbar (z.B. YouTube: 50% Growth + 20% Momentum + 15% Consistency + 15% Engagement). Aktuell einheitlich 40/30/20/10 für alle Plattformen. | Mittel |
| Engagement V3 — Multi-Signal | Neben Upload-Aktivität auch Engagement-Rate (Likes/Follower, Comments/Views) einbeziehen, wenn verfügbar. Aktuell nur Upload-Frequenz als Proxy. | Mittel |
| Score-History-Vergleich | Admin-Dashboard mit Plattform-Verteilung der Top-Scores über Zeit (Chart: war es schon immer IG-lastig? Wie hat sich V2 ausgewirkt?). | Niedrig |
| Tier-spezifische Mindest-Datenpunkte | Micro-Profile brauchen 14 statt 7 Datenpunkte für stable Status → weniger volatiles Scoring bei kleinen Profilen mit kurzer Historie. | Niedrig |
| Admin Score-Boost | Manueller Score-Penalty reicht nicht — Admin sollte auch Score-Boost geben können (z.B. für bekannte Brands die algorithmisch untergehen). Ähnlich wie manual_penalty, aber als positiver Multiplikator. | Niedrig |
Erweiterungsideen: AI Detection Queue Snowball Fix (Audit 2026-02-23)
| Item | Beschreibung | Priorität |
|---|
| Prioritaets-System fuer AI-Detection Queue | Separate Queue-Prioritaeten fuer AI-Detection: HIGH (frisch importierte Profile), NORMAL (regulaerer 15-Min-Zyklus), LOW (woechentlicher Retry), BACKGROUND (Re-Detection nach Cooldown). Umsetzung ueber --queue=ai-detection-high,ai-detection,ai-detection-low oder Laravel Queue Priorities. | Mittel |
Erledigt: Gemini 2.5 Flash-Lite Migration — umgesetzt, Modell laeuft auf gemini-2.5-flash-lite (konfigurierbar via GEMINI_MODEL).
Erweiterungsideen: SEO & Structured Data (Audit 2026-02-23)
Hinweis (Audit 2026-02-24): E1 (Dynamische OG-Images), E2 (FAQ-Schema), E3 (VideoObject-Schema) und OG-Default-Bild wurden implementiert.
Hinweis (Audit 2026-03-10): E6 (Hreflang-Tags) wurde mit Plan 33 (Mehrsprachigkeit) vollständig umgesetzt — hreflang de/en/x-default auf allen öffentlichen Seiten + Sitemap. Keine verbleibenden Items.
Erweiterungsideen: OG-Image-Generierung (Audit 2026-02-24)
| Item | Beschreibung | Priorität |
|---|
| E3: Animated OG-Images | GIF/APNG mit Follower-Chart-Animation für Discord/Telegram (experimentell, nur wenige Plattformen unterstützen animierte Previews). | Niedrig |
| E4: A/B-Testing OG-Image-Designs | Unterschiedliche Templates mit Conversion-Tracking (Klickrate aus GSC nach Template-Wechsel messen). Erfordert Template-Rotation und Auswertungslogik. | Niedrig |
| E5: WebP/AVIF statt PNG | Aktuell noch nicht breit unterstützt von Social-Media-Crawlern (WhatsApp, Facebook, LinkedIn erwarten PNG/JPG). Sobald Support breiter wird, auf WebP umstellen für ~50% kleinere Dateien. | Niedrig |
Erweiterungsideen: Cloudflare R2 Storage Migration (Audit 2026-02-24)
| Item | Beschreibung | Priorität |
|---|
| E1: Cloudflare Image Resizing | On-the-fly Resize via URL-Parameter (?width=128&height=128&fit=cover). Eliminiert lokale Varianten-Generierung (ProfileImageProcessor) komplett — nur noch Originale speichern. Cloudflare Pro Plan erforderlich ($20/Monat). Spart Storage (keine _md/_sm Varianten) und Server-CPU. Umstellung: alle getUrlForSize() Aufrufe auf URL-Parameter umstellen. | Mittel |
| E2: Cloudflare Image Transformations (Polish) | Automatische WebP/AVIF-Konvertierung durch Cloudflare Polish für alle Bilder. Eliminiert lokale Bildverarbeitung komplett — nur noch Original-JPG speichern, Cloudflare liefert optimiertes Format basierend auf Browser Accept-Header. Cloudflare Pro Plan erforderlich. Kombinierbar mit E1 für komplette Eliminierung von ProfileImageProcessor. | Niedrig |
Erweiterungsideen: Pulse DB-Reduktion (Audit 2026-02-25)
| Item | Beschreibung | Priorität |
|---|
| E2: Admin-Metrik-Export | Server-Metriken als CSV/JSON Export für externe Monitoring-Tools. | Niedrig |
| E3: Pulse komplett deaktivieren für Server-Metriken | Eigene Recorder statt Pulse-Recorder für CPU/RAM/Swap — Pulse nur noch für CacheInteractions, SlowQueries, Exceptions. | Niedrig |
| E4: Prometheus-Export | server_metrics Daten als Prometheus-Endpunkt für Grafana-Integration. | Niedrig |
Erweiterungsideen: Auto-Discovery (Audit 2026-02-25)
| Item | Beschreibung | Priorität |
|---|
| E1: Batch-Discovery-Queue | Batch-basierte Discovery statt pro-Link-Jobs. Mehrere Links in einem Job zusammenfassen für bessere API-Quota-Nutzung. | Niedrig |
| E4: Discovery-History-Timeline | Chronologischer Verlauf aller Discoveries mit Vor-/Nachher-Status, gefundenen Profilen und Fehlern. Admin-UI in /admin/import-status. | Niedrig |
| E6: Rückwärts-Discovery | Wenn ein neues Profil importiert wird, automatisch prüfen ob es als Contact-Link auf existierenden Profilen referenziert wird und diese Verknüpfungen nachholen. | Mittel |
Erweiterungsideen: Web Vitals V2 (Audit 2026-02-25)
| Item | Beschreibung | Priorität |
|---|
| E2: CSV/PDF-Export | Web Vitals Report als downloadbare CSV/PDF-Datei für Stakeholder-Kommunikation. | Niedrig |
| E5: Budget-System | Konfigurierbare p75-Budgets pro Metrik (z.B. LCP ≤ 2000ms). Alerts wenn Budget überschritten wird. | Mittel |
| E6: Real-User-Monitoring Dashboard | Öffentliches Performance-Dashboard für Transparenz (wie speedlify/calibre), read-only für alle User. | Niedrig |
| E7: Historische Vergleiche | Vergleich aktueller Periode gegen frei wählbare historische Periode (nicht nur vorherige Periode). | Niedrig |
Erweiterungsideen: Nightly Pipeline Queue-Umbau (Audit 2026-02-26)
| Item | Beschreibung | Priorität |
|---|
| E1: Adaptive Batch Sizes | Batch-Größe dynamisch an aktuelle DB-Last anpassen (z.B. via pg_stat_activity Connection-Count). Bei hoher Last kleinere Batches, bei niedriger Last größere. Aktuell statisch über Config. | Mittel |
| E2: Priority Lanes (VIP-Profile zuerst) | Profile mit aktiven Watchern, hoher Follower-Zahl oder Premium-Workspaces bevorzugt verarbeiten. Separate Priority-Batches am Anfang der Pipeline dispatchen. | Mittel |
| E3: Incremental Scores | Nur Profile mit neuen Metriken seit letzter Berechnung scoren statt alle ~35.000. Erfordert Tracking welche Profile neue social_profile_daily_metrics seit gestern haben. Potenzial: ~80% weniger Score-Berechnungen an ruhigen Tagen. | Hoch |
| E5: Global Leaderboards mit aktuellen Scores | Global Leaderboards nach Score-Berechnung statt nach Rollups ausführen, damit die neuesten Scores einfließen. Aktuell laufen Leaderboards nach Rollups (Batch 1B → 2AB), Scores nach Batch 1A. | Niedrig |
Erweiterungsideen: YouTube New-Video-Detection (Audit 2026-02-28)
| Item | Beschreibung | Priorität |
|---|
| E1: Adaptive RSS-Polling-Frequenz | Polling-Frequenz basierend auf Upload-Frequenz des Channels anpassen. Channels die taeglich uploaden: alle 15min. Channels die woechentlich uploaden: alle 2h. Reduziert unnoetige RSS-Requests. | Mittel |
| E2: First-24h Stats Frequency | In den ersten 24h nach Video-Erkennung haeufigere Stats-Abfragen (alle 2h statt taeglich). Wichtig fuer Performance-Analyse im kritischen Zeitfenster. | Mittel |
| E4: Premiere/Scheduled Video Support | Videos mit liveBroadcastContent=upcoming oder liveStreamingDetails.scheduledStartTime erkennen und gesondert behandeln (z.B. Countdown, geplante Veroeffentlichung anzeigen). | Niedrig |
E5: Short Detection | YouTube Shorts erkennen — Erledigt: is_short + isEffectiveShort() + Admin MarkVideoAsShort-Button implementiert. | Niedrig |
| E6: Batch-Import | Mehrere Video-URLs gleichzeitig hinzufuegen (Textarea mit Zeilenumbruch-Trennung). Batch-API-Call fuer bis zu 50 Videos gleichzeitig. | Niedrig |
| E7: Channel Adding via Workspace Selection | Video-URL-Resolver erlaubt Channel-Hinzufuegen wenn Profil noch nicht existiert. Workspace-Selector fuer automatischen Watcher-Import. | Niedrig |
| E8: Cross-Workspace Video Sharing | Wenn ein Video ueber WebSub/RSS erkannt wird, allen Watchers mit demselben Channel eine Notification senden, nicht nur dem ersten. | Niedrig |
| E9: Notifications bei neuen Videos | Push-Notification/Toast an User wenn ein neues Video fuer einen beobachteten Channel erkannt wird. | Mittel |
| E10: Immediate Score Calculation | Nach Video-Erkennung sofort einen initialen Video-Score berechnen statt auf den naechsten Nightly-Run zu warten. | Niedrig |
| E11: WebSub Health Dashboard | Dediziertes WebSub-Health-Monitoring mit Subscription-Status-Map, Notification-Latenz-Charts, Hub-Response-Zeiten. | Niedrig |
| E12: Stats Frequency Tiers | Unterschiedliche Stats-Frequenzen basierend auf Video-Alter: ≤24h alle 2h, ≤7d taeglich, ≤30d alle 3 Tage, >30d woechentlich. | Mittel |
Erweiterungsideen: Merge Profile-Categories → Explore-Status (Audit 2026-02-28)
| Item | Beschreibung | Priorität |
|---|
| E1: Category Trend in Inventar | Kategorisierungs-Trend als Sparkline in der 14-Tage-Bestandsentwicklungs-Tabelle. | Niedrig |
| E2: Drill-Down per Kategorie | Klick auf Kategorie oeffnet Detail-Ansicht mit allen Profilen dieser Kategorie, Filtermoglichkeiten, Bulk-Aktionen. | Niedrig |
| E3: Category Configuration on Page | Kategorien direkt auf der Admin-Seite konfigurieren (Labels, Icons, Reihenfolge) statt ueber Config. | Niedrig |
| E4: Coverage Trend Chart | Zeitverlauf-Diagramm der Kategorie-Abdeckung (% kategorisiert ueber Zeit). | Niedrig |
Erweiterungsideen: Newcomer-Datenqualitaet (Audit 2026-02-28)
| Item | Beschreibung | Priorität |
|---|
| E1: "Newly Discovered" Badge | Badge in Toplists fuer Profile die erst kuerzlich importiert wurden (z.B. ≤7 Tage). | Niedrig |
| E2: Separate Newcomer-Sektion | Eigene "Neu entdeckt"-Sektion auf /tops-flops fuer Profile mit kurzer Historie. | Mittel |
| E3: Percentile-Based Outlier Detection | Statistischer Ansatz: Wachstumsraten die >3 Standardabweichungen ueber dem Median liegen, als Anomalie markieren. | Niedrig |
| E4: Admin Newcomer Report | Admin-Dashboard-Card die Profile mit kurzem Tracking-Zeitraum und ungewoehnlich hohem Ranking anzeigt. | Niedrig |
| E5: Configurable Threshold per Metric | Unterschiedliche min_history_days pro Metrik (z.B. Follower: 3 Tage, Views: 7 Tage, Score: 14 Tage). | Niedrig |
| Item | Beschreibung | Priorität |
|---|
| E1: Gewichtetes Scoring nach Quelle | Lokale Kandidaten-Score-Gewichtung nach Quelle differenzieren: FTS-Treffer 1.0x, AI-Keyword-Match 1.2x, Parsed-Link 1.5x. Aktuell gleichgewichtet. | Niedrig |
| E3: Candidate Quality Feedback Loop | Wenn ein Admin eine Related-Beziehung manuell entfernt oder bestaetigt, dieses Feedback fuer kuenftige Suchen nutzen (positive/negative Signale). | Mittel |
| E4: Stale Local Candidates Refresh | Lokale Kandidaten periodisch neu berechnen wenn sich AI-Keywords oder Kategorien des Quell-Profils aendern. Aktuell nur bei manueller oder Auto-Fill-Ausloesung. | Niedrig |
| E5: Local-Only Mode (Zero API) | Config-Option um Related-Channel-Suche komplett ohne API-Zugriff zu betreiben (nur lokale Kandidaten). Fuer Quota-Engpaesse oder Dev-Umgebungen. | Niedrig |
Erweiterungsideen: YouTube Publishing-Analytics (Audit 2026-02-27)
| Item | Beschreibung | Priorität |
|---|
| E4: CSV-Export | CSV-Download der Publishing-Analytics-Rohdaten (Wochentag-Statistiken, VFR, Engagement) für eigene Analysen. Export-Button auf der Admin-Seite. | Niedrig |
| E5: Push-Benachrichtigung | "Heute ist dein bester Veröffentlichungstag!" — automatische Notification an User basierend auf ihren Publishing-Analytics-Daten. Erfordert Preference-Einstellung pro User. | Niedrig |
| E7: API-Endpunkt | GET /api/v1/publishing-insights?tier=small&category=gaming&weeks=8 — REST-API für Publishing-Insights, nutzbar für User-Dashboard, Explore-Seite oder als Premium-Feature. | Niedrig |
| E9: Scheduling-Empfehlung | Personalisierte Empfehlung "Bester Veröffentlichungstag/-uhrzeit" basierend auf Channel-Kategorie und Tier. Erfordert Aggregation pro Kategorie und User-Facing Widget. | Niedrig |
| E10: Historischer Vergleich Vorwoche | Woche-zu-Woche-Vergleich der Publishing-Patterns: "Diese Woche vs. letzte Woche" mit Delta-Anzeige für alle Metriken. Erfordert week_start-basierte Filterung. | Niedrig |
| E14: Feiertage im Kalender | Weltweite Feiertage in der Heatmap/Kalender-Ansicht anzeigen um saisonale Effekte auf Publishing-Patterns zu erklären. Benötigt Feiertags-Datenquelle (z.B. Nager.Date API oder statische Liste). | Niedrig |
Erweiterungsideen: Video-Thumbnails von R2 (Audit 2026-02-27)
| Item | Beschreibung | Priorität |
|---|
E2: <picture> Element mit srcset | Verschiedene Größen (sm/md) per srcset anbieten, damit der Browser die optimale Größe wählt. Analog zum Profilbild-System möglich, erfordert Blade-Component-Erweiterung. | Niedrig |
| E4: Thumbnail-Qualitätsprüfung | Prüfen ob YouTube das maxresdefault-Thumbnail liefert oder nur ein Default-Placeholder (graues Bild). Manche Videos haben kein HD-Thumbnail — diese könnten markiert oder mit niedrigerer Priorität behandelt werden. | Niedrig |
Erweiterungsideen: Sitemap Management Erweiterungen (Audit 2026-02-28)
| Item | Beschreibung | Priorität |
|---|
| E7: GSC-Cross-Reference | Indexed Pages aus Google Search Console mit Sitemap-URLs vergleichen — Coverage-% anzeigen. Erfordert GSC API-Integration (OAuth) und periodischen Abgleich. | Niedrig |
Erweiterungsideen: Instagram → YouTube Research (Audit 2026-02-28)
| Item | Beschreibung | Priorität |
|---|
| E3: AI-Social-Links als Primärquelle | Statt Keyword-Suche zuerst die Social-Media-Links aus der Instagram-Bio parsen (AI-extrahiert). Wenn ein YouTube-Link vorhanden ist, direkt importieren ohne API-Suche. Spart Quota und hat höchste Trefferquote. Erfordert Zugriff auf ai_social_links oder Contact-Link-Daten. | Hoch |
| E5: Parallel Processing | Mehrere Instagram-Profile gleichzeitig researchen (parallel Job-Dispatch statt sequentiell). Erfordert bessere Quota-Koordination zwischen parallelen Jobs und möglicherweise einen Semaphore-Mechanismus. | Mittel |
| E7: Success Rate Tracking | Erfolgsrate pro Suchstrategie tracken (S1/S2/S3/E9): wie oft findet Namens-Suche vs. Handle-Suche vs. Keyword-Suche tatsächlich passende Channels? Ermöglicht datenbasierte Optimierung der Suchstrategie-Reihenfolge. | Mittel |
| E8: Topic-ID aus Instagram-Kategorie | YouTube Topic-ID automatisch aus der Instagram-Kategorie ableiten (z.B. "Gaming" → /m/0bzvm2). Verbessert Suchrelevanz bei Keyword-Suchen. Erfordert Mapping-Tabelle Kategorie → Topic-ID. | Niedrig |
| E10: Batch-Mode | Sammel-Import: alle gefundenen Channels eines Tages in einen einzigen WatcherImportRun zusammenfassen statt pro Profil einen Import zu erstellen. Reduziert Import-Run-Overhead und vereinfacht Admin-Übersicht. | Niedrig |
Erweiterungsideen: App-Monitoring / Sentry-Cron-Ersatz (Audit 2026-03-03)
| Item | Beschreibung | Priorität |
|---|
| E1: Slack/Telegram-Alerts | Cron-Heartbeat-Ausfälle zusätzlich über Slack oder Telegram pushen statt nur In-App-Notifications. Erfordert Webhook-Integration und Channel-Konfiguration. | Mittel |
| E5: Custom Health-Checks | Beliebige Health-Checks registrierbar machen (z.B. "R2 erreichbar?", "Gemini API OK?"). Registry-Pattern mit Interface HealthCheck und register() Methode. Erweiterbar für externe Dienst-Überwachung. | Mittel |
Erweiterungsideen: AI-Agent-Integration & IndexNow (Audit 2026-03-03)
| Item | Beschreibung | Priorität |
|---|
| E2: Markdown-Versionen öffentlicher Seiten | Jede öffentliche Seite unter {url}.md als Markdown-Version bereitstellen (llms.txt Standard). Z.B. /explorer/category/gaming.md liefert eine Markdown-Tabelle aller Gaming-Profile. Erfordert Middleware oder Route-Suffix-Handling. | Niedrig |
| E5: OG-Image Auto-Regeneration nach IndexNow | Wenn ein Profil aktualisiert wird, automatisch OG-Image neu generieren und dann IndexNow submitten — so sehen AI-Agents und Social-Media-Shares immer aktuelle Daten. Erfordert Kopplung OG-Image-Pipeline → IndexNow-Observer. | Niedrig |
| E8: RSS/Atom Feed für neue Profile | Feed unter /explorer/feed.xml der neue/geänderte Profile listet. AI-Agents können den Feed abonnieren statt die Sitemap zu polleen. Erfordert RSS-Generator mit Pagination und lastBuildDate. | Niedrig |
| E9: Admin-Toggle für AI-Bot-Erlaubnis | Pro Bot ein Toggle im Admin-Dashboard, der sowohl robots.txt als auch Cloudflare WAF Rules aktualisiert. Zentrale Steuerung ohne Dashboard-Wechsel. Erfordert Cloudflare API-Integration für WAF Rule Updates. | Mittel |
Erweiterungsideen: Matomo Admin-Statistiken (Audit 2026-03-06)
| Item | Beschreibung | Priorität |
|---|
| E2: Echtzeit-Besucher-Liste | Live.getLastVisitsDetails mit erweiterten Details (besuchte Seiten, Verweildauer pro Seite). Aktuell nur Basis-Daten (Land, Aktionen, Dauer). countVisitorsToFetch=20 begrenzen. | Niedrig |
| E3: Seiten-Performance | PagePerformance.get für DOM/Network/Server/Transfer Ladezeiten. Kombination mit Web Vitals-Daten. Nur verfügbar wenn Matomo JS-Tracker Performance-Plugin aktiviert hat. | Niedrig |
| E7: CSV/PDF-Export | KPI-Daten als CSV exportierbar für Reports. PDF-Snapshot des Dashboards für wöchentliche Team-Reports. | Niedrig |
| E9: Dashboard-Widgets für Workspace-Owner | Workspace-spezifische Stats via Matomo Segment-API. Erfordert User-spezifisches Tracking (customVariable). | Niedrig |
Erweiterungsideen: R2 Metrics Langzeitspeicherung (Audit 2026-03-06)
| Item | Beschreibung | Priorität |
|---|
| E4: CSV/JSON-Export | Download-Button für die Rohdaten der R2-Metriken (Hourly/Daily Snapshots). Analogie zum Cloudflare Dashboard "Download"-Button. | Niedrig |
| E5: Vergleichs-Modus | Zwei Zeiträume im Chart überlagert darstellen (z.B. diese Woche vs. letzte Woche). Erfordert doppelte Datenabfrage und überlappende Serien. | Niedrig |
| E6: Dashboard-Widget | Kleines Storage-Sparkline-Chart auf der Admin-Hauptseite als Quick-Glance. Erfordert Mini-Component mit reduzierten Daten. | Niedrig |
Erweiterungsideen: Cloudflare R2 Dashboard Refactor (Audit 2026-03-04)
| Item | Beschreibung | Priorität |
|---|
| E6: Operations-Heatmap | Requests pro Stunde/Wochentag als Heatmap — zeigt Lastmuster (z.B. Scraping-Peaks). Erfordert stündliche Granularität in GraphQL-Abfrage und Heatmap-Rendering (z.B. via Chart.js Matrix). | Niedrig |
| E7: Public-Explorer CDN-Performance | Cloudflare CDN Cache-Hit-Rate für den Public Explorer messen (separate Cloudflare Zone Analytics API). Zeigt wie effektiv der CDN-Cache arbeitet und wo Cache-Misses auftreten. | Niedrig |
| E8: Grafana/Prometheus Export | R2-Metriken als Prometheus-Endpunkt exportieren für externe Monitoring-Tools (Grafana). Erfordert /metrics-Route mit Prometheus-Format und Authentication. | Niedrig |
Deep Audit: Security & Code Quality (2026-03-04)
Security Findings
| Item | Beschreibung | Priorität |
|---|
| HTML-Sanitization für CMS-Pages | Page->content wird mit {!! !!} unescaped gerendert (show.blade.php, legal-consent.blade.php, register.blade.php). Bei kompromittiertem Admin-Konto XSS-Risiko. Lösung: mews/purifier auf Page-Model integrieren oder Content beim Speichern sanitizen. | Mittel |
Content-Security-Policy (CSP) Header | Implementiert (2026-03-05). Vollständige CSP mit dynamischen Origins. jsdelivr.net für ApexCharts, Sentry CDN, Matomo, Reverb WebSocket, Turnstile, CDN — alles dynamisch aus Config. | ✅ Erledigt |
shell_exec() durch PHP-Alternativen ersetzen | 7 Stellen nutzen shell_exec() für du, git log, find. Alle mit internen Pfaden (kein User-Input), aber PHP-native Alternativen (scandir(), DirectoryIterator) wären sicherer. | Niedrig |
Code Quality Findings
| Item | Beschreibung | Priorität |
|---|
| CloudflareR2Service Unit-Tests | Kritischer Service (API-Calls, Kostenberechnung, Anomalie-Erkennung) hat keine dedizierten Unit-Tests. Mock-Tests für fetchAccountMetrics(), calculateMonthlyCost(), detectAnomalies() erstellen. | Hoch |
Index-Prüfung social_profile_links | Nach Widening von value/display_url auf varchar(2048) prüfen ob bestehende Indexes noch effizient sind. Ggf. Partial-Index oder Functional-Index auf LOWER(value) für Lookups. | Mittel |
| YouTube Research Limit als Config | Hardcoded $limit = 1000 in ProcessYouTubeResearchBatch (Line 185) sollte als Config-Wert oder Klassenkonstante mit Begründung definiert werden. | Niedrig |
env() in AppServiceProvider | env('SENTRY_RELEASE') in AppServiceProvider::boot()env('SENTRY_RELEASE') existiert nicht mehr. | ✅ Erledigt |
Erweiterungsideen: Sentry-Feedback-Replacement (Audit 2026-03-05)
| Item | Beschreibung | Priorität |
|---|
| Kontext-Erkennung im globalen Feedback (E2) | Wenn der User auf einer Watcher-Seite ist, automatisch den Watcher-Kontext erkennen per Route-Parameter oder Meta-Tag. Würde separate kontextspezifische Buttons überflüssig machen. Erfordert Livewire-Routing-Kontext im global eingebundenen Component. | Mittel |
| Keyboard-Shortcut für Feedback (E3) | Ctrl+Shift+F oder ähnlich zum schnellen Öffnen des Feedback-Modals. Alpine.js @keydown.window Listener im Floating-Button. | Niedrig |
| Screenshot-via-API (E4) | Browser-Screenshot automatisch als Anhang mitschicken (html2canvas oder ähnlich). Erhöht die Qualität der Bug-Reports deutlich. ~2h Aufwand. | Niedrig |
| Feedback-Admin-Panel (E5) | Admin-Seite zum Verwalten eingegangener Feedbacks (aus contact_submissions). Status-Tracking (offen, in Bearbeitung, erledigt), Antwort-Funktion direkt aus der App. Erfordert neue Admin-Route, Livewire-Component und Status-Spalte in contact_submissions. | Niedrig |
| Toast statt Modal-Wechsel (E6) | Nach erfolgreichem Feedback-Versand: Toast statt Erfolgsmeldung im Modal. Modal schließt sich automatisch, Toast bestätigt. ~15 min Aufwand. | Niedrig |
Erweiterungsideen: Profilbild-Varianten / Image Pipeline (Audit 2026-03-05)
| Item | Beschreibung | Priorität |
|---|
| AVIF Dual-Format (E2) | WebP + AVIF parallel generieren, <picture> Element mit AVIF-Preference. Bessere Kompression (~30% kleiner als WebP). Erfordert Intervention Image AVIF-Support und Template-Anpassung. | Mittel |
| BlurHash JS-Decoder (E3) | Dedizierter JavaScript BlurHash-Decoder für animiertes Blur-to-Sharp Fade-In statt statischem CSS-Background. Aktuell ist BlurHash als CSS background-image data-URL implementiert. | Niedrig |
| CDN-Layer vor R2 (E4) | Cloudflare CDN (oder Bunny CDN) vor R2 schalten. Cache-Hit-Rate für Slider-Bilder wäre >90%. Reduziert R2-Egress und Latenz. ~4h Aufwand. | Mittel |
| On-Demand Resize via Cloudflare (E5) | Statt Varianten vorab zu generieren: Cloudflare Image Resizing. URL-basiert: /cdn-cgi/image/width=512,quality=80/original.jpg. Kein Backfill nötig, beliebige Größen jederzeit. Kosten: $0.50/1000 Transformations. | Mittel |
| Adaptive Qualität (E6) | Save-Data HTTP-Header auswerten. Bei langsamer Verbindung: kleinere Variante (medium statt large). ~2h Aufwand. | Niedrig |
| Explore-spezifische Variante (E8) | Explore-Grid hat andere Card-Größen als der Slider. Ggf. eigene Variante für das Explore-Grid (z.B. 300×300). ~1h Aufwand. | Niedrig |
| Lazy Loading mit Intersection Observer | JavaScript-basiertes Lazy Loading mit Intersection Observer statt loading="lazy" — ermöglicht animiertes Blurhash-to-Image Fade-In. Erfordert kleines JS-Modul und Integration in profile-image Component. | Niedrig |
| CDN Cache-Warming nach Backfill | Nach images:generate-variants automatisch die generierten URLs über Cloudflare API pre-warmen, damit der erste Seitenaufruf keine Cold-Cache-Latenz hat. Erfordert Cloudflare API Integration und ggf. Queue-Job. | Niedrig |
| Admin Image-Stats Dashboard | Admin-Seite mit Statistiken zu Bildvarianten: Anzahl Bilder mit/ohne Varianten, Speicherverbrauch pro Variante, Format-Verteilung (WebP/AVIF), Backfill-Fortschritt. Erfordert neue Admin-Route und Livewire-Component. | Niedrig |
Erweiterungsideen: Video-Statistiken-Tracking (Audit 2026-03-07)
| Item | Beschreibung | Priorität |
|---|
Drill-Down-Modal im UI | getProfileDrillDown() ist implementiert, aber noch kein UI-Modal./admin/youtube-management. Klick auf Tag öffnet Modal mit Profil-Liste. | Niedrig |
| QuotaGuard-Integration für präzise Quota-Daten | Quota-Units werden aktuell aus der Metrik-Anzahl geschätzt (ceil(videosWithMetrics/50)). Für präzisere Daten die tatsächlichen QuotaGuard-Metriken aus Redis (job_blocked, circuit_opened) in die Aggregation aufnehmen. | Niedrig |
| Trend-Pfeile in KPI-Kacheln | Coverage und Health Score mit Vortags-Vergleich (↑/↓ mit Delta). Erfordert Laden des Vortags-Aggregations-Datensatzes. | Niedrig |
| Historische Baseline für Health Score | Der Sync-Anteil im Health Score verwendet den aktuellen Stand der auto_sync_enabled Profile. Für historische Tage (Backfill) wäre ein Snapshot des Profil-Status zum jeweiligen Zeitpunkt präziser. | Niedrig |
Erweiterungsideen: Cloudflare AI Crawl Analytics (Audit 2026-03-07)
| Item | Beschreibung | Priorität |
|---|
| E7: Webhook/Alert bei Bot-Blockierung | Wenn plötzlich viele 403er für einen Bot auftauchen (z.B. durch Cloudflare WAF Rule), Admin automatisch benachrichtigen. Schwellwert-basiert (z.B. >50% 4xx-Rate für einen Bot). Erfordert Scheduled Check oder Integration in bestehenden Cron. | Mittel |
| E8: Vergleich mit Matomo Bot-Daten | Cross-Reference: Cloudflare sieht ALLE Requests (inkl. blockierte), Matomo sieht nur durchgelassene. Differenz zeigt wie viel Cloudflare blockt. Erfordert Matomo API-Abfrage für Bot-Traffic und Vergleichslogik. | Niedrig |
| E10: Realtime-Widget (Polling) | Live-Counter "Aktuell aktive AI-Bots" mit 60s Auto-Refresh. Zeigt letzte 5 Minuten AI-Bot-Requests. Erfordert kurze Cache-TTL oder WebSocket-Push und spezielle Short-Range GraphQL Query. | Niedrig |
| E11: Bot Management Config (REST API) | Cloudflare GET/PUT /zones/{zone_id}/bot_management API nutzen um AI-Bot-Schutz (ai_bots_protection), Crawler-Schutz (crawler_protection) und Bot Fight Mode direkt aus dem Admin-Dashboard zu steuern. Erfordert erweiterte API-Token-Permissions. | Mittel |
Erweiterungsideen: Health-Check-Kalibrierung (Audit 2026-03-09)
| Item | Beschreibung | Priorität |
|---|
| E2: UptimeRobot API-Integration | Historische UptimeRobot-Daten (Uptime-Prozent, Response-Zeiten, Downtime-Perioden) in die App-Monitoring-Seite einbinden. Erfordert UptimeRobot API-Key (UPTIMEROBOT_API_KEY) und neuen Service + Livewire-Computed-Property. | Niedrig |
| E5: Separate UptimeRobot-Monitore pro Check-Gruppe | Statt einem /up_system-Endpoint: separate Endpoints /up_system/cron, /up_system/services, /up_system/queue für granulareres UptimeRobot-Monitoring. Erfordert neue Controller-Methoden und UptimeRobot-Monitor-Konfiguration. | Mittel |
| E8: Notification-Digest statt Einzel-Alerts | Statt einzelner In-App-Benachrichtigungen pro Heartbeat-Ausfall: Sammlung aller Ausfälle in einer täglichen/stündlichen Digest-Nachricht. Reduziert Alert-Noise bei kaskadierten Pipeline-Ausfällen. Erfordert Anpassung des CronHeartbeatMonitorService. | Mittel |
| Item | Beschreibung | Priorität |
|---|
| E1: Explore API-Endpoint für SPA-Feeling | Lightweight JSON-API (GET /api/explore/sections?section=trending&platform=all) statt Livewire-Fullpage-Rerender. Alpine.js fetcht Sektionen asynchron, Seite lädt sofort. Ermöglicht Infinite Scroll und granulares Caching pro Sektion. Erfordert API-Route, Controller und Alpine.js Integration. | Mittel |
| E6: Cursor-basierte Pagination | ProfileGrid: Infinite Scroll mit cursorPaginate(49) statt OFFSET. Schneller bei hohen Page-Nummern. Erfordert Livewire Cursor-Pagination und Frontend-Anpassung. | Niedrig |
| E9: ETag/304 für authentifizierte Explore-Seiten | ContentFreshness-Middleware auf /explore-Routen anwenden. Komplex weil authentifizierte Seiten unterschiedliche Watcher-Maps pro User haben. Ggf. ETag pro User+Filter-Kombination. | Niedrig |
Erweiterungsideen: Deep Audit Plan 34 — R2 Storage (Audit 2026-03-11)
| Item | Beschreibung | Priorität |
|---|
R1: exists() vor Landing-Page-Bilder | CloudflareR2Service::getPublicImageUrl() ruft exists() vor jeder URL-Generierung auf Landing Pages auf. Bei vielen Bildern pro Seite (Explorer, Toplists) unnötige API-Calls. Lösung: Batch-exists() oder URL direkt generieren und 404-Fallback im Frontend. | Mittel |
| R4: Backup State-Tracking | r2:sync-backup hat kein State-Tracking (welche Dateien schon synchronisiert). Bei Wiederanlauf wird allFiles() erneut aufgerufen und alle Dateien verglichen. Lösung: Cursor-/Marker-basiertes Tracking oder Manifest-Datei. | Niedrig |
Erweiterungsideen: Plan 35 — Admin Social Profiles Image-Management (Audit 2026-03-20)
| Item | Beschreibung | Priorität |
|---|
| E3: Varianten-Regenerierung mit neuem Format (AVIF) | Button/Command zum Regenerieren aller Varianten in einem neuen Format (z.B. AVIF statt WebP). Erfordert --force --format=avif Option im images:generate-variants Command und UI-Trigger im Admin. Sinnvoll wenn AVIF-Support flächendeckend ist und Bandbreite gespart werden soll. | Niedrig |
| E6: Bulk-Actions in Profil-Tabelle | Checkbox-Auswahl in der Admin-Profil-Tabelle für Batch-Operationen: Bilder neu laden, Varianten regenerieren, Profile deaktivieren. Erfordert Livewire-Checkbox-State, Bulk-Action-Dropdown und entsprechende Backend-Methoden. | Mittel |
Erweiterungsideen: Mehrsprachigkeit / i18n (Audit 2026-03-10)
| Item | Beschreibung | Priorität |
|---|
| E1: Locale-spezifische Zahlenformatierung | DE: 1.234,56 vs EN: 1,234.56. Aktuell überall deutsches Format (number_format($n, 0, ',', '.')). Erfordert Helper oder NumberFormatter Wrapper der app()->getLocale() berücksichtigt. | Mittel |
| E2: Locale auf queued Mailables | $this->locale($user->locale) auf allen Mailables setzen, damit queued Mails in der Sprache des Empfängers gerendert werden. Aktuell werden Mails in der Server-Default-Locale (DE) gerendert. | Mittel |
| E3: Weitere Sprachen (ES, FR, IT, PT) | AI-Beschreibungen existieren bereits in 6 Sprachen — UI-Strings wären der Hauptaufwand (~500 Keys pro Sprache). Erfordert User::SUPPORTED_LOCALES Erweiterung, neue JSON-Files, Sitemap-Erweiterung. | Niedrig |
Erweiterungsideen: Admin Social Profiles Image-Management (Audit 2026-03-21)
| Item | Beschreibung | Priorität |
|---|
| E3: Varianten-Regenerierung mit neuem Format | Alle bestehenden Varianten mit neuem Format (z.B. AVIF) regenerieren. "Alle neu generieren"-Button im Admin. Erfordert Format-Konfiguration und Bulk-Regenerierungs-Job. | Niedrig |
| E4: Storage-Dashboard | Eigenes Dashboard für Storage-Übersicht: Speicherverbrauch pro Variante, Wachstumstrend, Cleanup-Optionen. Ergänzung zum bestehenden R2-Dashboard. | Niedrig |
| E5: Auto-Varianten bei Upload-Fehler | Automatische Varianten-Generierung als Fallback wenn der reguläre Upload-Prozess fehlschlägt. Retry-Queue für fehlgeschlagene Varianten. | Niedrig |
| E6: Bulk-Actions in Profil-Tabelle | Mehrfachauswahl in der Admin-Profiltabelle mit Bulk-Aktionen (z.B. Bilder neu laden, Varianten regenerieren, Status ändern). Erfordert Checkbox-Spalte und Action-Dropdown. | Mittel |
Erweiterungsideen: Collector Idle Bonus Scraping (Audit 2026-03-20)
| Item | Beschreibung | Priorität |
|---|
| E2: Adaptive Bonus-Limits | Bonus-Limit dynamisch an die verfügbare Collector-Kapazität anpassen statt festes max_daily_jobs. Basierend auf historischer Completion-Rate, Tageszeit und aktiver Collector-Anzahl automatisch hochfahren wenn Kapazität vorhanden ist. | Mittel |
| E4: Smart Bonus-Priorisierung | Profile mit höherem "Wert" (mehr Watcher, schnelleres Wachstum, PRO-Profile) bei Bonus-Scrapes bevorzugen. Aktuell wird nur nach Bucket-Proximity und Follower-Count sortiert. Erfordert einen Scoring-Algorithmus für Bonus-Priorität. | Mittel |
| E6: Bonus-Scraping für TikTok | TikTok-Plattform in das Bonus-Scraping-System integrieren sobald TikTok-Scraping über Collector-Jobs läuft. Erfordert TikTok-spezifische Rotation-Konfiguration und Idle-Detection. | Niedrig |
| E7: Cross-Platform Bonus-Budget-Sharing | Intelligente Verteilung des Bonus-Budgets zwischen Instagram und YouTube basierend auf verbleibender Kapazität und Quota. Aktuell teilen sich beide ein globales max_daily_jobs Limit — dedizierte per-Platform-Budgets könnten effizienter sein. | Niedrig |
| E8: Bonus-Scrape-History & Reporting | Historische Daten über Bonus-Scraping-Aktivität speichern (täglich: dispatched, completed, failed, quota_used). Ermöglicht Trend-Analyse und Optimierung der Konfiguration über Zeit. | Niedrig |
Erweiterungsideen: Collector API Fail-Statistik & Token-Schutz (Audit 2026-03-20)
| Item | Beschreibung | Priorität |
|---|
| E5: Per-Collector Tageslimit | Maximal X Jobs pro Token pro Tag. Wenn ein Token sein Limit erreicht hat, bekommt er keine neuen Jobs. Nützlich um Last gleichmäßig auf Collectors zu verteilen. Erfordert täglichen Counter pro Client und Konfiguration in config/collector.php. | Mittel |
| E7: Webhook-Alarme | Neben E-Mail auch Webhook-Support (z.B. Slack, Discord, Telegram) für CRITICAL-Alarme. Config-basiert mit URL + Secret. Erfordert CollectorTokenWebhookAlarm-Notification und Config-Einträge für Webhook-URLs. | Mittel |
| E8: Geo-basierte Fehler-Analyse | Wenn Collectors in verschiedenen Regionen laufen: Erkennung ob bestimmte Regionen mehr Fehler haben (z.B. IP-Range-Blocking durch Instagram). Erfordert GeoIP-Zuordnung der Collector-Clients und regionale Fehlerrate-Aggregation. | Niedrig |
| E9: Dashboard-Widget für Fehler-Trends | Live-Widget auf der Admin-Startseite das die Top-3-Fehler der letzten Stunde zeigt mit Trend-Pfeil (↑ steigend, → stabil, ↓ sinkend). Erfordert Vergleich aktueller Stunde vs. vorherige Stunde aus Cache-Countern. | Niedrig |
Erweiterungsideen: Instagram Post Tracking (Plan 39, 2026-03-22)
| Item | Beschreibung | Priorität |
|---|
| Carousel-Slide-Metriken | Wenn Instagram jemals Engagement pro Carousel-Slide liefert (Likes/Comments pro einzelnem Slide), könnte man diese granularer tracken. Erfordert Erweiterung der instagram_post_metrics Tabelle um Slide-Index und separate Metriken pro Slide. Aktuell liefert der Collector nur aggregierte Werte pro Post. | Niedrig |
Erweiterungsideen: PHPStan Baseline-Reduktion (Audit 2026-03-24)
| Item | Beschreibung | Priorität |
|---|
| Weitere Baseline-Reduktion (~3693 Fehler) | Die verbleibenden ~3693 Baseline-Fehler enthalten viele wiederkehrende Patterns (Cannot cast mixed to int/string, Cannot access property on mixed). Die meisten erfordern tiefere Refactorings (typed DTOs statt arrays, generische Model-Methoden) die über reine Annotations hinausgehen. Opportunistisch bei ohnehin angefassten Dateien abbauen. | Mittel |
| Rector-resistente Annotations | Für künftige PHPStan-Arbeit assert() oder @phpstan-var statt @var verwenden, da Rector @var-Annotations aggressiv als redundant entfernt. Pattern: assert($x instanceof Foo) inline oder /** @phpstan-var Type $var */ statt /** @var Type $var */. In CLAUDE.md oder docs-agents/ als Best Practice dokumentieren. | Mittel |
Erweiterungsideen: YouTube PRO Auto-Activation (Audit 2026-03-28)
| Item | Beschreibung | Prioritaet |
|---|
| Admin-UI fuer Auto-Aktivierungen | Uebersicht aller automatisch aktivierten PRO-Profile mit Datum, Follower-Stand, Sync-Status und Related-Channel-Status. Zeigt wann/warum ein Profil automatisch PRO wurde. | Mittel |
| pro_auto_disabled Flag | Manuelles "Nie automatisch PRO aktivieren"-Flag pro Profil, damit Admins einzelne Profile dauerhaft von der Auto-Aktivierung ausschliessen koennen. Nuetzlich wenn ein Profil aus bestimmten Gruenden nicht PRO sein soll (z.B. Spam, Content-Policy). | Niedrig |
| Threshold-Stufen / Mehrstufiges PRO | Verschiedene Schwellen fuer verschiedene PRO-Level (z.B. 100K = Light-PRO mit 50 Videos, 1M = Full-PRO mit 1000 Videos). Erfordert Erweiterung des PRO-Modells und der Video-Sync-Logik. | Niedrig |
| Score-basierte Aktivierung | Zusaetzlich zum Follower-Threshold auch den Postbox-Score als Kriterium nutzen (analog zu Tinker-Variante A). Profile mit hohem Score aber weniger Followern koennten ebenfalls PRO erhalten. | Niedrig |
| Admin-Benachrichtigung bei Aktivierung | Admin-Toast oder E-Mail wenn neue Profile automatisch aktiviert wurden, damit Admins die Aktivierungen im Blick behalten. | Niedrig |
| Item | Beschreibung | Prioritaet |
|---|
| Retry-Limit pro Query (max 3) | Max 3 Retries pro Query, danach permanent als "Nicht loesbar" markieren. Erfordert retry_count Counter auf youtube_research_queries Tabelle. Verhindert endlose Retry-Schleifen bei dauerhaft fehlschlagenden Queries. | Mittel |
| Automatischer Retry nach Quota-Reset | Job der genau zum YouTube-Quota-Reset-Zeitpunkt (Mitternacht PT + 5 Min) dispatcht wird und alle offenen Failed-Queries automatisch wiederholt. Nutzt YouTubeQuotaGuard::secondsUntilQuotaReset() fuer praezises Timing. | Mittel |
| Retry-History | Neue Tabelle youtube_research_query_retries mit Timestamp + Fehler pro Versuch. Ermoeglicht Analyse welche Keywords/Topics systematisch fehlschlagen und warum. | Niedrig |
| Smart Retry Scheduling | Nur retrien wenn genuegend Quota fuer den gesamten Batch vorhanden ist (geschaetzt: 1 Unit pro Keyword × 10 Seiten). Verhindert Partial-Retries die erneut mid-batch abbrechen. | Niedrig |
| Bulk-Delete fuer fehlgeschlagene Queries | Button um alle fehlgeschlagenen Queries eines Batches endgueltig zu entfernen. Nuetzlich fuer Cleanup nach bekannten API-Ausfaellen wo die Ergebnisse nicht mehr relevant sind. | Niedrig |
Erweiterungsideen: Storage-Migration R2 → Hetzner (Plan 51, 2026-03-30)
| Item | Beschreibung | Prioritaet |
|---|
| Auto Image-Backup (E2) | Automatisches Backup der Bilder via Hetzner-Mechanismus einrichten. Hetzner Object Storage bietet keine native Replikation — muesste ueber rclone Cronjob oder Hetzner Snapshot-Feature geloest werden. | Mittel |
| Multi-Region Hetzner (E10) | Object Storage in zweiter Hetzner-Region (z.B. NBG1 Nuernberg) fuer Redundanz. Erfordert Cross-Region-Sync und ggf. GeoDNS fuer Routing. Aktuell bewusst auf FSN1 Single-Region beschraenkt. | Niedrig |
Erweiterungsideen: AI-Enhancer Queue System (Audit 2026-04-01)
| Item | Beschreibung | Prioritaet |
|---|
| JSONB-Indexes auf ai_detection_logs | Indexes auf output_data->>'language', output_data->>'country', output_data->>'category_confidence' fuer die Admin-AI-Enhancements-Seite. Die Filter-Queries scannen aktuell die volle Tabelle ohne Index. Mit Cache (1h) entschaerft, aber bei wachsender Tabelle trotzdem sinnvoll. | Mittel |
| ConsolidateTagChunk auf ai-detection Queue | ConsolidateTagChunk nutzt die Default-Queue statt der dedizierten ai-detection Queue. Sollte $this->onQueue('ai-detection') im Constructor setzen, analog zu den anderen 3 Gemini-Jobs. | Mittel |
| ConsolidateTagChunk ShouldBeUnique | ConsolidateTagChunk implementiert ShouldBeUnique nicht — doppelte Dispatches koennen doppelte Tag-Merges ausfuehren. Braucht ShouldBeUnique, uniqueId() (basierend auf $batchId) und uniqueFor(). | Mittel |
| Correlated Subquery in DetectChannelLanguages | DetectChannelLanguages::queueProfiles() Zeile 140-143 nutzt correlated Subquery (SELECT MAX(date) FROM social_profile_daily_metrics WHERE ...) im LEFT JOIN. Durch limit() begrenzt und aktuell kein Problem, aber bei wachsenden Tabellen koennte ein DISTINCT ON-basierter Subquery effizienter sein. | Niedrig |
Erweiterungsideen: Plan 55 — Public YouTube Publishing Analytics (Audit 2026-04-19)
Erstrelease ist komplett ausgeliefert (/de/tools/youtube-publishing-analytics). Folgende Erweiterungen wurden bewusst zurueckgestellt und koennen iterativ nachgezogen werden:
| Idee | Beschreibung | Prioritaet |
|---|
| Personalisierte Empfehlung | Fuer eingeloggte User: "Basierend auf deiner Channel-Kategorie empfehlen wir Dienstag 14:00." Blendet einen weiteren KPI-Card-Slot ein. | Mittel |
| Download als PDF/PNG | Charts + Heatmap clientseitig als PNG/PDF exportieren (html2canvas + jsPDF). Deep-Link in Tweets/LinkedIn Posts. | Niedrig |
| Eigener Channel-Overlay | Overlay eines ausgewaehlten eigenen Channels ueber die aggregierte Heatmap — "wie performt dein Zeitplan gegen den Durchschnitt?". | Mittel |
| Instagram Publishing Analytics | Gleiche Analyse fuer Instagram-Posts (abhaengig von Plan 41 Daten-Backbone). | Niedrig |
| API-Endpoint | RESTful API fuer Dritttools (Creator-Tools, Zapier-Integration), rate-limited via Sanctum. | Niedrig |
| Embed-Widget | Kompakte <iframe>-Version der Heatmap fuer Blogs / YouTube-Beschreibungen. | Niedrig |
| Heatmap-Spalten als ApexCharts Heatmap | Aktuell Table-basierte Heatmap (Memory-Gruende in Admin). Public-Seite koennte auf ApexCharts heatmap-Type wechseln, wenn Performance-Budget passt. | Niedrig |
| VFR / Engagement pro Shorts-Modus | Aktuell filtert der Shorts-Toggle nur die Videozahl-Charts; VFR/Engagement zeigen weiterhin "Alle". Separate Aggregationen pro Modus im Command persistieren, dann filterbar ausliefern. | Mittel |
RustFS Storage Monitoring — Prometheus/OTel-Metriken (2026-04-23) ERLEDIGT
Geloest am 2026-04-23: OTel Collector auf dem Server installiert, stellt RustFS-Metriken als Prometheus-Text unter https://console.cdn.postbox.so/metrics bereit. Alle Metriken (Storage, Requests, Latenz, Traffic, Prozess, Disk) werden jetzt alle 15 Minuten gescraped und im Dashboard angezeigt. Nativer RustFS-Prometheus-Endpoint (/minio/v2/metrics/cluster) weiterhin nicht funktional — der Workaround ueber OTel Collector funktioniert stabil.
Verbleibende Erweiterungsideen:
| Item | Beschreibung | Prioritaet |
|---|
| Error-Count Metrik | RustFS exportiert aktuell keine Error-Count-Metrik ueber OTel. Spalte error_count in DB existiert, wird aber nicht befuellt. Pruefen ob zukuenftige RustFS-Versionen dies liefern. | Niedrig |
| Nativer Prometheus-Endpoint | Wenn RustFS /minio/v2/metrics/cluster funktional macht, koennte der OTel-Collector-Umweg entfallen. Bearer-Auth bleibt ein bekannter Bug (Issue #1228). | Niedrig |
| Storage-Forecast | Lineare Regression fuer Storage-Wachstumsprognose (wie beim R2-Dashboard). Datengrundlage jetzt vorhanden, Feature kann nachgezogen werden. | Mittel |
Plan 61 wurde mit allen Findings (F1–F14) und User-bestaetigten Erweiterungen (E2 Sitemap-Priority, E3 BreadcrumbList, E4 SoftwareApplication, E5 FAQ-Coverage) umgesetzt. Folgende Ideen wurden in die Tech-Debt verschoben:
| Item | Beschreibung | Prioritaet |
|---|
| SEO Audit-Command (E1) | php artisan seo:audit checkt Meta-Tags, JSON-LD, Sitemap-URLs auf 200-Response, Dublin-Core-Vollstaendigkeit. Baut auf bestehenden Sitemap-Validierungen auf. Schreibt Report nach storage/app/seo-audit/{date}.json, Notification an Admin bei >0 Issues. | Niedrig |
| Speakable-Schema (E6) | Speakable-Schema (Schema.org) fuer Voice-Search auf Profile- und CMS-Pages. Definiert ueber CSS-Selectors welche Text-Bloecke vorgelesen werden koennen. Aktuell minimaler Mehrwert, da Voice-Search bei Postbox kaum Conversion bringt. | Niedrig |
hreflang x-default Strategie (F12) | Aktuell zeigt x-default immer auf /de/. Bei Internationalisierung (US-Markt) auf /en/ oder neutrale Landing-Page umstellen. | Niedrig |
| Search Console API aktivieren (F14) | SearchConsoleService existiert, aber enabled=false als Default. Bei Aktivierung: Indexing-Status pro Page, Performance-Daten (Klicks, Impressions, Position) im Admin-Dashboard. Voraussetzung: Service-Account-Setup + verifizierte Site. | Mittel |
| OG-Image-Aktivierung Production | Im Code bereits funktional, nur Server-seitiger Schalter (OG_IMAGES_ENABLED=true in Production-Env) + Initial-Backfill via php artisan og-images:generate --type=all. Voraussetzung: Browsershot/Chromium auf dem Server. | Hoch |
Erweiterungsideen: Plan 56 v2 — Intelligente Video-Stats-Tiers (Audit 2026-04-28)
Plan 56 v2 wurde mit allen 11 Phasen umgesetzt. Folgende optionale Items wurden in die Tech-Debt verschoben:
| Item | Beschreibung | Prioritaet |
|---|
| LastUploadCheck / Reactivation-Pfad (Phase 5.1) | Kein YouTubeReactivationCheck Command fuer paused-Profile. Paused-Profile werden erst beim naechsten reevaluate-stats-tier Run (alle 14 Tage) re-evaluiert, nicht proaktiv per channels.list-Check. Spart Quota, aber langsamere Reaktivierung. | Niedrig |
| CSV-Export Coverage-Trends (Phase 11.4) | Plan erwaehnt CSV-Export der Snapshot-Rows im CoverageTrends-Dashboard. Nicht implementiert. | Niedrig |
--from Flag SnapshotCoverage (Phase 11.2) | Optionales --from=YYYY-MM-DD Flag fuer historische Backfills. Nicht implementiert. | Niedrig |
| Bulk-Update statt Einzel-Saves | ReevaluateVideoStatsTier::persistDecision() macht pro Profil ein save(). Bei 10K+ Aenderungen pro Run waere ein CASE WHEN-Bulk-Update performanter. | Mittel |
Prune-Policy extended_stats_tier_changes | Plan erwaehnt Rows aelter als 365 Tage einmal pro Monat entfernen. Kein Prune-Command existiert. Bei ~40 MB/Jahr nicht dringend. | Niedrig |
| Admin-Mail woechentliche Zusammenfassung | Config-Key YOUTUBE_STATS_NOTIFY_EMAIL ist da, aber kein Mailer fuer woechentliche Tier-Verteilungs-Zusammenfassung implementiert. | Niedrig |
isDowngradeFrom() ungenutzt | VideoStatsTier::isDowngradeFrom() ist getestet aber nirgends im Listener konsumiert. Aktuell feuert Notification bei jeder Aenderung — koennte auf Downgrades beschraenkt werden (Listener-Filter). | Niedrig |
| Workspace-Members in Notifications | HandleVideoStatsTierChange benachrichtigt nur workspaces.owner_id, ignoriert Workspace-Members. Wenn Multi-User-Workspaces (Plan 26) aktiv werden, muss der JOIN auf workspace_members ergaenzt werden. | Niedrig |
| Lock-Toggle Audit-Eintrag | VideoStatsTierManagement::toggleLock() und forceReview() schreiben keinen Audit-Eintrag in extended_stats_tier_changes. Forensisch suboptimal — separater Audit-Trail fuer Lock-Aenderungen waere nice-to-have. | Niedrig |
videoStatsActive Scope-Konsolidierung | Der Scope SocialProfile::videoStatsActive ist definiert, aber wird nirgends genutzt. Tier-Filter im Sync-Command verwendet stattdessen direktes whereIn(...). Cleanup: Scope verwenden oder loeschen. | Niedrig |
Erweiterungsideen: Charts-Migration Flux→ApexCharts (Audit 2026-04-29)
| Item | Beschreibung | Prioritaet |
|---|
| Chart-Annotations fuer wichtige Events (E2) | ApexCharts unterstuetzt annotations.points und annotations.xaxis — koennte z.B. "Profil hinzugefuegt", "Score-Neuberechnung" oder "Sanitizer-Block" als markierte Punkte auf Watcher-Charts anzeigen. Aktuell nicht implementiert. | Niedrig |
| Vergleichs-Overlay: 2 Watcher in einem Chart (E3) | Aktuell zeigen Watcher-Detail-Seite und Public Explorer nur einen Watcher pro Chart. Future: zweiten Watcher als Overlay-Series einblenden, um Wachstumsverlaeufe direkt zu vergleichen. | Niedrig |
| Persistierte Range-Auswahl pro User (E4) | Smart-Range setzt aktuell pro Component-Instanz auf 30d zurueck. Future: letzte Range-Wahl in user_preferences speichern, damit User beim erneuten Aufruf direkt die zuletzt genutzte Range sehen. | Niedrig |
Synchronisierte Charts via chart.group (E5) | ApexCharts chart.group synchronisiert Hover/Zoom zwischen mehreren Charts. Z.B. auf Watcher-Detail wuerde Hover ueber ScoreChart automatisch den Cursor auf VideoScoreChart highlighten. Verbessert Multi-Chart-UX. | Niedrig |
| ApexCharts 5.x Breaking-Change-Audit | Migration von 3.49 (CDN) auf 5.x (Vite-Bundle) gemacht. Manche Optionen koennten subtle Verhaltensaenderungen haben — z.B. Tooltip-Format, Y-Axis-Auto-Scaling. Pruefen sobald QA gelaufen ist. | Niedrig |
Erweiterungsideen: Livewire v4 Modernisierung (Audit 2026-04-29)
| Item | Beschreibung | Prioritaet |
|---|
| Async Bulk-Actions (E5) | Admin-Bulk-Tier-Updates (VideoStatsTierManagement) koennten mit Livewire v4 #[Async]-Attribut parallel statt sequentiell ausgefuehrt werden. Reduziert Wartezeit bei >100 Profil-Updates. Voraussetzung: #[Async] Feature muss in der verwendeten Livewire-Version stabil sein. | Mittel |
#[Lazy] fuer Admin-Chart-Sub-Components | In Plan 69 versuchsweise auf 5 Components angewendet, dann zurueckgenommen weil bestehende Tests das Initial-HTML pruefen (Lazy zeigt nur Placeholder). Sinnvoll bei zukuenftiger Watcher-Detail-Refactoring: extrahiere schwere Sub-Sektionen als eigene Components mit #[Lazy], schreibe Tests die __lazyLoad aufrufen. | Niedrig |
| Islands fuer Dashboard | Livewire v4 Islands (@island-Direktive) sind in v4.2.4 experimentell vorhanden. Wenn offiziell dokumentiert und stabil, koennten Dashboard-Sektionen (Chart, Winners, Losers) als isolierte Update-Regionen definiert werden — nur geaenderte Sektionen re-rendern bei Filter-Wechsel. | Niedrig |
.renderless fuer Toggle-Aktionen | Toggle-Actions (toggleLock, toggleBlock, toggleShort) koennten mit wire:click.renderless ausgefuehrt werden — Server-State aendert sich ohne DOM-Diff. Voraussetzung: Alpine-basierte optimistische UI-Updates pro Toggle. | Niedrig |
| wire:sort nativer Ersatz | wire:sort ist in Livewire v4.2.4 als leeres Feature-Directory vorhanden (SupportWireSort). Wenn implementiert, koennte die Alpine-basierte Source-Reorder-Logik (Plan 69/E1) durch natives wire:sort ersetzt werden. | Niedrig |
Erweiterungsideen: Plan 77 Page-Cache-Warming (Plan 2026-05-02)
Verworfen / verschoben aus Plan 77 (Public-Pages-Cache-Warming für SEO):
| Item | Beschreibung | Priorität |
|---|
| PageCachePartitionService (Multi-DB-Redis) | Eigene Redis-DB für Page-Cache mit getrenntem maxmemory. Vorteil: Page-Cache-Eviction kann nie Application-Cache (Sessions, App-Caches) treffen. Nachteil: komplexerer Setup, getrennte Connection-Pools, separate Redis-Server-Config. → Wenn Memory-Druck im Single-DB-Setup steigt sinnvoll werden. Aktuell: shared DB mit Soft-Cap reicht. | Niedrig |
| Brotli-Compression vor Redis-Speicherung | Brotli erreicht 30-40% bessere Kompression als gzip bei text-lastigem Content (HTML). → Wenn Page-Cache > 90% Budget regelmäßig erreicht und 8 GB Redis-Total nicht erweiterbar ist. Aktuell: gzip im HTTP-Response-Layer reicht; Page-Cache speichert minified HTML ohne zusätzliche Compression. | Niedrig |
| Cloudflare Edge-Cache | Page-Cache-Hits zusätzlich am CDN-Edge zwischenspeichern via Cache-Control: public, max-age Header. Würde Bot-Traffic vor Postbox-Server abfangen. → Verworfen wegen Pflicht zu kostenpflichtigen Cloudflare-Diensten. | Verworfen |
Erweiterungsideen: Heutige Session (Audit 2026-05-04)
Nicht umgesetzte Vorschläge aus den heutigen Bug-Hunts:
| Item | Beschreibung | Priorität |
|---|
| YouTube Per-Video New-Video-Boost | Aktuell snappen wir Per-Video-Stats für FULL-Tier nur 1×/Tag. Bei neu veröffentlichten Videos wäre die wichtigste View-Kurve in den ersten 24h. Vorschlag: für Videos published_at < 48h (Full+Standard) zusätzliche Snapshots im 4-6h-Takt (1h, 4h, 12h, 24h, 48h). Quota-Aufwand minimal (~5 zusätzliche videos.list-Calls/Profil). Dafür muss aber das Storage-Schema umgestellt werden — youtube_video_daily_metrics hat aktuell unique(video_id, date), also nur 1 Row pro Tag pro Video. Migration nötig auf (video_id, snapped_at) oder neue Intra-Day-Tabelle. 2026-05-04 vom User explizit abgelehnt ("wir bleiben bei dem wie es jetzt ist") — als Notiz für späteres Audit. | Niedrig (vom User verworfen) |
| OG-Images Failed-Counter Auto-Alert | Mit dem heutigen Background-Dispatch-Refactor sehen wir jetzt Pending/Erfolgreich/Fehlgeschlagen-Counter in der UI. Nächster Schritt: bei Failed-Counter > N pro Stunde automatisch Admin-Notification. Aktuell: User soll nach Deploy selbst beobachten. | Mittel |
| Hourly-Rollup für Redis-History-Charts | server_metrics_hourly (1-Jahr-Retention) wurde NICHT um die heute hinzugefügten Redis-Spalten erweitert. Auswirkung: Range-Selector auf /admin/server zeigt Redis-Daten nur für 1h-30d (Rohwerte aus server_metrics, 90-Tage-Retention). Wenn User später 365d-Range will: ServerRollupHourly-Command analog erweitern + Migration für server_metrics_hourly Spalten. | Niedrig |
| CORS-Retry im profile-image onerror | Heute auf direkten Placeholder-Fallback vereinfacht (vorher 2-stufiges crossorigin-Retry → Placeholder). Falls echte CORS-Probleme bei R2-Bildern auftauchen, könnte man den Retry-Pfad zurückbringen — aber dann sauber statt mit dem flaky this.src=this.src-Trick. | Niedrig |
Frontend __() JS-Helper | Bei der Extension-Filter-Diskussion kam auf: wir nutzen Blade-__() server-side für Übersetzungen, aber haben kein JS-Pendant. Bei dynamisch generierten Texten (z.B. JS-Toast-Meldungen aus Alpine) müssen Übersetzungen per @js(__('...')) durchgeschleift werden. Sauberer wäre ein globales window.__() aus einem lang/de.json-Bundle. → Geringe Priorität, aktuell keine User-facing Probleme. | Niedrig |
Erweiterungsideen: Production-Bug-Hunts (Audit 2026-05-08)
Nicht umgesetzte Erweiterungen aus den heutigen Production-Fixes:
| Item | Beschreibung | Priorität |
|---|
video_stats_tier_changed Per-User-Batch-Notification | Heute behoben: Listener HandleVideoStatsTierChange setzte kein title/body/url → 2.379 generische "Benachrichtigung"-Einträge bei einem Scheduler-Batch. Throttle ist 14d pro Profil, nicht pro User — wenn ein User-Workspace viele Watcher mit überlappenden Profilen hat, kann ein Tier-Rebuild trotzdem hunderte Notifications auslösen. Erweiterung: BatchTierNotification-Job, der pro User in einem 5-Min-Fenster alle Tier-Aenderungen sammelt und EINE Sammel-Notification mit Liste der betroffenen Profile schickt (statt N einzelne). Reduziert Inbox-Spam massiv ohne Throttle-Aufweichung. Trigger via CarbonInterval::minutes(5)->floorMinutes() Buckets oder Redis Sorted-Set mit users:tier-pending:{userId}. | Mittel |
YouTube videos.list Batch-Restricted-Filter | Heute behoben: FetchNewYouTubeVideo (Single-Video) catched HTTP 403 mit myRating-Message als "not accessible". SyncYouTubeVideoStats (Batch mit bis zu 50 Video-IDs, parts=statistics) wurde NICHT angefasst, weil dort der Failure-Mode bisher nicht beobachtet wurde. Falls der Bug dort auch auftritt (ein restricted Video würde den ganzen Batch killen), den gleichen Catch-Handler übertragen + Retry des Batches ohne die problematische ID. Aktuell: Beobachten. | Niedrig |
| Tier-aware ExploreTrending-Datenqualitäts-Schwelle | Heute behoben: Schwelle für 24h-Growth-Coverage von 30% auf 3% gesenkt, da Plan-75 tier-basiertes Syncing einführte. 3% ist eine grobe Untergrenze ("Sync-Pipeline ist down") — präziser wäre eine Tier-Breakdown-aware Schwelle: aus tier_full_count + tier_standard_count (die heute syncen sollten) berechnen wieviele Snapshots erwartet werden, und mit with_growth_24h vergleichen. So würde die Warning auch dann feuern, wenn nur ein Tier-Bucket ausfällt (z.B. nur Standard-Profile syncen nicht). Voraussetzung: aggregator-side Verfügbarkeit der tier-Counts via YouTubeVideoStatsDailyAggregation. | Niedrig |
profiles:backfill-rotation-buckets Schedule | Heute behoben: SocialProfile::booted() setzt rotation_bucket beim creating-Event. Falls jemals Mass-Inserts via DB::table('social_profiles')->insert(...) (Bypass des Eloquent-Events) hinzukommen, würden NULL-Buckets wieder accumulieren. Defense-in-Depth wäre Schedule::command('profiles:backfill-rotation-buckets')->daily(). Aktuell überflüssig, da der Boot-Hook alle bekannten Create-Pfade abdeckt. | Niedrig |
| Tier-Sync-Lastverteilung über Buckets | Beobachtung: alle Standard-Tier-Profile syncen am gleichen Tag (cycle=2) statt verteilt über die 2 Tage. Das spike't Quota-Verbrauch und Queue-Last. Erweiterung: Tier-Skip mit rotation_bucket-Modulo kombinieren — z.B. Bucket 0 syncn an Tag X, Bucket 1 an X+1, alle 2 Tage rotieren. Komplexer Eingriff in SyncYouTubeVideoStats::handle(), betrifft Migration der last_sync_at-Semantik. Quota-Spike ist aktuell handlebar, also nice-to-have. | Niedrig |
youtube:aggregate-video-stats-tracking Root-Cause-Audit | Heute behoben: Diagnose-Output verbessert (Exception-Klasse, FAIL_SUMMARY-Zeile, appendOutputTo()). Eigentliche Ursache des deterministischen exit code 1 über mehrere Tage ist noch nicht identifiziert — die nächsten Forge-Logs nach Deploy zeigen sie. Wenn Stack-Trace bekannt ist: spezifischen Fix nachziehen + Test-Case ergänzen. | Hoch (sobald Logs da) |
| Frontend Promise-Reject-Convention | Mehrere Stellen werfen Promise.reject({error: 'foo'}) mit Plain-Objects statt new Error('foo'). Dadurch verlieren wir den Stack-Trace im unhandledrejection-Handler. Heute via extractRejectionMessage() JSON-Stringify als Fallback eingebaut, aber die eigentlichen Reject-Quellen sollten auf Error-Instanzen umgestellt werden. Audit nötig: grep -rn "Promise.reject|reject(" resources/js public/. | Niedrig |
Erweiterungsideen: /admin/youtube Coverage-Chart-Anomalie diagnostizieren (Audit 2026-05-25)
Userreport vom 25.05.: das Coverage-Chart auf /admin/youtube zeigt eine alternierende 95%/5%-Pattern (mit unregelmässigem Abstand: 04.05 → 07.05 → 09.05, also 3-3-2 Tage), während die Tier-Verteilung 100% Light suggeriert. Mathematisch passt das nicht zusammen: Light-Tier hat intervalDays=7, sollte also ~14% pro Tag liefern.
Mögliche Wurzel-Ursachen (noch nicht verifiziert):
- Aggregator-Timeout-Artefakt: Die Aggregator-Fails durch
calculateReasons-Timeout (gefixt mit 7832e2e) haben in den vorhergehenden Tagen partiell aggregierte Daten geschrieben. Manche Spalten (z.B. tier_*_count) sind möglicherweise stale, andere (z.B. videos_with_metrics) korrekt. Wahrscheinlichste Ursache, sollte sich nach Deploy von 7832e2e über 7-14 Tage selbst-heilen.
tier_*_count falsch: Die calculateTierBreakdown-Funktion zählt zwar extended_stats_tier, aber wenn der ReevaluateVideoStatsTier-Cron stale ist, könnten Profile veraltete Tier-Werte tragen. Realität vs Anzeige diskrepant.profiles_synced falsch: videos_with_metrics zeigt 343K auf 09.05, aber Tier=2.0% impliziert nur ~9K Profile (343K / 9K = 38 Videos/Profil — passt nicht zu Light-Tier top_limit=5).
Geplantes Vorgehen:
| Item | Beschreibung | Priorität |
|---|
Diagnostic-Command youtube:diagnose-coverage --date=YYYY-MM-DD | Rohe Production-Daten auslesen: tatsaechliche Tier-Verteilung in social_profiles.extended_stats_tier, Verteilung von youtube_video_syncs.last_sync_at per Tier, Distribution der bucket = crc32(external_id) % 7 Werte, Anzahl Profile mit auto_sync_enabled=true + last_sync_at IS NULL. Output als Tabelle für Admin-Diagnose. Aufwand: ~2h. | Mittel |
ReevaluateVideoStatsTier-Run-Frequency erhoehen | Aktuell dailyAt($reviewTime) — koennte zu langsam sein wenn AutoActivatePro alle 24h neue PRO-Profile anlegt, die einen Tag lang tier=null (unclassified) bleiben. Eventuell stuendlich laufen oder nach AutoActivatePro chained. | Niedrig (nach Diagnose) |
Selbst-Healing nach 7832e2e-Deploy verifizieren | 7-14 Tage warten, dann das /admin/youtube Chart erneut prüfen. Falls Alternation persistiert, vertieft mit Diagnostic-Command nachgehen. Falls weg, war es Aggregator-Artefakt. | Hoch (passiv) |
Erweiterungsideen: YouTube Disable-Pfade konsolidieren (Audit 2026-05-25)
Userreport "ich habe Profile deaktiviert, die sind nun doch wieder aktiv" zeigte: vier Code-Pfade deaktivieren YouTube-PRO/Auto-Sync mit jeweils ähnlicher, aber leicht divergenter Logik. Drei Pfade waren Plan-67-konform (setzten pro_auto_activation_blocked_at + alle 7 extended_stats-Felder), der vierte (DisableYouTubeVideoAutoSyncController hinter POST /watchers/{id}/youtube-video-auto-sync/disable) hatte die Plan-67-Felder vergessen und der youtube:auto-activate-pro-Cron reaktivierte die Profile.
| Item | Beschreibung | Priorität |
|---|
YouTubeProDisabler-Service | Die 4 Disable-Pfade in einen gemeinsamen Service extrahieren (disable(SocialProfile $profile, string $triggeredBy = 'admin'): void), der die 7 Profile-Felder + YouTubeVideoSync-Update + VideoStatsTierChanged-Event + WebSubManager::unsubscribe atomar macht. Alle 4 Aufrufer (Livewire/Watchers/Show, Livewire/Admin/SocialProfiles/Index, Livewire/Admin/YouTubeManagement/VideoStatsTierManagement, Http/Controllers/Watchers/DisableYouTubeVideoAutoSyncController) delegieren an den Service. Verhindert strukturell zukünftige Divergenz. Aufwand: ~3h Refactor + Tests. | Mittel |
Erweiterungsideen: Vantage + Dashboard (Audit 2026-05-16)
Aus den Production-Bug-Hunts (Plan 78 Phase 4, Plan 79, Plan 81). Plan 80 wurde verworfen, weil Cloudflare die Bot-Filterung auf Edge-Ebene übernimmt.
| Item | Beschreibung | Priorität |
|---|
BuildOwnerDashboardSnapshots Per-Day-Subjob-Split | Aktuell: 1 Job baut bis zu 14 Tage Rollups, 300s Timeout (heute von 120s bumped). Falls auch 300s irgendwann nicht reicht (sehr großer Workspace, mehr Profile, mehr Rollup-Dimensionen): Job in N kleine BuildOwnerDashboardSnapshotsForDate($owner, $date)-Subjobs aufsplitten, Parent dispatcht 14 davon. Skaliert beliebig — bei Timeout fehlt nur 1 Tag. Aufwand: ~2-3h Refactor + Tests. | Niedrig (Reserve) |
Legacy vantage:prune --status=completed-Schedule entfernen | Vantage trackt Successes als status='processed' (nicht completed) — verifiziert in Q8 vom 2026-05-15. Der bestehende vantage:prune --status=completed --hours=24 --force-Schedule um 01:25 UTC lief vermutlich seit Vantage-Install ohne Effekt. Neuer --status=processed-Schedule um 01:27 UTC (Plan 79) macht die echte Arbeit. Der Legacy-Schedule kann ohne Risiko aus routes/console.php entfernt werden. | Niedrig (Cleanup) |
Vantage --status=released-Pruning obsolet | Plan-79-Refactor hat --status=released-Schedule entfernt nach DELETE-Approach. Falls Vantage später eine eigene released-Status-Migration einführt, könnten orphaned released-Rows entstehen — dann Pruning-Schedule re-introduce. Aktuell nicht relevant. | Niedrig (Watchdog) |
Erweiterungsideen: Collector↔API-Vertrag v1.4.0 (Audit 2026-06-01)
Aus der Umsetzung des Collector↔API-Vertrags v1.4.0. Die Kernpunkte (Fail-Routing nach 4 Kategorien, nullable Post-Engagement + views_count, Doku) sind umgesetzt. Folgende Punkte wurden bewusst nicht umgesetzt:
| Item | Beschreibung | Priorität |
|---|
| DailyScrapeProgress-Doppelzählung bei kumulativen Re-Queues | InstagramDailyScrapeProcessor::handleFailure ruft updateDailyScrapeProgress(success:false) bei jedem kumulativen Fehler (parse_error/scrape_error/…) auf — auch wenn der Controller den Job danach erneut einreiht. Beim späteren Retry-Erfolg wird success:true gezählt → derselbe Job erhöht sowohl failed_count als auch completed_count (pre-existing). Session/Transient/tab_closed sind seit v1.4.0 korrekt (Early-Return überspringt Progress). Sauberer Fix erfordert, dass der Processor die Re-Queue-Entscheidung des Controllers kennt (fail_count vs. max_fail_count): entweder handleFailure nach der Entscheidung aufrufen + willPark-Flag übergeben, oder die Progress-Logik in den Controller ziehen. Aufwand: ~2h + Tests. | Niedrig (kosmetisch — nur die „Daily-Scrape fertig"-Benachrichtigung kann leicht verfrüht oder mit inflationiertem failed_count zählen) |
| Harte Schema-Validierung im FormRequest (profile_type-Enum, scrape_quality-Range) | Bewusst lenient gelassen: Der Vertrag empfiehlt defensive Schema-Validierung, aber harte Ablehnung würde einen ganzen Scrape verwerfen. Aktuell: lenient speichern + Enrichment-Clamping (scrape_quality auf [0,1] geklemmt, ungültige Anomalie-Severities verworfen, profile_type as-is gespeichert). Falls künftig ein striktes Vertrags-Gate gewünscht ist (z.B. 422 bei unbekanntem profile_type), in CompleteCollectorJobRequest umsetzen — Trade-off „Datenverlust vs. Strenge" beachten. | Niedrig |
| views_count-Auswertung (IG-Reel-Engagement) | instagram_post_metrics.views_count wird befüllt, sobald der Collector es liefert, aber noch nicht ausgewertet. Bei Umsetzung der IG-Engagement-Analytics (Plans 41–43): per-View-Engagement für Reels (analog YouTube), per-Follower für Feed — und dabei die nullable Engagement-Spalten korrekt behandeln (NULL = unbekannt, nicht 0; AVG/COALESCE statt roher Arithmetik). | Mittel (mit Plans 41–43) |