fix(llm): model_map params erreichen die Wire-Ebene + Dream-Degenerations-Fixes

[W4-NERF]

fix(llm): model_map params erreichen die Wire-Ebene + Dream-Degenerations-Fixes (v5.1.0-Basis)

Problem (v5.0.0-Regression + Nemotron-Degeneration, prod-beobachtet 2026-08-22/24)

Seit der v5.0.0-Backend-Pool-Migration schlugen dream-eval und query-temporal
(translate-Rolle) mit unexpected end of JSON input fehl. Zusätzlich degenerierte
Nemotron 3.5 Lightning (vLLM/LiteLLM) auf dichten technischen Blöcken. Symptome:

• dream: response hit the output cap — truncated JSON mit num_predict: 600,
  completion_tokens: 12000 → links_parsed: 0 (stiller Fehlschlag, kein WARN)
• temporal LLM fallback failed, no temporal expansion available →
  temporal: invalid JSON: unexpected end of JSON input
• Nemotron-Degeneration: keywords too few (1) / no valid strings found auf
  Backslash-lastigem Content (BRADES-Migrations-Blöcke), 9× completion_tokens=1200,
  Endlos-Retry alle ~6 Min (workers=1 blockierte den Zyklus)
• Eval-Cap-Hits: 21–28 Kandidaten ließen 1200er-Cap reißen (parse links: unexpected end)
• Vor der Migration (Settings-basiert, dream.think=false): Ø ~4.700 Tokens/Eval,
  keine Fehler. Nach Migration: Ø ~12.000 Tokens, fast jeder Eval am Limit.

Root Cause

applyModelParams (llm/chain.go) verarbeitet aus model_map.<role>.params nur die
festen Options-Keys (temperature, top_p, num_predict/max_tokens, think, …) und
verschluckt alle unbekannten Keys stillschweigend — insbesondere
chat_template_kwargs, das bei vLLM/LiteLLM-servierten Modellen (Nemotron 3.5
Lightning) der einzig wirksame Thinking-Schalter ist.

chatOpenAI (llm/client.go) übersetzt think:false stattdessen in das
OpenRouter-spezifische Feld reasoning:{enabled:false,exclude:true}. Das
ignorieren nicht-OpenRouter-Provider (vLLM/LiteLLM) → das Modell denkt weiter,
der Output läuft in den Token-Cap, strukturiertes JSON kommt abgeschnitten an.

Der dokumentierte Vertrag — "per-backend tuning belongs in the serving row's
model_map params … which override this default at dispatch" (Kommentar in
dream/evaluate.go, DreamOptions) — galt damit nur für die festen Keys.

Fix

Generic Passthrough statt Config-Workaround:

1. Options bekommt ein Extra map[string]any Feld (json:"-" — Ollamas
   /api/chat options-Block bekommt bewusst keine fremden Keys).
2. applyModelParams sammelt unbekannte Params in Options.Extra, statt sie
   zu droppen. chat_template_kwargs wird explizit als bekannter Passthrough-Key
   geführt (dokumentiert, dass er nur auf dem OpenAI-Wire wirkt).
