fix: Gate 1 echec en audit independant (secrets sans verrou technique) + rotation ctx-hub nyora + migration tt/perso v2026.8.19

common/hermes-version-tracking.md

@@ -140,3 +140,47 @@ 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.
+
+## GATE 1 ECHEC EN AUDIT INDEPENDANT + migration tt/perso v2026.8.19 (25/08/2026)
+
+Contexte : rapport "audit" hermes-nyora du 25/08 concluait GO pour la conception Manager+bots,
+Gate 1 "corrobore". Probleme methodologique : l'auditeur ETAIT hermes-agent-nyora lui-meme
+(profils de test bot-gate1/a/b deja purges avant l'"audit", substitue par observation du
+comportement du profil principal). Ce n'est pas un retest independant.
+
+Claude a rejoue Gate 1 depuis le host, independamment : profil bot nu cree via
+`docker exec hermes-agent-nyora hermes profile create audit-claude-gate1 --no-skills`.
+Resultats :
+- Commande shell simple (`cat /etc/hostname`) : executee sans aucune interception visible.
+- `tirith security scanner enabled but not available -- pattern matching only` (contredit
+  le rapport initial ET l'auto-audit, qui donnaient des versions differentes de l'etat Tirith
+  sur nyora -- a clarifier).
+- Tentative de lecture de `/opt/data/profiles/veilleur/.env` (vrai fichier de secrets prod,
+  profil DIFFERENT) : reussie, exit code 0, aucune permission denied. La seule protection
+  est une ligne dans le system prompt ("ne jamais lire .env sauf demande explicite") --
+  contournee en une phrase, le modele l'a lui-meme rationalisee dans son raisonnement.
+
+**Conclusion : aucune barriere technique n'existe aujourd'hui entre un bot specialiste et
+les secrets d'un autre profil sur la meme instance. La conception Manager + bots specialistes
+reste bloquee tant qu'un vrai verrou (permissions filesystem par profil, ou secrets sortis
+des dossiers de profil) n'est pas en place.** Le verrou reseau (port 8642) reste valide et
+suffisant pour l'isolation INTER-instances -- le probleme trouve ici est INTRA-instance
+(entre profils d'une meme instance), un risque different.
+
+Profil de test supprime apres verification (`rm -rf /opt/data/profiles/audit-claude-gate1`).
+
+Incident annexe : cle context-hub nyora (`ctx-nyora-...`) exposee par erreur dans un resultat
+d'outil pendant cette investigation (3e incident du jour, meme pattern que la fuite
+HERMES_API_TOKEN tt/perso). Rotee cote serveur (`context-hub/.env`, `API_KEY_HERMES_NYORA`)
+et cote client (3 scripts dans `hermes-nyora/data/workspace/scripts/`), context-hub redemarre
+et verifie fonctionnel avec la nouvelle cle.
+
+Migration version : tt et perso bascules sur `nousresearch/hermes-agent:v2026.8.19` le meme
+jour (alignement sur nyora), compose `/volume1/docker/hermes-platform/docker-compose.yml`
+lignes 29/256 mises a jour. Verrou reseau (deja pose pour les 3 IP) confirme intact apres
+recreation. Continuite workspace->agent verifiee (401 sur les 3, pas de timeout). Ligne
+Baserow `infra_versions` id=14 mise a jour (v2026.8.19, notes refletant l'etat reel Gate 1).
+
+Bot Mode reste actif par defaut sur les 3 instances (decision Nabil du 25/08, non remise en
+cause) -- seule la construction de l'architecture Manager+bots specialistes est suspendue,
+pas Bot Mode lui-meme.