fix(dashboard): ch1-Akzeptanzbalken bei 0-Eval-Lauf ehrlich kennzeichnen + Merge-Notes als eigene Scatter-Kategorie

[TillQuandel]

Befund

Folge zu #237 (Rest-Backlog aus PR #246). Zwei im Issue genannte Ehrlichkeitslücken bleiben, nachdem #246 nur die Akzeptanz-KACHEL neutralisiert hat:

(a) ch1 "Akzeptanzrate je PDF" (internal/dashboard/eval_dashboard.html, renderCharts()) färbte einen Balken tone-basiert (mint/amber/coral nach T.accept-Schwelle), auch wenn für die PDF-Gruppe 0 Notes evaluiert wurden — der Wert stammt dann rein aus Routing-Logs (accept), nicht aus Eval-Daten. Repro-Fall Run 20260713-084724 (M3, Schlebbe & Greifeneder): accept=100.0, n_notes=0 → vollständig grüner 100%-Balken, identischer Fehleindruck wie die #237-Kachel. Zusätzlicher Fund dabei: das (n=X)-Label wurde bei n_notes===0 durch einen Truthy-Check (nMap[p.l]?..., 0 ist falsy) stillschweigend weggelassen — der einzige ehrliche Hinweis verschwand genau dann, wenn er am wichtigsten wäre.

