rpa_vision_v3/.kiro/specs/rpa-vision-excellence/tasks.md

Plan d'Implémentation

Phase 1 : Validateur de Qualité d'Entraînement

• 1. Implémenter le cœur du Validateur de Qualité

  • 1.1 Créer core/training/quality_validator.py avec la classe TrainingQualityValidator
    • Implémenter la méthode validate_workflow() retournant QualityReport
    • Implémenter compute_cluster_metrics() utilisant sklearn silhouette_score
    • Créer les dataclasses QualityReport et ClusterMetrics
    • Exigences : 1.1, 1.4
  • * 1.2 Écrire le test property pour la cohérence de qualité des clusters
    • Propriété 1 : Cohérence de la Qualité des Clusters
    • Valide : Exigences 1.1
  • 1.3 Implémenter la détection d'outliers avec méthode IQR
    • Créer la méthode detect_outliers() avec seuil IQR 1.5
    • Retourner les indices des embeddings outliers
    • Exigences : 1.3
  • * 1.4 Écrire le test property pour la détection d'outliers
    • Propriété 2 : Correction de la Détection d'Outliers
    • Valide : Exigences 1.3
  • 1.5 Implémenter la validation croisée pour la qualité du workflow
    • Créer la méthode cross_validate() avec ratio holdout configurable
    • Calculer la précision de match sur les observations retenues
    • Exigences : 1.5
  • * 1.6 Écrire le test property pour la validation croisée
    • Propriété 3 : Précision de la Validation Croisée
    • Valide : Exigences 1.5

• 2. Intégrer le Validateur de Qualité avec GraphBuilder

  • 2.1 Modifier core/graph/graph_builder.py pour appeler le validateur après création du workflow
    • Ajouter l'étape de validation de qualité dans build_from_session()
    • Stocker les métriques de qualité dans les métadonnées du workflow
    • Exigences : 1.1, 1.2
  • 2.2 Ajouter les restrictions d'état basées sur la qualité
    • Empêcher la transition AUTO_CANDIDATE si qualité < 0.7
    • Marquer les clusters à faible confiance dans le workflow
    • Exigences : 1.2, 1.4

• 3. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 2 : Matcher Hiérarchique

• 4. Implémenter le cœur du Matcher Hiérarchique

  • 4.1 Créer core/matching/hierarchical_matcher.py avec la classe HierarchicalMatcher
    • Implémenter la méthode match() retournant MatchResult
    • Créer les dataclasses MatchResult et TemporalContext
    • Exigences : 2.1, 2.2, 2.3
  • 4.2 Implémenter le matching niveau fenêtre
    • Créer match_window_level() comparant pattern de titre et processus
    • Retourner un score de confiance 0.0-1.0
    • Exigences : 2.1
  • 4.3 Implémenter le matching niveau région
    • Créer match_region_level() comparant les régions UI
    • Utiliser IoU et similarité d'embedding pour le matching de régions
    • Exigences : 2.2
  • 4.4 Implémenter le matching niveau élément
    • Créer match_element_level() comparant les éléments individuels
    • Utiliser rôle, texte et similarité visuelle
    • Exigences : 2.3
  • 4.5 Implémenter la formule de combinaison de confiance
    • Combiner : 0.2fenêtre + 0.3région + 0.5*élément
    • Exigences : 2.4
  • * 4.6 Écrire le test property pour les bornes de confiance
    • Propriété 4 : Bornes de Confiance Hiérarchique
    • Valide : Exigences 2.4
  • 4.7 Implémenter le boost de contexte temporel
    • Augmenter la confiance de 0.1 pour les nodes successeurs valides
    • Plafonner la confiance finale à 1.0
    • Exigences : 2.5
  • * 4.8 Écrire le test property pour le boost temporel
    • Propriété 5 : Correction du Boost Temporel
    • Valide : Exigences 2.5

