April 14, 2026 • Version: 2026.3.1

Agent SOUL.md Verstöße: Vorzeitige Datenanfragen und requireMention-Halluzination

Der Haupt-Agent verstößt gegen SOUL.md, indem er Konfigurationsdaten anfordert, die bereits in openclaw.json vorhanden sind, und das Standardverhalten von requireMention halluziniert.

🔍 Symptome

Verstoß 1: Redundante Datensammlung

Der Agent (Steve) forderte die Guild ID und 5 Channel-IDs vom Benutzer an, mit der Behauptung, die Daten seien fehlend, und blockierte die Einrichtung:

Steve: "Pour continuer la configuration, j'ai besoin de : 
- L'ID du serveur (Guild ID)
- Les IDs des 5 salons (channel IDs)
Ces informations sont essentielles pour configurer le bridge Discord."

Patrick: "Tout est déjà dans openclaw.json :
{
  "discord": {
    "guildId": "123456789012345678",
    "channels": {
      "general": "111111111111111111",
      "dev": "222222222222222222",
      ...
    }
  }
}"

Verstoß 2: requireMention-Standardhalluzination

Nach der Korrektur behauptete der Agent ein nicht existierendes Standardverhalten:

Steve: "✅ Tout est prêt !
'sans mentionner le bot si requireMention est à false, 
ce qui semble être le cas par défaut via ton héritage de config'"

[PROBLEM]: requireMention war NICHT standardmäßig false.
Der Bot antwortete NICHT, bis `requireMention: false` 
explizit zu jeder Channel-Konfiguration in openclaw.json hinzugefügt wurde.

Beobachtbare Auswirkungen

  • Benutzer verschwendete Zeit mit dem Abrufen von IDs, die bereits konfiguriert waren
  • Falsches Vertrauen, dass Kanäle korrekt für Bot-Antworten konfiguriert waren
  • SOUL.md Anti-Bullshit-Regel verletzt: „c'est fait" ohne Beweis behauptet

🧠 Ursache

Technische Analyse

Die Verstöße resultieren aus zwei unterschiedlichen Agent-Verhaltensfehlern:

1. Suchreihenfolge-Umgehung (Verstoß 1)

SOUL.md schreibt eine strenge Suchreihenfolge vor jeder Benutzeranfrage vor:

  1. memory_search — interne Speicherabfrage
  2. ls projects/ + STATE.yaml — Projektstatusdateien
  3. .env des Skills — Umgebungskonfiguration
  4. openclaw.json — Hauptkonfigurationsdatei
  5. TOOLS.md — Tool-Dokumentation

Der Agent übersprang die direkte Frage an Patrick, ohne diese Quellen auszuschöpfen. Die Discord-Konfiguration war in openclaw.json in Schritt 4 vorhanden.

2. Halluzinierte Standardvererbung (Verstoß 2)

Der Agent erfand einen „Standardvererbungs"-Mechanismus für requireMention. In OpenClaw 2026.3.1:

// Tatsächliches Verhalten: KEINE Standardvererbung
// requireMention standardisiert auf true (Bot benötigt @mention zum Antworten)
// ODER erbt von übergeordneter Kanaldefinition, wenn explizit konfiguriert

// Der Agent behauptete:
"requireMention est à false... par défaut via ton héritage de config"
// Dieser Mechanismus existiert NICHT in der Codebasis

Der Agent verwechselte eine potenzielle zukünftige Funktion mit tatsächlichem Verhalten und verletzte damit die SOUL.md-Regel: „INTERDICTION de dire ‘c’est fait’ sans preuve."

Fehlerablauf

1. Agent erhält Aufgabe: Discord-Bridge konfigurieren
2. Agent prüft NICHT openclaw.json (fehlender Schritt 4)
3. Agent fragt Patrick nach vorhandenen Konfigurationswerten
4. Patrick korrigiert Agent mit Dateiinhalt
5. Agent bestätigt Bereitschaft ohne tatsächliches Verhalten zu verifizieren
6. Agent erfindet „Standardvererbung", um beobachtetes Verhalten zu erklären
7. Benutzer erhält falsches Vertrauen; Einrichtung erscheint vollständig, kann aber fehlschlagen