(b) Scatter-Chart (ch2, Fehlerquote vs. Belegrate): gemergte, nicht evaluierte Vault-Notes (Routing "Merge" — landen im Vault, werden aber laut #237-Diagnosebefund nie separat neu evaluiert) hatten kein Fehlerquote/Belegrate-Koordinatenpaar und tauchten im Chart schlicht nicht auf — implizit als Nicht-Problem statt als eigene Kategorie sichtbar.

Live-Renderpfad ist internal/dashboard/eval_dashboard.html + generative/eval_dashboard_server.py::_build_live_html() (fetch /data.json) — nicht das deprecated _build_html() in generative/eval_dashboard.py (Legacy-CLI-Pfad, per Code-Kommentar dort explizit als "NICHT dieser hier" markiert).

Fix

(a) renderCharts() ch1-Block: neue barColor(p)-Funktion — Balken mit n_notes===0 bekommen die neutrale Grau-Farbe t.ink4 (dieselbe gedämpfte Farbe wie die bestehende "Weitere"-Sammelkategorie in Scatter/Scaling, keine neue Farbe) statt der tone-Schwelle. Label zeigt (n=X) jetzt immer, auch bei 0 (!=null-Check statt Truthy-Check). Tooltip erklärt bei n_notes===0 zusätzlich "keine Eval-Basis — 0 Notes evaluiert (nur Routing-Daten)".

(b) Neues Feld n_merge pro PDF-Zeile: _accept_from_runs() (generative/eval_dashboard.py) gibt jetzt (accept, accept_ver, accept_n, n_merge) zurück — Summe der Merge-Stub-Notes auf derselben Versions-Basis wie accept/accept_n (kein zweiter Aggregationspfad, SSoT). _calc_pdf_table() trägt n_merge in beide Zeilentypen (Eval-Gruppen + Routing-only) ein. Client liest d.pdf_table[].n_merge und zeigt eine explizit beschriftete Legenden-Kategorie "N gemergt, nicht evaluiert" neben dem Scatter (.hint/.hint-pop-Tooltip mit PDF-Breakdown) — dieselbe visuelle Sprache (Dot + Label) wie die "Weitere"-Kategorie, keine neue CSS-Regel. Bewusst kein fiktiver Scatter-Punkt: Merge-Notes haben kein Fehlerquote/Belegrate-Wertepaar, ein erfundenes Koordinatenpaar wäre selbst eine neue Ehrlichkeitslücke.

Anker-Korrektur: Issue nannte _chart_scaling (eval_dashboard.py:1034) als Anker für (b). Nach Analyse ist _calc_pdf_table/_accept_from_runs der präzisere Anker — dort existiert bereits die Merge-Zahl pro Routing-Run (n_merge in _read_all_log_runs()), _chart_scaling selbst aggregiert nur Wörter-vs-Notes-Zahl (Chart 3, unverändert).

TDD — RED-Beleg

generative/tests/test_dashboard_ch1_merge_scatter_honesty.py, 9 Tests. RED vor dem Fix:

FAILED test_accept_from_runs_returns_merge_count - ValueError: not enough values to unpack (expected 4, got 3)
FAILED test_pdf_table_eval_row_exposes_n_merge - KeyError: 'n_merge'
FAILED test_pdf_table_routing_only_merge_stub_exposes_n_merge - KeyError: 'n_merge'
FAILED test_pdf_table_row_without_merge_defaults_to_zero - KeyError: 'n_merge'
FAILED test_ch1_bar_color_guarded_by_zero_evaluated_notes - kein n=0-Guard fuer die ch1-Balkenfarbe gefunden
FAILED test_ch1_label_shows_n_even_when_zero
FAILED test_ch1_tooltip_explains_missing_eval_basis
FAILED test_scatter_legend_has_merged_not_evaluated_category
FAILED test_scatter_legend_merge_count_sourced_from_pdf_table

Nach Fix: alle 9 GREEN (4 Python-Datenschicht-Tests direkt gegen _accept_from_runs/_calc_pdf_table, 5 String-Marker-Tests gegen _build_live_html() — gleiches Muster wie #246).

Suite + Lint

• pytest generative lib/decision_engine/tests shared/tests -q: 5866 passed, 3 skipped, 8 deselected.
• ruff check + ruff format --check auf geänderte Dateien: sauber.

Verifikation (Playwright-Browser-Launch fehlgeschlagen, siehe unten — Ersatzverifikation)

Server entkoppelt aus dem Worktree gestartet (Port 8064, ATOMIC_DB_PATH auf eine reine Kopie der Analytics-DB C:\tmp\249-db.db, nur lesend zugegriffen). Playwright-Firefox startete 3x in Folge mit identischem Fehler (<process did exit: exitCode=0> sofort nach Launch — systemisches Sandbox-Problem, kein Fluke). Ersatz: die IDENTISCHE JS-Logik aus renderCharts()/_mergedBreakdown/_mergedLegendChip 1:1 in ein Node-Skript kopiert und gegen ECHTE /data.json-Antworten des laufenden Servers ausgeführt:

• Repro-Run 20260713-084724 (n_notes=0, accept=100.0, n_merge=1, verifiziert per /data.json?run=20260713-084724): Balkenfarbe #7e92a6 (= --ink-4, neutral/grau, NICHT mint/grün), Label "Schlebbe und Greifen… (n=0)", Tooltip ["100 % akzeptiert", "keine Eval-Basis — 0 Notes evaluiert (nur Routing-Daten)"].
• Unfiltered View (299 Scatter-Punkte, 34 gemergte Notes über 17 PDF-Zeilen laut /data.json, u. a. 2 Routing-only-Zeilen mit n_notes=0 UND n_merge>0): Merge-Chip "34 gemergt, nicht evaluiert" korrekt gerendert.
• Gegenprobe: ein Balken mit echter Eval-Basis (z. B. "Afzal (2017)") bleibt unverändert tone-basiert (#6dbf8c = mint) — der Guard trifft nur n_notes===0-Zeilen.
• --ink-4 ist in beiden Themes definiert (:root dunkel #7e92a6, Light-Override #6b6b6b) — automatisch hell/dunkel-tauglich ohne neue CSS-Regel.

NUL-Byte-Invarianten von eval_dashboard.html vor/nach Edit geprüft: exakt 1 (unverändert).

Eigener Server-Prozess nach Verifikation beendet, Port 8064 wieder frei.

Geänderte HTML-Regionen

Ausschließlich renderCharts() ch1-/ch2-Block und renderScatter() (+ 2 neue Helper-Funktionen _mergedBreakdown/_mergedLegendChip direkt davor) — keine Berührung der KPI-Kachelleiste (#kpis, kpiDefs), die parallel von einem anderen Agenten bearbeitet wurde.

Closes #249