Known Issues¶

Stand: 2026-05-26

Jarvis Originalprojekt nicht direkt serverfähig¶

Status: bewertet am 2026-05-29.

Das analysierte Repository Julian-Ivanov/jarvis-voice-assistant ist ein Windows-/Desktop-Assistent mit Web Speech API im Browser, sichtbarem Playwright-Chromium, Screen Capture, lokaler Audio-Hardware, PowerShell-Launch und direkten Anthropic-/ElevenLabs-API-Abhängigkeiten.

Auswirkung: Das Originalprojekt wird nicht direkt produktiv auf Hermes betrieben. Hermes nutzt stattdessen einen eigenen backend-only Voice-Pilot mit /voice/health, /voice/session und /voice/message.

Aktualisierung 2026-05-29: Der Voice-Pilot routet Textnachrichten nun vom Lanstyle AI Gateway an den Nous Hermes Agent Core. Das loest nicht die lokale Audio-/Wakeword-/TTS-Frage; diese bleibt bewusst Aufgabe des Voice-Clients oder eines dedizierten Voice-Terminals.

Nous Hermes Core noch nicht public exposed¶

Der Nous Hermes Core läuft intern auf 127.0.0.1:8642 im LXC lanstyle-hermes-01. Das ist beabsichtigt. Public Exposure, DNS/NPM oder Teams-Livebetrieb brauchen separate Freigabe und Security-Prüfung.

Auswirkung: OpenWebUI, Teams und Voice-Clients sollen den Lanstyle Gateway nutzen, nicht direkt den Core.

Offen: echter Audio-End-to-End-Test mit Mikrofon/Lautsprecher auf einem separaten Gerät.

Hermes Memory Pflege erforderlich¶

Status: aktiv seit 2026-05-30.

Hermes nutzt Obsidian/Qdrant als kuratierte Knowledge-Schicht. Das funktioniert für bestätigte Betriebsfakten, kann aber bei veralteten oder ungenauen Notizen falsche Sicherheit erzeugen.

Regel: Neue Infrastruktur-Fakten müssen mit confidence, source_system und möglichst observed_at gepflegt werden. Unsichere Einträge dürfen nicht als bestätigte Fakten erscheinen. Secrets dürfen nie in Obsidian oder Qdrant landen.

Technische Schutzmaßnahme: Der Gateway fordert den Nous Core explizit auf, bei fehlendem Kontext unsicher zu melden und keine direkten Shell-/Systemtool-Empfehlungen für Infrastrukturänderungen zu geben.

Update 2026-06-02: Fuer Multi-Kunden-Retrieval gibt es eine Offline-Validation ohne Secrets/Deploy: agent-runtime/scripts/validate-hermes-retrieval.py --mode fixture. Sie prueft TecMed, SGO, SGJ, generische UDM-Fragen, Kurzfragen wie Kunde? und blockiert Lanstyle-Live-Infra als Kunden-Fallback.

Der authentifizierte Browser-End-to-End-Test wurde am 2026-05-26 erfolgreich über https://ai.lanstyle.de durchgeführt.

Validiert:

Login mit bestehendem Benutzer
Modellliste sichtbar mit 11 Modellen
Modellwahl litellm.lanstyle/agent-stable
Chat über Open WebUI mit sichtbarer Antwort OK OpenWebUI E2E
SearXNG über https://search.lanstyle.de/search?... liefert Ergebnisse

Einschränkung: Datei-Upload, Open-WebUI-Toolausführung aus dem Chat und längere Multi-Tab-Sessions wurden in diesem Lauf nicht tief getestet.

Status: backendseitig validiert und in OpenWebUI als Banner eingetragen am 2026-05-27.

Der Banner OpenCode Zugriff ist in der nativen OpenWebUI-Konfiguration ui.banners hinterlegt und verweist auf /opencode-access. Der Link enthaelt keine Token, keine Delivery-ID und keine Query-Parameter.

Einschraenkung: Der echte Browser-Klicktest mit angemeldeter Benutzer-Session muss von einem Client innerhalb der bestehenden NPM Access List erfolgen. Die Access List wurde bewusst nicht erweitert.

`lanstyle/agent` finish=length / leerer sichtbarer Content¶

lanstyle/agent routet korrekt auf qwen3.6:35b-a3b, endet aber bei Standard-Requests ohne think:false reproduzierbar mit leerem content, Reasoning-Content und finish=length, wenn das Output-Budget zu klein ist.

Auswirkung: Als alleiniger OpenCode-/Open-WebUI-Default ist lanstyle/agent aktuell nicht robust genug.

Status: OpenCode und Open WebUI sind auf lanstyle/agent-stable als produktiven Default gesetzt. lanstyle/agent und lanstyle/agent-nothink sind seit 2026-06-08 nicht mehr Teil der produktiven LiteLLM-Runtime-Liste.

