- Lea.bat ne tue plus TOUS les pythonw.exe du poste (Jupyter, Spyder)
Kill ciblé uniquement sur le PID lu dans lea_agent.lock
- LeaServerClient utilise RPA_SERVER_URL (HTTPS prod) au lieu de
hardcode http://:5005
- Normalisation du slash final de l'URL
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>
- Nouveau module persistent_buffer.py (SQLite WAL, thread-safe)
- Purge automatique des captures locales après ACK 200 serveur
- Drain loop 15s, retry exponentiel, plafonds tentatives
- Enum ImageSendResult.{OK, FAILED, FILE_GONE} pour distinguer les cas
- FileNotFoundError n'est plus un faux succès (P0-E audit)
- 14 tests intégration
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
"Fichier" dans "*,Ceci est un test – Bloc-notes" était rejeté
parce que le titre attendu était "test.txt – Bloc-notes".
Maintenant la comparaison extrait le nom d'app (Bloc-notes)
et accepte le match si c'est la même application.
Résout : "Ajouter un nouvel onglet" bloqué quand un fichier
différent est ouvert dans Bloc-notes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Le session_cleaner détecte les dialogues système (Enregistrer sous,
Ouvrir, Confirmer, etc.) et marque les actions correspondantes comme
conditionnelles. Au replay, si le dialogue n'apparaît pas (ex: Ctrl+S
sauve silencieusement car le fichier existe), les actions du dialogue
sont skippées automatiquement.
Détection basée sur des patterns de noms de dialogues Windows FR/EN.
Testé : seul le clic dans "Enregistrer sous" est conditionnel,
les actions Bloc-notes/Rechercher/systray restent normales.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Quand la fenêtre attendue ne correspond pas (ex: Ctrl+S a sauvé sans
dialogue "Enregistrer sous"), Léa passe en mode capture au lieu de
retourner paused_need_help. Si l'humain ne fait rien pendant 10s,
l'action est skippée (l'état est considéré déjà atteint).
4 déclencheurs apprentissage maintenant couverts :
- retry_failed : grounding + retry échouent
- no_screen_change : clic sans effet visible
- wrong_window : fenêtre attendue absente
- SUPERVISE direct : Policy décide de demander
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Premier replay fonctionnel de bout en bout (Bloc-notes, Chrome).
Corrections critiques :
- Fix double-lancement agent (Lea.bat start /b + verrou PID)
- Sérialisation replay (threading.Lock dans poll_and_execute)
- Garde UIA bbox >50% écran (rejet conteneurs "Bureau")
- Filtre fenêtres bruit système (systray overflow)
- Auto-nettoyage replays bloqués (paused_need_help)
Cascade visuelle complète dans session_cleaner :
- UIA local (10ms) → template matching (100ms) → serveur docTR/VLM
- Nettoyage bureau pré-replay (clic "Afficher le bureau")
- Crops 80x80 + vlm_description pour chaque clic
Grounding contraint à la fenêtre active :
- Capture croppée à la fenêtre au lieu de l'écran entier
- Conversion coordonnées fenêtre → écran
- Élimine les faux positifs taskbar/systray
Mode apprentissage supervisé (SUPERVISE → capture humaine) :
- Léa passe en mode capture quand elle est perdue
- Capture mini-workflow humain (clics + frappes + combos)
- Fin par Ctrl+Shift+L ou timeout inactivité 10s
- Correction stockée dans target_memory.db via serveur
Deploy Windows complet (grounding.py, policy.py, uia_helper.py).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
build_replay_from_raw_events transforme les events (réordonne, injecte
du setup "ouvrir l'app", fusionne les actions, ajoute des waits) ce qui
décale les clics par rapport à l'enregistrement original. Le texte était
saisi dans le mauvais champ parce que les actions n'étaient plus en 1:1
avec la session.
Le fallback _simple_build_replay reproduit les events tels quels en
coords brutes — exactement ce qu'on veut pour "nettoyer et rejouer".
Le session_cleaner l'utilise maintenant exclusivement.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contournement temporaire du crash agent "cannot unpack non-iterable
NoneType object" qui se produit quand l'agent Windows tente une
résolution visuelle (visual_mode=True) sur les actions replay.
Les actions construites par build_replay_from_raw_events gardent
leurs coordonnées enrichies (x_pct, y_pct calculés depuis la
session) mais sont envoyées avec visual_mode=False pour que l'agent
clique aux coords brutes sans passer par le grounding.
C'est un compromis temporaire : moins intelligent (pas de résolution
adaptative) mais fonctionnel (les clics arrivent aux bonnes coords).
Le mode visuel sera réactivé quand le bug agent sera diagnostiqué
et corrigé (le traceback n'est pas visible côté serveur, le
redéploiement de l'agent avec debug n'a pas pris effet).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Deux bugs dans _simple_build_replay :
1. Mauvais noms de champs : x_percent/y_percent au lieu de x_pct/y_pct
attendus par l'agent executor. Et valeurs en 0-100 au lieu de 0-1.
Résultat : l'agent recevait x_pct=None → crash "cannot unpack
non-iterable NoneType object".
2. Pas de visual_mode=False explicite. Sans enrichissement
(target_spec vide, pas d'anchor), l'agent tentait une résolution
visuelle sur du vide → crash.
Aussi : la condition de fallback empêchait le déclenchement quand
build_replay_from_raw_events crashait (error_message non vide bloquait
la branche). Corrigé : le fallback se déclenche sur `not replay_actions`
(couvre None, liste vide, et crash du build principal).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Petit serveur Flask standalone (tools/session_cleaner.py) qui permet de :
- Lister les sessions enregistrees recentes
- Visualiser chaque session avec ses screenshots (crop + full)
- Marquer les clics parasites a supprimer (auto-detection des toasts,
clics droit, fenetres Lea/systray, derniers 3 evenements)
- Re-construire un replay nettoye et l'injecter dans la queue via
POST /api/v1/traces/stream/replay/raw
Option A du rapport audit VWB : "Le besoin reel est supprimer 3 clics
parasites et relancer — c'est 30 secondes d'UX, pas un Visual Workflow
Builder."
Port : 5006
Dependencies : Flask (deja dans le venv), aucune nouvelle
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Supprime ~8.2 Go de fichiers parasites qui polluent les grep, consomment
des tokens, et ajoutent du bruit au repo :
- _a_trier/ (561 Mo) — scripts legacy, backups, sessions logs, démos
- archives/ (21 Mo) — copie figée code décembre 2024 (déjà dans git history)
- visual_workflow_builder/_a_trier/ (7.6 Go) — backups VWB legacy + anciens frontends
- web_dashboard/app.py.bak_20260304_2225 — fichier .bak oublié
- agent_v1/ (top-level) — scaffold vide jamais alimenté
- core/detection/ui_detector_old.py.bak — .bak traqué par erreur
Retire aussi du tracking git :
- 2 fichiers __pycache__ traqués par erreur dans VWB backend
Met à jour .gitignore pour prévenir la récurrence :
- *.bak, *.bak_*, *.orig, *.old
- _a_trier/, archives/
Tout ce contenu reste récupérable via git history (tag pre-cleanup-phase1-20260410).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Symétrie avec le fix 7cc03f6f1 (no_screen_change strict → paused_need_help).
Avant : si l'agent détecte en pré-vérification que la fenêtre active
n'est pas celle attendue, l'erreur retombait dans la branche retry+stop
legacy → 3 retries inutiles puis status=error et queue vidée.
C'est une violation de feedback_failure_is_learning.md : un échec Léa
n'est jamais un "stop avec error", c'est un moment pédagogique.
Maintenant :
1. L'agent envoie warning="wrong_window" dans le résultat (en plus
de l'error textuel existant). Ajouté aux 2 chemins :
- pré-vérif (expected_window_before mismatch, executor.py ~587)
- post-vérif strict (expected_window_title timeout, executor.py ~820)
2. Le serveur détecte warning="wrong_window" AVANT la branche
retry+stop legacy → redirection vers paused_need_help
3. pause_message explicite : "Je m'attendais à voir la bonne fenêtre
mais je vois autre chose. Peux-tu vérifier que l'application est
au premier plan ?"
4. Queue intacte (l'action reste en tête, prête à être relancée)
5. log_replay_failure pour l'apprentissage futur
Cause fréquente identifiée : les popups de Léa elle-même (notifications,
fenêtre de chat) volent le focus Windows pendant le replay → l'app cible
perd le premier plan → pré-vérif détecte le mismatch. Bug UX séparé à
traiter (Léa ne devrait pas prendre le focus pendant un replay actif).
Appliqué aux 2 copies de l'agent (dev + deploy).
Tests : 56 E2E + Phase0 passent, 0 régression.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ce fichier existe sur disque depuis le 4 avril mais n'a jamais été ajouté
à git. Il est importé par api_stream.py (ligne 29) — un fresh clone sans
ce fichier ne peut pas démarrer le serveur streaming.
Découvert par le project-quality-guardian lors de l'audit global du
11 avril (item C1, priorité P0 bloquant absolu).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rectification de la branche C introduite dans a21f1ea9f.
## Ce qui était faux
a21f1ea9f faisait :
strict + no_screen_change → retry × 3 → status=error → queue vidée
C'est le réflexe d'un RPA classique qui se casse la figure quand ça
rate. Ce n'est PAS la philosophie Léa.
Dom m'a rappelé que j'avais oublié ma propre vision documentée dans
project_lea_apprentissage_plan.md et feedback_not_a_click_box.md :
*"Quand elle dit qu'elle n'a pas trouvé X, elle demande montre-moi.
C'est à ce moment qu'il faudrait passer en mode apprentissage."*
## Ce qui est correct maintenant
strict + no_screen_change
→ status = "paused_need_help"
→ failed_action stocké (target, screenshot, method, score, reason)
→ pause_message demandant l'intervention humaine
→ queue intacte (l'action reste en tête, prête à être relancée)
→ log_replay_failure pour l'apprentissage futur
→ l'agent reçoit replay_paused=True dans /replay/next et s'arrête
→ l'humain corrige physiquement sur la machine cible
→ le replay reprend via /replay/{replay_id}/resume
Redirection vers le mécanisme paused_need_help qui existe déjà pour le
cas target_not_found. Zéro nouveau code de pause, juste une 2ème entrée
dans ce mécanisme.
Le comportement legacy (success_strict=False) reste inchangé : on
log un warning et on continue, comportement tolérant pour les actions
non-critiques.
## Lesson apprises
1. Toujours relire les fichiers mémoire pertinents AVANT d'implémenter
une branche de gestion d'erreur (nouvelle règle dans
feedback_reread_before_code.md)
2. Un échec Léa n'est jamais un "stop avec error" — c'est un moment
pédagogique (nouvelle règle dans feedback_failure_is_learning.md)
3. Ne pas s'auto-presser quand Dom n'a jamais demandé d'aller vite
## Tests
- 56 tests E2E + Phase0 passent, 0 régression
- Comportement vérifié par inspection du code : pause_message formé
correctement, queue préservée, log_replay_failure appelé
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Deux garde-fous qui ferment des trous identifiés lors du test de replay
chirurgical du 11 avril 2026 sur sess_20260411T084629_2d588e.
## B — Garde qualité en sortie de cascade (_validate_resolution_quality)
Couche de validation ajoutée en sortie du handler /resolve_target, après
que la cascade (_resolve_target_sync) a produit son meilleur candidat.
Single point of insertion, n'altère pas la cascade existante.
Deux checks :
1. Seuil de score minimum par méthode (_RESOLUTION_MIN_SCORES)
- hybrid_text_direct ≥ 0.80
- som_anchor_match / som_text_match ≥ 0.75
- template_matching ≥ 0.85
- vlm_* / grounding ≥ 0.60
- memory_* : pas de seuil (confiance cristallisée)
- v4_uia_local / uia ≥ 0.90
2. Garde de proximité contre coords enregistrées
Si fallback_x/y_pct sont significatifs (pas placeholder 0.5/0.5 ni
0.0/0.0), rejette si drift > 20% de l'écran dans un axe.
Reproduit un faux positif vu en production : SoM a trouvé
"Enregistrer" à (0.505, 0.770) alors que l'enregistrement était à
(0.093, 0.356) — écart de 0.41.
Quand un check rejette : retourne resolved=False avec method=
"rejected_low_score_*" ou "rejected_drift_*" et reason détaillée.
L'action passe alors par le chemin "visual_resolve_failed" côté agent
→ Policy → pause supervisée ou retry selon contexte.
7 tests unitaires inline validés (score bas, drift, mémoire qui passe
toujours, placeholders V4 qui skip la garde drift, etc.).
## C — no_screen_change devient un échec strict en mode strict
Avant : si un clic retourne warning='no_screen_change' (écran inchangé
après action), le replay loggait un warning et CONTINUAIT à l'action
suivante. Trop indulgent pour les workflows critiques.
Maintenant : la branche no_screen_change consulte le flag
success_strict de l'action courante.
- success_strict=True : traité comme vrai échec
→ retry si retry_count < MAX_RETRIES_PER_ACTION
→ stop définitif sinon (status=error, queue vidée, callback)
- success_strict=False (legacy) : comportement inchangé, on continue
Prérequis : _create_replay_state copie maintenant success_strict,
expected_window_before, expected_window_title, intention dans la
version slim de actions stockée dans replay_state. Nécessaire pour
lire le flag depuis current_action_index dans /replay/result.
## Tests
- 7 tests unitaires inline sur _validate_resolution_quality
- 56 tests E2E + Phase0 passent, zéro régression
- Instrumentation [REPLAY] reste pleinement fonctionnelle
## Limites non traitées ici (explicites)
- La latence de 14s entre deux clics (pre-analyze + cascade + agent
polling) reste inchangée. Les menus déroulants Windows peuvent encore
se refermer avant le 2ème clic. Piste A du plan, à traiter séparément.
- L'intégration d'OS-Atlas-Base-7B comme grounder spécialisé reste
dans les cartons (recommandation du rapport état de l'art).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ajoute creationflags=CREATE_NO_WINDOW (0x08000000) au subprocess.run()
qui appelle lea_uia.exe dans UIAHelper._run(). Sans ce flag, Windows
ouvre brièvement une fenêtre cmd noire à CHAQUE appel — et le captor
appelle UIA à chaque clic utilisateur pendant l'enregistrement.
Symptômes rapportés par Dom :
- Flash de fenêtre terminal à chaque clic (visible à l'œil)
- Ralentissement de la souris pendant les enregistrements
- Pollution des données d'apprentissage : le VLM de post-analyse
"voit" la fenêtre cmd et l'enregistre comme élément cliqué
(log serveur : "gemma4 a lu l'élément : 'C:\\Lea\\helpers\\lea_uia.exe'")
Implémentation portable :
- Flag calculé au niveau module : 0x08000000 sur Windows, 0 sur Linux/Mac
- getattr(subprocess, "CREATE_NO_WINDOW", ...) pour gérer l'absence de
la constante sur Linux
- creationflags=0 est un no-op sur Linux, safe
Appliqué aux 2 copies synchronisées :
- agent_v0/agent_v1/core/uia_helper.py (source active pour l'agent)
- core/workflow/uia_helper.py (copie identique)
85 tests in silico OK (29 UIA + 56 E2E/Phase0). Le vrai test c'est
Dom qui refait un enregistrement et vérifie qu'il n'y a plus de
flash de terminal.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ajoute 6 points de log structurés homogénéisés avec le préfixe [REPLAY]
aux endroits clés de la chaîne de replay, pour permettre de suivre
précisément ce qui se passe pendant un test humain et diagnostiquer
les points de rupture sans déduire à l'aveugle.
Points de log :
1. DISPATCH — /replay/next envoie une action (expected_before/after,
resolve_order, has_uia, has_anchor, by_text, strict)
2. RESOLVE_ENTRY — _resolve_target_sync reçoit la demande (window_title,
uia_target, anchor, strict_mode)
3. RESOLVE_EXIT — résolution terminée (method, coords, score, from_memory)
4. RESOLVE_EXCEPTION — crash rare dans la résolution
5. REPORT — /replay/result reçoit le rapport agent (success, error,
warning, resolution_method, actual_position)
6. VERIFY — décision finale post-vérification (agent_success,
ver_verified, sem_verified, final_success)
Usage : journalctl --user -u rpa-streaming -f | grep REPLAY
Aucune modif de logique, uniquement des logger.info() aux points de
décision critiques. 56 tests E2E + Phase0 restent verts.
Ces logs sont là pour stabiliser la chaîne après les modifications
robustesse du matin (strict control, UIA strict, filtre UIA-aware)
qui ont cassé les replays réels de Dom et ne se voient pas dans les
tests automatisés in silico.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Greffe minimale du mécanisme d'apprentissage persistant (Fiche #18,
target_memory_store.py) sur le pipeline streaming V4 sans toucher à V3.
Architecture (docs/PLAN_APPRENTISSAGE_LEA.md) :
- Lookup mémoire AVANT la cascade résolution coûteuse OCR/template/VLM
dans _resolve_target_sync → hit = <10ms, miss = overhead zéro
- Record APRÈS validation post-condition (title_match strict)
dans /replay/result → 2 succès → cristallisation par répétition
- Single source of truth : l'agent remplit report.actual_position avec
les coords effectivement cliquées, le serveur les lit directement.
Pas de cache intermédiaire (option C du plan).
Signature écran V4 : sha256(normalize(window_title))[:16]. Robuste aux
données variables, faux positifs rattrapés par le post-cond qui
décrémente la fiabilité via record_failure().
Fichiers :
- agent_v0/server_v1/replay_memory.py : nouveau wrapper 316 lignes
exposant compute_screen_sig/memory_lookup/record_success/failure,
lazy-init du store, normalisation texte stable, garde sanity coords
- agent_v0/server_v1/resolve_engine.py : lookup mémoire en tête de
_resolve_target_sync (30 lignes)
- agent_v0/server_v1/replay_engine.py : _create_replay_state stocke
une copie slim des actions (sans anchor base64) pour retrouver le
target_spec par current_action_index
- agent_v0/server_v1/api_stream.py : 4 callers passent actions=...,
record success/failure dans /replay/result lit actual_position
du rapport (click-only), correction du commentaire Pydantic
- agent_v0/agent_v1/core/executor.py : remplit result["actual_position"]
après self._click(), transmis dans le report de poll_and_execute
Tests : 56 E2E + Phase0 passent, zéro régression. Cycle Phase 1 validé
en simulation : miss → record → miss → record → HIT au 3ème passage.
Le deploy copy executor.py a une divergence pré-existante de 1302
lignes non committées — traité séparément lors du cleanup prochain.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Filtre d'événements parasites basé sur la CIBLE UIA :
- Un clic n'est filtré que si son uia_snapshot indique que l'élément
cliqué (ou un parent) est dans la fenêtre de Léa.
- Avant : on filtrait sur window.title qui pouvait être "Lea" même
quand le clic visait la taskbar (Léa au premier plan).
- Après : on regarde où va VRAIMENT le clic via parent_path UIA.
Extraction du expected_window depuis le parent_path UIA :
- Priorité au nom de la fenêtre racine du parent_path (plus fiable).
- Fallback sur window.title si pas de snapshot UIA ou pas de racine.
- Les fenêtres Léa sont neutralisées (effective_title="").
Pré-vérif avec polling tolérant (executor.py) :
- 5 tentatives avec 300ms entre chaque (total 1.5s max).
- Ignore les transitions "unknown_window" et fenêtre Léa.
- Évite les faux négatifs sur fenêtres en cours de changement.
Note : le filtrage reste basé sur des heuristiques. Un tri intelligent
par gemma4 au build reste à implémenter pour gérer les workflows
enregistrés avec des actions parasites (mail, chat, etc.).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Corrections critiques après test E2E qui montrait des clics au mauvais endroit :
1. Routage par machine_id (api_stream.py)
Quand 2 machines partagent le même session_id (agent_demo_user),
les actions d'un replay pour la VM ne doivent PLUS être distribuées
au PC physique. Vérification que le replay_state appartient bien à
la machine qui poll avant de consommer la queue.
2. IRBuilder extrait expected_window_before/after (ir_builder.py)
Pour chaque action click/type/key_combo, stocke le titre de la fenêtre
au moment du clic (before) et le titre du prochain événement (after).
Ces champs alimentent le contrôle strict au runtime.
3. ExecutionCompiler crée SuccessCondition title_match (execution_compiler.py)
Quand expected_window_after est défini, crée une condition de succès
STRICTE avec method="title_match" et expected_title. Plus de simple
"l'écran a changé" — on vérifie la fenêtre résultante.
4. Runner propage expected_window_before et success_strict
Le flag success_strict indique à l'agent que le contrôle post-action
DOIT être strict (STOP sur mismatch au lieu de warning).
5. UIA strict sur parent_path (executor.py)
_resolve_via_uia_local REJETTE un match si l'élément trouvé n'est pas
dans la bonne fenêtre parente (évite ex: "Rechercher" taskbar confondu
avec "Rechercher" explorateur).
6. Pré/post vérif stricte et bloquante (executor.py)
- expected_window_before lu en priorité depuis l'action (plan V4)
- Post-vérif : si success_strict=True et timeout, result.success=False
→ le replay s'arrête au lieu de continuer avec des warnings.
Validé sur la VM :
- Le replay s'arrête proprement quand l'étape 2 aboutit dans "Propriétés de
Internet" au lieu de "blocnote.txt - Bloc-notes"
- Plus de clics en aveugle / saisie au mauvais endroit
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Câblage agent Windows pour le pipeline V4 :
captor.py — capture UIA pendant l'enregistrement
- _inject_uia_snapshot() appelé après chaque clic
- Ajoute evt['uia_snapshot'] = {name, control_type, parent_path, ...}
- Non-bloquant : fallback silencieux si helper absent
- ~10-20ms par clic, pas de ralentissement perceptible
executor.py — résolution UIA locale au replay
- _resolve_via_uia_local() : appelle lea_uia.exe find via UIAHelper
- Court-circuit prioritaire avant le GroundingEngine serveur
- Activé quand resolve_order[0] == "uia" et target_spec.uia_target présent
- Coordonnées pixel-perfect (bounding_rect → center)
- Fallback transparent vers le grounding serveur si UIA échoue
uia_helper.py copié dans agent_v1/core/ (wrapper Python pour lea_uia.exe)
Auto-détection du binaire dans C:\Lea\helpers\lea_uia.exe
Singleton partagé get_shared_helper()
Déployé et validé sur la VM Windows :
- query_at(100,100) → "Bureau 1" en 10ms depuis Python
- Binaire lea_uia.exe trouvé et fonctionnel
- Les 3 modules Python sont dans C:\Lea\agent_v1\core\
Ce qui est maintenant possible (après redémarrage de Léa sur la VM) :
- Enregistrer un workflow : chaque clic aura un uia_snapshot
- Compiler via /workflow/compile : plan V4 avec stratégie UIA primaire
- Rejouer via /replay/plan : l'agent utilise UIA (10-20ms) au lieu de VLM (2-5s)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Pipeline V4 câblé de bout en bout :
RawTrace (avec uia_snapshot) → IRBuilder → Action._enrichment
WorkflowIR → ExecutionCompiler (avec SurfaceProfile) → ExecutionPlan
ExecutionPlan → runner → target_spec (avec uia_target + resolve_order)
ResolutionStrategy étendu :
- Champs UIA : uia_name, uia_control_type, uia_automation_id, uia_parent_path
- Champs DOM : dom_selector, dom_xpath, dom_url_pattern (préparation web)
ExecutionCompiler.compile(surface_profile=...) :
- Timeouts/retries tirés du profil (citrix=15s/3x, web=5s/1x, natif=8s/2x)
- UIA primaire seulement si surface=WINDOWS_NATIVE et uia_available
- Citrix ignore UIA même si snapshot présent (UIA ne marche pas dans Citrix)
IRBuilder lit evt['uia_snapshot'] et le stocke dans action._enrichment
(à remplir par l'agent Windows pendant l'enregistrement via lea_uia.exe)
execution_plan_runner propage uia_target et dom_target dans target_spec
pour que l'agent Windows puisse les consommer au runtime.
11 tests de câblage E2E :
- Profils (Citrix/web/natif) imposent bien les timeouts
- Stratégie UIA créée quand snapshot+surface OK
- Stratégie UIA bloquée sur Citrix
- IRBuilder propage uia_snapshot
- Runner produit target_spec avec uia_target + resolve_order=['uia', 'ocr', 'vlm']
496 tests au total, 0 régression.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Premier pas de l'Option B hybride : vision + UIA pour Windows natif.
Pourquoi Rust ?
- Binaire standalone ~500 Ko, aucune dépendance runtime
- 5-10x plus rapide que pywinauto (10-20ms par query vs 50-200ms)
- Compilation cross-platform depuis Linux (x86_64-pc-windows-gnu)
- Safe : pas de crash sur null pointer ou memory leak
- Préparation d'un déploiement industriel robuste
Commandes :
- query --x N --y N : élément UIA à cette position
- find --name "..." --control-type "..." : recherche par nom
- capture --max-depth N : élément focus + hiérarchie
- health : vérifier que UIA est dispo
Sortie JSON structurée (stdin/stdout pour IPC avec Python).
Stub Linux pour dev/tests sans Windows.
Validé sur VM Windows :
- query (100,100) → "Bureau 1" en 18ms
- query (500,400) → "Bureau 1" en 12ms
- find "Rechercher" → not_found en 11ms (normal, rien d'ouvert)
Le binaire lea_uia.exe sera packagé avec Léa dans C:\Lea\helpers\
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Le resolve_engine suit désormais l'ordre de méthodes décidé par l'ExecutionCompiler
au lieu de sa cascade improvisée. C'est la pièce maîtresse du V4 :
- execution_plan_runner.py : ajout de 'resolve_order' dans target_spec
["ocr", "template", "vlm"] = stratégies dans l'ordre de préférence
- resolve_engine.py : _resolve_with_precompiled_order() honore l'ordre
- Court-circuite la cascade legacy quand resolve_order est présent
- Fallback sur la cascade si toutes les méthodes V4 échouent
- _resolve_by_ocr_text() : résolution OCR directe via docTR (~200ms)
Chemin rapide V4 — pas de VLM pour les éléments avec texte visible
- 12 nouveaux tests : propagation resolve_order, cascade, fallback, pipeline E2E
220 tests passent (208 existants + 12 nouveaux), 0 régression.
"Le LLM compile. Le runtime exécute."
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Format canonique entre RawTrace (capture) et ExecutionPlan (exécution).
C'est ce que Léa a COMPRIS en observant l'utilisateur.
- WorkflowIR : steps, variables, intentions, pré/postconditions
- IRBuilder : transforme les événements bruts en WorkflowIR via gemma4
- Générique : fonctionne pour TIM, compta, RH, stocks — le domaine est une couche par-dessus
- Versionné, sérialisable JSON, save/load
- Détection automatique des variables (texte saisi → substituable)
- 18 tests (format, sérialisation, builder, segmentation, variables)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Les clics taskbar (sans window_capture.rect) ne passent plus par le
grounding VLM qui trouve "Rechercher" dans l'explorateur au lieu de
la taskbar. Le template matching du crop 80x80 est utilisé à la place.
Règle : fenêtre = grounding, taskbar = template matching.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Quand le magnétoscope ne trouve pas la cible, au lieu de la pause
supervisée, gemma4 (Docker port 11435, think=True) reçoit le contexte
(action prévue + fenêtre active) et décide :
- PASSER : le résultat est déjà atteint (onglet actif, dialog ouvert)
- STOPPER : état incohérent (mauvaise app)
- EXECUTER : fallback vers la pause supervisée
Testé : gemma4 décide PASSER quand l'onglet est déjà actif (5s).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
La description de la cible dans les notifications et logs utilise
by_text et window_title au lieu de by_role="yolo" qui n'a pas de
sens pour l'utilisateur.
Testé : gemma4 en mode texte (CPU, 0.2s) prend la décision "PASSER"
quand l'onglet est déjà actif. Base pour l'acteur intelligent.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Avant la résolution visuelle, compare l'embedding CLIP de l'écran
actuel (fenêtre) avec l'embedding de référence (enregistrement).
Si similarité < 0.75 → mauvaise application → STOP.
CLIP sur fenêtre = insensible au fond d'écran.
CLIP ne distingue pas les états fins (texte différent) → le titre
de fenêtre reste la vérification principale.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Approche hybride :
- Actions du magnétoscope (by_text, target_spec, grounding)
- Embeddings CLIP du workflow (512D par screenshot de clic)
- Au replay : CLIP vérifie l'état de l'écran AVANT chaque clic
Pipeline complet mesuré :
- ScreenAnalyzer (OCR) : 1.05s/screenshot
- CLIP embeddings : 0.093s/screenshot
- FAISS : <0.01s pour 13 vecteurs
- GraphBuilder : 0.7s (13 nodes, 12 edges)
- Total : 15.7s pour 1.5 min de session
- Extrapolation 1h : ~10 min
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. Le grounding se déclenche pour by_text_source="vlm" (pas juste "ocr")
Les textes lus par gemma4 (onglets, labels) sont du texte visible,
le grounding doit les chercher comme n'importe quel texte OCR.
2. gemma4 est automatiquement déchargé après le build_replay
pour libérer la VRAM et permettre à qwen2.5vl de charger au replay.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Quand plusieurs éléments ont le même texte ("Rechercher" dans la taskbar
ET dans l'explorateur), la position relative (en bas, en haut, à gauche)
aide le VLM à choisir le bon.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Quand l'OCR et SomEngine ne trouvent pas de texte sur un élément cliqué,
gemma4 (Ollama 0.20 Docker) analyse le screenshot fenêtre + position du
clic pour identifier l'élément ("voiture elec", "Settings", etc.).
Résultat : 0 clic sans by_text (vs 3 avant). Validation locale 7/8 (87%).
L'onglet Bloc-notes est maintenant correctement identifié.
Docker : ollama/ollama:0.20.2 sur port 11435 (GEMMA4_PORT env var).
Host : Ollama 0.16.3 sur port 11434 (qwen2.5vl grounding).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Compare 'Bloc-notes' (après le –) au lieu du titre complet.
'blocnote.txt – Bloc-notes' et 'voiture.txt – Bloc-notes'
sont la même app → pré-vérif et post-vérif passent.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Le resolve_target reçoit un screenshot temp de l'agent — le fichier
_window.png n'existe pas à cet emplacement. Au lieu de chercher un
fichier, on crop directement la fenêtre depuis le full screenshot
en utilisant window_rect du target_spec.
Fonctionne au replay (screenshot live) comme à l'enregistrement.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