3. chatOpenAI merged Options.Extra nach dem Marshal in den Request-Body —
   vor applyOpenAIBodyExtras, sodass die Backend-extra_body bei
   Key-Kollision weiter Vorrang behält (last write wins, "extra_body only
   tightens").

Damit funktioniert die bestehende model_map-Konfiguration wie dokumentiert:

{
  "dream": {
    "model": "DGX_nemotron_3_5_lightning",
    "params": {
      "max_tokens": 600,
      "think": false,
      "chat_template_kwargs": { "enable_thinking": false }
    }
  }
}

Dream-Budget: dream.num_predict (v5.1 hot-Setting) statt Code-Konstante

Zweites, unabhängiges Problem: Nemotron 3.5 Lightning ignoriert die
"Maximum 5 entries"-Instruktion und listet alle Kandidaten (~40 Tokens pro
pretty-printed Array-Eintrag). Bei 10+ Kandidaten riss der 600er-Cap das JSON
mitten im Array ab (prod: Block 01a0120d, 2× "output cap — truncated JSON"),
bei 21–28 Kandidaten auch der 1200er-Cap (parse links: unexpected end of JSON input, prod 2026-08-24). v5.1.0 bringt dream.num_predict als hot-Setting —
dieser PR dokumentiert die Prod-Erkenntnisse im Code-Kommentar und empfiehlt
dream.num_predict=1600 für Nemotron-Installationen (~30 Einträge, weit unter
der 12000-Degenerations-Schwelle). Modelle, die die 5-Einträge-Instruktion
befolgen, bleiben weit darunter (gemessen 61–315 Tokens).

Keyword-Phase: Cap hart (CapLocked) + 12h-Cooldown bei Fehlschlag

Drittes, wieder anderes Problem (prod 2026-08-22, Block 01a02b24 "Migration
BRADES-SERVER"): Die Keyword-Phase nutzt dieselbe Rolle RoleDream wie die
Eval-Phase — das model_map dream.max_tokens-Override (1200, für Eval
gedacht) blähte dadurch auch die Keyword-Extraktion auf (Code-Default 200).
Bei einem Block mit vielen Backslash-Pfaden (E:\brades-export\ etc.)
degenerierte Nemotron und generierte 9× deterministisch bis zum Cap
(completion_tokens: 1200, "keywords too few (1)"). Da der Fehlschlag nur
einen 5-Min-Cooldown auslöste, wurde der Block alle ~6 Min neu gepickt —
ein Endlos-Retry, der den Dream-Zyklus (workers=1) blockierte.

Zwei Fixes:

1. Options.CapLocked: markiert eine Phase mit hartem Budget. Die
   Keyword-Phase setzt es (keywordOptions: NumPredict 200, CapLocked) —
   applyModelParams wendet num_predict/max_tokens-Overrides dann nicht
   an. Eine Extraktions-Phase behält damit immer ihr Budget, egal was die
   Serving-Row für andere Phasen derselben Rolle konfiguriert.
2. CooldownKeywordFailMinutes = 12h: nach 3 fehlgeschlagenen
   Keyword-Versuchen parkt der Block 12h statt 5 Min. Transiente Fehler
   (Preempt, GPU-Outage) bleiben beim 5-Min-Pfad.

Deterministischer Keyword-Fallback + Tokenize-Fix

Viertes Problem (prod 2026-08-23): Auch mit CapLocked-400 degenerierte Nemotron
auf dichten technischen Blöcken (Windows-Pfade) bis zum Cap → no valid strings found. Fixes:

1. GenerateKeywords fällt nach KeywordsMaxRetries auf den deterministischen
   ExtractKeywords-Tokenizer zurück — der Block wird trotzdem gesucht/evaluiert
   statt geparkt; der 12h-Cooldown greift nur, wenn selbst der Tokenizer nichts findet.
2. tokenize spaltet an allen Nicht-Buchstaben-/Ziffern-Zeichen (außer
   Bindestrich): C:\Users\Brades\.ssh\authorized_keys wird zu suchbaren
   Begriffen statt einem Riesen-Token. Verifiziert: BRADES-Content liefert
   [authorizedkeysfile streaming-pc admin-user-falle pipeline-server ...].

Tests: TestCapLockedResistsModelMapOverride pinnt den CapLocked-Vertrag,
TestGenerateKeywords_FallbackAfterRetries den Fallback, TestExtractKeywords_BradesContent
den Tokenize-Fix auf Prod-Content.

⚠️ Wichtig: Diese Konfiguration ist NUR für Modelle nötig, die standardmäßig denken

Die think:false/chat_template_kwargs.enable_thinking:false-Konfiguration ist
nur erforderlich, wenn das Serving-Modell per Default Reasoning/Thinking
emittiert — konkret nicht für Qwen 3.6/3.8 (27b/35b), die ohne Thinking
antworten. Betroffen war Nemotron 3.5 Lightning (30B A3B NVFP4) über
vLLM/LiteLLM, das standardmäßig Chain-of-Thought produziert.

Für Qwen-Modelle kann die Konfiguration entfallen bzw. wäre nur eine
Optimierung; für Nemotron und andere Default-Thinking-Modelle ist sie
zwingend, sonst fressen Reasoning-Tokens das Output-Budget und JSON-Antworten
werden abgeschnitten.

Warum KEIN neues Settings-System (bewusste Entscheidung)

Die v5.0.0-Migration (133) hat die alten Tuple-Settings (dream.think,
chat.* etc.) bewusst retired — die Architektur ist jetzt Backend-zentriert
(context_backends mit model_map/extra_body). Diese Konfiguration als
globale Settings wieder einzuführen wäre ein Schritt zurück und würde die
Per-Rolle-/Per-Backend-Differenzierung (chat vs. dream vs. translate) verlieren.
Der Passthrough macht das vorhandene model_map-Params-System vollständig
funktionsfähig — der richtige Ort für Backend-spezifische Knöpfe.

Tests

• TestModelMapExtraPassthrough (neu, llm/wire_test.go): pinnt den Vertrag —
  chat_template_kwargs landet in Options.Extra, geht auf die Wire-Ebene,
  Backend-extra_body gewinnt bei Kollision, think:false wird gesetzt.
• TestCapLockedResistsModelMapOverride (neu): CapLocked-Phase behält ihr
  Budget trotz model_map-Override; Kontrolle ohne Lock übersteuerbar.
• TestGenerateKeywords_FallbackAfterRetries (neu): 3 LLM-Calls, dann
  deterministischer Fallback, >= MinKeywords.
• TestExtractKeywords_BradesContent (neu): Tokenize-Fix auf Prod-Content.
• TestEvaluateRelationships_CapHitStillErrors (dream): Cap-hit-Pfad bleibt
  Observability-only.
• Bestehende Wire-Tests (Temporal/Synthesize/ChatChain) + dream-Tests grün
  (auf v5.1.0-Basis rebased).
• go vet + golangci-lint: 0 Issues.

Verifikation (prod, 2026-08-22/24, v5.1.0 + Fixes)

• Dream: Zyklen links_evaluated/links_written 5/5, 5/5, 6/6 — keine stillen
  0-Fehlschläge. Tokens 12.000 → 162–865.
• Keyword-Loop gestoppt: BRADES-Block (vorher 9×1200-Token-Degeneration) im
  12h-Cooldown; kein Endlos-Retry mehr. 24h: 790/835 eval-Erfolg (94,6%),
  keyword-Fehler auf ~6 Blöcke begrenzt (Retry-Versuche, Fallback greift).
• Cap-Hits (21–28 Kandidaten) durch dream.num_predict=1600 adressiert.
• Temporal: Live-Query mit Zeitbezug liefert saubere temporal-Auflösung,
  kein Fallback-Fehler mehr.
• v5.1.0: rebased, deployed, erster Zyklus 5/5 Links, Health ok.

Beobachtungszeitraum

Erneuter Beobachtungszeitraum nach Merge dieses PRs: 48 h (mindestens
10 Dream-Zyklen + mehrere temporal-Queries), danach Abschluss-Urteil.

[GottZ]

Merged in v5.3.0 — danke für die saubere Analyse-Strecke, die Prod-Evidenz im PR-Body war Gold wert.

Deine 8 Commits sind als ein Squash-Commit mit deiner Autorschaft gelandet: 621b0cd (fix(llm): model_map params erreichen die Wire-Ebene + Dream-Degenerations-Fixes (#39)). Obendrauf drei Härtungs-Commits aus dem Review plus ein Folge-Feature:

• 6176100 — der BRADES-Test las /tmp/block_content.txt (in CI stiller Skip, lokal beliebiger Fremdinhalt, und die echte Fixture wäre privater Block-Content im Repo) → synthetische Inline-Fixture mit derselben Fehlerform.
• a8f9aa7 — der Objekt-Drift-Salvage nahm die Map-Values in Go-Zufallsreihenfolge und ungekappt (empirisch: 20 Paare → 20 Keywords → 20 RRF-Suchen) → sortierte Key-Reihenfolge, Kappung bei MaxObjectDriftKeywords=8 (die Obergrenze, die der Array-Prompt selbst fordert).
• 5584aa9 — das Warn-Log sagte noch „transient cooldown", der Code parkt seit deinem Umbau 12h → Text + cooldown_minutes-Feld sagen jetzt den echten Zustand.
• b281a7c — Folge deines Passthroughs: der Web-ModelMapEditor editiert model_map-Params jetzt pro Rolle als freies JSON-Objekt (das alte „+params (edit via CLI)"-Badge ist raus).

Credit steht in CONTRIBUTORS.md (f3acfde). Verifikation vor dem Merge: volle go-short-Suite, Integration dream+llm, vitest 978/978, e2e-visual 447/447.

Closing als merged — der Squash taucht für GitHub nicht als Branch-Merge auf, die Commits sind seit dem v5.3.0-Push auf root.