Ergaenzung 2026-06-08: Der fruehere Hermes-Router lanstyle/ai wurde aus der produktiven LiteLLM-Modellliste entfernt. Hermes bleibt als separater Spezialdienst/LXC erhalten, ist aber nicht mehr Standardpfad fuer OpenCode oder OpenWebUI.

Erkenntnis 2026-05-26/27: Direkte Ollama-Tests zeigen dasselbe Verhalten. Top-Level think:false behebt den sichtbaren Content bei kleinen Budgets; options.think=false und reine Prompt-Hinweise reichen nicht. LiteLLM kann think:false durchreichen, wenn Clients es als Top-Level-Feld oder extra_body.think=false senden.

Empfehlung: lanstyle/agent separat mit einer explizit getesteten think:false-Policy oder einem eigenen No-Think-Alias nacharbeiten, aber nicht mitten im Betrieb als Default verwenden.

Status No-Think-Alias: Der experimentelle Alias war fuer Admin-/Evaluationstests nutzbar, wurde aber zur Reduktion der Modellverwirrung aus der produktiven Runtime entfernt. Bei Bedarf muss er als klar separater Testalias wieder eingefuehrt werden, nicht als Benutzerdefault.

MCPHub OAuth-Register EROFS¶

MCPHub-Logs enthielten ältere EROFS-Fehler bei /oauth/register mit Schreibversuch auf /app/mcp_settings.json.

Status: Am 2026-05-26 wurde mcp_settings.json nach Backup schreibbar in den MCPHub-Container gemountet und auf dem Host auf 0600 root:root gesetzt. MCPHub wurde kontrolliert neu gestartet; danach wurden keine neuen EROFS-Fehler beobachtet.

Empfehlung: Weiter beobachten. Falls wieder OAuth-Register-Probleme auftreten, MCPHub-Logs und Datei-Persistenz prüfen, aber keine Direct-SQLite- oder NPM-Workarounds nutzen.

OpenCode-MCP-Token Source of Truth¶

Status: erledigt am 2026-05-26.

Der aktive OpenCode-MCP-Token fuer Maximilian liegt in Vaultwarden als Lanstyle / OpenCode MCP Token / maximilian-eberhardt-mbp-pro-max. Der fruehere Bootstrap-Token ist serverseitig deaktiviert und liefert 401.

Rest-Risiko: Fuer weitere Benutzer muessen eigene Tokens nach Schema vorname-nachname-client erzeugt, in Vaultwarden abgelegt und nach erfolgreichem Test einzeln freigegeben werden.

SearXNG Engine-CAPTCHA und Timeouts¶

SearXNG meldet wiederkehrende DuckDuckGo-CAPTCHA-Fehler sowie einzelne Brave-/Wikidata-Timeouts.

Auswirkung: Suchanfragen über search.lanstyle.de liefern HTTP 200, einzelne Engines können aber unvollständige Ergebnisse liefern.

Empfehlung: Engine-Auswahl, Rate Limits und ggf. weniger aggressive parallele Abfragen separat optimieren.

Controlled Execution produktive Writes stark begrenzt aktiv¶

Status: bewusst eingeschraenkt.

Der Controlled Execution Layer ist fuer Approval, Backup, Audit, Verification und Rollback aktiv. Neben Mock und Export-only Aktionen sind aktuell eng begrenzte Proxmox-Test-Writes erlaubt: proxmox:set_lxc_description und proxmox:rollback_set_lxc_description fuer LXC 121 mit exakt erwarteten Zielzustaenden.

Naechster Schritt: weiterer produktiver Low-Risk-Write nur nach separater Freigabe. Sinnvoll ist eine einzelne NetBox-Testobjekt-Beschreibungs- bzw. Tag-Aenderung.

NetBox Test-Write Rechte¶

Status: behoben am 2026-05-26.

Der Controlled Execution Versuch netbox:test_write fuer den Tag ai-execution-test hat den Vorab-Export geschrieben, wurde aber von NetBox mit 403 Forbidden abgelehnt. Das Testobjekt wurde nicht erstellt.

Auswirkung: NetBox ist als Read-Ziel erreichbar, aber der aktuell genutzte Token besitzt keine ausreichenden Rechte fuer den geplanten Tag-Write.

Naechster Schritt: separat freigeben, ob ein minimal berechtigter NetBox-Test-Write-Token fuer extras.tags angelegt und in Vaultwarden/Runtime hinterlegt werden soll. Bis dahin keine weiteren NetBox-Write-Retries mit derselben Approval-ID.

Update 2026-05-26: Der minimale NetBox-Test-Write-User und Runtime-Token sind vorbereitet. Der neue Testwrite mit appr-netbox-test-write-20260526-114210 wurde erfolgreich ausgefuehrt und der Test-Tag ai-execution-test erstellt. Vaultwarden-Ablage ist noch offen, weil die lokale Vaultwarden CLI gesperrt war.

SMTP Legacy-IP `10.0.0.3` nicht erreichbar¶

Status: erklaert am 2026-05-26.

