Changelog

Überarbeitete Enrichment-Engine (V2) mit Retrieval-first-Ansatz: Kontaktdaten werden vorrangig aus realen Quellen recherchiert und erst durch ein LLM bewertet und zugeordnet statt generiert. Verarbeitungsstufen: Fast Path (welche Felder fehlen), Domain Discovery, Website Retrieval, Person Resolution, Web Search Fallback, LLM-Resolution/Validierung. Jedes Feld speichert Verification-Status (VERIFIED/FOUND_ON_SOURCE/INFERRED/UNKNOWN) und Confidence (0–1). Strukturierte Failure Reasons (NO_PHONE_FOUND, WEBSITE_OFFLINE u.a.) machen fehlende Ergebnisse auditierbar. Bereits vorhandene hochwertige (VERIFIED/FOUND_ON_SOURCE) Daten werden nicht verschlechtert ("no-deterioration"). Nutzen: höhere Datenqualität, nachvollziehbare Herkunft jedes Felds und geringere Halluzinationsgefahr bei Kontaktdaten.

Zusätzliche Deep-Search-Stufe für Leads, bei denen die reguläre Recherche noch fehlende Kontaktdaten (Telefon, Website, E-Mail, Kontaktperson) nicht liefern konnte. Sie greift erst als automatischer Fallback, wenn die reguläre V2-Recherche nicht ausreicht, und führt gezielte erweiterte Web-Queries durch. Gefundene Werte werden validiert und mit Quelle und Confidence gespeichert; es werden keine Kontaktdaten erfunden oder erraten. Nutzen: höhere Abschlussquote bei schwierigen Datensätzen, ohne die Qualitäts- und Verifikationsregeln aufzuweichen.

Kontrollierte Parallelisierung der Enrichment-Verarbeitung: begrenzte Lead-Concurrency, paralleles Website-Retrieval mehrerer Unterseiten gleichzeitig sowie Retry-/Timeout-Handling bei externen Requests. Dadurch werden grössere Lead-Bestände schneller und stabiler verarbeitet, während API- und LLM-Last kontrolliert bleibt (Concurrency-Limit, Caching, bewusste Stufenfolge). Nutzen: kürzere Laufzeiten bei grösseren Durchläufen, geringere externe Kosten und stabileres Verhalten auch bei einzelnen fehlgeschlagenen Requests.

Neuer Admin-Prozess "Altbestand anreichern": bestehende, noch nicht oder nur teilweise angereicherte Leads können automatisch nachbearbeitet werden, ohne erneut importiert zu werden. Der Backfill nutzt die vorhandene Enrichment Engine V2 und verarbeitet die Leads autonom über die zentrale Queue und die Worker. Bereits vorhandene gute Daten bleiben erhalten. Wichtig: Der bestehende Lead Pool wird dadurch nicht verändert — Lead-Pool-Leads sind vom Backfill ausdrücklich ausgeschlossen. Nutzen: qualitative Nachbearbeitung des historischen Bestands ohne Neuimport und ohne Berührung des produktiven Lead Pools.

Persistente Enrichment-Queue mit zentralen Feldern (queue_status, queue_priority, queued_at, enrichment_started_at, queue_lock_expires_at, enrichment_attempt_count, next_retry_at). Priorisierung (1 = neue wirtschaftsdaten.ch-Leads bis 4 = historischer Backfill), kontrollierte Batch-Verarbeitung, Versuchszähler mit konfigurierbarem Maximalwert, Retry-Handling mit Sperrverfall (abgestürzte Worker geben Leads nach Lock-Ablauf frei), automatische Worker-Verarbeitung (Schedule alle 5 Min.) sowie manuelles Starten eines Worker-Laufs durch Admins. Nutzen: zuverlässige, autonome und nachvollziehbare Abarbeitung auch grösserer Mengen mit klarem Status je Lead.

