Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: replay E2E fonctionnel — 25/25 actions, 0 retries, SomEngine via serveur

Browse Source 
Validé sur PC Windows (DESKTOP-58D5CAC, 2560x1600) :
- 8 clics résolus visuellement (1 anchor_template, 1 som_text_match, 6 som_vlm)
- Score moyen 0.75, temps moyen 1.6s
- Texte tapé correctement (bonjour, test word, date, email)
- 0 retries, 2 actions non vérifiées (OK)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
2026-03-31 14:04:41 +02:00
parent 5e0b53cfd1
commit a7de6a488b
79542 changed files with 6091757 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

253
.kiro/specs/self-healing-workflows/design.md Normal file
View File

@@ -0,0 +1,253 @@
# Self-Healing Workflows Design Document
## Overview
This document specifies the design for an enhanced self-healing system for RPA Vision V3 that combines existing healing strategies with progressive tolerance relaxation during retries. The system enables workflows to automatically recover from failures by applying increasingly tolerant matching criteria and spatial search parameters.
## Architecture
The self-healing system consists of two main integration points:
1. **Target Resolver Healing Integration**: Progressive relaxation of matching criteria based on healing attempt counter
2. **Action Executor Retry Integration**: Activation of healing mode during retry loops with exponential backoff
### Core Components
```
┌─────────────────────────────────────────────────────────────────┐
│ Self-Healing Architecture │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ Action │ │ Target │ │ Healing │ │
│ │ Executor │ │ Resolver │ │ Profiles │ │
│ │ │ │ │ │ │ │
│ │ • Retry Loop │◄──►│ • healing_ │◄──►│ • min_ratio │ │
│ │ • Backoff │ │ attempt │ │ • pad_mul │ │
│ │ • Counter Mgmt │ │ • Role Aliases │ │ • expand_ │ │
│ │ │ │ • Fuzzy Thresh │ │ roles │ │
│ └─────────────────┘ └─────────────────┘ └─────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ Existing │ │ Spatial │ │ Metrics │ │
│ │ Healing │ │ Search │ │ Collection │ │
│ │ Strategies │ │ Enhancement │ │ │ │
│ │ │ │ │ │ • Success │ │
│ │ • Semantic │ │ • ROI Padding │ │ Rates │ │
│ │ • Spatial │ │ • Container │ │ • Attempt │ │
│ │ • Timing │ │ Detection │ │ Counts │ │
│ │ • Format │ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
## Components and Interfaces
### 1. Healing Profile System
The healing profile system provides progressive tolerance based on attempt count:
```python
@dataclass
class HealingProfile:
"""Configuration for healing attempt tolerance levels"""
min_ratio: float # Fuzzy matching threshold
pad_mul: float # Spatial padding multiplier
expand_roles: bool # Whether to use role aliases
attempt_level: int # Healing attempt level (0=strict, 1+=relaxed)
```
**Healing Profiles by Attempt Level:**
- **Level 0 (Normal)**: `min_ratio=0.82, pad_mul=1.0, expand_roles=False`
- **Level 1 (First Healing)**: `min_ratio=0.78, pad_mul=1.3, expand_roles=True`
- **Level 2+ (Desperate)**: `min_ratio=0.72, pad_mul=1.7, expand_roles=True`
### 2. Role Alias System
Semantic role expansion for more tolerant matching:
```python
ROLE_ALIASES = {
"input": {"input", "textfield", "text_field", "form_input", "forminput", "edit", "textbox"},
"button": {"button", "submit", "action", "cta"},
"label": {"label", "text", "data_display"},
"checkbox": {"checkbox", "check_box", "toggle"},
}
TYPE_ALIASES = {
"text_input": {"text_input", "input", "textfield"},
"button": {"button"},
}
```
### 3. Enhanced Target Resolver
The `TargetResolver` class is enhanced with healing capabilities:
```python
class TargetResolver:
def __init__(self):
self.healing_attempt = 0 # Healing attempt counter
def _healing_profile(self) -> Dict[str, Any]:
"""Get tolerance profile based on healing attempt level"""
def _find_element_by_text(self, text: str, ui_elements: List[UIElement],
min_ratio: float = 0.65) -> Optional[UIElement]:
"""Enhanced with configurable fuzzy threshold"""
def _resolve_by_role(self, role: str, ...) -> Optional[ResolvedTarget]:
"""Enhanced with role alias expansion"""
def _build_anchor_and_roi_and_container(self, target_spec, ui_elements):
"""Enhanced with configurable padding multipliers"""
```
### 4. Enhanced Action Executor
The `ActionExecutor` integrates healing during retry loops:
```python
class ActionExecutor:
def execute_edge(self, edge: WorkflowEdge, screen_state: ScreenState) -> ExecutionResult:
"""Enhanced with healing activation during retries"""
# Normal execution attempt
result = self._execute_action(edge.action, screen_state, context, edge)
# If failed and retries configured, activate healing
if result.status != ExecutionStatus.SUCCESS and retries > 0:
for i in range(retries):
# Apply exponential backoff
time.sleep((backoff_ms * (2 ** i)) / 1000.0)
# Activate healing attempt on resolver
self.target_resolver.healing_attempt = i + 1
try:
# Retry with healing active
result = self.execute_edge(edge, current_state)
finally:
# Always reset healing attempt
self.target_resolver.healing_attempt = 0
if result.status == ExecutionStatus.SUCCESS:
return result
```
## Data Models
### HealingAttemptMetrics
```python
@dataclass
class HealingAttemptMetrics:
"""Metrics for healing attempt tracking"""
attempt_level: int
success: bool
strategy_used: str
original_criteria: Dict[str, Any]
relaxed_criteria: Dict[str, Any]
duration_ms: float
timestamp: datetime
```
### ResolutionDetails Enhancement
The existing `ResolvedTarget.resolution_details` is enhanced with healing information:
```python
resolution_details = {
"healing_attempt": int, # Current healing attempt level
"healing_profile": Dict[str, Any], # Applied healing profile
"role_aliases_used": List[str], # Role aliases that were tried
"fuzzy_threshold_used": float, # Actual fuzzy threshold used
"spatial_padding_used": float, # Spatial padding multiplier used
}
```
## Correctness Properties
*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
### Property 1: Healing Attempt Progression
*For any* target resolution that fails initially, when healing attempts are incremented, the tolerance criteria should become progressively more relaxed
**Validates: Requirements 7.2, 7.3, 7.4**
### Property 2: Healing Counter Reset
*For any* successful action execution after healing attempts, the healing attempt counter should be reset to zero
**Validates: Requirements 8.4**
### Property 3: Role Alias Expansion
*For any* role-based target resolution with healing active, the system should accept elements matching role aliases when expand_roles is true
**Validates: Requirements 7.3**
### Property 4: Fuzzy Threshold Relaxation
*For any* text-based target resolution, the fuzzy matching threshold should decrease (become more tolerant) as healing attempt level increases
**Validates: Requirements 7.2**
### Property 5: Spatial Padding Expansion
*For any* spatial search operation during healing, the padding multiplier should increase the search area proportionally to the healing attempt level
**Validates: Requirements 7.4**
### Property 6: Backoff Timing Consistency
*For any* retry sequence with healing, the delay between attempts should follow exponential backoff pattern regardless of healing success
**Validates: Requirements 8.2**
### Property 7: Healing Metrics Recording
*For any* healing attempt, the system should record metrics including attempt level, success status, and applied criteria
**Validates: Requirements 7.5**
## Error Handling
### Healing Failure Scenarios
1. **Maximum Attempts Reached**: Log all attempted healing profiles and strategies
2. **Invalid Healing Configuration**: Fall back to strict matching with warning
3. **Role Alias Resolution Conflicts**: Use first successful match with preference logging
4. **Spatial Search Boundary Violations**: Clamp to screen boundaries with adjustment logging
### Recovery Strategies
1. **Graceful Degradation**: If healing system fails, continue with strict matching
2. **Profile Validation**: Validate healing profiles before application
3. **Counter Synchronization**: Ensure healing counter consistency across components
4. **Metrics Resilience**: Continue operation even if metrics collection fails
## Testing Strategy
### Unit Tests
- Test healing profile generation for different attempt levels
- Test role alias expansion logic
- Test fuzzy threshold adjustment
- Test spatial padding calculations
- Test healing counter management
### Property-Based Tests
- **Property 1**: Healing progression tolerance verification
- **Property 2**: Counter reset consistency
- **Property 3**: Role alias acceptance
- **Property 4**: Fuzzy threshold relaxation
- **Property 5**: Spatial padding expansion
- **Property 6**: Backoff timing verification
- **Property 7**: Metrics recording completeness
### Integration Tests
- End-to-end healing scenarios with UI changes
- Multi-attempt healing sequences
- Healing with existing self-healing strategies
- Performance impact measurement
- Cross-component healing coordination
### Performance Tests
- Healing overhead measurement (<1ms per attempt)
- Memory usage during extended healing sequences
- Concurrent healing attempt handling
- Cache interaction with healing profiles

108
.kiro/specs/self-healing-workflows/requirements.md Normal file
View File

@@ -0,0 +1,108 @@
# Requirements Document
## Introduction
Ce document spécifie les exigences pour un système de workflows auto-réparateurs (self-healing) pour RPA Vision V3. Le système permettra aux workflows de se corriger automatiquement en cas d'échec, en utilisant des stratégies de fallback intelligentes, l'apprentissage des corrections, et la mémorisation des solutions pour les exécutions futures.
## Glossary
- **Self-Healing Workflow**: Workflow capable de se corriger automatiquement en cas d'échec sans intervention humaine
- **Fallback Strategy**: Stratégie alternative utilisée quand l'approche principale échoue
- **Healing Action**: Action corrective appliquée pour résoudre un échec
- **Correction Memory**: Base de données des corrections appliquées avec succès
- **Semantic Variant**: Variante sémantique d'un élément UI (ex: "Submit" → "Envoyer" → "Valider")
- **Spatial Fallback**: Recherche d'éléments dans une zone élargie autour de la position attendue
- **Retry Policy**: Politique de réessai avec backoff exponentiel
- **Healing Context**: Contexte d'exécution incluant l'historique des tentatives et corrections
## Requirements
### Requirement 1
**User Story:** As a workflow executor, I want workflows to automatically try semantic variants when an element is not found, so that UI changes don't break automation.
#### Acceptance Criteria
1. WHEN an element match fails with the original description, THE Self-Healing System SHALL generate semantic variants of the description
2. WHEN semantic variants are generated, THE Self-Healing System SHALL attempt matching with each variant in order of semantic similarity
3. WHEN a semantic variant succeeds, THE Self-Healing System SHALL record the successful variant in Correction Memory
4. WHEN the same element is searched again, THE Self-Healing System SHALL prioritize previously successful variants
### Requirement 2
**User Story:** As a workflow executor, I want workflows to search in expanded spatial regions when elements move, so that layout changes don't break automation.
#### Acceptance Criteria
1. WHEN an element is not found at the expected position, THE Self-Healing System SHALL expand the search region incrementally
2. WHEN searching in expanded regions, THE Self-Healing System SHALL maintain a maximum search radius to avoid false positives
3. WHEN an element is found in an expanded region, THE Self-Healing System SHALL update the element position in the workflow
4. WHEN multiple candidates are found in expanded regions, THE Self-Healing System SHALL select the candidate with highest confidence score
### Requirement 3
**User Story:** As a workflow executor, I want workflows to retry failed actions with exponential backoff, so that temporary issues don't cause permanent failures.
#### Acceptance Criteria
1. WHEN an action fails, THE Self-Healing System SHALL retry the action according to the configured retry policy
2. WHEN retrying actions, THE Self-Healing System SHALL apply exponential backoff between attempts
3. WHEN the maximum retry count is reached, THE Self-Healing System SHALL escalate to alternative healing strategies
4. WHEN an action succeeds after retries, THE Self-Healing System SHALL log the number of attempts required
### Requirement 4
**User Story:** As a system administrator, I want corrections to be memorized and reused, so that the system learns from past fixes.
#### Acceptance Criteria
1. WHEN a healing action succeeds, THE Correction Memory SHALL store the correction with context including workflow_id, node_id, and original description
2. WHEN the same failure occurs again, THE Correction Memory SHALL retrieve applicable corrections ordered by success rate
3. WHEN a correction is reused successfully, THE Correction Memory SHALL increment its success counter
4. WHEN a correction fails, THE Correction Memory SHALL decrement its confidence score
### Requirement 5
**User Story:** As a workflow developer, I want healing strategies to be configurable per workflow, so that I can control the healing behavior.
#### Acceptance Criteria
1. WHEN a workflow is created, THE Self-Healing System SHALL allow configuration of enabled healing strategies
2. WHEN healing strategies are configured, THE Self-Healing System SHALL validate that strategy parameters are within acceptable ranges
3. WHEN a workflow executes, THE Self-Healing System SHALL apply only the enabled healing strategies in configured order
4. WHEN healing is disabled for a workflow, THE Self-Healing System SHALL execute without any healing attempts
### Requirement 6
**User Story:** As a system operator, I want to monitor healing effectiveness, so that I can optimize healing strategies.
#### Acceptance Criteria
1. WHEN healing actions are attempted, THE Self-Healing System SHALL record metrics including strategy used, success/failure, and duration
2. WHEN healing succeeds, THE Self-Healing System SHALL increment Prometheus counters for successful healings by strategy type
3. WHEN healing fails after all strategies, THE Self-Healing System SHALL log the failure with all attempted strategies
4. WHEN healing metrics are requested, THE Admin Dashboard SHALL display healing success rates by strategy and workflow
### Exigence 7
**Histoire utilisateur :** En tant que résolveur de cibles, je veux assouplir progressivement les critères de correspondance lors des tentatives, afin que les changements d'interface utilisateur ne cassent pas l'automatisation.
#### Critères d'acceptation
1. QUAND une correspondance d'élément échoue à la première tentative, LE Résolveur de Cibles DOIT maintenir des critères de correspondance stricts
2. QUAND le compteur de tentatives de guérison augmente, LE Résolveur de Cibles DOIT progressivement assouplir les seuils de correspondance floue
3. QUAND le compteur de tentatives de guérison augmente, LE Résolveur de Cibles DOIT étendre les alias de rôles pour inclure les variantes sémantiques
4. QUAND le compteur de tentatives de guérison augmente, LE Résolveur de Cibles DOIT augmenter les multiplicateurs de padding de recherche spatiale
5. QUAND la guérison réussit avec des critères assouplis, LE Résolveur de Cibles DOIT enregistrer le profil de guérison réussi
### Exigence 8
**Histoire utilisateur :** En tant qu'exécuteur d'actions, je veux activer le mode de guérison lors des tentatives, afin que les actions échouées puissent récupérer automatiquement.
#### Critères d'acceptation
1. QUAND une action échoue et qu'une nouvelle tentative est configurée, L'Exécuteur d'Actions DOIT incrémenter le compteur de tentatives de guérison sur le résolveur de cibles
2. QUAND une action est retentée, L'Exécuteur d'Actions DOIT appliquer un backoff exponentiel entre les tentatives
3. QUAND le compteur de tentatives de guérison est actif, LE Résolveur de Cibles DOIT utiliser des profils de correspondance progressivement plus tolérants
4. QUAND la nouvelle tentative réussit, L'Exécuteur d'Actions DOIT remettre à zéro le compteur de tentatives de guérison
5. QUAND le nombre maximum de tentatives est atteint, L'Exécuteur d'Actions DOIT enregistrer l'échec avec toutes les tentatives de guérison effectuées

223
.kiro/specs/self-healing-workflows/tasks.md Normal file
View File

@@ -0,0 +1,223 @@
# Plan d'Implémentation - Workflows Auto-Réparateurs
**Auteur :** Dom, Alice Kiro
**Date :** 15 décembre 2024
- [x] 1. Configurer la structure du module de guérison
- Créer le répertoire `core/healing/` avec ses sous-répertoires
- Définir les interfaces de base et les modèles de données
- _Exigences: Toutes_
- [x] 2. Implémenter les modèles de données
- [x] 2.1 Créer la dataclass RecoveryContext
- Définir tous les champs requis avec les types appropriés
- _Exigences: 1.1, 2.1, 3.1_
- [x] 2.2 Créer la dataclass RecoveryResult
- Définir les champs de résultat incluant success, new_element, strategy_used
- _Exigences: 1.3, 2.3, 3.4_
- [x] 2.3 Créer la dataclass RecoveryPattern
- Définir les champs de stockage des motifs
- _Exigences: 4.1, 4.2_
- [x] 3. Implémenter le Référentiel d'Apprentissage
- [x] 3.1 Créer la classe LearningRepository
- Implémenter le stockage et la récupération des motifs
- Persistance basée sur JSON
- _Exigences: 4.1, 4.2_
- [x] 3.2 Implémenter la logique de correspondance des motifs
- Faire correspondre les motifs par workflow_id, node_id et contexte
- _Exigences: 4.2_
- [x] 3.3 Implémenter le suivi des succès
- Incrémenter le compteur de succès lors de la réutilisation
- Décrémenter la confiance en cas d'échec
- _Exigences: 4.3, 4.4_
- [x]* 3.4 Écrire un test de propriété pour le stockage des motifs
- **Propriété 2: Stockage des motifs d'apprentissage**
- **Valide: Exigences 4.1**
- [x]* 3.5 Écrire un test de propriété pour la réutilisation des motifs
- **Propriété 5: Cohérence de la réutilisation des motifs**
- **Valide: Exigences 4.2, 4.3**
- [x]* 3.6 Écrire un test de propriété pour l'élagage
- **Propriété 10: Exactitude de l'élagage du référentiel**
- **Valide: Exigences 4.4**
- [x] 4. Implémenter le Calculateur de Confiance
- [x] 4.1 Créer la classe ConfidenceScorer
- Implémenter le calcul de similarité textuelle
- Implémenter le calcul de similarité de position
- _Exigences: 1.2, 2.4_
- [x] 4.2 Implémenter le scoring combiné
- Combiner le texte, la position et le succès historique
- _Exigences: 1.2, 2.4, 4.3_
- [x]* 4.3 Écrire un test de propriété pour la plage de confiance
- **Propriété 3: Validité du score de confiance**
- **Valide: Exigences 1.2, 2.4**
- [x]* 4.4 Écrire un test de propriété pour la similarité des éléments
- **Propriété 9: Validité du score de similarité des éléments**
- **Valide: Exigences 1.2, 2.4**
- [x] 5. Implémenter les Stratégies de Récupération
- [x] 5.1 Créer l'interface de base RecoveryStrategy
- Définir les méthodes can_handle et attempt_recovery
- _Exigences: 5.1, 5.3_
- [x] 5.2 Implémenter SemanticVariantsStrategy
- Générer des variantes sémantiques
- Essayer les variantes par ordre de similarité
- _Exigences: 1.1, 1.2, 1.3_
- [x] 5.3 Implémenter SpatialFallbackStrategy
- Étendre la région de recherche de manière incrémentale
- Sélectionner le meilleur candidat par confiance
- _Exigences: 2.1, 2.2, 2.3, 2.4_
- [x] 5.4 Implémenter TimingAdaptationStrategy
- Appliquer un backoff exponentiel
- Suivre les tentatives de retry
- _Exigences: 3.1, 3.2, 3.3, 3.4_
- [x] 5.5 Implémenter FormatTransformationStrategy
- Transformer les formats de date, téléphone et texte
- _Exigences: 1.1_
- [x] 6. Implémenter le Moteur de Guérison
- [x] 6.1 Créer la classe SelfHealingEngine
- Orchestrer les stratégies de récupération
- Prioriser basé sur le succès historique
- _Exigences: 5.1, 5.3_
- [x] 6.2 Implémenter la sélection de stratégie
- Filtrer les stratégies par can_handle
- Ordonner par taux de succès historique
- _Exigences: 5.3_
- [x] 6.3 Implémenter la boucle de tentative de récupération
- Essayer les stratégies jusqu'au succès ou épuisement
- Respecter la limite max_recovery_time
- _Exigences: 3.3, 5.3_
- [x] 6.4 Implémenter l'apprentissage du succès
- Stocker les motifs réussis
- Mettre à jour les scores de confiance
- _Exigences: 1.3, 4.1, 4.3_
- [x]* 6.5 Écrire un test de propriété pour les tentatives max
- **Propriété 1: Application des tentatives de récupération max**
- **Valide: Exigences 3.3**
- [x]* 6.6 Écrire un test de propriété pour les limites de temps
- **Propriété 4: Limites de temps de récupération**
- **Valide: Exigences 3.3**
- [x]* 6.7 Écrire un test de propriété pour l'apprentissage
- **Propriété 2: Apprentissage du succès**
- **Valide: Exigences 4.1, 4.3**
- [x] 7. Implémenter le Logger de Récupération
- [x] 7.1 Créer la classe RecoveryLogger
- Enregistrer toutes les tentatives de récupération
- Suivre les métriques par stratégie
- _Exigences: 6.1, 6.2, 6.3_
- [x] 7.2 Implémenter la collecte de métriques
- Compter les succès/échecs par stratégie
- Calculer les taux de succès
- _Exigences: 6.2_
- [x] 7.3 Implémenter la génération d'insights
- Générer des insights actionnables
- Identifier les motifs dans les échecs
- _Exigences: 6.4_
- [x] 7.4 Implémenter les alertes
- Détecter les échecs répétés
- Alerter sur les faibles taux de succès
- _Exigences: 6.3_
- [x]* 7.5 Écrire un test de propriété pour la complétude du logging
- **Propriété 8: Complétude du logging de récupération**
- **Valide: Exigences 6.1, 6.3**
- [x] 8. Implémenter l'Intégration d'Exécution
- [x] 8.1 Créer la classe SelfHealingIntegration
- Intégrer avec ExecutionLoop
- Gérer les échecs d'exécution
- _Exigences: Toutes_
- [x] 8.2 Implémenter les mises à jour de définition de workflow
- Mettre à jour le workflow avec les corrections réussies
- Persister les changements
- _Exigences: 1.4, 2.3_
- [x] 8.3 Implémenter la gestion de configuration
- Configuration de guérison par workflow
- Activation/désactivation de stratégie
- _Exigences: 5.1, 5.2, 5.3, 5.4_
- [x]* 8.4 Écrire un test de propriété pour les mises à jour de workflow
- **Propriété 6: Mises à jour de définition de workflow**
- **Valide: Exigences 1.4, 2.3**
- [x]* 8.5 Écrire un test de propriété pour les seuils de sécurité
- **Propriété 7: Application des seuils de sécurité**
- **Valide: Exigences 5.2**
- [x] 9. Créer la démo et la documentation
- [x] 9.1 Créer demo_self_healing.py
- Démontrer toutes les stratégies de guérison
- Montrer le monitoring et les insights
- _Exigences: Toutes_
- [x] 9.2 Créer SELF_HEALING_IMPLEMENTATION.md
- Documentation technique complète
- _Exigences: Documentation_
- [x] 9.3 Créer SELF_HEALING_QUICKSTART.md
- Guide de démarrage rapide
- _Exigences: Documentation_
- [ ] 10. Implémenter la Guérison Progressive dans Target Resolver (Fiche #10)
- [x] 10.1 Ajouter un compteur de tentatives de guérison au TargetResolver
- Initialiser le compteur healing_attempt dans __init__
- Créer la méthode _healing_profile() pour les niveaux de tolérance
- _Exigences: 7.1, 7.2_
- [x] 10.2 Implémenter le système d'alias de rôles
- Définir les constantes ROLE_ALIASES et TYPE_ALIASES
- Améliorer _resolve_by_role avec l'expansion d'alias
- _Exigences: 7.3_
- [x] 10.3 Améliorer la correspondance de texte floue
- Faire accepter à _find_element_by_text un min_ratio configurable
- Appliquer les seuils flous du profil de guérison
- _Exigences: 7.2, 7.4_
- [x] 10.4 Améliorer la recherche spatiale avec des multiplicateurs de padding
- Appliquer pad_mul aux calculs ROI dans _build_anchor_and_roi_and_container
- Mettre à l'échelle les zones de recherche spatiale basées sur la tentative de guérison
- _Exigences: 7.4_
- [x] 10.5 Ajouter des métadonnées de guérison aux détails de résolution
- Inclure healing_attempt, healing_profile dans ResolvedTarget
- Suivre les alias de rôles et les seuils utilisés
- _Exigences: 7.5_
- [ ]* 10.6 Écrire un test de propriété pour la progression de guérison
- **Propriété 1: Progression des tentatives de guérison**
- **Valide: Exigences 7.2, 7.3, 7.4**
- [ ]* 10.7 Écrire un test de propriété pour l'expansion d'alias de rôle
- **Propriété 3: Expansion d'alias de rôle**
- **Valide: Exigences 7.3**
- [x] 11. Implémenter l'Intégration de Guérison dans Action Executor (Fiche #10)
- [x] 11.1 Améliorer la boucle de retry avec activation de guérison
- Incrémenter target_resolver.healing_attempt pendant les retries
- Appliquer un backoff exponentiel entre les tentatives de guérison
- _Exigences: 8.1, 8.2, 8.3_
- [x] 11.2 Implémenter la gestion du compteur de guérison
- Réinitialiser healing_attempt à 0 en cas de succès
- Assurer un nettoyage approprié dans les blocs finally
- _Exigences: 8.4_
- [x] 11.3 Ajouter la collecte de métriques de guérison
- Enregistrer les niveaux de tentative de guérison et les résultats
- Enregistrer toutes les tentatives de guérison quand les retries max sont atteints
- _Exigences: 8.5_
- [ ]* 11.4 Écrire un test de propriété pour la réinitialisation du compteur
- **Propriété 2: Réinitialisation du compteur de guérison**
- **Valide: Exigences 8.4**
- [ ]* 11.5 Écrire un test de propriété pour le timing de backoff
- **Propriété 6: Cohérence du timing de backoff**
- **Valide: Exigences 8.2**
- [x] 12. Créer des tests de guérison complets
- [x] 12.1 Créer test_auto_healing_fiche10.py
- Tester les scénarios de progression de guérison
- Tester la résolution d'alias de rôle avec des doublons
- Tester la relaxation des seuils flous
- _Exigences: 7.1, 7.2, 7.3, 7.4_
- [x] 12.2 Créer des scénarios de test d'intégration
- Guérison de bout en bout avec changements d'UI
- Séquences de guérison multi-tentatives
- Mesure de l'impact sur les performances
- _Exigences: Toutes_
- [ ]* 12.3 Écrire un test de propriété pour les métriques de guérison
- **Propriété 7: Enregistrement des métriques de guérison**
- **Valide: Exigences 7.5**
- [x] 13. Point de contrôle final - S'assurer que tous les tests passent
- S'assurer que tous les tests passent, demander à l'utilisateur si des questions se posent.