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/resolution-palette-vide-cross-machine/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.9 KiB
Raw Blame History

Spécification : Résolution du Problème de Palette Vide Cross-Machine

Introduction

Cette spécification définit la résolution du problème de palette vide dans le Visual Workflow Builder (VWB) lorsque l'application est utilisée sur une machine distante. Le problème identifié est que seules les actions web hardcodées apparaissent dans la palette, tandis que les actions du catalogue VisionOnly ne se chargent pas à cause d'une URL de service hardcodée.

Auteur : Dom, Alice, Kiro - 10 janvier 2026

Contexte et Problème Identifié

État Actuel

  • Fonctionnement local : La palette affiche toutes les actions (web + catalogue VisionOnly)
  • Problème cross-machine : Seules les actions web apparaissent, le catalogue VisionOnly est vide
  • Cause racine : URL hardcodée http://localhost:5004 dans catalogService.ts

Analyse Technique

  1. Actions web : Hardcodées dans getDefaultCategories() → Toujours disponibles
  2. Actions catalogue : Chargées dynamiquement via useCatalogActions hook → Échouent cross-machine
  3. Service catalogue : Utilise URL fixe localhost:5004 → Inaccessible depuis machine distante

Objectifs du Projet

Objectif Principal

Résoudre le problème de palette vide cross-machine en rendant le service catalogue configurable et robuste, avec fallback gracieux vers des actions par défaut.

Objectifs Spécifiques

  1. Configuration dynamique : Rendre l'URL du service catalogue configurable
  2. Détection automatique : Détecter automatiquement l'URL du backend VWB
  3. Fallback robuste : Implémenter un catalogue statique de secours
  4. Gestion d'erreurs : Améliorer la gestion des erreurs réseau
  5. Tests cross-machine : Valider le fonctionnement sur machines distantes

Exigences Fonctionnelles

Exigence 1 : Configuration Dynamique du Service Catalogue

User Story : En tant qu'utilisateur du VWB sur une machine distante, je veux que la palette charge automatiquement les actions du catalogue, afin d'avoir accès à toutes les fonctionnalités.

Critères d'Acceptation

  1. LE service catalogue DOIT détecter automatiquement l'URL du backend VWB
  2. QUAND l'URL automatique échoue, LE système DOIT essayer des URLs alternatives configurables
  3. LA configuration DOIT supporter les variables d'environnement et paramètres URL
  4. LE service DOIT fonctionner avec localhost, IP locale, et noms d'hôte
  5. LA détection DOIT être transparente pour l'utilisateur

Exigence 2 : Catalogue Statique de Secours

User Story : En tant qu'utilisateur du VWB hors ligne ou avec service catalogue indisponible, je veux avoir accès aux actions de base, afin de pouvoir créer des workflows simples.

Critères d'Acceptation

  1. LE système DOIT fournir un catalogue statique avec actions Vision UI de base
  2. QUAND le service catalogue est indisponible, LA palette DOIT afficher les actions statiques
  3. LES actions statiques DOIVENT inclure : ClickAnchor, TypeText, WaitForAnchor, ExtractText
  4. CHAQUE action statique DOIT avoir les mêmes métadonnées que les actions dynamiques
  5. LE passage au mode statique DOIT être transparent avec indicateur visuel

Exigence 3 : Détection Automatique d'URL

User Story : En tant que système VWB, je veux détecter automatiquement l'URL du backend, afin de fonctionner sans configuration manuelle.

Critères d'Acceptation

  1. LE système DOIT essayer l'URL courante du frontend (même origine)
  2. QUAND l'origine échoue, LE système DOIT essayer localhost:5004
  3. LE système DOIT essayer l'IP locale détectée avec port 5004
  4. CHAQUE tentative DOIT avoir un timeout de 2 secondes maximum
  5. LA première URL qui répond DOIT être mise en cache pour les requêtes suivantes

Exigence 4 : Gestion d'Erreurs Améliorée

User Story : En tant qu'utilisateur du VWB, je veux comprendre pourquoi le catalogue ne se charge pas, afin de pouvoir résoudre le problème ou utiliser les alternatives.

Critères d'Acceptation

  1. QUAND le catalogue échoue, LE système DOIT afficher un message explicatif en français
  2. LE message DOIT indiquer si c'est un problème réseau, de service, ou de configuration
  3. L'interface DOIT proposer un bouton "Réessayer" pour recharger le catalogue
  4. LE système DOIT logger les tentatives de connexion pour diagnostic
  5. UN indicateur visuel DOIT montrer l'état du catalogue (en ligne/hors ligne/erreur)

Exigence 5 : Persistance de Configuration

