Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a7de6a488b8269927a6eb78adea3c9632acc3f33
rpa_vision_v3/.kiro/specs/auto-heal-hybrid/requirements.md
Dom a7de6a488b feat: replay E2E fonctionnel — 25/25 actions, 0 retries, SomEngine via serveur 
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>
2026-03-31 14:04:41 +02:00

8.8 KiB
Raw Blame History

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_/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
Reference in New Issue View Git Blame Copy Permalink