Fix research pipeline provider failures

HANDOFF.md

@@ -85,39 +85,34 @@ Mit einem gültigen, bereits erzeugten Key im Browser testen:
    Antwortcodes gemeinsam auswerten. Klartext-Keys niemals in Chat oder Logs
    kopieren.
 
-### Aktueller Blocker im Browser-Flow — 2026-09-06
+### Browser-Flow: Backend-Blocker lokal behoben — 2026-09-06
 
-Der Browser-Flow erreicht inzwischen die Detailseite und fragt Status,
-Quellen, Claims, Evidenz und Bericht ab. Eine tatsächlich gestartete Recherche
-liefert jedoch derzeit keine Ergebnisse. Dies ist ein Backend-Problem, nicht
-mehr der Frontend-Proxy oder die API-Key-Loginstrecke.
+Die drei Backend-Ursachen für leere, scheinbar erfolgreiche Researches sind
+lokal implementiert, getestet und mit `docker compose up -d --build` deployed:
 
-Reproduzierbare Logbefunde aus `docker compose logs nsct-api`:
+1. `LLMProvider._create_client()` normalisiert die Basis-URL und hängt `/v1`
+   nur an, wenn sie nicht bereits enthalten ist. Ein authentifizierter,
+   sanitisiert ausgegebener Chat-Completions-Probe war erfolgreich.
+2. `SearXNGProvider` ist in `src/nsct/providers/searxng.py` implementiert und
+   wird vom Orchestrator registriert. Compose mountet eine minimale SearXNG-
+   Konfiguration, die `format=json` erlaubt, und nutzt den vom aktuellen
+   SearXNG-Image erwarteten Variablennamen `SEARXNG_SECRET`. Ein echter,
+   sanitisiert ausgegebener Search-Probe lieferte ein Ergebnis.
+3. Die Pipeline führt wieder `fetching → extracting → analyzing` aus.
+   Fehler beim Planen, Suchen, Abrufen oder Extrahieren werden nicht mehr als
+   leere Fallbacks als Erfolg gemeldet: Der Run wird `FAILED`, mit Fehlergrund
+   im REST-Status (`error`). Fehlende Provider führen ebenfalls zu `FAILED`.
 
-- `Planning failed: Error code: 401 - {'error': 'authentication required'}`
-- `No search providers configured — search will return empty results`
-- abgelehnte State-Transitions, etwa `fetching -> analyzing`,
-  `fetching -> synthesizing` und `fetching -> completed`.
+Validierung: Syntaxprüfung, Compose-Konfigurationsprüfung und 29 fokussierte
+Tests (inklusive neuer Regressionen für URL-Normalisierung, SearXNG und
+State-Flow) sind erfolgreich. `tests/test_rest_research.py` wurde nicht als
+Gesamtsuite abgewartet, da seine Background-Tasks echte externe Retries
+auslösen; die neuen deterministischen Tests decken den geänderten Fehlerpfad.
 
-Ursachen und nächste Reparaturen:
-
-1. `src/nsct/providers/llm.py` ergänzt in `_create_client()` immer `/v1`.
-   `NSCT_LLM_BASE_URL` ist laut `.env.example` und Deployment-Dokumentation
-   bereits eine OpenAI-kompatible URL mit `/v1`. Den Basis-URL-Join
-   normalisieren, damit nie `/v1/v1` entsteht. Danach einen authentifizierten
-   Chat-Completions-Probe ausführen, ohne URL oder Key auszugeben.
-2. `src/nsct/orchestration/orchestrator.py::_get_multi_search()` importiert
-   `nsct.providers.searxng.SearXNGProvider`, aber
-   `src/nsct/providers/searxng.py` existiert nicht. Der `ImportError` wird
-   still geschluckt; deshalb hat die Pipeline keinen Search-Provider. Entweder
-   den SearXNG-Provider implementieren oder den vorhandenen
-   `DuckDuckGoProvider` als Fallback registrieren. Compose setzt bereits
-   `NSCT_SEARXNG_BASE_URL=http://searxng:8080/`.
-3. Das Orchestrator-/REST-Fehlerhandling muss bei nicht ausführbarer Pipeline
-   einen nachvollziehbaren `FAILED`-Status mitsamt Fehlergrund liefern, statt
-   mit leeren Fallbacks scheinbar abgeschlossene Schritte zu zeigen. Die
-   Transition-Matrix und die Fallback-Logik in `orchestrator.py` prüfen und
-   gezielt testen.
+Nächster Schritt: Den Browser-End-to-End-Test mit einem gültigen, **nicht im
+Chat offengelegten** Frontend-API-Key durchführen. Dabei insbesondere prüfen,
+dass Quellen, Claims und Bericht nach einem echten Research-Lauf erscheinen
+und ein Provider-/LLM-Ausfall in der UI den REST-Fehlergrund zeigt.
 
 Frontend-Fixes des laufenden Browser-Tests (alle im Frontend-Repository
 `/home/faligam/apps/NSCT-FrontEnd`, `main`, gepusht):