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) |
Erweiterungsideen: Plan 85 — Publishing-Analytics Monats-Aggregation (Audit 2026-06-05)
Aus der Archivierung des umgesetzten Plans 85. Der Kern (echte Monats-Aggregation per published_at, drei Modi, percentile_cont, idempotenter laufender Monat) ist umgesetzt. Bewusst nicht umgesetzt:
| Item | Beschreibung | Priorität |
|---|
| Wochengenaue Snapshots | Zusätzlich zu Monats-Snapshots auch Wochen-Snapshots für eine „letzte 4 Wochen"-Ansicht. | Niedrig |
| Materialized View statt Command-Snapshots | Die Command-getriebenen youtube_publishing_monthly_snapshots könnten durch eine PostgreSQL Materialized View ersetzt werden (Refresh-getrieben statt Aggregations-Command). | Niedrig |
| Anomalie-Ausschluss korrupter Kanäle in der Publishing-Aggregation | Mindestens ein Ausreißer-Kanal hat ~644 Tsd. Videos, deren published_at allesamt um 00–01 UTC klumpen — vermutlich wurde beim Import der Import-Zeitstempel statt der echten Veröffentlichungszeit gespeichert (published_at ≈ created_at für den Großteil dieser Videos). In der Heatmap dominiert dieser eine Kanal den „Ø Videos pro Kanal"-Mittelwert und erzeugt einen falschen Nacht-Peak. v2.2.6 mildert das nur für die Default-Ansicht (Umschalter-Default „Regulär" — Shorts sind der Haupttreiber); die Shorts- und Alle-Ansicht bleiben verzerrt. Offen: (1) den Import-/Sync-Pfad finden und fixen, der published_at mit dem Import-Zeitpunkt überschreibt (Datenkorrektur für betroffene Videos); (2) generischer Anomalie-Ausschluss in der Aggregation (AggregateYouTubePublishingStats) — Kanäle mit absurder Video-Zahl bzw. extrem geklumpter Upload-Verteilung aus dem Mittelwert ausschließen, sodass auch Shorts/Alle ein echtes Muster zeigen. Vom User explizit als nächstes Projekt vorgesehen (2026-06-18). | Mittel |
Erweiterungsideen: Datenqualitäts-Check (Audit 2026-06-18)
| Item | Beschreibung | Priorität |
|---|
| Per-Profil-Cutoff im PRO-Video-Metrics-Check | DataQualityStatus::proVideoMetricsHealth() zählt getrackte Videos je Profil mit dem global frühesten Cutoff (eine GROUP-BY-Query statt 300–400 Einzelqueries), nicht mit dem jeweils eigenen video_tracking_start_date. Profile mit deutlich späterem Tracking-Start können dadurch Videos im Fenster [earliestCutoff, eigener Cutoff] mitgezählt bekommen, die der Sync gar nicht abdeckt → potenzielle (Schein-)Lücken. Das min(.., pro_max_videos)-Cap fängt High-Volume-Profile ab, Low-Volume-Profile mit spätem Start nicht. Saubere Lösung: per-Profil-Cutoff in den Count-Queries respektieren (z. B. Join gegen eine VALUES (id, cutoff)-Liste in PostgreSQL) — architektur-relevant, daher bewusst vertagt, bis Rest-Lücken im Tab tatsächlich auftreten. | Niedrig |
Erweiterungsideen: Plan 75 — YouTube-Aggregator Tier-Awareness (Audit 2026-06-05)
Aus der Archivierung des umgesetzten Plans 75. Der Kern (Tier-Breakdown-Spalten, --backfill-from, Tier-Filter in der Aggregation, Test) ist umgesetzt. Bewusst nicht umgesetzt:
| Item | Beschreibung | Priorität |
|---|
| Stacked-Bar-Tier-Chart | UI-Erweiterung im YouTube-Management-Chart: Stacked-Bar pro Tag mit Tier-Verteilung (standard/light/paused/off/unclassified). Die Datenbasis (tier_*_count-Spalten) liegt vor, nur die Visualisierung fehlt. | Niedrig |
Collector-Extension: CORS via Host-Permission umgehen (2026-06-08)
Der Server-Fix (config/cors.php, paths => ['api/*']) löst den CORS-Preflight-Fehler auf der Collector-API. Die robustere Lösung läge extension-seitig und wurde bewusst zugunsten des Server-Fixes vertagt:
| Item | Beschreibung | Priorität |
|---|
| Extension Host-Permission | In der Collector-Chrome-Extension optional_host_permissions für die API-Origin (https://app.postbox.so/*) deklarieren und via chrome.permissions.request anfordern. Mit Host-Permission macht die Extension Requests ohne CORS-Preflight → CORS entfällt komplett; Server-CORS bleibt als Fallback. (Betrifft das Extension-Repo, nicht dieses.) | Niedrig |
Aus dem umfassenden Review vom 2026-06-10. Umgesetzt wurden: Lease-Backoff-Gate, Keyset-Pagination im Image-Cleanup, lazy OG-Orphan-Scan, Research-N+1, Umlaut-/Label-/Suffix-Fixes, WorkOS-Key-Entfernung — sowie (nach Freigabe am selben Tag) der Lease-Index/Query-Split (collector_jobs_lease_pick_idx). Bewusst nicht umgesetzt:
| Item | Beschreibung | Priorität |
|---|
available_at-Spalte statt created_at-Zweckentfremdung | Der Requeue-Backoff verschiebt created_at in die Zukunft (Sortier- + Gate-Mechanik). Eine eigene available_at-Spalte (wie Laravels jobs-Tabelle) hielte Queue-Age-Metriken ehrlich und machte das Backoff-Gate explizit. Migration + Lease-/Fail-/Monitoring-Anpassung. | Niedrig |
| ApexCharts-Loader-Meldung transliteriert | console.error('[Postbox] ApexCharts nach 5s nicht verfuegbar') in 13 Views — Browser-Konsole, nicht UI-gerendert (Grauzone Regel #2). Bei der nächsten Sammeländerung an den Chart-Views mitziehen (verfügbar). | Niedrig |
Rohes header()+exit für 301-Canonical-Redirect in Livewire-Mount | PublicExplorer/Show::mount() (app/Livewire/PublicExplorer/Show.php:83-84) macht den SEO-301-Redirect auf die kanonische URL über header('Location: …', true, 301); exit;. Das umgeht Laravels Response-Lifecycle (SecurityHeaders-/TrackPageView-Middleware) und ist nicht testbar. Sauberer wäre ein echter 301-RedirectResponse aus dem Mount (Livewire-Full-Page-Redirect mit Status 301) — aber SEO-kritisch, daher mit Redirect-Verhaltens-Test absichern. Vom Arch-Test (tests/Arch/) entdeckt; die/exit sind dort bewusst nicht policed. | Niedrig |
NotificationCenter: Echtzeit-Event-Burst überlief max_calls (Audit 2026-06-11)
Ein einmaliger TooManyCallsException (562 Aufrufe > 100, HTTP 500) auf /admin/update-status wurde durch Anheben von payload.max_calls auf 1000 entschärft (config/livewire.php) — der einzige Hebel, der Aufrufe pro Request begrenzt. Die clientseitige Drossel (safeServerDispatch, max. 40/Burst, Reset nach 2 s Ruhe) begrenzt nur Aufrufe pro Ruhe-Fenster, nicht pro Livewire-Commit. Durable-Hardening, bewusst (noch) nicht umgesetzt (braucht Browser-Verifikation, daher nicht blind am globalen Layout-Component geändert):
| Item | Beschreibung | Priorität |
|---|
| Drossel gegen Rückstands-Akkumulation härten | safeServerDispatch setzt dispatchCount nach 2 s Ruhe auf 0. Staut sich bei stockender/pausierter Verbindung (Tab im Hintergrund) ein Rückstand über mehrere Fenster und flusht Livewire ihn in einem Commit, summieren sich 40+40+… über das Limit. Robuster: ein gleitendes Gesamt-Limit (kein voller Reset, solange ein Commit aussteht) oder die reverb-*-Events clientseitig coalescen, bevor sie an den Server gehen. | Mittel |
| Bulk-Operationen: ein Summen-Broadcast statt N Einzel-Events | Flotten-Operationen (Sanitizer/Reaktivierung über viele Profile) broadcasten pro Profil einen .profile.sanitized/.profile.reactivated-Event → N Server-Dispatches + N Toasts + N Notification-Rows. Ein gebündelter „X Profile betroffen"-Broadcast (wie daily.scrape.completed, das bewusst 1×/Tag/User feuert) würde die Quelle des Bursts beseitigen. | Mittel |
Verwaiste Instagram-Profile + IG/YT-Queue-Asymmetrie (Audit 2026-06-11)
Aus dem Fix „Neue Profile 0 % / Bonus blockiert". Der Status-Service zählt jetzt nur queue-fähige (watcher-verknüpfte, nicht blockierte) Profile — die verwaisten Profile selbst bleiben aber als Datenrest bestehen. Offen:
| Item | Beschreibung | Priorität |
|---|
Verwaiste tracking_enabled-Profile aufräumen | Wird der letzte Watcher eines Profils gelöscht, bleibt tracking_enabled = true ohne watcher_source. Diese Profile werden nie gequeued und liegen dormant in der DB. Option: beim Löschen der letzten watcher_source tracking_enabled = false setzen (zentral, z. B. im WatcherSourceObserver/Delete-Pfad) + ein einmaliges Cleanup-Command für den Bestand. Vorher prüfen, ob ein Profil bewusst „global" getrackt wird (Explore/Leaderboard) — dann nicht deaktivieren. | Mittel |
IG-vs-YT watcher_source-Requirement vereinheitlichen | Instagram queued nur watcher-verknüpfte Profile, YouTube alle tracking_enabled. Das ist eine bewusste, aber inkonsistente Design-Entscheidung. Klären, ob YouTube ebenfalls nur watcher-verknüpfte Profile scrapen soll (spart Quota/Kapazität) oder ob Instagram auf das Watcher-Requirement verzichten soll. Betrifft QueueDailyInstagramScrapes vs. SocialScrapeDailyFollowers + beide Status-Services. | Niedrig |
Laravel-13-Upgrade: zurückgestellte Punkte (Plan 68, 2026-06-11)
Beim Upgrade auf Laravel 13.15 bewusst nicht mitgenommen — jeweils mit Grund, damit nichts „vergessen" wirkt:
| Item | Beschreibung | Priorität |
|---|
serializable_classes auf Allow-List härten | Aktuell true (= Laravel-12-Verhalten) in config/cache.php, env-tunebar via CACHE_SERIALIZABLE_CLASSES. Die L13-Härtung (Schutz gegen PHP-Deserialization-Gadgets bei APP_KEY-Leak) braucht eine vollständige Inventur aller Objekt-cachenden Pfade (Cache::remember mit Objekten, Pulse-Recorder) und dann eine explizite Klassen-Allow-List. Alternativ Cache-Strategie auf Arrays/JSON umstellen (Plan-68-Idee E6). | Mittel |
| Puppeteer 24 → 25 | Puppeteer 25 ist ESM-only (+ executablePath/defaultArgs liefern Promises, Node ≥ 22). Browsershots Bridge (vendor/spatie/browsershot/bin/browser.cjs) ist CommonJS (require('puppeteer')) → Bump bricht die OG-Image-Pipeline. Warten bis spatie/browsershot ESM-Puppeteer unterstützt, dann zusammen bumpen + OG-Tests fahren. Bis dahin: 24.x latest (24.43.1), 0 CVEs. | Niedrig |
| html2canvas-pro 1.6 → 2.0 | v2.0 = „major architecture refactoring" ohne dokumentierte Breaking Changes im Changelog. Genutzt vom Feedback-Widget-Screenshot (resources/js/screenshot-capture.js, lazy-loaded, Browser-only — im Sandbox nicht verifizierbar). Bump nur mit manueller Verifikation des Screenshot-Features nach Deploy. | Niedrig |
| intervention/image v3 → v4 | v4 entfernt read() (→ decode*()) und alle toWebp()/toAvif()/toJpeg()-Methoden (→ encodeUsingFormat()), min. PHP 8.3. Betrifft ProfileImageProcessor (Profilbild-Pipeline, 540k+ Bilder). Eigene Migration mit Variant-Test-Gate (64 Tests vorhanden), nicht als Beifang eines Framework-Upgrades. | Niedrig |
Sec-Fetch-Site-CSRF-Zusatzschutz prüfen | Laravel 13 bringt Request-Origin-Verifikation in PreventRequestForgery mit. Prüfen, ob zusätzliche Konfiguration (z. B. Strict-Modus) für unsere Setups (Cloudflare-Proxy, Livewire-Requests) sinnvoll ist. | Niedrig |
Bugs (während Larastan-Baseline-Marathon entdeckt, 2026-06-14)
| Item | Beschreibung | Priorität |
|---|
YouTubeVideoUrlResolver: Channel-Mismatch-Erkennung ist toter Code | Die exists_other_channel-Logik (Toast „Dieses Video passt nicht zum geöffneten Channel" + Link zum fremden Kanal) hat nie funktioniert. Drei falsche Relations-/Property-Zugriffe sind mit @phpstan-ignore property.notFound maskiert: $existing->socialProfile (korrekt: $existing->profile), Watcher::find(...)?->socialProfile (korrekt: ?->primarySource?->socialProfile), $owningProfile->display_name (existiert nicht — Produkt-Entscheidung nötig: title/handle?). Da die Relationen zur Laufzeit null liefern, bleibt $isChannelMismatch immer false. Fix braucht: korrekte Relationen + display-Entscheidung + Repro-Test + Entfernen der @phpstan-ignore. Achtung: Fix ändert User-facing-Verhalten (Mismatch-Meldung erscheint dann erstmals). | Mittel |
Erweiterungsideen: Tagesdaten-Anomalie-Erkennung (Plan 89 + Plan 91)
Phase 1 (Erkennung auf followers_count + Ausschluss aus Leaderboards/Overview/Charts) ist umgesetzt
(Plan 89). Phase 2 (Plan 91, 2026-06-16): Postbox-Score-Ausschluss, Erkennung vor dem Scoren in der
Pipeline, Per-Video-view_count-Erkennung (youtube_video_daily_metrics) inkl. Video-Score-Ausschluss,
gestrichelte Chart-Entwertung der Aggregierten Video-Performance — alles umgesetzt. Offen geblieben:
| Item | Beschreibung | Priorität |
|---|
Within-Row-Per-Metrik-Erkennung (social_profile_daily_metrics) | Der Profil-Detektor flaggt die GANZE Tageszeile anhand followers_count (deckt Whole-Scrape-Failures ab). Eine isolierte Anomalie nur in view_count/post_count bei intaktem followers_count wird nicht erkannt. (Video-view_count hat seit Plan 91 eine eigene Erkennung auf youtube_video_daily_metrics.) Bei Bedarf je Profil-Metrik separat erkennen (bräuchte ein Flag-Schema je Metrik statt einer Zeilen-Spalte). | Niedrig |
| Explore-Metriken schließen Glitch-Tage nicht aus | CalculateProfileMetricsBatch lädt den Tagesmetrik-Preload ungefiltert; der Postbox-Score filtert ihn intern (Plan 91), die Explore-Wachstumsmetriken (rising star, Growth) im selben Preload jedoch nicht. Bei Bedarf den Preload withoutAnomalies()-filtern (Explore-Datums-Lookups auf fehlende Tage prüfen). | Niedrig |
| Admin-Sichtbarkeit der Anomalien | anomaly_state + social_profile_anomalies (Plan 86) werden noch nicht im Admin-UI dargestellt. Eine Liste „heute geflaggte Glitch-Tage" (Profile + Videos) + manuelles Override (false-positive entflaggen) wäre hilfreich. | Niedrig |
pending im Profil-Chart gestrichelt markieren | Im Profil-Chart (Show.php) wird nur confirmed als Lücke gerendert; pending (jüngster, unbestätigter Tag) wird normal gezeigt. Optional pending visuell als gestrichelten/provisorischen Punkt kennzeichnen (der Aggregat-Video-Chart entwertet seit Plan 91 bereits gestrichelt). | Niedrig |
| Aggregat-Chart: partielle Pro-Video-Exklusion erzeugt Teil-Dips (Audit 2026-06-16) | Die „Aggregierte Video-Performance" bildet SUM(view_count) über withoutAnomalies()-gefilterte Zeilen. Wird an einem Tag nur EIN Teil der Videos geflaggt (kein globaler Sync-Ausfall), bleibt der Tag vorhanden (die ungeflaggten Videos liefern Zeilen), aber die Summe sinkt um den Beitrag der ausgeschlossenen Videos → ein nicht-überbrückter Teil-Dip in der durchgezogenen Linie. Die gestrichelte Überbrückung greift nur, wenn ALLE Videos eines Tages geflaggt/abwesend sind. Robustere Alternative: Anomalien direkt auf der aggregierten Summen-Serie erkennen (analog ScoreChart) statt auf das Hochblubbern der Pro-Video-Flags zu Tages-Lücken zu setzen. In der Praxis selten (Sync-Glitches sind meist global; das Ausschließen eines einzelnen fehlerhaften Video-Tags ist zudem fachlich korrekt), daher niedrige Priorität. | Niedrig |
Erweiterungsideen: Chart-Lifecycle (Plan / 2026-06-15)
| Item | Beschreibung | Priorität |
|---|
Inline-Admin-Charts gegen detached-$refs härten | 10 inline x-data-Chart-Blöcke rufen new ApexCharts(this.$refs.X, …) ohne isConnected-Guard auf — dasselbe „null node"-Muster wie die zentralen Chart-Komponenten. ✅ Erledigt (2026-06-15): Statt jeden Inline-Block einzeln zu härten, kapselt jetzt ein zentraler Render-Guard ApexCharts.prototype.render in apex-helper.js — er bricht ab, wenn this.el kein verbundenes DOM-Element ist, und schluckt asynchrone Render-Rejections. Schützt alle Charts (inline Blade, JS-Module, apexHelper.spline) an einer Stelle, ohne die ~25 Call-Sites anzufassen. | ✅ Erledigt |
Erweiterungsideen: flux:tooltip in Overflow-Containern (2026-06-15)
| Item | Beschreibung | Priorität |
|---|
| Admin-Tabellen-Tooltips auditieren | Commit 21677ce2 ersetzte app-weit native title-Tooltips durch flux:tooltip. In overflow-x-auto/overflow-auto-Tabellen-Wrappern faellt die Floating-UI-Positionierung auf den Viewport-Ursprung (oben links) zurueck. Auf /admin/profile-link-management bereits auf native title zurueckgesetzt; weitere Admin-Listen mit flux:tooltip in Overflow-Containern pruefen (grep flux:tooltip + naheliegendes overflow-). Fuer „vollen Text beim Hover zeigen" ist native title ohnehin passend. | Mittel |
Erweiterungsideen: Automatisches Premium-Tier (Plan 90, 2026-06-15)
Das Premium-Tier (Top-X-%-Profile nach Follower-Anzahl täglich abrufen, je Plattform via .env) ist umgesetzt: premium_tier-Config, PremiumTierService (Perzentil-Schwelle + Min-Floor), Integration in SocialScrapeDailyFollowers + QueueDailyInstagramScrapes (inkl. Schließen der IG-PRO-Priority-Lücke) und Admin-Sichtbarkeit auf /admin/update-status. Folgende Erweiterungsideen wurden bewusst nicht umgesetzt:
| Item | Beschreibung | Priorität |
|---|
E1: YouTube-Daily-Scrape batchen (channels.list, 50 IDs/Call) | Der YouTube-Daily-Scrape verarbeitet Profile seriell (1 API-Call/Profil ≈ 1 Quota-Unit). Der YouTubeDataApiClient hat bereits getChannelsByIds() (max 50 IDs/Call = 1 Unit). Eine Umstellung brächte ~÷50 Quota und deutlich kürzere Laufzeit — relevant, falls POSTBOX_PREMIUM_TIER_YOUTUBE_PERCENT bei großem YT-Universum hoch gewählt wird. Bewusst zurückgestellt: die serielle Methode ist stabil und soll vorerst unverändert bleiben. | Mittel |
| E2: Admin-UI für Schwelle/Anzahl + Tuning | Live-Anzeige (ggf. Slider/Vorschau) der aktuellen Premium-Schwelle und -Anzahl je Plattform direkt im Admin, um den Prozentsatz datenbasiert zu justieren, ohne .env-Deploy. | Niedrig |
| E3: Quota-Guard-Awareness im YouTube-Daily-Scrape | Der YouTube-Daily-Scrape ist nicht durch den YouTubeQuotaGuard (Pre-Flight canMakeCall + Release-on-Exhaustion) geschützt; bei Quota-Erschöpfung fallen Rest-Profile still aus. Unabhängig vom Premium-Tier sinnvoll, durch dieses aber relevanter. | Mittel |
| E4: Dry-Run-/Report-Command „Was wäre das Premium-Set?" | Vor dem Aktivieren/Ändern des Prozentsatzes risikofrei Anzahl, Schwelle und netto-neue Profile je Plattform anzeigen (Impact-Vorschau). | Niedrig |
| E5: Absoluter Follower-Floor als Hybrid-Kriterium | Zusätzlich zum Perzentil ein absoluter „immer täglich ab N Followern"-Schwellwert (max(percentile, floor)), um die ganz großen Accounts unabhängig vom Universum sicher abzudecken. | Niedrig |
| E6: Dynamischer Prozentsatz (Rest-Kapazität füllen) | Premium füllt automatisch die freie Collector-/Quota-Kapazität bis zu einem Budget, statt eines festen Prozentsatzes. | Niedrig |
| E7: Premium → täglicher Video-Stats-Sync (YouTube) | YouTube-Premium-Channels zusätzlich täglich im Video-Stats-Sync berücksichtigen (Quota beachten), damit auch Video-Metriken tagesaktuell sind. | Niedrig |
| E8: Benachrichtigung bei Tier-Ein-/Austritt | Audit/Notification, wenn ein Profil ins Premium-Tier ein- oder austritt (Relevanz-Signal, Nachvollziehbarkeit). | Niedrig |
| E9: Score-/Engagement-gewichtetes Tier (Variante) | Statt rein Follower-basiert eine Variante, die Relevanz breiter fasst (Score/Engagement). | Niedrig |
| E10: Materialisierte „latest follower"-Snapshot-Tabelle | Exakte, günstige Schwellen-/Selektionsbasis ohne Per-Query-Perzentil — nützlich, falls die Perzentil-Query bei sehr großem Universum teuer wird. | Niedrig |
| E11: Schwellen-Cache-Warming als Pipeline-Pre-Step | Den 4-h-Cache der Premium-Schwelle proaktiv warmhalten, damit der erste Mitternachts-Lauf die Perzentil-Query nicht selbst zahlt. | Niedrig |
| E12: TikTok-Vorbereitung | SocialPlatform::TikTok existiert, Scraping noch nicht. Sobald TikTok-Daten erfasst werden, das Premium-Tier analog aktivierbar machen (percentForPlatform/eligibleUniverse erweitern). | Niedrig |
Erweiterungsideen: Anomalie/Charts (v2.2.6, 2026-06-19)
| Item | Beschreibung | Priorität |
|---|
| Gerundete Abkürzungs-Followerwerte (3M/5M) | Der Instagram-Scraper liefert an manchen Tagen die abgekürzte Anzeige-Zahl (z. B. „3M"/„5M" → exakt 3.000.000/5.000.000) statt der genauen Zahl. Das liegt innerhalb der Anomalie-Toleranz (±25 %) und ist damit weder vom Detektor noch vom Ingestion-Collapse-Guard erkennbar — es erzeugt aber Fake-Score-Spikes/-Dips (z. B. 2,65 Mio. ↔ 3,0 Mio.). Sauber nur scraper-seitig lösbar (exakten Count aus den Seiten-Daten lesen statt der abgekürzten Anzeige). In-App-Heuristiken (Wert == runder Millionen-/100k-Wert UND off-trend) sind fragil (echte runde Counts) und wurden bewusst NICHT umgesetzt. | Mittel |
| Per-Video-Chart (VideoStatsChart) Anomalie-Dashing | Die per-Video-Views/Likes-Charts nutzen withoutAnomalies() (Anomalie-Tage werden ausgelassen → solide verbunden, kein falscher Dip), stricheln den ungültigen Zeitraum aber noch nicht wie die Followers-/Score-/Aggregat-Charts. Für volle visuelle Konsistenz denselben GappedSeries-Solid+Dashed-Ansatz im Absolut-Modus anwenden (Mehrserien-Chart: Views/Likes + Engagement + Kanal-Ø → Legende/dashArray-Abgleich nötig). | Niedrig |