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

37 lines
3.6 KiB
Markdown

# 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: openrouter``custom`, `model: deepseek/deepseek-v4-flash``mimo-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.