diff --git a/common/brief-gemini-dsh-autonomie-hub-decommission-20260826.md b/common/brief-gemini-dsh-autonomie-hub-decommission-20260826.md index 0279907..805fa5e 100644 --- a/common/brief-gemini-dsh-autonomie-hub-decommission-20260826.md +++ b/common/brief-gemini-dsh-autonomie-hub-decommission-20260826.md @@ -1,31 +1,34 @@ -# Brief — Décommissionnement hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue +# Brief — Réduction de hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue -**Date** : 26 août 2026 +**Date** : 26 août 2026 (v2 — corrige la v1 après lecture directe du code hermes-hub et vérification DNS Cloudflare) **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) +**Remplace** : brief-gemini-dsh-memoire-contexthub-20260826.md (caduc) et la section 1 + section 7 de la v1 de ce fichier (hypothese de decommissionnement total invalidee, voir 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 +- 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) : l'UI switcher et la persistance chat des 4 Hermes disparaissent, mais le processus qui les sert doit être conservé et réduit, pas supprimé — voir section 1. --- -## 1. Désinstaller hub.yesminedor.tn +## 1. Réduire hub.yesminedor.tn à son strict rôle d'origine Cloudflare — pas une désinstallation totale -**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 : +**Topologie réelle, vérifiée le 26/08 (lecture directe de hermes-hub/app/main.py + interrogation de l'API Cloudflare)** — corrige une hypothèse fausse de la v1 de ce brief : -- 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. +- Les 6 hostnames (hub, tt-hub, nyora-hub, perso-hub, nabil-hub, dsh-hub, files-hub .yesminedor.tn) pointent tous en CNAME vers le même tunnel Cloudflare (700c0fe6-2b2c-4e1a-abfa-3f94f2f7c909.cfargotunnel.com) — vérifié via l'API Cloudflare avec le token disponible dans /mnt/docker/.claude/API_KEY.env (CLOUDFLARE_API_TOKEN, scopé zone, sans accès compte). Une seule origine locale existe pour tout ce zonage : hermes-hub (port 127.0.0.1:8088), qui fait lui-même le dispatch par en-tête Host en interne (fonction get_subdomain_target, app/main.py), y compris pour dsh-hub.yesminedor.tn et files-hub.yesminedor.tn. +- **dsh-vps-proxy (nginx, ports 8900/8901) existe et fonctionne, mais n'est pas dans le chemin public réel.** La v1 de ce brief affirmait le contraire — c'était faux, corrigé après lecture du code. +- Conséquence directe : **supprimer hermes-hub en entier casse aussi dsh-hub.yesminedor.tn et files-hub.yesminedor.tn.** +- Ne pas chercher à repointer un ingress Cloudflare : le token disponible n'a pas la portée compte nécessaire pour éditer un tunnel (cfd_tunnel est une ressource de compte), et de toute façon les 6 hostnames partagent déjà le même CNAME — le levier n'est pas côté Cloudflare, il est dans le code de hermes-hub. -**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. +**Action retenue : réduire hermes-hub à un dispatcher minimal, ne pas le supprimer.** + +1. Dans le code de hermes-hub, retirer : le routeur chat.py (/api/chat/{universe}/...), sa base de conversations (chat_service.py/db.py, fichier hub.db), et la vue index_view/template index.html (l'UI switcher servie à l'apex). Remplacer la racine hub.yesminedor.tn par une réponse simple (404/410) — plus de switcher. +2. **Conserver intact** : get_subdomain_target, le middleware subdomain_routing_middleware, proxy_request, proxy_websocket. C'est ce qui fait fonctionner dsh-hub.yesminedor.tn et files-hub.yesminedor.tn aujourd'hui, et ça doit rester le seul chemin public vers DSH. +3. Dans UNIVERSES (config), retirer les entrées tt/nyora/perso/nabil (elles ne servent plus qu'à l'ancienne UI supprimée). Ne garder que l'entrée dsh (et son alias filebrowser files). +4. Rebuild et redéployer hermes-hub avec ce code réduit, même nom de container, même port — aucun changement DNS ni tunnel nécessaire. +5. Vérifier après déploiement, à travers Cloudflare (pas seulement en interne) : dsh-hub.yesminedor.tn et files-hub.yesminedor.tn répondent normalement ; hub.yesminedor.tn seul ne sert plus le switcher ; Telegram répond toujours pour les 4 Hermes (chemin totalement indépendant, non affecté par ce qui précède). +6. ports-registry.md : mettre à jour l'entrée hermes-hub — préciser rôle réduit (dispatcher dsh-hub/files-hub uniquement), pas de suppression de ligne. --- @@ -79,22 +82,3 @@ Nabil demande "plus d'autonomie" et de "modifier le Full Access". Deux choses à --- -## 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 : -1. 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. -2. 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). -3. 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. -4. 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.