Zum Inhalt

Hermes Operationalisierung

Stand: 2026-06-02

Kurzfazit

Hermes ist nicht mehr nur als Context-/Retrieval-Schicht geplant. Der operative Schwerpunkt liegt jetzt auf Qualitaetssicherung: Kundenscope erzwingen, Obsidian/Qdrant-Treffer validieren, OpenWebUI/OpenCode gegen Datenvermischung absichern und serverseitige Knowledge-Jobs kontrolliert aktivieren.

Diese Seite beschreibt den aktuellen Arbeitsplan nach den Live-Fixes vom 2026-06-02. Aeltere Aussagen wie "nur vorbereitet" gelten nur noch dort, wo sie explizit so markiert sind.

Prioritaetenstatus

Prioritaet Komponente Status
1 Retrieval Scope Validation aktiv priorisiert; Kundenscope muss vor Antwortbildung greifen
2 Obsidian Reindex Service vorbereitet; nur nach Snapshot und Dry-Run produktiv schreiben
3 Retrieval Validation Service aktiv als read-only Validation-Job/testbarer Codepfad
4 OpenCode / MCP Context Tools Remote MCP ist nutzbar; Fokus ist Tool-Sichtbarkeit, Voice-Scope und kompakte Responses
5 OpenWebUI Modellsicht live teilbereinigt; Normaluser-Sicht weiter verifizieren
6 Memory Candidate Queue file-backed v1 vorbereitet
7 Fact Review Queue ueber Candidate Queue Review-Events vorbereitet
8 Confirmed Fact Pipeline Governance und Queue-Statusmodell vorbereitet
9 Retrieval Metrics Dashboard JSON-Report-Generator vorbereitet

Neuer Qualitaetsfokus

OpenWebUI und OpenCode duerfen keine Kunden- oder Systemdaten vermischen. Jede retrieval-basierte Antwort muss:

  • einen erkannten oder explizit abgefragten customer_context haben, wenn die Frage kundenspezifisch ist
  • bei unklarem Scope blockieren oder nachfragen
  • confirmed, interpreted und uncertain trennen
  • Quellen und Aktualitaet sichtbar machen
  • keine historischen Inhalte als aktive Wahrheit ausgeben

Beispiele fuer Pflichtverhalten:

Frage Erwartung
"Welche UDM ist dokumentiert?" Scope-Rueckfrage statt globaler Mischantwort
"Welche UDM hat TecMed?" Nur TecMed-Quellen oder klarer Hinweis auf fehlende Daten
"Wie sieht der Proxmox Cluster bei TecMed aus?" Keine Lanstyle-Clusterinfos verwenden
Kunde ohne Daten "Keine bestaetigten Daten gefunden" statt Erfindung

Obsidian Reindex Service

Artefakte:

  • agent-runtime/scripts/validate-obsidian-frontmatter.py
  • agent-runtime/scripts/run-obsidian-reindex-validation.sh
  • systemd/lanstyle-obsidian-reindex.service
  • systemd/lanstyle-obsidian-reindex.timer

Default-Verhalten:

  • --dry-run
  • keine Qdrant Writes
  • Secret-Status nur als SET oder MISSING
  • Frontmatter-Validierung
  • Report unter agent-runtime/reports/knowledge

Execute-Verhalten ist absichtlich streng:

  • --execute braucht LITELLM_API_KEY und QDRANT_API_KEY
  • fehlt ein Secret, endet der Job blocked
  • nach produktivem Reindex muss Retrieval Validation laufen

Retrieval Validation Service

Artefakte:

  • agent-runtime/scripts/validate-hermes-retrieval.py
  • systemd/lanstyle-hermes-retrieval-validation.service
  • systemd/lanstyle-hermes-retrieval-validation.timer

Read-only Testfragen:

  • Wo laeuft Hermes?
  • Was ist der Unterschied zwischen Gateway und Nous Core?
  • Wie funktioniert OpenCode als AI Operations Console?
  • Welche Inhalte duerfen nicht in Obsidian?
  • Welche Qdrant Collection ist fuer Obsidian Memory vorgesehen?

Der Job schreibt nur strukturierte Validierungsberichte. Er speichert keine neuen Memory-Inhalte.

OpenCode / MCP Hermes Context Tools

hermes_context_search und hermes_session_summary_preview sind im Remote-MCP-Code vorhanden. Die Registry steht auf:

status: active_runtime_validation_required

Das bedeutet:

  • Codepfad ist vorhanden.
  • Tool ist read-only.
  • Es darf keine Infrastrukturwrites ausfuehren.
  • Remote MCP ist grundsaetzlich nutzbar.
  • Gruen ist der Pfad erst, wenn ein echter OpenCode-/OpenWebUI-Test mit scoped Kundendaten, Quellen und Tool Listing erfolgreich ist.
  • Voice-/Device-Tokens duerfen nur erlaubte read-only Tools sehen.

