Session Routing — Smart Multi-Session Router

Ce skill est chargé automatiquement à chaque début de session. Il analyse la demande de l’utilisateur et sélectionne l’approche la plus adaptée parmi les 3 disponibles.

🔍 Logique de Routage — Arbre de Décision

1. La demande est-elle privée / sensible ? → ✅ Profile dev (historique isolé, pas de fuite entre contextes)

2. Nécessite-t-elle un modèle différent (Claude, Gemini, autre que DeepSeek) ? → ✅ Profile dédié (chaque profile a son propre model/provider)

3. Est-ce une tâche longue, asynchrone, sans besoin de réponse immédiate ? (déploiement, analyse de logs, batch processing, monitoring) → ✅ Kanban (tâche dispatchée, peut prendre des heures)

4. Est-ce une conversation parallèle, rapide, dans le même DM Telegram ? (recherche de papiers, veille, questions diverses) → ✅ /topic (gratuit, sessions isolées, zéro configuration)

5. Tout le reste (conversation normale, demande unique) → ✅ Rester dans la session courante (par défaut)

📋 Guide par type de demande

🔧 Commandes Rapides

Topics Telegram (dans ce DM)

/topic on              → Activer les topics
/topic new "Nom"       → Créer un topic
/topic list            → Lister les topics
/topic <nom>           → Basculer sur un topic

Kanban

hermes kanban create "description" --assignee default
hermes kanban list
hermes kanban show <id>
hermes kanban complete <id>

Profiles

travail chat           → Lancer Hermes en mode Travail
dev chat               → Lancer Hermes en mode Dev
profile use travail    → Basculer le profile par défaut

📝 Logging & Rollback

Toute modification système suit la règle Backup → Modify → Verify → Log → Rollback :

1. Backup first → ~/.hermes/backups/pre-<date>/
2. Modify → effectuer le changement
3. Verify → tester que le changement fonctionne (commande, service, accès)
4. Log to Google Sheet → python3 ~/openclaw-workspace/scripts/log-change-sheets.py "Action" "Détails" "Catégorie" "✅" — NE LOGGER QUE si l’étape 3 est OK
5. Rollback if failed → restore from latest backup, log l’échec avec 🔴

Script: ~/openclaw-workspace/scripts/log-change-sheets.py Aussi sous: devops/sysguard/scripts/log-change-sheets.py Sheet: https://docs.google.com/spreadsheets/d/1U-GaOz6qmQaBP8NRwwRlVqY67wT_a1O7cA8dp60GGYs

Routage Multi-Bot

Si tu as plusieurs bots Telegram (support, alertes, commandes, etc.) et veux router les messages vers le bon bot selon le contexte, voir le skill complémentaire :

• telegram-multi-bot-routing — routage EXTERNE (quel bot expédie le message)
• Ce skill session-routing — routage INTERNE (Topics/Profiles/Kanban dans le même bot)

Les deux peuvent coexister : le routage externe choisit le bot, le routage interne choisit le topic/profile.

Référence : Guide de configuration complet

Le guide pas-à-pas pour reproduire toute l’infrastructure multi-session + logging sur un nouveau VPS est disponible dans le skill sysguard :

• devops/sysguard/references/full-reproduction-guide.md — 9 modules (52+ étapes) avec commandes exactes, vérifications et pièges
• Modules pertinents pour le routage : 3.Profiles, 4.Kanban, 5.Topics, 6.Routage
• Source : feuille 📖 Guide du Sheet central 1U-GaOz6qmQaBP8NRwwRlVqY67wT_a1O7cA8dp60GGYs

⚠️ Pièges Connus

Topics Telegram

• /topic on doit être tapé UNE FOIS dans le DM Telegram (pas envoyé par l’agent)
• Les topics sont une fonctionnalité native Telegram — Hermes ne fait que les exposer
• Chaque topic = une session Hermes isolée, mais TOUS partagent le même turn budget et le même modèle

