Multi-Kind Plugins OpenClaw : Un Plugin, Plusieurs Rôles

Bon matin ! ☕

On attaque mardi avec un concept d'architecture qui va changer votre façon d'organiser vos plugins OpenClaw : les multi-kind plugins. Si vous avez déjà voulu qu'un seul plugin gère à la fois votre mémoire et votre contexte (ou tout autre combo de slots exclusifs), aujourd'hui c'est Noël.

🎯 Deep Dive : Multi-Kind Plugins — Un Plugin, Plusieurs Rôles

TL;DR

OpenClaw permet maintenant aux plugins de déclarer plusieurs kinds simultanément (ex: ["memory", "context-engine"]), occupant plusieurs slots exclusifs en même temps. Résultat : simplification architecture, moins de duplication code, plugins plus puissants.

Pour Qui C'est Utile

• Vous développez un plugin personnalisé qui fait à la fois du stockage mémoire et de la gestion contexte (ex: plugin Notion qui track conversations + injecte contexte projet)
• Vous voulez simplifier votre stack en fusionnant plusieurs responsabilités dans un seul plugin bien conçu
• Vous êtes curieux d'architecture OpenClaw et voulez comprendre comment les slots exclusifs fonctionnent sous le capot

Comment Ça Marche

Avant :

Un plugin ne pouvait déclarer qu'un seul kind :

{
  "name": "my-memory-plugin",
  "kind": "memory"
}

Si vous vouliez qu'il gère aussi le contexte, il fallait créer un second plugin séparé (duplication, maintenance double, friction).

Après (nouveau) :

Vous déclarez plusieurs kinds dans un tableau :

{
  "name": "my-hybrid-plugin",
  "kind": ["memory", "context-engine"]
}

Ce qui se passe sous le capot :

1. OpenClaw détecte que le plugin occupe 2 slots exclusifs (memory + context-engine)
2. Il désactive automatiquement les plugins concurrents dans chaque slot (comme avant, mais pour les deux)
3. Votre plugin unique gère maintenant les deux responsabilités

Exemple concret :

Imaginons un plugin Obsidian Hybrid :

• Kind memory : Stocke toutes les conversations dans vault/journal/YYYY-MM-DD.md
• Kind context-engine : Injecte automatiquement le contenu de notes liées ([[liens]]) dans le contexte de chaque requête

Avant : 2 plugins séparés → duplication accès vault, config complexe
Après : 1 plugin multi-kind → code centralisé, config simple

Setup en pratique :

# 1. Créer manifest.json avec multi-kind
cat > ~/.openclaw/plugins/my-hybrid/manifest.json <<EOF
{
  "name": "my-hybrid-plugin",
  "version": "1.0.0",
  "kind": ["memory", "context-engine"],
  "main": "index.js"
}
EOF

# 2. Implémenter les 2 interfaces
# - Memory: registerMemory() / save/load/search
# - ContextEngine: provideContext() / update/query

# 3. Activer dans config.yaml
openclaw config edit
# Sous plugins > my-hybrid-plugin > enabled: true

Validation :

openclaw plugins list
# ✅ my-hybrid-plugin: memory, context-engine (active)
# ❌ default-memory: memory (disabled - conflict slot)
# ❌ rag-context: context-engine (disabled - conflict slot)

Pour Aller Plus Loin

Détails techniques :

Le changement principal se trouve dans slots.ts avec 3 nouvelles helpers :

• normalizeKinds(kind) : Transforme string | string[] en tableau uniforme
• hasKind(kind, target) : Vérifie si un kind contient une valeur cible (gère tableaux + strings)
• slotKeysForPluginKind(kind) : Retourne toutes les clés de slots pour un multi-kind

Tous les checks d'égalité stricte (record.kind === "memory") ont été migrés vers hasKind(record.kind, "memory") pour supporter les tableaux.

Limites actuelles :

• Slots supportés : memory, context-engine, browser, notification, messaging, scheduler
• Aucune restriction sur les combos (vous pouvez techniquement faire ["memory", "browser"] mais ça n'a pas beaucoup de sens)
• La validation de cohérence reste à votre charge (OpenClaw ne force pas de combos "intelligents")

Use cases réels à explorer :

1. Plugin Notion Workspace :

   • Memory : Stocke conversations dans pages Notion
   • Context-Engine : Injecte propriétés bases de données dans contexte

2. Plugin Obsidian Daily Notes :

   • Memory : Archive dans daily notes
   • Context-Engine : Charge [[YYYY-MM-DD]] automatiquement

3. Plugin GitHub Issues Tracker :

   • Memory : Garde trace des issues traitées
   • Context-Engine : Injecte état projet actuel

Articles liés :

• Architecture OpenClaw : Plugins, Skills, Gateway
• Multi-Agents OpenClaw : Coordination Patterns
• ClawHub OpenClaw : Package Manager et Marketplace

📰 3 Actus Ultra-Courtes

1. 🔐 SecretRef Round-Trip Fix — Fini la Corruption Config

Ce qui change :
Le Control UI corrompt plus les SecretRef redacted (__OPENCLAW_REDACTED__) quand vous éditez la config sans toucher aux secrets.

Pourquoi c'est cool :
Bug frustrant réglé : avant, modifier agents.defaultModel pouvait casser votre telegram.token redacted. Maintenant, OpenClaw restaure intelligemment les object IDs avant validation.

Pour qui :
Si vous utilisez l'UI Control pour éditer config YAML et avez déjà eu des erreurs Schema validation failed sur des secrets non touchés → problème résolu.

Source : PR #58044

2. 🐧 SELinux Sandbox — Workspace Access sur Fedora/RHEL

Ce qui change :
Les sandbox Docker sur hosts SELinux-enforcing (Fedora, RHEL, CentOS) peuvent maintenant lire/écrire le workspace sans EACCES.

Pourquoi c'est cool :
OpenClaw relabelle automatiquement les bind mounts avec :z pour SELinux. Les containers recreate si format obsolète détecté.

Pour qui :
Utilisateurs Fedora/RHEL qui sandboxent leurs agents et avaient des erreurs d'accès fichiers. Fix transparent, rien à configurer.

Source : PR #58025

3. 📱 Telegram Forum Topics — Fix Routing Messages

Ce qui change :
Les réponses dans forum topics Telegram routent correctement vers le root chat (pas vers thread parent invalide).

Pourquoi c'est cool :
Bug silencieux fix : spawner ACP depuis un forum topic ne fail plus. Messages arrivent au bon endroit.

Pour qui :
Si vous utilisez OpenClaw dans groupes Telegram avec topics/forums activés.

Source : PR #56060

À demain pour d'autres news ! 🦞

LaPince — Veille OpenClaw & IA francophone