deploy: brief v3 Nyora/Gemini - Bot Mode accepte, cible v2026.8.19, verrou reseau bloquant

_INDEX.md

@@ -10,6 +10,7 @@
 
 | Runbook | Date | Tags |
 |---------|------|------|
+| [Brief v3 Nyora/Gemini — MAJ Hermes Agent, Bot Mode accepte (v2026.8.19), architecture Manager + bots specialistes, verrou reseau bloquant identifie (reseau Docker n8n partage entre les 3 instances)](common/brief-gemini-hermes-botmode-20260825-v3.md) | 2026-08-25 | hermes, bot-mode, browser-use, n8n-network, versioning, brief-gemini |
 | [Hermes absent du suivi de versions infra — 4 lignes ajoutees (hermes-agent, hermes-workspace, hermes-nabil, hermes-hub), decisions de pin/miroir VPS actees](common/hermes-version-tracking.md) | 2026-08-25 | hermes, baserow, n8n, versioning, infra_versions |
 | [Hermes Hub — Déploiement et Exploitation Multi-Univers sur VPS (FastAPI, proxy async, design tokens, Tailscale)](common/hermes-hub-deploiement.md) | 2026-08-19 | hermes, hub, multi-univers, vps, tailscale, cloudflare-access, fastapi |
 | [Déploiement Superpowers — Flotte Hermes Agent, Claude Code & Antigravity (procédure, piège TLS 1.3, piège SSH PATH Synology)](common/superpowers-hermes-installation.md) | 2026-08-18 | hermes, superpowers, plugins, skills, tls, ssh, synology, claude-code, antigravity |

common/brief-gemini-hermes-botmode-20260825-v3.md

@@ -0,0 +1,67 @@
+# 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.