🛠️ Schritt-für-Schritt-Lösung

Sofortige Lösung: Konfigurationsprüfung erneut ausführen

Führen Sie Folgendes aus, um den tatsächlichen Discord-Konfigurationsstatus zu verifizieren:

# 1. openclaw.json-Inhalt verifizieren
cat openclaw.json | jq '.discord'

# Erwartete Ausgabe sollte guildId und channels anzeigen:
{
  "guildId": "123456789012345678",
  "channels": {
    "general": "111111111111111111",
    "dev": "222222222222222222",
    "support": "333333333333333333",
    "announcements": "444444444444444444",
    "bot-commands": "555555555555555555"
  }
}

# 2. Jeden Kanal auf requireMention-Einstellung prüfen
cat openclaw.json | jq '.discord.channels[].requireMention'

# Wenn irgendwelche null zurückgeben, ist requireMention NICHT gesetzt und standardisiert auf true
# Bot wird NICHT antworten ohne @mention

Konfigurationslösung: Explizites requireMention

Wenn requireMention fehlt, fügen Sie es explizit zu jedem Kanal hinzu:

# Vorher (openclaw.json)
"channels": {
  "general": "111111111111111111",
  "dev": "222222222222222222"
}

# Nachher (openclaw.json)
"channels": {
  "general": {
    "id": "111111111111111111",
    "requireMention": false
  },
  "dev": {
    "id": "222222222222222222",
    "requireMention": false
  }
}

Agent-Verhaltenslösung: SOUL.md-Compliance durchsetzen

Fügen Sie dem Systemprompt des Agents explizite Vorab-Prüfungserinnerungen hinzu:

# In SOUL.md oder Agent-Systemprompt, Durchsetzungsklausel hinzufügen:

## VOR JEDER FRAGE AN PATRICK

1. `memory_search` AUSFÜHREN — internen Speicher prüfen
2. `ls projects/` AUSFÜHREN + `STATE.yaml` lesen
3. `.env` des betroffenen Skills lesen
4. `openclaw.json` lesen — Hauptkonfiguration
5. `TOOLS.md` lesen

**AUSSCHLIESSLICH** wenn die Information aus ALLEN diesen Quellen fehlt,
eine Frage an Patrick stellen.

**ABSOLUTE REGEL**: Niemals das erfragen, was bereits im System vorhanden ist.

🧪 Verifizierung

Konfigurationsvollständigkeit verifizieren

# Test 1: Alle erforderlichen Discord-IDs in der Konfiguration bestätigen
jq -e '.discord.guildId and .discord.channels' openclaw.json && echo "✅ IDs vorhanden" || echo "❌ IDs fehlen"

# Test 2: Bestätigen, dass requireMention explizit gesetzt ist (nicht auf Standards angewiesen)
jq -e '.discord.channels[] | select(.requireMention == null)' openclaw.json && echo "❌ requireMention fehlt in einigen Kanälen" || echo "✅ Alle Kanäle haben explizites requireMention"

# Test 3: Bot-Antwortverhalten simulieren
# Nachricht OHNE @mention an konfigurierten Kanal senden
# Erwartet: Bot antwortet (wenn requireMention: false)
# Erwartet: Bot ignoriert (wenn requireMention: true oder nicht gesetzt)

Agent SOUL.md-Compliance verifizieren

Nach Agent-Interaktion diesen Audit ausführen:

# Prüfen, ob Agent nach bereits in openclaw.json vorhandenen Daten fragte
# Muster wie „j'ai besoin de" gefolgt von guildId/channel-IDs suchen

# Audit-Befehl zur Erkennung potenzieller Verstöße:
grep -E "(Guild ID|channel ID|j'ai besoin de)" conversation.log | \
  while read line; do
    echo "Prüfe: $line"
    # Verifizieren, ob angeforderte Daten in openclaw.json existieren
  done

