LLMGui — Recent Changes

Alle relevanten Änderungen, neuen Features und Bugfixes. Neueste Einträge zuerst.

Hinweis: Zukünftige Dokumentation zu neuen Features landet ebenfalls auf dieser Seite.

Navigation

• LLMGui Übersicht
• VS Code Extension
• MCP Server & Client
• Control Center

2026-03-03 — /full-audit — Alle Checks in einem Durchlauf

brainy/commands/analysis.py — FullAuditCommand:
- Neuer Slash-Command /full-audit [path] führt alle 7 Quality- und Security-Checks sequenziell aus:
1. Linting (flake8 / ruff / pylint)
2. Type Check (mypy)
3. Security (bandit)
4. Complexity (radon)
5. Dead Code (vulture)
6. Vuln-Scan (pip-audit / safety / semgrep)
7. Secret-Scan (Regex + Entropy)
- Zeigt vor dem Start einen Plan-Header mit allen Schritten
- Jeder Schritt sendet scan_phase-SSE-Events (Spinner → Checkmark in VS Code)
- Abschluss: Summary-Tabelle (Rich Table) mit Status je Check + offene Findings aus der DB
- Ohne Argument: scannt den aktuellen Workspace. Mit Argument: scannt Datei oder Verzeichnis.
- Registriert in brainy/commands/__init__.py, brainy/tools/command_tools.py (Tool-Registry), brainy/mcp/server.py

2026-03-03 — VS Code: Security Findings TreeView

brainy/api/server.py — GET /api/findings:
- Neuer REST-Endpunkt liest Security-Findings aus ~/.brainy/security_findings.db
- Parameter: workspace (filtert project_path), status (default "open", "all" für alle)
- Antwort: { findings: [...], total: N } — max. 500 Einträge, sortiert nach CVSS-Score

clients/vscode/src/FindingsViewProvider.ts (neu):
- vscode.TreeDataProvider<FindingItem> — native VS Code TreeView
- 2-Ebenen-Struktur: Severity-Gruppe (Critical / High / Medium / Low / Info) → Finding-Items
- Jedes Finding zeigt: vuln_id · dateiname:zeile mit Tooltip (Beschreibung, Tool, CVSS, Fix-Hint)
- Klick auf Finding → Datei öffnen und direkt zur betroffenen Zeile springen
- getCount() für Badge-Zähler an der View

clients/vscode/src/extension.ts:
- createTreeView('llmgui.findingsView', ...) statt registerTreeDataProvider (Badge-Support)
- Badge wird nach jedem Refresh automatisch auf Anzahl offener Findings gesetzt
- Neue Commands:
- llmgui.findings.refresh — Refresh-Button in der Toolbar
- llmgui.findings.fixWithLLM — Baut Prompt aus Finding-Daten, öffnet Chat mit /agent-Modus
- llmgui.findings.openFile (intern) — Öffnet Datei an Zeile

clients/vscode/package.json:
- Neue View llmgui.findingsView unter llmgui-explorer (unterhalb des Chat-Panels)
- Toolbar: Refresh-Button $(refresh)
- Kontextmenü auf Finding-Items: "Mit LLMGui fixen" (view/item/context when: viewItem == finding)

2026-03-02 — Control Center: Security-Tab Trend-Anzeige & History-Vergleich

brainy/api/server.py — GET /api/security/trend:
- Neuer REST-Endpunkt, der Security-Findings aus ~/.brainy/security_findings.db nach Datum und Severity aggregiert
- Query-Parameter: days (7/30/90/0=alle) und project_path (optional)
- Antwort enthält data_points (täglich gruppiert: critical/high/medium/low/total) und comparison (Delta erster↔letzter Tag)

llmgui-control.py — Security-Tab:
- _tab_security(): Bestehender Findings-Pane und neuer Trend-Tab werden in einem Gtk.Notebook zusammengefasst (🔍 Findings / 📈 Trend & Vergleich)
- _build_sec_trend_tab(): Zeitraum-Dropdown (7/30/90 Tage / Gesamt) + Refresh-Button + Cairo-Chart + Vergleichs-Panel
- _draw_sec_trend(): Linien-Chart mit 4 Severity-Serien (critical=rot, high=orange, medium=gelb, low=blau), Y-Gitter, X-Datumsbeschriftungen, Legende
- _refresh_sec_trend() / _sec_trend_bg() / _apply_sec_trend_ui(): Async HTTP-Fetch vom /api/security/trend-Endpunkt, UI-Update im GLib-Idle
- _apply_scan_results_ui(): Ruft nach jedem Live-Scan automatisch _refresh_sec_trend() auf