OpenWebUI Modellsicht

Die fruehere Aussage "keine Live-Korrektur ausgefuehrt" ist ueberholt. Die OpenWebUI-Modellsicht wurde live verbessert; der aktuelle Fokus ist nicht mehr Aktivierung, sondern Normaluser-Verifikation und Vermeidung von Rohmodell-/Kundenmix.

Aktueller Sollzustand:

  • Normale Benutzer sehen bevorzugt lanstyle/ai als Router oder die freigegebenen Lanstyle-Aliase.
  • Experimentelle Modelle bleiben verborgen.
  • Direkte Rohprovider duerfen nicht als Normaluser-Default erscheinen.
  • Admin-Sicht darf bewusst mehr zeigen, muss aber als Admin-Sicht erkennbar bleiben.

Verifikation:

  1. Normal-User-Modellliste exportieren.
  2. Admin-Modellliste exportieren.
  3. LiteLLM Virtual-Key-Scopes vergleichen.
  4. Testfragen mit Kundenscope ausfuehren.
  5. Pruefen, ob lanstyle/ai korrekt routet und nicht halluziniert.
  6. Smoke-Test mit normalem Benutzer.

Nicht erlaubt:

  • normale User auszusperren
  • Admin-Profil heimlich zu begrenzen
  • experimentelle Modelle als Default sichtbar zu machen
  • rohe Providernamen ohne Ursache live zu loeschen

Memory Candidate Queue

Artefakt:

  • agent-runtime/scripts/memory-candidate-queue.py

V1 ist append-only JSONL:

agent-runtime/state/memory-candidates.jsonl

Unterstuetzte Aktionen:

  • enqueue
  • list
  • review

Sicherheitsregeln:

  • secret-like Text wird blockiert
  • Evidence wird nur als Fingerprint gespeichert
  • Kandidaten starten als draft
  • confirmed braucht Review-Event mit Reviewer

Fact Review Queue und Confirmed Fact Pipeline

Die Fact Review Queue ist in V1 dieselbe append-only Queue mit Review-Events.

Statusfluss:

draft -> interpreted -> confirmed
draft -> deprecated
interpreted -> deprecated
confirmed -> historical

Confirmed Facts duerfen erst nach Review nach Obsidian/MkDocs uebernommen und danach reindiziert werden. Qdrant wird nicht direkt aus ungeprueften Sessions beschrieben.

Retrieval Metrics Dashboard

Artefakte:

  • agent-runtime/scripts/retrieval-metrics-dashboard.py
  • systemd/lanstyle-retrieval-metrics.service
  • systemd/lanstyle-retrieval-metrics.timer

Der Report aggregiert:

  • Anzahl Reindex-Reports
  • Anzahl Retrieval-Validation-Reports
  • letzten Retrieval-Status
  • letzten Reindex-Status
  • letzte Retrieval Summary

Aktuelle Arbeitsreihenfolge

  1. Retrieval-Qualitaet mit Kundenscope testen.
  2. TecMed/Lanstyle/UDM/Proxmox-Negativfaelle verifizieren.
  3. Obsidian-Frontmatter und Kundendaten auf Plausibilitaet pruefen.
  4. Qdrant Reindex nur nach Snapshot und Dry-Run.
  5. OpenWebUI Normaluser-Modell-/Retrievalsicht testen.
  6. OpenCode MCP Tool Listing und read-only Toolcalls testen.
  7. Scheduled Retrieval Validation aktivieren, wenn Tests stabil gruen sind.

Stop-Kriterien

  • Secret-Fund im Obsidian Vault
  • fehlender Qdrant Snapshot vor Execute-Reindex
  • Retrieval Validation red
  • OpenCode Context Tool gibt Secretwerte oder Roh-ENV aus
  • OpenWebUI-Modellsicht wuerde normale User aussperren oder Rohprovider als Default zeigen
  • Kundenscope fehlt bei kundenspezifischen Antworten
  • Retrieval mischt Kunden oder Systeme
  • Qdrant Write ohne vorherigen Dry-Run

Naechste Schritte

  1. Live-Retrieval-Tests fuer TecMed, Lanstyle, UDM und Kunden ohne Daten durchfuehren.
  2. OpenWebUI Normaluser/Admin-Modelllistenvergleich erneut pruefen.
  3. Obsidian-Kundendaten mit customer_context/Frontmatter konsolidieren.
  4. Qdrant Dry-Run und Snapshot vorbereiten.
  5. Retrieval Validation als wiederkehrenden Job aktivieren, sobald die Negativtests stabil sind.