Neues/erweitertes Admin-Monitoring für die Enrichment-Automation: Queue-Grösse, aktuell verarbeitete Leads, Tagesstatistiken (verarbeitet, erfolgreich, Lead-Pool-Conversion, Needs Review, Partial, Failed) sowie Performance-Kennzahlen (Median/P90-Laufzeit, aktive Worker, Concurrency). Dazu operative Werkzeuge (Worker starten, Reconciliation, Dedup, Quality-Gate, Backfill). Nutzen: transparente Steuerung und Kontrolle der autonomen Anreicherung durch die Administration.

Live-Monitoring des laufenden Altbestand-Backfills: Fortschrittsanzeige (verarbeitet/gesamt in %), aktive Worker, Live-Queue mit Status, Versuchen, Deep-Search-Status, Laufzeit und Failure Reason pro Lead, automatische Dashboard-Aktualisierung. Es ist rein Monitoring — Lead-Pool- und Enrichment-Regeln werden dadurch nicht verändert. Nutzen: belastbare Nachvollziehbarkeit des Fortschritts und frühzeitiges Erkennen von Blockaden.

Werkzeuge für das Bestands-Cleanup: Bestandsanalyse, Duplicate-Dry-Run und kontrolliertes Zusammenführen bestätigter Dubletten. Historien und vorhandene hochwertige Daten bleiben beim Merge erhalten; unterschiedliche Event-Datensätze derselben Firma (gleiche UID, anderes Ereignis) werden nicht automatisch als Dublette behandelt, sondern als eigenständige Datensätze erhalten; nur unsichere Treffer gehen in den Admin-Review. Nutzen: nachvollziehbare, sichere Dublettenbereinigung ohne Datenverlust.

Striktes, serverseitiges Quality-Gate für die Lead-Pool-Freigabe (vollständige Verifikation von Firma, Telefon, Website, E-Mail, Kontaktperson) mit zugehörigen Werkzeugen: Quality-Gate-Dry-Run und Revalidierungsmöglichkeit für Administratoren, sodass die Qualitätsprüfung vorhandener Datensätze kontrolliert und ohne produktive Änderung vorab geprüft werden kann. Die bestehenden Lead-Pool-Regeln werden dadurch nicht verändert. Nutzen: kontrollierte, nachvollziehbare Qualitätssicherung vor produktiven Änderungen.

Zusätzlicher Pull-/Reconciliation-Prozess zwischen wirtschaftsdaten.ch und AG READY als Sicherheitsmechanismus zum bestehenden Push: fehlende Events können automatisch erkannt und importiert werden, mit Pagination über alle Seiten, Watermark-/Sync-Mechanismus und Idempotenz über transfer_key gegen Doppelimporte. Push und Pull ergänzen sich. Status: implementiert; der produktive Sync-Endpoint wird aktuell bei Ratenbegrenzung noch stabilisiert (in Umsetzung). Nutzen: höhere Robustheit der Datenübernahme und Schutz gegen verpasste Events.

Integration des ag-ready/events-Endpoints von wirtschaftsdaten.ch mit API-Key-basierter Authentifizierung (serverseitig als Secret gespeichert). Verarbeitung von BANKRUPTCY-, LIQUIDATION- und DELETION-Events mit Übernahme der relevanten Unternehmens- und Ereignisinformationen; ein transfer_key stellt die eindeutige Zuordnung und Idempotenz sicher. Keine API-Secrets oder Schlüssel werden veröffentlicht. Nutzen: strukturierte, idempotente Übernahme relevanter Handelsregister-Ereignisse in den AG-READY-Bestand.

Reconciliation-Monitoring und Fehlerbehandlung im Admin-Dashboard: HTTP-Status, Sync-Status, erhaltene/bereits bekannte/neue Events, importierte Leads, API-Requests/Seiten, Laufzeit und Importfehler. Der Sync-Watermark (last_successful_sync) wird nur bei einem vollständig fehlerfreien Lauf fortgeschrieben; bei Fehlern bleibt er stehen, sodass fehlende Events beim nächsten Lauf erneut gezogen werden. Nutzen: belastbare Nachvollziehbarkeit jedes Sync-Laufs und Schutz gegen stillen Datenverlust.