2026-03-02 — Control Center: Security-Tab Live-Scan

llmgui-control.py — _tab_security():
- Neue Scan-Toolbar zwischen Stats-Cards und Findings-Tabelle:
- Pfad-Entry (Placeholder: aktuelles Verzeichnis)
- Vuln Scan Button → POST /api/scan/vuln
- Secret Scan Button → POST /api/scan/secrets
- Spinner + farbige Status-Meldung (blau = läuft, grün = fertig, rot = Fehler)
- _on_sec_scan(mode): liest Pfad, startet BG-Thread
- _sec_scan_bg(path, mode): HTTP POST an localhost:8080 mit 180s Timeout
- _apply_scan_results_ui(data, mode, path): befüllt vorhandene _sec_store-Tabelle direkt aus REST-Response (kein SQLite nötig); aktualisiert Total/Critical-Cards; Severity-Icons (💥🔴🟡💡)
- _sec_scan_error_ui(msg): zeigt Fehler rot an (Server nicht erreichbar etc.)
- Live-Scan-Ergebnisse haben DB_ID = -1 → „Fix with AI" aktiv, „Verify Fix" deaktiviert

2026-03-02 — Control Center: Benchmark-History in Modellliste

llmgui-control.py:
- _bm_model_store: 3 neue Spalten — bench_hint (Text), bench_color (Farbe), bench_tooltip (Tooltip)
- _bm_collect_history(): liest alle benchmark_results_*.json + planning_results_*.json, gibt {model: {std_speed, std_date, plan_score, plan_date}} zurück; bm_dir.exists()-Guard, encoding="utf-8", per-File try/except
- _bm_history_hint(): erzeugt (text, color, tooltip) 3-Tuple:
- — (grau) = kein Benchmark
- ⚡7.1 (blau) = nur Standard (avg. Tokens/s)
- ★8.5 (lila) = nur Planning (Total-Score)
- ⚡7.1 ★8.5 (grün) = beide gelaufen
- _bm_apply_models(history): history im BG-Thread vorgeladen, Spalten 4/5/6 je Modell befüllt; set_tooltip_column(6)
- _bm_refresh_hints(): aktualisiert nur Hint-Spalten ohne Ollama-Reload; wird nach Benchmark aufgerufen
- Bugfix: _bm_is_vision_model von @staticmethod auf @classmethod umgestellt — ControlCenterApp war im GLib-Idle-Kontext nicht auflösbar → nur 2 Modelle wurden angezeigt
- Robustheit: size-Check via isinstance(size, (int, float)) für Ollama-Modelle ohne Größenangabe

2026-03-02 — Strukturierte Security-Scan-Ergebnisse (Phase 1)

brainy/commands/security.py:
- VulnScanCommand.execute(): speichert _scan_results (List[VulnerabilityReport]), _scan_warnings und _merged_count nach Deduplication
- SecretScanCommand.execute(): speichert _secret_results (List[dict]) nach Findings-Sammlung

brainy/api/server.py:
- ScanRequest Pydantic-Modell (path, workspace)
- _resolve_scan_path() Hilfsfunktion für absolute/relative Pfadauflösung
- _make_mock_app() modulweiter Mock-App-Factory für REST-Endpoints
- POST /api/scan/vuln — führt VulnScan aus, gibt JSON zurück (total, merged, tool_summary, reports[], warnings[])
- POST /api/scan/secrets — führt SecretScan aus, gibt JSON zurück (total, findings[])
- run_slash_command() emittiert scan_result SSE-Event nach /vuln-scan und /secret-scan

clients/vscode/src/extension.ts:
- DiagnosticCollection llmgui-scan erstellt und per subscriptions verwaltet, an ChatViewProvider weitergegeben

clients/vscode/src/ChatViewProvider.ts:
- ScanReport Interface + applyDiagnostics() Funktion (CVSS → DiagnosticSeverity, byFile-Gruppierung)
- _scanDiagnostics Parameter im Konstruktor
- case 'scan_result': empfängt Reports vom Webview, befüllt VS Code Problems-Panel

