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>

.kiro/specs/resolution-palette-vide-cross-machine/requirements.md

@@ -0,0 +1,181 @@
+# 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.