85 lines
8.4 KiB
Markdown
85 lines
8.4 KiB
Markdown
# Brief — Réduction de hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue
|
|
|
|
**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) 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) : 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. Réduire hub.yesminedor.tn à son strict rôle d'origine Cloudflare — pas une désinstallation totale
|
|
|
|
**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 :
|
|
|
|
- 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.
|
|
|
|
**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.
|
|
|
|
---
|
|
|
|
## 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).
|
|
|
|
---
|
|
|