clients/vscode/media/webview.js:
- case "scan_phase": animierter Spinner-Card (running → done mit ✓)
- case "tool_missing": rote Fehlerkarte mit Tool-Name und Install-Hint
- case "scan_result": forwarded Reports per vscode.postMessage an Extension-Host

2026-03-02 — Planning-Benchmark: Vision-Filter, SHA256-Fix, Prompt-Verbesserungen

llmgui-control.py:
- _BM_SKIP_PATTERNS: Vision/Multimodal-Modelle (llava, moondream, -vision, -vl, …) werden im Planning-Benchmark standardmäßig nicht vorausgewählt — sie können keine Python-Coding-Aufgaben lösen
- _bm_is_vision_model(): Pattern-Matcher auf Modellnamen (case-insensitive)

benchmark/planning_benchmark.py:
- Schritt 3: expliziter hashlib.sha256().hexdigest()-Aufruf + "genau 64 Hex-Zeichen" verhindert dass Modelle SHA1 (40 Zeichen) verwenden

2026-03-02 — Planning-Benchmark Fixes, checkov 3.2.506

benchmark/fixtures/index.html:
- Apache-Sort-Links (?C=N;O=D) entfernt — sauberes, minimales HTML verhindert HTML-Parsing-Fehler bei deepseek-r1:14b, deepseek-coder:6.7b, llama3.2-vision:11b

benchmark/planning_benchmark.py:
- PROMPT_TEMPLATE Schritt 5: explizites print()-Beispiel mit os.path.basename() — kein vager "Gib Pfade aus"-Text mehr (Fix für qwen2.5-coder:7b)
- PROMPT_TEMPLATE Schritt 7: klärt dass venv-Befehle nur gedruckt, nicht ausgeführt werden (Fix für deepseek-coder-v2:16b, mistral-nemo)
- FIX_PROMPT_TEMPLATE: Hinweise zu absolutem Pfad in os.walk() und zwingender print()-Ausgabe ergänzt

requirements-sec-tools.txt, build_sec_tools.sh:
- checkov 3.2.0 → 3.2.506 (stark veraltete Version aktualisiert)

2026-03-02 — Tests, /format CSS/SCSS/HTML/YAML

tests/test_security_phase2.py:
- TestCVEDeduplication: 10 neue Unit-Tests für _deduplicate_reports() — identische CVE/GHSA/PYSEC-IDs, höchster CVSS, Tool-Merge, case-insensitive, Tool-spezifische IDs (B601 etc.) unberührt

brainy/commands/analysis.py:
- FormatCommand._JS_EXTS erweitert: .css .scss .less .html .htm .yaml .yml
- prettier mit --ignore-unknown behandelt alle neuen Typen automatisch

2026-03-02 — CVE-Deduplication, /format mit prettier, Install-Fixes

brainy/commands/security.py:
- _deduplicate_reports(): Findings mit identischer CVE-/GHSA-/PYSEC-ID aus mehreren Scannern werden zusammengeführt (trivy + osv-scanner meldeten dieselbe CVE doppelt)
- Höchster CVSS-Score gewinnt, Tool-Namen werden gemergt (z.B. trivy+osv-scanner)
- Tool-spezifische IDs (B601, TAINT-PATH, …) bleiben unangetastet
- Summary zeigt 🔁 N Duplikat(e) zusammengeführt
- Deduplizierte Liste fließt in LLM-Analyse und _save_reports ein

brainy/commands/analysis.py:
- /format erkennt jetzt Datei-Extension und dispatcht:
- .py/.pyi → black + isort + pyupgrade (wie bisher)
- .js/.mjs/.jsx/.ts/.tsx/.cjs/.json → prettier --write
- Verzeichnis → beides (Python-Formatter auf .py, prettier mit --ignore-unknown)
- _lint_php: tool_missing-Hinweis korrigiert (curl phpstan.phar statt composer global require)
- _lint_js: tool_missing-Hinweis korrigiert (npm install -g --prefix "$HOME/.local")

llmgui-control.py:
- prettier zur TOOLS-Liste hinzugefügt (Code Quality, npm binary)
- prettier zu _GROUPS (qa_grid) hinzugefügt

