3.6 KiB
Correctif résiduel : DeepSeek oublié sur hermes-nabil (ticket infra-2026-09-048)
Contexte
Ticket correctif ouvert suite à l'audit indépendant de Claude sur le ticket infra-2026-09-047 (migration DeepSeek V4(.1) Flash → Mimo V2.5 sur le rôle execution/skills/tool-calls, exécutée par Gemini le 12/09/2026).
Constat de l'audit
Le rapport de Gemini annonçait un "recensement exhaustif" couvrant toute la flotte Hermes NAS/VPS. Vérification indépendante poste par poste :
- hermes-agent-tt : profil evaluateur-ao + bloc delegation → mimo-v2.5, confirmé, aucune trace de deepseek.
- hermes-agent-nyora : bloc auxiliary.approval → mimo-v2.5, confirmé, aucune trace de deepseek.
- hermes-agent-perso : déjà propre (mimo-v2.5 partout) avant même le ticket 047, rien à migrer — explique l'absence de mention dans le rapport de Gemini.
- context-hub (scope llm) : default_model mimo-v2.5, confirmé via API.
- n8n : workflow actif 702UIFgeJBc8xPAC confirmé migré ; requête directe sur workflow_entity (n8n-DB) — tous les autres workflows contenant "deepseek" dans leurs nodes sont inactifs, aucun autre consommateur actif oublié.
- hermes-nabil (VPS) : bloc
delegationencore surprovider: openrouter/model: deepseek/deepseek-v4-flash— non détecté par Gemini, absent du rapport et des 6 interventions Baserow. Cause probable : ce chemin passe par OpenRouter directement (pas par Bifrost), donc invisible à une vérification centrée sur les VK Bifrost. - DSH (VPS) : un seul sélecteur de modèle dans settings.yaml (agent-default-model), déjà sur un modèle gratuit OpenRouter, jamais DeepSeek. Les autres occurrences de "deepseek" dans l'arborescence sont des noms de packages npm (@deepseek-ai/...), sans rapport avec le routage de modèle.
- openclaw-perso : agents.defaults.model.primary déjà sur bifrost/opencode/mimo-v2.5. Les entrées DeepSeek trouvées ne sont que des entrées de catalogue de modèles disponibles, pas la sélection active.
- opencode natif VPS : model top-level déjà sur bifrost/mimo-v2.5.
"Tirith" identifié
Ce n'est pas un consommateur séparé mais un sous-système de sécurité interne à hermes-nabil (security.tirith_enabled, script /opt/hermes/tools/tirith_security.py, scan statique sans modèle LLM propre codé en dur). Aucune action de migration nécessaire dessus spécifiquement.
Correctif appliqué par Claude (12/09/2026)
- Sauvegarde :
/data/config.yaml.bak-pre-ticket048-20260912-095604sur le conteneur hermes-nabil. - Bloc
delegationmodifié :provider: openrouter→custom,model: deepseek/deepseek-v4-flash→mimo-v2.5, ajout debase_url: http://100.94.90.119:3086/v1etapi_key(VK dédiée hermes-nabil), alignés sur le blocmodeltop-level déjà en place sur la même instance. - YAML validé (
python3 -c "import yaml; yaml.safe_load(...)"), zéro trace résiduelle de "deepseek" dans le fichier. - Conteneur redémarré proprement (logs de démarrage sans erreur).
- Test de routage réel via bifrost-proxy avec la VK hermes-nabil : requête correctement résolue vers provider=opencode / model=mimo-v2.5 (confirmation que le VK autorise bien mimo-v2.5 et que le routage aboutit) — réponse 429
GoUsageLimitError(quota mensuel OpenCode Go épuisé, reset attendu sous 24h), un état global pré-existant et non lié à ce correctif, qui empêche un test fonctionnel bout-en-bout à chaud mais confirme que le chemin de routage est correct.
Verdict d'audit
Réserves sur le ticket infra-2026-09-047 (recensement non exhaustif malgré l'annonce). Correctif clos en définitif sur le ticket infra-2026-09-048, exécuté et audité par Claude dans la même session.