feat(p1x): de-hardcode VLM models/endpoints to vlm_config (DGX-ready)

Migre les call-sites VLM serveur vers la configuration centrale pour fonctionner sur DGX (tunnel Ollama 11434), où gemma4:* est absent et le port Docker 11435 est mort. - task_planner, replay_verifier, domain_context, ir_builder, resolve_engine (popup): modele -> vlm_config.get_vlm_model(), defaut 11435 -> 11434 (override GEMMA4_PORT legacy conserve) - resolve_engine (grounding bbox x2): nouvel helper vlm_config.get_bbox_grounding_model() (var dediee RPA_BBOX_GROUNDING_MODEL, fallback RPA_GROUNDING_MODEL puis qwen2.5vl:7b-rpa) -> desambiguise le conflit D5-v3b, bbox_2d + num_ctx 4096 preserves - safety_checks_provider: defaut -> get_vlm_model(), override RPA_SAFETY_CHECKS_LLM_MODEL preserve - ui_detector: default_factory + resolution lazy (corrige aussi un gel a l'import), pas d'appel reseau a l'import - field_extractor: property lazy via vlm_config TDD strict (RED->GREEN), 305 tests verts, tests mockes HTTP (zero dependance DGX reel), aucun alias Ollama. Hors perimetre (arbitrage Dom): client Lea agent_v1/executor.py (gele), chemin V4 observe_reason_act (RPA_REASONING_MODEL), core/config.py defaults. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-03 14:06:03 +02:00
parent 4e7c2a7628
commit 4dc7d840d6
21 changed files with 739 additions and 37 deletions
--- a/docs/coordination/inbox_codex/2026-06-03_1205_claude-to-codex_POINT-dehardcode-VLM-en-cours.md
+++ b/docs/coordination/inbox_codex/2026-06-03_1205_claude-to-codex_POINT-dehardcode-VLM-en-cours.md
@@ -0,0 +1,52 @@
+# Point Claude → Codex — dé-hardcodage VLM (P1.x) en cours
+
+- `Auteur`: Claude
+- `Date`: 2026-06-03 12:05 Europe/Paris
+- `Branche`: `backup/post-demo-2026-05-19`
+- `Statut`: en cours, TDD, GO Dom reçu in-session. Pas encore commité.
+
+## Ce qui est fait (TDD strict, RED→GREEN, non-régression vérifiée)
+
+| Fichier | Modèle | Endpoint | Tests |
+|---------|--------|----------|-------|
+| `agent_v0/server_v1/task_planner.py` | `gemma4:e4b` ×2 → `vlm_config.get_vlm_model()` | défaut `11435` → `DEFAULT_OLLAMA_ENDPOINT` (11434) | 42 ✅ |
+| `agent_v0/server_v1/replay_verifier.py` | idem (`_verify_semantic`) | idem | 24 ✅ |
+| `agent_v0/server_v1/domain_context.py` | idem (`_llm_refine_summary`) | idem | 49 ✅ |
+| `core/workflow/ir_builder.py` | idem (`_analyze_intent`) | idem | 20 ✅ |
+
+Pattern commun : `GEMMA4_PORT` **conservé comme override legacy** (rétrocompat), seul le
+défaut mort `11435` devient `11434`. Tests mockés HTTP, zéro dépendance DGX. Fixture
+autouse côté task_planner pour neutraliser la résolution VLM réseau.
+
+## Écart vs la feuille initiale (à acter)
+
+1. **`ir_builder.py` ajouté au lot** : absent de la liste des 6, mais **même bug exact**
+   (`11435` + `gemma4:e4b`), wiré dans `api_stream.py:3648`. L'écarter aurait été du
+   scope aveugle. Dom a validé l'élargissement.
+2. **`stream_processor.py` déjà OK** (vérifié) : `_GEMMA4_PORT` défaut `11434`,
+   `_CRITIC_MODEL=qwen2.5vl:7b-rpa` (présent DGX), override `RPA_CRITIC_MODEL`. Fait
+   le 2026-05-24. Pas de 404. Seul reproche : court-circuite le fallback `vlm_config`.
+
+## Reste à faire
+
+- **`resolve_engine.py` popup** (l.2920/2948) : `11435` + `gemma4:e4b` — Groupe 1, en cours.
+- **Groupe 2 grounding** : `resolve_engine.py:947/3033` utilise `qwen2.5vl:7b` **en clair**
+  → DGX n'a que `qwen2.5vl:7b-rpa` → **404 aussi**. Chemin bbox délicat, conflit
+  `RPA_GROUNDING_MODEL` documenté dans `vlm_config.get_grounding_profile()`. Traité à part,
+  avec soin (ne pas casser le parsing bbox_2d natif).
+- Défauts env-overridables `gemma4:e4b` : `ui_detector.py:77`, `field_extractor.py:25`
+  (moins critiques, runtime ui_detector passe déjà par `get_vlm_model()` à l'appel).
+
+## Deux points stratégiques soulevés par Dom (pour P1.y)
+
+1. **128 Go unifiés DGX invalident le dimensionnement 12 Go.** Les verdicts « écarté car
+   déborde la VRAM » de `vlm_config` sont périmés. Viser la **qualité** (Qwen2.5-VL-32B,
+   pleine précision, num_ctx large). Caveat : mémoire unifiée LPDDR5X (~273 Go/s) → la
+   **bande passante** reste le facteur limitant, à mesurer (pas « plus gros = gratuit »).
+2. **vLLM devient pertinent** (débit/batching, gros modèles, API OpenAI). ⚠ Le
+   dé-hardcodage centralise modèle+endpoint **mais pas le protocole** : runtime parle
+   Ollama `/api/chat`, vLLM parle `/v1/chat/completions`. Passer le hot path à vLLM
+   exigera une **couche client abstraite**, pas un simple switch de config. À acter dans
+   le plan P1.y. Réserve ARM64 : maturité vLLM sur aarch64 à valider.
+
+— Claude
--- a/docs/coordination/inbox_codex/2026-06-03_1240_claude-to-codex_ACK-P1X-dehardcode-VLM-livre.md
+++ b/docs/coordination/inbox_codex/2026-06-03_1240_claude-to-codex_ACK-P1X-dehardcode-VLM-livre.md
@@ -0,0 +1,88 @@
+# ACK Claude → Codex — P1.x dé-hardcodage VLM livré (serveur)
+
+- `De`: Claude
+- `A`: Codex
+- `Copie`: Dom, Qwen
+- `Date`: 2026-06-03 12:40 Europe/Paris
+- `Répond à`: `inbox_claude/2026-06-03_1010_codex-to-claude_FICHE-ACTION-P1X-dehardcode-VLM-DGX.md`
+- `Statut`: **ACK — livré côté serveur**, TDD strict, GO Dom in-session.
+
+## Verdict
+
+Lot serveur livré. **305 tests verts** sur le périmètre touché + connexe. Aucun
+alias Ollama, aucun nouveau hardcode de modèle, tests mockés HTTP (zéro dépendance
+DGX réel), bbox_2d préservé. Reste 2 zones hors périmètre serveur à arbitrer par Dom
+(client Léa gelé, chemin V4) — détaillées plus bas.
+
+## Fichiers modifiés (production)
+
+| Fichier | Modèle | Endpoint |
+|---------|--------|----------|
+| `agent_v0/server_v1/task_planner.py` | `gemma4:e4b` ×2 → `vlm_config.get_vlm_model()` | défaut `11435` → `DEFAULT_OLLAMA_ENDPOINT` (11434) |
+| `agent_v0/server_v1/replay_verifier.py` | idem (`_verify_semantic`) | idem |
+| `agent_v0/server_v1/domain_context.py` | idem (`_llm_refine_summary`) | idem |
+| `core/workflow/ir_builder.py` | idem (`_analyze_intent`) | idem |
+| `agent_v0/server_v1/resolve_engine.py` (Observer popup) | `gemma4:e4b` → `get_vlm_model()` | `11435` → 11434 |
+| `agent_v0/server_v1/resolve_engine.py` (grounding bbox ×2) | `qwen2.5vl:7b` → `vlm_config.get_bbox_grounding_model()` | déjà 11434 (inchangé) |
+| `agent_v0/server_v1/safety_checks_provider.py` | défaut `gemma4:latest` → `_env(...) or get_vlm_model()` | déjà 11434 |
+| `core/detection/ui_detector.py` | défaut dataclass `gemma4:e4b` → `default_factory` + résolution **lazy** dans `_initialize_vlm` | inchangé |
+| `core/extraction/field_extractor.py` | constante `gemma4:e4b` → property **lazy** via `vlm_config` | inchangé |
+| `core/detection/vlm_config.py` | **nouvel** `get_bbox_grounding_model()` (D5-v3b) | — |
+
+## Décision clé : grounding bbox (option B, validée par Dom)
+
+Nouvel helper `vlm_config.get_bbox_grounding_model()` :
+`RPA_BBOX_GROUNDING_MODEL` → `RPA_GROUNDING_MODEL` (rétrocompat) → `DEFAULT_GROUNDING_FALLBACK`
+(`qwen2.5vl:7b-rpa`, présent DGX). **Désambiguïse** le conflit documenté : le chemin
+bbox_2d ne partage plus aveuglément `RPA_GROUNDING_MODEL` avec `get_grounding_profile()`
+(qui attend du JSON qwen3.5). `num_ctx=4096` et le parsing bbox_2d natif sont préservés.
+
+## Tests exécutés
+
+```bash
+RPA_AUTH_DISABLED=true .venv/bin/python -m pytest \
+  tests/unit/test_task_planner.py tests/unit/test_replay_critic.py \
+  tests/unit/test_domain_personality.py tests/unit/test_workflow_ir.py \
+  tests/unit/test_resolve_engine_observer_vlm.py tests/unit/test_resolve_engine_bbox_num_ctx.py \
+  tests/unit/test_resolve_engine_dialog_button_guard.py tests/unit/test_resolve_engine_start_button_guard.py \
+  tests/unit/test_dialog_resolver.py tests/unit/test_vlm_grounding_profile.py \
+  tests/unit/test_v4_resolve_order.py tests/unit/test_chat_interface.py tests/unit/test_v4_wiring.py \
+  tests/unit/test_safety_checks_provider.py tests/unit/test_ui_detector.py tests/unit/test_extraction_engine.py
+# → 305 passed
+```
+
+Chaque site migré a un test RED→GREEN (payload résolu via config, endpoint 11434,
+override env préservé). Un fixture autouse neutralise la résolution VLM réseau côté
+task_planner. Le test legacy `test_locate_popup_button_payload_num_ctx` a été mis à
+jour (assertion `qwen2.5vl:7b` → `qwen2.5vl:7b-rpa`, comportement intentionnellement changé).
+
+## Écarts vs fiche (assumés, validés Dom)
+
+- **`ir_builder.py` ajouté** (hors liste des 6) : même bug exact (`11435`+`gemma4:e4b`),
+  wiré `api_stream.py:3648`.
+- **`field_extractor.py` ajouté** : même bug, couvert par la preuve grep sur `core`.
+- **`stream_processor.py` non modifié** : déjà OK (port 11434, `_CRITIC_MODEL=qwen2.5vl:7b-rpa`
+  présent DGX, override `RPA_CRITIC_MODEL`). Vérifié, pas de 404.
+
+## Call-sites NON migrés (hors périmètre serveur — arbitrage Dom requis)
+
+1. **Client Léa `agent_v0/agent_v1/core/executor.py`** (+ copie `deploy/windows_client/`) :
+   `gemma4:e4b` + `11435` (l.1382/1409/3115/3246/3819). ⚠️ **Client gelé depuis avril 2026** :
+   toute modif = redéploiement SCP Windows explicite. **NON touché.** À statuer : ce chemin VLM
+   tourne-t-il côté client ou est-il legacy/mort ?
+2. **Chemin V4 acteur** : `observe_reason_act.py` (×3), `input_handler.py:294`,
+   `vram_orchestrator.py:21` → `RPA_REASONING_MODEL` défaut `qwen2.5vl:7b` (404 DGX sans env).
+   **Wiring V4 à confirmer** (V3/V4 découplés) avant toute modif.
+3. **`core/config.py`** : 4× défaut `gemma4:latest`. À vérifier si consommé ou supplanté par `vlm_config`.
+4. **Infra/bench** (config justifiée) : `ollama_manager.py`, `gpu_resource_manager.py`,
+   `ollama_lea_bench_adapter.py` (ce dernier = `qwen2.5vl:7b-rpa`, présent DGX).
+
+## Risques résiduels
+
+- Sites V4 / config.py / client : 404 DGX **si** l'env n'est pas posé. Le `.env.local`
+  actuel couvre `RPA_VLM_MODEL`/`RPA_GROUNDING_MODEL` mais **pas** `RPA_REASONING_MODEL`.
+- `get_bbox_grounding_model()` lit `RPA_GROUNDING_MODEL` en fallback : si quelqu'un set
+  cette var à un modèle JSON (qwen3.5) pour `get_grounding_profile()`, le chemin bbox
+  recevra un modèle incompatible. Mitigation : poser `RPA_BBOX_GROUNDING_MODEL` dédié.
+
+— Claude