Kanban

• Kanban ne fonctionne pas sans gateway — le dispatcher tourne dans le gateway toutes les 60s
• Si gateway est arrêté, les tâches restent en “ready” indéfiniment
• kanban dispatch_in_gateway: true par défaut (config.yaml)
• Créer les tâches avec --assignee default pour le dispatcher les prenne
• Max 5 échecs de spawn avant auto-block de la tâche

Profiles

• --clone copie la config DU DEFAULT, pas d’un autre profile
• Les profiles partagent les clés API (même .env) mais les sessions sont isolées
• Chaque profile a ses propres skills/sessions/mémoire
• Pour changer le modèle d’un profile : hermes config set model.default <modele> dans le profile
• Ne pas oublier chmod 600 ~/.hermes/.env après création (le clone hérite des permissions du parent)

Ordre d’activation

1. Topics Telegram — immédiat, juste /topic on
2. Kanban — hermes kanban init une fois, puis gateway doit tourner
3. Profiles — créer avec --clone, personnaliser SOUL.md si besoin

🪟 Session CLI persistante (tmux)

Quand tu utilises Hermes CLI via SSH/Mosh, la session Hermes meurt si la connexion réseau est interrompue (SSH drop, laptop fermé, réseau instable). Solution : faire tourner Hermes CLI dans une session tmux.

Connexion avec recovery automatique

# Option 1 : alias h (recommandé)
alias h="tmux new-session -A -s hermes"
h  # Attache ou crée la session hermes → puis lancer `hermes`

# Option 2 : manuelle
ssh vps-vmi2802045
tmux attach -t hermes 2>/dev/null || tmux new -s hermes
hermes

Après une déconnexion SSH :

1. Re-SSH → tmux attach -t hermes (ou h)
2. Hermes CLI est exactement là où tu l’as laissé
3. Les messages et l’historique sont intacts

Mosh + tmux = combo optimal

Les deux sont complémentaires. Tmux garde le process Hermes côté serveur. Mosh empêche les déconnexions intempestives côté client.

Installations vérifiées

• VPS : tmux 3.2a + mosh 1.3.2 installés (UDP 60000-61000)
• mx : mosh 1.4.0 installé (client)
• Tmux-resurrect + Tmux-continuum installés (auto-save/15min, auto-restore reboot) mais non activés — la session simple suffit.

Récupération de session (plan B)

Même sans tmux, les conversations Hermes sont persistées dans la DB SQLite (SessionDB). Pour retrouver une conversation passée :

/hermes search [mots-clés]   # → retrouve le fil via FTS5

Tu dois relancer un hermes frais, mais le contenu est récupérable.

Scripts et processes background

Les processes lancés avec terminal(background=true, notify_on_complete=true) survivent à la déconnexion SSH indépendamment de tmux — ils tournent sur le serveur. Tu reçois leur notification de complétion à la reconnexion.

🚨 Gestion de la Fenêtre de Contexte

Règle : quand la fenêtre de contexte Hermes dépasse 20%, sauvegarder l’état et proposer un reset.

Procédure (contexte > 20%)

1. Sauvegarder : écrire l’état dans memory/YYYY-MM-DD.md (tâches en cours, décisions, contexte)
2. Informer l’utilisateur que la fenêtre est saturée et qu’un reset est recommandé
3. Tâches fond : si une tâche Claude Code tourne en background avec notify_on_complete, la laisser continuer — elle est indépendante de la session Hermes
4. Proposer /new pour repartir dans une fenêtre propre
5. Ne PAS interrompre Claude Code ou autres processus background — ils survivent au reset de session

Quand ignorer la règle

• Si l’utilisateur est en plein milieu d’une tâche critique et ne veut pas perdre le momentum
• Si Claude Code est en cours et qu’on attend juste sa notification
• Si la prochaine action est juste une réponse simple sans analyse