# Brief Nyora → Gemini/AntiGravity : MAJ Hermes Agent (v3 — Bot Mode en périmètre) **Émetteur** : Claude (cerveau stratégique) **Destinataire d'exécution** : hermes-nyora — cadre et pilote Gemini/AntiGravity **Date** : 2026-08-25 **Statut** : remplace le brief v2 (`common/brief-gemini-hermes-browserless-botmode-20260825-v2.md`). Décision de Nabil : Bot Mode est accepté, actif par défaut, pattern Manager + bots spécialistes retenu comme architecture cible. --- ## 0. Décisions de Nabil (25/08, ne pas rouvrir sans nouvel élément) - **Bot Mode validé sur le principe** : plusieurs bots spécialisés à tâche précise, coordonnés par un Manager/Cerveau, sont jugés plus fiables qu'un seul agent généraliste portant toute une tâche. Bot Mode actif par défaut (`bot_mode_protocol: true`) est acceptable — pas besoin de le désactiver. - **Cible de version : `nousresearch/hermes-agent:v2026.8.19` (v0.20.5)**, pas `v2026.8.18`. Cette version la plus mûre inclut les correctifs Bot Mode ultérieurs (group-room threads, routing cross-machine stabilisé) et le scan NVIDIA SkillEvaluator sur les installs de skills. - **Isolation totale, sans aucune exception, y compris en interne** : aucune connexion `hermes peer` entre AUCUNE des instances/déploiements Hermes de Nabil (hermes-tt, hermes-nyora, hermes-perso, hermes-nabil, hermes-hub), ni vers l'extérieur. Nabil a explicitement écarté deux exceptions qui auraient pu sembler naturelles : **hermes-nabil** (censé le représenter personnellement) et **hermes-nyora** (qui a une vue transverse et pourrait un jour intervenir sur une autre instance) — aucun des deux n'est une exception légitime. Coordination Bot Mode = strictement intra-instance, entre bots vivant dans le même profil Hermes. --- ## 1. Préalable technique bloquant — vérifié en direct, à traiter AVANT tout test Bot Mode Les 3 conteneurs `hermes-agent-tt` / `hermes-agent-nyora` / `hermes-agent-perso` partagent aujourd'hui le réseau Docker `n8n` (172.27.0.0/16) — **le maillage principal de toute la stack** (n8n, Baserow, Gitea, Bifrost, context-hub et une trentaine d'autres conteneurs y sont aussi). Vérifié via `docker network inspect n8n` : les 3 instances Hermes s'y trouvent avec des IP routables entre elles (172.27.0.35/.37/.33). **Rien n'empêche aujourd'hui un `hermes peer add` d'une instance vers une autre en interne — l'isolation entre sphères repose actuellement sur la discipline, pas sur une barrière réseau.** Retirer les instances Hermes de ce réseau n'est pas la solution : elles en dépendent pour leurs appels légitimes (n8n, Baserow, Bifrost, context-hub). Ce qu'il faut, et c'est la première tâche de Gemini avant tout test Bot Mode : 1. Identifier le(s) port(s) exact(s) utilisé(s) par le protocole peer Bot Mode (`hermes peer`, mécanisme de connexion Desktop relay). 2. Poser une règle de pare-feu ciblée (iptables sur le host, ou règle crowdsec dédiée) qui bloque spécifiquement ce port entre les IP des conteneurs `hermes-agent-tt` / `hermes-agent-nyora` / `hermes-agent-perso` entre eux, sans toucher au reste du trafic sur le réseau `n8n`. 3. Vérifier en direct (tentative de connexion peer réelle entre deux instances, doit échouer) que la règle fonctionne. 4. Appliquer la même logique côté VPS pour `hermes-nabil` / `hermes-hub` (probablement plus simple : déploiements séparés, pas de réseau Docker partagé avec le NAS a priori — à confirmer). Ce verrou réseau doit être en place et vérifié avant l'étape 4 (test Bot Mode) ci-dessous, pas après. --- ## 2. Étape 1 — Vérification factuelle (reprise du brief v1, résultats déjà obtenus par Claude) Déjà fait, pas à refaire : tag v2026.8.19 confirmé disponible sur le registre (Docker Hub), digest vérifié. Browser Use mode présent depuis v0.20.1, Bot Mode présent depuis v0.20.4 (code dans `agent_init.py`, `conversation_loop.py`, `system_prompt.py` — pas un plugin isolé). Flag `agent.bot_mode_protocol` : défaut `True`, confirmé par lecture directe du code (`_agent_section.get("bot_mode_protocol", True)`). --- ## 3. Étape 2 — Tests bloquants avant toute mise en prod (gates, pas des curiosités) 1. **Test Tirith sur commande shell émise par un bot** : créer un profil bot nu (sans toolset superflu), lui faire tenter une commande shell quelconque, constater si la review Tirith se déclenche. Si elle ne se déclenche pas → remonter à Nabil avant d'aller plus loin, ne pas contourner. 2. **Mécanisme de roster local** : deux bots créés dans la même instance (même profil hermes-nyora) se découvrent-ils automatiquement, ou faut-il un enregistrement explicite même en local ? À documenter précisément — ça conditionne comment le Manager/Cerveau doit être configuré pour piloter ses bots spécialistes. 3. **Vérification du verrou réseau (§1.3 ci-dessus)** avant tout test Bot Mode réel entre instances (même si aucune connexion n'est prévue, vérifier que la règle empêche bien une tentative). --- ## 4. Phase A — Pilote hermes-nyora, architecture Manager + bots spécialistes Une fois §1 et §3 validés : 1. Sauvegarder config/mémoire actuelles (comme prévu dans le plan initial). 2. Bascule image → `nousresearch/hermes-agent:v2026.8.19`, `--force-recreate`. 3. Batterie de re-tests continuité (gateway Telegram, cron, mémoire, webhook veille-backend, MCP context-hub, SMTP) — reprise du plan initial. 4. Premier cas d'usage réel à construire avec Nabil : décomposer une tâche récurrente de hermes-nyora en bots spécialistes (ex. un bot par sous-tâche bien définie) coordonnés par un Manager. Ne pas improviser la répartition — la faire valider par Nabil avant implémentation, comme il l'a précisé ("c'est à nous de fixer les tâches de chacun"). 5. Test Browser Use mode (repris du plan initial, sans changement). --- ## 5. Ce qui reste hors périmètre Extension à hermes-tt / hermes-perso (Phase C du plan initial) : uniquement après retour positif du pilote hermes-nyora ET validation explicite de Nabil. hermes-nabil / hermes-hub (VPS) : suivent en miroir une fois la version validée sur NAS (cf. décision déjà actée sur le suivi de versions). --- ## Rappel du mécanisme Claude conçoit le motif → hermes-nyora cadre et fait exécuter → Gemini installe/investigue → Claude audite en un seul passage qui reteste réellement en direct. Le verrou réseau (§1) et les deux tests de gate (§3) ne sont pas optionnels : c'est la condition posée par Nabil pour que "aucune connexion vers l'extérieur, jamais, sans exception" soit une propriété technique vérifiée et pas une promesse.