deploy: brief Gemini decommission hub.yesminedor.tn + historique/memoire/autonomie DSH

This commit is contained in:
hermes-nyora
2026-08-26 18:10:54 +01:00
parent 0c0126d5ac
commit d5c2159113
@@ -0,0 +1,78 @@
# 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).