Le filtre len<3 bloquait les boutons "OK" (2 chars) et "No" (2 chars).
Seuil abaissé à 2 — filtre les lettres isolées mais laisse passer
les boutons courts courants des dialogues Windows.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
UIPatternLibrary câblée dans l'executor et le stream processor.
Pendant un wait_for_anchor, Léa surveille l'écran toutes les secondes :
1. OCR plein écran (docTR)
2. Pattern matching (dialogues Save, OK, Cancel, cookies...)
3. OCR ciblé pour trouver le bouton par son texte réel
4. Clic sur le match le plus bas (bouton, pas titre)
Fix : seuil ratio supprimé (trigger trouvé = match, quelle que soit
la longueur du texte OCR). Matching strict mot exact ≥3 chars
(évite les faux positifs sur lettres isolées). Fallback recherche
partielle pour les lettres soulignées (E_nregistrer).
Plus aucune coordonnée hardcodée — 100% vision.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
VWB Executor :
- _check_screen_for_patterns() : capture écran + OCR + pattern matching
- _handle_detected_pattern() : clic automatique sur dialogues connus
- Vérifie entre chaque étape en mode intelligent/debug
- Si un dialogue bloque (OK, Save, Cancel), Léa le gère seule
Stream Processor :
- Enrichit les ScreenState avec ui_pattern/ui_pattern_action/ui_pattern_target
- Les patterns détectés sont loggés et stockés dans les résultats
- Permet au GraphBuilder de savoir quels écrans sont des dialogues
Phase 2 du plan "connaissance native de l'environnement".
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
CSS : le dropdown héritait color:white du header → forcé #212121
sur .workflow-dropdown et .dropdown-item .item-name
Bibliothèque : migration localStorage → backend (capture_library.json)
- GET/POST /api/v3/capture/library (max 50 captures)
- loadLibraryAsync() charge depuis backend, fallback localStorage
- saveLibrary() écrit dans les deux (localStorage + backend)
- capture_library.json gitignored
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Le refresh du layout X11 juste avant xdotool type force le bon keymap.
Sans ça, xdotool envoie des keycodes décalés (: → M, / → !, etc.)
dans les VM spice/QEMU.
Solution trouvée via askubuntu.com/questions/914718.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remet xclip+Ctrl+V comme méthode prioritaire. Les spice tools sont
installés dans la VM → le presse-papier est partagé → pas de problème
de mapping clavier. xdotool envoie des événements synthétiques X11
que spice/QEMU traite différemment des vraies frappes (: → M).
Citrix partage aussi le clipboard nativement → même méthode en prod.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
xdotool type pour les segments alphanumériques (un seul appel, rapide),
xdotool key avec keysym uniquement pour les caractères spéciaux
(:, /, @, etc.) qui cassent en AZERTY dans les VM.
Évite le subprocess par caractère (trop lent, effet visuel désagréable).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
xdotool type envoie des scancodes QWERTY — dans une VM AZERTY,
':' devient 'M', '/' devient '!', etc.
Nouvelle approche : xdotool key avec les noms de keysym X11
(colon, slash, period, etc.) qui sont indépendants du layout.
Chaque caractère est envoyé individuellement — plus lent mais
100% fiable en AZERTY/QWERTY, local ou VM.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
safe_type_text() : xdotool type en priorité au lieu du presse-papier.
Le clipboard xclip ne traverse pas les VM (QEMU) ni Citrix/RDP.
xdotool envoie des frappes X11 réelles que les VM capturent.
Délai 20ms entre caractères pour fiabilité.
Cosmétique : couleur texte forcée sur les items workflow du sidebar
(color: var(--text-primary)) — était blanc sur blanc.
Logs diagnostic ajoutés dans execute_workflow_thread et execute_action.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Avant : tous les workflows importés s'appelaient « Unnamed Workflow »
→ la liste devenait illisible dès qu'il y en avait plusieurs.
Après : génération d'un nom explicite par _derive_default_name :
1. Premier `template.window.title_pattern` utile dans les nodes
(filtrage de "Unknown" / "unknown_window"), avec extraction de
l'app derrière le séparateur Windows « – » / « - »
(ex: « Sans titre – Bloc-notes » → « Bloc-notes »).
2. Premier `template.window.process_name` non-null
(ex: « explorer.exe »).
3. Fallback : 8 premiers caractères du workflow_id, après
nettoyage des préfixes techniques ("workflow_sess_", ...).
Le nom final inclut toujours la date de l'import :
« Léa Bloc-notes — 2026-04-16 08:41 »
« Léa explorer.exe — 2026-04-16 08:41 »
« Léa 20260404 — 2026-04-16 08:41 » (fallback)
Ne se déclenche que si le nom entrant est vide,
« Unnamed Workflow » ou « Workflow importé » (insensible à la
casse). Le paramètre `name` explicite de la requête reste
prioritaire. L'utilisateur peut renommer via le bouton éditer.
Pas de modification du schema workflow (champ `name` existant).
Tests manuels sur données réelles :
- notepad_enriched.json (tous nodes "Unknown") → fallback id OK
- Bloc-notes, Explorateur et Recherche (2) → « Léa Rechercher »
- workflow construit avec title 'Sans titre – Bloc-notes'
→ « Léa Bloc-notes » OK
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Token obligatoire (RPA_API_TOKEN) sur /capture et /file-action
- Bind 127.0.0.1 par défaut, 0.0.0.0 exige token (fail-closed)
- /health reste public pour monitoring
- VWB backend injecte le Bearer pour les proxys distants
- hmac.compare_digest pour comparaison temps constant
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Workflows appris par Léa visibles dans le VWB ("Appris par Léa")
- Bouton "Importer" pour éditer un workflow appris
- Bouton "Exporter pour Léa" pour rendre un workflow VWB exécutable
- Conversion bidirectionnelle core ↔ VWB via learned_workflow_bridge
- Liste unifiée dans le chat Léa (merged + dédupliquée)
- reload_workflows() sur le streaming server (pas de redémarrage)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Floutage (conformité AI Act) :
- Détection OpenCV des champs de saisie (rectangles clairs avec texte)
- Flou gaussien avant stockage/envoi
- Activé par défaut (RPA_BLUR_SENSITIVE=true)
- <200ms par screenshot, 12 tests
Fix actions fichiers VWB :
- Pas de wait 5s pour les actions fichiers (inutile)
- Routing direct vers agent port 5006
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- 5 actions : lister, créer dossier, déplacer, copier, classer par extension
- Exécution sur Windows via agent port 5006
- Sécurité chemins (bloque C:\Windows, /etc, etc.)
- Propriétés panel + preview canvas pour chaque action
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Le proxy injecte x_pct/y_pct depuis le centre du bbox de l'ancre
- Si le visual resolve timeout → clic aux coordonnées bbox (pas à 0,0)
- Lookup replay_states par machine_id (premier replay fonctionne)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- /replay/next cherche dans replay_states par machine_id (pas seulement machine_replay_target)
- execute-windows auto-détecte la machine Windows connectée
- resolve_target utilise ThreadPool par défaut (pas le GPU executor saturé)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Capture auto : détecte OS navigateur → capture Windows ou Linux
- Timer capture utilise aussi la smart capture
- Heartbeat background permanent (même sans session)
- Tri screenshots par date (plus de vieilles captures)
- Chat Léa : 450x650, polices 11pt, redimensionnable, meilleur contraste
- Bouton Exécuter : "Linux" + "Windows" avec feedback visuel
- Délai 5s avant replay Windows (temps de réduire le navigateur)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Bouton "Windows" dans VWB pour exécuter sur le PC distant
- Template matching OpenCV multi-scale pour localiser les ancres visuelles
- Proxy VWB→streaming server avec chargement ancre (thumb, pas full)
- Fix executor Windows : mss lazy, result reporting, debug prints
- Fix poll replay permanent (sans session active)
- Mapping types VWB→executor (click_anchor→click, type_text→type)
- CORS streaming server, capture Windows dans VWB
- Dédup heartbeats côté client (hash perceptuel)
- Mode cloud VLM configurable via RPA_VLM_MODEL
- Fix resolve_target : pas de ScreenAnalyzer fallback (trop lent)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Bouton "Parcourir..." ouvre l'explorateur natif du navigateur
- Upload vers /api/v3/upload-excel, sauvegarde dans data/uploads/
- Nom de table auto-suggéré depuis le nom du fichier
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- ExcelImporter : import .xlsx → SQLite auto (détection types, batch insert)
- DBIterator : lecture ligne par ligne avec filtre/tri/limite
- VWB actions : "Importer Excel" + "Pour chaque ligne" dans la palette
- DAG executor : pré-exécution import, boucle foreach avec injection
${current_row.colonne} dans les étapes dépendantes
- 36 tests unitaires Excel/DB (tous passent)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Refonte majeure du système Agent Chat et ajout de nombreux modules :
- Chat unifié : suppression du dual Workflows/Agent Libre, tout passe par /api/chat
avec résolution en 3 niveaux (workflow → geste → "montre-moi")
- GestureCatalog : 38 raccourcis clavier universels Windows avec matching sémantique,
substitution automatique dans les replays, et endpoint /api/gestures
- Mode Copilot : exécution pas-à-pas des workflows avec validation humaine via WebSocket
(approve/skip/abort) avant chaque action
- Léa UI (agent_v0/lea_ui/) : interface PyQt5 pour Windows avec overlay transparent
pour feedback visuel pendant le replay
- Data Extraction (core/extraction/) : moteur d'extraction visuelle de données
(OCR + VLM → SQLite), avec schémas YAML et export CSV/Excel
- ReplayVerifier (agent_v0/server_v1/) : vérification post-action par comparaison
de screenshots, avec logique de retry (max 3)
- IntentParser durci : meilleur fallback regex, type GREETING, patterns améliorés
- Dashboard : nouvelles pages gestures, streaming, extractions
- Tests : 63 tests GestureCatalog, 47 tests extraction, corrections tests existants
- Dépréciation : /api/agent/plan et /api/agent/execute retournent HTTP 410,
suppression du code hardcodé _plan_to_replay_actions
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Backend:
- analyser_avec_ia.py: centraliser URL Ollama via os.environ.get()
- action_contracts.py: assouplir le contrat ai_analyze_text (mode texte
sans ancre visuelle, accepter prompt ou analysis_prompt)
- intelligent_executor.py: supprimer le fallback coordonnées statiques
quand la vision échoue — renvoyer not_found pour self-healing
- workflow.py: ajouter endpoints validate et export-training
run.sh:
- Corriger les ports (3000 → 3002) et le venv (venv_v3 → .venv)
- Lancer run_v4.sh au lieu de l'ancien run.sh
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Phase 1 — Code mort et duplication :
- Supprimer catalog_routes.py (-1832 lignes, doublon de v2_vlm)
- Mettre à jour app.py et app_lightweight.py vers catalog_routes_v2_vlm
- Nettoyer 9 imports inutilisés dans catalog_routes_v2_vlm.py
- Supprimer get_required_params inutilisé dans execute.py
Phase 2 — Centraliser la configuration :
- Ollama URL via os.environ.get() dans verify_text_content.py et extraire_tableau.py
- MODEL_PATH relatif au projet + var env UI_DETR_MODEL_PATH dans ui_detection_service.py
Phase 3 — Thread-safety de l'exécution :
- Ajouter _execution_lock (RLock) pour protéger _execution_state
- Remplacer le polling self-healing par threading.Event
- Initialiser 'variables' dans le dict initial (plus de création dynamique)
- Corriger bare except → except Exception as db_err avec message
Phase 4 — Logging minimal :
- Ajouter logger dans execute.py, remplacer print() critiques par logger
- Configurer RotatingFileHandler (5MB, 3 backups) dans app.py
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
## Nouvelles fonctionnalités
### 1. SeeClick Adapter (visual grounding fallback)
- Nouvel adapter pour le modèle SeeClick (HuggingFace)
- Intégré dans la chaîne de fallback: CLIP → Template → SeeClick → Static
- Localise les éléments GUI à partir de descriptions textuelles
### 2. Self-Healing Interactif
- Dialogue qui propose des alternatives quand l'ancre n'est pas trouvée
- L'utilisateur peut choisir: candidat alternatif, coords statiques, ou sauter
- Nouveaux endpoints: /healing/status, /healing/choose, /healing/candidates
- État "waiting_for_choice" pour mettre l'exécution en pause
### 3. Dashboard Confiance (temps réel)
- Affiche les scores de confiance pendant l'exécution
- Montre: méthode utilisée, distance, taux de succès
- Interface pliable en bas à droite
- Visible uniquement en mode intelligent/debug
## Fichiers ajoutés
- core/detection/seeclick_adapter.py
- frontend_v4/src/components/SelfHealingDialog.tsx
- frontend_v4/src/components/ConfidenceDashboard.tsx
## Fichiers modifiés
- core/detection/__init__.py
- backend/services/intelligent_executor.py
- backend/api_v3/execute.py
- frontend_v4/src/App.tsx
- frontend_v4/src/services/api.ts
- docs/VISION_RPA_INTELLIGENT.md
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
API = Source de vérité unique (SQLite + Flask)
- Backend: API v3 avec session, workflow, capture, execute
- Frontend: Vanilla TypeScript, pas de state local
- Contrats stricts pour les actions RPA
- Drag & drop pour réorganiser les étapes
- Insertion d'étapes entre deux existantes
- Bibliothèque de captures (sessionStorage)
- Exécution avec coordonnées statiques (pyautogui)
Fonctionne mais fragile (coordonnées fixes, pas de détection visuelle)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
