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

common/migration-mimo-v25-cerveau-hermes.md

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