2026-03-02 — AppSec-Toolchain: 12 neue Tools, /format, sprachübergreifendes /lint

Kernpunkt: Vollständige Integration einer SAST/SCA/IaC-Toolchain und einer Tool-Discovery-Engine die externe Binaries automatisch findet.

Neue Tools

Security Scanning (gehen in /vuln-scan und /secret-scan):

Code Quality (gehen in /complexity und /lint):

Formatierung (neuer /format-Command):

Neuer Slash-Command: /format

/format <file|dir> — Führt black + isort + pyupgrade in Sequenz aus. Bei Verzeichnissen werden alle .py-Dateien globbed (max 200), __pycache__/, venv/, dist/ und build/ übersprungen.

Tool-Discovery-Engine

brainy/tools/sec_tools.py — find_sec_tool(name) sucht jetzt in Prioritätsreihenfolge:

1. $LLMGUI_TOOLS_DIR/name.pyz
2. dist/tools/name.pyz
3. ~/.local/lib/llmgui/tools/name.pyz
4. dist/tools/name            (plain binary)
4b. ~/.local/lib/llmgui/tools/name
4c. ~/.local/bin/name         (npm --prefix, curl-Downloads)
5. shutil.which(name)         (System-PATH)
6. python -m MODULE           (Legacy-Venv-Fallback)

Schritte 4, 4b und 4c sind neu. Externe Binaries (trivy, gitleaks, osv-scanner, eslint, phpstan) werden automatisch gefunden, sobald sie in ~/.local/bin/ oder dist/tools/ landen — ohne Code-Änderung.

/lint: Sprachübergreifender Dispatch

LintCommand dispatcht jetzt nach Datei-Extension:

• .sh/.bash/.zsh/.ksh → shellcheck (--format=gcc)
• .php/.phtml → phpstan (analyse --no-progress --error-format=raw)
• .js/.mjs/.jsx/.ts/.tsx/.cjs → eslint (--format=stylish)
• Default → Python-Pipeline (flake8/ruff/pylint)

/complexity: xenon + lizard

ComplexityCommand dispatcht jetzt:
- .py-Datei → radon (Details) + xenon (Thresholding)
- Directory / Nicht-Python → lizard (CCN > 15, warnings-only)

Control Center: Tools & Config Tab

• Per-Row-Status (Spalte 5): ⏳ läuft… / ✓ Fertig / ✗ Fehler (rc=X) / ⊘ Abgebrochen
• Status-Update via GLib.idle_add aus Background-Thread; nach Erfolg automatischer _check_status()-Refresh
• Sudo nur wenn nötig: _build_sec_tools_install() prüft Beschreibbarkeit der Zielverzeichnisse
• Gefixter Install-Commands: trivy (Aquasecurity curl-Script), osv-scanner (GitHub-Release binary), phpstan (phar curl), eslint (npm --prefix "$HOME/.local")

.pyz Build System

build_sec_tools.sh verwaltet jetzt 15 Tools (neu: xenon, lizard, checkov, black, isort, pyupgrade). Versionen in requirements-sec-tools.txt gepinnt.

2026-03-01 — Benchmark: Correctness-Checks verbessert

Diagnose: Analyse aller bisher gelaufenen Benchmark-Runs ergab zwei systematische Fehler in der Correctness-Verifikation.

Bug 1: SHA256 nie erkannt (betraf fast alle Modelle)

verify_execution() prüfte, ob der rohe 64-Zeichen-Hex-Hash im stdout vorkommt. Der Prompt fragte aber nur "gib aus, ob die Prüfsumme stimmt" — LLMs gaben also SHA256 verified: True aus, nicht den Hash selbst. Einzige Ausnahme: thirdeyeai/Qwen2.5-Coder-7B druckte den Hash zufällig mit.

Fix planning_benchmark.py: Aufgabe 3 im Prompt explizit erweitert:

"Gib den Hash im Format SHA256: <64-Zeichen-Hex-Hash> aus"

Bug 2: Kommaformatierte Zahlen nicht erkannt

biggest_bytes_correct und most_lines_count_correct prüften str(n) in stdout. LLMs geben Zahlen teils als 1,234,567 aus — dann schlägt "1234567" in stdout fehl.

