a21f1ea9fa3eb04ecc6b187e5efbe42b32b32648
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>
RPA Vision V3 - 100% Vision-Based Workflow Automation
📊 Status
🚀 PRODUCTION-READY - Phase 12 Complete (77% System Completion) ✅
Latest Update: 14 Décembre 2024
- ✅ 10/13 Phases Complétées - Système mature et fonctionnel
- ✅ Performance Exceptionnelle - 500-6250x plus rapide que requis
- ✅ Architecture Entreprise - 148k+ lignes, 19 modules, 6 specs complètes
- ✅ Innovations Techniques - Self-healing, Multi-modal, GPU management
- 📊 Audit Complet - Rapport détaillé
Quick Test: bash test_clip.sh
🎯 Vision
RPA basé sur la compréhension sémantique des interfaces, pas sur des coordonnées de clics.
Le système apprend des workflows en observant l'utilisateur et les automatise de manière robuste grâce à une architecture en 5 couches.
🏗️ Architecture en 5 Couches
RawSession (Couche 0)
↓
ScreenState (Couche 1) - 4 niveaux d'abstraction
↓
UIElement Detection (Couche 2) - Types + Rôles sémantiques
↓
State Embedding (Couche 3) - Fusion multi-modale
↓
Workflow Graph (Couche 4) - Nodes + Edges + Learning States
📁 Structure
rpa_vision_v3/
├── core/
│ ├── models/ # Couches 0-4 : Structures de données
│ ├── capture/ # Couche 0 : Capture événements + screenshots
│ ├── detection/ # Couche 2 : Détection UI sémantique
│ ├── embedding/ # Couche 3 : Fusion multi-modale + FAISS
│ ├── graph/ # Couche 4 : Construction + Matching + Exécution
│ └── persistence/ # Sauvegarde/Chargement
├── data/
│ ├── sessions/ # RawSessions
│ ├── screen_states/ # ScreenStates
│ ├── embeddings/ # Vecteurs .npy
│ ├── faiss_index/ # Index FAISS
│ └── workflows/ # Workflow Graphs
└── tests/ # Tests unitaires + intégration
🚀 Démarrage Rapide
Installation
# 1. Installer Ollama
curl -fsSL https://ollama.ai/install.sh | sh # Linux
# ou
brew install ollama # macOS
# 2. Démarrer Ollama
ollama serve
# 3. Télécharger le modèle VLM
ollama pull qwen3-vl:8b
# 4. Installer dépendances Python
pip install -r requirements.txt
Test Rapide
# Diagnostic système
python3 rpa_vision_v3/examples/diagnostic_vlm.py
# Test de détection
./rpa_vision_v3/test_quick.sh
Utilisation - Détection UI
from rpa_vision_v3.core.detection import create_detector
# Créer le détecteur
detector = create_detector()
# Détecter les éléments UI
elements = detector.detect("screenshot.png")
# Utiliser les résultats
for elem in elements:
print(f"{elem.type:15s} | {elem.role:20s} | {elem.label}")
Utilisation - Workflow (Phase 4 - À venir)
from rpa_vision_v3.core.models import RawSession, ScreenState, Workflow
from rpa_vision_v3.core.graph import GraphBuilder, NodeMatcher
# 1. Capturer une session
session = RawSession(...)
# ... capturer événements et screenshots
# 2. Construire workflow automatiquement
builder = GraphBuilder(...)
workflow = builder.build_from_session(session)
# 3. Matcher état actuel
matcher = NodeMatcher(...)
current_state = ScreenState(...)
match = matcher.match(current_state, workflow)
# 4. Exécuter action
if match:
edge = workflow.get_outgoing_edges(match.node.node_id)[0]
executor.execute_edge(edge, current_state)
📚 Documentation
Guides Principaux
- Quick Start :
QUICK_START.md- Démarrage rapide - Prochaines Étapes :
NEXT_STEPS.md- Roadmap et Phase 4 - Phase 3 Complète :
PHASE3_COMPLETE.md- Résumé Phase 3
Documentation Technique
- Spec complète :
.kiro/specs/workflow-graph-implementation/ - Architecture :
docs/reference/ARCHITECTURE_VISION_COMPLETE.md - Détection Hybride :
HYBRID_DETECTION_SUMMARY.md - Intégration Ollama :
docs/OLLAMA_INTEGRATION.md
🎓 Concepts Clés
RPA 100% Vision
- ❌ Pas de coordonnées (x, y) fixes
- ✅ Rôles sémantiques (primary_action, form_input, etc.)
- ✅ Matching par similarité visuelle et textuelle
- ✅ Robuste aux changements d'UI
Apprentissage Progressif
OBSERVATION (5+ exécutions)
↓
COACHING (10+ assistances, succès >90%)
↓
AUTO_CANDIDATE (20+ exécutions, succès >95%)
↓
AUTO_CONFIRMÉ (validation utilisateur)
State Embedding
Fusion multi-modale :
- 50% Image (screenshot complet)
- 30% Texte (texte détecté)
- 10% Titre (fenêtre)
- 10% UI (éléments détectés)
🧪 Tests
# Tests unitaires
pytest tests/unit/
# Tests d'intégration
pytest tests/integration/
# Tests de performance
pytest tests/performance/ --benchmark-only
📈 Roadmap - 77% Complété (10/13 Phases)
✅ Phases Complétées
- Phase 1-2 : Fondations + Embeddings FAISS ✅
- Phase 4-6 : Détection UI + Workflow Graphs + Action Execution ✅
- Phase 7-8 : Learning System + Training System ✅
- Phase 10-12 : GPU Management + Performance + Monitoring ✅
🎯 Phases Restantes
- Phase 3 : Checkpoint Final (tests storage)
- Phase 9 : Visual Workflow Builder (90% → 100%)
- Phase 13 : Tests End-to-End + Documentation finale
🚀 Composants Production-Ready
- Agent V0 : Capture cross-platform + Encryption ✅
- Server API : Processing pipeline + Web dashboard ✅
- Analytics System : Monitoring + Insights + Reporting ✅
- Self-Healing : Automatic adaptation + Recovery ✅
🤝 Contribution
Voir .kiro/specs/workflow-graph-implementation/tasks.md pour les tâches en cours.
📄 Licence
Propriétaire - Tous droits réservés
Description
Languages
Python
82.6%
TypeScript
11.8%
HTML
2.7%
Shell
1.2%
CSS
1.1%
Other
0.4%