docs: etat des lieux migration cerveau -- cloture 2026-08-17

2026-08-18 20:24:55 +00:00
parent 930d44aa7d
commit 8d110b7f1c
1 changed files with 63 additions and 0 deletions
@@ -200,3 +200,66 @@ a definir si/quand la question se represente, en comparant le cout reel cumule D
 l'estimation cout+latence d'un passage a mimo-v2.5). Tant que ce seuil n'est pas atteint, ne pas
 rouvrir cette question sans element nouveau (hausse tarifaire DeepSeek, volume Tirith en forte
 hausse, etc.).
 ## État au 2026-08-17 — dette ouverte (consolidation, verification finale)
 Section unique de cloture, verifiee le 2026-08-18 en reprise de session (rate limit interrompu
 puis reinitialise) -- regroupe tout ce qui etait jusqu'ici disperse entre plusieurs sections de
 ce runbook, sans rien ajouter de nouveau sur le fond. Chaque ligne ci-dessous est verifiable
 individuellement -- fait confirme distingue de ce qui reste suppose.
 **Les 5 cibles migrees et confirmees** (detail complet plus haut dans ce runbook) :
 hermes-perso, hermes-HARNESS (dsh-vps), hermes-tt, hermes-nyora, Yesmine-Key (VK Bifrost).
 **Phase 1 -- Coherence git/live, verification finale (2026-08-18)** : comparaison directe entre
 le dernier commit pousse sur `bolbol/hermes-<instance>:data/config.yaml` et l'etat reellement
 charge dans le conteneur (`model.default`, `context_length`, `max_tokens`), sur les 3 instances
 Hermes concernees (dsh-vps hors sujet, pas de repo git pour ce fichier). **Aucun ecart trouve** :
 - hermes-tt : commit `5aa8199` = live (`mimo-v2.5` / `opencode-go` / `1048576` / `131000`).
 - hermes-perso : commit `5c055eb` = live (memes valeurs).
 - hermes-nyora : commit `a4d35f4` = live sur les champs cibles ; seul `api_key` differe par
  construction (placeholder `REDACTED-live-only...` en git vs secret litteral en live) -- ecart
  deliberement maintenu, deja documente ci-dessus (point 2), pas un nouvel ecart.
 **Phase 2 -- Plafond de sortie confirme en usage reel (hermes-tt)** : demande de generation
 longue et structuree (document technique 12 sections, via l'interface habituelle, prompt neutre
 sans donnee metier). Resultat : `completion_tokens: 18831`, `finish_reason: stop` -- generation
 effective d'un document de 60 Ko sans troncature, tres au-dela de l'ancien plafond de 8192.
 Confirme en usage reel, pas seulement en absence d'erreur sur un appel minimal.
 **Phase 3 -- Test Baserow en conditions reelles, lecture seule (perso / tt / nyora)** : question
 posee via l'interface habituelle de chaque agent, avec consigne explicite de verifier en
 direct plutot que de repondre depuis la memoire.
 - **hermes-perso** : appel outil reel confirme (`prompt_tokens: 185368`), chiffres precis croises
  sur 2 bases Baserow / 6 tables (ex. 57/56/55 marches selon la table). Pas un snapshot fige.
 - **hermes-nyora** : reponse explicite *"requete directe sur Baserow (JWT, pas de memoire)"*,
  memes chiffres croises retrouves independamment (`prompt_tokens: 256913`).
 - **hermes-tt** : cas le plus demonstratif -- le modele a lui-meme distingue son snapshot fige
  embarque (55) de la valeur live obtenue par appel reel (56), et l'a signale explicitement dans
  sa reponse (*"le snapshot embarque indiquait 55 -- il y en a maintenant 56"*). Confirme sans
  ambiguite que l'agent interroge Baserow en direct en usage courant, pas seulement en test isole.
 Les trois appels de Phase 3 ont depasse tres largement l'ancien plafond `context_length: 128000`
 (jusqu'a 689638 tokens de prompt sur un appel tt) -- preuve vivante supplementaire, en usage
 reel cette fois, que la correction de la Phase 2 (17/08) etait necessaire et pas cosmetique.
 **Items restes hors perimetre ce soir (constat, pas de correction tentee)** :
 | Item | Raison du report | Ce qu'il faudra pour debloquer |
 |---|---|---|
 | Secret Bifrost en clair sur hermes-nyora (`api_key: bfk-...` x2 dans le yaml live) | Necessite un vrai correctif du mecanisme d'auth key_env/Bifrost (cf point 2 plus haut), pas une nouvelle tentative ce soir -- la premiere tentative a casse l'authentification et a ete rollback proprement | Investigation cote code/config Hermes sur la construction du header (`Authorization: Bearer` vs `x-bf-vk`) selon le champ utilise, avant nouvel essai |
 | Session few-shot AO/RLA sur hermes-tt (`dco-generation-tt`, `courriers-officiels-tt`, `gsd-ao-evaluation`) | Necessite Nabil directement (deja ecrit dans les skills eux-memes : "pas depuis mcp-nas seul") -- pas un blocage technique, une decision deja prise de le faire en session dediee | Selection de 2-3 documents Zone Sud deja valides par type, avec Nabil |
 | VK dediee `BIFROST_VK_HERMES_NYORA` provisionnee le 18/07, jamais cablee dans `config.yaml` (nyora continue d'utiliser `Nabil-Key` partagee) | Decision a trancher (basculer nyora sur sa propre VK dediee), pas a executer ce soir -- lie au meme sujet non traite que le secret en clair | Decision explicite : basculer maintenant, ou assumer `Nabil-Key` partagee plus longtemps |
 | Panne `nvidia_nim` sur Bifrost (404 sur tout appel, reconfirme en direct le 17/08 lors du refus d'ajouter des "gratuits nvidia_nim" a Yesmine-Key) | Dette preexistante deja documentee ailleurs (memoire infra `bifrost-keys-config-json`, 38 jours), reconfirmee mais pas retentee ce soir -- aucun modele nvidia_nim gratuit ou payant ne repond via Bifrost actuellement | Diagnostic du routage `nvidia_nim` cote Bifrost (`base_url: https://integrate.api.nvidia.com/v1`) -- hors perimetre de cette migration |
 **Note de coherence** : le sujet "Suite (2026-08-18)" plus bas dans ce runbook (straggler
 nyora-veille + decision Tirith) est **deja resolu**, pas un 5e item ouvert -- mentionne ici
 uniquement pour eviter toute confusion entre ce qui reste a trancher (tableau ci-dessus) et ce
 qui a deja ete tranche par Nabil le meme jour.
 **ports-registry.md** : les 3 lignes hermes-agent-tt/nyora/perso affichaient deja "Mimo V2.5"
 au moment de cette verification (fichier modifie le 18/08 a 15:30, avant la reprise de cette
 session a 21:16 -- probablement une edition manuelle anterieure, pas cette tache). Contenu
 confirme exact (backup du 25/07 confirmant qu'il indiquait bien "DeepSeek V4 Flash" avant),
 seule la date d'en-tete etait restee a "12/07/2026" -- corrigee.