# AXE A5 — Tokenisation d'écran (OmniParser, Set-of-Marks, modèles natifs)

**Date :** 2026-05-23
**Auteur :** Claude (agent dispatché par session principale)
**Statut :** lecture seule, recherche pour arbitrage post-démo. Pas d'action proposée.
**Axes liés :** A1 (modèles VLM grounding), A4 (OCR/docTR/RapidOCR), CLAUDE.md §asymétrie record/replay.

---

## 1. TL;DR

**Recommandation : Scénario B (log implicite, no risk) maintenant, Scénario A (OmniParser V2 dans la cascade replay) à instruire post-démo, Scénario C (OS-Atlas / GUI-Actor) à benchmarker en R&D mais hors trajectoire courte.**

**Top finding** : `core/detection/som_engine.py` est **déjà câblé** sur les weights OmniParser (`/home/dom/ai/OmniParser/weights/icon_detect/model.pt`, YOLOv8) côté serveur. Utilisé en **recording** (`stream_processor.py:607-638`) ET déclaré dans une voie `_resolve_set_of_marks` du `resolve_engine.py:1083-1325`. L'asymétrie pointée par CLAUDE.md n'est donc pas "UI-DETR-1 vs rien", elle est "SomEngine activé selon les paths". À vérifier au runtime si `_resolve_set_of_marks` est effectivement appelé en replay — possible code orphelin (cf. champs de mines CLAUDE.md).

**Trois faits 2025 qui changent l'arbitrage :**
1. **OmniParser V2** (publié 12 février 2025, MIT pour le code + Florence-2, **AGPL-3.0 pour les poids YOLOv8 icon_detect**) — 0.6 s/frame A100, 0.8 s/frame RTX 4090, état de l'art ScreenSpot-Pro 39.6 % combiné GPT-4o. Notre RTX 5070 ≈ 12 GB VRAM tient le pipeline complet (icon_detect ~150 MB + Florence-2 base ~750 MB).
2. **Set-of-Mark** (Yang et al., arXiv 2310.11441, NeurIPS 2023) — pattern qui sous-tend OmniParser, Magma, ShowUI. Devenu vocabulaire standard du domaine en 2025.
3. **Coordinate-free grounding émerge** : GUI-Actor (Microsoft, NeurIPS 2025) et Aguvis (ICML 2025) bypassent le besoin d'un étage de tokenisation séparé. GUI-Actor-7B sur Qwen2.5-VL = 44.6 % ScreenSpot-Pro, > UI-TARS-72B. **Tendance** : la tokenisation explicite OmniParser-style devient un raccourci d'aujourd'hui que les VLM "GUI-natifs" intégreront demain.

**Verdict honnête pour rpa_vision_v3** : la cause des bugs récents (cf. `REPLAY_BLOCAGE_NOTES_MEDICALES_2026-05-08.md`) est **transport HTTP + OCR-DIRECT center-of-line**, pas la cascade vision. Ajouter OmniParser V2 en replay ne réparera **rien** des bugs P0 ouverts. Mais c'est la brique manquante pour le **Validator** (Skyvern-style) et pour un **log de candidats parsés** côté replay (suggestion §4.1 de `INSPIRATION_FRAMEWORKS`).

---

## 2. OmniParser V2 — fiche détaillée

### 2.1. Identité

- **Auteur** : Microsoft Research
- **Repo** : https://github.com/microsoft/OmniParser
- **Modèle HF** : https://huggingface.co/microsoft/OmniParser-v2.0
- **Release V2** : 12 février 2025
- **Stars GitHub mai 2026** : ~22k (cité dans `INSPIRATION_FRAMEWORKS_2026-05-10.md`)
- **Article officiel** : https://www.microsoft.com/en-us/research/articles/omniparser-v2-turning-any-llm-into-a-computer-use-agent/

### 2.2. Architecture interne (2 modèles)

| Sous-modèle | Rôle | Taille | Backend | Licence |
|---|---|---|---|---|
| **icon_detect** | YOLOv8 fine-tuné sur dataset Microsoft d'éléments interactifs (boutons, icônes, champs) | ~150 MB | Ultralytics `YOLO` | **AGPL-3.0** ⚠ |
| **icon_caption** | Florence-2 base fine-tuné sur 7K paires icon-description annotées GPT-4o | ~750 MB | Transformers | **MIT** |