• 5. Intégrer le Matcher Hiérarchique avec le Pipeline

  • 5.1 Modifier core/pipeline/workflow_pipeline.py pour utiliser HierarchicalMatcher
    • Remplacer le matching FAISS simple par l'approche hiérarchique
    • Maintenir le contexte temporel entre les matchs
    • Exigences : 2.1, 2.2, 2.3, 2.4, 2.5

• 6. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 3 : Apprenant Continu

• 7. Implémenter le cœur de l'Apprenant Continu

  • 7.1 Créer core/learning/continuous_learner.py avec la classe ContinuousLearner
    • Implémenter update_prototype() avec EMA (alpha=0.1)
    • Créer la dataclass DriftStatus
    • Exigences : 3.1
  • * 7.2 Écrire le test property pour la mise à jour EMA du prototype
    • Propriété 6 : Mise à Jour du Prototype par EMA
    • Valide : Exigences 3.1
  • 7.3 Implémenter la détection de dérive
    • Créer detect_drift() suivant les matchs consécutifs à faible confiance
    • Signaler la dérive après 3 matchs consécutifs sous 0.85
    • Exigences : 3.2
  • * 7.4 Écrire le test property pour la détection de dérive
    • Propriété 7 : Seuil de Détection de Dérive
    • Valide : Exigences 3.2
  • 7.5 Implémenter la création de variante sur dérive
    • Créer create_variant() pour les nouvelles variantes UI
    • Stocker l'embedding de variante séparément
    • Exigences : 3.3
  • 7.6 Implémenter la consolidation des variantes
    • Créer consolidate_variants() quand les variantes dépassent 5
    • Re-clusteriser les variantes pour réduire le nombre
    • Exigences : 3.4

• 8. Implémenter le Gestionnaire de Versions de Prototypes

  • 8.1 Créer core/learning/prototype_version_manager.py
    • Implémenter save_version(), get_version(), list_versions()
    • Stocker les versions comme fichiers .npy avec métadonnées
    • Exigences : 3.5
  • 8.2 Implémenter la fonctionnalité de rollback
    • Créer rollback_prototype() pour restaurer une version précédente
    • Mettre à jour l'index FAISS lors du rollback
    • Exigences : 3.5

• 9. Intégrer l'Apprenant Continu avec la Boucle d'Exécution

  • 9.1 Modifier core/execution/execution_loop.py pour appeler l'apprenant
    • Mettre à jour le prototype après exécution réussie
    • Vérifier la dérive après chaque match
    • Exigences : 3.1, 3.2

• 10. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 4 : Gestionnaire de Variantes

• 11. Implémenter le cœur du Gestionnaire de Variantes

  • 11.1 Créer core/variants/variant_manager.py avec la classe VariantManager
    • Implémenter detect_variants() utilisant le clustering par similarité
    • Créer les dataclasses VariantCluster et NodeVariant
    • Exigences : 4.1
  • 11.2 Implémenter le matching avec variantes
    • Créer match_with_variants() retournant le meilleur match de variante
    • Comparer contre toutes les variantes, retourner la plus haute similarité
    • Exigences : 4.3
  • * 11.3 Écrire le test property pour le seuil de similarité des variantes
    • Propriété 8 : Seuil de Similarité des Variantes
    • Valide : Exigences 4.2
  • * 11.4 Écrire le test property pour la sélection de la meilleure variante
    • Propriété 9 : Sélection de la Meilleure Variante
    • Valide : Exigences 4.3
  • 11.5 Implémenter la détection d'états UI
    • Créer detect_ui_states() analysant les caractéristiques visuelles
    • Détecter : états activé, désactivé, coché, chargement, erreur
    • Exigences : 4.4
  • 11.6 Implémenter la détection d'overlay
    • Créer detect_overlay() comparant l'écran actuel vs baseline
    • Identifier les overlays modal, popup, tooltip, dropdown
    • Exigences : 4.5

