docs: add POC specs, handoffs, and research notes
This commit is contained in:
Dom
257
docs/plans/BACKLOG_HORIZON1_LEA_FIRST_2026-05-19.md
Normal file
257
docs/plans/BACKLOG_HORIZON1_LEA_FIRST_2026-05-19.md
Normal file
@@ -0,0 +1,257 @@
|
||||
# Backlog Horizon 1 Lea-first -- 2026-05-19
|
||||
|
||||
**Objet**
|
||||
- Transformer `Horizon 1` en backlog d'execution concret.
|
||||
- Se limiter au coeur produit `Lea-first`.
|
||||
- Ne pas reintroduire `VWB` ou la demo comme reference produit.
|
||||
|
||||
## 1. Definition de done
|
||||
|
||||
Horizon 1 est termine quand les conditions suivantes sont vraies :
|
||||
|
||||
- un workflow Lea-first canonique peut etre capture puis rejoue sans passer par `VWB`
|
||||
- `pause -> intervention humaine -> resume` est fiable et comprehensible
|
||||
- les succes, echecs et corrections humaines alimentent vraiment la memoire persistante
|
||||
- on dispose d'un gate minimal reproductible avant toute session terrain
|
||||
- on dispose d'un runbook operatoire court pour lancer, observer et reprendre un replay
|
||||
|
||||
## 2. Baseline technique au 2026-05-19
|
||||
|
||||
### Pipeline reel retenu
|
||||
|
||||
Le chemin nominal reste :
|
||||
|
||||
`capture Lea -> stream serveur -> replay direct -> verification -> memory`
|
||||
|
||||
Fichiers pivots :
|
||||
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
- `agent_v0/agent_v1/core/executor.py`
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/stream_processor.py`
|
||||
- `agent_v0/server_v1/resolve_engine.py`
|
||||
- `agent_v0/server_v1/replay_learner.py`
|
||||
- `agent_v0/server_v1/replay_memory.py`
|
||||
- `core/learning/target_memory_store.py`
|
||||
|
||||
### Gate minimal deja vert
|
||||
|
||||
Tests executes localement le 2026-05-19 :
|
||||
|
||||
- `pytest -q tests/integration/test_replay_resume_acknowledgments.py tests/integration/test_loop_detector_replay.py tests/unit/test_target_memory_store.py`
|
||||
- `pytest -q tests/integration/test_stream_processor.py tests/smoke/test_smoke_e2e_minimal.py`
|
||||
- `pytest -q tests/integration/test_pause_for_human.py tests/unit/test_replay_critic.py`
|
||||
|
||||
Conclusion :
|
||||
|
||||
- les briques `resume`, `loop detector`, `target memory`, `stream processor` et le smoke critique offline sont deja exploitables comme premier garde-fou
|
||||
- `pause_for_human` et `replay_critic` peuvent rejoindre ce garde-fou immediatement
|
||||
- il reste un warning `pytest-asyncio` de configuration de boucle, non bloquant pour Horizon 1
|
||||
- `tests/unit/test_policy_grounding_recovery_learning.py` n'est pas encore un gate portable : 4 tests `RecoveryEngine` tombent localement sur `ModuleNotFoundError: pynput`
|
||||
- ce gate ne prouve pas encore le replay Windows reel de bout en bout
|
||||
|
||||
## 3. Ordre d'attaque
|
||||
|
||||
### Chantier H1-A -- Stabiliser le replay nominal
|
||||
|
||||
**But**
|
||||
- faire du replay direct le chemin assume et observable
|
||||
|
||||
**Fichiers cibles**
|
||||
- `agent_v0/server_v1/stream_processor.py`
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
- `agent_v0/agent_v1/core/executor.py`
|
||||
|
||||
**Taches**
|
||||
- figer un workflow Lea-first canonique de reference
|
||||
- verifier que `build_replay_from_raw_events(...)` produit des actions propres sur ce workflow
|
||||
- verifier le couplage `session_id / machine_id / replay queue` pour eviter les confusions inter-machines
|
||||
- tracer explicitement le passage `capture finalisee -> replay injecte -> action poll -> resultat recu`
|
||||
|
||||
**Acceptation**
|
||||
- a partir d'une capture Lea, le serveur injecte une queue de replay exploitable sans bridge VWB
|
||||
- l'agent recupere les actions avec le bon `machine_id`
|
||||
- l'index courant du replay et le nombre d'actions restantes restent coherents jusqu'a completion ou pause
|
||||
|
||||
**Gate associe**
|
||||
- `tests/integration/test_stream_processor.py`
|
||||
- `tests/smoke/test_smoke_e2e_minimal.py`
|
||||
|
||||
### Chantier H1-B -- Fiabiliser la pause supervisee
|
||||
|
||||
**But**
|
||||
- rendre deterministe et lisible la boucle `pause / aide humaine / reprise`
|
||||
|
||||
**Fichiers cibles**
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/loop_detector.py`
|
||||
- `agent_v0/agent_v1/network/feedback_bus.py`
|
||||
- `agent_v0/agent_v1/ui/chat_window.py`
|
||||
|
||||
**Taches**
|
||||
- formaliser la matrice des causes de `paused_need_help`
|
||||
- distinguer les pauses qui doivent reinjecter l'action de celles qui ne doivent pas la reinjecter
|
||||
- verifier l'alignement entre payload serveur, bulle Lea et endpoint `/replay/{id}/resume`
|
||||
- verifier que les acquittements de `safety_checks` restent obligatoires quand requis
|
||||
|
||||
**Causes a couvrir explicitement**
|
||||
- `pause_for_human`
|
||||
- `target_not_found`
|
||||
- `wrong_window`
|
||||
- `no_screen_change_strict`
|
||||
- `system_dialog`
|
||||
- `loop_detected`
|
||||
|
||||
**Acceptation**
|
||||
- chaque pause expose une raison, un message et un comportement de reprise clairs
|
||||
- `resume` ne relance pas une action qui etait une pause intentionnelle
|
||||
- `cancel` vide proprement la queue
|
||||
- aucun cas de pause ne laisse le replay dans un etat ambigu
|
||||
|
||||
**Gate associe**
|
||||
- `tests/integration/test_replay_resume_acknowledgments.py`
|
||||
- `tests/integration/test_loop_detector_replay.py`
|
||||
- `tests/integration/test_pause_for_human.py`
|
||||
|
||||
### Chantier H1-C -- Faire apprendre la memoire de replay
|
||||
|
||||
**But**
|
||||
- s'assurer que la boucle d'apprentissage est branchee sur le runtime reel, pas seulement documentee
|
||||
|
||||
**Fichiers cibles**
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/replay_learner.py`
|
||||
- `agent_v0/server_v1/replay_memory.py`
|
||||
- `agent_v0/server_v1/resolve_engine.py`
|
||||
- `core/learning/target_memory_store.py`
|
||||
|
||||
**Taches**
|
||||
- verifier le contrat `actual_position` entre agent et serveur
|
||||
- verifier que `memory_record_success()` ne se declenche qu'apres succes verifie
|
||||
- verifier que `memory_record_failure()` decremente bien la fiabilite utile
|
||||
- verifier que `record_human_correction()` nourrit bien `target_memory.db`
|
||||
- tracer un cas de `memory_lookup HIT` jusqu'a la resolution suivante
|
||||
|
||||
**Acceptation**
|
||||
- au moins un cas reel montre la sequence :
|
||||
`target_not_found ou no_screen_change_strict -> correction humaine -> stockage -> hit memoire sur replay suivant`
|
||||
- les fichiers `data/learning/replay_results/*.jsonl` et `data/learning/events/*/resolution_events.jsonl` sont utiles et lisibles
|
||||
- `target_memory.db` contient des entrees correspondant a des cibles reelles du workflow canonique
|
||||
|
||||
**Gate associe**
|
||||
- `tests/unit/test_target_memory_store.py`
|
||||
- `tests/unit/test_policy_grounding_recovery_learning.py`
|
||||
- `tests/unit/test_replay_critic.py`
|
||||
|
||||
### Chantier H1-D -- Runbook et gate terrain
|
||||
|
||||
**But**
|
||||
- disposer d'un protocole d'execution simple avant toute session reelle
|
||||
|
||||
**Fichiers cibles**
|
||||
- `agent_v0/deploy/test_replay_diag.py`
|
||||
- `tests/smoke/test_smoke_e2e_minimal.py`
|
||||
- nouvelle doc de runbook Lea-first
|
||||
|
||||
**Taches**
|
||||
- definir un gate local minimum avant session terrain
|
||||
- definir un workflow canonique a jouer a blanc avant toute session utilisateur
|
||||
- ecrire une checklist courte `avant capture / avant replay / pendant pause / apres correction`
|
||||
- rendre explicites les artefacts a conserver apres un incident
|
||||
|
||||
**Acceptation**
|
||||
- on sait dire en moins de 5 minutes si la machine est "prete a rejouer"
|
||||
- on sait quoi collecter en cas d'echec sans improviser
|
||||
- on sait faire une reprise propre apres une pause supervisee
|
||||
|
||||
**Gate associe**
|
||||
- `python agent_v0/deploy/test_replay_diag.py`
|
||||
- `pytest -q tests/smoke/test_smoke_e2e_minimal.py`
|
||||
|
||||
## 4. Sequence immediate
|
||||
|
||||
### Etape 1 -- Geler le gate Horizon 1
|
||||
|
||||
- conserver les 5 fichiers de test deja verts comme premier noyau
|
||||
- ajouter maintenant `tests/integration/test_pause_for_human.py`
|
||||
- ajouter maintenant `tests/unit/test_replay_critic.py`
|
||||
- garder `tests/unit/test_policy_grounding_recovery_learning.py` en seconde couronne tant que la dependance `pynput` n'est pas geree proprement pour le contexte de test
|
||||
|
||||
### Etape 2 -- Choisir le workflow canonique
|
||||
|
||||
- un seul workflow Lea-first
|
||||
- court
|
||||
- peu de fenetres
|
||||
- au moins un clic, une saisie, une verification, une pause possible
|
||||
|
||||
### Etape 3 -- Prioriser les corrections
|
||||
|
||||
Ordre de traitement :
|
||||
|
||||
1. ambiguite de replay `session_id / machine_id / queue`
|
||||
2. cas de pause/reprise incoherents
|
||||
3. apprentissage non persiste ou non reutilise
|
||||
4. runbook et collecte d'artefacts
|
||||
|
||||
## 5. Integration de l'audit Claude
|
||||
|
||||
Reference :
|
||||
|
||||
- [AUDIT_LEA_FIRST_RUNTIME_2026-05-19.md](/home/dom/ai/rpa_vision_v3/docs/AUDIT_LEA_FIRST_RUNTIME_2026-05-19.md)
|
||||
|
||||
Important :
|
||||
|
||||
- dans ce repo, `agent_v0/` reste le **conteneur de chemin** du code courant
|
||||
- l'audit qui parle de `agent_v0/agent_v1` et `agent_v0/server_v1` parle donc bien du runtime actuel
|
||||
|
||||
### Points valides
|
||||
|
||||
- `record_human_correction()` est reellement casse
|
||||
- la capture via `mss.monitors[1]` n'a pas de garde contre des dimensions aberrantes
|
||||
- `_replay_active` est mal gere cote client pendant `replay_paused=true`
|
||||
|
||||
### Points a corriger dans la formulation
|
||||
|
||||
- le replay direct **existe bien** via `POST /api/v1/traces/stream/replay-session`
|
||||
- ce endpoint charge `live_events.jsonl`, appelle `build_replay_from_raw_events(...)`, puis injecte la queue de replay
|
||||
- en revanche, `finalize` n'enchaine pas ce chemin automatiquement et la surface produit reste morcelee
|
||||
- `build_workflow_replay()` est bien orphelin, mais cela ne prouve pas que le replay direct n'existe pas
|
||||
|
||||
- le gating memoire sur `window_title` est reel
|
||||
- mais sur le flux Lea-first natif, `build_replay_from_raw_events(...)` propage deja `window_title` dans les clics enrichis
|
||||
- le risque est donc surtout : actions non enrichies, cas degradés, et workflows non Lea-first ou incompletés
|
||||
|
||||
- `core/learning/*` non branche au runtime serveur est un constat juste
|
||||
- mais pour Horizon 1, ce n'est pas un blocage du coeur produit si on assume que `TargetMemoryStore` est la seule boucle d'apprentissage necessaire court terme
|
||||
|
||||
### Reclassement pratique pour Horizon 1
|
||||
|
||||
- `P0 reel` : correction humaine cassee
|
||||
- `P0 reel` : corruption possible des captures moniteur
|
||||
- `P1 reel` : pause/reprise desynchronisee cote client
|
||||
- `P1 structurant` : absence de chainage produit propre `finalize -> replay-session`
|
||||
- `P1 risque` : memoire trop dependante de `window_title`
|
||||
- `P2 assume` : branches `core/learning/*` hors chemin nominal court terme
|
||||
|
||||
## 6. Ce que je retiens pour la suite immediate
|
||||
|
||||
Ordre de traitement mis a jour :
|
||||
|
||||
1. corriger `record_human_correction()` pour rouvrir l'apprentissage supervise
|
||||
2. blinder la capture moniteur contre les dimensions aberrantes
|
||||
3. corriger `_replay_active` sur `action=null + replay_paused=true`
|
||||
4. definir si `finalize` doit proposer ou lancer explicitement `replay-session`
|
||||
5. renforcer le fallback `window_title` pour le record / lookup memoire
|
||||
|
||||
## 7. Premier ticket d'execution
|
||||
|
||||
Le premier ticket que je lancerais sans attendre est :
|
||||
|
||||
**"Corriger `record_human_correction()` et valider un vrai cycle correction -> target_memory.db -> hit memoire."**
|
||||
|
||||
Pourquoi :
|
||||
|
||||
- c'est le bug le plus net et le plus rentable de l'audit
|
||||
- il touche directement la promesse produit Lea-first
|
||||
- il fournit ensuite un cas de validation concret pour Horizon 1
|
||||
313
docs/plans/CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md
Normal file
313
docs/plans/CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md
Normal file
@@ -0,0 +1,313 @@
|
||||
# Cadrage coeur produit Lea -- 2026-05-19
|
||||
|
||||
**But**
|
||||
- Repartir du vrai produit.
|
||||
- Ne pas confondre le coeur `Lea-first` avec la demo recente ni avec le VWB.
|
||||
- Distinguer ce qui est **branche au runtime**, ce qui est **partiellement branche**, et ce qui releve surtout de `VWB/demo/veille`.
|
||||
|
||||
## 1. Definition du coeur produit
|
||||
|
||||
Le coeur produit n'est pas :
|
||||
- un canvas de creation manuelle de workflows
|
||||
- un assembleur de demo
|
||||
- un bench de modeles
|
||||
|
||||
Le coeur produit est :
|
||||
- **un agent local Lea** qui observe un humain,
|
||||
- **un serveur de streaming/replay** qui reconstruit une procedure exploitable,
|
||||
- **une boucle d'apprentissage** qui s'ameliore avec les replays, les verifications et les corrections humaines.
|
||||
|
||||
En une ligne :
|
||||
|
||||
`capture Lea -> streaming serveur -> reconstruction procedure -> replay supervise -> apprentissage persistant`
|
||||
|
||||
## 2. Ce qui est reellement branche aujourd'hui
|
||||
|
||||
### A. Capture Lea -> serveur : OUI, c'est le vrai chemin de base
|
||||
|
||||
Cote client :
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
- `agent_v0/agent_v1/core/captor.py`
|
||||
- `agent_v0/agent_v1/network/streamer.py`
|
||||
|
||||
Ce que fait Lea aujourd'hui :
|
||||
- capture evenements clavier/souris
|
||||
- capture screenshots/crops
|
||||
- ajoute du contexte UIA et fenetre
|
||||
- streame vers le serveur via :
|
||||
- `/register`
|
||||
- `/event`
|
||||
- `/image`
|
||||
- `/finalize`
|
||||
|
||||
Conclusion :
|
||||
- **la capture et le streaming Lea sont bien le socle produit deja branche**
|
||||
|
||||
### B. Reconstruction immediate d'un replay depuis la capture : OUI
|
||||
|
||||
Cote serveur :
|
||||
- `agent_v0/server_v1/stream_processor.py`
|
||||
- fonction `build_replay_from_raw_events(...)`
|
||||
|
||||
Ce chemin prend `live_events.jsonl` et produit directement :
|
||||
- des actions rejouables
|
||||
- des clics enrichis visuellement
|
||||
- des intentions et screenshots attendus
|
||||
- une consolidation avec l'historique d'apprentissage
|
||||
|
||||
Conclusion :
|
||||
- **il existe deja un chemin capture -> replay exploitable sans passer par le VWB**
|
||||
- c'est un candidat fort pour le vrai noyau produit court terme
|
||||
|
||||
### C. Replay d'execution Lea : OUI
|
||||
|
||||
Cote serveur :
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/replay_engine.py`
|
||||
- `agent_v0/server_v1/resolve_engine.py`
|
||||
|
||||
Cote client :
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
- `agent_v0/agent_v1/core/executor.py`
|
||||
|
||||
Ce qui est branche :
|
||||
- le serveur alimente une queue de replay
|
||||
- Lea poll `/replay/next`
|
||||
- Lea execute
|
||||
- le serveur resout les cibles, verifie, enregistre les resultats
|
||||
|
||||
Conclusion :
|
||||
- **le replay Lea pilote par serveur est bien un axe central du produit**
|
||||
|
||||
### D. Apprentissage persistant sur le replay : OUI, mais partiel
|
||||
|
||||
Modules reels :
|
||||
- `agent_v0/server_v1/replay_learner.py`
|
||||
- `agent_v0/server_v1/replay_memory.py`
|
||||
- `core/learning/target_memory_store.py`
|
||||
|
||||
Ce qui est reellement branche :
|
||||
- historisation des resultats d'actions de replay
|
||||
- stockage des corrections humaines
|
||||
- lookup memoire avant cascade de resolution couteuse
|
||||
- enregistrement des succes verifies apres action
|
||||
|
||||
Conclusion :
|
||||
- **la boucle d'apprentissage "apres replay" existe vraiment**
|
||||
- **c'est aujourd'hui le morceau le plus concret de l'apprentissage Lea**
|
||||
|
||||
## 3. Ce qui existe mais n'est pas encore le coeur runtime
|
||||
|
||||
### A. ShadowObserver / ShadowValidator : presents, mais pas au centre
|
||||
|
||||
Modules :
|
||||
- `core/workflow/shadow_observer.py`
|
||||
- `core/workflow/shadow_validator.py`
|
||||
- endpoints `api_stream.py` : `/api/v1/shadow/*`
|
||||
|
||||
Constat important :
|
||||
- le client Lea ne les appelle pas nativement
|
||||
- aucun appelant clair n'apparait dans `agent_v0/agent_v1/`
|
||||
- aucun appelant clair n'apparait non plus dans `visual_workflow_builder/` ou `agent_chat/`
|
||||
|
||||
Conclusion :
|
||||
- **le mode shadow est une brique prometteuse, mais pas encore un flux produit dominant**
|
||||
|
||||
### B. WorkflowIR -> ExecutionPlan : presents, mais pas encore la voie nominale
|
||||
|
||||
Modules :
|
||||
- `core/workflow/ir_builder.py`
|
||||
- `core/workflow/execution_compiler.py`
|
||||
- `agent_v0/server_v1/execution_plan_runner.py`
|
||||
- endpoints `api_stream.py` :
|
||||
- `/api/v1/traces/stream/workflow/compile`
|
||||
- `/api/v1/traces/stream/replay/plan`
|
||||
|
||||
Constat :
|
||||
- ce pipeline est bien code
|
||||
- il compile une session en artefacts plus propres et plus deterministes
|
||||
- mais il n'est pas pilote naturellement par le client Lea
|
||||
- il ne semble pas etre le chemin principal utilise au quotidien
|
||||
|
||||
Conclusion :
|
||||
- **c'est probablement la meilleure direction architecturale**
|
||||
- **ce n'est pas encore le coeur produit effectivement adopte**
|
||||
|
||||
### C. WorkflowPipeline / GraphBuilder / LearningManager : reels, mais plutot couche moteur
|
||||
|
||||
Modules :
|
||||
- `core/pipeline/workflow_pipeline.py`
|
||||
- `core/graph/graph_builder.py`
|
||||
- `core/learning/learning_manager.py`
|
||||
|
||||
Constat :
|
||||
- ce socle exprime tres bien l'ambition du produit
|
||||
- il construit des workflows depuis les sessions
|
||||
- il gere des etats d'apprentissage
|
||||
|
||||
Mais :
|
||||
- `LearningManager` est en memoire, pas le centre d'un flux de promotion produit visible
|
||||
- cette couche n'est pas encore le protocole operatoire dominant Lea
|
||||
|
||||
Conclusion :
|
||||
- **c'est le moteur conceptuel**
|
||||
- **pas encore la boucle produit la plus nette pour les 15 prochains jours**
|
||||
|
||||
## 4. Ce qui releve du VWB, pas du coeur produit
|
||||
|
||||
Le VWB sert aujourd'hui surtout a :
|
||||
- creer ou editer manuellement des workflows
|
||||
- importer des workflows appris
|
||||
- exporter un workflow vers Lea
|
||||
- lancer une execution via proxy vers le streaming server
|
||||
|
||||
Indices forts dans le repo :
|
||||
- `visual_workflow_builder/backend/api_v3/learned_workflows.py`
|
||||
- `visual_workflow_builder/backend/api_v3/execute.py`
|
||||
- `visual_workflow_builder/frontend_v4/src/services/api.ts`
|
||||
|
||||
Le VWB n'est donc pas :
|
||||
- la source unique de l'apprentissage Lea
|
||||
- le protocole naturel de capture du savoir-faire
|
||||
- la definition du produit coeur
|
||||
|
||||
Conclusion :
|
||||
- **le VWB est un outil satellite d'authoring, d'inspection et de bridge**
|
||||
- **il ne doit pas definir la direction du produit Lea-first**
|
||||
|
||||
## 5. Ce qui releve surtout de la demo ou de la veille
|
||||
|
||||
Hors coeur produit immediat :
|
||||
- workflows reconstruits manuellement pour la demo
|
||||
- corrections specifiques a la maquette de demo
|
||||
- benches de modeles et comparatifs
|
||||
- experiments UX ou UX debug non relies a la capture/replay Lea
|
||||
- documentation strategique ou speculative non branchee
|
||||
|
||||
Cela peut avoir de la valeur :
|
||||
- comme preuve
|
||||
- comme R&D
|
||||
- comme materiau commercial
|
||||
|
||||
Mais ce n'est pas le socle a partir duquel il faut juger l'etat du produit.
|
||||
|
||||
## 6. Matrice simple
|
||||
|
||||
### A. Coeur produit branche aujourd'hui
|
||||
- capture client Lea
|
||||
- streaming temps reel
|
||||
- replay serveur -> client Lea
|
||||
- resolution visuelle au runtime
|
||||
- apprentissage persistant post-replay
|
||||
|
||||
### B. Coeur produit partiellement branche
|
||||
- observation shadow pendant l'enregistrement
|
||||
- validation/correction structurée du savoir-faire
|
||||
- compilation systematique en WorkflowIR/ExecutionPlan
|
||||
- promotion explicite observation -> coaching -> autonomie
|
||||
|
||||
### C. Satellite produit
|
||||
- VWB
|
||||
- dashboard de supervision
|
||||
- agent_chat
|
||||
|
||||
### D. Hors coeur / exploration
|
||||
- benches modeles
|
||||
- comparatifs frameworks
|
||||
- documents de vision non encore materialises dans le chemin runtime
|
||||
|
||||
## 7. Ce qui manque pour que Lea "apprenne vraiment"
|
||||
|
||||
### 1. Un chemin unique assume
|
||||
|
||||
Aujourd'hui, plusieurs chemins coexistent :
|
||||
- capture -> replay direct
|
||||
- capture -> GraphBuilder/workflow
|
||||
- capture -> shadow -> WorkflowIR
|
||||
- WorkflowIR -> ExecutionPlan -> replay
|
||||
|
||||
Probleme :
|
||||
- tant qu'un chemin nominal n'est pas assume, l'energie se disperse
|
||||
|
||||
Ce qu'il faut :
|
||||
- choisir un pipeline principal
|
||||
- releguer les autres en support, migration ou R&D
|
||||
|
||||
### 2. Une validation utilisateur native sur le chemin Lea
|
||||
|
||||
Le mode shadow et la validation structurée existent, mais ne semblent pas au centre de l'usage client.
|
||||
|
||||
Ce qu'il faut :
|
||||
- que Lea sache naturellement :
|
||||
- observer
|
||||
- montrer ce qu'elle a compris
|
||||
- recevoir correction/validation
|
||||
- cristalliser un artefact rejouable
|
||||
|
||||
### 3. Une vraie politique de promotion de l'apprentissage
|
||||
|
||||
Le repo contient des concepts d'etat d'apprentissage, mais pas encore un protocole operatoire simple du style :
|
||||
- observe N fois
|
||||
- replaye sous supervision
|
||||
- apprend des corrections
|
||||
- passe en autonomie sur critere
|
||||
|
||||
Ce qu'il faut :
|
||||
- des seuils, des traces, et un etat visible par workflow
|
||||
|
||||
### 4. Une alimentation effective de la memoire
|
||||
|
||||
La memoire persistante est branchee, mais sa valeur depend de :
|
||||
- replays repetes
|
||||
- validations reelles
|
||||
- corrections humaines capturees proprement
|
||||
|
||||
Ce qu'il faut :
|
||||
- 1 ou 2 cas terrain qui nourrissent vraiment la memoire
|
||||
- une verification que la base d'apprentissage grossit utilement
|
||||
|
||||
## 8. Consequence pratique pour la remise en ordre
|
||||
|
||||
Si on parle du vrai produit, il faut travailler dans cet ordre :
|
||||
|
||||
1. **Cartographier et assumer le pipeline nominal Lea-first**
|
||||
2. **Verifier le flux capture -> replay -> apprentissage**
|
||||
3. **Decider ce qui, dans shadow/IR/ExecutionPlan, doit devenir le prochain cran officiel**
|
||||
4. **Sortir le VWB du role de reference produit**
|
||||
5. **Ranger la veille et la demo comme materiaux satellites**
|
||||
|
||||
## 9. Point de depart recommande
|
||||
|
||||
Le bon point de depart n'est pas :
|
||||
- la demo recente
|
||||
- le VWB
|
||||
- la doc speculative
|
||||
|
||||
Le bon point de depart est :
|
||||
- `agent_v0/agent_v1/`
|
||||
- `agent_v0/server_v1/`
|
||||
- `core/learning/`
|
||||
- `core/workflow/` uniquement pour distinguer le branche du promis
|
||||
|
||||
## 10. Decision simple
|
||||
|
||||
**Formulation recommandee**
|
||||
|
||||
"Le produit coeur est Lea qui observe, rejoue et apprend.
|
||||
Le VWB est un outil satellite.
|
||||
Le pipeline nominal doit etre pense depuis Lea, pas depuis le canvas."
|
||||
|
||||
## 11. Sources principales
|
||||
|
||||
- [agent_v0/agent_v1/main.py](/home/dom/ai/rpa_vision_v3/agent_v0/agent_v1/main.py)
|
||||
- [agent_v0/agent_v1/network/streamer.py](/home/dom/ai/rpa_vision_v3/agent_v0/agent_v1/network/streamer.py)
|
||||
- [agent_v0/server_v1/stream_processor.py](/home/dom/ai/rpa_vision_v3/agent_v0/server_v1/stream_processor.py)
|
||||
- [agent_v0/server_v1/api_stream.py](/home/dom/ai/rpa_vision_v3/agent_v0/server_v1/api_stream.py)
|
||||
- [agent_v0/server_v1/replay_learner.py](/home/dom/ai/rpa_vision_v3/agent_v0/server_v1/replay_learner.py)
|
||||
- [agent_v0/server_v1/replay_memory.py](/home/dom/ai/rpa_vision_v3/agent_v0/server_v1/replay_memory.py)
|
||||
- [core/learning/target_memory_store.py](/home/dom/ai/rpa_vision_v3/core/learning/target_memory_store.py)
|
||||
- [core/workflow/shadow_observer.py](/home/dom/ai/rpa_vision_v3/core/workflow/shadow_observer.py)
|
||||
- [core/workflow/ir_builder.py](/home/dom/ai/rpa_vision_v3/core/workflow/ir_builder.py)
|
||||
- [core/workflow/execution_compiler.py](/home/dom/ai/rpa_vision_v3/core/workflow/execution_compiler.py)
|
||||
- [docs/VISION_RPA_INTELLIGENT.md](/home/dom/ai/rpa_vision_v3/docs/VISION_RPA_INTELLIGENT.md)
|
||||
- [docs/CARTE_FONCTIONNELLE_2026-05-08.md](/home/dom/ai/rpa_vision_v3/docs/CARTE_FONCTIONNELLE_2026-05-08.md)
|
||||
@@ -0,0 +1,403 @@
|
||||
# Cartographie executable du pipeline Lea-first -- 2026-05-19
|
||||
|
||||
**Objet**
|
||||
- Decrire le pipeline reel du produit a partir du code branche.
|
||||
- Montrer les artefacts, endpoints, workers et bifurcations.
|
||||
- Distinguer clairement :
|
||||
- le **nominal actuel**
|
||||
- les **branches optionnelles**
|
||||
- les **outils satellites** (`VWB`)
|
||||
|
||||
## 1. Vue d'ensemble
|
||||
|
||||
Le pipeline reel se lit aujourd'hui comme ceci :
|
||||
|
||||
```text
|
||||
Lea (capture locale)
|
||||
-> stream register/event/image/finalize
|
||||
-> live session serveur
|
||||
-> deux suites possibles
|
||||
|
||||
Suite A: replay direct
|
||||
live_events.jsonl
|
||||
-> build_replay_from_raw_events
|
||||
-> queue de replay
|
||||
-> Lea execute
|
||||
-> verify + learning
|
||||
|
||||
Suite B: apprentissage structure
|
||||
session finalisee
|
||||
-> worker VLM
|
||||
-> ScreenStates + embeddings
|
||||
-> GraphBuilder
|
||||
-> workflow JSON appris
|
||||
|
||||
Suite C: compilation V4 (optionnelle)
|
||||
live_events.jsonl
|
||||
-> IRBuilder
|
||||
-> WorkflowIR
|
||||
-> ExecutionCompiler
|
||||
-> ExecutionPlan
|
||||
-> replay/plan
|
||||
```
|
||||
|
||||
## 2. Pipeline nominal actuel
|
||||
|
||||
### Etape 1 -- Capture locale par Lea
|
||||
|
||||
Fichiers principaux :
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
- `agent_v0/agent_v1/core/captor.py`
|
||||
- `agent_v0/agent_v1/network/streamer.py`
|
||||
|
||||
Flux :
|
||||
1. `start_session()` cree `session_id`, `VisionCapturer`, `TraceStreamer`, `EventCaptorV1`.
|
||||
2. `_on_event_bridge()` enrichit chaque action avec :
|
||||
- `machine_id`
|
||||
- `window`
|
||||
- `screenshot_id`
|
||||
- `vision_info`
|
||||
- `window_capture`
|
||||
3. Lea pousse :
|
||||
- les evenements via `push_event`
|
||||
- les screenshots via `push_image`
|
||||
4. un `action_result` est capture 1s apres l'action
|
||||
5. des heartbeats sont envoyes pendant l'enregistrement et hors enregistrement
|
||||
|
||||
Sorties locales utiles :
|
||||
- session de capture locale Lea
|
||||
- crops et screenshots associes
|
||||
- stream HTTP vers le serveur
|
||||
|
||||
### Etape 2 -- Reception et persistance serveur
|
||||
|
||||
Fichiers principaux :
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/live_session_manager.py`
|
||||
|
||||
Endpoints principaux :
|
||||
- `POST /api/v1/traces/stream/register`
|
||||
- `POST /api/v1/traces/stream/event`
|
||||
- `POST /api/v1/traces/stream/image`
|
||||
- `POST /api/v1/traces/stream/finalize`
|
||||
|
||||
Ce qui est persiste :
|
||||
- `data/training/live_sessions/{machine_id}/{session_id}/live_events.jsonl`
|
||||
- `data/training/live_sessions/{machine_id}/{session_id}/shots/*.png`
|
||||
- etat session en memoire via `LiveSessionManager`
|
||||
|
||||
Remarques importantes :
|
||||
- les evenements sont journalises en JSONL
|
||||
- les screenshots `shot_*_full` sont stockes sans analyse GPU immediate
|
||||
- les heartbeats et screenshots de resultat sont gardes, mais pas tous analyses
|
||||
|
||||
### Etape 3 -- Generation immediate d'un replay direct
|
||||
|
||||
Fichiers principaux :
|
||||
- `agent_v0/server_v1/stream_processor.py`
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
|
||||
Fonction centrale :
|
||||
- `build_replay_from_raw_events(...)`
|
||||
|
||||
Ce qu'elle produit a partir de `live_events.jsonl` :
|
||||
- actions normalisees
|
||||
- fusion de texte saisi
|
||||
- sanitization clavier
|
||||
- `visual_mode` pour les clics
|
||||
- `target_spec` enrichi
|
||||
- `expected_screenshot_b64`
|
||||
- `expected_window_title`
|
||||
- `intention`
|
||||
- consolidation avec l'historique du `ReplayLearner`
|
||||
|
||||
Conclusion :
|
||||
- **c'est le chemin le plus direct entre observation Lea et replay exploitable**
|
||||
|
||||
### Etape 4 -- Replay serveur vers Lea
|
||||
|
||||
Fichiers principaux :
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
- `agent_v0/server_v1/replay_engine.py`
|
||||
- `agent_v0/server_v1/resolve_engine.py`
|
||||
- `agent_v0/agent_v1/core/executor.py`
|
||||
- `agent_v0/agent_v1/main.py`
|
||||
|
||||
Endpoints :
|
||||
- `GET /api/v1/traces/stream/replay/next`
|
||||
- `POST /api/v1/traces/stream/replay/result`
|
||||
- `POST /api/v1/traces/stream/replay/{replay_id}/resume`
|
||||
- `POST /api/v1/traces/stream/replay/{replay_id}/cancel`
|
||||
|
||||
Flux :
|
||||
1. le serveur alimente une queue de replay
|
||||
2. Lea poll `replay/next`
|
||||
3. le serveur execute au besoin les actions serveur (`extract_text`, `t2a_decision`, etc.) avant de renvoyer une action visuelle
|
||||
4. Lea execute l'action
|
||||
5. Lea renvoie le resultat
|
||||
6. le serveur verifie et met a jour l'etat du replay
|
||||
|
||||
Conclusion :
|
||||
- **c'est le runtime produit actif**
|
||||
|
||||
### Etape 5 -- Verification et apprentissage post-replay
|
||||
|
||||
Fichiers principaux :
|
||||
- `agent_v0/server_v1/replay_learner.py`
|
||||
- `agent_v0/server_v1/replay_memory.py`
|
||||
- `core/learning/target_memory_store.py`
|
||||
|
||||
Ce qui se passe apres chaque action :
|
||||
- enregistrement du resultat d'action
|
||||
- stockage des corrections humaines
|
||||
- `memory_record_success()` apres succes verifie
|
||||
- `memory_record_failure()` sur echec
|
||||
- `memory_lookup()` avant la cascade de resolution au prochain replay
|
||||
|
||||
Artefacts d'apprentissage :
|
||||
- `data/learning/replay_results/*.jsonl`
|
||||
- `data/learning/events/YYYY-MM-DD/resolution_events.jsonl`
|
||||
- `data/learning/target_memory.db`
|
||||
|
||||
Conclusion :
|
||||
- **la memoire de replay est le bloc d'apprentissage le plus concret aujourd'hui**
|
||||
|
||||
## 3. Branche d'apprentissage structurel via worker
|
||||
|
||||
### Objectif
|
||||
|
||||
Construire un workflow appris a partir d'une session finalisee.
|
||||
|
||||
### Fichiers principaux
|
||||
|
||||
- `agent_v0/server_v1/run_worker.py`
|
||||
- `agent_v0/server_v1/stream_processor.py`
|
||||
- `core/pipeline/workflow_pipeline.py`
|
||||
- `core/graph/graph_builder.py`
|
||||
|
||||
### Flux
|
||||
|
||||
1. `finalize` marque la session et l'ajoute a `data/training/_worker_queue.txt`
|
||||
2. `run_worker.py` lit la queue
|
||||
3. `reprocess_session()` recharge les screenshots `shot_*_full.png`
|
||||
4. `process_screenshot()` produit :
|
||||
- `ScreenState`
|
||||
- embedding
|
||||
- indexation FAISS
|
||||
5. `finalize_session()` convertit vers `RawSession`
|
||||
6. `GraphBuilder.build_from_session(...)` construit le workflow
|
||||
7. `_persist_workflow()` sauvegarde le workflow appris
|
||||
|
||||
Artefacts :
|
||||
- `data/training/_worker_queue.txt`
|
||||
- `data/training/workflows/{machine_id}/wf_*.json`
|
||||
|
||||
Conclusion :
|
||||
- **ce chemin construit du savoir-faire structure, mais en arriere-plan**
|
||||
- **il n'est pas le replay nominal court terme**
|
||||
|
||||
## 4. Branche V4 compilee
|
||||
|
||||
### Objectif
|
||||
|
||||
Transformer une session en artefacts plus propres :
|
||||
- `WorkflowIR`
|
||||
- `ExecutionPlan`
|
||||
|
||||
### Fichiers principaux
|
||||
|
||||
- `core/workflow/ir_builder.py`
|
||||
- `core/workflow/execution_compiler.py`
|
||||
- `agent_v0/server_v1/execution_plan_runner.py`
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
|
||||
### Endpoints
|
||||
|
||||
- `POST /api/v1/traces/stream/workflow/compile`
|
||||
- `POST /api/v1/traces/stream/replay/plan`
|
||||
|
||||
### Flux
|
||||
|
||||
1. lecture de `live_events.jsonl`
|
||||
2. `IRBuilder.build(...)`
|
||||
3. sauvegarde en `data/workflows_ir/*.json`
|
||||
4. `ExecutionCompiler.compile(...)`
|
||||
5. sauvegarde en `data/plans/*.json`
|
||||
6. `execution_plan_to_actions(...)`
|
||||
7. injection dans la queue de replay
|
||||
|
||||
Artefacts :
|
||||
- `data/workflows_ir/*.json`
|
||||
- `data/plans/*.json`
|
||||
|
||||
Conclusion :
|
||||
- **c'est la branche architecturale la plus propre**
|
||||
- **mais elle n'est pas encore pilotee naturellement par Lea**
|
||||
|
||||
## 5. Branche shadow
|
||||
|
||||
### Fichiers principaux
|
||||
|
||||
- `core/workflow/shadow_observer.py`
|
||||
- `core/workflow/shadow_validator.py`
|
||||
- `agent_v0/server_v1/api_stream.py`
|
||||
|
||||
### Endpoints
|
||||
|
||||
- `POST /api/v1/shadow/start`
|
||||
- `POST /api/v1/shadow/stop`
|
||||
- `POST /api/v1/shadow/feedback`
|
||||
- `GET /api/v1/shadow/{session_id}/understanding`
|
||||
- `POST /api/v1/shadow/build`
|
||||
|
||||
### Role
|
||||
|
||||
- observer la capture en temps reel
|
||||
- construire une comprehension incrementale
|
||||
- laisser l'utilisateur valider/corriger
|
||||
- produire un `WorkflowIR`
|
||||
|
||||
### Constat
|
||||
|
||||
- le code est present
|
||||
- le serveur l'accepte
|
||||
- mais le client Lea ne semble pas le piloter nativement
|
||||
|
||||
Conclusion :
|
||||
- **shadow est branche cote serveur**
|
||||
- **shadow n'est pas encore la voie nominale Lea-first**
|
||||
|
||||
## 6. Role reel du VWB
|
||||
|
||||
### Ce qu'il fait
|
||||
|
||||
Fichiers principaux :
|
||||
- `visual_workflow_builder/backend/api_v3/learned_workflows.py`
|
||||
- `visual_workflow_builder/backend/api_v3/execute.py`
|
||||
- `visual_workflow_builder/frontend_v4/src/services/api.ts`
|
||||
|
||||
Role :
|
||||
- lister les workflows appris
|
||||
- les importer dans le VWB
|
||||
- les exporter vers Lea
|
||||
- lancer une execution via proxy
|
||||
|
||||
Conclusion :
|
||||
- **le VWB est un bridge et un outil d'authoring**
|
||||
- **il ne doit pas etre lu comme le pipeline coeur du produit**
|
||||
|
||||
## 7. Artefacts de reference
|
||||
|
||||
### Capture live
|
||||
- `data/training/live_sessions/{machine_id}/{session_id}/live_events.jsonl`
|
||||
- `data/training/live_sessions/{machine_id}/{session_id}/shots/*.png`
|
||||
|
||||
### Sessions serveur en memoire / persistance
|
||||
- `data/training/live_sessions/`
|
||||
- `data/training/live_sessions/...`
|
||||
|
||||
### Queue worker
|
||||
- `data/training/_worker_queue.txt`
|
||||
- `data/training/_replay_active.lock`
|
||||
|
||||
### Workflows appris
|
||||
- `data/training/workflows/{machine_id}/wf_*.json`
|
||||
|
||||
### Pipeline V4
|
||||
- `data/workflows_ir/*.json`
|
||||
- `data/plans/*.json`
|
||||
|
||||
### Apprentissage replay
|
||||
- `data/learning/replay_results/*.jsonl`
|
||||
- `data/learning/events/YYYY-MM-DD/resolution_events.jsonl`
|
||||
- `data/learning/target_memory.db`
|
||||
|
||||
## 8. Ce qui est nominal, ce qui ne l'est pas
|
||||
|
||||
### Nominal actuel
|
||||
- capture Lea
|
||||
- streaming serveur
|
||||
- replay direct
|
||||
- verification
|
||||
- memoire post-replay
|
||||
|
||||
### Non nominal mais reel
|
||||
- worker qui fabrique un workflow appris
|
||||
- compile V4 vers `ExecutionPlan`
|
||||
- shadow avec validation
|
||||
|
||||
### Satellite
|
||||
- import/export VWB
|
||||
- edition manuelle VWB
|
||||
- lancement VWB via proxy
|
||||
|
||||
## 9. Point de decision architectural
|
||||
|
||||
Le repo contient aujourd'hui **trois chemins serieux** :
|
||||
|
||||
### Option A -- assumer le direct replay comme v1 produit
|
||||
|
||||
Chemin :
|
||||
- capture Lea
|
||||
- `build_replay_from_raw_events`
|
||||
- replay
|
||||
- apprentissage memoire
|
||||
|
||||
Avantage :
|
||||
- c'est le plus branche
|
||||
- c'est le plus immediat
|
||||
|
||||
Limite :
|
||||
- moins propre conceptuellement
|
||||
- moins explicite sur la validation du savoir-faire
|
||||
|
||||
### Option B -- promouvoir `shadow -> WorkflowIR -> ExecutionPlan`
|
||||
|
||||
Chemin :
|
||||
- capture Lea
|
||||
- observation shadow
|
||||
- correction/validation
|
||||
- compilation
|
||||
- replay de plan
|
||||
|
||||
Avantage :
|
||||
- pipeline plus propre
|
||||
- meilleure explicitation du savoir-faire
|
||||
|
||||
Limite :
|
||||
- pas encore le flux naturel pilote par le client
|
||||
|
||||
### Option C -- continuer a passer par VWB
|
||||
|
||||
Ce n'est pas recommande comme coeur produit, car cela deplace la reference
|
||||
du produit vers un outil satellite.
|
||||
|
||||
## 10. Recommandation de lecture
|
||||
|
||||
Si l'objectif est de remettre le produit en ordre, lire dans cet ordre :
|
||||
|
||||
1. `agent_v0/agent_v1/main.py`
|
||||
2. `agent_v0/agent_v1/network/streamer.py`
|
||||
3. `agent_v0/server_v1/api_stream.py`
|
||||
4. `agent_v0/server_v1/stream_processor.py`
|
||||
5. `agent_v0/server_v1/replay_learner.py`
|
||||
6. `agent_v0/server_v1/replay_memory.py`
|
||||
7. `core/workflow/ir_builder.py`
|
||||
8. `core/workflow/execution_compiler.py`
|
||||
9. `visual_workflow_builder/backend/api_v3/learned_workflows.py`
|
||||
|
||||
## 11. Conclusion courte
|
||||
|
||||
Le produit reel aujourd'hui n'est pas :
|
||||
- `VWB -> workflow manuel -> replay`
|
||||
|
||||
Le produit reel aujourd'hui est plutot :
|
||||
- `Lea observe -> le serveur reconstruit -> Lea rejoue -> le systeme apprend`
|
||||
|
||||
La vraie question n'est donc pas "faut-il garder le VWB au centre ?"
|
||||
|
||||
La vraie question est :
|
||||
|
||||
**quel pipeline Lea-first on officialise comme voie nominale :**
|
||||
- le replay direct deja branche,
|
||||
- ou la voie `shadow/IR/ExecutionPlan` qu'il faut maintenant faire monter en puissance ?
|
||||
307
docs/plans/FEUILLE_DE_ROUTE_PRODUIT_LEA_FIRST_2026-05-19.md
Normal file
307
docs/plans/FEUILLE_DE_ROUTE_PRODUIT_LEA_FIRST_2026-05-19.md
Normal file
@@ -0,0 +1,307 @@
|
||||
# Feuille de route produit Lea-first -- 2026-05-19
|
||||
|
||||
**But**
|
||||
- Transformer le recadrage technique en arbitrages produit.
|
||||
- Dire clairement ce qui reste au centre, ce qui sort du centre, et ce qu'on fait monter en puissance.
|
||||
- Donner une sequence d'execution lisible pour les prochaines semaines.
|
||||
|
||||
## 1. These produit
|
||||
|
||||
Le produit n'est pas un editeur de workflows.
|
||||
|
||||
Le produit est **Lea**, un agent local qui :
|
||||
- observe un humain,
|
||||
- rejoue une procedure,
|
||||
- demande de l'aide quand elle ne sait pas,
|
||||
- memorise les corrections,
|
||||
- devient progressivement plus autonome.
|
||||
|
||||
La phrase de reference devrait etre :
|
||||
|
||||
**"Lea apprend par observation et se fiabilise par replay supervise."**
|
||||
|
||||
## 2. Decision structurante
|
||||
|
||||
### Ce qu'on garde au centre
|
||||
|
||||
- `agent_v0/agent_v1/`
|
||||
- `agent_v0/server_v1/`
|
||||
- `replay direct` depuis la capture
|
||||
- `verification post-action`
|
||||
- `memoire persistante` de replay
|
||||
- `pause_for_human` et correction humaine
|
||||
|
||||
### Ce qu'on sort du centre
|
||||
|
||||
- `visual_workflow_builder/` comme chemin principal de creation
|
||||
- la demo GHT comme reference produit
|
||||
- les benches modeles comme moteur de roadmap
|
||||
- `agent_chat/` comme facade prioritaire
|
||||
- les analytics non necessaires a la boucle observation -> replay -> apprentissage
|
||||
|
||||
### Ce qu'on garde mais en satellite
|
||||
|
||||
- `VWB` pour inspection, import/export, correction manuelle ponctuelle
|
||||
- dashboard pour supervision
|
||||
- worker `GraphBuilder`
|
||||
- pipeline `WorkflowIR -> ExecutionPlan`
|
||||
|
||||
## 3. Regle d'arbitrage
|
||||
|
||||
Une fonctionnalite est prioritaire si elle renforce au moins un de ces 4 axes :
|
||||
|
||||
1. Lea observe mieux
|
||||
2. Lea rejoue plus surement
|
||||
3. Lea apprend vraiment des corrections
|
||||
4. Lea sait mieux quand s'arreter et demander de l'aide
|
||||
|
||||
Si une fonctionnalite ne renforce aucun de ces 4 axes, elle ne doit pas etre sur le chemin critique.
|
||||
|
||||
## 4. Ce qu'on garde
|
||||
|
||||
### A. Socle produit a conserver
|
||||
|
||||
- capture Lea enrichie (`captor`, `vision`, `streamer`)
|
||||
- streaming serveur
|
||||
- replay pilote par serveur
|
||||
- `resolve_engine`
|
||||
- `ReplayLearner`
|
||||
- `replay_memory`
|
||||
- `TargetMemoryStore`
|
||||
- worker de retraitement session -> workflow appris
|
||||
|
||||
### B. Briques d'avenir a conserver
|
||||
|
||||
- `ShadowObserver`
|
||||
- `ShadowValidator`
|
||||
- `IRBuilder`
|
||||
- `ExecutionCompiler`
|
||||
- `ExecutionPlanRunner`
|
||||
|
||||
Pourquoi les garder :
|
||||
- elles portent la meilleure cible architecturale moyen terme
|
||||
- mais ne doivent pas dicter le court terme tant qu'elles ne sont pas sur le chemin nominal
|
||||
|
||||
## 5. Ce qu'on coupe du centre
|
||||
|
||||
### A. Couper du centre ne veut pas dire supprimer
|
||||
|
||||
On parle ici de **deprioriser**, pas de detruire.
|
||||
|
||||
### B. A sortir du role de reference produit
|
||||
|
||||
- `VWB` comme voie principale de creation de procedures
|
||||
- workflows de demo recables a la main
|
||||
- chasse aux bugs VWB sans impact sur Lea
|
||||
- ajout de nouveaux blocs VWB non necessaires au produit
|
||||
- travaux de design/UI autour d'un canvas qui n'est pas le coeur
|
||||
|
||||
### C. A stopper temporairement
|
||||
|
||||
- benchmarker de nouveaux modeles sans lien avec un echec produit concret
|
||||
- etendre `agent_chat` tant que Lea n'est pas stabilisee
|
||||
- pousser des analytics riches avant d'avoir une boucle d'apprentissage fiable
|
||||
- melanger preuves demo, veille et architecture produit dans la meme priorite
|
||||
|
||||
## 6. Ce qu'on gele
|
||||
|
||||
### Gel court terme
|
||||
|
||||
- nouvelles features VWB
|
||||
- nouvelles experiences demo-centriques
|
||||
- nouvelles couches d'orchestration conversationales
|
||||
- nouvelle dette de docs "vision" sans branchement runtime
|
||||
|
||||
### Autorise pendant le gel
|
||||
|
||||
- correctifs minimaux si un satellite bloque le coeur Lea-first
|
||||
- documentation de clarification
|
||||
- import/export necessaire pour debloquer un usage reel
|
||||
|
||||
## 7. Ce qu'on promeut
|
||||
|
||||
### Promotion immediate
|
||||
|
||||
**Voie nominale v1 produit**
|
||||
|
||||
`capture Lea -> replay direct -> verify -> memory`
|
||||
|
||||
C'est le pipeline a assumer officiellement maintenant.
|
||||
|
||||
### Promotion a court terme
|
||||
|
||||
- correction humaine explicite comme mecanisme produit central
|
||||
- memoire persistante comme actif principal
|
||||
- supervision humaine native
|
||||
- runbook operatoire autour de Lea
|
||||
|
||||
### Promotion a moyen terme
|
||||
|
||||
**Voie nominale v2 cible**
|
||||
|
||||
`capture Lea -> shadow/validation -> WorkflowIR -> ExecutionPlan -> replay`
|
||||
|
||||
Cette voie doit etre promue seulement quand elle devient :
|
||||
- plus simple a operer que le direct replay,
|
||||
- et vraiment pilotee par Lea, pas par un outillage annexe.
|
||||
|
||||
## 8. Produit cible en 3 etages
|
||||
|
||||
### Etage 1 -- Lea Rejoue
|
||||
|
||||
Promesse :
|
||||
- Lea peut rejouer de facon supervisee une procedure observee
|
||||
|
||||
Definition of done :
|
||||
- 1 a 2 workflows reels reproductibles
|
||||
- pause propre sur incertitude
|
||||
- reprise fiable
|
||||
- apprentissage des corrections
|
||||
|
||||
### Etage 2 -- Lea Apprend
|
||||
|
||||
Promesse :
|
||||
- Lea rejoue mieux la 2e fois que la 1ere
|
||||
|
||||
Definition of done :
|
||||
- `target_memory.db` utile et alimentee
|
||||
- hits memoire visibles
|
||||
- baisse des resolutions couteuses sur cas repetes
|
||||
- historique de corrections exploitable
|
||||
|
||||
### Etage 3 -- Lea Comprend
|
||||
|
||||
Promesse :
|
||||
- Lea sait expliciter ce qu'elle a compris pendant l'observation
|
||||
|
||||
Definition of done :
|
||||
- flux shadow/validation utilisable sans bricolage externe
|
||||
- generation d'un artefact rejouable propre
|
||||
- promotion vers `ExecutionPlan`
|
||||
|
||||
## 9. Roadmap pratique
|
||||
|
||||
## Horizon 1 -- Stabiliser le produit reel
|
||||
|
||||
### Objectif
|
||||
|
||||
Faire de `capture -> replay direct -> apprentissage` un vrai produit POC.
|
||||
|
||||
### Priorites
|
||||
|
||||
1. Stabiliser le replay Lea sur 1 ou 2 cas reels
|
||||
2. Rendre la pause supervisee propre et fiable
|
||||
3. Aligner la verification et la memorisation
|
||||
4. S'assurer que les corrections humaines nourrissent vraiment la memoire
|
||||
5. Ecrire le runbook produit Lea
|
||||
|
||||
### Livrables
|
||||
|
||||
- pipeline nominal documente
|
||||
- checklist de pre-replay
|
||||
- 1 workflow canonique Lea-first
|
||||
- 1 base de memoire non vide et utile
|
||||
|
||||
## Horizon 2 -- Native learning loop
|
||||
|
||||
### Objectif
|
||||
|
||||
Faire de la correction humaine un chemin naturel, pas un mecanisme cache.
|
||||
|
||||
### Priorites
|
||||
|
||||
1. rendre visible l'etat "je sais / je ne sais pas"
|
||||
2. exposer clairement les corrections memorisees
|
||||
3. definir les criteres de promotion d'un workflow
|
||||
4. connecter proprement observation, replay et apprentissage
|
||||
|
||||
### Livrables
|
||||
|
||||
- etat d'apprentissage lisible par workflow
|
||||
- journal des corrections humaines
|
||||
- mesure simple du gain de memoire
|
||||
|
||||
## Horizon 3 -- Promotion de la voie compilee
|
||||
|
||||
### Objectif
|
||||
|
||||
Faire monter `shadow -> WorkflowIR -> ExecutionPlan` jusqu'a pouvoir remplacer la voie directe sur certains cas.
|
||||
|
||||
### Priorites
|
||||
|
||||
1. brancher un vrai appelant Lea vers `shadow`
|
||||
2. rendre la validation utilisateur exploitable
|
||||
3. compiler automatiquement une session validee
|
||||
4. comparer replay direct vs replay compile sur un meme cas
|
||||
|
||||
### Livrables
|
||||
|
||||
- 1 flux shadow complet de bout en bout
|
||||
- 1 `ExecutionPlan` reel lance sans bricolage annexe
|
||||
- decision go/no-go sur la promotion en voie nominale
|
||||
|
||||
## 10. Non-objectifs explicites
|
||||
|
||||
Ce qu'on ne cherche pas a faire maintenant :
|
||||
|
||||
- faire du VWB le centre du produit
|
||||
- multiplier les demos au prix du coeur technique
|
||||
- construire un editeur BPMN generaliste
|
||||
- benchmarker tout l'ecosysteme VLM
|
||||
- transformer `agent_chat` en facade principale avant stabilisation Lea
|
||||
|
||||
## 11. Backlog dirigeant
|
||||
|
||||
### Maintenant
|
||||
|
||||
- replay direct fiable
|
||||
- correction humaine exploitable
|
||||
- memoire persistante alimentee
|
||||
- runbook Lea-first
|
||||
|
||||
### Ensuite
|
||||
|
||||
- etat d'apprentissage visible
|
||||
- shadow utile
|
||||
- compile vers `ExecutionPlan`
|
||||
|
||||
### Plus tard
|
||||
|
||||
- VWB comme outil de correction avancée
|
||||
- agent_chat comme surcouche
|
||||
- analytics et reporting riches
|
||||
|
||||
## 12. Formulation de pilotage
|
||||
|
||||
Si tu dois recadrer une session de travail, la phrase a utiliser est :
|
||||
|
||||
**"Est-ce que ce qu'on fait aide Lea a mieux observer, rejouer, apprendre ou demander de l'aide ?"**
|
||||
|
||||
Si la reponse est non :
|
||||
- ce n'est pas sur le chemin critique produit
|
||||
|
||||
## 13. Decision finale recommandee
|
||||
|
||||
### Voie nominale officielle a assumer maintenant
|
||||
|
||||
`Lea capture -> serveur construit un replay direct -> Lea execute -> le systeme apprend`
|
||||
|
||||
### Voie nominale cible a construire
|
||||
|
||||
`Lea capture -> Lea explicite ce qu'elle a compris -> validation -> ExecutionPlan -> replay`
|
||||
|
||||
### Statut du VWB
|
||||
|
||||
`outil satellite`
|
||||
|
||||
Pas :
|
||||
- coeur produit
|
||||
- reference d'architecture
|
||||
- source de verite sur ce qu'est Lea
|
||||
|
||||
## 14. Documents lies
|
||||
|
||||
- [CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md](./CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md)
|
||||
- [CARTOGRAPHIE_EXECUTABLE_PIPELINE_LEA_FIRST_2026-05-19.md](./CARTOGRAPHIE_EXECUTABLE_PIPELINE_LEA_FIRST_2026-05-19.md)
|
||||
- [PLAN_REMISE_EN_ORDRE_POCS_2026-05-19.md](./PLAN_REMISE_EN_ORDRE_POCS_2026-05-19.md)
|
||||
- [STATUS.md](/home/dom/ai/rpa_vision_v3/docs/STATUS.md)
|
||||
111
docs/plans/PLAN_ACTION_COLLEGES_2026-05-25_APRES_C1_G2.md
Normal file
111
docs/plans/PLAN_ACTION_COLLEGES_2026-05-25_APRES_C1_G2.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Plan d'action collegues — apres C1/G2
|
||||
|
||||
Date : 2026-05-25 13:41 Europe/Paris
|
||||
Pilotage : Codex
|
||||
Cible demo : lundi 1 juin 2026
|
||||
|
||||
## Etat factuel
|
||||
|
||||
- `rpa-streaming` 5005 : actif.
|
||||
- `rpa-agent-chat` 5004 : actif apres C1, SocketIO/CORS OK.
|
||||
- Windows `LeaInteractive` : running, `LEA_FEEDBACK_BUS=1`.
|
||||
- Inventaire Ollama v2 : 38 tags, reference actuelle.
|
||||
- `qwen3.5:9b` : calibre avec prefill, resident en `CONTEXT=2048`, `100% GPU`, ~8.6 GB.
|
||||
- `qwen2.5vl:7b-rpa` : point chaud precedent, peut revenir en `CONTEXT=8192` via appels hardcodes.
|
||||
- C2 build replay : baseline mesuree 88-94s -> 22-24s avec skip enrichment, speedup ~4x.
|
||||
|
||||
## Probleme restant prioritaire
|
||||
|
||||
C1b a montre que le flag `AutonomousPlanner` ne suffit pas : `agent_chat` charge encore OWL-v2 via `WorkflowPipeline -> UIDetector` au boot.
|
||||
|
||||
Log observe :
|
||||
|
||||
```text
|
||||
core.detection.owl_detector:Chargement OWL-v2 sur cuda...
|
||||
core.detection.owl_detector:OWL-v2 chargé
|
||||
core.detection.ui_detector:✓ OWL-v2 initialized
|
||||
agent_chat.autonomous_planner:OWL-v2 visual detector skipped at boot
|
||||
```
|
||||
|
||||
VRAM observee apres C1b restart :
|
||||
|
||||
```text
|
||||
agent_chat python3 : 1478 MiB
|
||||
ollama qwen3.5:9b : 7794-8566 MiB selon releve
|
||||
```
|
||||
|
||||
Donc le chantier VRAM n'est pas termine.
|
||||
|
||||
## Repartition
|
||||
|
||||
### Claude — C1c runtime 5004 sans OWL GPU au boot
|
||||
|
||||
Objectif : `rpa-agent-chat` doit servir SocketIO 5004 sans charger OWL-v2/CUDA au boot.
|
||||
|
||||
Actions :
|
||||
|
||||
- Identifier le meilleur point de coupure : `agent_chat/app.py` instancie `WorkflowPipeline()` ; `WorkflowPipeline` instancie `UIDetector` avec `use_owl_detection=True`.
|
||||
- Proposer patch minimal :
|
||||
- soit `WorkflowPipeline(enable_ui_detection=False, enable_vlm=False)` dans `agent_chat` si ces fonctions sont hors chemin narration ;
|
||||
- soit `DetectionConfig.use_owl_detection` pilote par env ;
|
||||
- soit `AGENT_CHAT_ENABLE_OWL=0` applique aussi a `UIDetector`.
|
||||
- Tests unitaires.
|
||||
- Redemarrage seulement apres GO Codex.
|
||||
- Critere : healthcheck OK, SocketIO OK, `agent_chat` VRAM nettement reduite, pas de log `Chargement OWL-v2 sur cuda`.
|
||||
|
||||
### Claude — C2b instrumentation des 22s restantes
|
||||
|
||||
Objectif : savoir ou part le build skip ~22-24s.
|
||||
|
||||
Actions :
|
||||
|
||||
- Ajouter des spans `[PERF]` autour de crops d'ancrage, cleaning, waits, ReplayLearner.
|
||||
- Garder harnais `performance` manuel.
|
||||
- Critere : tableau temps par segment, pas de replay live.
|
||||
|
||||
### Gemini — G2b benchmark qwen3.5 comparatif
|
||||
|
||||
Objectif : dire si `qwen3.5:9b` remplace `qwen2.5vl:7b-rpa`, devient fallback, ou est rejete.
|
||||
|
||||
Actions :
|
||||
|
||||
- Attendre que C1c stabilise VRAM si possible.
|
||||
- Benchmark court puis complet :
|
||||
- qwen3.5 avec prefill obligatoire ;
|
||||
- `num_ctx=2048`, puis 4096 seulement avec GO ;
|
||||
- 5 screenshots reels ;
|
||||
- JSON validity, p50/p95, precision coordonnées, VRAM, offload.
|
||||
- Comparer a `qwen2.5vl:7b-rpa` et `qwen2.5vl:3b` si cela ne perturbe pas un service actif.
|
||||
- Critere : matrice de decision claire.
|
||||
|
||||
### Gemini — G3c patch proposal politique contexte
|
||||
|
||||
Objectif : fermer les retours accidentels en `CONTEXT=8192`.
|
||||
|
||||
Actions :
|
||||
|
||||
- Proposer patch minimal couvrant :
|
||||
- executor Windows hardcodes 8192 ;
|
||||
- `resolve_engine.py` appels sans `num_ctx` ;
|
||||
- constante/env unique `RPA_VLM_DEFAULT_CTX=2048`.
|
||||
- Ne pas appliquer.
|
||||
- Inclure tests attendus et risques.
|
||||
|
||||
### Codex — arbitrage/integration
|
||||
|
||||
Actions :
|
||||
|
||||
- Maintenir healthcheck comme source de verite.
|
||||
- Autoriser ou refuser les restarts.
|
||||
- Integrer uniquement les patchs testables.
|
||||
- Garder le store Ollama en lecture seule.
|
||||
- Composer les decisions modele/runtime dans un plan demo.
|
||||
|
||||
## Ordre d'execution
|
||||
|
||||
1. C1c Claude : enlever le dernier chargement OWL GPU du 5004.
|
||||
2. Healthcheck + VRAM.
|
||||
3. G2b Gemini : benchmark qwen3.5 dans etat VRAM propre.
|
||||
4. G3c Gemini + implementation Codex/Claude : politique contexte 2048.
|
||||
5. C2b Claude : instrumentation 22s restantes.
|
||||
6. Smoke replay controle, seulement apres stabilisation.
|
||||
274
docs/plans/PLAN_PHASE2_TRACE_MANDAT_PROTOCOLS_2026-05-25.md
Normal file
274
docs/plans/PLAN_PHASE2_TRACE_MANDAT_PROTOCOLS_2026-05-25.md
Normal file
@@ -0,0 +1,274 @@
|
||||
# Plan Phase 2 — Trace mandat / protocoles
|
||||
|
||||
Date : 2026-05-25
|
||||
Statut : plan d'exécution chirurgical, issu du modèle v0.3
|
||||
Principe : additif, testable, sans refactor des gros blocs fragiles
|
||||
|
||||
## Objectif
|
||||
|
||||
Faire circuler un contrat commun dans Léa :
|
||||
|
||||
```text
|
||||
mandat -> intention -> scène -> affordance -> geste -> retour -> preuve
|
||||
```
|
||||
|
||||
Le but n'est pas de remplacer le replay actuel. Le but est de l'enrichir pour que les décisions, vérifications et apprentissages parlent la même langue.
|
||||
|
||||
## Règles de conduite
|
||||
|
||||
```text
|
||||
Pas de replay live tant que les correctifs locaux ne sont pas testés.
|
||||
Pas de refactor de api_stream.report_action_result.
|
||||
Pas de refactor de resolve_engine._resolve_target_sync.
|
||||
Pas de réveil brutal de LearningManager / ContinuousLearner.
|
||||
Champs additifs uniquement.
|
||||
Fallback comportement actuel si trace absente.
|
||||
LeaBench et tests unitaires avant runtime live.
|
||||
```
|
||||
|
||||
## Phase 2.0 — sécuriser le bug live Bloc-notes
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
empêcher qu'un rejet sémantique serveur soit contourné par hybrid_text_direct local
|
||||
```
|
||||
|
||||
Actions :
|
||||
|
||||
```text
|
||||
tester GroundingEngine après rejet serveur explicite ;
|
||||
vérifier qu'un simple non-trouvé serveur autorise encore le fallback ;
|
||||
déployer sur Windows seulement après tests ;
|
||||
ne retenter le replay Bloc-notes qu'après relance Léa.
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
le cas close_tab_out_of_recorded_zone ne produit plus de clic local ;
|
||||
le report remonte un échec honnête ou une pause, pas success=True.
|
||||
```
|
||||
|
||||
## Phase 2.1 — objet trace additif
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
créer un objet commun transportable sans changer le comportement runtime
|
||||
```
|
||||
|
||||
Trace minimale :
|
||||
|
||||
```text
|
||||
mandate_id
|
||||
intention_id
|
||||
scene_id
|
||||
affordance_signature
|
||||
expected_retour
|
||||
level_of_delegation
|
||||
```
|
||||
|
||||
Emplacement recommandé :
|
||||
|
||||
```text
|
||||
core/cognition/
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
tests unitaires de sérialisation ;
|
||||
aucun appel runtime obligatoire ;
|
||||
aucune régression si trace absente.
|
||||
```
|
||||
|
||||
## Phase 2.2 — enrichissement build-time
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
produire la trace au moment où le serveur compile/enrichit les actions
|
||||
```
|
||||
|
||||
Point d'entrée :
|
||||
|
||||
```text
|
||||
agent_v0/server_v1/stream_processor.py
|
||||
```
|
||||
|
||||
Principe :
|
||||
|
||||
```text
|
||||
étendre les champs déjà produits par l'enrichissement intention/expected_result ;
|
||||
ne pas rendre gemma4 obligatoire ;
|
||||
si enrichissement indisponible, garder l'action actuelle.
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
actions compilées contiennent trace quand disponible ;
|
||||
les anciens workflows restent valides.
|
||||
```
|
||||
|
||||
## Phase 2.3 — transport agent
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
faire traverser la trace jusqu'à agent_v1 sans logique métier côté agent
|
||||
```
|
||||
|
||||
Principe :
|
||||
|
||||
```text
|
||||
l'agent transporte et rapporte ;
|
||||
le serveur reste responsable du protocole ;
|
||||
l'agent peut utiliser scene_expected pour pré-vérif simple, mais pas choisir un mandat.
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
report contient causal_trace ;
|
||||
comportement identique si trace absente ;
|
||||
pause_message peut inclure intention courante.
|
||||
```
|
||||
|
||||
## Phase 2.4 — qualification retour
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
rattacher la vérification à l'intention et à la scène
|
||||
```
|
||||
|
||||
Briques :
|
||||
|
||||
```text
|
||||
ReplayVerifier
|
||||
Validator V2
|
||||
AuditTrail
|
||||
LoopDetector
|
||||
```
|
||||
|
||||
Sorties attendues :
|
||||
|
||||
```text
|
||||
réussite
|
||||
échec
|
||||
attente
|
||||
rupture
|
||||
doute_localisation
|
||||
doute_identification
|
||||
doute_scène
|
||||
doute_effet
|
||||
doute_intention
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
un "rien ne change" n'est plus seulement un retry mécanique ;
|
||||
il est qualifié selon l'intention, la scène et la temporalité attendue.
|
||||
```
|
||||
|
||||
## Phase 2.5 — preuve apprenable
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
promouvoir uniquement les retours qualifiés en preuves
|
||||
```
|
||||
|
||||
Briques à enrichir :
|
||||
|
||||
```text
|
||||
replay_learner.ActionOutcome
|
||||
replay_memory
|
||||
target_memory_store via shim additif
|
||||
audit_trail
|
||||
```
|
||||
|
||||
Règle :
|
||||
|
||||
```text
|
||||
pas de changement destructeur de hash mémoire existant sans migration ;
|
||||
pas de succès appris si correction humaine non qualifiée ;
|
||||
pas de promotion si semantic_verified est faux ou absent sur action sensible.
|
||||
```
|
||||
|
||||
Critère de réussite :
|
||||
|
||||
```text
|
||||
la mémoire sait distinguer "Enregistrer pour sauvegarder" de "Enregistrer dans une autre intention/scène".
|
||||
```
|
||||
|
||||
## Phase 2.6 — délégation tutorée
|
||||
|
||||
But :
|
||||
|
||||
```text
|
||||
modéliser le niveau d'autonomie par protocole, environnement et tuteur
|
||||
```
|
||||
|
||||
Niveaux :
|
||||
|
||||
```text
|
||||
N0 observation
|
||||
N1 proposition
|
||||
N2 exécution supervisée
|
||||
N3 autonomie de session
|
||||
N4 autonomie habituelle
|
||||
```
|
||||
|
||||
Principe MVP :
|
||||
|
||||
```text
|
||||
ne pas réveiller LearningManager ;
|
||||
utiliser l'étage live ;
|
||||
ajouter un DelegationResolver simple et non bloquant plus tard ;
|
||||
fallback restrictif si aucune délégation connue.
|
||||
```
|
||||
|
||||
## Bancs de validation
|
||||
|
||||
Ordre :
|
||||
|
||||
```text
|
||||
LeaBench Bloc-notes enrichi
|
||||
-> tests unitaires Grounding/Dialog/Verifier
|
||||
-> replay Bloc-notes live
|
||||
-> LeaBench Easily dérivés des fixtures
|
||||
-> adaptateur T2A urgences
|
||||
-> smoke E2E Easily live
|
||||
```
|
||||
|
||||
## Décisions déjà prises
|
||||
|
||||
```text
|
||||
priorité protocoles : mieux connu -> moins risqué -> plus court
|
||||
précondition plausible : vérifier l'état attendu
|
||||
risque : dépend du geste, du métier, du mandat et du niveau de Léa validé par tuteur
|
||||
trace : générée au build, amendable au runtime par intervention humaine explicite
|
||||
apprentissage : seulement sur résultat qualifié
|
||||
```
|
||||
|
||||
## Décisions à ne pas prendre maintenant
|
||||
|
||||
```text
|
||||
archiver workflow_replay.py
|
||||
activer DialogResolver serveur en live
|
||||
réveiller LearningManager / ContinuousLearner
|
||||
modifier le schéma target_memory.db
|
||||
refactorer api_stream.py
|
||||
```
|
||||
|
||||
## Prochaine action concrète
|
||||
|
||||
```text
|
||||
Terminer Phase 2.0 :
|
||||
tester et déployer le verrou GroundingEngine anti-fallback opportuniste,
|
||||
puis retenter le replay Bloc-notes.
|
||||
```
|
||||
217
docs/plans/PLAN_REMISE_EN_ORDRE_POCS_2026-05-19.md
Normal file
217
docs/plans/PLAN_REMISE_EN_ORDRE_POCS_2026-05-19.md
Normal file
@@ -0,0 +1,217 @@
|
||||
# Plan de remise en ordre POCs -- 2026-05-19
|
||||
|
||||
> Note : ce document a ete ecrit avant le recadrage explicite `Lea-first`.
|
||||
> Il doit etre relu a la lumiere de
|
||||
> [CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md](./CADRAGE_COEUR_PRODUIT_LEA_2026-05-19.md),
|
||||
> qui distingue proprement coeur produit, VWB/demo et veille.
|
||||
|
||||
**Contexte**
|
||||
- Les 15 derniers jours ont servi a produire une demo GHT sous forte pression.
|
||||
- La demo a ete enregistree, mais avec des contournements empiles et une derive de perimetre documentee dans [docs/handoffs/2026-05-19_handoff_post_demo_GHT.md](../handoffs/2026-05-19_handoff_post_demo_GHT.md).
|
||||
- Les premiers POCs demarrent dans 15 jours. L'objectif n'est pas de "tout reparer", mais de remettre le projet en ordre autour du chemin qui a le plus de valeur terrain.
|
||||
|
||||
## 1. Decision de pilotage
|
||||
|
||||
**Chemin nominal POC**
|
||||
- `agent_v0/agent_v1/` (Lea) pour la capture et l'execution
|
||||
- `agent_v0/server_v1/` pour le streaming, le replay et l'orchestration runtime
|
||||
- `core/` pour la detection, l'extraction, le raisonnement et la supervision
|
||||
|
||||
**Chemin non critique a court terme**
|
||||
- `visual_workflow_builder/` reste utile pour inspecter, exporter ou bricoler une demo
|
||||
- `visual_workflow_builder/` ne doit plus etre la source principale de creation des workflows POC tant que ses bugs structurants ne sont pas fermes
|
||||
|
||||
**Raison**
|
||||
- L'etat reel du projet decrit deja `agent_v1` + streaming + replay comme le socle le plus mature, alors que le VWB reste "en cours" avec bugs runtime connus.
|
||||
- Le retour d'experience post-demo confirme que la derive VWB a coute du temps et masque des causes racines.
|
||||
|
||||
## 2. Objectif dans 15 jours
|
||||
|
||||
Arriver au debut des POCs avec :
|
||||
- un chemin `Lea-first` assume et documente
|
||||
- un socle de replay reproductible sur 1 a 2 cas terrain
|
||||
- un smoke test canonique de pre-demo / pre-POC
|
||||
- un registre clair de ce qui est stable, de ce qui est experimental, et des workarounds encore actifs
|
||||
- une capitalisation utile de la veille, des benches et des lecons apprises
|
||||
|
||||
## 3. Ce qu'on garde, ce qu'on gele, ce qu'on sort du chemin critique
|
||||
|
||||
### A. A garder comme socle produit
|
||||
- `agent_v0/agent_v1/`
|
||||
- `agent_v0/server_v1/`
|
||||
- `core/detection/`, `core/execution/`, `core/llm/`, `core/graph/`, `core/security/`
|
||||
- la maquette et les assets de demo quand ils servent de terrain d'essai reproductible
|
||||
- les docs de bench et d'audit qui documentent des decisions reversibles ou des limites prouvees
|
||||
|
||||
### B. A geler temporairement
|
||||
- creation de workflows complexes par VWB pour les POCs
|
||||
- nouvelles features UI non necessaires a l'execution terrain
|
||||
- experimentation libre sur des variantes de modeles ou des sous-systemes non relies au replay
|
||||
|
||||
### C. A sortir du chemin critique
|
||||
- corrections cosmetiques du VWB
|
||||
- generalisation de `agent_chat/` tant qu'il n'est pas requis pour le protocole POC
|
||||
- analytics avancées, reporting, experimentation produit non necessaire au go-live POC
|
||||
|
||||
## 4. Priorites reelles
|
||||
|
||||
### P0 -- cette semaine
|
||||
1. **Fixer la ligne produit**
|
||||
- Ecrire noir sur blanc que le chemin POC est `Lea -> streaming -> core`.
|
||||
- Interdire les nouveaux workflows critiques crees d'abord dans le VWB.
|
||||
|
||||
2. **Geler une baseline de reference**
|
||||
- Comparer `demo-stable-2026-05-12`, `demo/ght-2026-05-08` et `backup/post-demo-2026-05-19`.
|
||||
- Sortie attendue : une baseline "reference POC" et une liste des ecarts volontaires ou accidentels.
|
||||
|
||||
3. **Lister les contournements actifs**
|
||||
- `static_result` / `static_text` dans le replay
|
||||
- bypass NPM auth hors git
|
||||
- `cancel-replays.sh`
|
||||
- pauses humaines remplaçant des automatisations defectueuses
|
||||
- tout workaround client Lea ou VM encore necessaire
|
||||
|
||||
4. **Construire un smoke test canonique**
|
||||
- 1 workflow de reference
|
||||
- 1 environnement de reference
|
||||
- 1 checklist avant execution
|
||||
- 1 resultat attendu par etape critique
|
||||
|
||||
5. **Traiter les bugs qui cassent Lea en execution reelle**
|
||||
- mapping coordonnees Y cote client
|
||||
- gestion correcte de `replay_paused`
|
||||
- reset d'etat propre apres replay
|
||||
- captures runtime utiles au matching
|
||||
|
||||
### P1 -- avant les POCs
|
||||
1. **Durcir le replay Lea-first**
|
||||
- harmoniser les comportements strict / legacy la ou ils degradent la supervision
|
||||
- verifier les delais runtime effectivement appliques
|
||||
- s'assurer que les annulations et reprises sont propres
|
||||
|
||||
2. **Mettre au propre le protocole d'enregistrement**
|
||||
- comment on capture un workflow de reference avec Lea
|
||||
- ce qui est interdit pendant l'enregistrement
|
||||
- quelles preuves garder quand un replay echoue
|
||||
|
||||
3. **Remettre a niveau la documentation de pilotage**
|
||||
- `STATUS`
|
||||
- un runbook POC
|
||||
- un registre de decisions
|
||||
- un registre de limites connues
|
||||
|
||||
### P2 -- apres stabilisation du socle
|
||||
1. **Reprendre le VWB comme chantier separe**
|
||||
- bug recapture d'anchor
|
||||
- bug Stop qui ne purge pas la queue
|
||||
- invalidation cache frontend
|
||||
- coherence BDD / export / execution
|
||||
|
||||
2. **Reprendre les chantiers exploratoires**
|
||||
- benchmarks modeles
|
||||
- agent_chat
|
||||
- analytics
|
||||
- autres pistes produit
|
||||
|
||||
## 5. Sprint 15 jours
|
||||
|
||||
### Jours 1 a 3 -- Cadrage et gel
|
||||
- Choisir la baseline de reference POC.
|
||||
- Produire une matrice `stable / workaround / casse / hors-scope`.
|
||||
- Lister les workflows de demo existants et en designer un seul comme workflow canonique.
|
||||
- Geler les developpements hors chemin critique.
|
||||
|
||||
**Livrable**
|
||||
- un dossier de reference POC
|
||||
- une baseline git clairement nommee
|
||||
- une checklist de reprise
|
||||
|
||||
### Jours 4 a 7 -- Stabilisation du runtime Lea
|
||||
- Corriger les bugs client / replay qui cassent l'execution reelle.
|
||||
- Retester sur l'environnement de demo le plus proche du terrain.
|
||||
- Documenter le protocole de capture et de replay.
|
||||
|
||||
**Livrable**
|
||||
- 1 smoke test manuel reproductible
|
||||
- 1 replay de reference stable
|
||||
- 1 liste limitee de workarounds encore toleres
|
||||
|
||||
### Jours 8 a 10 -- Tesorisation utile
|
||||
- Trier la doc recente en trois familles :
|
||||
- preuve exploitable
|
||||
- decision durable
|
||||
- archive de session
|
||||
- Extraire la substance des benches, audits et handoffs dans des documents courts.
|
||||
- Nettoyer la memoire projet pour que les vraies lecons remontent.
|
||||
|
||||
**Livrable**
|
||||
- un registre de decisions
|
||||
- un registre de preuves / benches
|
||||
- un registre des limites et des dettes actives
|
||||
|
||||
### Jours 11 a 13 -- Preparation POC
|
||||
- Rejouer le workflow canonique plusieurs fois.
|
||||
- Tester les preconditions machine, VM, reseau, clipboard, captures, modele VLM.
|
||||
- Verifier ce qui doit etre industrialise ou ritualise en procedure.
|
||||
|
||||
**Livrable**
|
||||
- runbook operatoire POC
|
||||
- checklist pre-demo / pre-POC
|
||||
- journal d'incidents restant
|
||||
|
||||
### Jours 14 a 15 -- Verrouillage
|
||||
- Dernier passage sur la doc critique.
|
||||
- Validation humaine du chemin nominal.
|
||||
- Gel des modifs non indispensables.
|
||||
|
||||
**Livrable**
|
||||
- branche de stabilisation POC
|
||||
- etat de confiance clair
|
||||
- liste "ne pas toucher" avant demarrage
|
||||
|
||||
## 6. Tesorisation : structure cible
|
||||
|
||||
L'objectif n'est pas de conserver toutes les notes telles quelles. Il faut les condenser.
|
||||
|
||||
### Documents a avoir
|
||||
- `docs/STATUS.md`
|
||||
- etat reel par sous-systeme
|
||||
- `docs/POC_RUNBOOK.md`
|
||||
- comment lancer, verifier, relancer, diagnostiquer
|
||||
- `docs/DECISIONS_LOG.md`
|
||||
- decisions structurantes, datees, avec raison
|
||||
- `docs/KNOWN_LIMITS.md`
|
||||
- limites connues, contournements toleres, date de revision
|
||||
- `docs/BENCHMARKS_INDEX.md`
|
||||
- index court vers les benches qui comptent vraiment
|
||||
|
||||
### Regle de tri
|
||||
- un handoff brut ne doit pas rester la seule source d'une decision importante
|
||||
- une conclusion durable doit etre recopier dans un document stable
|
||||
- une veille sans impact concret doit sortir du chemin critique documentaire
|
||||
|
||||
## 7. Ce que je ferais en premier, des demain
|
||||
|
||||
1. Choisir une baseline POC de reference.
|
||||
2. Ecrire un court document "chemin nominal POC".
|
||||
3. Construire le smoke test canonique.
|
||||
4. Ouvrir la liste des workarounds actifs et decider lesquels sont acceptables 15 jours, lesquels doivent disparaitre.
|
||||
5. Ne traiter le VWB que s'il bloque encore le chemin Lea-first.
|
||||
|
||||
## 8. Risques si on ne fait pas ce pivot
|
||||
|
||||
- Repartir dans des corrections VWB qui ne servent pas le demarrage POC
|
||||
- Continuer a melanger demo, produit, veille et bricolage runtime
|
||||
- Garder une documentation abondante mais peu actionnable
|
||||
- Rejouer les memes erreurs de session, faute d'avoir remonte les vraies lecons au bon niveau
|
||||
|
||||
## 9. Sources de reference
|
||||
|
||||
- [docs/handoffs/2026-05-19_handoff_post_demo_GHT.md](../handoffs/2026-05-19_handoff_post_demo_GHT.md)
|
||||
- [docs/handoffs/2026-05-18_handoff_consolidation.md](../handoffs/2026-05-18_handoff_consolidation.md)
|
||||
- [docs/STATUS.md](../STATUS.md)
|
||||
- [docs/CARTE_FONCTIONNELLE_2026-05-08.md](../CARTE_FONCTIONNELLE_2026-05-08.md)
|
||||
- [docs/AUDIT_BDD_WORKFLOW_2026-05-10.md](../AUDIT_BDD_WORKFLOW_2026-05-10.md)
|
||||
- [docs/QW_SUITE_MAI.md](../QW_SUITE_MAI.md)
|
||||
- [docs/BENCH_T2A_DECISION_11DOSSIERS.md](../BENCH_T2A_DECISION_11DOSSIERS.md)
|
||||
- [docs/AUDIT_MEMOIRE_CLAUDE_2026-05-08.md](../AUDIT_MEMOIRE_CLAUDE_2026-05-08.md)
|
||||
67
docs/plans/PLAN_STABILISATION_DEMO_2026-06-01.md
Normal file
67
docs/plans/PLAN_STABILISATION_DEMO_2026-06-01.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# Plan stabilisation demo Lea — cible lundi 1 juin 2026
|
||||
|
||||
Date de cadrage : 2026-05-25 12:44 Europe/Paris
|
||||
Pilotage : Codex
|
||||
Contexte : la demo client est reportee au lundi 1 juin 2026. On sort du mode rustine J-4 et on vise un systeme propre, mesurable, restaurable.
|
||||
|
||||
## Principes
|
||||
|
||||
1. Pas de restauration destructive ni suppression de modele sans inventaire et accord explicite.
|
||||
2. Pas de replay live tant que les chemins pause/resume, FeedbackBus et perf ne sont pas instrumentes.
|
||||
3. Les changements doivent avoir une preuve : test, commande de healthcheck, log cible, ou bench.
|
||||
4. `C:\rpa_vision` reste le runtime Windows reel ; ne pas resynchroniser `agent_v0/deploy/windows_client`.
|
||||
5. Les collegues repondent dans `docs/coordination/inbox_codex/` avec ACK/NACK explicite.
|
||||
|
||||
## P0 — Inventaire et protection Ollama
|
||||
|
||||
Objectif : garantir que les modeles critiques existent, sont referencables, et peuvent etre reconstruits si un tag disparait.
|
||||
|
||||
- Figer `ollama list`, manifests, gros blobs, `ollama show --modelfile` des modeles critiques.
|
||||
- Verifier les artefacts locaux et backup : `t2a-gemma3-27b-q8_0.gguf`, `t2a-gemma3-27b-q4_k_m.gguf`, merged safetensors.
|
||||
- Produire une table : tag Ollama, digest/blob, source GGUF/HF, backup, statut de reconstruction.
|
||||
- Identifier les vrais manquants avec Dom si sa liste attendue depasse les 38 tags actuels.
|
||||
|
||||
## P0 — FeedbackBus 5004 propre
|
||||
|
||||
Objectif : garder la narration temps reel si elle est utile, mais sans bruit log ni service fragile.
|
||||
|
||||
- Corriger la cause `rpa-agent-chat.service inactive`.
|
||||
- Corriger ou isoler le warning CLIP/torch au boot.
|
||||
- Corriger CORS/SocketIO pour la ChatWindow Windows.
|
||||
- Conserver le fallback HTTP 5005 pour `resume` / `abort`.
|
||||
- Decider apres test si `LEA_FEEDBACK_BUS=1` reste actif cote Windows.
|
||||
|
||||
## P0 — Performance mesurable
|
||||
|
||||
Objectif : remplacer les intuitions par des mesures reproductibles.
|
||||
|
||||
- Harness build replay sans live replay : mesure avec/sans `RPA_SKIP_INTENTION_ENRICHMENT`.
|
||||
- Mesure des appels VLM : modele, `num_ctx`, layers CPU/GPU, p50/p95, taux JSON valide.
|
||||
- Politique de residence Ollama : `MAX_LOADED_MODELS=1`, modele VLM prechauffe, eviter les swaps texte/VLM.
|
||||
- Decision documentee : `qwen2.5vl:7b-rpa` vs `qwen2.5vl:7b` vs `qwen2.5vl:3b` vs autre backend.
|
||||
|
||||
## P0 — Replay pause/resume robuste
|
||||
|
||||
Objectif : zero confusion visible dans Lea.
|
||||
|
||||
- La bulle supervisee ne doit plus tronquer le message.
|
||||
- La bulle doit se fermer a la reprise serveur (`server_cleared`).
|
||||
- Le compteur et le statut doivent refleter l'etape reelle.
|
||||
- Smoke Windows obligatoire apres patch deploye.
|
||||
|
||||
## P1 — Hygiene runtime/deploiement
|
||||
|
||||
Objectif : rendre le systeme re-demarrable sans memoire orale.
|
||||
|
||||
- Runbook Linux : `rpa-streaming`, `ollama`, `rpa-agent-chat`.
|
||||
- Runbook Windows : tache `LeaInteractive`, lock, logs, hash des fichiers deployes.
|
||||
- Separateur clair : source repo vs runtime `C:\rpa_vision`.
|
||||
|
||||
## P1 — Pack de preuve demo
|
||||
|
||||
Objectif : arriver lundi avec une preuve concrete, pas seulement du code.
|
||||
|
||||
- Healthcheck global : Linux 5005/5004/Ollama + Windows agent.
|
||||
- Bench perf avant/apres.
|
||||
- Smoke replay controle, sans improvisation.
|
||||
- Notes de risques restantes avec mitigation.
|
||||
@@ -0,0 +1,200 @@
|
||||
# Protocole seance 1 micro-apprentissage Lea - 2026-05-27
|
||||
|
||||
## Competence cible
|
||||
|
||||
Premiere competence atomique:
|
||||
|
||||
```text
|
||||
ouvrir le menu Demarrer
|
||||
```
|
||||
|
||||
Raison: ouvrir Chrome, Word ou une recherche depend souvent de cette brique. Si Lea apprend d'abord ce geste simple, observable et verifiable, on pourra composer ensuite:
|
||||
|
||||
```text
|
||||
ouvrir le menu Demarrer -> rechercher Chrome -> ouvrir Chrome
|
||||
ouvrir le menu Demarrer -> rechercher Word -> ouvrir Word
|
||||
```
|
||||
|
||||
On ne demarre donc pas par un scenario "ouvrir navigateur" complet. On commence plus petit.
|
||||
|
||||
## Duree
|
||||
|
||||
25 minutes maximum:
|
||||
|
||||
- 9 min: 3 demonstrations humaines,
|
||||
- 5 min: 1 essai supervise de Lea,
|
||||
- 5 min: 1 variante,
|
||||
- 6 min: debrief et decision.
|
||||
|
||||
## Avant de commencer
|
||||
|
||||
1. Verifier le socle:
|
||||
|
||||
```bash
|
||||
python3 tools/lea_micro_preflight.py
|
||||
```
|
||||
|
||||
Verdict acceptable: tout OK, warning VLM non resident accepte.
|
||||
|
||||
2. Mettre Windows dans un etat simple:
|
||||
|
||||
- bureau visible,
|
||||
- pas d'application plein ecran,
|
||||
- NoMachine stable,
|
||||
- presse-papiers non utilise,
|
||||
- Lea connectee.
|
||||
|
||||
3. Ne pas ouvrir VWB, Aiva ou un workflow metier.
|
||||
|
||||
## Demonstrations humaines
|
||||
|
||||
Chaque demonstration doit etre lancee avec `Apprenez-moi`, puis arretee avec `Arreter`.
|
||||
|
||||
Nom de session:
|
||||
|
||||
```text
|
||||
ouvrir le menu Demarrer
|
||||
```
|
||||
|
||||
### Demo A - clic souris
|
||||
|
||||
Dom dit ce qu'il fait:
|
||||
|
||||
```text
|
||||
J'ouvre le menu Demarrer en cliquant sur le logo Windows.
|
||||
```
|
||||
|
||||
Actions:
|
||||
|
||||
1. cliquer le logo Windows,
|
||||
2. attendre que le menu apparaisse,
|
||||
3. verifier visuellement le champ `Rechercher`,
|
||||
4. fermer avec `Echap`,
|
||||
5. arreter l'enregistrement.
|
||||
|
||||
Postcondition:
|
||||
|
||||
- le champ `Rechercher` est visible.
|
||||
|
||||
### Demo B - touche Windows
|
||||
|
||||
Dom dit:
|
||||
|
||||
```text
|
||||
J'ouvre le meme menu avec la touche Windows.
|
||||
```
|
||||
|
||||
Actions:
|
||||
|
||||
1. appuyer sur `Win`,
|
||||
2. attendre le menu,
|
||||
3. verifier `Rechercher`,
|
||||
4. fermer avec `Echap`,
|
||||
5. arreter l'enregistrement.
|
||||
|
||||
Postcondition:
|
||||
|
||||
- le champ `Rechercher` est visible.
|
||||
|
||||
### Demo C - Win+S
|
||||
|
||||
Dom dit:
|
||||
|
||||
```text
|
||||
J'ouvre directement la recherche avec Win+S.
|
||||
```
|
||||
|
||||
Actions:
|
||||
|
||||
1. appuyer sur `Win+S`,
|
||||
2. verifier que la zone de recherche est visible et active,
|
||||
3. fermer avec `Echap`,
|
||||
4. arreter l'enregistrement.
|
||||
|
||||
Postcondition:
|
||||
|
||||
- la zone de recherche est visible, idealement avec le focus.
|
||||
|
||||
## Essai supervise de Lea
|
||||
|
||||
Lea tente une methode simple, de preference `Win`.
|
||||
|
||||
Message attendu avant action:
|
||||
|
||||
```text
|
||||
J'ouvre le menu Demarrer avec la touche Windows.
|
||||
```
|
||||
|
||||
Verification attendue:
|
||||
|
||||
```text
|
||||
Je vois le champ Rechercher, comme attendu.
|
||||
```
|
||||
|
||||
Si elle echoue, elle s'arrete et affiche:
|
||||
|
||||
```text
|
||||
J'essaie de : ouvrir le menu Demarrer
|
||||
J'attendais : voir le champ Rechercher
|
||||
Je vois : <description de l'ecran actuel>
|
||||
Peux-tu : ouvrir le menu Demarrer une fois pour me montrer le geste
|
||||
```
|
||||
|
||||
## Variante
|
||||
|
||||
Une seule variante pendant cette seance:
|
||||
|
||||
- Notepad ou une autre fenetre simple au premier plan,
|
||||
- puis Lea tente d'ouvrir le menu Demarrer.
|
||||
|
||||
Critere de succes:
|
||||
|
||||
- le champ `Rechercher` devient visible malgre la fenetre au premier plan.
|
||||
|
||||
On ne teste pas encore DPI ou ecran secondaire pendant cette seance.
|
||||
|
||||
## Donnees a relever
|
||||
|
||||
Pour chaque demonstration et essai:
|
||||
|
||||
- methode: clic logo, Win, Win+S,
|
||||
- fenetre active avant action,
|
||||
- marqueur observe: `Rechercher`,
|
||||
- resultat: succes, correction, echec,
|
||||
- duree approximative,
|
||||
- message affiche si blocage.
|
||||
|
||||
## Criteres de succes
|
||||
|
||||
- Lea formule la competence comme une intention, pas comme une coordonnee.
|
||||
- Lea connait au moins deux methodes pour ouvrir le menu.
|
||||
- Lea verifie le marqueur `Rechercher`.
|
||||
- Aucun message generique ne sort: pas `un element`, pas `cette action`, pas `Validation requise`.
|
||||
- Aucun replay VWB/metier n'est lance.
|
||||
|
||||
## Criteres d'echec
|
||||
|
||||
- Lea clique une coordonnee sans regarder le resultat.
|
||||
- Lea dit OK alors que le menu n'est pas ouvert.
|
||||
- Lea demande une aide incomprehensible.
|
||||
- Lea confond menu Demarrer, bureau, navigateur ou Word.
|
||||
- La capture/finalisation de session ne produit aucun artefact exploitable.
|
||||
|
||||
## Promotion
|
||||
|
||||
| Etat | Condition |
|
||||
|---|---|
|
||||
| OBSERVATION | au moins une demonstration capturee |
|
||||
| COACHING | Lea peut tenter avec aide humaine disponible |
|
||||
| AUTO_CANDIDATE | 3 succes verifies sur au moins 2 methodes |
|
||||
| AUTO | pas pour cette seance; attendre DPI/ecran secondaire |
|
||||
|
||||
## Suite directe
|
||||
|
||||
Si cette seance est propre:
|
||||
|
||||
1. seance 2: saisir une recherche dans le menu Demarrer,
|
||||
2. seance 3: ouvrir Chrome depuis le menu,
|
||||
3. seance 4: ouvrir Word depuis le menu,
|
||||
4. seance 5: fermer Word proprement,
|
||||
5. seulement ensuite: DPI et ecran secondaire.
|
||||
Reference in New Issue
Block a user