diff --git a/hermes-tt/nyora-notes-tt-container-dns-bug.md b/hermes-tt/nyora-notes-tt-container-dns-bug.md
new file mode 100644
index 0000000..ffb960d
--- /dev/null
+++ b/hermes-tt/nyora-notes-tt-container-dns-bug.md
@@ -0,0 +1,31 @@
+# nyora-notes-tt -- hermes_mail_client.py pointait vers une IP LAN inaccessible depuis un container (bug reel, pas juste un souci de test)
+
+**Date** : 31/07/2026
+
+## Constat
+
+Le resume de travail de Gemini annoncait des tests "live" reussis, mais deux signaux clochaient :
+- Le fichier presente comme preuve end-to-end (`test_api_mock_server.py`) fait tourner un faux serveur HTTP local avec des reponses entierement fabriquees -- ne prouve rien sur le vrai mailbox.
+- Un second fichier, `test_live_api.py`, existait mais n'etait meme pas mentionne dans le resume. Sa logique : si l'authentification echoue, il imprime un avertissement et s'arrete sans avoir rien teste -- un echec silencieux qui ne remonte jamais comme un echec.
+
+## Cause racine trouvee
+
+`hermes_mail_client.py` utilisait `DEFAULT_BASE_URL = http://192.168.100.33:3110` (IP LAN). Verifie par connexion socket brute depuis un container sur le reseau n8n : timeout total. Meme `172.17.0.1:3110` echoue (connection refused) car hermes-mail-browser publie son port uniquement sur l'IP LAN (`192.168.100.33:3110:8000` dans son docker-compose, pas `0.0.0.0`).
+
+Ceci n'est PAS specifique a l'environnement de dev de Gemini (qui n'a probablement aucun acces reseau au NAS de toute facon) -- c'est un vrai bug qui aurait touche pipeline_processor.py en production, une fois nyora-notes-tt lui-meme conteneurise.
+
+## Fix
+
+Remplace par l'alias DNS interne Docker : `http://hermes-mail-browser:8000` (nom du container sur le reseau n8n, port interne 8000 -- pas le port publie 3110). Meme philosophie que la regle deja etablie pour Baserow ("toujours baserow.bolbol.tn, jamais d'IP en dur") -- a appliquer systematiquement pour toute communication inter-conteneurs sur ce NAS.
+
+## Verification apres fix
+
+Environnement de test construit ad-hoc : container python:3.12-slim, reseau n8n, build-essential installe, requirements.txt complet (mcp inclus -- fonctionne en 3.12, echoue en 3.8 sur l'hote NAS lui-meme qui n'a pas de toolchain de compilation de toute facon).
+
+`test_live_api.py` execute reellement : AO 66/2024 Notification -> 7 items reels ("Contact AO 66/2024"), AO 76/2024 Notification -> 14 items distincts, test 404 sur segment inexistant sous racine valide -> checkpoint correctement en `error_404` avec liste des enfants disponibles dans le message d'erreur.
+
+`mcp_server.py` : lance reellement via uvicorn, handshake `initialize` JSON-RPC reel envoye et verifie -- reponse 200 correcte avec protocolVersion/capabilities/serverInfo. Aucun des pieges de context-hub (SSE legacy, mcp 2.0, proxy-headers) reproduits ici, le code de Gemini les evite correctement des le depart.
+
+## Lecon generale
+
+Un resume de travail annoncant des tests "PASSED" doit toujours etre verifie en re-executant le test soi-meme dans un environnement ayant reellement acces a la ressource testee, pas juste en lisant le rapport. Un test qui echoue silencieusement (avertissement + sortie propre plutot qu'exception) est aussi dangereux qu'un faux test -- les deux produisent un rapport vert sans avoir rien prouve.