Der Altbestand-Backfill schliesst bestehende Lead-Pool-Leads (intake_status = leadpool) ausdrücklich aus — sie werden durch den Backfill nicht erneut angereichert. Bestehende Claims und Ownership bleiben unverändert, ebenso die BD-Berechtigungen und die Lead-Pool-Logik. Nutzen: klare Trennung zwischen Nachbearbeitung des Altbestands und dem produktiven Lead Pool; keine unerwünschten Veränderungen freigegebener Leads.

Erweitertes Enrichment-Datenmodell für bessere Nachvollziehbarkeit: Verification-Status und Confidence je Feld (Telefon, Website, E-Mail, Kontaktperson), Quelleninformation (source_url) je angereichertem Feld, Verifikationszeitpunkt, normalisierte Schweizer Telefonnummer, strukturierte Kontaktperson (Vorname, Nachname, Funktion) und strukturierte Failure Reasons. Nutzen: jede Anreicherung ist später feldbezogen nachvollziehbar, was Vertrauen, Audit-Fähigkeit und Datenqualität erhöht.

Neue serverseitige Lead-Weitergabe (transferLead) für Business Development: ein BD-Mitarbeiter kann eigene Leads an einen Kollegen (Business Development/Admin) übergeben — mit Kollegen-Auswahl, optionaler Notiz, atomarer Neuzuweisung, Zuordnung der Timeline an den neuen Owner und Eintrag in der Lead-Historie. Admins können jeden Lead weitergeben, BD nur eigene; Lead-Pool-, Claim-, RLS- und Quality-Gate-Logik bleiben unangetastet. Nutzen: saubere, nachvollziehbare Lead-Übergabe innerhalb des Teams ohne Umweg über den Lead Pool.

Strikte Rollentrennung zwischen Administration (Super Admin / Admin) und Business Development auf Daten- und Backend-Ebene. Row-Level Security für Leads verschärft: Business Development sieht ausschliesslich die eigenen, übernommenen Leads — keine unassigned oder fremden Datensätze mehr. Der Leadpool liefert vor der Übernahme nur noch fünf Felder (Firma, Branche, Kanton, Lead Score, Datenstand), serverseitig projiziert; vertrauliche Kontaktdaten werden erst nach der Übernahme sichtbar. Atomare, race-condition-sichere Lead-Übernahme mit konfigurierbarem Active-Lead-Limit pro Mitarbeiter. Serverseitige Eigentumsprüfung bei jedem Lead-Aufruf inklusive Audit-Eintrag (Lead geöffnet, Kontaktdaten eingesehen). Zentrales, unveränderliches Audit- und Lead-Historie-Logging aller Aktionen (Übernahme, Statuswechsel, Kontaktversuche, Notizen, Termine, Prüfung gestartet) — für Business Development nicht einsehbar, ausschliesslich der Administration vorbehalten. Statuswechsel laufen über eine serverseitige Funktion mit Pflichtfeld-Validierung (Rückruf, Wiedervorlage, Termin, Kein Interesse, Nicht geeignet, fehlerhafte Kontaktdaten) und Audit-Erfassung alt→neu. Automatischer Login-Redirect: Super Admin / Admin → Admin-Bereich, Business Development → Sales-Bereich. Admin-Routen rollenbasiert abgesichert; Business-Development-Navigation auf die zulässigen Bereiche eingeschränkt. Unberechtigte Zugriffsversuche werden als Security-Ereignis protokolliert.