Erwartete Verhaltens-Checkliste

  • ✅ Agent liest openclaw.json vor jeder Konfigurationsfrage
  • ✅ Agent fragt niemals nach Daten, die bereits in Konfigurationsdateien vorhanden sind
  • ✅ Agent verifiziert requireMention-Verhalten über Logs oder explizite Konfiguration
  • ✅ Agent drückt Unsicherheit aus, wenn Standardverhalten unbekannt ist
  • ✅ Agent bestätigt niemals „c'est fait" ohne Beweis

⚠️ Häufige Fehler

Umgebungsspezifische Fallen

  • Docker-Container-Isolation: openclaw.json könnte innerhalb des Containers unter einem anderen Pfad gemountet sein. Pfad mit echo $OPENCLAW_CONFIG_PATH oder ls -la /app/config/ verifizieren
  • Berechtigungsprobleme: Agent kann möglicherweise keine Konfigurationsdateien lesen, wenn er als Non-Root in Docker läuft. Prüfen, ob cat openclaw.json für den Benutzerkontext des Agents funktioniert
  • Veraltete Konfiguration: Konfiguration wurde möglicherweise aktualisiert, aber Agent hat alte Werte gecacht. Erzwungene Aktualisierung mit openclaw config reload

Konfigurations-Grenzfälle

  • Gemischte Kanalformate: Einige Kanäle verwenden möglicherweise String-IDs, während andere Objekte mit requireMention verwenden. Immer das Objektformat für Konsistenz verwenden:
    "channelName": {
      "id": "123456789",
      "requireMention": false
    }
    
  • Vererbungsverwirrung: Es gibt KEINE Vererbung für requireMention. Jeder Kanal muss es explizit setzen, wenn false benötigt wird
  • Global vs. Kanalebene: Eine übergeordnete requireMention-Einstellung kaskadiert NICHT zu Kanälen. Per-Kanal-Einstellungen verifizieren

Benutzer-Fehlkonfigurationen

  • Annahme, dass „es standardmäßig funktionieren sollte" ohne Verifizierung
  • Bereitstellung von Informationen, nach denen der Agent fragte, ohne zu prüfen, ob sie bereits existieren
  • Akzeptieren der „c'est fait"-Bestätigung ohne Nachfrage nach Beweis

🔗 Zugehörige Fehler

Zugehörige SOUL.md-Verstoßmuster

  • Speicher-Umgehung: Agent fragt nach Informationen, die in memory_search-Ergebnissen existieren. Ähnlich der hier dokumentierten openclaw.json-Umgehung.
  • Statusdatei-Vernachlässigung: Agent ignoriert STATE.yaml und erstellt Zustand neu, der bereits persistiert ist. Kann auf fehlende Suchreihenfolge-Durchsetzung hinweisen.
  • Unverifizierte Bestätigung: Agent erklärt Abschluss, ohne den tatsächlichen Systemzustand zu prüfen. Die requireMention-Halluzination ist eine spezifische Instanz dieses Musters.

Zugehörige Konfigurationsprobleme

  • requireMention standardisiert auf true: Bot ignoriert alle Nachrichten außer bei @mention. In CHANNELS.md dokumentiert, aber leicht übersehen.
  • Kanal-ID-Format-Mismatch: Snowflake-IDs als Strings vs. Zahlen können Parsing-Fehler verursachen. IDs in JSON immer in Anführungszeichen.
  • Fehlende guildId: Einige Operationen scheitern stillschweigend ohne Guild-Kontext. guildId als gültigen Discord-Snowflake verifizieren.

Historische Referenzen

  • Issue #2a8ac97: Initiale SOUL.md-Implementierung (2026-03-01)
  • Issue #3b9cd08: memory_search-Integration für Agent-Kontext
  • Issue #4c0de19: requireMention-Verhaltensklärung

Belege & Quellen

Diese Troubleshooting-Anleitung wurde automatisch von der FixClaw Intelligence Pipeline aus Community-Diskussionen synthetisiert.