From 0035d193ef6c9ac77a636948fd3c64e30ca212fb Mon Sep 17 00:00:00 2001 From: bolbol Date: Mon, 17 Aug 2026 22:36:30 +0000 Subject: [PATCH] docs: ajoute section Yesmine-Key (allowed_models mimo-v2.5, retrait deepseek) au runbook migration mimo --- common/migration-mimo-v25-cerveau-hermes.md | 48 +++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/common/migration-mimo-v25-cerveau-hermes.md b/common/migration-mimo-v25-cerveau-hermes.md index 9fd0e56..72e921c 100644 --- a/common/migration-mimo-v25-cerveau-hermes.md +++ b/common/migration-mimo-v25-cerveau-hermes.md @@ -94,3 +94,51 @@ sans erreur de limite cote opencode-go/Bifrost au premier essai. `hermes-nyora/verdict-pilote-mimo-v25.md`, `hermes-tt/passation-pj-hermes-tt-deepseek-mimo.md`, `common/bifrost-access.md`, `common/bifrost-vk-incidents.md`, `common/opencode-go-migration.md`. + + +## Yesmine-Key (VK Bifrost, hermes-desktop-yesmine — client pas encore actif) + +**Perimetre** : uniquement la VK Bifrost `Yesmine-Key` (id `028c7103-cc9f-4139-96a1-3d5420b2d2dd`). +Aucune instance NAS ni fichier agent — toute la config vit en DB Bifrost +(`governance_virtual_key_provider_configs`). + +**Etat trouve (Phase 1, verifie en live, rien suppose)** : +- `allowed_models` (provider `opencode`, row id=38) = `["deepseek-v4-flash"]` uniquement — + mimo-v2.5 absent malgre une decision anterieure supposee (audit du 17/08). `allow_all_keys` + deja a 1 (pas de correction necessaire la-dessus). +- Aucun concept de "modele par defaut" par VK cote Bifrost : schema `governance_virtual_keys` + n'a pas de champ modele ; `routing_rules`/`routing_targets` ne referencent aucun `virtual_key_id` + scope sur Yesmine-Key. Seul filtre existant = `allowed_models`. Le seul enregistrement scope + sur cette VK dans `governance_model_configs` est un rate-limit generique (`model_name='*'`), pas + un modele par defaut. +- Pas de concept context_length/max_output au niveau VK — ces valeurs sont globales par modele + (`governance_model_pricing`), deja documente vide pour `mimo-v2.5/opencode-go` plus haut dans ce + runbook. Hors perimetre de corriger cette table globale ici (deja couverte par les valeurs en dur + 1048576/131000 appliquees sur les yaml de la flotte ; Bifrost lui-meme ne bloque pas sur cette + table vide, confirme par le test Phase 3 ci-dessous). + +**Correction appliquee (Phase 2, edition DB directe — PAS l'API governance, piege `allow_all_keys` +reset connu)** : +```sql +UPDATE governance_virtual_key_provider_configs +SET allowed_models = '["mimo-v2.5"]' +WHERE id = 38 AND virtual_key_id = '028c7103-cc9f-4139-96a1-3d5420b2d2dd' AND provider = 'opencode'; +``` +`docker restart bifrost` obligatoire (chargement DB au boot, memoire vive garde l'ancien etat sinon) +— confirme healthy apres ~50s. + +**Test Phase 3 (controle minimal, hors tool-calling — pas de client reel a simuler)** : +- Appel direct `x-bf-vk` vers `mimo-v2.5` : `resolved_model_used: mimo-v2.5`, `finish_reason: stop`, + aucune erreur. +- Verification du retrait reel (pas juste un ajout) : appel `deepseek-v4-flash` sur la meme VK → + rejete (`could not auto resolve a provider for the request`) — confirme que le retrait est effectif, + pas seulement documentaire. + +**Trace** : ce changement n'existe qu'en DB Bifrost (`config.db`, table +`governance_virtual_key_provider_configs`), aucun fichier Git associe — pas de repo pour cette +config, contrairement aux instances Hermes. Cette entree de runbook est la seule trace ecrite du +changement, a ne pas oublier lors d'une future migration modele generale sur Bifrost. + +**Point ouvert** : `Yesmine-Key` reste provisionnee sans consommateur actif — aucun agent/client +n'appelle cette cle aujourd'hui (`hermes-desktop-yesmine` n'existe pas encore cote Windows/Claude +Desktop). A reevaluer (usage reel, cout, modele par defaut souhaite) quand ce client devient actif.