infra+garde-fou: fix routing vision text-only + protocole anti-hallucination benchmarks (27/07/2026)

common/vision-auxiliaire-routing-text-only-modeles.md

@@ -0,0 +1,59 @@
+# Vision auxiliaire mal routee sur modeles text-only (auto -> echec silencieux)
+
+**Instance auteur** : Claude (diagnostic multi-instance, hermes-perso + hermes-tt)
+**Date** : 2026-07-27
+**Tags** : [infra, vision, bifrost, config, transverse]
+**Statut** : valide
+
+---
+
+## Probleme
+
+`vision_analyze` echouait systematiquement sur hermes-perso (contexte : extraction guide d'orientation universitaire, screenshots de verification) avec une erreur `400 - Upstream request failed` (parfois 404 selon le provider), empechant toute verification visuelle avant livraison -- alors que cette verification est une regle etablie (post-incident IAKifech Ep2 : jamais de validation sur metriques seules).
+
+## Contexte et contraintes
+
+Config `auxiliary.vision.provider: auto` dans `config.yaml` de chaque instance Hermes. `auto` resout vers le modele principal configure pour l'instance (`model.default`). Sur hermes-perso et hermes-tt, ce modele principal est `deepseek-v4-flash` -- un modele **text-only** (confirme OpenRouter : Text-only, no vision/image input). Toute image envoyee a ce provider echoue par construction, pas par bug transitoire.
+
+hermes-nyora et hermes-nabil tournent sur `mimo-v2.5`, natif omnimodal -- `auto` fonctionne correctement pour ces deux-la, ce qui a masque le probleme puisqu'il ne touchait que 2 instances sur 4.
+
+## Ce qui NE fonctionne PAS
+
+| Tentative | Erreur obtenue | Raison de l'echec |
+|-----------|----------------|-------------------|
+| Laisser `auto` par defaut | `400 Upstream request failed` / `404` sur toute image | `auto` pointe vers le modele principal, ici text-only |
+| Ne rien configurer et esperer un fallback automatique | Meme erreur, aucun fallback vision dans la structure `auxiliary.vision` (pas de liste, contrairement a `fallback_providers` du modele principal) | La structure de config n'a qu'un seul provider/model pour vision, pas de chaine de fallback |
+
+## Solution validee
+
+Router explicitement `auxiliary.vision` vers un modele multimodal via Bifrost, avec les memes identifiants que le modele principal (meme base_url/api_key, provider custom) :
+
+```yaml
+auxiliary:
+  vision:
+    provider: custom
+    model: google/gemini-2.5-flash
+    base_url: http://bifrost-proxy/v1
+    api_key: bfk-0cd1fba7d440ca2eefd30b28a7349b7d28422dcbc49e982d
+    timeout: 120
+    download_timeout: 30
+```
+
+Applique sur `hermes-perso` et `hermes-tt` (fichiers `config.yaml`, backup `.bak-20260727` conserve a cote). Containers redemarres (`docker restart`) pour charger la nouvelle config -- `config.yaml` n'est lu qu'au demarrage, jamais a chaud (meme piege que `jobs.json`, cf. regle cron dans PROTOCOL-INFRA.md).
+
+`hermes-nyora` et `hermes-nabil` laisses en `auto` : leur modele principal gere nativement la vision, pas de changement necessaire pour l'instant.
+
+## Verification
+
+Prochaine tache impliquant une image sur hermes-perso ou hermes-tt : confirmer dans les logs (`/opt/data/logs/errors.log` ou `agent.log`) que l'appel vision affiche `provider=custom` et `model=google/gemini-2.5-flash` dans `routing_info`, plus aucune trace de `deepseek-v4-flash` sur un appel vision.
+
+## Pieges specifiques
+
+- `config.yaml` n'est pas recharge a chaud -- toujours redemarrer le container apres modification, quel que soit le champ touche.
+- Verifier ce meme champ sur toute future instance Hermes creee avec un modele principal text-only -- le defaut `auto` est un piege qui ne se revele qu'a l'usage (premier envoi d'image).
+- Le Gemini utilise ici (`google/gemini-2.5-flash`) est deja configure comme provider dans `bifrost-proxy/models.json` -- pas de nouvelle cle a creer.
+
+## References
+
+- Incident declencheur : diagnostic hermes-perso, tache orientation universitaire Yesmine (27/07/2026)
+- common/bifrost-vk-incidents.md, common/hermes-vers-bifrost-bifrost-proxy.md