Fix planning_benchmark.py: Neue Hilfsmethode _int_in_stdout(n_str, stdout):
- Prüft zuerst auf plain n → danach auf f"{n:,}" (kommaformatiert)
- Gilt für biggest_bytes_correct und most_lines_count_correct

Verbleibende offene Frage

Modelle wie qwen2.5-coder:14b und llava:13b laufen erfolgreich durch, scheitern aber an allen 4 restlichen Checks (Dateiname, Bytes, Zeilen). Ursache unklar — vermutlich andere Traversal-Logik führt zu anderen Ergebnissen. Zur Diagnose: exec_stdout (erste 2000 Zeichen) wird jetzt in planning_results_*.json mitgespeichert.

llmgui-control.py:
- exec_stdout[:2000] als Feld in jedem Ergebnis-JSON-Eintrag

2026-03-01 — Benchmark-Scoring: Ergebnis-first

Kernthese: Ein schöner Plan und eleganter Code taugen nichts, wenn das Ergebnis falsch ist.

Neues Scoring-Schema

Das Planning-Benchmark-Scoring wurde grundlegend überarbeitet. Correctness — ob das Skript die richtigen Werte in den Output schreibt — ist jetzt mit 40% das dominante Kriterium.

planning_benchmark.py:
- Neues 6-dim-Gewichtungsschema (WEIGHTS): Correctness 40%, Unit-Tests 20%, Implementation 15%, Adherence 10%, Planning 10%, Quality 5%
- Neues 5-dim-Fallback (WEIGHTS_5): wenn nur Unit-Tests laufen (kein Correctness): UT 40%
- Neues 4-dim-Fallback (WEIGHTS_4): reine Heuristik ohne Ausführung: Impl 40%
- score() bekommt neuen Parameter correctness_score=None
- export_markdown() zeigt das jeweils aktive Gewichtungsschema

llmgui-control.py:
- bm.score() wird jetzt mit correctness_score=corr aufgerufen
- Score-Anzeige im Live-Output zeigt Correctness oben mit ← 40%-Hinweis
- Dimensionsbezeichnung im Output: 6-dim, Ergebnis-first / 5-dim, UT-Proxy / 4-dim, Heuristik

Recalculated Results

Alle bisher gelaufenen Benchmark-Runs wurden mit der neuen Formel nachberechnet und in benchmark/planning_results_recalculated.json gespeichert. Das JSON enthält total_score (neu) und total_score_old (Vergleich) sowie ein scoring_mode-Feld.

2026-03-01 — Benchmark: Alle Modelle – letzter Stand

llmgui-control.py:
- Neue Combo-Option "Alle Modelle – letzter Stand" in der Benchmark-Ergebnisauswahl
- Kombiniert alle planning_results_*.json-Dateien, dedupliziert nach Modellname (neuester Run gewinnt)
- Sofort sichtbar nach jedem Benchmark-Run (automatisches Refresh der Combo)

2026-03-01 — Radar Chart: Interaktive Legende

llmgui-control.py:
- Klick auf Einträge in der Radar-Chart-Legende blendet das jeweilige Modell ein/aus
- Sofortiges visuelles Feedback ohne Neuzeichnen des gesamten Charts
- Koordinierte Ein-/Ausblendung von Polygon + Marker pro Modell

2026-03-01 — Live Output: Word-Wrap + Progress

llmgui-control.py:
- Live-Output-Bereich im Benchmark-Tab bricht lange Zeilen jetzt korrekt um
- Progress-Indikator zeigt aktuelles Modell und Phase (z.B. "Generiert Code … / Ausführung: 2 Versuche · Scoring …")

2026-03-01 — Fix: GTK ListStore int overflow (>2 GB Modelle)

llmgui-control.py:
- Modellgrößen >2 GB führten zu einem int overflow im GTK ListStore
- Fix: Größen werden jetzt als GLib.TYPE_INT64 (64-bit) gespeichert statt Standard-int

2026-03-01 — ARCHITECTURE.md + erste Benchmark-Ergebnisse

• ARCHITECTURE.md mit vollständiger Modul-Map und Datenfluss-Dokumentation hinzugefügt
• Erste Planning-Benchmark-Ergebnisse dokumentiert

2026-02-xx — VRAM-Auto-Detect via SSH

