diff --git a/common/migration-mimo-v25-cerveau-hermes.md b/common/migration-mimo-v25-cerveau-hermes.md index 7dbbbda..d823c19 100644 --- a/common/migration-mimo-v25-cerveau-hermes.md +++ b/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-: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.