Performance- und Ladeverhalten-Optimierung der öffentlichen Landing-Page. Render-Blocker entfernt: die globale Loading-Sperre (Auth/Public-Settings), die die gesamte App inkl. Landing-Page im Spinner hielt, wurde abgebaut. Route-Code-Splitting via React.lazy + Suspense — nur die Landing-Page ist eager, alle Admin-, Sales-, Portal- und Partner-Routen laden erst bei Aufruf (entfernt three.js, recharts, react-leaflet, react-quill, jspdf, framer-motion aus dem initialen Bundle; Haupt-JS-Bundle von ca. 552 KiB auf ca. 203 KiB reduziert). Google Fonts von render-blockierendem CSS-@import auf preconnect + nicht-blockierendes preload/swap umgestellt, Font-Gewichte von 11 auf 6 reduziert (Inter 400/500/600/700, Sora 600/700/800), display=swap. 4,96 MB unoptimiertes Office-Bild ersetzt durch responsives WebP via Medienpipeline (serviert in gerenderter Grösse); Artikel- und Wissenskarten-Bilder auf fill gestellt. Below-the-fold Daten (Team, Author, FAQ, Artikel) laden erst im requestIdleCallback; doppelte Author-Requests über geteilten Cache dedupliziert; KnowledgeSection lädt drei Author-Beiträge parallel statt sequenziell. Chat-Widget (inkl. chatConfig) per LazyChatWidget erst im Idle/Interaktion geladen. Google Tag Manager (gtag.js, ca. 167 KiB) wird erst nach erteilter Analytics-Einwilligung geladen — Erstbesucher ohne Einwilligung laden es nicht; dataLayer-Stub stellt sicher, dass keine Events verloren gehen. Ergebnis (verifiziert): Mobile Performance ca. 45 → 87, Desktop 91.

Leadpool-Karten zeigen neu «Im System seit» mit Datum und Uhrzeit (imported_at bei wirtschaftsdaten.ch-Importen, sonst created_date). CSV-Import erzwingt die Leadpool-Mindestanforderung: nur Leads mit Telefonnummer gelangen in den Leadpool; Leads ohne Telefon werden automatisch nach «Zur Prüfung» (needs_review) einsortiert, auch wenn die CSV den Status leadpool angibt.

Neuer verbindlicher Lead-Lifecycle: wirtschaftsdaten.ch → Import-Eingang → manuelle Auswahl → Enrichment Agent V2 (DataForSEO primär, Gemini Websearch Fallback) → Matching & Validierung → Qualitätsklasse A–D → Leadpool → Business Development. Importierte Unternehmen sind KEINE definitiven Sales-Leads. Harte Mindestanforderung Telefonnummer; ohne Telefon = REJECTED_NO_PHONE. Trennung von Original- und Enrichment-Daten (original_/enriched_). Keine erfundenen Kontaktdaten. Serverseitiger CSV-Export mit UTF-8-BOM, Varianten (alle/gefiltert/ausgewählt/angereichert/qualifiziert/mit Telefon/ohne Telefon), Audit Logging. Neues Statusmodell intake_status (IMPORTED … LEADPOOL). EnrichmentRun-Audit je Lauf.

Trennung von internem Entscheid und Kunden-Bescheid: der Entscheid wird intern gesetzt (notice_pending) und erst manuell als Bescheid über Resend versendet. Bei negativem Bescheid kann der Kunde im Portal intervenieren (Stellungnahme + Dokumente); Admin prüft die Intervention und erlässt einen versionierten Folgeentscheid (negativ bestätigt oder auf positiv geändert). Offerten werden erst nach gesendetem positivem Bescheid freigegeben (canCreateQuote-Gate im QuoteBuilder). Fortschrittsanzeige (computeLifecycle) als einzige fachliche Single Source of Truth aus echten Backend-States — kein paralleler Status. Neue Backend-Funktionen sendReviewNotice, submitReviewIntervention, processReviewIntervention; decideReview versendet keine Kundenmail mehr.

Verbindlicher 7-Schritt-Kundenworkflow (Erstgespräch → Prüfung → Entscheid → Offerte → Vertrag → Unternehmen aufbauen → Aktien übernehmen). Prüfung mit versioniertem Fragenkatalog, Rückfragen, Audit Trail. Neue Offertenlogik (AG-Gründung CHF 2’500 + monatlicher Block VR-Mandat/Buchhaltung/Domizil). Vertrag aus angenommener Offerten-Version. Elektronische Signatur mit OTP via Resend, Consent, SHA-256, Zertifikat und QR-Verifikation. Statusmodell, Rollen und Notifications synchron zur Implementierung dokumentiert.

Einführung des Kundenportals, vertragliche Prozesse und persistente interne Benachrichtigungen.

Lead Workspace, Lead-Zuweisung, versionierte Offerten mit Rückfrage- und Revisionslogik.

Öffentliche Website, SEO Landingpages, Fachredaktion und erstes Content-Setup.