Files
nas-runbooks/common/correctif-hermes-nabil-deepseek-residuel-ticket048-20260912.md
T

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 delegation encore sur provider: 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)

  1. Sauvegarde : /data/config.yaml.bak-pre-ticket048-20260912-095604 sur le conteneur hermes-nabil.
  2. Bloc delegation modifié : provider: openroutercustom, model: deepseek/deepseek-v4-flashmimo-v2.5, ajout de base_url: http://100.94.90.119:3086/v1 et api_key (VK dédiée hermes-nabil), alignés sur le bloc model top-level déjà en place sur la même instance.
  3. YAML validé (python3 -c "import yaml; yaml.safe_load(...)"), zéro trace résiduelle de "deepseek" dans le fichier.
  4. Conteneur redémarré proprement (logs de démarrage sans erreur).
  5. 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.