a7de6a488b
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>
139 lines
8.8 KiB
Markdown
139 lines
8.8 KiB
Markdown
# Requirements Document
|
|
|
|
## Introduction
|
|
|
|
Système d'auto-healing hybride qui maintient la continuité de service tout en garantissant la sécurité. Le système continue à fonctionner tant que c'est sûr, ralentit et durcit les critères quand c'est flou, et s'arrête localement quand c'est dangereux.
|
|
|
|
## Glossary
|
|
|
|
- **Auto_Heal_Manager**: Gestionnaire central des états d'exécution et des politiques de sécurité
|
|
- **Circuit_Breaker**: Mécanisme anti-boucle qui surveille les échecs consécutifs
|
|
- **Versioned_Store**: Système de versioning pour l'apprentissage réversible
|
|
- **Execution_State**: État d'un workflow (RUNNING, DEGRADED, QUARANTINED, ROLLBACK, PAUSED)
|
|
- **Failure_Window**: Fenêtre glissante pour compter les échecs sur une période donnée
|
|
- **Confidence_Threshold**: Seuil de confiance pour les décisions d'exécution
|
|
|
|
## Requirements
|
|
|
|
### Requirement 1: États d'Exécution avec Machine d'État
|
|
|
|
**User Story:** En tant que système RPA, je veux gérer différents états d'exécution pour chaque workflow, afin de maintenir la continuité tout en garantissant la sécurité.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Auto_Heal_Manager SHALL maintain execution states for each workflow: RUNNING, DEGRADED, QUARANTINED, ROLLBACK, PAUSED
|
|
2. WHEN a workflow is in RUNNING state, THE Auto_Heal_Manager SHALL allow normal execution with standard confidence thresholds
|
|
3. WHEN a workflow transitions to DEGRADED state, THE Auto_Heal_Manager SHALL increase confidence thresholds and disable learning updates
|
|
4. WHEN a workflow is QUARANTINED, THE Auto_Heal_Manager SHALL prevent execution and create a FailureCase record
|
|
5. WHEN a workflow enters ROLLBACK state, THE Auto_Heal_Manager SHALL restore previous stable versions of prototypes and FAISS indices
|
|
6. WHEN a workflow is PAUSED, THE Auto_Heal_Manager SHALL halt execution until manual intervention
|
|
|
|
### Requirement 2: Circuit Breaker Anti-Boucle
|
|
|
|
**User Story:** En tant qu'administrateur système, je veux un mécanisme de circuit breaker pour éviter les boucles infinies d'échecs, afin de protéger la stabilité du système.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN 3 consecutive step failures occur, THE Circuit_Breaker SHALL transition the workflow to DEGRADED state
|
|
2. WHEN 10 failures occur within a 10-minute window for a workflow, THE Circuit_Breaker SHALL transition it to QUARANTINED state
|
|
3. WHEN 30 global failures occur within a 10-minute window, THE Circuit_Breaker SHALL optionally trigger system-wide PAUSE
|
|
4. WHEN a circuit breaker triggers, THE Auto_Heal_Manager SHALL create a FailureCase record with Fiche #19 integration
|
|
5. WHEN a circuit breaker triggers, THE Auto_Heal_Manager SHALL generate a mini report using Fiche #16 if scenario available
|
|
|
|
### Requirement 3: Mode Dégradé Conservateur
|
|
|
|
**User Story:** En tant que système RPA, je veux un mode dégradé qui continue l'exécution avec des critères plus stricts, afin de maintenir la continuité tout en réduisant les risques.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL increase min_confidence threshold by 0.1
|
|
2. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL enforce minimum top1-top2 margin for FAISS matches
|
|
3. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL disable learning updates (no prototype updates, no memory writes)
|
|
4. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL require hard_constraints if provided
|
|
5. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL refuse clicks if ambiguous flag is true
|
|
6. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL only proceed with clear and unambiguous targets
|
|
|
|
### Requirement 4: Apprentissage Réversible avec Rollback
|
|
|
|
**User Story:** En tant que système d'apprentissage, je veux pouvoir revenir à des versions stables précédentes, afin de récupérer d'une dégradation de performance causée par un mauvais apprentissage.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN consolidating prototypes, THE Versioned_Store SHALL create versioned snapshots in data/learning/prototypes/vNN/
|
|
2. WHEN updating FAISS indices, THE Versioned_Store SHALL version indices in data/faiss_index/workflow_<id>/vNN/
|
|
3. WHEN updating target memory, THE Versioned_Store SHALL create SQLite snapshots or WAL checkpoints
|
|
4. WHEN success rate drops by >20% over 50 steps after an update, THE Auto_Heal_Manager SHALL trigger automatic rollback
|
|
5. WHEN rollback is triggered, THE Versioned_Store SHALL restore prototypes, FAISS indices, and target memory to previous stable version
|
|
6. THE Versioned_Store SHALL maintain rollback capability to at least 5 previous versions
|
|
|
|
### Requirement 5: Stockage Hybride des Décisions
|
|
|
|
**User Story:** En tant que système d'audit, je veux un stockage hybride qui maintient la traçabilité complète tout en optimisant les performances, afin d'assurer la conformité et l'efficacité.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Auto_Heal_Manager SHALL write all decisions to JSONL format for complete audit trail
|
|
2. THE Auto_Heal_Manager SHALL write to SQLite only for validated successes (postconditions OK)
|
|
3. WHEN in DEGRADED mode, THE Auto_Heal_Manager SHALL NOT write success records to SQLite
|
|
4. THE Auto_Heal_Manager SHALL maintain decision metadata including confidence scores and execution state
|
|
5. THE Auto_Heal_Manager SHALL provide query interface for decision history and patterns
|
|
|
|
### Requirement 6: Configuration de Politique Flexible
|
|
|
|
**User Story:** En tant qu'administrateur, je veux configurer les seuils et politiques d'auto-healing, afin d'adapter le comportement aux besoins spécifiques de l'environnement.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Auto_Heal_Manager SHALL load configuration from data/config/auto_heal_policy.json
|
|
2. THE configuration SHALL include step failure thresholds, time windows, and confidence levels
|
|
3. THE configuration SHALL support different modes: hybrid, conservative, aggressive
|
|
4. THE configuration SHALL allow customization of degraded mode behavior and rollback triggers
|
|
5. WHEN configuration changes, THE Auto_Heal_Manager SHALL apply new settings without restart
|
|
|
|
### Requirement 7: Intégration avec Systèmes Existants
|
|
|
|
**User Story:** En tant que développeur, je veux que l'auto-healing s'intègre seamlessly avec les systèmes existants, afin de maintenir la compatibilité et réutiliser les fonctionnalités.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Auto_Heal_Manager SHALL integrate with Fiche #19 FailureCase recording for automatic capture
|
|
2. THE Auto_Heal_Manager SHALL integrate with Fiche #16 simulation reports when scenarios are available
|
|
3. THE Auto_Heal_Manager SHALL integrate with Fiche #18 persistent learning for rollback decisions
|
|
4. THE Auto_Heal_Manager SHALL integrate with Fiche #10 precision metrics for confidence scoring
|
|
5. THE Auto_Heal_Manager SHALL provide hooks in execution loop for should_execute_step() and on_step_result()
|
|
|
|
### Requirement 8: Surveillance et Métriques
|
|
|
|
**User Story:** En tant qu'administrateur, je veux surveiller l'état et les performances du système d'auto-healing, afin de détecter les problèmes et optimiser les configurations.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Auto_Heal_Manager SHALL maintain sliding window counters for step, workflow, and global failures
|
|
2. THE Auto_Heal_Manager SHALL track state transition history and durations
|
|
3. THE Auto_Heal_Manager SHALL provide real-time status via get_mode() and health endpoints
|
|
4. THE Auto_Heal_Manager SHALL generate alerts for quarantine events and rollback triggers
|
|
5. THE Auto_Heal_Manager SHALL expose metrics for monitoring dashboard integration
|
|
|
|
### Requirement 9: Déclencheurs de Transition d'État
|
|
|
|
**User Story:** En tant que système de surveillance, je veux des déclencheurs clairs pour les transitions d'état, afin de réagir de manière prévisible aux conditions du système.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN TARGET_NOT_FOUND occurs repeatedly, THE Auto_Heal_Manager SHALL trigger appropriate state transitions
|
|
2. WHEN POSTCONDITION_FAILED occurs repeatedly, THE Auto_Heal_Manager SHALL trigger degraded or quarantine states
|
|
3. WHEN WATCHDOG_TIMEOUT occurs, THE Auto_Heal_Manager SHALL consider it as a failure event
|
|
4. WHEN node_match_confidence is low (FAISS top1-top2 too close), THE Auto_Heal_Manager SHALL trigger degraded mode
|
|
5. WHEN runtime drift is detected (resolution/scale changes), THE Auto_Heal_Manager SHALL adapt thresholds accordingly
|
|
|
|
### Requirement 10: Tests et Validation
|
|
|
|
**User Story:** En tant que développeur, je veux pouvoir tester facilement le système d'auto-healing, afin de valider son comportement dans différents scénarios d'échec.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE system SHALL provide test scenarios for forcing TARGET_NOT_FOUND failures
|
|
2. THE system SHALL demonstrate DEGRADED mode activation after 3 consecutive failures
|
|
3. THE system SHALL demonstrate QUARANTINED mode activation after threshold breaches
|
|
4. THE system SHALL demonstrate rollback functionality with intentionally degraded prototypes
|
|
5. THE system SHALL provide validation tools for configuration and state transitions |