Files
rpa_vision_v3/.kiro/specs/correction-proprietes-etapes-vides/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.7 KiB

Correction des Propriétés d'Étapes Vides - Spécifications

Auteur : Dom, Alice, Kiro
Date : 12 janvier 2026
Version : 1.0.0

Problème Identifié

Le système de propriétés d'étapes du Visual Workflow Builder affiche systématiquement "Cette étape n'a pas de paramètres configurables" même pour les étapes qui devraient avoir des paramètres (comme type_text, click_anchor, etc.).

Analyse du Problème

  1. Code existant fonctionnel : Les composants PropertiesPanel et VWBActionProperties sont correctement implémentés
  2. Configuration complète : La configuration stepParametersConfig contient tous les types d'étapes standard
  3. Problème de mapping : La fonction getParameterConfig() retourne un tableau vide car le mapping entre selectedStep.type et stepParametersConfig ne fonctionne pas
  4. Détection VWB défaillante : La logique de détection des actions VWB du catalogue ne fonctionne pas correctement

Causes Racines Identifiées

  1. Incohérence des types d'étapes : Les types d'étapes créées ne correspondent pas aux clés de stepParametersConfig
  2. Logique de détection VWB : Les hooks useIsVWBStep et useVWBActionId ne détectent pas correctement les actions du catalogue
  3. Mapping défaillant : La correspondance entre les étapes du canvas et les configurations de paramètres est rompue

User Stories

US-1 : Affichage des Propriétés Standard

En tant qu'utilisateur, je veux voir les propriétés configurables pour les étapes standard (click, type, wait, etc.) afin de pouvoir configurer correctement mes workflows.

Critères d'acceptation :

  • Les étapes click affichent les paramètres target et clickType
  • Les étapes type affichent les paramètres target, text, et clearFirst
  • Les étapes wait affichent le paramètre duration
  • Tous les autres types d'étapes standard affichent leurs paramètres respectifs

US-2 : Affichage des Propriétés VWB

En tant qu'utilisateur, je veux voir les propriétés configurables pour les actions VWB du catalogue afin de pouvoir utiliser les actions avancées du système.

Critères d'acceptation :

  • Les actions click_anchor affichent le composant VWBActionProperties
  • Les actions type_text affichent les paramètres VWB appropriés
  • La détection des actions VWB fonctionne correctement
  • Le chargement des détails d'actions depuis le catalogue fonctionne

US-3 : Validation en Temps Réel

En tant qu'utilisateur, je veux que les paramètres soient validés en temps réel afin de détecter les erreurs avant l'exécution.

Critères d'acceptation :

  • Les paramètres requis sont marqués comme obligatoires
  • Les erreurs de validation s'affichent immédiatement
  • Les suggestions d'amélioration sont proposées
  • L'état de validation global est visible

US-4 : Persistance des Paramètres

En tant qu'utilisateur, je veux que mes paramètres soient sauvegardés automatiquement afin de ne pas perdre ma configuration.

Critères d'acceptation :

  • Les changements de paramètres sont sauvegardés immédiatement
  • La configuration persiste lors du changement d'étape
  • Les valeurs par défaut sont appliquées correctement
  • L'état est synchronisé avec le store Redux

Exigences Techniques

Correction de la Logique de Mapping

  1. Normalisation des types d'étapes

    • Standardiser les types d'étapes entre le canvas et la configuration
    • Créer un mapping explicite entre les types d'étapes et les configurations
    • Gérer les cas spéciaux (actions VWB vs étapes standard)
  2. Amélioration de la détection VWB

    • Corriger les hooks useIsVWBStep et useVWBActionId
    • Implémenter une détection robuste basée sur les métadonnées d'étape
    • Gérer le fallback vers les configurations standard
  3. Validation de la configuration

    • Vérifier que stepParametersConfig contient toutes les configurations nécessaires
    • Ajouter des logs de débogage pour tracer le processus de résolution
    • Implémenter des tests unitaires pour la logique de mapping

Architecture de la Solution

// Structure de données normalisée
interface StepTypeMapping {
  standardTypes: Record<StepType, ParameterConfig[]>;
  vwbTypes: Set<string>;
  typeNormalizer: (stepType: string) => StepType | null;
  isVWBType: (stepType: string) => boolean;
}