10.222.40.25:25 ist nach der Core-Service-Migration nicht mehr der aktive SMTP-Relay-Pfad. Der aktive Relay laeuft als LXC 109 auf 10.222.40.25/24, FQDN smtp.ad.lanstyle.de, und ist aus LXC 259 sowie weiteren Kern-LXCs auf TCP 25 erreichbar.

Der Healthcheck wurde auf smtp.ad.lanstyle.de:25 umgestellt und laeuft wieder gruen. Es wurde keine Firewall- oder Routing-Aenderung vorgenommen.

Details: SMTP Analyse.

Controlled Execution Failure-Audit Backup-Referenz¶

Status: behoben am 2026-05-26.

Beim fehlgeschlagenen NetBox-Testwrite wurde der Backup-Export erfolgreich geschrieben, aber der Failure-Audit-Eintrag enthielt die Backup-Referenz noch nicht. Der Controlled Execution Layer schreibt backup_reference und backup_status jetzt auch in Failure-Audits, sobald der Backup-Schritt erfolgreich abgeschlossen wurde.

Validierung: isolierte Mock-Failure-Simulation mit erfolgreichem Backup und absichtlich fehlschlagender Action. Ergebnis: Status failed, Backup-Referenz vorhanden, Backup-Datei vorhanden, keine Rollback-Referenz ohne erfolgreichen Write.

Multi-System Create noch nicht live freigegeben¶

Status: bewusst offen am 2026-05-26.

Der Workflow lanstyle-ce-test-01 ist nur als Preflight aktiv. Der spaetere Schritt proxmox:create_lxc waere der erste echte Infrastruktur-Create ueber Execution Chains und braucht vor Ausfuehrung eine separate Approval-ID, eine eigene scoped Create-Implementierung, Backup-/Export-Nachweise und eine validierte Rollback-Strategie.

Update 2026-05-26: Der Proxmox-Teil wurde mit Approval appr-chain-lanstyle-ce-test-01-create-20260526-134137 erfolgreich ausgefuehrt. Offen bleibt weiterhin der Cleanup-/Rollback-Teil fuer echte Creates, insbesondere remove_lxc, der bis zur separaten scoped Cleanup-Implementierung forbidden bleibt.

Update 2026-05-26: Der Cleanup-Preflight lanstyle_ce_test_01_cleanup_prepare ist aktiv und plan-only. Er prueft Dependency-Scope, Archivanforderungen, Cooldown und Double Confirmation, fuehrt aber keinen Cleanup aus. remove_lxc_enabled=false bleibt bewusst gesetzt.

Nicht enthalten in v1:

DNS-Records
NPM-Backend-Aenderungen
Firewall-Regeln
Kundensysteme
freie Shell- oder Root-Runner

Dependency Lock Storage¶

Status: verbessert am 2026-05-26.

Der operational aktive Lock Store wurde von JSONL-only auf SQLite mit WAL und atomaren BEGIN IMMEDIATE-Transaktionen umgestellt. JSONL bleibt als Audit-Trail erhalten. Bei SQLite-Problemen soll der Lock-Layer fail-closed arbeiten und nicht automatisch auf ungesicherte JSONL-Writes zurueckfallen.

Update 2026-05-26: Fuer orphaned, failed-release, stale, expired und emergency-hold Locks gibt es einen approval-basierten Recovery-Flow. Blind Release und Hard Delete bleiben verboten.

Runtime Backup Validation Sichtbarkeit¶

Status: verbessert am 2026-05-26.

Der produktive Read-only-Golden-Path runtime_backup_validation_v1 laeuft und erzeugt JSON-/Markdown-Reports. Der erste Lauf ergab 5 grüne und 5 rote Komponenten.

Rot bedeutet hier nicht automatisch, dass physisch kein Backup existiert. Es bedeutet, dass der Backup-Nachweis aus Sicht der Agent Runtime nicht sichtbar oder nicht belastbar ist.

Nicht sichtbar waren:

Agent Runtime Backup-Pfade
Qdrant Snapshots
Open WebUI Backups
GB10/Ollama Config Backups
MkDocs/Gitea Doku-Backups

Naechster Schritt: Backup-Pfade zentral sichtbar machen oder je Zielsystem read-only Metadaten-Exporter ergaenzen. Danach den Golden Path erneut ausfuehren und Restore-Readiness neu bewerten.

Update 2026-05-26: Die roten Nachweis-/Sichtbarkeitsluecken wurden ueber read-only Metadaten-Snapshots geschlossen. Der Zwischenstand war 9 gruen, 1 gelb, 0 rot.

Gelb bleibt gb10_ollama_config_backups, weil der neueste sichtbare GB10/Ollama-Backup-Nachweis gruppenschreibbar ist (-rw-rw-r--). Das ist kein Restore-Blocker, aber ein Hardening-Punkt.

Update 2026-05-26: GB10/Ollama-Backup-Rechte wurden ohne Inhaltszugriff gehärtet. Aktueller Status von runtime_backup_validation_v1: 10 gruen, 0 gelb, 0 rot.