From d5d6a3b6299bb1df85cefb4ce95578b1fcb6c618 Mon Sep 17 00:00:00 2001 From: bolbol Date: Tue, 25 Aug 2026 18:58:10 +0100 Subject: [PATCH] deploy: brief v3 Nyora/Gemini - Bot Mode accepte, cible v2026.8.19, verrou reseau bloquant --- _INDEX.md | 1 + ...brief-gemini-hermes-botmode-20260825-v3.md | 67 +++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 common/brief-gemini-hermes-botmode-20260825-v3.md diff --git a/_INDEX.md b/_INDEX.md index 5c81b0a..142c5e1 100644 --- a/_INDEX.md +++ b/_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 | diff --git a/common/brief-gemini-hermes-botmode-20260825-v3.md b/common/brief-gemini-hermes-botmode-20260825-v3.md new file mode 100644 index 0000000..fbae535 --- /dev/null +++ b/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.