// Logique de résolution améliorée
function resolveParameterConfig(step: Step): ParameterConfig[] {
  // 1. Normaliser le type d'étape
  // 2. Vérifier si c'est une action VWB
  // 3. Retourner la configuration appropriée
  // 4. Logger le processus pour débogage
}

Composants à Modifier

  1. PropertiesPanel/index.tsx

    • Corriger la fonction getParameterConfig()
    • Améliorer la logique de détection VWB
    • Ajouter des logs de débogage
  2. hooks/useVWBStepIntegration.ts

    • Corriger useIsVWBStep et useVWBActionId
    • Améliorer la détection basée sur les métadonnées
    • Gérer les cas edge
  3. types/index.ts

    • Standardiser les types d'étapes
    • Ajouter des métadonnées pour la détection VWB
    • Créer des types utilitaires pour le mapping

Critères d'Acceptation Globaux

Fonctionnels

  • Toutes les étapes standard affichent leurs propriétés configurables
  • Toutes les actions VWB du catalogue affichent le composant spécialisé
  • La validation en temps réel fonctionne correctement
  • Les paramètres sont persistés automatiquement
  • L'interface est responsive et accessible

Techniques

  • Aucune erreur TypeScript dans la compilation
  • Tous les tests unitaires passent
  • Les tests d'intégration valident le comportement end-to-end
  • La performance reste optimale (< 100ms pour l'affichage)
  • Le code respecte les conventions du projet

Qualité

  • Code documenté en français avec attribution auteur
  • Tests couvrant tous les cas d'usage
  • Gestion d'erreurs robuste
  • Logs de débogage appropriés
  • Compatibilité avec l'architecture existante

Contraintes

Techniques

  • Maintenir la compatibilité avec l'architecture React + TypeScript existante
  • Respecter les patterns Material-UI établis
  • Conserver les performances actuelles
  • Assurer la thread-safety pour les hooks

Fonctionnelles

  • Ne pas casser les workflows existants
  • Maintenir la compatibilité avec le catalogue d'actions
  • Préserver l'expérience utilisateur actuelle
  • Respecter les conventions d'accessibilité

Organisationnelles

  • Documentation en français obligatoire
  • Attribution auteur "Dom, Alice, Kiro" avec date
  • Tests dans le répertoire tests/
  • Documentation dans le répertoire docs/

Définition de "Terminé"

La correction est considérée comme terminée quand :

  1. Validation fonctionnelle

    • Toutes les étapes affichent leurs propriétés configurables
    • La validation en temps réel fonctionne
    • Les paramètres sont persistés correctement
  2. Validation technique

    • Compilation TypeScript sans erreur
    • Tous les tests passent (unitaires + intégration)
    • Performance maintenue
  3. Validation qualité

    • Code documenté et testé
    • Respect des conventions du projet
    • Documentation utilisateur mise à jour
  4. Validation utilisateur

    • Interface intuitive et responsive
    • Pas de régression fonctionnelle
    • Expérience utilisateur améliorée

Risques et Mitigation

Risques Identifiés

  1. Régression fonctionnelle : Les modifications pourraient casser des fonctionnalités existantes

    • Mitigation : Tests de régression complets avant déploiement
  2. Performance dégradée : La logique de détection pourrait être coûteuse

    • Mitigation : Optimisation avec mémorisation et cache
  3. Complexité accrue : La logique de mapping pourrait devenir complexe

    • Mitigation : Refactoring en composants simples et testables
  4. Incompatibilité TypeScript : Les changements de types pourraient créer des erreurs

    • Mitigation : Migration progressive avec validation continue

Métriques de Succès

Métriques Fonctionnelles

  • Taux d'affichage des propriétés : 100% des étapes affichent leurs propriétés
  • Temps de réponse : < 100ms pour l'affichage des propriétés
  • Taux d'erreur : 0% d'erreurs dans la console lors de l'utilisation

Métriques Techniques

  • Couverture de tests : > 90% pour les composants modifiés
  • Compilation TypeScript : 0 erreur, 0 warning
  • Performance : Pas de régression mesurable

Métriques Qualité

  • Documentation : 100% des fonctions documentées
  • Conventions : 100% de respect des conventions projet
  • Accessibilité : Conformité WCAG 2.1 AA maintenue