Files
rpa_vision_v3/visual_workflow_builder
Dom 35b27ae492 fix(stream+vwb): chaîne replay robuste — auth, anchor type_text, lock async, drift, prompt LLM
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>
2026-05-02 00:32:57 +02:00
..
2026-04-16 08:37:12 +02:00
2026-04-16 08:37:12 +02:00
2026-04-16 08:37:12 +02:00
2026-04-16 08:37:12 +02:00
2026-04-16 08:37:12 +02:00

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.sh ou ./launch.sh (wrapper). Le dossier frontend/ est conservé pour référence legacy (Create React App, port 3000), lancé par ./run.sh. Les sections launch.sh setup/stop/restart/logs ci-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

  1. Interface utilisateur : http://localhost:3000
  2. API Health Check : http://localhost:5001/health
  3. Import/Export : Utilisez les boutons dans l'interface
  4. 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 production
  • SECRET_KEY: Clé secrète pour les sessions
  • DATABASE_URL: URL de la base de données
  • REDIS_URL: URL Redis pour le cache
  • CORS_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

  1. Frontend: Build et déploiement sur CDN ou serveur web

    npm run build
    # Les fichiers sont dans dist/
    
  2. Backend: Déploiement avec Gunicorn + Nginx

    gunicorn -k geventwebsocket.gunicorn.workers.GeventWebSocketWorker -w 1 app:app
    
  3. Base de données: Migrer vers PostgreSQL

  4. Cache: Configurer Redis

  5. 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