docs(audit): README honnête + STATUS + DEV_SETUP + cleanup build

- README.md : bandeau POC, date 14 avril 2026, retrait claims "production-ready 77%" (alignement code/doc post-audit) - docs/STATUS.md : état réel par module (opérationnel/alpha/en cours) - docs/DEV_SETUP.md : gestion worktrees Claude - QUICK_START.md : gemma4:latest au lieu de qwen3-vl:8b - deploy/build_package.sh : +9 fichiers dans REQUIRED_FILES (system_dialog_guard.py, persistent_buffer.py, grounding.py, etc.) - agent_v0/deploy_windows.py : marqué OBSOLÈTE (legacy) - .gitignore : ajout data/, .hypothesis, .deps_installed, buffer/, instance/*.db, caches SQLite Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-14 16:49:29 +02:00
parent 36737cfe9d
commit 42f571d496
7 changed files with 438 additions and 172 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -83,3 +83,30 @@ backups/
 # === Legacy / Triage ===
 _a_trier/
 archives/
+
+# === Claude Code — worktrees et données locales ===
+# Worktrees générés par la CLI Claude Code lors d'exécutions d'agents
+# parallèles. Peuvent atteindre plusieurs centaines de Mo chacun.
+# Ne jamais committer — gérer via `git worktree list` / `git worktree remove`.
+.claude/
+.kiro/
+.mcp.json
+.snapshots/
+
+# === Données runtime (sessions, learning, buffer, config local) ===
+data/
+.hypothesis/
+.deps_installed
+# Buffers SQLite locaux (streamer, cache)
+**/buffer/
+**/pending_events.db
+# Databases applicatives (instance Flask)
+**/instance/*.db
+**/instance/*.sqlite
+**/instance/*.sqlite3
+# Caches et index locaux
+*.sqlite
+*.sqlite3
+*.db-journal
+*.db-wal
+*.db-shm
--- a/QUICK_START.md
+++ b/QUICK_START.md
@@ -21,7 +21,12 @@ ollama serve
 ### 3. Télécharger le modèle VLM

 ```bash
-ollama pull qwen3-vl:8b
+# Modèle par défaut du projet (voir .env.example)
+ollama pull gemma4:latest
+
+# Alternatives supportées
+# ollama pull qwen3-vl:8b
+# ollama pull 0000/ui-tars-1.5-7b-q8_0:7b   # grounder visuel
 ```

 ## Utilisation
--- a/README.md
+++ b/README.md
@@ -1,207 +1,203 @@
-# RPA Vision V3 - 100% Vision-Based Workflow Automation
+# RPA Vision V3 — Automatisation basée sur la compréhension visuelle des interfaces

-## 📊 Status
+> ⚠️ **Projet en phase POC** — voir [`docs/STATUS.md`](docs/STATUS.md) pour l'état
+> réel par module. Certaines briques sont opérationnelles bout en bout,
+> d'autres sont en cours de stabilisation. Ce dépôt n'est pas production-ready.

-🚀 **PRODUCTION-READY** - Phase 12 Complete (77% System Completion) ✅
+*Dernière mise à jour : 14 avril 2026*

-**Latest Update**: 14 Décembre 2024
- ✅ **10/13 Phases Complétées** - Système mature et fonctionnel
- ✅ **Performance Exceptionnelle** - 500-6250x plus rapide que requis
- ✅ **Architecture Entreprise** - 148k+ lignes, 19 modules, 6 specs complètes
- ✅ **Innovations Techniques** - Self-healing, Multi-modal, GPU management
- 📊 **Audit Complet** - [Rapport détaillé](AUDIT_COMPLET_SYSTEME_RPA_VISION_V3.md)
+## Intention

-**Quick Test**: `bash test_clip.sh`
+Automatiser des workflows métier par **compréhension sémantique de l'écran**
+plutôt que par coordonnées de clic fixes. Le système observe l'utilisateur,
+reconstruit un graphe d'états de l'interface, et cherche à rejouer la
+procédure en reconnaissant visuellement les éléments cibles — y compris
+quand l'UI change légèrement.

-## 🎯 Vision
+Terrain cible principal : postes hospitaliers (Citrix, applications métier
+web et desktop). Contrainte forte : **100 % local**, pas d'appel à un LLM
+cloud dans le pipeline par défaut.

-RPA basé sur la **compréhension sémantique** des interfaces, pas sur des coordonnées de clics.
-
-Le système apprend des workflows en observant l'utilisateur et les automatise de manière robuste grâce à une architecture en 5 couches.
-
-## 🏗️ Architecture en 5 Couches
+## Architecture en couches

 ```
-RawSession (Couche 0)
+RawSession (couche 0) — capture événements + screenshots
        ↓
-ScreenState (Couche 1) - 4 niveaux d'abstraction
+ScreenState (couche 1) — états d'écran à plusieurs niveaux d'abstraction
        ↓
-UIElement Detection (Couche 2) - Types + Rôles sémantiques
+UIElement (couche 2) — détection sémantique (cascade OCR + templates + VLM)
        ↓
-State Embedding (Couche 3) - Fusion multi-modale
+State Embedding (couche 3) — fusion multi-modale + index FAISS
        ↓
-Workflow Graph (Couche 4) - Nodes + Edges + Learning States
+Workflow Graph (couche 4) — nœuds, transitions, résolution de cibles
 ```

-## 📁 Structure
+## État des fonctionnalités (synthèse)

-```
-rpa_vision_v3/
-├── core/
-│   ├── models/          # Couches 0-4 : Structures de données
-│   ├── capture/         # Couche 0 : Capture événements + screenshots
-│   ├── detection/       # Couche 2 : Détection UI sémantique
-│   ├── embedding/       # Couche 3 : Fusion multi-modale + FAISS
-│   ├── graph/           # Couche 4 : Construction + Matching + Exécution
-│   └── persistence/     # Sauvegarde/Chargement
-├── data/
-│   ├── sessions/        # RawSessions
-│   ├── screen_states/   # ScreenStates
-│   ├── embeddings/      # Vecteurs .npy
-│   ├── faiss_index/     # Index FAISS
-│   └── workflows/       # Workflow Graphs
-└── tests/               # Tests unitaires + intégration
-```
+Le détail par module est dans [`docs/STATUS.md`](docs/STATUS.md).

-## 🚀 Démarrage Rapide
+**Opérationnel**
+- Capture Windows (Agent V1) + streaming vers serveur Linux
+- Stockage des sessions brutes (screenshots + événements)
+- Streaming server FastAPI, sessions en mémoire
+- Build du package Windows (`deploy/build_package.sh`)
+
+**Alpha (fonctionnel sur un cas de référence, encore peu généralisé)**
+- Détection UI par cascade VLM + OCR + templates
+- Construction de workflow graph depuis une session
+- Replay E2E supervisé — premier succès sur Notepad le 13 avril 2026
+- Mode apprentissage : pause et demande d'aide humaine quand la résolution échoue
+- Embeddings CLIP + index FAISS
+- Module auth (Fernet + TOTP), federation (LearningPack)
+- Web Dashboard, Agent Chat
+
+**En cours**
+- Visual Workflow Builder (VWB) — bugs DB runtime connus
+- Self-healing / recovery global
+- Analytics / reporting
+- Worker de compilation sessions → ExecutionPlan
+- Tests E2E multi-applications
+
+## Limitations connues
+
+- Le pipeline de replay est validé sur un nombre très restreint d'applications.
+- `TargetMemoryStore` (apprentissage Phase 1) est câblé mais sa base reste
+  vide tant qu'un replay complet n'a pas été cristallisé.
+- Certaines asymétries entre chemins stricts et legacy dans le serveur de
+  streaming peuvent provoquer des arrêts au lieu de pauses d'apprentissage.
+- VWB n'est pas encore stable en écriture ; un outil dédié plus simple est
+  envisagé.
+
+## Démarrage
+
+### Prérequis
+
+- Python 3.10 à 3.12
+- [Ollama](https://ollama.ai) installé et démarré localement
+- Recommandé : GPU NVIDIA pour l'inférence VLM
+- Windows 10/11 uniquement pour le client Agent V1

 ### Installation

 ```bash
-# 1. Installer Ollama
-curl -fsSL https://ollama.ai/install.sh | sh  # Linux
-# ou
-brew install ollama  # macOS
-
-# 2. Démarrer Ollama
-ollama serve
-
-# 3. Télécharger le modèle VLM
-ollama pull qwen3-vl:8b
-
-# 4. Installer dépendances Python
+# 1) Cloner puis créer le venv
+python3 -m venv .venv
+source .venv/bin/activate
 pip install -r requirements.txt
+
+# 2) Démarrer Ollama et récupérer le modèle VLM par défaut
+ollama serve &
+ollama pull gemma4:latest        # défaut du projet
+# Alternatives supportées :
+# ollama pull qwen3-vl:8b
+# ollama pull 0000/ui-tars-1.5-7b-q8_0:7b   # grounder visuel
+
+# 3) Copier et ajuster la configuration
+cp .env.example .env
+# éditer .env pour vérifier RPA_VLM_MODEL, VLM_ENDPOINT, ports, etc.
 ```

-### Test Rapide
+### Lancer les services
+
+Tous les services sont pilotés par `svc.sh` (source de vérité des ports :
+`services.conf`).

 ```bash
-# Diagnostic système
-python3 rpa_vision_v3/examples/diagnostic_vlm.py
-
-# Test de détection
-./rpa_vision_v3/test_quick.sh
+./svc.sh status          # État de tous les services
+./svc.sh start           # Tout démarrer
+./svc.sh start streaming # Streaming server uniquement (port 5005)
+./svc.sh restart api     # Redémarrer l'API (port 8000)
+./svc.sh stop            # Tout arrêter
 ```

-### Utilisation - Détection UI
+| Port | Service |
+|---|---|
+| 8000 | API Server (upload / traitement core) |
+| 5001 | Web Dashboard |
+| 5002 | VWB Backend (Flask) |
+| 5003 | Monitoring |
+| 5004 | Agent Chat |
+| 5005 | Streaming Server (Agent V1 → pipeline core) |
+| 5006 | Session Cleaner |
+| 5099 | Worker de compilation (optionnel) |
+| 3002 | VWB Frontend (Vite/React) |

-```python
-from rpa_vision_v3.core.detection import create_detector
+### Client Windows (Agent V1)

-# Créer le détecteur
-detector = create_detector()
-
-# Détecter les éléments UI
-elements = detector.detect("screenshot.png")
-
-# Utiliser les résultats
-for elem in elements:
-    print(f"{elem.type:15s} | {elem.role:20s} | {elem.label}")
-```
-
-### Utilisation - Workflow (Phase 4 - À venir)
-
-```python
-from rpa_vision_v3.core.models import RawSession, ScreenState, Workflow
-from rpa_vision_v3.core.graph import GraphBuilder, NodeMatcher
-
-# 1. Capturer une session
-session = RawSession(...)
-# ... capturer événements et screenshots
-
-# 2. Construire workflow automatiquement
-builder = GraphBuilder(...)
-workflow = builder.build_from_session(session)
-
-# 3. Matcher état actuel
-matcher = NodeMatcher(...)
-current_state = ScreenState(...)
-match = matcher.match(current_state, workflow)
-
-# 4. Exécuter action
-if match:
-    edge = workflow.get_outgoing_edges(match.node.node_id)[0]
-    executor.execute_edge(edge, current_state)
-```
-
-## 📚 Documentation
-
-### Guides Principaux
- **Quick Start** : `QUICK_START.md` - Démarrage rapide
- **Prochaines Étapes** : `NEXT_STEPS.md` - Roadmap et Phase 4
- **Phase 3 Complète** : `PHASE3_COMPLETE.md` - Résumé Phase 3
-
-### Documentation Technique
- **Spec complète** : `.kiro/specs/workflow-graph-implementation/`
- **Architecture** : `docs/reference/ARCHITECTURE_VISION_COMPLETE.md`
- **Détection Hybride** : `HYBRID_DETECTION_SUMMARY.md`
- **Intégration Ollama** : `docs/OLLAMA_INTEGRATION.md`
-
-## 🎓 Concepts Clés
-
-### RPA 100% Vision
-
- ❌ Pas de coordonnées (x, y) fixes
- ✅ Rôles sémantiques (primary_action, form_input, etc.)
- ✅ Matching par similarité visuelle et textuelle
- ✅ Robuste aux changements d'UI
-
-### Apprentissage Progressif
-
-```
-OBSERVATION (5+ exécutions)
-    ↓
-COACHING (10+ assistances, succès >90%)
-    ↓
-AUTO_CANDIDATE (20+ exécutions, succès >95%)
-    ↓
-AUTO_CONFIRMÉ (validation utilisateur)
-```
-
-### State Embedding
-
-Fusion multi-modale :
- 50% Image (screenshot complet)
- 30% Texte (texte détecté)
- 10% Titre (fenêtre)
- 10% UI (éléments détectés)
-
-## 🧪 Tests
+Le client capture souris, clavier et écran sur le poste Windows et envoie
+les données au streaming server Linux.

 ```bash
-# Tests unitaires
-pytest tests/unit/
-
-# Tests d'intégration
-pytest tests/integration/
-
-# Tests de performance
-pytest tests/performance/ --benchmark-only
+# Build du package Windows depuis le repo Linux
+./deploy/build_package.sh
+# produit deploy/Lea_v<version>.zip
 ```

-## 📈 Roadmap - 77% Complété (10/13 Phases)
+Voir [`docs/DEV_SETUP.md`](docs/DEV_SETUP.md) pour la maintenance du dépôt
+(worktrees, build, services).

-### ✅ **Phases Complétées**
- [x] **Phase 1-2** : Fondations + Embeddings FAISS ✅
- [x] **Phase 4-6** : Détection UI + Workflow Graphs + Action Execution ✅  
- [x] **Phase 7-8** : Learning System + Training System ✅
- [x] **Phase 10-12** : GPU Management + Performance + Monitoring ✅
+## Arborescence du dépôt

-### 🎯 **Phases Restantes**
- [ ] **Phase 3** : Checkpoint Final (tests storage)
- [ ] **Phase 9** : Visual Workflow Builder (90% → 100%)
- [ ] **Phase 13** : Tests End-to-End + Documentation finale
+```
+rpa_vision_v3/
+├── agent_v0/                # Agent V1 (client Windows) + serveur de streaming
+│   ├── agent_v1/            # Source de l'agent (capture, UI tray, exécution)
+│   └── server_v1/           # FastAPI streaming + processeurs
+├── core/                    # Pipeline core
+│   ├── detection/           # Cascade VLM + OCR + templates
+│   ├── embedding/           # CLIP + FAISS
+│   ├── graph/               # Construction / matching de workflow graphs
+│   ├── execution/           # Résolution de cibles, actions LLM
+│   ├── learning/            # TargetMemoryStore (apprentissage)
+│   ├── auth/                # Vault Fernet + TOTP
+│   └── federation/          # Export/import de LearningPacks
+├── visual_workflow_builder/ # VWB (backend Flask + frontend React Vite)
+├── web_dashboard/           # Dashboard Flask + SocketIO
+├── agent_chat/              # Interface conversationnelle + planner
+├── deploy/                  # Scripts de build et unités systemd
+├── data/                    # Sessions, embeddings, index FAISS, apprentissage
+├── docs/                    # Documentation technique
+├── tests/                   # pytest (unit, integration, e2e)
+├── services.conf            # Source de vérité des ports
+├── svc.sh                   # Orchestrateur des services
+└── run.sh                   # Démarrage tout-en-un (legacy, préférer svc.sh)
+```

-### 🚀 **Composants Production-Ready**
- **Agent V0** : Capture cross-platform + Encryption ✅
- **Server API** : Processing pipeline + Web dashboard ✅  
- **Analytics System** : Monitoring + Insights + Reporting ✅
- **Self-Healing** : Automatic adaptation + Recovery ✅
+## Tests

-## 🤝 Contribution
+```bash
+source .venv/bin/activate

-Voir `.kiro/specs/workflow-graph-implementation/tasks.md` pour les tâches en cours.
+# Tests rapides (hors marqueur slow)
+pytest -m "not slow" -q

-## 📄 Licence
+# Tests d'intégration (streaming, pipeline)
+pytest tests/integration/ -q

-Propriétaire - Tous droits réservés
+# Tests E2E
+pytest tests/test_pipeline_e2e.py -q
+```
+
+Quelques tests legacy sont connus comme cassés — voir la mémoire projet et
+`docs/` pour la liste.
+
+## Documentation
+
+- [`docs/STATUS.md`](docs/STATUS.md) — état réel par module
+- [`docs/DEV_SETUP.md`](docs/DEV_SETUP.md) — tâches d'administration (worktrees, build)
+- [`docs/VISION_RPA_INTELLIGENT.md`](docs/VISION_RPA_INTELLIGENT.md) — cahier des charges
+- [`docs/PLAN_ACTEUR_V1.md`](docs/PLAN_ACTEUR_V1.md) — architecture 3 niveaux (Macro / Méso / Micro)
+- [`docs/CONFORMITE_AI_ACT.md`](docs/CONFORMITE_AI_ACT.md) — journalisation, floutage, rétention
+
+## Concepts clés
+
+- **RPA 100 % vision** : pas de coordonnées fixes ; l'agent localise un
+  élément par ce qu'il voit (label + contexte visuel), pas par `x,y`.
+- **Apprentissage progressif** : mode shadow → assisté → autonome, validé
+  par supervision humaine sur les échecs.
+- **LLM 100 % local** : Ollama sur la machine. Aucun appel cloud dans le
+  pipeline par défaut (cf. feedback projet `feedback_local_only.md`).
+
+## Licence
+
+Propriétaire — tous droits réservés.
--- a/agent_v0/deploy_windows.py
+++ b/agent_v0/deploy_windows.py
@@ -2,6 +2,17 @@
 """
 deploy_windows.py — Script de packaging du client Windows pour Agent V1.

+⚠️ OBSOLÈTE (avril 2026)
+   Le build officiel du package Windows passe par ``deploy/build_package.sh``
+   (à la racine du repo) qui lit directement ``agent_v0/agent_v1/`` et évite
+   les clones intermédiaires. Ce script est conservé pour référence mais son
+   manifeste ``FILE_MANIFEST`` est incomplet : il n'inclut pas
+   ``system_dialog_guard.py``, ``persistent_buffer.py``, ``recovery.py``,
+   ``uia_helper.py``, ``grounding.py``, ``policy.py``,
+   ``vision/blur_sensitive.py``, ``vision/system_info.py``,
+   ``ui/chat_window.py``, ``ui/capture_server.py``, ``ui/shared_state.py``.
+   Ne PAS l'utiliser pour un packaging réel.
+
 Copie uniquement les fichiers nécessaires au fonctionnement de l'agent
 sur le PC cible (Windows), sans le serveur ni les dépendances lourdes.

--- a/deploy/build_package.sh
+++ b/deploy/build_package.sh
@@ -146,8 +146,14 @@ REQUIRED_FILES=(
    "agent_v1/core/__init__.py"
    "agent_v1/core/captor.py"
    "agent_v1/core/executor.py"
+    "agent_v1/core/grounding.py"
+    "agent_v1/core/policy.py"
+    "agent_v1/core/recovery.py"
+    "agent_v1/core/system_dialog_guard.py"
+    "agent_v1/core/uia_helper.py"
    "agent_v1/network/__init__.py"
    "agent_v1/network/streamer.py"
+    "agent_v1/network/persistent_buffer.py"
    "agent_v1/session/__init__.py"
    "agent_v1/session/storage.py"
    "agent_v1/ui/__init__.py"
@@ -156,6 +162,8 @@ REQUIRED_FILES=(
    "agent_v1/ui/chat_window.py"
    "agent_v1/ui/capture_server.py"
    "agent_v1/ui/notifications.py"
+    "agent_v1/ui/activity_panel.py"
+    "agent_v1/ui/messages.py"
    "agent_v1/vision/__init__.py"
    "agent_v1/vision/capturer.py"
    "agent_v1/vision/blur_sensitive.py"
--- a/docs/DEV_SETUP.md
+++ b/docs/DEV_SETUP.md
@@ -0,0 +1,107 @@
+# DEV_SETUP — Guide développeur
+
+Ce document recense les tâches d'administration du dépôt qui ne sont pas couvertes
+par `README.md` (destiné aux utilisateurs) mais nécessaires au quotidien.
+
+## Sommaire
+
+- [Environnement Python](#environnement-python)
+- [Services locaux](#services-locaux)
+- [Worktrees Claude Code](#worktrees-claude-code)
+- [Build du package Windows](#build-du-package-windows)
+
+---
+
+## Environnement Python
+
+- Venv du projet : `.venv/` (à la racine du repo)
+- Python supporté : 3.10 à 3.12
+
+```bash
+python3 -m venv .venv
+source .venv/bin/activate
+pip install -r requirements.txt
+```
+
+## Services locaux
+
+Utiliser `./svc.sh` pour piloter tous les services. La carte des ports est
+dans `services.conf`.
+
+```bash
+./svc.sh status          # État de tous les services
+./svc.sh start streaming # Démarrer le serveur Agent V1 (port 5005)
+./svc.sh restart api     # Redémarrer l'API (port 8000)
+./svc.sh stop            # Tout arrêter
+```
+
+## Worktrees Claude Code
+
+La CLI Claude Code peut créer des worktrees git dans `.claude/worktrees/` pour
+exécuter des agents parallèles sur des branches isolées. Ces dossiers peuvent
+occuper plusieurs centaines de Mo chacun et polluer les grep.
+
+### Vérifier l'état des worktrees
+
+```bash
+# Worktrees actifs vs branches git
+git worktree list
+git branch | grep worktree
+
+# Espace disque consommé
+du -sh .claude/worktrees/* 2>/dev/null
+```
+
+### Supprimer un worktree proprement
+
+```bash
+# 1) Retirer l'entrée git (libère le lock dans .git/worktrees/)
+git worktree remove .claude/worktrees/agent-<hash>
+
+# 2) Si le dossier persiste (worktree orphelin), forcer le retrait
+git worktree remove --force .claude/worktrees/agent-<hash>
+
+# 3) Supprimer les branches worktree abandonnées
+git branch -D worktree-agent-<hash>
+```
+
+### Nettoyage global
+
+```bash
+# Supprimer TOUS les worktrees et leurs branches associées
+for wt in .claude/worktrees/*/; do
+    hash=$(basename "$wt")
+    git worktree remove --force "$wt" 2>/dev/null
+done
+git branch | grep worktree-agent- | xargs -r git branch -D
+git worktree prune -v
+
+# Nettoyer les branches orphelines (worktree supprimé mais branche subsiste)
+git branch | grep worktree-agent- | xargs -r git branch -D
+```
+
+Le dossier `.claude/` est gitignoré — il ne sera jamais committé.
+
+## Build du package Windows
+
+Le package de déploiement pour le PC Windows des utilisateurs est généré par
+`deploy/build_package.sh`. Il embarque `agent_v0/agent_v1/` directement (pas
+de staging intermédiaire).
+
+```bash
+./deploy/build_package.sh          # Build standard
+./deploy/build_package.sh --clean  # Nettoyer avant de builder
+```
+
+Le script vérifie la présence de tous les fichiers Python requis via la liste
+`REQUIRED_FILES`. Si vous ajoutez un nouveau module Python critique côté agent
+(ex: dans `agent_v1/core/` ou `agent_v1/network/`), **ajoutez-le à
+`REQUIRED_FILES`** pour qu'un fichier manquant fasse échouer le build plutôt
+que de produire un zip incomplet.
+
+### Note historique : `agent_v0/deploy/windows_client/`
+
+Ce dossier a été créé par `agent_v0/deploy_windows.py` comme staging de build
+et s'est désynchronisé. Il a été supprimé en avril 2026 — le build officiel
+passe désormais par `deploy/build_package.sh` qui lit directement
+`agent_v0/agent_v1/`.
--- a/docs/STATUS.md
+++ b/docs/STATUS.md
@@ -0,0 +1,112 @@
+# STATUS — État réel du projet RPA Vision V3
+
+> Dernière mise à jour : 14 avril 2026
+>
+> Ce document remplace les affirmations marketing du README historique.
+> Il décrit l'état réel des modules, sans embellissement.
+
+## Positionnement
+
+**POC avancé** — certaines briques sont fonctionnelles de bout en bout
+(capture, streaming, premier replay E2E sur Notepad), d'autres sont en cours
+de stabilisation ou à l'état d'ébauche. Le projet n'est pas « production-ready ».
+
+Les fonctionnalités ci-dessous sont documentées sans minimiser les limites.
+
+## Légende
+
+- **opérationnel** : testé, utilisé régulièrement, pas de régression récente connue
+- **alpha** : branché et fonctionnel sur un cas d'usage de référence, manque
+  de recul sur la généralisation
+- **en cours** : en développement actif, comportement instable
+- **non démarré** : planifié, pas encore de code significatif
+
+## Vue d'ensemble par module
+
+| Module / fonctionnalité | État | Commentaire |
+|---|---|---|
+| Capture d'écran + événements (Agent V1 Windows) | opérationnel | `agent_v0/agent_v1/` — systray, streaming vers serveur |
+| Streaming server (`agent_v0/server_v1/`) | opérationnel | FastAPI port 5005, sessions en mémoire |
+| Stockage sessions (`RawSession`) | opérationnel | JSON + screenshots, rotation manuelle |
+| Détection UI (`core/detection/`) | alpha | Cascade VLM + OCR + templates, sensible au modèle choisi |
+| Embedding & FAISS (`core/embedding/`) | alpha | CLIP ViT-B/32 + index Flat, pas testé à grande échelle |
+| Workflow Graph (`core/graph/`) | alpha | Construction depuis sessions, matching heuristique |
+| Replay E2E (`agent_v0/server_v1/api_stream.py`) | alpha | Premier succès le 13 avril 2026 sur Notepad, asymétries strict/legacy connues |
+| Mode apprentissage supervisé | alpha | Pause sur échec répété, demande d'intervention humaine |
+| TargetMemoryStore (Phase 1 apprentissage) | alpha | Schéma SQLite en place, DB vide jusqu'au premier replay complet |
+| Grounding visuel (UI-TARS, gemma4, qwen3-vl) | alpha | Switch de modèle via `.env` (`RPA_VLM_MODEL`) |
+| SomEngine (YOLO + docTR + VLM) | alpha | Intégré, dormant dans la cascade par défaut |
+| Web Dashboard (port 5001) | alpha | Flask + SocketIO, fonctionnel mais non durci |
+| Visual Workflow Builder (VWB, ports 5002 + 3002) | en cours | Catalogue d'actions, UI React. Bugs DB runtime connus |
+| Agent Chat (port 5004) | alpha | Planner autonome, basé LLM local |
+| Module auth (`core/auth/`) | alpha | Vault Fernet + TOTP, CLI seul, pas d'intégration UI |
+| Federation (`core/federation/`) | alpha | Export/import de LearningPacks, pas de test terrain |
+| GPU Resource Manager (`core/gpu/`) | alpha | Gestion Ollama + warmup modèles, code utilisé mais peu testé |
+| Self-healing / recovery | en cours | Heuristiques présentes, comportement global non stabilisé |
+| Analytics / reporting | en cours | Prototype, pas de frontend finalisé |
+| Tests end-to-end | en cours | 1 replay E2E réussi, 56 tests d'intégration verts hors cas connus |
+| Deploy Windows (`deploy/build_package.sh`) | opérationnel | Produit `Lea_v<version>.zip`, vérification des fichiers requis |
+| Conformité AI Act (journalisation, floutage, rétention logs) | alpha | Mécanismes en place, audit formel non fait |
+
+## Limites connues (non exploitables comme failles)
+
+- Plusieurs copies parallèles du code agent ont existé (source, staging
+  Windows, worktrees) avec risque de divergence. Le staging Windows obsolète
+  a été supprimé ; le build officiel passe par `deploy/build_package.sh`.
+- La base `data/learning/target_memory.db` reste vide tant qu'un replay
+  complet n'a pas été cristallisé — l'apprentissage est câblé mais pas
+  encore éprouvé.
+- Certaines asymétries entre chemins « strict » et « legacy » dans
+  `api_stream.py` peuvent faire retomber une erreur en mode strict vers
+  le retry+stop legacy au lieu de la pause d'apprentissage.
+- Le worker de compilation sessions → `ExecutionPlan` (port 5099) n'est pas
+  lancé par défaut — les sessions enregistrées ne sont pas compilées
+  automatiquement.
+- Le VWB présente des bugs en écriture DB identifiés et documentés.
+- La détection VLM est sensible au choix de modèle ; le défaut est
+  `gemma4:latest` (cf. `.env.example`).
+
+## Modèles utilisés
+
+Définis dans `.env` (voir `.env.example`) :
+
+| Variable | Valeur par défaut | Rôle |
+|---|---|---|
+| `RPA_VLM_MODEL` | `gemma4:latest` | Modèle VLM principal (Ollama) |
+| `VLM_MODEL` | `gemma4:latest` | Alias de compatibilité |
+| `CLIP_MODEL` | `ViT-B-32` | Embeddings visuels |
+| `CLIP_PRETRAINED` | `openai` | Poids pré-entraînés |
+| `VLM_ENDPOINT` | `http://localhost:11434` | Ollama local |
+
+Modèles alternatifs testés : `qwen3-vl:8b`, `ui-tars` (grounding direct).
+Aucun appel cloud par défaut — tout passe par Ollama local.
+
+## Infrastructure
+
+- **OS cible serveur** : Linux (Ubuntu 24.04 testé)
+- **GPU recommandé** : NVIDIA (ex. RTX 5070) pour l'inférence VLM locale
+- **OS cible client** : Windows 10/11 (Agent V1)
+- **Python** : 3.10 à 3.12
+- **Ollama** : service local obligatoire
+
+## Ports utilisés (source : `services.conf`)
+
+| Port | Service |
+|---|---|
+| 8000 | API Server (core upload) |
+| 5001 | Web Dashboard |
+| 5002 | VWB Backend (Flask) |
+| 5003 | Monitoring |
+| 5004 | Agent Chat |
+| 5005 | Streaming Server (Agent V1) |
+| 5006 | Session Cleaner |
+| 5099 | Worker de compilation (optionnel) |
+| 3002 | VWB Frontend (Vite/React) |
+
+## Prochaines étapes prioritaires
+
+1. Stabiliser le replay E2E sur 3 applications métier différentes
+2. Alimenter `TargetMemoryStore` via des replays réussis réels
+3. Harmoniser les branches `strict` / `legacy` dans `api_stream.py`
+4. Durcir VWB ou pivoter vers un outil dédié plus simple
+5. Activer le worker de compilation sessions → ExecutionPlan