# Hermes absent du suivi de versions infra — comble le 25/08/2026 **Instance auteur** : Claude (session chat) **Date** : 2026-08-25 **Tags** : hermes, baserow, n8n, versioning, infra_versions **Statut** : en-cours (verification n8n en attente) --- ## Probleme Nabil a remarque que Hermes n'etait jamais entre dans le suivi automatique des versions infra (table Baserow `infra_versions`, ID 1097, database_id 317 / workflow n8n actif `veille-versions-stack`, ID `zUWN5K4Q1A2JKFIS`), alors que ce sont justement les MAJ Hermes et n8n qui avaient motive la creation de ce suivi le 21/08/2026. Verification directe (JWT admin Baserow, pas d'hypothese) : la table contenait 11 lignes (n8n, bifrost, gitea, portainer, vaultwarden, baserow, crowdsec, tailscale-nyora-bridge, trilium, dsh-vps, dsh-vps-filebrowser) — aucune ligne Hermes. Le token API Baserow habituel (`XGCwbfgwg8ZiLVb4dxEfagWa7XptyUcM`, cf `topics/baserow-access.md`) n'a PAS les permissions sur cette table (`ERROR_NO_PERMISSION_TO_TABLE`) — la lecture/ecriture a du passer par un JWT obtenu via `/api/user/token-auth/` avec le compte admin `contact@bolbol.tn` (credentials dans `/mnt/docker/baserow-schema-mcp/.env`). --- ## Trouvaille annexe : changement de schema de version sur hermes-agent Le runbook `common/brief-gemini-skills-hermes-antigravity-20260821.md` (21/08) confirmait l'image `nousresearch/hermes-agent` en **v0.20.0** (commit upstream `3c27eb62`). Verification en direct aujourd'hui (`docker inspect` sur hermes-agent-tt/nyora/perso) : image maintenant en **v2026.8.3** — nouveau schema de versionnage (calver annee.mois.build) plutot qu'un simple bump semver. C'est probablement la MAJ que Nabil a trouvee "interessante". --- ## Ce qui NE fonctionne PAS | Tentative | Erreur obtenue | Raison de l'echec | |-----------|----------------|-------------------| | Connecteur MCP Baserow standard (`Baserow:get_table_schema` table 1097) | `[]` puis `ERROR_NO_PERMISSION_TO_TABLE` sur l'endpoint direct | Token API scope a un workspace different (achats Zone Sud), pas le workspace infra (workspace_id 187) | | `n8n:get_workflow_details` sur `veille-versions-stack` | "Workflow is not available in MCP" | Acces MCP non active sur la fiche du workflow (a activer manuellement depuis n8n) | --- ## Solution validee 4 lignes ajoutees dans `infra_versions` (table 1097) via l'API Baserow (JWT admin) : 1. **hermes-agent** (NAS, id ligne 14) — `nousresearch/hermes-agent:v2026.8.3`, methode `image_tag`, criticite Critique. Une seule ligne pour les 3 conteneurs hermes-agent-tt/nyora/perso (meme image, meme tag sur les 3 — pas de doublon). 2. **hermes-workspace** (NAS, id ligne 15) — `ghcr.io/outsourc-e/hermes-workspace`, actuellement sur `:latest` non pinne (digest verifie via `docker inspect` + `ghcr.io/token` API, different du dernier tag semver publie `v2.1.3` — le tag `latest` suit la branche `main`, pas les releases). **Decision Nabil (25/08)** : pinner un tag explicite a chaque futur deploiement au lieu de `:latest`. Ligne en statut "En pause" en attendant ce pin. 3. **hermes-nabil** (VPS, id ligne 16) — build local (pas de registre public), suit `hermes-agent` NAS en miroir. **Decision Nabil (25/08)** : mise a jour manuelle a chaque propagation validee NAS -> VPS, pas de verif de registre independante. 4. **hermes-hub** (VPS, id ligne 17) — build docker-compose 100% custom (image auto-nommee `hermes-hub-hermes-hub`), aucun fichier de version trouve dans le conteneur (recherche `package.json`/`VERSION*` infructueuse). Meme logique miroir que hermes-nabil, statut "En pause" tant qu'aucun marqueur de version n'existe. `hermes-mail-browser` (build local) et `hermes-watchdog-telegram` (image officielle `docker:cli` utilisee comme outil) exclus du suivi : ce ne sont pas des composants Hermes versionnables au sens de cette table. --- ## Verification ```bash TOKEN=$(curl -s -X POST "http://baserow.bolbol.tn/api/user/token-auth/" -H "Content-Type: application/json" -d '{"email":"contact@bolbol.tn","password":""}' | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])") curl -s "http://baserow.bolbol.tn/api/database/rows/table/1097/?size=200&user_field_names=true" -H "Authorization: JWT $TOKEN" | python3 -c "import sys,json; print(json.load(sys.stdin)['count'])" # Resultat attendu : 15 (11 initiales + 4 Hermes) ``` --- ## A faire (non cloture) - Activer l'acces MCP sur la fiche du workflow `veille-versions-stack` (n8n) pour confirmer s'il lit dynamiquement toutes les lignes de `infra_versions` (auto-inclusion de `hermes-agent` au prochain passage hebdo, rien d'autre a faire) ou s'il faut lui ajouter un noeud dedie pour Hermes. - Pinner `hermes-workspace` a un tag explicite au prochain deploiement (au lieu de `:latest`) et mettre a jour la ligne 15 en consequence. --- ## References - Table Baserow `infra_versions`, ID 1097 (database_id 317, workspace_id 187) - Workflow n8n `veille-versions-stack`, ID `zUWN5K4Q1A2JKFIS` - [common/brief-gemini-skills-hermes-antigravity-20260821.md](brief-gemini-skills-hermes-antigravity-20260821.md) **CORRECTIF (2026-08-25, meme session)** : la "trouvaille" ci-dessus sur un changement de schema de versionnage (v0.20.0 -> v2026.8.3) est **erronee** -- confusion entre deux identifiants distincts. `docker exec hermes-agent-tt .../hermes version` donne `Hermes Agent v0.20.0 (2026.8.3) · upstream 3c27eb62` -- c'etait deja le cas le 21/08 (cf `common/brief-gemini-skills-hermes-antigravity-20260821.md`). Le tag Docker EST et reste `nousresearch/hermes-agent:v2026.8.3`, aucun changement detecte entre le 21/08 et le 25/08. `v0.20.0` = version interne du paquet Python (pyproject.toml), `2026.8.3` = date de build encodee dans le meme identifiant, pas deux versions successives. Pas de nouvelle MAJ image cote hermes-agent pour l'instant -- la MAJ "interessante" evoquee par Nabil concerne des fonctionnalites (Browserless mode, Bot Mode), pas un bump de tag. ## CLOTURE — Rotation credentials + verrou reseau Bot Mode (25/08/2026) Suite investigation hermes-nyora (brief v3, §1) : fuite HERMES_API_TOKEN tt+perso via inspection Portainer (filtre de caviardage defaillant sur "TOKEN"). Rotation faite le jour meme : nouvelles `HERMES_TT_API_KEY` / `HERMES_PERSO_API_KEY` dans `/volume1/docker/hermes-platform/.env`, 4 conteneurs (agent+workspace tt/perso) recrees, tous healthy. nyora non concerne. Verrou reseau applique et verifie en direct le meme jour (Claude, via `crowdsec-firewall-bouncer` — network host + NET_ADMIN, pas besoin de sudo) : DROP du port peer Bot Mode 8642 sur le bridge Docker partage `n8n` (nom reel du bridge sur ce NAS : `docker-8dbc7efc`, PAS `br-` — convention Synology, a ne jamais supposer generique). Trafic legitime workspace->agent confirme passer par le reseau dedie de chaque instance (`getent hosts` depuis chaque workspace), donc non affecte par le verrou — verifie par test reel (401 sur les 3, pas de timeout) apres application. Script de reference : `/volume1/docker/hermes-platform/scripts/verrou-botmode.sh`. Persistance au reboot : tache planifiee DSM "Verrou_Bot_Mode", declenchement au demarrage — posee par Nabil (hors acces SSH Best0f, `synoschedtask` indisponible pour ce compte). Incident annexe : une commande d'audit Claude a par erreur affiche la cle tt en clair dans un resultat d'outil pendant l'investigation — cle rotee de toute facon, mentionne pour tracabilite. Decisions encore ouvertes (brief v3 §8, non bloquantes pour la suite) : durcissement 4.3 (bind selectif par IP dediee, necessite grep prealable des workflows n8n), activation Tirith sur hermes-nyora pour le pilote (actuellement `security.tirith_enabled: false`), choix roster headless (tag manuel profile.yaml vs Desktop de gestion) — a trancher pendant la conception du cas d'usage Manager + bots specialistes (brief v3 §4.4). Brief v3 valide et transmis a hermes-nyora par Nabil le 25/08 — prochaine etape : rapport Phase A (Gemini/AntiGravity), audit Claude a suivre.