llmgui-control.py:
- Automatische Erkennung des GPU-VRAMs des Remote-Ollama-Servers dana via SSH + nvidia-smi
- VRAM-Gesamtkapazität und -Auslastung pro Modell in der Modell-Liste
- Kein manuelles Eintragen von VRAM-Werten mehr nötig

2026-02-xx — Planning Benchmark: Unit-Tests + Radar Chart

planning_benchmark.py:
- Unit-Test-Suite (test_generated.py) für automatisierte Verifikation der generierten Lösung
- run_unit_tests(): Führt pytest gegen Artefakte im work_dir aus, setzt Ground-Truth als Env-Vars
- unit_test_score fließt in den Gesamt-Score ein (war Vorläufer des aktuellen 6-dim-Schemas)

llmgui-control.py:
- Radar-Chart-Visualisierung der Score-Dimensionen pro Modell
- Score-Verlaufsgraph über mehrere Runs

2026-02-xx — Planning Benchmark: Ground Truth + Correctness

planning_benchmark.py:
- establish_ground_truth(): Führt reference_solution.py aus, extrahiert SHA256, größte Datei, meiste Zeilen
- verify_execution(): Vergleicht LLM-Stdout gegen Ground-Truth-Werte (5 binäre Checks)
- correctness_score (0–10) als separates Ergebnis-Feld
- Bis zu 5 Ausführungsversuche mit automatischer Fehlerkorrektur via LLM

2026-02-xx — Planning Benchmark: Basisimplementierung

planning_benchmark.py:
- Vollständiger Benchmark-Framework: Fixture-HTTP-Server, Code-Generierung, Ausführung, Heuristisches Scoring
- 4 heuristische Dimensionen: Planning, Adherence, Implementation, Quality
- Fix-Loop: Bei Fehler wird Fehlermeldung zurück an LLM geschickt

2026-02-xx — LLM-as-Judge

planning_benchmark.py:
- judge_score(): Optionaler Judge-Modus mit separatem LLM-Modell
- 4 Qualitätsdimensionen: correctness, completeness, code_quality, robustness
- judge_total als unabhängige Qualitätsperspektive (fließt nicht in total_score ein)
- Robust gegenüber JSON-Wrapping und Markdown-Artefakten im Judge-Output

2026-02-28 — Bugfixes: Slash Commands im API-Server

Systematische Überarbeitung aller Slash Commands für korrekte Funktion im FastAPI-Server-Modus:

2026-02-28 — PHP-Security-Scanning

brainy/commands/security.py:
- Semgrep als primärer PHP-Scanner in /vuln-scan (p/php + p/secrets)
- Fallback: eigene Regex-Patterns (_parse_php()) wenn semgrep nicht verfügbar
- semgrep in requirements.txt (wird in .pyz gebundled)
- CVSS-Matrix: ERROR+HIGH=9.0, ERROR+MEDIUM=8.0, WARNING+MEDIUM=5.5, ...
- _semgrep_available(): sucht via shutil.which() dann venv-relativ

brainy/quality/code_reviewer.py:
- PHP_SECURITY_PATTERNS + .php-Branch hinzugefügt
- /review funktioniert jetzt auch für PHP-Dateien und PHP-Verzeichnisse

2026-02-xx — Local-Only Modus

brainy/llm/client.py + Server + Extension:
- Neuer localOnly-Flag: Deaktiviert alle Cloud-Fallbacks (Gemini etc.)
- Bei aktiviertem Local-Only: Fehler statt Remote-Weiterleitung
- Konfigurierbar in: ~/.llmgui/slash_commands.yaml, VS Code Extension Settings, Chat-Panel

2026-02-xx — Markdown-Export für Slash Commands

brainy/commands/:
- Slash-Command-Ergebnisse können als Markdown-Reports gespeichert werden
- Zielverzeichnis: .llmgui/ (konsolidiert, kein Streuen von .llmgui_*-Dateien mehr)
- /risk-scan speichert Ergebnisse in .llmgui/risk-scan.md

2026-02-xx — OOM-Handling + Lokaler Fallback

brainy/llm/client.py:
- Kein Retry bei OOM-Fehlern (Out-of-Memory) — sofortiger Fallback
- Lokale Modelle werden vor Gemini als Fallback probiert
- Bessere Fehlermeldungen bei VRAM-Engpässen

Ältere Einträge

Ältere Änderungen sind im Git-Log des Repositories dokumentiert:

git log --oneline