User Story : En tant qu'utilisateur du VWB, je veux que le système se souvienne de la configuration qui fonctionne, afin d'éviter les délais de détection à chaque utilisation.

Critères d'Acceptation

  1. QUAND une URL fonctionne, LE système DOIT la sauvegarder en localStorage
  2. AU démarrage suivant, LE système DOIT essayer d'abord l'URL sauvegardée
  3. SI l'URL sauvegardée échoue, LE système DOIT relancer la détection automatique
  4. LA configuration DOIT expirer après 24 heures pour forcer une re-détection
  5. L'utilisateur DOIT pouvoir forcer une re-détection via l'interface

Exigences Techniques

Exigence 6 : Architecture de Service Configurable

User Story : En tant que développeur VWB, je veux un service catalogue flexible, afin de supporter différents environnements de déploiement.

Critères d'Acceptation

  1. LE service catalogue DOIT accepter une configuration d'URLs multiples
  2. LA classe CatalogService DOIT implémenter un pattern de fallback automatique
  3. CHAQUE méthode DOIT gérer gracieusement les erreurs réseau
  4. LE service DOIT exposer des métriques de santé et connectivité
  5. L'architecture DOIT permettre l'ajout facile de nouveaux modes de détection

Exigence 7 : Catalogue Statique Intégré

User Story : En tant que système VWB, je veux un catalogue d'actions intégré, afin de garantir un fonctionnement minimal même hors ligne.

Critères d'Acceptation

  1. UN fichier staticCatalog.ts DOIT définir les actions de base
  2. LES actions statiques DOIVENT respecter l'interface VWBCatalogAction
  3. LE catalogue statique DOIT être importé comme module ES6
  4. LES actions statiques DOIVENT avoir des exemples et documentation
  5. LE système DOIT pouvoir basculer dynamiquement entre catalogue dynamique et statique

Exigence 8 : Tests Cross-Machine

User Story : En tant que développeur VWB, je veux valider le fonctionnement cross-machine, afin d'assurer la robustesse du système.

Critères d'Acceptation

  1. LES tests DOIVENT simuler différents scénarios réseau (localhost, IP, hostname)
  2. UN test DOIT valider le fallback vers le catalogue statique
  3. LES tests DOIVENT vérifier la persistance de configuration
  4. UN test d'intégration DOIT valider le fonctionnement sur machine distante réelle
  5. TOUS les tests DOIVENT être dans le répertoire tests/integration/

Plan d'Implémentation

Phase 1 : Service Catalogue Configurable (Jour 1)

  • Modification de catalogService.ts pour support URLs multiples
  • Implémentation de la détection automatique d'URL
  • Tests unitaires du nouveau service

Phase 2 : Catalogue Statique de Secours (Jour 1-2)

  • Création de staticCatalog.ts avec actions de base
  • Intégration dans useCatalogActions hook
  • Tests du mode fallback

Phase 3 : Interface Utilisateur Améliorée (Jour 2)

  • Amélioration des indicateurs de statut dans la palette
  • Messages d'erreur explicatifs en français
  • Bouton de rechargement manuel

Phase 4 : Tests et Validation (Jour 2-3)

  • Tests d'intégration cross-machine
  • Validation sur environnements réels
  • Documentation utilisateur

Critères de Succès

  1. Fonctionnel : Palette complète sur machines locales et distantes
  2. Robustesse : Fallback automatique vers catalogue statique
  3. Performance : Détection d'URL en moins de 5 secondes
  4. Utilisabilité : Messages d'erreur clairs et actions correctives
  5. Tests : Validation sur au moins 2 configurations réseau différentes

Risques et Mitigation

Risque 1 : Complexité de Détection Réseau

Mitigation : Implémentation progressive avec fallback simple vers catalogue statique

Risque 2 : Performance de Détection

Mitigation : Timeouts courts et mise en cache de la configuration qui fonctionne

Risque 3 : Compatibilité Cross-Browser

Mitigation : Tests sur Chrome, Firefox, Edge avec différentes configurations réseau

Risque 4 : Maintenance du Catalogue Statique

Mitigation : Synchronisation automatique avec le catalogue dynamique lors des builds

Conclusion

Cette spécification définit une solution complète pour résoudre le problème de palette vide cross-machine dans le VWB. L'approche combine détection automatique intelligente, fallback robuste, et amélioration de l'expérience utilisateur pour garantir un fonctionnement fiable dans tous les environnements.

L'implémentation sera rapide (2-3 jours) et permettra aux utilisateurs d'accéder à toutes les fonctionnalités du VWB indépendamment de leur configuration réseau.

Reference in New Issue View Git Blame Copy Permalink