Six modifications structurelles côté serveur, non destructives, aboutissant à un
pipeline replay bien plus stable pour la démo GHT Sud 95 (Urgences UHCD).
1. visual_workflow_builder/backend/app.py
load_dotenv() chargeait .env (cwd) au lieu de .env.local racine projet.
Conséquence : RPA_API_TOKEN absent après chaque restart manuel du backend
et tous les proxies VWB→streaming échouaient en 401 « Token API invalide ».
Charge maintenant explicitement .env.local du project root.
2. visual_workflow_builder/backend/api_v3/learned_workflows.py
Quatre appels proxy /api/v1/traces/stream/* ne portaient pas le Bearer.
Helper _stream_headers() factorisé et appliqué (workflows list/detail,
workflow detail, reload-workflows).
3. visual_workflow_builder/backend/api_v3/dag_execute.py
_ANCHOR_CLICK_TYPES excluait type_text/type_secret : pas de pre-click de
focus avant la frappe → texte tapé sans focus → textareas vides au replay.
Helper _inject_anchor_targeting() factorisé (centre bbox + visual_mode +
target_spec) appliqué aux click_anchor* ET aux type_text/type_secret dès
qu'un anchor_id est présent. Workflows historiques sans anchor sur
type_text → comportement inchangé.
4. agent_v0/server_v1/api_stream.py — endpoint /replay/next
_replay_lock (threading.Lock global) tenu pendant les actions serveur
lentes (extract_text OCR ~5s, t2a_decision LLM ~8-13s). Comme le handler
est async def, l'event loop FastAPI était bloqué : les polls clients
timeout à 5s, leurs actions étaient popped serveur sans destinataire,
perdues silencieusement. Mesure : 8 actions/25 perdues sur replay Urgence.
acquire(timeout=4.5) puis run_in_executor pour libérer l'event loop
pendant l'attente du lock ET pendant les handlers serveur synchrones.
Pendant un t2a_decision en cours, les polls concurrents reçoivent
immédiatement {action: null, server_busy: true} → l'agent ne timeout
plus, aucune action n'est popped sans destinataire.
5. agent_v0/server_v1/resolve_engine.py — _validate_resolution_quality
Drift > 0.20 par rapport aux coords enregistrées → fallback aux coords
enregistrées même quand le template matching trouve l'image avec un
score quasi parfait. Or un score >= 0.95 signifie que l'image EST
visuellement à l'écran à l'endroit indiqué, le drift reflète juste
un changement de layout (scroll, F11, redimensionnement), pas une
erreur. Exception ajoutée : score >= 0.95 sur template_matching →
ignore drift check, utilise position visuelle.
6. core/llm/t2a_decision.py — prompt T2A/PMSI
Ancien prompt autorisait « Critère non validé » en fallback creux.
Nouveau prompt impose au moins une CITATION LITTÉRALE entre « ... »
du DPI dans chaque preuve_critereN, qu'elle soutienne ou infirme le
critère. Si non validé : factualisation explicite (« Aucune ... »,
« Sortie à H+2 ») citée du dossier. Sortie = preuves cliniques
traçables et professionnelles, pas du remplissage.
État DB : aucun changement net (bbox patchés puis revertés depuis backup
visual_anchors_backup_20260501 ; by_text re-aligné sur 25003284). Le
re-enregistrement du workflow Urgence en conditions bureau standard
(Chrome normal, taille fenêtre standard) est l'étape suivante côté Dom.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Visual Workflow Builder
Interface graphique pour créer des workflows RPA par glisser-déposer, sans écrire de code.
État actuel (avril 2026) : la version active est
frontend_v4/(Vite + React, port 3002), lancée par./run_v4.shou./launch.sh(wrapper). Le dossierfrontend/est conservé pour référence legacy (Create React App, port 3000), lancé par./run.sh. Les sectionslaunch.sh setup/stop/restart/logsci-dessous sont historiques : seules./launch.sh(=./run_v4.sh) et./launch.sh legacy(=./run.sh) sont effectivement implémentées.
🚀 Démarrage Ultra-Rapide
Méthode Simple (Recommandée)
# Démarrer l'application complète (frontend_v4, port 3002)
./launch.sh
# Ouvrir http://localhost:3002 dans votre navigateur
Sur Windows :
# Configuration initiale (une seule fois)
launch.bat setup
# Démarrer l'application complète
launch.bat start
Prérequis
- Python 3.8+
- Node.js 16+
- npm
🎮 Commandes Principales
Script de Lancement Unifié
Le script launch.sh (ou launch.bat sur Windows) simplifie toutes les opérations :
# Démarrer en mode développement (avec hot reload)
./launch.sh start --dev
# Démarrer en mode production
./launch.sh start --prod
# Arrêter l'application
./launch.sh stop
# Redémarrer
./launch.sh restart
# Voir le statut
./launch.sh status
# Voir les logs en temps réel
./launch.sh logs
# Lancer tous les tests
./launch.sh test
# Configuration initiale
./launch.sh setup
# Nettoyer les fichiers temporaires
./launch.sh clean
# Aide complète
./launch.sh --help
Ports Personnalisés
# Frontend sur port 3001, backend sur port 5002
./launch.sh start --port 3001 --backend-port 5002
🧪 Tests
Tests Automatisés
# Tous les tests
./launch.sh test
# Tests spécifiques
./test_import_export.sh # Test import/export
./test_zoom_pan.sh # Test zoom et panoramique
Tests Manuels
- Interface utilisateur : http://localhost:3000
- API Health Check : http://localhost:5001/health
- Import/Export : Utilisez les boutons dans l'interface
- Zoom/Pan : Molette de souris + Ctrl+Drag
Architecture
Le projet est divisé en deux parties principales :
Frontend (React + TypeScript)
- Framework: React 18 avec TypeScript
- Canvas: react-flow-renderer pour le rendu des graphes avec zoom/pan personnalisé
- State Management: Hooks personnalisés avec Undo/Redo
- UI Components: Composants personnalisés + Material-UI
- Real-time: Socket.IO client pour synchronisation d'exécution
- Import/Export: Support JSON/YAML avec validation
- Build: Create React App avec TypeScript
Backend (Flask + Python)
- Framework: Flask avec Flask-SocketIO
- Database: SQLAlchemy (SQLite pour dev, PostgreSQL pour prod)
- Validation: JSON Schema + validation personnalisée
- Import/Export: API REST avec support multi-formats
- Cache: Redis (optionnel)
- Testing: Pytest + tests d'intégration
Structure du Projet
visual_workflow_builder/
├── launch.sh # 🚀 Script de lancement principal (Linux/Mac)
├── launch.bat # 🚀 Script de lancement principal (Windows)
├── backend/ # API Flask
│ ├── api/
│ │ ├── workflows.py # CRUD workflows
│ │ ├── import_export.py # Import/Export
│ │ ├── templates.py # Templates
│ │ └── websocket_handlers.py # WebSocket
│ ├── models/ # Modèles de données
│ ├── services/ # Logique métier
│ └── app.py # Point d'entrée
├── frontend/ # Interface React + TypeScript
│ ├── src/
│ │ ├── components/
│ │ │ ├── Canvas/ # Canvas principal avec zoom/pan
│ │ │ ├── ZoomControls/ # Contrôles de zoom
│ │ │ ├── ImportExport/ # Import/Export UI
│ │ │ └── UndoRedoToolbar/ # Undo/Redo
│ │ ├── hooks/
│ │ │ ├── useZoomPan.ts # Hook zoom/panoramique
│ │ │ ├── useWorkflowWithUndo.ts # Workflow + Undo
│ │ │ └── useExecutionSync.ts # Sync exécution
│ │ ├── utils/
│ │ │ ├── ImportExport.ts # Logique import/export
│ │ │ └── UndoManager.ts # Gestionnaire Undo/Redo
│ │ └── types/ # Types TypeScript
│ └── public/
├── test_import_export.sh # Tests import/export
├── test_zoom_pan.sh # Tests zoom/panoramique
└── docs/ # Documentation
Installation
Prérequis
- Node.js 18+ et npm
- Python 3.10+
- Redis (optionnel pour dev, requis pour prod)
Frontend
cd frontend
npm install
npm start # Démarre le serveur de développement sur http://localhost:3000
Backend
cd backend
python -m venv venv
source venv/bin/activate # Sur Windows: venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env # Configurer les variables d'environnement
python app.py # Démarre le serveur Flask sur http://localhost:5001
Développement
Frontend
npm start # Serveur de développement avec hot reload
npm run build # Build de production
npm test # Exécuter les tests
npm run lint # Vérifier le code avec ESLint
npm run type-check # Vérifier les types TypeScript
Backend
python app.py # Démarrer le serveur
pytest # Exécuter tous les tests
pytest tests/unit # Tests unitaires seulement
pytest -m property # Tests property-based seulement
pytest --cov # Tests avec couverture de code
black . # Formater le code
flake8 . # Vérifier le style
mypy . # Vérifier les types
Tests
Frontend
- Tests unitaires: Jest + React Testing Library
- Coverage: Minimum 70% requis
Backend
- Tests unitaires: Pytest
- Tests d'intégration: Pytest avec fixtures
- Tests property-based: Hypothesis
- Coverage: Minimum 70% requis
Configuration
Variables d'Environnement Backend
Voir .env.example pour la liste complète. Les principales :
FLASK_ENV: development ou productionSECRET_KEY: Clé secrète pour les sessionsDATABASE_URL: URL de la base de donnéesREDIS_URL: URL Redis pour le cacheCORS_ORIGINS: Origines autorisées pour CORS
Configuration Frontend
Le frontend se configure via webpack.config.js et les variables d'environnement peuvent être passées au build.
Déploiement
Production
-
Frontend: Build et déploiement sur CDN ou serveur web
npm run build # Les fichiers sont dans dist/ -
Backend: Déploiement avec Gunicorn + Nginx
gunicorn -k geventwebsocket.gunicorn.workers.GeventWebSocketWorker -w 1 app:app -
Base de données: Migrer vers PostgreSQL
-
Cache: Configurer Redis
-
Monitoring: Configurer logs et métriques
Roadmap
Phase 1: MVP (4-6 semaines)
- ✅ Structure du projet configurée
- ⏳ API REST de base
- ⏳ Canvas avec drag & drop
- ⏳ Nodes essentiels
- ⏳ Exécution simple
Phase 2: Fonctionnalités Avancées (4-6 semaines)
- ⏳ WebSocket temps réel
- ⏳ Templates avancés
- ⏳ Undo/Redo
- ⏳ Zoom/Pan optimisé
- ⏳ Variables management
Phase 3: Production (2-4 semaines)
- ⏳ Optimisations performance
- ⏳ Sécurité renforcée
- ⏳ Documentation complète
- ⏳ Déploiement production
Contribution
Voir le document de design complet dans .kiro/specs/visual-workflow-builder/design.md pour les détails d'architecture et les propriétés de correction à respecter.
License
MIT