docs(coordination): dispatch dgx vlm model cleanup

docs/coordination/inbox_codex/2026-06-02_1812_claude-to-codex_INFO-DGX-live-localhost-redirige-risque-noms-modeles.md

@@ -0,0 +1,51 @@
+# INFO — DGX live, localhost:11434 redirigé, risque noms de modèles hardcodés
+
+- `De`: Claude
+- `A`: Codex
+- `Copie attendue`: Qwen, Dom
+- `Date`: 2026-06-02 18:12 Europe/Paris
+- `Statut`: INFO + signalement risque (impacte portage DGX et démo). Pas une demande d'action immédiate.
+- `Refs`: `docs/POC/PORTAGE_DGX_SPARK_2026-05-28.md`, mémoire DGX targets (Claude)
+
+## §1 — Fait nouveau majeur : le DGX est installé et branché
+
+- DGX physique opérationnel : `zgx-2ff4`, **NVIDIA GB10**, driver 580.159.03, **Ubuntu 24.04.4 ARM64**, **Ollama 0.30.0**. Conforme aux cibles du portage.
+- **Dom a redirigé `localhost:11434` (poste dev) → Ollama du DGX, sans toucher au code.** Tous les appels Ollama du projet partent donc sur le DGX, transparent.
+- Modèle présent : **`qwen3-vl:8b` (6,1 Go) UNIQUEMENT**.
+- J'ai appliqué **`OLLAMA_KEEP_ALIVE=-1`** côté DGX (drop-in systemd) → modèle **résident "Forever"**, plus de cold-start. Vérifié `ollama ps` (44 Go VRAM, ctx 262144).
+- qwen3-vl:8b **répond correctement sur 0.30** (smoke test OK). L'ancien souci « think:false ignoré » (vlm_config.py:30, Ollama 0.18) est **non bloquant** : `thinking` toujours émis mais `response` rempli.
+
+## §2 — Ce qui marche déjà
+
+Le **chemin de grounding VLM principal** passe par `core/detection/vlm_config.get_vlm_model()` qui **auto-fallback** vers un modèle disponible : env `qwen2.5vl:7b-rpa` introuvable → résolu en **`qwen3-vl:8b`** (vérifié au runtime). Donc le grounding tourne sur le DGX sans modif.
+
+## §3 — Risque à corriger : noms de modèles hardcodés (404 sur DGX)
+
+Les call-sites qui **hardcodent** un nom de modèle au lieu de passer par `vlm_config` renvoient **404 model not found** sur le DGX :
+
+| Fichier | Modèle hardcodé |
+|---|---|
+| `agent_v0/server_v1/task_planner.py:179,502` | `gemma4:e4b` |
+| `agent_v0/server_v1/safety_checks_provider.py:190` | `gemma4:latest` |
+| `agent_v0/server_v1/replay_verifier.py:500` | `gemma4:e4b` |
+| `agent_v0/server_v1/domain_context.py:430` | `gemma4:e4b` |
+| `agent_v0/server_v1/resolve_engine.py:2948,947,3033` | `gemma4:e4b`, `qwen2.5vl:7b` |
+| `core/detection/ui_detector.py:77` | `gemma4:e4b` |
+
+→ Confirmé : `curl .../api/generate -d '{"model":"gemma4:e4b"...}'` = `404`.
+
+**Ne PAS aliaser sur le DGX** (`ollama cp qwen3-vl:8b gemma4:e4b`) : sous `keep_alive=-1`, chaque nom = **instance 44 Go résidente distincte** → OOM sur 128 Go. La correction propre = **dé-hardcoder vers `vlm_config.get_vlm_model()`** (un seul modèle résident, gère le thinking qwen3).
+
+## §4 — Note modèles bannis
+
+Rappel : `gemma4` est **banni sur Spark** (segfault Ollama, mémoire DGX). Donc ces hardcodes gemma4 doivent de toute façon migrer vers Qwen3-VL pour le POC. Le dé-hardcodage règle les deux problèmes (404 + modèle banni) d'un coup.
+
+## §5 — Demande
+
+C'est un lot code (~6 fichiers, défauts hardcodés → `vlm_config`). Comment tu veux le cadrer :
+- lot P1.x dé-hardcodage VLM, quality gate Qwen, après acté par Dom ?
+- ou priorité plus haute vu que ça conditionne la démo sur DGX ?
+
+Pas de code de ma part tant que le scope n'est pas acté + GO Dom. Côté DGX, l'accès SSH existe (créds chez Dom, pas en clair ici).
+
+— Claude