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 :

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.
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).
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.
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).

7. CORRECTIF CRITIQUE (26/08 soir) — topologie Cloudflare Tunnel, a traiter avant Phase B

Le point 1 de ce brief affirmait que dsh-hub.yesminedor.tn et files-hub.yesminedor.tn etaient servis independamment de hermes-hub par dsh-vps-proxy (nginx). Faux, verifie et corrige : inspection directe de hermes-hub/app/main.py (fonction get_subdomain_target) confirme un routage par en-tete Host, exact :

dsh-hub.yesminedor.tn -> HERMES_DSH_URL (proxy via hermes-hub)
files-hub.yesminedor.tn -> DSH_FILEBROWSER_URL (proxy via hermes-hub)
Les 5 hostnames *-hub.yesminedor.tn (tt/nyora/perso/nabil/dsh) arrivent tous sur la meme origine Cloudflare Tunnel (hermes-hub:8080), redistribues en interne selon le Host header.

Le tunnel cloudflared tourne en mode gere a distance (cloudflared --no-autoupdate tunnel --no-autoupdate run, aucun fichier de config local trouve sur le VPS) : les regles d'ingress vivent dans le dashboard/API Cloudflare, pas sur disque.

Sequence obligatoire, dans cet ordre, avant toute suppression de hermes-hub :

Localiser un token API Cloudflare (chercher dans les .env du VPS) ou obtenir de Nabil un acces dashboard Cloudflare Zero Trust pour le tunnel concerne.
Repointer l'ingress de dsh-hub.yesminedor.tn vers 100.94.90.119:8900 et files-hub.yesminedor.tn vers 100.94.90.119:8901 (dsh-vps-proxy).
Verifier les deux domaines publics de bout en bout a travers Cloudflare (pas seulement en interne/Tailscale) - reponse HTTP correcte, WebSocket fonctionnel pour dsh-hub.
Seulement apres validation du point 3 : proceder a la Phase B (arret/suppression de hermes-hub).

Ne pas supprimer hermes-hub avant d'avoir confirme le point 3 - sinon dsh-hub.yesminedor.tn et files-hub.yesminedor.tn tombent avec lui.

Phase A, point 2 (permission preset) : ne pas arbitrer entre danger-full-access et workspace-write sans validation explicite de Nabil - en attente de sa reponse, ne pas downgrader par defaut.

9.3 KiB Raw Blame History