v1.0 - Version stable: multi-PC, détection UI-DETR-1, 3 modes exécution
- Frontend v4 accessible sur réseau local (192.168.1.40) - Ports ouverts: 3002 (frontend), 5001 (backend), 5004 (dashboard) - Ollama GPU fonctionnel - Self-healing interactif - Dashboard confiance Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
272
docs/specs/ROADMAP.md
Normal file
272
docs/specs/ROADMAP.md
Normal file
@@ -0,0 +1,272 @@
|
||||
# RPA Vision V3 - Roadmap Mise à Jour
|
||||
|
||||
**Date:** 22 Novembre 2024
|
||||
**Status:** Phase 3 Complétée, Phase 2 à finaliser
|
||||
|
||||
---
|
||||
|
||||
## 📊 État Actuel
|
||||
|
||||
### ✅ Phase 1 : Modèles de Base - COMPLÉTÉ
|
||||
- [x] RawSession, ScreenState, UIElement, StateEmbedding, WorkflowGraph
|
||||
- [x] Sérialisation/désérialisation JSON
|
||||
- [x] Tests unitaires de base
|
||||
|
||||
### ⏳ Phase 2 : Système d'Embeddings - À COMPLÉTER
|
||||
**Status:** Structures créées, embedders réels manquants
|
||||
|
||||
#### Fait
|
||||
- [x] FusionEngine (fusion pondérée)
|
||||
- [x] FAISSManager (indexation)
|
||||
- [x] Similarity (calculs)
|
||||
- [x] StateEmbeddingBuilder (structure)
|
||||
|
||||
#### À Faire 🎯
|
||||
- [ ] **2.8 Implémenter vrais embedders CLIP** ← PROCHAINE TÂCHE
|
||||
- Copier/adapter depuis geniusia2/core/embedders/
|
||||
- Créer `rpa_vision_v3/core/embedding/clip_embedder.py`
|
||||
- Charger OpenCLIP
|
||||
- Implémenter `embed_image()` et `embed_text()`
|
||||
|
||||
- [ ] **2.9 Intégrer CLIP dans StateEmbeddingBuilder**
|
||||
- Remplacer vecteurs aléatoires par vrais embeddings
|
||||
- Configurer embedders
|
||||
- Tester avec screenshots réels
|
||||
|
||||
- [ ] **2.10 Tests d'intégration**
|
||||
- Valider pipeline complet
|
||||
- Benchmarks de performance
|
||||
|
||||
### ✅ Phase 3 : UI Detection avec VLM - COMPLÉTÉ (22 Nov 2024)
|
||||
- [x] OllamaClient (qwen3-vl:8b)
|
||||
- [x] UIDetector hybride (OpenCV + VLM)
|
||||
- [x] Tests complets sur screenshots réels
|
||||
- [x] Documentation complète
|
||||
- [x] Précision: 88%, Vitesse: 0.8s/élément
|
||||
|
||||
### 🚀 Phase 3.5 : Optimisation Asynchrone - PROCHAINE
|
||||
**Objectif:** Gain de vitesse 3-5x (40s → 8-12s pour 50 éléments)
|
||||
|
||||
#### À Faire
|
||||
- [ ] **3.5.1 AsyncOllamaClient**
|
||||
- Refactoriser avec asyncio/aiohttp
|
||||
- Batch processing (5-10 éléments parallèles)
|
||||
- Gestion concurrence avec semaphore
|
||||
|
||||
- [ ] **3.5.2 AsyncUIDetector**
|
||||
- Intégrer AsyncOllamaClient
|
||||
- Traitement parallèle des régions
|
||||
- Tests de performance
|
||||
|
||||
- [ ] **3.5.3 Cache Intelligent**
|
||||
- Cache basé sur hash visuel
|
||||
- Détection de similarité
|
||||
- Hit rate > 30%
|
||||
|
||||
- [ ] **3.5.4 Monitoring**
|
||||
- Métriques temps réel
|
||||
- Resource management
|
||||
- Dashboard simple
|
||||
|
||||
### ⏳ Phase 4 : Construction de Workflow Graphs - EN ATTENTE
|
||||
**Dépend de:** Phase 2 complétée
|
||||
|
||||
#### À Faire
|
||||
- [ ] **4.1 GraphBuilder**
|
||||
- Construction depuis RawSession
|
||||
- Détection de patterns
|
||||
- Clustering d'états
|
||||
|
||||
- [ ] **4.2 NodeMatcher**
|
||||
- Matching par similarité
|
||||
- Validation de contraintes
|
||||
- Recherche FAISS
|
||||
|
||||
- [ ] **4.3 Tests d'intégration**
|
||||
- Pipeline complet
|
||||
- Validation sur données réelles
|
||||
|
||||
### ⏳ Phase 5-9 : Exécution, Apprentissage, etc. - EN ATTENTE
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Plan d'Action Recommandé
|
||||
|
||||
### Option A : Finir Phase 2 d'abord (Recommandé)
|
||||
```
|
||||
1. Implémenter CLIP embedders (2-3h)
|
||||
2. Intégrer dans StateEmbeddingBuilder (1h)
|
||||
3. Tester avec données réelles (1h)
|
||||
4. Puis Phase 3.5 (Async) (4-6h)
|
||||
5. Puis Phase 4 (Workflow Graphs) (8-12h)
|
||||
```
|
||||
|
||||
**Avantages:**
|
||||
- Système complet et cohérent
|
||||
- Embeddings réels pour Phase 4
|
||||
- Pas de refactoring plus tard
|
||||
|
||||
### Option B : Async d'abord, Phase 2 après
|
||||
```
|
||||
1. Phase 3.5 (Async) (4-6h)
|
||||
2. Phase 2 (CLIP) (4h)
|
||||
3. Phase 4 (Workflow Graphs) (8-12h)
|
||||
```
|
||||
|
||||
**Avantages:**
|
||||
- Gain de vitesse immédiat
|
||||
- Phase 3 optimisée rapidement
|
||||
|
||||
---
|
||||
|
||||
## 📋 Tâches Détaillées Phase 2
|
||||
|
||||
### Task 2.8 : Implémenter CLIP Embedders
|
||||
**Priorité:** Haute
|
||||
**Estimation:** 2-3h
|
||||
**Dépendances:** Aucune
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/core/embedding/clip_embedder.py`
|
||||
- `rpa_vision_v3/core/embedding/base_embedder.py` (interface)
|
||||
|
||||
**Étapes:**
|
||||
1. Copier `geniusia2/core/embedders/base.py` → `base_embedder.py`
|
||||
2. Copier `geniusia2/core/embedders/clip_embedder.py` → `clip_embedder.py`
|
||||
3. Adapter imports et chemins
|
||||
4. Tester chargement du modèle
|
||||
5. Tester génération d'embeddings
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Modèle OpenCLIP charge correctement
|
||||
- [ ] `embed_image()` génère vecteur 512D normalisé
|
||||
- [ ] `embed_text()` génère vecteur 512D normalisé
|
||||
- [ ] Tests unitaires passent
|
||||
|
||||
### Task 2.9 : Intégrer CLIP dans StateEmbeddingBuilder
|
||||
**Priorité:** Haute
|
||||
**Estimation:** 1-2h
|
||||
**Dépendances:** 2.8
|
||||
|
||||
**Fichiers à modifier:**
|
||||
- `rpa_vision_v3/core/embedding/state_embedding_builder.py`
|
||||
|
||||
**Étapes:**
|
||||
1. Importer CLIPEmbedder
|
||||
2. Initialiser dans `__init__` avec embedders dict
|
||||
3. Remplacer `np.random.randn()` par vrais embeddings
|
||||
4. Tester avec screenshot réel
|
||||
5. Valider dimensions et normalisation
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Vecteurs aléatoires remplacés par CLIP
|
||||
- [ ] Embeddings image/texte/titre fonctionnels
|
||||
- [ ] Vecteur fusionné normalisé (L2 norm = 1)
|
||||
- [ ] Tests d'intégration passent
|
||||
|
||||
### Task 2.10 : Tests et Validation
|
||||
**Priorité:** Moyenne
|
||||
**Estimation:** 1h
|
||||
**Dépendances:** 2.9
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/tests/integration/test_embedding_pipeline.py`
|
||||
- `rpa_vision_v3/examples/test_embeddings.py`
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Pipeline complet testé (screenshot → embedding)
|
||||
- [ ] Similarité entre états similaires > 0.8
|
||||
- [ ] Similarité entre états différents < 0.5
|
||||
- [ ] Performance < 200ms par état
|
||||
|
||||
---
|
||||
|
||||
## 📋 Tâches Détaillées Phase 3.5
|
||||
|
||||
### Task 3.5.1 : AsyncOllamaClient
|
||||
**Priorité:** Haute
|
||||
**Estimation:** 2h
|
||||
**Dépendances:** Aucune
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/core/detection/async_ollama_client.py`
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Client async avec aiohttp
|
||||
- [ ] Batch processing 5-10 éléments
|
||||
- [ ] Semaphore pour limitation concurrence
|
||||
- [ ] Gestion erreurs par élément
|
||||
- [ ] Tests de performance
|
||||
|
||||
### Task 3.5.2 : AsyncUIDetector
|
||||
**Priorité:** Haute
|
||||
**Estimation:** 1.5h
|
||||
**Dépendances:** 3.5.1
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/core/detection/async_ui_detector.py`
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Détection async complète
|
||||
- [ ] Gain de vitesse ≥ 3x mesuré
|
||||
- [ ] Précision maintenue ≥ 85%
|
||||
- [ ] Tests d'intégration
|
||||
|
||||
### Task 3.5.3 : Cache Intelligent
|
||||
**Priorité:** Moyenne
|
||||
**Estimation:** 2h
|
||||
**Dépendances:** 3.5.2
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/core/detection/region_cache.py`
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Cache basé sur hash visuel
|
||||
- [ ] Hit rate ≥ 30%
|
||||
- [ ] TTL configurable
|
||||
- [ ] Tests unitaires
|
||||
|
||||
### Task 3.5.4 : Monitoring
|
||||
**Priorité:** Basse
|
||||
**Estimation:** 2h
|
||||
**Dépendances:** 3.5.2
|
||||
|
||||
**Fichiers à créer:**
|
||||
- `rpa_vision_v3/core/detection/performance_monitor.py`
|
||||
- `rpa_vision_v3/core/detection/resource_manager.py`
|
||||
|
||||
**Critères d'acceptation:**
|
||||
- [ ] Métriques temps réel
|
||||
- [ ] Adaptation dynamique batch size
|
||||
- [ ] Logs structurés
|
||||
- [ ] Dashboard optionnel
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Recommandation Finale
|
||||
|
||||
**Je recommande Option A : Finir Phase 2 d'abord**
|
||||
|
||||
**Raison:**
|
||||
1. Phase 2 est presque finie (juste embedders manquants)
|
||||
2. Phase 4 a besoin d'embeddings réels
|
||||
3. Évite refactoring plus tard
|
||||
4. Système cohérent et complet
|
||||
|
||||
**Plan:**
|
||||
```
|
||||
Jour 1 : Phase 2 (4h)
|
||||
- Matin : Implémenter CLIP (2-3h)
|
||||
- Après-midi : Intégrer + tester (1-2h)
|
||||
|
||||
Jour 2 : Phase 3.5 (6h)
|
||||
- Matin : AsyncOllamaClient + AsyncUIDetector (3-4h)
|
||||
- Après-midi : Cache + Monitoring (2-3h)
|
||||
|
||||
Jour 3+ : Phase 4 (8-12h)
|
||||
- GraphBuilder
|
||||
- NodeMatcher
|
||||
- Tests
|
||||
```
|
||||
|
||||
**Qu'en pensez-vous ?** 🤔
|
||||
1419
docs/specs/design.md
Normal file
1419
docs/specs/design.md
Normal file
File diff suppressed because it is too large
Load Diff
224
docs/specs/requirements.md
Normal file
224
docs/specs/requirements.md
Normal file
@@ -0,0 +1,224 @@
|
||||
# Document de Requirements - Workflow Graph Implementation
|
||||
|
||||
## Introduction
|
||||
|
||||
Ce document définit les exigences pour l'implémentation de l'architecture Workflow Graph du système RPA Vision V2. Le système transforme progressivement des captures d'écran brutes en workflows sémantiques appris, permettant une automatisation basée sur la compréhension visuelle plutôt que sur des coordonnées de clics.
|
||||
|
||||
L'architecture suit une approche en 5 couches : RawSession (capture brute) → ScreenState (analyse multi-modale) → UIElement Detection (détection sémantique) → State Embedding (fusion multi-modale) → Workflow Graph (modélisation en graphe avec apprentissage progressif).
|
||||
|
||||
## Glossaire
|
||||
|
||||
- **System** : Le système RPA Vision V2
|
||||
- **ScreenState** : Représentation structurée d'un état d'écran à 4 niveaux (Raw, Perception, Sémantique UI, Contexte Métier)
|
||||
- **UIElement** : Élément d'interface détecté avec type, rôle et embeddings
|
||||
- **State Embedding** : Vecteur unique (fingerprint) fusionnant toutes les modalités d'un écran
|
||||
- **WorkflowNode** : Template d'état d'écran dans un graphe de workflow
|
||||
- **WorkflowEdge** : Transition (action) entre deux nodes
|
||||
- **Workflow Graph** : Graphe complet modélisant un workflow avec états d'apprentissage
|
||||
- **Learning State** : État de progression (OBSERVATION, COACHING, AUTO_CANDIDATE, AUTO_CONFIRMÉ)
|
||||
- **RawSession** : Enregistrement brut des événements utilisateur avec screenshots
|
||||
- **Embedding** : Vecteur numérique représentant une modalité (image, texte, UI)
|
||||
- **FAISS Index** : Index de recherche de similarité pour embeddings
|
||||
- **VLM** : Vision-Language Model (modèle vision-langage)
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1
|
||||
|
||||
**User Story:** En tant que développeur système, je veux capturer fidèlement les sessions utilisateur avec tous les événements et screenshots, afin de pouvoir analyser et apprendre les workflows.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System captures a user session THEN THE System SHALL record all mouse events with precise timestamps and window context
|
||||
2. WHEN THE System captures a user session THEN THE System SHALL record all keyboard events with key combinations and window context
|
||||
3. WHEN THE System captures a user session THEN THE System SHALL take screenshots at each significant event with unique identifiers
|
||||
4. WHEN THE System saves a RawSession THEN THE System SHALL serialize it to JSON format with schema version "rawsession_v1"
|
||||
5. WHEN THE System loads a RawSession THEN THE System SHALL deserialize it from JSON and validate schema compatibility
|
||||
|
||||
### Requirement 2
|
||||
|
||||
**User Story:** En tant que développeur système, je veux transformer chaque screenshot en ScreenState structuré à 4 niveaux, afin d'avoir une représentation riche et exploitable de l'état d'écran.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System processes a screenshot THEN THE System SHALL create a ScreenState with Raw level containing image path and metadata
|
||||
2. WHEN THE System processes a screenshot THEN THE System SHALL create Perception level with image embedding using OpenCLIP
|
||||
3. WHEN THE System processes a screenshot THEN THE System SHALL detect text using VLM and create text embeddings
|
||||
4. WHEN THE System processes a screenshot THEN THE System SHALL detect UI elements and create Sémantique UI level
|
||||
5. WHEN THE System processes a screenshot THEN THE System SHALL extract window context and create Contexte Métier level
|
||||
6. WHEN THE System saves a ScreenState THEN THE System SHALL serialize it to JSON with all 4 levels preserved
|
||||
|
||||
### Requirement 3
|
||||
|
||||
**User Story:** En tant que développeur système, je veux détecter les éléments UI de manière sémantique avec types et rôles, afin de pouvoir les identifier et les manipuler indépendamment de leur position exacte.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System detects UI elements THEN THE System SHALL identify regions of interest using VLM
|
||||
2. WHEN THE System detects UI elements THEN THE System SHALL classify each element with a semantic type (button, text_input, checkbox, etc.)
|
||||
3. WHEN THE System detects UI elements THEN THE System SHALL assign a semantic role to each element (primary_action, cancel, form_input, etc.)
|
||||
4. WHEN THE System detects UI elements THEN THE System SHALL extract visual features (dominant color, shape, size category)
|
||||
5. WHEN THE System detects UI elements THEN THE System SHALL generate dual embeddings (image embedding and text embedding) for each element
|
||||
6. WHEN THE System detects UI elements THEN THE System SHALL compute a confidence score for each detection
|
||||
7. WHEN THE System saves UIElements THEN THE System SHALL serialize them to JSON with all attributes and embeddings references
|
||||
|
||||
### Requirement 4
|
||||
|
||||
**User Story:** En tant que développeur système, je veux fusionner toutes les modalités d'un écran en un State Embedding unique, afin de pouvoir comparer et matcher des états d'écran de manière robuste.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System creates a State Embedding THEN THE System SHALL compute image embedding from the full screenshot
|
||||
2. WHEN THE System creates a State Embedding THEN THE System SHALL compute text embedding from all detected text concatenated
|
||||
3. WHEN THE System creates a State Embedding THEN THE System SHALL compute title embedding from window title
|
||||
4. WHEN THE System creates a State Embedding THEN THE System SHALL compute UI embedding by averaging all UIElement embeddings
|
||||
5. WHEN THE System creates a State Embedding THEN THE System SHALL fuse all embeddings using weighted combination with configurable weights
|
||||
6. WHEN THE System creates a State Embedding THEN THE System SHALL normalize the final embedding vector
|
||||
7. WHEN THE System compares two State Embeddings THEN THE System SHALL compute cosine similarity between vectors
|
||||
8. WHEN THE System saves a State Embedding THEN THE System SHALL store the vector in FAISS index and save metadata to JSON
|
||||
|
||||
### Requirement 5
|
||||
|
||||
**User Story:** En tant que développeur système, je veux modéliser les workflows comme des graphes explicites avec Nodes et Edges, afin de représenter clairement les états et transitions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System creates a WorkflowNode THEN THE System SHALL define a screen template with window constraints
|
||||
2. WHEN THE System creates a WorkflowNode THEN THE System SHALL define required text patterns for matching
|
||||
3. WHEN THE System creates a WorkflowNode THEN THE System SHALL define required UI elements with roles and types
|
||||
4. WHEN THE System creates a WorkflowNode THEN THE System SHALL compute an embedding prototype from sample ScreenStates
|
||||
5. WHEN THE System creates a WorkflowNode THEN THE System SHALL set a minimum similarity threshold for matching
|
||||
6. WHEN THE System saves a WorkflowNode THEN THE System SHALL serialize it to JSON with all template constraints
|
||||
|
||||
### Requirement 6
|
||||
|
||||
**User Story:** En tant que développeur système, je veux définir les transitions entre nodes comme des WorkflowEdges avec actions sémantiques, afin de spécifier comment naviguer dans le workflow.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define source and target nodes
|
||||
2. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define action type (mouse_click, key_press, text_input, compound)
|
||||
3. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define target element by semantic role rather than coordinates
|
||||
4. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define selection policy for target element (first, last, by_similarity)
|
||||
5. WHEN THE System creates a WorkflowEdge THEN THE System SHALL define pre-conditions and post-conditions for validation
|
||||
6. WHEN THE System creates a WorkflowEdge THEN THE System SHALL track execution statistics (success count, failure count, avg time)
|
||||
7. WHEN THE System saves a WorkflowEdge THEN THE System SHALL serialize it to JSON with all action details and stats
|
||||
|
||||
### Requirement 7
|
||||
|
||||
**User Story:** En tant que développeur système, je veux assembler Nodes et Edges en Workflow Graph complet avec métadonnées, afin d'avoir une représentation complète du workflow.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System creates a Workflow Graph THEN THE System SHALL define entry nodes and end nodes
|
||||
2. WHEN THE System creates a Workflow Graph THEN THE System SHALL validate that all edges reference existing nodes
|
||||
3. WHEN THE System creates a Workflow Graph THEN THE System SHALL detect cycles and branching in the graph
|
||||
4. WHEN THE System creates a Workflow Graph THEN THE System SHALL assign a unique workflow_id
|
||||
5. WHEN THE System creates a Workflow Graph THEN THE System SHALL initialize learning state to OBSERVATION
|
||||
6. WHEN THE System saves a Workflow Graph THEN THE System SHALL serialize it to JSON with all nodes, edges and metadata
|
||||
|
||||
### Requirement 8
|
||||
|
||||
**User Story:** En tant que développeur système, je veux implémenter les états d'apprentissage progressif (OBSERVATION, COACHING, AUTO_CANDIDATE, AUTO_CONFIRMÉ), afin de permettre au système d'apprendre graduellement.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System initializes a workflow THEN THE System SHALL set learning state to OBSERVATION
|
||||
2. WHEN THE System has observed a workflow 5 times with similarity > 0.90 THEN THE System SHALL transition to COACHING state
|
||||
3. WHEN THE System has assisted a workflow 10 times with success rate > 0.90 THEN THE System SHALL transition to AUTO_CANDIDATE state
|
||||
4. WHEN THE System has executed a workflow 20 times in AUTO_CANDIDATE with success rate > 0.95 THEN THE System SHALL be eligible for AUTO_CONFIRMÉ state
|
||||
5. WHEN THE System transitions learning state THEN THE System SHALL log the transition with reason and timestamp
|
||||
6. WHEN THE System is in AUTO_CONFIRMÉ state and confidence drops below 0.90 THEN THE System SHALL rollback to COACHING state
|
||||
|
||||
### Requirement 9
|
||||
|
||||
**User Story:** En tant que développeur système, je veux matcher un ScreenState actuel contre les WorkflowNodes existants, afin de reconnaître dans quel état du workflow on se trouve.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System matches a ScreenState THEN THE System SHALL compute State Embedding for current screen
|
||||
2. WHEN THE System matches a ScreenState THEN THE System SHALL search FAISS index for similar node prototypes
|
||||
3. WHEN THE System matches a ScreenState THEN THE System SHALL validate window constraints for candidate nodes
|
||||
4. WHEN THE System matches a ScreenState THEN THE System SHALL validate required text patterns for candidate nodes
|
||||
5. WHEN THE System matches a ScreenState THEN THE System SHALL validate required UI elements for candidate nodes
|
||||
6. WHEN THE System matches a ScreenState THEN THE System SHALL return best matching node with confidence score
|
||||
7. WHEN THE System matches a ScreenState and no node matches above threshold THEN THE System SHALL return null match
|
||||
|
||||
### Requirement 10
|
||||
|
||||
**User Story:** En tant que développeur système, je veux exécuter les actions définies dans WorkflowEdges en trouvant les UIElements par rôle, afin d'automatiser le workflow de manière robuste.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System executes a WorkflowEdge THEN THE System SHALL find target UIElement by semantic role in current ScreenState
|
||||
2. WHEN THE System executes a mouse_click action THEN THE System SHALL click on the center of the matched UIElement
|
||||
3. WHEN THE System executes a text_input action THEN THE System SHALL type text into the matched UIElement
|
||||
4. WHEN THE System executes a compound action THEN THE System SHALL execute all steps in sequence
|
||||
5. WHEN THE System executes an action THEN THE System SHALL wait for post-conditions to be satisfied
|
||||
6. WHEN THE System executes an action THEN THE System SHALL verify transition to expected target node
|
||||
7. WHEN THE System executes an action and post-conditions fail THEN THE System SHALL log failure and rollback if possible
|
||||
|
||||
### Requirement 11
|
||||
|
||||
**User Story:** En tant que développeur système, je veux détecter automatiquement les patterns répétés dans les RawSessions, afin de construire les Workflow Graphs sans intervention manuelle.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System analyzes a RawSession THEN THE System SHALL group events by window context
|
||||
2. WHEN THE System analyzes a RawSession THEN THE System SHALL create ScreenStates for all screenshots
|
||||
3. WHEN THE System analyzes a RawSession THEN THE System SHALL compute State Embeddings for all ScreenStates
|
||||
4. WHEN THE System analyzes a RawSession THEN THE System SHALL detect repeated sequences using embedding similarity
|
||||
5. WHEN THE System detects a repeated sequence THEN THE System SHALL cluster similar ScreenStates into candidate nodes
|
||||
6. WHEN THE System detects a repeated sequence THEN THE System SHALL identify transitions as candidate edges
|
||||
7. WHEN THE System detects a repeated sequence with 3+ repetitions THEN THE System SHALL propose a Workflow Graph
|
||||
|
||||
### Requirement 12
|
||||
|
||||
**User Story:** En tant que développeur système, je veux persister tous les artefacts (ScreenStates, Embeddings, Workflow Graphs) de manière structurée, afin de pouvoir les recharger et les analyser.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System saves a ScreenState THEN THE System SHALL write JSON file with schema version
|
||||
2. WHEN THE System saves embeddings THEN THE System SHALL write numpy arrays to .npy files
|
||||
3. WHEN THE System saves embeddings THEN THE System SHALL add vectors to FAISS index
|
||||
4. WHEN THE System saves a Workflow Graph THEN THE System SHALL write JSON file with all nodes and edges
|
||||
5. WHEN THE System loads a Workflow Graph THEN THE System SHALL deserialize JSON and reconstruct graph structure
|
||||
6. WHEN THE System loads embeddings THEN THE System SHALL load FAISS index and metadata mappings
|
||||
7. WHEN THE System saves artifacts THEN THE System SHALL organize files by date and workflow_id
|
||||
|
||||
### Requirement 13
|
||||
|
||||
**User Story:** En tant que développeur système, je veux valider la qualité des State Embeddings, afin de m'assurer qu'ils discriminent bien les différents états.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System validates State Embeddings THEN THE System SHALL compute intra-node similarity (states of same node should be similar)
|
||||
2. WHEN THE System validates State Embeddings THEN THE System SHALL compute inter-node similarity (states of different nodes should be dissimilar)
|
||||
3. WHEN THE System validates State Embeddings THEN THE System SHALL compute embedding quality score as ratio of intra/inter similarity
|
||||
4. WHEN THE System validates State Embeddings and quality score is below 0.70 THEN THE System SHALL log warning
|
||||
5. WHEN THE System validates State Embeddings THEN THE System SHALL report discriminative power metric
|
||||
|
||||
### Requirement 14
|
||||
|
||||
**User Story:** En tant que développeur système, je veux gérer les erreurs de matching et d'exécution de manière robuste, afin que le système soit résilient aux changements d'UI.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System fails to match a ScreenState to any node THEN THE System SHALL log the unmatched state with screenshot
|
||||
2. WHEN THE System fails to find a target UIElement by role THEN THE System SHALL try fallback strategies (visual similarity, position)
|
||||
3. WHEN THE System fails to execute an action THEN THE System SHALL log the failure with context
|
||||
4. WHEN THE System detects UI change (similarity drop) THEN THE System SHALL pause execution and notify user
|
||||
5. WHEN THE System is in AUTO_CONFIRMÉ and confidence drops THEN THE System SHALL rollback to COACHING state
|
||||
6. WHEN THE System encounters repeated failures on same edge THEN THE System SHALL mark edge as problematic
|
||||
|
||||
### Requirement 15
|
||||
|
||||
**User Story:** En tant que développeur système, je veux optimiser les performances du système, afin que le matching et l'exécution soient rapides (< 400ms).
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN THE System computes State Embedding THEN THE System SHALL complete in less than 100ms
|
||||
2. WHEN THE System matches ScreenState against nodes THEN THE System SHALL complete FAISS search in less than 50ms
|
||||
3. WHEN THE System detects UI elements THEN THE System SHALL complete detection in less than 200ms
|
||||
4. WHEN THE System executes an action THEN THE System SHALL complete execution in less than 50ms
|
||||
5. WHEN THE System processes a ScreenState end-to-end THEN THE System SHALL complete in less than 400ms total
|
||||
696
docs/specs/tasks.md
Normal file
696
docs/specs/tasks.md
Normal file
@@ -0,0 +1,696 @@
|
||||
ok # Implementation Plan - Workflow Graph Implementation
|
||||
|
||||
## Vue d'Ensemble
|
||||
|
||||
Ce plan d'implémentation transforme le design en tâches concrètes et progressives. Chaque tâche construit sur les précédentes pour implémenter l'architecture complète en 5 couches du système RPA Vision V2.
|
||||
|
||||
**Principe** : Implémentation incrémentale avec tests à chaque étape. Focus sur le RPA 100% Vision avec workflows sémantiques.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] 1. Phase 1 : Fondations - Structures de Données
|
||||
- Créer les classes de base pour toutes les couches
|
||||
- Implémenter sérialisation/désérialisation JSON
|
||||
- _Requirements: 1.4, 1.5, 2.6, 7.6, 12.1, 12.4, 12.5_
|
||||
|
||||
- [ ] 1.1 Créer modèle RawSession avec sérialisation JSON
|
||||
- Implémenter classe `RawSession` dans `geniusia2/core/models/raw_session.py`
|
||||
- Implémenter classes `Event` et `Screenshot`
|
||||
- Implémenter méthodes `to_json()` et `from_json()`
|
||||
- Valider schéma "rawsession_v1"
|
||||
- _Requirements: 1.4, 1.5_
|
||||
|
||||
- [ ]* 1.2 Écrire tests unitaires pour RawSession
|
||||
- Tester sérialisation/désérialisation
|
||||
- Tester ajout d'événements et screenshots
|
||||
- Tester validation de schéma
|
||||
- **Property 1: RawSession Serialization Round Trip**
|
||||
- **Validates: Requirements 1.4, 1.5**
|
||||
|
||||
- [ ] 1.3 Créer modèle ScreenState avec 4 niveaux
|
||||
- Implémenter classe `ScreenState` dans `geniusia2/core/models/screen_state.py`
|
||||
- Implémenter classes `RawLevel`, `PerceptionLevel`, `ContextLevel`
|
||||
- Implémenter méthodes `to_json()` et `from_json()`
|
||||
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6_
|
||||
|
||||
- [ ]* 1.4 Écrire tests unitaires pour ScreenState
|
||||
- Tester création des 4 niveaux
|
||||
- Tester sérialisation/désérialisation
|
||||
- **Property 2: ScreenState Multi-Level Consistency**
|
||||
- **Validates: Requirements 2.1, 2.2, 2.3, 2.4, 2.5**
|
||||
|
||||
- [ ] 1.5 Créer modèle UIElement avec embeddings duaux
|
||||
- Implémenter classe `UIElement` dans `geniusia2/core/models/ui_element.py`
|
||||
- Implémenter classes `UIElementEmbeddings`, `VisualFeatures`
|
||||
- Implémenter méthodes `to_json()` et `from_json()`
|
||||
- _Requirements: 3.7_
|
||||
|
||||
- [ ]* 1.6 Écrire tests unitaires pour UIElement
|
||||
- Tester création avec tous les attributs
|
||||
- Tester sérialisation/désérialisation
|
||||
- **Property 3: UIElement Detection Confidence Bounds**
|
||||
- **Validates: Requirements 3.6**
|
||||
|
||||
- [ ] 1.7 Créer modèle StateEmbedding
|
||||
- Implémenter classe `StateEmbedding` dans `geniusia2/core/models/state_embedding.py`
|
||||
- Implémenter méthode `get_vector()` pour charger .npy
|
||||
- Implémenter méthode `compute_similarity()`
|
||||
- _Requirements: 4.7, 4.8_
|
||||
|
||||
- [x]* 1.8 Écrire tests unitaires pour StateEmbedding
|
||||
- Tester chargement de vecteur
|
||||
- Tester calcul de similarité
|
||||
- **Property 4: State Embedding Normalization**
|
||||
- **Property 5: State Embedding Similarity Symmetry**
|
||||
- **Property 6: State Embedding Similarity Bounds**
|
||||
- **Validates: Requirements 4.6, 4.7**
|
||||
|
||||
- [x] 1.9 Créer modèles Workflow Graph (Node, Edge, Workflow)
|
||||
- Implémenter classes dans `geniusia2/core/models/workflow_graph.py`
|
||||
- Implémenter `WorkflowNode`, `WorkflowEdge`, `Workflow`
|
||||
- Implémenter classes de support (ScreenTemplate, Action, etc.)
|
||||
- Implémenter méthodes `to_json()` et `from_json()`
|
||||
- _Requirements: 5.6, 6.7, 7.6_
|
||||
|
||||
- [ ]* 1.10 Écrire tests unitaires pour Workflow Graph
|
||||
- Tester création de nodes et edges
|
||||
- Tester sérialisation/désérialisation
|
||||
- **Property 12: Workflow Graph Structural Validity**
|
||||
- **Property 18: Workflow JSON Serialization Round Trip**
|
||||
- **Validates: Requirements 7.2, 7.6, 12.4, 12.5**
|
||||
|
||||
|
||||
|
||||
- [ ] 2. Phase 2 : Système d'Embeddings et FAISS
|
||||
- Implémenter fusion multi-modale
|
||||
- Implémenter gestion FAISS
|
||||
- Optimiser performances
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.8, 12.3, 12.6, 15.1, 15.2_
|
||||
|
||||
- [x] 2.1 Implémenter FusionEngine pour fusion pondérée
|
||||
- Créer classe `FusionEngine` dans `geniusia2/core/embedding/fusion_engine.py`
|
||||
- Implémenter méthode `fuse()` avec fusion pondérée
|
||||
- Implémenter normalisation des vecteurs
|
||||
- Configurer poids par défaut (image: 0.5, text: 0.3, title: 0.1, ui: 0.1)
|
||||
- _Requirements: 4.5, 4.6_
|
||||
|
||||
- [ ]* 2.2 Écrire tests unitaires pour FusionEngine
|
||||
- Tester fusion pondérée
|
||||
- Tester normalisation
|
||||
- **Property 17: State Embedding Component Weights Sum**
|
||||
- **Validates: Requirements 4.5**
|
||||
|
||||
- [x] 2.3 Implémenter FAISSManager pour indexation
|
||||
- Créer classe `FAISSManager` dans `geniusia2/core/embedding/faiss_manager.py`
|
||||
- Implémenter méthode `add_embedding()`
|
||||
- Implémenter méthode `search_similar()`
|
||||
- Implémenter sauvegarde/chargement d'index
|
||||
- Gérer metadata_store pour mappings
|
||||
- _Requirements: 4.8, 12.3, 12.6_
|
||||
|
||||
- [ ]* 2.4 Écrire tests unitaires pour FAISSManager
|
||||
- Tester ajout d'embeddings
|
||||
- Tester recherche de similarité
|
||||
- Tester sauvegarde/chargement
|
||||
- **Property 11: FAISS Index Consistency**
|
||||
- **Validates: Requirements 4.8, 12.3, 12.6**
|
||||
|
||||
- [x] 2.5 Implémenter calculs de similarité
|
||||
- Créer module `geniusia2/core/embedding/similarity.py`
|
||||
- Implémenter similarité cosinus
|
||||
- Implémenter distance euclidienne
|
||||
- Implémenter normalisation L2
|
||||
- _Requirements: 4.7_
|
||||
|
||||
- [ ]* 2.6 Écrire tests de performance pour embeddings
|
||||
- Benchmarker temps de fusion (cible: <100ms)
|
||||
- Benchmarker temps de recherche FAISS (cible: <50ms)
|
||||
- **Property 19: Performance Constraint - State Embedding**
|
||||
- **Validates: Requirements 15.1, 15.2**
|
||||
|
||||
- [x] 2.7 Implémenter StateEmbeddingBuilder
|
||||
- Créer classe pour construire State Embeddings complets
|
||||
- Intégrer FusionEngine
|
||||
- Calculer embeddings pour image, texte, titre, UI
|
||||
- Sauvegarder vecteurs en .npy
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6_
|
||||
|
||||
- [ ]* 2.8 Écrire tests d'intégration pour StateEmbeddingBuilder
|
||||
- Tester construction complète depuis ScreenState
|
||||
- Tester sauvegarde de vecteurs
|
||||
- Vérifier normalisation finale
|
||||
|
||||
- [ ] 3. Checkpoint - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [ ] 4. Phase 3 : Détection UI Sémantique
|
||||
- Intégrer VLM pour détection
|
||||
- Classifier types et rôles
|
||||
- Générer embeddings duaux
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 15.3_
|
||||
|
||||
- [x] 4.1 Créer UIDetector avec intégration VLM
|
||||
- Créer classe `UIDetector` dans `geniusia2/core/detection/ui_detector.py`
|
||||
- Intégrer client VLM (Qwen 2.5-VL via Ollama)
|
||||
- Implémenter détection de régions d'intérêt
|
||||
- _Requirements: 3.1_
|
||||
|
||||
- [x] 4.2 Implémenter classification de types UI
|
||||
- Ajouter méthode `classify_type()` dans UIDetector
|
||||
- Supporter types: button, text_input, checkbox, radio, dropdown, tab, link, icon, table_row, menu_item
|
||||
- Utiliser VLM pour classification
|
||||
- _Requirements: 3.2_
|
||||
|
||||
- [x] 4.3 Implémenter classification de rôles sémantiques
|
||||
- Ajouter méthode `classify_role()` dans UIDetector
|
||||
- Supporter rôles: primary_action, cancel, submit, form_input, search_field, etc.
|
||||
- Utiliser contexte visuel et textuel
|
||||
- _Requirements: 3.3_
|
||||
|
||||
- [x] 4.4 Implémenter extraction de features visuelles
|
||||
- Ajouter méthode `extract_visual_features()`
|
||||
- Extraire couleur dominante, forme, taille
|
||||
- Détecter présence d'icônes
|
||||
- _Requirements: 3.4_
|
||||
|
||||
- [x] 4.5 Implémenter génération d'embeddings duaux
|
||||
- Intégrer OpenCLIP pour embeddings
|
||||
- Générer embedding image (crop de l'élément)
|
||||
- Générer embedding texte (label détecté)
|
||||
- Sauvegarder embeddings en .npy
|
||||
- _Requirements: 3.5_
|
||||
|
||||
- [x] 4.6 Implémenter calcul de confiance de détection
|
||||
- Combiner confiance VLM + confiance classification
|
||||
- Filtrer éléments sous seuil (0.7)
|
||||
- _Requirements: 3.6_
|
||||
|
||||
- [ ]* 4.7 Écrire tests unitaires pour UIDetector
|
||||
- Tester détection avec screenshots de test
|
||||
- Tester classification de types et rôles
|
||||
- Tester génération d'embeddings
|
||||
- **Property 13: UIElement Role Uniqueness Per Type**
|
||||
- **Validates: Requirements 3.3**
|
||||
|
||||
- [ ]* 4.8 Écrire tests de performance pour détection UI
|
||||
- Benchmarker temps de détection (cible: <200ms)
|
||||
- Tester avec screenshots de différentes tailles
|
||||
- **Validates: Requirements 15.3**
|
||||
|
||||
|
||||
|
||||
- [x] 5. Phase 4 : Construction et Matching de Workflow Graphs ✅ COMPLÉTÉ (23 Nov 2024)
|
||||
- Construire graphes depuis sessions
|
||||
- Matcher ScreenStates contre nodes
|
||||
- Détecter patterns répétés
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7_
|
||||
|
||||
- [x] 5.1 Implémenter GraphBuilder pour construction automatique
|
||||
- Créer classe `GraphBuilder` dans `rpa_vision_v3/core/graph/graph_builder.py`
|
||||
- Implémenter méthode `build_from_session()`
|
||||
- Créer ScreenStates depuis RawSession
|
||||
- Calculer State Embeddings pour tous les états
|
||||
- _Requirements: 11.1, 11.2, 11.3_
|
||||
|
||||
- [x] 5.2 Implémenter détection de patterns répétés
|
||||
- Ajouter méthode `_detect_patterns()` dans GraphBuilder
|
||||
- Utiliser clustering sur embeddings (DBSCAN ou K-means)
|
||||
- Identifier transitions récurrentes entre clusters
|
||||
- Détecter séquences avec 3+ répétitions
|
||||
- _Requirements: 11.4, 11.5, 11.6, 11.7_
|
||||
|
||||
- [ ]* 5.3 Écrire tests pour détection de patterns
|
||||
- Tester avec sessions simulées
|
||||
- Vérifier détection de répétitions
|
||||
- **Property 16: Pattern Detection Minimum Repetitions**
|
||||
- **Validates: Requirements 11.7**
|
||||
|
||||
- [x] 5.4 Implémenter construction de WorkflowNodes depuis patterns
|
||||
- Ajouter méthode `_build_nodes()` dans GraphBuilder
|
||||
- Créer ScreenTemplate depuis cluster d'états
|
||||
- Calculer embedding prototype (moyenne des embeddings)
|
||||
- Extraire contraintes de fenêtre et texte requis
|
||||
- Identifier éléments UI requis
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_
|
||||
|
||||
- [ ]* 5.5 Écrire tests pour construction de nodes
|
||||
- Tester création de templates
|
||||
- Tester calcul de prototypes
|
||||
- **Property 14: Embedding Prototype Sample Count**
|
||||
- **Validates: Requirements 5.4**
|
||||
|
||||
- [x] 5.6 Implémenter construction de WorkflowEdges depuis transitions
|
||||
- Ajouter méthode `_build_edges()` dans GraphBuilder
|
||||
- Identifier actions entre états (depuis événements RawSession)
|
||||
- Créer TargetSpec avec rôles sémantiques
|
||||
- Définir pre-conditions et post-conditions
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6_
|
||||
|
||||
- [ ]* 5.7 Écrire tests pour construction d'edges
|
||||
- Tester identification d'actions
|
||||
- Tester création de TargetSpec
|
||||
- Vérifier contraintes
|
||||
|
||||
- [x] 5.8 Implémenter NodeMatcher pour matching en temps réel
|
||||
- Créer classe `NodeMatcher` dans `rpa_vision_v3/core/graph/node_matcher.py`
|
||||
- Implémenter méthode `match()`
|
||||
- Calculer State Embedding du ScreenState actuel
|
||||
- Chercher dans FAISS les prototypes similaires
|
||||
- Valider contraintes (fenêtre, texte, UI)
|
||||
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7_
|
||||
|
||||
- [ ]* 5.9 Écrire tests pour NodeMatcher
|
||||
- Tester matching avec différents seuils
|
||||
- Tester validation de contraintes
|
||||
- Tester cas où aucun node ne match
|
||||
- **Property 7: WorkflowNode Matching Consistency**
|
||||
- **Validates: Requirements 9.1, 9.2, 9.3, 9.4, 9.5, 9.6**
|
||||
|
||||
- [x] 5.10 Implémenter méthode WorkflowNode.matches()
|
||||
- Ajouter logique de matching dans WorkflowNode
|
||||
- Vérifier contraintes de fenêtre
|
||||
- Vérifier texte requis présent
|
||||
- Vérifier éléments UI requis présents
|
||||
- Vérifier similarité embedding > seuil
|
||||
- Retourner (match: bool, confidence: float)
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5_
|
||||
|
||||
- [ ]* 5.11 Écrire tests d'intégration pour workflow complet
|
||||
- Tester construction depuis session → matching
|
||||
- Vérifier graphe construit correctement
|
||||
- Vérifier matching fonctionne sur nouveaux états
|
||||
|
||||
- [ ] 6. Checkpoint - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
|
||||
|
||||
- [x] 6. Phase 6 : Action Execution ✅ COMPLÉTÉ (23 Nov 2024)
|
||||
- Exécuter automatiquement les workflows construits
|
||||
- Résoudre targets par rôle sémantique
|
||||
- Vérifier post-conditions
|
||||
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 15.4_
|
||||
|
||||
- [x] 6.1 Créer ActionExecutor pour exécution d'actions
|
||||
- Créer classe `ActionExecutor` dans `rpa_vision_v3/core/execution/action_executor.py`
|
||||
- Implémenter méthode `execute_edge()`
|
||||
- Vérifier pre-conditions avant exécution
|
||||
- Intégrer avec pyautogui pour automation
|
||||
- _Requirements: 10.5_
|
||||
|
||||
- [x] 6.2 Créer TargetResolver pour résolution de targets
|
||||
- Créer classe `TargetResolver` dans `rpa_vision_v3/core/execution/target_resolver.py`
|
||||
- Implémenter méthode `resolve_target()`
|
||||
- Supporter résolution by_role, by_text, by_position
|
||||
- Gérer fallback strategies
|
||||
- _Requirements: 10.1_
|
||||
|
||||
- [x] 6.3 Implémenter recherche d'éléments par rôle sémantique
|
||||
- Ajouter méthode `_find_by_role()` dans TargetResolver
|
||||
- Chercher UIElements par rôle dans ScreenState
|
||||
- Appliquer selection_policy (first, last, by_similarity)
|
||||
- Implémenter fallback par similarité visuelle
|
||||
- _Requirements: 10.1_
|
||||
|
||||
- [x] 6.4 Implémenter exécution d'actions mouse_click
|
||||
- Ajouter méthode `_execute_click()` dans ActionExecutor
|
||||
- Cliquer au centre de l'UIElement trouvé
|
||||
- Appliquer click_offset si configuré
|
||||
- Attendre wait_after_ms
|
||||
- Logger action exécutée
|
||||
- _Requirements: 10.2_
|
||||
|
||||
- [x] 6.5 Implémenter exécution d'actions text_input
|
||||
- Ajouter méthode `_execute_text_input()` dans ActionExecutor
|
||||
- Taper texte dans l'UIElement trouvé
|
||||
- Gérer caractères spéciaux
|
||||
- Attendre wait_after_ms
|
||||
- Logger action exécutée
|
||||
- _Requirements: 10.3_
|
||||
|
||||
- [x] 6.6 Implémenter exécution d'actions compound
|
||||
- Ajouter méthode `_execute_compound()` dans ActionExecutor
|
||||
- Exécuter séquence d'actions
|
||||
- Gérer repeat policies (all, until_success)
|
||||
- Logger chaque sous-action
|
||||
- _Requirements: 10.4_
|
||||
|
||||
- [x] 6.7 Implémenter vérification de post-conditions
|
||||
- Ajouter méthode `_verify_postconditions()` dans ActionExecutor
|
||||
- Attendre changement de fenêtre si requis
|
||||
- Attendre nouveaux éléments UI si requis
|
||||
- Vérifier transition vers node attendu
|
||||
- Timeout si post-conditions non satisfaites
|
||||
- Logger résultat de vérification
|
||||
- _Requirements: 10.6_
|
||||
|
||||
- [ ]* 6.8 Écrire tests unitaires pour ActionExecutor
|
||||
- Tester recherche d'éléments par rôle
|
||||
- Tester exécution de chaque type d'action
|
||||
- Tester vérification de post-conditions
|
||||
- **Property 8: WorkflowEdge Pre-Condition Validation**
|
||||
- **Property 15: Action Execution Timeout**
|
||||
- **Validates: Requirements 10.5, 10.6**
|
||||
|
||||
- [ ]* 6.9 Écrire tests de performance pour exécution
|
||||
- Benchmarker temps d'exécution (cible: <50ms)
|
||||
- **Validates: Requirements 15.4**
|
||||
|
||||
- [x] 6.10 Créer exemple d'exécution end-to-end
|
||||
- Créer script `rpa_vision_v3/examples/test_phase6_simple.py`
|
||||
- Tester exécution complète d'un workflow
|
||||
- Valider avec workflow réel capturé
|
||||
- Logger toutes les étapes
|
||||
|
||||
- [ ] 7. Checkpoint - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 8. Phase 7 : Learning System ✅ COMPLÉTÉ (23 Nov 2024)
|
||||
- Gérer états d'apprentissage
|
||||
- Implémenter transitions automatiques
|
||||
- Système de feedback
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6_
|
||||
|
||||
- [x] 8.1 Implémenter LearningManager pour états d'apprentissage
|
||||
- Créer classe `LearningManager` dans `rpa_vision_v3/core/learning/learning_manager.py`
|
||||
- Gérer dictionnaire de workflows
|
||||
- Implémenter méthode `update_workflow_stats()`
|
||||
- _Requirements: 8.5_
|
||||
|
||||
- [x] 8.2 Implémenter transitions d'états d'apprentissage
|
||||
- Ajouter méthode `_check_state_transition()` dans LearningManager
|
||||
- Implémenter `_can_transition_to_coaching()` (5 observations, similarité >0.90)
|
||||
- Implémenter `_can_transition_to_auto_candidate()` (10 assists, succès >0.90)
|
||||
- Implémenter `_can_transition_to_auto_confirmed()` (20 exécutions, succès >0.95)
|
||||
- Logger toutes les transitions avec raison
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
|
||||
|
||||
- [x] 8.3 Implémenter rollback automatique
|
||||
- Ajouter méthode `_should_rollback()` dans LearningManager
|
||||
- Détecter confiance < 0.90 en mode AUTO_CONFIRMÉ
|
||||
- Rétrograder vers COACHING
|
||||
- Logger le rollback
|
||||
- _Requirements: 8.6_
|
||||
|
||||
- [x] 8.4 Implémenter FeedbackProcessor
|
||||
- Créer classe `FeedbackProcessor` dans `rpa_vision_v3/core/learning/feedback_processor.py`
|
||||
- Traiter feedback utilisateur (CORRECT, INCORRECT, PARTIAL, SKIP)
|
||||
- Générer suggestions d'amélioration
|
||||
- Calculer statistiques et accuracy
|
||||
- _Requirements: 8.5_
|
||||
|
||||
- [ ]* 8.5 Écrire tests pour LearningManager
|
||||
- Tester transitions d'états
|
||||
- Tester calcul de métriques
|
||||
- Tester rollback
|
||||
- **Property 9: Learning State Monotonic Progression**
|
||||
- **Property 10: Learning State Rollback Condition**
|
||||
- **Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.6**
|
||||
|
||||
- [ ]* 8.6 Écrire tests d'intégration pour apprentissage complet
|
||||
- Simuler 5 observations → COACHING
|
||||
- Simuler 10 assists → AUTO_CANDIDATE
|
||||
- Simuler 20 exécutions → AUTO_CONFIRMÉ
|
||||
- Simuler baisse de confiance → rollback
|
||||
|
||||
- [ ] 9. Phase 8 : Training System - Apprentissage Offline
|
||||
- Collecter données d'entraînement
|
||||
- Entraîner modèles offline
|
||||
- Valider avant production
|
||||
- _Requirements: Custom (new phase)_
|
||||
|
||||
- [x] 9.1 Implémenter TrainingDataCollector
|
||||
- Créer classe `TrainingDataCollector` dans `rpa_vision_v3/core/training/training_data_collector.py`
|
||||
- Enregistrer sessions, actions, screenshots, embeddings
|
||||
- Gérer corrections utilisateur
|
||||
- Export en JSON structuré
|
||||
|
||||
- [x] 9.2 Implémenter OfflineTrainer
|
||||
- Créer classe `OfflineTrainer` dans `rpa_vision_v3/core/training/offline_trainer.py`
|
||||
- Entraîner prototypes de workflows
|
||||
- Optimiser seuils de similarité
|
||||
- Validation croisée
|
||||
- Export modèle entraîné
|
||||
|
||||
- [x] 9.3 Implémenter ModelValidator
|
||||
- Créer classe `ModelValidator` dans `rpa_vision_v3/core/training/model_validator.py`
|
||||
- Valider modèle avant production
|
||||
- Calculer métriques (accuracy, precision, recall, F1)
|
||||
- Comparaison avec baseline
|
||||
- Recommandations de déploiement
|
||||
|
||||
- [x] 9.4 Créer guide d'utilisation Training System
|
||||
- Créer `rpa_vision_v3/TRAINING_GUIDE.md`
|
||||
- Documenter workflow en 4 phases
|
||||
- Exemples de code complets
|
||||
- Bonnes pratiques
|
||||
- Troubleshooting
|
||||
|
||||
- [x] 9.5 Créer tests Training System
|
||||
- Créer `rpa_vision_v3/examples/test_training_system.py`
|
||||
- Tester TrainingDataCollector
|
||||
- Tester OfflineTrainer
|
||||
- Tester ModelValidator
|
||||
- Tester workflow complet
|
||||
|
||||
- [ ] 10. Checkpoint - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Créer classe `ActionExecutor` dans `geniusia2/core/graph/action_executor.py`
|
||||
- Implémenter méthode `execute_edge()`
|
||||
- Vérifier pre-conditions avant exécution
|
||||
- _Requirements: 10.5_
|
||||
|
||||
- [ ] 7.2 Implémenter recherche d'éléments par rôle sémantique
|
||||
- Ajouter méthode `_find_target_element()` dans ActionExecutor
|
||||
- Chercher UIElements par rôle dans ScreenState
|
||||
- Appliquer selection_policy (first, last, by_similarity)
|
||||
- Implémenter fallback strategies
|
||||
- _Requirements: 10.1_
|
||||
|
||||
- [ ] 7.3 Implémenter exécution d'actions mouse_click
|
||||
- Ajouter méthode `_execute_click()` dans ActionExecutor
|
||||
- Cliquer au centre de l'UIElement trouvé
|
||||
- Appliquer click_offset si configuré
|
||||
- Attendre wait_after_ms
|
||||
- _Requirements: 10.2_
|
||||
|
||||
- [ ] 7.4 Implémenter exécution d'actions text_input
|
||||
- Ajouter méthode `_execute_text_input()` dans ActionExecutor
|
||||
- Taper texte dans l'UIElement trouvé
|
||||
- Gérer caractères spéciaux
|
||||
- _Requirements: 10.3_
|
||||
|
||||
- [ ] 7.5 Implémenter exécution d'actions compound
|
||||
- Ajouter méthode `_execute_compound()` dans ActionExecutor
|
||||
- Exécuter séquence d'actions
|
||||
- Gérer repeat policies (all, until_success)
|
||||
- _Requirements: 10.4_
|
||||
|
||||
- [ ] 7.6 Implémenter vérification de post-conditions
|
||||
- Ajouter méthode `_wait_for_postconditions()` dans ActionExecutor
|
||||
- Attendre changement de fenêtre si requis
|
||||
- Attendre nouveaux éléments UI si requis
|
||||
- Vérifier transition vers node attendu
|
||||
- Timeout si post-conditions non satisfaites
|
||||
- _Requirements: 10.6_
|
||||
|
||||
- [ ]* 7.7 Écrire tests unitaires pour ActionExecutor
|
||||
- Tester recherche d'éléments par rôle
|
||||
- Tester exécution de chaque type d'action
|
||||
- Tester vérification de post-conditions
|
||||
- **Property 8: WorkflowEdge Pre-Condition Validation**
|
||||
- **Property 15: Action Execution Timeout**
|
||||
- **Validates: Requirements 10.5, 10.6**
|
||||
|
||||
- [ ]* 7.8 Écrire tests de performance pour exécution
|
||||
- Benchmarker temps d'exécution (cible: <50ms)
|
||||
- **Validates: Requirements 15.4**
|
||||
|
||||
- [ ] 7.9 Implémenter LearningManager pour états d'apprentissage
|
||||
- Créer classe `LearningManager` dans `geniusia2/core/graph/learning_manager.py`
|
||||
- Gérer dictionnaire de workflows
|
||||
- Implémenter méthode `update_workflow_stats()`
|
||||
- _Requirements: 8.5_
|
||||
|
||||
- [ ] 8.2 Implémenter transitions d'états d'apprentissage
|
||||
- Ajouter méthode `_check_state_transition()` dans LearningManager
|
||||
- Implémenter `_can_transition_to_coaching()` (5 observations, similarité >0.90)
|
||||
- Implémenter `_can_transition_to_auto_candidate()` (10 assists, succès >0.90)
|
||||
- Implémenter `_can_transition_to_auto_confirmed()` (20 exécutions, succès >0.95)
|
||||
- Logger toutes les transitions avec raison
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
|
||||
|
||||
- [ ] 8.3 Implémenter rollback automatique
|
||||
- Ajouter méthode `_should_rollback()` dans LearningManager
|
||||
- Détecter confiance < 0.90 en mode AUTO_CONFIRMÉ
|
||||
- Rétrograder vers COACHING
|
||||
- Logger le rollback
|
||||
- _Requirements: 8.6_
|
||||
|
||||
- [ ]* 8.4 Écrire tests pour LearningManager
|
||||
- Tester transitions d'états
|
||||
- Tester calcul de métriques
|
||||
- Tester rollback
|
||||
- **Property 9: Learning State Monotonic Progression**
|
||||
- **Property 10: Learning State Rollback Condition**
|
||||
- **Validates: Requirements 8.1, 8.2, 8.3, 8.4, 8.6**
|
||||
|
||||
- [ ]* 8.5 Écrire tests d'intégration pour apprentissage complet
|
||||
- Simuler 5 observations → COACHING
|
||||
- Simuler 10 assists → AUTO_CANDIDATE
|
||||
- Simuler 20 exécutions → AUTO_CONFIRMÉ
|
||||
- Simuler baisse de confiance → rollback
|
||||
|
||||
- [ ] 9. Checkpoint - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 10. Phase 8 : Gestion des Erreurs et Robustesse ✅ COMPLÉTÉ (24 Nov 2024)
|
||||
- Gérer échecs de matching
|
||||
- Gérer échecs de détection
|
||||
- Gérer violations de post-conditions
|
||||
- Détecter changements d'UI
|
||||
- _Requirements: 14.1, 14.2, 14.3, 14.4, 14.5, 14.6_
|
||||
|
||||
- [x] 9.1 Implémenter gestion d'échecs de matching ✅ COMPLÉTÉ
|
||||
- Créé ErrorHandler centralisé dans core/execution/error_handler.py
|
||||
- Logging détaillé avec screenshots et embeddings
|
||||
- Calcul similarité avec tous les nodes candidats
|
||||
- Génération suggestions automatiques (CREATE_NEW_NODE, UPDATE_NODE, ADJUST_THRESHOLD)
|
||||
- Tracking des edges problématiques (>3 échecs)
|
||||
- _Requirements: 14.1_
|
||||
|
||||
- [x] 9.2 Implémenter stratégies de fallback pour détection UI
|
||||
- Ajouter fallback par visual similarity dans ActionExecutor
|
||||
- Ajouter fallback par position approximative
|
||||
- Logger tentatives de fallback
|
||||
- _Requirements: 14.2_
|
||||
|
||||
- [x] 9.3 Implémenter gestion de violations de post-conditions
|
||||
- Logger violations avec détails (attendu vs réel)
|
||||
- Attendre timeout configuré
|
||||
- Marquer exécution comme échec si timeout
|
||||
- Incrémenter compteur d'échecs pour edge
|
||||
- Marquer edge comme problématique si échecs répétés (>3)
|
||||
- _Requirements: 14.3_
|
||||
|
||||
- [x] 9.4 Implémenter détection de changements d'UI
|
||||
- Ajouter méthode `detect_ui_change()` dans NodeMatcher
|
||||
- Comparer similarité actuelle vs prototype
|
||||
- Détecter changement si similarité < 0.70
|
||||
- Capturer screenshot pour analyse
|
||||
- Mettre en pause exécution automatique
|
||||
- Notifier utilisateur
|
||||
- _Requirements: 14.4_
|
||||
|
||||
- [x] 9.5 Implémenter système de rollback
|
||||
- Ajouter méthode `rollback()` dans ActionExecutor
|
||||
- Stocker historique des 3 dernières actions
|
||||
- Implémenter inverse pour chaque type d'action
|
||||
- Logger tentatives de rollback
|
||||
- _Requirements: 14.5_
|
||||
|
||||
- [ ]* 9.6 Écrire tests pour gestion d'erreurs
|
||||
- Tester échec de matching
|
||||
- Tester échec de détection UI
|
||||
- Tester violation de post-conditions
|
||||
- Tester détection de changement UI
|
||||
- Tester rollback
|
||||
|
||||
- [x] 10. Phase 7 : Persistence et Storage
|
||||
- Implémenter sauvegarde structurée
|
||||
- Implémenter chargement avec validation
|
||||
- Organiser fichiers par date et workflow
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7_
|
||||
|
||||
- [x] 10.1 Implémenter StorageManager pour gestion de fichiers
|
||||
- Créer classe `StorageManager` dans `geniusia2/core/persistence/storage_manager.py`
|
||||
- Implémenter méthode `save_raw_session()`
|
||||
- Implémenter méthode `save_screen_state()`
|
||||
- Implémenter méthode `save_workflow()`
|
||||
- Organiser par date (YYYY-MM-DD)
|
||||
- _Requirements: 12.1, 12.2, 12.4, 12.7_
|
||||
|
||||
- [x] 10.2 Implémenter sauvegarde d'embeddings
|
||||
- Ajouter méthode `save_embedding()` dans StorageManager
|
||||
- Sauvegarder vecteurs en .npy
|
||||
- Ajouter à FAISS index
|
||||
- Sauvegarder métadonnées
|
||||
- _Requirements: 12.2, 12.3_
|
||||
|
||||
- [x] 10.3 Implémenter chargement avec validation
|
||||
- Ajouter méthode `load_workflow()` dans StorageManager
|
||||
- Valider schéma JSON
|
||||
- Charger FAISS index
|
||||
- Charger métadonnées
|
||||
- Reconstruire objets Python
|
||||
- _Requirements: 12.5, 12.6_
|
||||
|
||||
- [x]* 10.4 Écrire tests pour persistence
|
||||
- Tester sauvegarde/chargement de tous les types
|
||||
- Tester organisation de fichiers
|
||||
- Tester validation de schémas
|
||||
|
||||
- [-] 11. Phase 8 : Optimisation et Performance
|
||||
- Optimiser embeddings (batching, caching)
|
||||
- Optimiser FAISS (IVF index)
|
||||
- Optimiser détection UI (ROI)
|
||||
- Mesurer et valider performances
|
||||
- _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5_
|
||||
|
||||
- [x] 11.1 Implémenter batch processing pour embeddings
|
||||
- Ajouter méthode `compute_embeddings_batch()` dans FusionEngine
|
||||
- Traiter multiples images en parallèle
|
||||
- Optimiser utilisation GPU si disponible
|
||||
|
||||
- [x] 11.2 Implémenter caching d'embeddings
|
||||
- Ajouter cache LRU pour prototypes
|
||||
- Mettre en cache derniers State Embeddings
|
||||
- Invalider cache intelligemment
|
||||
|
||||
- [x] 11.3 Optimiser FAISS avec index IVF
|
||||
- Migrer vers index IVF pour >10k embeddings
|
||||
- Optimiser périodiquement l'index
|
||||
- Utiliser GPU si disponible
|
||||
|
||||
- [x] 11.4 Optimiser détection UI avec ROI
|
||||
- Limiter résolution des screenshots (max 1920x1080)
|
||||
- Détecter régions d'intérêt avant traitement complet
|
||||
- Mettre en cache résultats pour frames similaires
|
||||
|
||||
- [x]* 11.5 Écrire tests de performance complets
|
||||
- Benchmarker toutes les opérations
|
||||
- Valider contraintes de temps
|
||||
- **Property 19: Performance Constraint - State Embedding**
|
||||
- **Property 20: Performance Constraint - End-to-End**
|
||||
- **Validates: Requirements 15.1, 15.2, 15.3, 15.4, 15.5**
|
||||
|
||||
- [x] 12. Checkpoint Final - Vérifier que tous les tests passent
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [ ] 13. Phase 9 : Tests End-to-End et Documentation
|
||||
- Tests de bout en bout complets
|
||||
- Documentation utilisateur
|
||||
- Guide de déploiement
|
||||
|
||||
- [ ] 13.1 Créer tests end-to-end pour workflow complet
|
||||
- Tester capture → construction → matching → exécution
|
||||
- Tester apprentissage progressif complet
|
||||
- Tester robustesse aux changements UI
|
||||
- Tester multi-workflows
|
||||
|
||||
- [ ]* 13.2 Écrire tests de validation de qualité
|
||||
- Tester qualité des embeddings
|
||||
- **Property 13: UIElement Role Uniqueness Per Type**
|
||||
- **Validates: Requirements 13.1, 13.2, 13.3, 13.4, 13.5**
|
||||
|
||||
- [ ] 13.3 Créer documentation utilisateur
|
||||
- Guide de démarrage rapide
|
||||
- Guide d'utilisation des 5 couches
|
||||
- Exemples de workflows
|
||||
- FAQ et troubleshooting
|
||||
|
||||
- [ ] 13.4 Créer guide de déploiement
|
||||
- Instructions d'installation
|
||||
- Configuration requise
|
||||
- Configuration des modèles
|
||||
- Optimisation de production
|
||||
Reference in New Issue
Block a user