• 12. Améliorer le modèle WorkflowNode

  • 12.1 Mettre à jour core/models/workflow_graph.py avec support des variantes
    • Ajouter les champs variants list, primary_variant_id, quality_score
    • Ajouter les champs prototype_version et prototype_history
    • Exigences : 4.1, 4.2, 4.3

• 13. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 5 : Compréhension UI Avancée

• 14. Implémenter les Relations Spatiales

  • 14.1 Créer core/detection/spatial_analyzer.py avec la classe SpatialAnalyzer
    • Implémenter compute_relations() entre éléments UI
    • Supporter : relations au-dessus, en-dessous, à_gauche_de, à_droite_de, à_l'intérieur
    • Exigences : 5.1
  • * 14.2 Écrire le test property pour la symétrie des relations spatiales
    • Propriété 10 : Symétrie des Relations Spatiales
    • Valide : Exigences 5.1
  • 14.3 Implémenter la détection de conteneurs sémantiques
    • Créer detect_containers() groupant les éléments liés
    • Identifier : conteneurs formulaire, menu, barre d'outils, dialogue, liste
    • Exigences : 5.2

• 15. Améliorer le Target Resolver avec fallback spatial

  • 15.1 Modifier core/execution/target_resolver.py pour utiliser les relations spatiales
    • Ajouter la stratégie de fallback par relation spatiale
    • Utiliser les éléments ancres quand le match direct échoue
    • Exigences : 5.3, 5.4
  • 15.2 Ajouter la détection d'état visuel au matching d'éléments
    • Détecter activé/désactivé depuis couleur, opacité, bordure
    • Exigences : 5.5

• 16. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 6 : Qualité des Sessions d'Entraînement

• 17. Implémenter l'Analyseur de Session

  • 17.1 Créer core/training/session_analyzer.py avec la classe SessionAnalyzer
    • Implémenter analyze_session() retournant SessionQualityReport
    • Calculer le score de qualité depuis clarté, cohérence, timing
    • Exigences : 6.1
  • 17.2 Implémenter la détection de qualité des screenshots
    • Détecter faible contraste, flou, artefacts
    • Marquer les frames problématiques
    • Exigences : 6.2
  • 17.3 Implémenter l'analyse de timing
    • Détecter le timing d'action incohérent (>2x écart-type)
    • Identifier les transitions problématiques
    • Exigences : 6.3
  • 17.4 Implémenter la détection de doublons
    • Détecter les screenshots quasi-dupliqués
    • Suggérer l'optimisation de la fréquence de capture
    • Exigences : 6.4
  • 17.5 Générer des recommandations actionnables
    • Fournir des suggestions d'amélioration spécifiques
    • Exigences : 6.5

• 18. Point de contrôle - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.

Phase 7 : Robustesse d'Exécution

• 19. Améliorer le Moteur d'Exécution

  • 19.1 Implémenter le retry avec backoff exponentiel
    • Ajouter la logique de retry à l'exécution d'action
    • Utiliser le pattern temps_base * 2^(tentative-1)
    • Exigences : 7.1
  • * 19.2 Écrire le test property pour le backoff exponentiel
    • Propriété 11 : Backoff Exponentiel des Retries
    • Valide : Exigences 7.1
  • 19.3 Implémenter l'attente d'élément avec re-détection
    • Attendre jusqu'au timeout avec re-détection périodique
    • Exigences : 7.2
  • 19.4 Implémenter la récupération d'état
    • Re-matcher l'état actuel vers le graphe de workflow en cas d'échec
    • Trouver un chemin de récupération si possible
    • Exigences : 7.3
  • 19.5 Implémenter la gestion d'écran inconnu
    • Mettre en pause l'exécution sur écran inconnu
    • Demander guidance utilisateur avec contexte
    • Exigences : 7.4
  • 19.6 Implémenter les diagnostics détaillés d'échec
    • Logger screenshots, scores de match, stratégies
    • Exigences : 7.5

• 20. Point de contrôle final - Vérifier que tous les tests passent

  • Vérifier que tous les tests passent, demander à l'utilisateur si des questions se posent.