**OCR** : OmniParser embarque aussi un OCR (PaddleOCR ou EasyOCR selon config). Notre `som_engine.py` actuel **a remplacé** par docTR (cf. lignes 117-127).

### 2.3. Format de sortie ("interactable elements")

Liste de dicts avec :
- `bbox` (coordonnées normalisées 0-1)
- `interactivity` (true / false)
- `content` (caption Florence-2 : "close button", "search field", "OK")
- `source` ("box_yolo_content_ocr" / "box_yolo_content_yolo" / "icon")

Cette sortie est conçue pour être insérée **dans le prompt du VLM principal** (GPT-4o, Claude) sous forme de tableau numéroté → c'est du Set-of-Marks appliqué automatiquement.

### 2.4. Performance benchmarks

| Métrique | Valeur | Source |
|---|---|---|
| ScreenSpot-Pro + GPT-4o | **39.6 %** | Microsoft Research article 2026-02-12 |
| ScreenSpot-Pro GPT-4o seul (sans OmniParser) | 0.8 % | idem |
| Latence A100 (1 frame) | **0.6 s** | idem |
| Latence RTX 4090 (1 frame) | **0.8 s** | idem |
| VRAM mini | 4 GB (inference) / 8 GB (recommandé loop agent) | GitHub Issue #31 |
| Résolution supportée | 640 → **1920 px** côté long (icon_detect) | doc HF V2.0 |

**Implication directe rpa_vision_v3** : nos screenshots Léa sont **2560×1600** (RTX 5070). Il faudra **resize** à 1920 px côté long → ratio ~0.75. Toutes les coordonnées YOLO de retour doivent être re-scalées. **Risque** : c'est le même piège que `smart_resize` Qwen2.5-VL bbox_2d (DETTE-006/010/014, `MIGRATION_VLM_PLAN_2026-05-09.md` §2). À traiter explicitement.

### 2.5. Licence — point sensible commercial

Combinaison **AGPL-3.0** (icon_detect) + **MIT** (icon_caption + code) :
- **AGPL-3.0** sur icon_detect = **interdit en produit commercial fermé** sans rachat de licence YOLOv8 commercial (Ultralytics, ~5 000 $/an estimé), ou remplacement par un détecteur alternatif (Florence-2 task `<OD>`, ou détecteur custom).
- Pour rpa_vision_v3 en POC interne / GHT / Anoust : usage actuel défendable. **Pour vente externe : showstopper sur icon_detect tel quel**.

Le code de notre `som_engine.py` charge directement `/home/dom/ai/OmniParser/weights/icon_detect/model.pt` (AGPL-3.0) → audit licence à reprendre.

### 2.6. État interne du projet — code existant

- `core/detection/som_engine.py` (316 lignes, complet) — singleton thread-safe, YOLO + docTR + annotation. Device par défaut `cpu` (cf. `get_shared_engine`).
- `core/detection/omniparser_adapter.py` — wrapper plus complet citant Florence-2 caption. **Sépare** du `som_engine.py` simplifié.
- `agent_v0/server_v1/stream_processor.py:607-700` — appel SoM au **recording** pour enrichir chaque event click avec l'élément cliqué (cf. UI-DETR-1 dans `INSPIRATION_FRAMEWORKS_2026-05-10.md` §4 — c'est en fait SoM, pas un détecteur tiers).
- `agent_v0/server_v1/resolve_engine.py:1083-1325` — voie `_resolve_set_of_marks` au **replay**. Lance SomEngine, fallback template matching anchor↔éléments YOLO. **À tracer au runtime** pour confirmer qu'elle est invoquée.

→ **L'asymétrie record/replay décrite dans CLAUDE.md n'est peut-être pas l'asymétrie réelle.** À valider explicitement avec Dom au prochain run.

---

## 3. Set-of-Marks original

### 3.1. Identité

- **Papier** : Yang et al., "Set-of-Mark Prompting Unleashes Extraordinary Visual Grounding in GPT-4V", arXiv 2310.11441 (oct 2023, dernière révision nov 2023)
- **Code** : https://github.com/microsoft/SoM
- **Lien** : https://arxiv.org/abs/2310.11441
- 124 citations (mai 2026)

### 3.2. Approche

1. Segmenter l'image en régions sémantiques (SEEM ou SAM, off-the-shelf)
2. Overlayer chaque région avec un **mark** (numéro, lettre, masque coloré, bbox)
3. Demander au VLM : "click on mark 7" plutôt que "click at (x=420, y=380)"

