# Brief — Décommissionnement hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue **Date** : 26 août 2026 **Auteur** : Claude (cerveau stratégique) **Exécutant** : Gemini AntiGravity **Remplace** : `brief-gemini-dsh-memoire-contexthub-20260826.md` (caduc — ne pas exécuter, scope entièrement revu ci-dessous) **Architecture cible validée par Nabil** : - `Hermes (tt/nyora/perso/nabil) <--> Telegram` — seul canal d'accès conservé pour les 4 Hermes - `https://dsh-hub.yesminedor.tn/ <--> DSH <--> https://files-hub.yesminedor.tn/files/` — DSH reste l'outil de dépannage rapide, avec plus d'autonomie - `https://hub.yesminedor.tn/` (Workspace Switcher Multi-Univers) et tout ce qui lui est propre : à désinstaller --- ## 1. Désinstaller hub.yesminedor.tn **Topologie vérifiée en direct (26/08, `docker ps -a` + inspection nginx sur le VPS)** — à connaître avant de couper quoi que ce soit : - Le container `hermes-hub` (image `hermes-hub-hermes-hub`, port `127.0.0.1:8088->8080`, réseaux `dsh_vps_net`+`mcp-vps`) est la seule chose à retirer pour ce point. Il embarque sa propre DB de conversations (`chat_service.py`/`db.py`) et un routeur `/api/chat/{universe}/...` — tout ça part avec lui. - `dsh-hub.yesminedor.tn` et `files-hub.yesminedor.tn` sont servis par un container **totalement séparé** : `dsh-vps-proxy` (nginx, réseau `dsh_vps_net`), qui proxy respectivement le port 8900 vers `dsh-vps:3080` et le port 8901 vers `dsh-filebrowser:8080`. Aucune dépendance croisée avec `hermes-hub` — confirmé par lecture directe de sa conf nginx. **Rien à toucher ici.** - `hermes-nabil` (le "Master Agent VPS") n'a aucun port exposé en dehors du réseau Docker interne — il n'est atteignable depuis l'extérieur qu'via Telegram (indépendant de `hermes-hub`, préexistant à son ajout du 19/08) ou via le proxy de `hermes-hub` lui-même. Après suppression de `hermes-hub`, `hermes-nabil` reste joignable **uniquement par Telegram** — c'est exactement ce que Nabil veut, mais à confirmer explicitement avant coupure pour ne pas le découvrir après coup. - Les 3 Hermes NAS (tt/nyora/perso, ports 3010/3020/3031 en LAN, `100.86.197.88` en Tailscale) sont indépendants de `hermes-hub` — celui-ci ne fait que les proxifier pour l'UI web. Rien à changer côté NAS. **Actions** : 1. `docker compose down` sur le service `hermes-hub` (localiser son compose sur le VPS, probablement `/home/.../hermes-hub/`), puis suppression du container, de l'image, des volumes nommés dédiés à sa DB de conversations. 2. Retirer l'entrée DNS/Cloudflare Tunnel pour `hub.yesminedor.tn` (vérifier d'abord si le tunnel Cloudflare est mutualisé avec d'autres domaines avant de toucher à la config du tunnel — ne pas supprimer une route partagée). 3. Vérifier après coupure : Telegram répond toujours pour les 4 Hermes, `dsh-hub.yesminedor.tn` et `files-hub.yesminedor.tn` répondent toujours normalement. 4. `ports-registry.md` : retirer la ligne `hermes-hub`, ajouter une entrée changelog datée. --- ## 2. Historique cassé sur dsh-hub.yesminedor.tn — cause probable identifiée Root-cause tracée en direct, pas une supposition : - L'erreur UI `"Loading the provider directory failed: settings are unavailable in this browser"` vient du code client (`dsh-client-ui-settings-models/lib/client.js` ligne 551) : elle se déclenche quand `describeFace.getSnapshot()` ne reçoit jamais de vue valide. - `describeFace` se synchronise via les WebSockets `/api/events.mux` et `/api/events.host`. Logs observés : `WebSocket proxy bridge error ... timed out during opening handshake` sur ces deux canaux, et des `httpx.ReadError` sur `/api/host.describe`. - Le container `dsh-vps` lui-même est stable (0 restart, pas d'OOM, 43% RAM sur 1 Gio, CPU quasi nul) — ce n'est pas un crash-loop. Le problème est plus probablement un souci de handshake WebSocket applicatif dans `dsh-vps` (ou un timeout mal réglé dans `dsh-vps-proxy`/nginx pour les upgrades WS) qui empêche `describeFace` de s'initialiser correctement, ce qui casse en cascade : historique de session, `host.describe`, et l'annuaire des providers dans Settings. **Action** : investiguer côté `dsh-vps` pourquoi `/api/events.mux` et `/api/events.host` timeout à l'ouverture — commencer par la conf nginx de `dsh-vps-proxy` (`proxy_read_timeout`/`proxy_buffering off` sont déjà en place, donc regarder plutôt côté process `dsh-vps` : charge au démarrage, ordre d'initialisation, éventuel bug connu de `@deepseek-ai/dsh` sur les WS derrière un reverse-proxy TLS-terminé en amont). Documenter, ne pas juste redémarrer le container en espérant que ça passe — si ça revient après un restart, capturer les logs à chaud pour identifier le déclencheur. --- ## 3. Mémoire persistante pour DSH (le mécanisme, toujours valide) Ce qui avait été établi dans le brief précédent reste vrai et exploitable — reprendre tel quel : - `dsh plugin add` échoue (`pnpm not found on PATH`) : ajouter pnpm au Dockerfile de `dsh-vps` avant tout. - Une fois pnpm présent, installer le plugin first-party `@deepseek-ai/dsh-mcp-client`, le pointer vers NyoraNotes. - **Reachability déjà prouvée** (pas à revérifier) : `curl http://100.86.197.88:8787/health` répond `{"status":"ok","notes_count":412}` depuis le VPS. Le tunnel Tailscale est bon. - Usage : mémoire propre de DSH dans son dossier `vault/dsh/` existant. --- ## 4. Identité de Nabil pour DSH Une fois le bridge NyoraNotes vivant (point 3), écrire une note initiale dans `vault/dsh/` avec : - Nabil, Responsable Achats Zone Sud Tunisie Telecom (Sfax), venture perso Nyora - Préférences de forme : français, accents corrects, direct, sans tics IA (em-dash, tricolons, "il est important de noter") - Cadre d'usage : dépannage ponctuel, modifications non stratégiques (icônes, thèmes, petites features) sur des outils identifiés — pas de données métier TT ni familiales/santé dans cette instance. --- ## 5. Autonomie accrue pour DSH — à clarifier avant exécution Nabil demande "plus d'autonomie" et de "modifier le Full Access". Deux choses à ne pas confondre, comme déjà signalé : - **Le `permission.defaultPreset: danger-full-access` actuel** régit ce que DSH peut faire *dans son propre bac à sable* (déjà le préréglage le plus permissif qui existe côté DSH — il n'y a rien "au-dessus" à activer). Si le bug Settings (point 2) empêche ce préréglage de se charger/sauvegarder correctement dans l'UI, le fixer réglera aussi ce symptôme. - **L'autonomie réelle sur l'infra** (faire une modif sur un outil sans passer par Claude/Gemini) demande un accès *sortant* que DSH n'a pas aujourd'hui. Recommandation maintenue : un credential Gitea scopé à un ou deux dépôts précis (pas `mcp-nas`/`mcp-vps`, pas d'accès shell brut au NAS) — DSH commit, c'est diffable/revertable, et ça donne l'audit trail en temps réel que Nabil veut. **Gemini ne doit pas aller au-delà du credential Gitea scopé sans validation explicite de Nabil sur le(s) dépôt(s) concerné(s)** — cette liste n'a pas encore été fixée dans cette conversation. --- ## 6. Vérification indépendante et capitalisation - Revérifier chaque point en direct par SSH avant de déclarer terminé. - Runbook `bolbol/nas-runbooks` (`common/`), `_INDEX.md` à jour, commit + push compte `bolbol`. - `ports-registry.md` : retrait `hermes-hub`, entrée changelog. - Note NyoraNotes `[infra, runbook]` pour chaque problème résolu (historique DSH, mémoire, décommissionnement hub).