Bénéfice : le VLM raisonne en **identifiants discrets** et non en coordonnées continues. Évite le bug des coords mal calibrées (cf. notre DETTE-006 bbox_2d Qwen2.5-VL).

### 3.3. Résultats clés (papier 2023)

GPT-4V + SoM en zero-shot **bat le SOTA fine-tuned** sur RefCOCOg (referring expression comprehension). Pour la première fois, un modèle généraliste prompted dépasse les modèles spécialisés sur ce benchmark.

### 3.4. Complémentarité avec OmniParser

- **SoM = méthode de prompting** (overlay sur l'image, le VLM répond un ID)
- **OmniParser = pipeline complet** (détection + caption + format prompt)
- OmniParser = "SoM industrialisé pour les UIs". OmniParser fournit les régions ET les marks ET les captions, contre SoM original qui fournit seulement les marks à partir d'une segmentation SEEM/SAM générique.
- Magma (Microsoft, CVPR 2025) entraîne explicitement le modèle sur des images SoM-labellisées → SoM passe de "trick de prompting" à "supervision de pré-entraînement".

---

## 4. Modèles VLM qui tokenisent nativement

### 4.1. OS-Atlas-Base (ICLR 2025)

- **Repo** : https://github.com/OS-Copilot/OS-Atlas
- **Modèles** : OS-Atlas-Base-4B (sur InternVL2-4B) et OS-Atlas-Base-7B (sur Qwen2-VL-7B-Instruct)
- **Approche** : entraînement sur **13 M éléments GUI** cross-platform (Windows, Linux, macOS, Android, web). Tokens spéciaux `<|box_start|>(x1,y1),(x2,y2)<|box_end|>`. Coordonnées normalisées 0-1000.
- **Tokenise nativement ?** Pas au sens "produit une liste d'éléments en sortie", mais **internalise la grammaire bbox** comme tokens spéciaux. Le modèle apprend que "(124, 380) → (228, 412)" est une bbox, pas une séquence d'entiers libres.
- **Coût** : OS-Atlas-Base-7B = ~14 GB FP16, ~7 GB en 4-bit. Compatible RTX 5070 12 GB en 4-bit ou avec Flash-Attn.

### 4.2. ShowUI-2B (CVPR 2025, Outstanding Paper NeurIPS 2024 workshop)

- **Repo** : https://github.com/showlab/ShowUI
- **HF** : https://huggingface.co/showlab/ShowUI-2B
- **Innovation clé** : **UI-Guided Visual Token Selection** — construit un graphe UI au sein du modèle, élimine 33 % des tokens visuels redondants. **5× plus rapide, 2× plus précis** que les VLM généralistes en localisation.
- **Perf** : **75.1 % accuracy zero-shot ScreenSpot grounding** avec seulement 2B params + 256K échantillons de training.
- **Tokenise nativement ?** Oui, c'est sa nature : la sélection des tokens visuels EST une forme de tokenisation. Pas de pipeline externe.
- **Coût** : 2B params → ~4 GB FP16, ~2 GB en 4-bit. **Léger pour notre RTX 5070**.

### 4.3. Aguvis (ICML 2025)

- **Repo** : https://aguvis-project.github.io/
- **Approche** : framework "pure vision" multi-plateforme avec **inner monologue** structuré. Pipeline 2 étapes (grounding séparé de planification).
- **Caractéristique** : premier agent GUI pure-vision entièrement **open-source** (sans dépendance closed-source).

### 4.4. GUI-Actor (Microsoft, NeurIPS 2025) — **le plus pertinent**

- **Repo** : https://github.com/microsoft/GUI-Actor
- **HF** : https://huggingface.co/microsoft/GUI-Actor-7B-Qwen2.5-VL
- **Innovation** : **coordinate-free**. Au lieu de produire "(420, 380)", produit un token `<ACTOR>` qui s'attache via attention aux patches visuels pertinents. Génère plusieurs régions candidates en 1 forward.
- **Perf** : GUI-Actor-7B sur Qwen2.5-VL = **44.6 % ScreenSpot-Pro** (> UI-TARS-72B).
- **Implication directe** : **tue le bug d'échelle bbox_2d** (DETTE-006/010/014) à la racine. Pas de smart_resize à débugger. Pas de mismatch de résolution.
- **Coût** : 7B + Qwen2.5-VL → ~14 GB FP16, ~7 GB 4-bit. Compatible RTX 5070 en 4-bit.

### 4.5. Magma (Microsoft, CVPR 2025)

- **Repo** : https://github.com/microsoft/Magma
- **Approche** : pré-entraînement multimodal avec **Set-of-Mark labellisation automatique** des éléments cliquables + **Trace-of-Mark** pour la planification d'actions (videos). Premier modèle multi-domaine (GUI + robotique).
- **Tokenise nativement ?** Oui, SoM est dans la supervision de pré-entraînement, pas une étape inférence externe.

---

## 5. Comparaison latence / perf / robustesse

### 5.1. Tableau synthèse

| Approche | Latence / écran 2560×1600 | VRAM | Sortie | Licence | Tokenise nativement ? |
|---|---|---|---|---|---|
| **UI-DETR-1 record-only (actuel)** | n/a (recording offline) | n/a | événements VWB enrichis | propriétaire MS | non, étape séparée |
| **SomEngine actuel** (YOLO icon_detect + docTR) | ~150-300 ms estimé (docTR seul ~100 ms, YOLO ~15 ms, +overhead annotation) | ~1 GB | liste `SomElement` | AGPL-3.0 (YOLO) | non |
| **OmniParser V2 complet** (YOLO + Florence-2 caption) | **0.8 s** (RTX 4090) → ~1.0 s (RTX 5070 estimé) après resize 1920 | ~2 GB | liste `interactable_element` + caption sémantique | AGPL-3.0 + MIT | non |
| **YOLOv8-UI fine-tuned custom** (sans caption) | ~50-100 ms | ~200 MB | bbox seules | AGPL-3.0 par défaut, MIT possible si from scratch | non |
| **ShowUI-2B** | grounding direct, ~1-2 s estimé | ~2-4 GB | coord ou région | code MIT | **oui** (UI-guided token selection) |
| **GUI-Actor-7B** | grounding direct, ~2-3 s estimé | ~7-14 GB | régions multiples via attention | code MIT | **oui** (attention head dédiée) |
| **OS-Atlas-Base-7B** | grounding direct, ~2-3 s estimé | ~7-14 GB | bbox tokens spéciaux | code MIT (modèle Qwen2-VL Apache 2.0) | partiellement |
| **InfiGUI-G1-3B (actuel)** | déjà mesuré ~1-2 s | 3.9 GB | bbox | Apache 2.0 (Qwen) | partiellement |

### 5.2. Robustesse — ce que dit la littérature 2025

- **GUI-Robust** (arXiv 2506.14477) : tous les MLLM (y compris GUI-spécialisés) se dégradent significativement sur 7 types d'anomalies (popups, modifications de layout, désactivation). **OmniParser ne corrige PAS ces anomalies à lui seul** — il aide à voir les éléments, pas à comprendre les bugs UI.
- **Magma + SoM** (CVPR 2025) : SoM **en supervision** > SoM **en prompting inference-only**. Confirme que la prochaine génération est "SoM natif", pas "OmniParser externe".

### 5.3. Comparaison concrète avec notre cascade actuelle

Notre cascade `_resolve_target` (cf. `cartography_execution_flow.md`) :

```
OCR docTR (~200 ms) → template cv2 (~50 ms) → YOLO/SoM optionnel → VLM (1-15 s)
```

Avec SomEngine déjà existant et OmniParser V2 disponible localement (`/home/dom/ai/OmniParser/`), le coût marginal d'ajouter le caption Florence-2 = ~500-700 ms (Florence-2 base). Total cascade enrichie : **~2 s** vs actuel ~1-15 s suivant l'étage qui réussit. **Latence pas un blocker**.

---

## 6. Recommandation pour rpa_vision_v3 — 3 scénarios

### Scénario A — Intégrer OmniParser V2 complet dans la cascade replay

**Description** : activer `_resolve_set_of_marks` en replay, brancher icon_caption Florence-2 pour enrichir les éléments YOLO avec des descriptions sémantiques, exposer cette "vue parsée" à VWB UI et au VLM principal en prompt.

**Pour** :
- Asymétrie record/replay corrigée explicitement.
- Vue parsée disponible pour debug (UI VWB pourrait overlayer les éléments détectés sur captures Léa).
- Caption Florence-2 = donnée d'entrée pour un Validator sémantique post-clic (compare "j'attendais Notes médicales" vs "j'ai cliqué sur élément captioned 'Imagerie tab'").
- Coût latence ~1 s — compatible démo.

**Contre** :
- **Licence AGPL-3.0** sur icon_detect → audit légal avant déploiement commercial Anoust / GHT vente.
- N'efface AUCUN des 5 bugs P0 post-démo (transport HTTP, Stop VWB, mss monitors, échelle pixel, skip ord 13).
- Ajoute une dépendance lourde (`/home/dom/ai/OmniParser/`) au runtime.
- Le bug primaire diagnostiqué 8 mai est OCR-DIRECT center-of-line, pas un manque de candidats détectés.

**Effort** : 1-2 j (le code SomEngine existe, manque le câblage Florence-2 caption + UI debug).

**Risque** : moyen-faible. Tout est déjà en place côté code.

### Scénario B — Log implicite des candidats (no risk, à faire dès stabilisation post-démo)

**Description** : à chaque appel `_resolve_target`, logger systématiquement dans `logs/audit/` la liste des candidats produits par CHAQUE étage de la cascade (docTR lignes/spans, template matches > seuil, sorties YOLO si SomEngine actif, sorties VLM). JSON structuré, 1 ligne par résolution.

**Pour** :
- **Zéro nouveau modèle, zéro nouvelle dépendance**. Pure instrumentation.
- Vue parsée gratuite, exploitable hors-bande (analyse, dashboard).
- Comble l'asymétrie record/replay au sens "trace équivalente".
- Préalable indispensable à tout Validator sémantique futur.
- Aligné avec la suggestion §4.1 de `INSPIRATION_FRAMEWORKS_2026-05-10.md` ("logger systématiquement la liste des candidats détectés par chaque étage de la cascade").

**Contre** :
- N'apporte aucune nouvelle robustesse en propre — juste de l'observabilité.

**Effort** : 0.5 j.

**Risque** : très bas.

**→ À faire en priorité, indépendamment des autres scénarios.**

### Scénario C — Remplacer la cascade par un modèle VLM qui tokenise nativement

**Description** : remplacer `_resolve_target` par un appel direct à GUI-Actor-7B (ou ShowUI-2B en option légère) qui produit la zone-cible en coordinate-free. Peut coexister avec OCR docTR pour validation post-action.

**Pour** :
- **Tue le bug d'échelle bbox_2d** (DETTE-006/010/014) — plus de smart_resize à débugger.
- État de l'art ScreenSpot-Pro (44.6 % GUI-Actor > UI-TARS-72B).
- Architecture plus simple long-terme : 1 modèle = 1 grounder.
- ShowUI-2B = 2× moins gourmand que notre InfiGUI-G1-3B actuel.

**Contre** :
- **Décision structurelle**, pas réversible facilement. Réécrit la moitié de `resolve_engine.py`.
- Aucun bench interne pour valider sur nos écrans Easily / Citrix réels.
- Pas de caption sémantique = pas de Validator sémantique post-action.
- Effort production-grade : 1-2 semaines.

**Effort** : 5-10 j.

**Risque** : élevé tant que pas benché sur nos workflows.

---

## 7. Recommandation finale

**Maintenant (post-démo, semaine du 26 mai)** :
1. **Scénario B obligatoirement** — log des candidats. Coût minimal, valeur immense pour debug futur.
2. **Vérifier au runtime si `_resolve_set_of_marks` est appelé en replay**. Si non = code orphelin (CLAUDE.md §champs de mines). Si oui = on est déjà mi-Scénario A sans le savoir.
3. **Audit licence** AGPL-3.0 sur icon_detect avant tout pitch commercial.

**Sprint suivant (juin si bande passante)** :
4. **Scénario A partiel** — activer Florence-2 icon_caption sur l'événement de recording VWB ET sur les résolutions en échec replay (sentinelle, pas systématique). Caption disponible pour un Validator sémantique futur.
5. **Bench GUI-Actor-7B et ShowUI-2B** sur 10-20 captures Easily Assure réelles. Décision Scénario C **uniquement** sur preuves.

**À ne PAS faire** :
- Activer OmniParser V2 systématiquement en runtime tant que les 5 bugs P0 (`LESSONS_LEARNED_GHT_2026-05.md`) ne sont pas refermés. Latence supplémentaire sur démo fragile.
- Remplacer InfiGUI-G1-3B sans bench comparatif documenté.

---

## 8. Sources

### OmniParser V2
- [Microsoft Research — OmniParser V2: Turning Any LLM into a Computer Use Agent (2025-02-12)](https://www.microsoft.com/en-us/research/articles/omniparser-v2-turning-any-llm-into-a-computer-use-agent/)
- [GitHub microsoft/OmniParser](https://github.com/microsoft/OmniParser)
- [HF microsoft/OmniParser-v2.0](https://huggingface.co/microsoft/OmniParser-v2.0)
- [MarkTechPost — Microsoft AI Releases OmniParser V2 (2025-02-18)](https://www.marktechpost.com/2025/02/18/microsoft-ai-releases-omniparser-v2-an-ai-tool-that-turns-any-llm-into-a-computer-use-agent/)
- [LearnOpenCV — OmniParser Vision-Based GUI Agent](https://learnopencv.com/omniparser-vision-based-gui-agent/)
- [DeepWiki — OmniParser Icon Detection and Captioning Models](https://deepwiki.com/microsoft/OmniParser/2.2-ocr-and-image-processing)

### Set-of-Marks
- [Yang et al. arXiv 2310.11441 — Set-of-Mark Prompting (2023)](https://arxiv.org/abs/2310.11441)
- [GitHub microsoft/SoM](https://github.com/microsoft/SoM)

### Modèles GUI natifs 2025
- [arXiv 2410.23218 — OS-ATLAS Foundation Action Model (ICLR 2025)](https://arxiv.org/abs/2410.23218)
- [OS-Atlas Homepage](https://osatlas.github.io/)
- [GitHub showlab/ShowUI (CVPR 2025)](https://github.com/showlab/ShowUI)
- [arXiv 2411.17465 — ShowUI Vision-Language-Action GUI Visual Agent](https://arxiv.org/abs/2411.17465)
- [Aguvis Project — ICML 2025](https://aguvis-project.github.io/)
- [arXiv 2412.04454 — Aguvis Unified Pure Vision Agents](https://arxiv.org/abs/2412.04454)
- [GitHub microsoft/GUI-Actor (NeurIPS 2025)](https://github.com/microsoft/GUI-Actor)
- [arXiv 2506.03143 — GUI-Actor Coordinate-Free Grounding](https://arxiv.org/abs/2506.03143)
- [GitHub microsoft/Magma (CVPR 2025)](https://github.com/microsoft/Magma)
- [arXiv 2502.13130 — Magma Foundation Model](https://arxiv.org/abs/2502.13130)

### Florence-2 (sous-jacent OmniParser icon_caption)
- [HF microsoft/Florence-2-large](https://huggingface.co/microsoft/Florence-2-large)
- [Microsoft Research — Florence-2 Unified Representation](https://www.microsoft.com/en-us/research/publication/florence-2-advancing-a-unified-representation-for-a-variety-of-vision-tasks/)

### Robustesse GUI agents
- [arXiv 2506.14477 — GUI-Robust Dataset](https://arxiv.org/abs/2506.14477)

### Computer use / pure vision
- [Skyvern — Browser Automation with LLM and Computer Vision](https://github.com/Skyvern-AI/skyvern)
- [Claude Computer Use — Anthropic Docs](https://docs.claude.com/en/docs/agents-and-tools/tool-use/computer-use-tool)
- [Tech Insider — Claude Computer Use Citrix Legacy Apps 2026](https://tech-insider.org/anthropic-claude-computer-use-agent-2026/)

### Référence interne
- `core/detection/som_engine.py` (316 lignes) — SomEngine YOLO + docTR déjà câblé
- `core/detection/omniparser_adapter.py` — wrapper Florence-2 caption
- `agent_v0/server_v1/resolve_engine.py:1083-1325` — voie `_resolve_set_of_marks` au replay
- `agent_v0/server_v1/stream_processor.py:607-700` — SoM au recording
- `docs/INSPIRATION_FRAMEWORKS_2026-05-10.md` §4 — vague d'inspirations frameworks RPA visuels
- `docs/SYNTHESE_TECHNOS_REPLAY_2026-05-23.md` §5.3 — note sur l'asymétrie OmniParser ↔ cascade
- `docs/MIGRATION_VLM_PLAN_2026-05-09.md` §2 — bug d'échelle bbox_2d (lien Scénario C)
- `docs/LESSONS_LEARNED_GHT_2026-05.md` §🔴 — 5 bugs P0 qui restent prioritaires sur tout ajout d'étage