docs(coordination): sync agent inboxes and active decisions
This commit is contained in:
Dom
52
docs/coordination/active/2026-05-25_etat-courant.md
Normal file
52
docs/coordination/active/2026-05-25_etat-courant.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# Etat courant — 2026-05-25
|
||||
|
||||
- `Responsable arbitration`: Codex
|
||||
- `Demo cible`: 2026-06-01
|
||||
- `Statut global`: stabilisation avancee, smoke live Bloc-notes valide
|
||||
- `Derniere mise a jour`: 2026-05-25 19:30 Europe/Paris
|
||||
|
||||
## File active
|
||||
|
||||
1. Profil demo Linux active par drop-ins systemd et services redemarres.
|
||||
2. Smoke live Bloc-notes de reference valide : `replay_sess_1c0bfb42`, `16/16`, 0 failed, 0 retries, 0 pause Lea.
|
||||
3. Healthcheck global en `WARN` acceptable : VLM non resident a froid + `LeaInteractive=Ready` mais process agent vivant.
|
||||
4. Smoke offline cible OK.
|
||||
5. Perf build confirmee : `build.TOTAL=58 ms` sur le smoke live, `skip_ms=253`, `speedup=209.7x`.
|
||||
6. Gemini a repris le contexte et valide la structure/profil demo.
|
||||
7. Ne pas relancer de chantier D5-v3b avant validation/freeze du lot courant.
|
||||
8. Healthcheck Windows OK fonctionnel avec secret non persistant ; la relance visible de Lea doit rester manuelle si SSH lance un process invisible.
|
||||
9. Risque R6 EasyOCR leve par Gemini et verifie par Codex : la modif respecte `RPA_EASYOCR_GPU=0`.
|
||||
10. Prochaine etape : revue/commit discipline du lot stabilisation, puis traiter les optimisations OCR/VLM residuelles.
|
||||
11. Flags demo Linux actifs :
|
||||
- `RPA_SKIP_INTENTION_ENRICHMENT=true`
|
||||
- `RPA_SKIP_BUILD_VISION=true`
|
||||
- `RPA_EASYOCR_GPU=0`
|
||||
- ne pas forcer `RPA_GROUNDING_MODEL=qwen3.5:9b` tant que les callers runtime n'utilisent pas encore le profil JSON.
|
||||
|
||||
## Validations recentes
|
||||
|
||||
- C2d-bis valide techniquement : build skip mesure a 271 ms, speedup 223x local Codex.
|
||||
- D5-v3a mini-fix valide techniquement cote Codex et Gemini : tests cibles verts, lot elargi vert avec xfail attendu.
|
||||
- Smoke live post-recablage valide : `replay_sess_1c0bfb42`, `16/16`, 0 failed, 0 retries, 0 non verifiees, 0 pause.
|
||||
- Garde-fous memoire valides en live :
|
||||
- `memory_lookup SKIP : window_transition_requires_visual_confirmation` sur le clic `Enregistrer` ouvrant `Enregistrer sous` ;
|
||||
- `memory_lookup SKIP : generic_button_missing_context` sur le bouton generique `Oui`.
|
||||
- Derniere action Save As OK : `act_raw_154f4a32`, `anchor_template`, score `0.977`, warning attendu `runtime_dialog_handled_post_verify`.
|
||||
- D5-v2 pose l'API `get_grounding_profile()` / `generate_grounding()` mais n'est pas encore consomme en runtime.
|
||||
- Execution profil demo Linux documentee dans `active/2026-05-25_execution-profil-demo-linux.md`.
|
||||
- Gemini ACK reprise : `inbox_codex/2026-05-25_1945_gemini-to-codex_ACK-reprise-contexte.md`.
|
||||
- R6 EasyOCR leve : `inbox_codex/2026-05-25_2000_gemini-to-codex_INFO-levee-risque-R6.md`.
|
||||
|
||||
## Points a ne pas oublier
|
||||
|
||||
- Ne pas archiver les inbox actives tant que Claude/Gemini peuvent encore repondre.
|
||||
- Ne pas toucher les chemins VLM/`num_ctx` Windows dans `agent_v0/agent_v1/core/executor.py` sans decision D5-v3c et plan de redeploiement Windows.
|
||||
- Ne pas confondre grounding JSON qwen3.5 et grounding bbox qwen2.5vl.
|
||||
- Le diff `resolve_engine.py` contient une modification EasyOCR preexistante : ne pas la melanger avec D5-v3a mini-fix.
|
||||
- Le pre-check OCR a rejete `Enregi` pour `Enregistrer` pendant le smoke, mais l'action a reussi par template : future correction tolerance OCR, non bloquante.
|
||||
|
||||
## Prochaine decision Codex
|
||||
|
||||
- Synthese des changements et commits propres par mission.
|
||||
- Informer Claude/Gemini du smoke live `replay_sess_1c0bfb42` OK, de la levee R6 et du residuel OCR/offload.
|
||||
- Ne pas ouvrir D5-v3b avant que le lot perf/stabilite soit stable.
|
||||
@@ -0,0 +1,121 @@
|
||||
# Execution profil demo Linux — 2026-05-25
|
||||
|
||||
- `Execute par`: Codex
|
||||
- `Date`: 2026-05-25 19:30 Europe/Paris
|
||||
- `Statut`: **OK Linux + healthcheck Windows fonctionnel + smoke live valide**
|
||||
|
||||
## Actions realisees
|
||||
|
||||
1. Creation drop-ins systemd :
|
||||
- `/home/dom/.config/systemd/user/rpa-streaming.service.d/profil-demo.conf`
|
||||
- `/home/dom/.config/systemd/user/rpa-agent-chat.service.d/profil-demo.conf`
|
||||
2. `systemctl --user daemon-reload`
|
||||
3. Restart controle :
|
||||
- `rpa-streaming.service`
|
||||
- `rpa-agent-chat.service`
|
||||
4. Verification env chargee.
|
||||
5. Healthcheck Linux.
|
||||
6. Smoke offline tests.
|
||||
7. Mesure perf build.
|
||||
8. `ollama stop qwen2.5vl:7b-rpa` apres le test perf pour liberer la VRAM.
|
||||
9. Smoke live Bloc-notes relance apres correctifs builder + UI Lea.
|
||||
10. Healthcheck Lea ajuste pour ne pas echouer si `LeaInteractive=Ready` mais process agent vivant.
|
||||
|
||||
## Flags charges
|
||||
|
||||
`rpa-streaming.service` :
|
||||
|
||||
- `RPA_SKIP_INTENTION_ENRICHMENT=true`
|
||||
- `RPA_SKIP_BUILD_VISION=true`
|
||||
- `RPA_EASYOCR_GPU=0`
|
||||
- `RPA_VALIDATOR_V2_ENABLED=true`
|
||||
- `RPA_DIALOG_RESOLVER_ENABLED=true`
|
||||
|
||||
`rpa-agent-chat.service` :
|
||||
|
||||
- `AGENT_CHAT_ENABLE_OWL=0`
|
||||
- `AGENT_CHAT_ENABLE_UI_DETECTION=0`
|
||||
|
||||
## Resultats
|
||||
|
||||
- Services systemd : `active` / `active`.
|
||||
- agent_chat logs :
|
||||
- CLIP charge sur CPU ;
|
||||
- `WorkflowPipeline initialisé (ui_detection=False, ...)` ;
|
||||
- `OWL-v2 visual detector skipped`.
|
||||
- VRAM finale :
|
||||
- seulement `gnome-remote-desktop-daemon` ~164 MiB ;
|
||||
- aucun process `agent_chat` sur GPU ;
|
||||
- aucun modele Ollama resident apres `ollama stop`.
|
||||
- Healthcheck Linux final :
|
||||
- `WARN` uniquement car `qwen2.5vl:7b-rpa` non resident ;
|
||||
- ce WARN est acceptable a froid.
|
||||
- Smoke offline :
|
||||
- lot cible OK avec xfail attendu.
|
||||
- Perf build :
|
||||
- `full_ms=53021`
|
||||
- `skip_ms=253`
|
||||
- `speedup=209.7x`
|
||||
- `step4 skip=75 ms`
|
||||
- `step10 skip=0 ms`
|
||||
- Smoke live de reference post-recablage :
|
||||
- replay `replay_sess_1c0bfb42`
|
||||
- source `sess_20260520T102916_066851`
|
||||
- actions generees : `16` (`10 setup + 6 replay`)
|
||||
- resultat : `completed`, `16/16`, `0 failed`, `0 retries`, `0 non verifiees`, `0 pause Lea`
|
||||
- resolutions live : `semantic_close_tab_hotkey=1`, `grounding_vlm=1`, `anchor_template=1`
|
||||
- garde transition : `memory_lookup SKIP : window_transition_requires_visual_confirmation`
|
||||
- garde bouton generique : `memory_lookup SKIP : generic_button_missing_context`
|
||||
- Save As final : `act_raw_154f4a32`, `anchor_template`, score `0.977`, warning attendu `runtime_dialog_handled_post_verify`
|
||||
- lock replay supprime en fin de run.
|
||||
|
||||
## Healthcheck Windows
|
||||
|
||||
Commande executee par Codex avec injection ephemere du secret dans le processus
|
||||
uniquement, sans ecriture dans les docs.
|
||||
|
||||
Resultat :
|
||||
|
||||
- SSH Windows : OK ;
|
||||
- `LeaInteractive` : `Ready` apres relance, mais process agent vivant ;
|
||||
- agent process : OK ;
|
||||
- `LEA_FEEDBACK_BUS='1'` : OK ;
|
||||
- healthcheck global : WARN uniquement pour etats non bloquants (`qwen2.5vl:7b-rpa` non resident a froid et tache `Ready` avec process vivant).
|
||||
|
||||
Verification complementaire :
|
||||
|
||||
- observation anterieure : deux processus `run_agent_v1.py` observes ;
|
||||
- interpretation : couple parent/enfant, pas deux agents independants concurrents ;
|
||||
- point d'exploitation : le relancement SSH peut lancer un process non visible ; pour les smokes live, preferer relance manuelle de Lea dans la session Windows visible.
|
||||
|
||||
```text
|
||||
ProcessId 60472 parent 2416 : C:\rpa_vision\.venv\Scripts\pythonw.exe C:\rpa_vision\run_agent_v1.py
|
||||
ProcessId 44368 parent 60472 : C:\Users\dom\AppData\Local\Programs\Python\Python312\pythonw.exe C:\rpa_vision\run_agent_v1.py
|
||||
```
|
||||
|
||||
## Non realise / reporte
|
||||
|
||||
- Aucun commit.
|
||||
- Aucun D5-v3b.
|
||||
- Correction tolerance OCR partielle : pendant le smoke, le pre-check a lu `Enregi` au lieu de `Enregistrer`, mais l'action a reussi par template.
|
||||
|
||||
## R6 EasyOCR
|
||||
|
||||
Gemini a leve le risque R6 :
|
||||
|
||||
- `docs/coordination/inbox_codex/2026-05-25_2000_gemini-to-codex_INFO-levee-risque-R6.md`
|
||||
|
||||
Verification Codex :
|
||||
|
||||
- `resolve_engine.py` utilise `easyocr_gpu_enabled(default=False)` pour le validateur OCR ;
|
||||
- `core/llm/ocr_extractor.py` lit `RPA_EASYOCR_GPU` et n'active le GPU que pour `1/true/yes/on` ;
|
||||
- cette modification est coherente avec le profil demo et evite une allocation VRAM EasyOCR cachee.
|
||||
|
||||
## Suite
|
||||
|
||||
1. Revue du diff et commits propres par mission.
|
||||
2. Documenter le smoke live OK a Claude/Gemini.
|
||||
3. Traiter ensuite les residuels :
|
||||
- tolerance OCR `Enregi`/`Enregistrer` ;
|
||||
- offload Ollama observe sur `qwen2.5vl:7b` (`36%/64% CPU/GPU`, `CONTEXT=4096`) ;
|
||||
- clarification `LeaInteractive=Ready` vs process agent vivant.
|
||||
480
docs/coordination/active/2026-05-25_runbook-profil-demo-smoke.md
Normal file
480
docs/coordination/active/2026-05-25_runbook-profil-demo-smoke.md
Normal file
@@ -0,0 +1,480 @@
|
||||
# Runbook profil démo + smoke — démo cible 2026-06-01
|
||||
|
||||
- `Auteur initial`: Claude
|
||||
- `Date création`: 2026-05-25 16:30 Europe/Paris
|
||||
- `Statut`: **execute par Codex, smoke live de reference valide le 2026-05-25 17:47:59**
|
||||
- `Doc only`: pas de patch code, pas de restart, pas de live replay
|
||||
- `Réfs`:
|
||||
- `docs/coordination/active/2026-05-25_etat-courant.md`
|
||||
- `docs/coordination/syntheses/2026-05-25_synthese-direction.md`
|
||||
- `docs/plans/PLAN_STABILISATION_DEMO_2026-06-01.md`
|
||||
|
||||
---
|
||||
|
||||
## 0. Convention
|
||||
|
||||
Les commandes marquées **`[CODEX ONLY]`** sont à exécuter par Codex (ou Dom). Aucune commande destructive ou à effet runtime ne doit être lancée par Claude sans GO explicite. Les commandes marquées **`[READ ONLY]`** sont exécutables par n'importe qui (lecture seule, sans risque).
|
||||
|
||||
---
|
||||
|
||||
## 1. Profil démo — flags recommandés
|
||||
|
||||
### Variables d'environnement à activer en bloc (drop-in systemd)
|
||||
|
||||
Fichier cible : `/home/dom/.config/systemd/user/rpa-streaming.service.d/profil-demo.conf` (à créer **`[CODEX ONLY]`**).
|
||||
|
||||
```ini
|
||||
[Service]
|
||||
# Profil démo 2026-06-01 — voir docs/coordination/active/2026-05-25_runbook-profil-demo-smoke.md
|
||||
# Skip enrichissement intentions gemma4 (économie ~30s/build, code mort sem_verified=None)
|
||||
Environment=RPA_SKIP_INTENTION_ENRICHMENT=true
|
||||
# Skip SomEngine + _gemma4_read_element au build (économie ~22s/build sur fixture)
|
||||
Environment=RPA_SKIP_BUILD_VISION=true
|
||||
# EasyOCR forcé CPU (libère ~768 MiB VRAM côté serveur Python)
|
||||
Environment=RPA_EASYOCR_GPU=0
|
||||
```
|
||||
|
||||
Fichier cible : `/home/dom/.config/systemd/user/rpa-agent-chat.service.d/profil-demo.conf` (à créer **`[CODEX ONLY]`**).
|
||||
|
||||
```ini
|
||||
[Service]
|
||||
# Profil démo 2026-06-01 — agent_chat sans VRAM lourde
|
||||
# OWL-v2 désactivé dans AutonomousPlanner (économie ~600 MiB VRAM)
|
||||
Environment=AGENT_CHAT_ENABLE_OWL=0
|
||||
# UI detection désactivée dans WorkflowPipeline (économie ~900 MiB via UIDetector→OWL)
|
||||
Environment=AGENT_CHAT_ENABLE_UI_DETECTION=0
|
||||
```
|
||||
|
||||
### Activation
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY]
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user restart rpa-streaming.service
|
||||
systemctl --user restart rpa-agent-chat.service
|
||||
```
|
||||
|
||||
### Validation post-activation
|
||||
|
||||
```bash
|
||||
# [READ ONLY]
|
||||
systemctl --user show rpa-streaming.service -p Environment
|
||||
systemctl --user show rpa-agent-chat.service -p Environment
|
||||
# Doit afficher les 3 + 2 variables ci-dessus
|
||||
```
|
||||
|
||||
### Gain cumulé attendu
|
||||
|
||||
| Étage | Avant | Après profil démo | Source |
|
||||
|---|---|---|---|
|
||||
| Build replay (16 actions fixture) | ~91 000 ms | **~270 ms** (mesuré) | C2 + C2b + C2d-bis |
|
||||
| VRAM agent_chat | 1478 MiB | < 100 MiB | C1b + C1c + C1d |
|
||||
| VRAM EasyOCR Python | 768 MiB | 0 MiB | Phase 1 |
|
||||
| Cumul libéré côté GPU | — | **~2.1 GiB** | combinaison |
|
||||
|
||||
---
|
||||
|
||||
## 2. Flags à NE PAS activer (ou avec prudence)
|
||||
|
||||
### À ne PAS activer en démo
|
||||
|
||||
| Flag | Raison |
|
||||
|---|---|
|
||||
| `RPA_GROUNDING_MODEL=qwen3.5:9b` | **Conflit env var** : `resolve_engine.py:959, 985, 1013` lit aussi cette var et attend un modèle **bbox_2d** (qwen2.5vl), pas JSON x_pct (qwen3.5). Le set globalement casserait silencieusement les 3 sites grounding bbox actifs. Reporté D5-v3b (renommage `RPA_BBOX_GROUNDING_MODEL`). |
|
||||
| `RPA_VLM_PREFILL=false` | Désactive le prefill JSON D5-v2. API D5-v2 préparatoire, pas encore consommée, mais cette var pourrait casser un futur caller. Garder défaut. |
|
||||
| `OLLAMA_FLASH_ATTENTION=1` + `OLLAMA_KV_CACHE_TYPE=q8_0` | Pas encore testé sur ce setup. Codex avait acté "à tester séparément après D5-v2 avec rollback clair". À traiter après stabilisation du lot courant. |
|
||||
| `AGENT_CHAT_ENABLE_OWL=1` | Réactivation OWL → +600 MiB VRAM perdus. Ne réactiver qu'en debug, jamais en démo. |
|
||||
| `AGENT_CHAT_ENABLE_UI_DETECTION=1` | Idem +900 MiB. Démo uniquement avec flag OFF. |
|
||||
| Pull/retag modèles Ollama | Hors scope démo. Pas de migration modèle pendant freeze. |
|
||||
|
||||
### À manier avec prudence
|
||||
|
||||
| Action | Pourquoi |
|
||||
|---|---|
|
||||
| Modification `agent_v0/agent_v1/core/executor.py` (Windows) | Reporté D5-v3c. Hardcoded `num_ctx=8192` connu mais nécessite redéploiement Windows. Pas de patch avant démo. |
|
||||
| Restart `rpa-agent-chat.service` seul | OK si nécessaire mais préférer le bloc complet pour cohérence d'état. |
|
||||
| `RPA_BBOX_GROUNDING_MODEL=...` | Var **n'existe pas encore** (D5-v3b). Set silencieusement ignoré. |
|
||||
| `git checkout HEAD -- ...` sur fichiers patchés | Worktree large et sale → vérifier diff avant rollback partiel. |
|
||||
|
||||
---
|
||||
|
||||
## 3. Procédure restart Linux services
|
||||
|
||||
### Pré-conditions
|
||||
|
||||
```bash
|
||||
# [READ ONLY]
|
||||
# Vérifier que les fichiers drop-in sont posés
|
||||
ls -la ~/.config/systemd/user/rpa-streaming.service.d/profil-demo.conf
|
||||
ls -la ~/.config/systemd/user/rpa-agent-chat.service.d/profil-demo.conf
|
||||
|
||||
# Vérifier l'état actuel avant restart
|
||||
systemctl --user status rpa-streaming.service --no-pager | head -10
|
||||
systemctl --user status rpa-agent-chat.service --no-pager | head -10
|
||||
|
||||
# Capturer VRAM baseline
|
||||
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv > /tmp/vram_avant_profil_demo.txt
|
||||
cat /tmp/vram_avant_profil_demo.txt
|
||||
```
|
||||
|
||||
### Restart contrôlé
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY]
|
||||
systemctl --user daemon-reload
|
||||
|
||||
# Restart rpa-streaming en premier (port 5005, dépendance amont)
|
||||
systemctl --user restart rpa-streaming.service
|
||||
sleep 3
|
||||
systemctl --user status rpa-streaming.service --no-pager | head -8
|
||||
# Attendu : Active: active (running)
|
||||
|
||||
# Restart rpa-agent-chat (port 5004)
|
||||
systemctl --user restart rpa-agent-chat.service
|
||||
sleep 5 # CLIP CPU load ~3-5s + Flask boot
|
||||
systemctl --user status rpa-agent-chat.service --no-pager | head -8
|
||||
# Attendu : Active: active (running)
|
||||
```
|
||||
|
||||
### Vérification immédiate post-restart
|
||||
|
||||
```bash
|
||||
# [READ ONLY]
|
||||
# Vérifier journal startup : flags actifs + aucun chargement OWL/UI detection
|
||||
journalctl --user -u rpa-agent-chat.service --since "1 min ago" \
|
||||
| grep -E "WorkflowPipeline|OWL-v2|ui_detection|skipped|VRAM"
|
||||
|
||||
# Attendu :
|
||||
# "✓ WorkflowPipeline initialisé (ui_detection=False, ...)"
|
||||
# "OWL-v2 visual detector skipped at boot (AGENT_CHAT_ENABLE_OWL!=1, ...)"
|
||||
# NE DOIT PAS apparaître :
|
||||
# "Chargement OWL-v2 sur cuda"
|
||||
# "✓ OWL-v2 initialized"
|
||||
|
||||
# Mesure VRAM post-restart
|
||||
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv > /tmp/vram_apres_profil_demo.txt
|
||||
diff /tmp/vram_avant_profil_demo.txt /tmp/vram_apres_profil_demo.txt
|
||||
# Attendu : agent_chat passe de ~1478 MiB → < 100 MiB
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Healthcheck Linux + Windows
|
||||
|
||||
### Linux
|
||||
|
||||
```bash
|
||||
# [READ ONLY]
|
||||
.venv/bin/python tools/lea_healthcheck.py
|
||||
```
|
||||
|
||||
**Critère GO** : ligne finale `Lea healthcheck: OK` ou `WARN` justifie uniquement par les warnings toleres ci-dessous.
|
||||
|
||||
WARN tolérés (à valider individuellement avant freeze) :
|
||||
- `ollama:resident-vlm - qwen2.5vl:7b-rpa is not currently resident` est
|
||||
tolérable immédiatement après restart ou après `ollama stop` : cela signifie
|
||||
que la VRAM est libre et qu'aucun grounding n'a encore réchauffé le modèle.
|
||||
Avant smoke live, ce WARN ne bloque pas ; pendant/après un resolve bbox, on
|
||||
vérifiera plutôt `ollama ps` et le `CONTEXT=4096`.
|
||||
- `windows:LeaInteractive - task state='Ready', but agent process is alive` est
|
||||
tolérable si `windows:agent-process` confirme au moins un `run_agent_v1.py`.
|
||||
Cas observe apres relance manuelle/tache : la tache n'est plus `Running`, mais
|
||||
l'agent reste vivant et a execute un smoke `16/16`.
|
||||
- Tout autre WARN = action corrective avant smoke.
|
||||
|
||||
### Windows (Léa)
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY] — SSH déjà testé OK ce matin
|
||||
SSHPASS='<mot_de_passe_windows>' LEA_SSH_COMMAND='sshpass -e ssh' \
|
||||
.venv/bin/python tools/lea_healthcheck.py --windows-host 192.168.1.11
|
||||
```
|
||||
|
||||
**Critère GO** : ligne finale `Lea healthcheck: OK` ou `WARN` limite aux deux warnings toleres ci-dessus.
|
||||
|
||||
Vérifications spécifiques Windows :
|
||||
- `LeaInteractive` Running
|
||||
- Process `pythonw.exe` actif avec `CommandLine` pointant `C:\rpa_vision\run_agent_v1.py`
|
||||
- Lock `C:\rpa_vision\lea_agent.lock` cohérent avec PID actif
|
||||
- Hashes des fichiers critiques `agent_v1/core/executor.py`, `agent_v1/core/grounding.py`, `agent_v1/main.py` matchent la source Linux (cf. D4 runbook)
|
||||
- `LEA_FEEDBACK_BUS='1'` côté Windows (narration ChatWindow active)
|
||||
|
||||
---
|
||||
|
||||
## 5. Procédure smoke offline
|
||||
|
||||
But : valider que les patches serveur n'ont pas cassé le pipeline build sans tirer sur l'agent Windows.
|
||||
|
||||
```bash
|
||||
# [READ ONLY] — pas de Windows requis, pas de live, pas d'Ollama lourd
|
||||
.venv/bin/python -m pytest \
|
||||
tests/unit/test_executor_verify_window_guard.py \
|
||||
tests/integration/test_replay_single_inflight.py \
|
||||
tests/unit/test_clip_embedder_device_fix.py \
|
||||
tests/unit/test_agent_chat_cors_lan.py \
|
||||
tests/unit/test_autonomous_planner_owl_flag.py \
|
||||
tests/unit/test_workflow_pipeline_ui_detection_disabled.py \
|
||||
tests/unit/test_enrich_click_skip_build_vision.py \
|
||||
tests/unit/test_vlm_grounding_profile.py \
|
||||
tests/unit/test_resolve_engine_bbox_num_ctx.py \
|
||||
-v
|
||||
```
|
||||
|
||||
**Critère GO** : `88 passed, 1 xfailed` (xfail = `test_get_next_action_two_concurrent_polls` attendu race WP-C Q1).
|
||||
|
||||
### Mesure perf build (optionnel mais utile)
|
||||
|
||||
```bash
|
||||
# [READ ONLY] — utilise Ollama gemma4, prend ~2 min
|
||||
.venv/bin/python -m pytest tests/integration/test_build_replay_perf.py \
|
||||
-m performance -s
|
||||
```
|
||||
|
||||
**Critère GO** :
|
||||
- Speedup ≥ 3x (skip vs full)
|
||||
- Build skip avec profil démo `RPA_SKIP_INTENTION_ENRICHMENT=true` + `RPA_SKIP_BUILD_VISION=true` → < 1 000 ms attendu (mesuré 271 ms par Codex)
|
||||
- Attention : ce test exécute aussi le chemin full pour calculer le ratio et
|
||||
peut réchauffer `qwen2.5vl:7b-rpa` en `CONTEXT=8192` via le chemin critic
|
||||
historique. Après ce test, exécuter `ollama stop qwen2.5vl:7b-rpa` pour
|
||||
revenir à un état VRAM froid avant smoke.
|
||||
|
||||
Pour activer le profil démo dans le test :
|
||||
```bash
|
||||
# [READ ONLY]
|
||||
RPA_SKIP_BUILD_VISION=true \
|
||||
.venv/bin/python -m pytest tests/integration/test_build_replay_perf.py \
|
||||
-m performance -s
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Procédure smoke live court Bloc-notes
|
||||
|
||||
**Préalable** : sections 1-5 doivent être OK.
|
||||
|
||||
### Préparation Windows
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY] — vérifier Léa active et propre
|
||||
SSHPASS='<mot_de_passe_windows>' LEA_SSH_COMMAND='sshpass -e ssh' \
|
||||
.venv/bin/python tools/lea_healthcheck.py --windows-host 192.168.1.11
|
||||
# Doit retourner OK
|
||||
```
|
||||
|
||||
### Lancement smoke
|
||||
|
||||
Commande executee par Codex le 2026-05-25 17:46 Europe/Paris :
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY] — trigger live
|
||||
curl -fsS -X POST \
|
||||
-H "Authorization: Bearer $RPA_API_TOKEN" \
|
||||
"http://127.0.0.1:5005/api/v1/traces/stream/replay-session?session_id=sess_20260520T102916_066851&machine_id=DESKTOP-58D5CAC_windows"
|
||||
```
|
||||
|
||||
Resultat de reference post-recablage :
|
||||
|
||||
- replay : `replay_sess_1c0bfb42`
|
||||
- total genere : `16` actions (`10 setup + 6 replay`)
|
||||
- statut final : `completed`, `16/16`, `0 failed`, `0 retries`, `0 non verifiees`, `0 pause Lea`
|
||||
- garde transition : `memory_lookup SKIP : window_transition_requires_visual_confirmation`
|
||||
- garde bouton generique : `memory_lookup SKIP : generic_button_missing_context`
|
||||
- dialogue remplacement : warning attendu `runtime_dialog_handled_post_verify`
|
||||
- resolutions : `semantic_close_tab_hotkey=1`, `grounding_vlm=1`, `anchor_template=1`, score moyen `0.94`, temps moyen `4793 ms`
|
||||
|
||||
### Critères GO smoke live
|
||||
|
||||
| # | Critère | Source de vérité |
|
||||
|---|---|---|
|
||||
| 1 | Replay termine toutes les actions generees (`16/16` pour `replay_sess_1c0bfb42`) | `journalctl rpa-streaming` ligne `Replay replay_sess_... termine avec succes : X/X actions` |
|
||||
| 2 | 0 failed, 0 retries inutiles | idem ligne replay |
|
||||
| 3 | Save As final valide sans pause humaine | log `REPORT action_id=act_raw_154f4a32 success=True warning='runtime_dialog_handled_post_verify' resolution_method='anchor_template'` |
|
||||
| 4 | `[PERF] build.TOTAL ... total_ms < 1000` | journal `rpa-streaming` post-build (instrumentation C2b) |
|
||||
| 5 | `ollama ps` : `CONTEXT=4096` sur les appels grounding bbox (pas 8192) | `ollama ps` pendant le replay |
|
||||
| 6 | Aucun replay lock restant apres completion | absence de `data/training/_replay_active.lock` |
|
||||
| 7 | Healthcheck Linux+Windows : OK ou WARN toleres avant ET après smoke | sections 4 |
|
||||
|
||||
### Critères NOGO smoke live
|
||||
|
||||
| # | Symptôme | Action |
|
||||
|---|---|---|
|
||||
| 1 | Replay termine avec moins que le nombre d'actions generees ou echec | Stop. Analyser journal. Rollback profil démo (cf. section 7). |
|
||||
| 2 | `RuntimeError` / `UnboundLocalError` / `OOM CUDA` dans le journal | Stop. Capturer logs. Rollback. |
|
||||
| 3 | Offload Ollama plus mauvais que le baseline observe (`qwen2.5vl:7b` environ `36%/64% CPU/GPU`) | Stop. Vérifier `nvidia-smi` autres process, restart sans profil démo, isoler la cause. |
|
||||
| 4 | `[PERF] build.TOTAL > 5000 ms` (régression perf 18x vs cible) | Stop. Re-vérifier flags actifs. |
|
||||
| 5 | Dialog `Enregistrer sous` ou `Confirmer l'enregistrement` cause pause humaine non absorbée | Stop. Vérifier builder save-dialog + `_handle_known_runtime_dialog`. |
|
||||
|
||||
---
|
||||
|
||||
## 7. Rollback rapide
|
||||
|
||||
### Rollback profil démo (chaud, sans modif code)
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY]
|
||||
# Supprimer les drop-in (revient au comportement par défaut)
|
||||
rm ~/.config/systemd/user/rpa-streaming.service.d/profil-demo.conf
|
||||
rm ~/.config/systemd/user/rpa-agent-chat.service.d/profil-demo.conf
|
||||
rmdir ~/.config/systemd/user/rpa-streaming.service.d/ 2>/dev/null
|
||||
rmdir ~/.config/systemd/user/rpa-agent-chat.service.d/ 2>/dev/null
|
||||
|
||||
systemctl --user daemon-reload
|
||||
systemctl --user restart rpa-streaming.service
|
||||
systemctl --user restart rpa-agent-chat.service
|
||||
```
|
||||
|
||||
Effet : les flags `RPA_SKIP_*` et `AGENT_CHAT_ENABLE_*` retombent à leurs défauts. Comportement historique restauré (mais avec les patches code C1+C1b+C1c+C1d+C2b+C2d-bis+D5-v2+D5-v3a déjà posés dans le worktree).
|
||||
|
||||
### Rollback code (annule les patches)
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY] — uniquement si patches identifiés comme cause
|
||||
# Vérifier la liste des fichiers modifiés
|
||||
git status -s
|
||||
|
||||
# Rollback ciblé d'un fichier
|
||||
git checkout HEAD -- <fichier>
|
||||
|
||||
# Rollback de tout le lot stabilisation (DANGEREUX — annule TOUS les patches)
|
||||
git checkout HEAD -- \
|
||||
agent_chat/app.py \
|
||||
agent_chat/autonomous_planner.py \
|
||||
core/embedding/clip_embedder.py \
|
||||
core/detection/vlm_config.py \
|
||||
core/detection/ollama_client.py \
|
||||
agent_v0/server_v1/stream_processor.py \
|
||||
agent_v0/server_v1/resolve_engine.py
|
||||
# Puis restart services
|
||||
```
|
||||
|
||||
**Important** : ne pas rollback les patches grounding bbox `num_ctx=4096` si la régression vient d'ailleurs — la fuite 8192 reviendrait.
|
||||
|
||||
### Backups Windows (référence)
|
||||
|
||||
Codex a posé des `.bak-codex-*` lors des déploiements Windows ce matin. Pour rollback Windows :
|
||||
|
||||
```bash
|
||||
# [CODEX ONLY] — exemple, à adapter
|
||||
SSHPASS='<mot_de_passe_windows>' LEA_SSH_COMMAND='sshpass -e ssh' ssh dom@192.168.1.11 \
|
||||
"cd C:\rpa_vision && copy run_agent_v1.py.bak-codex-* run_agent_v1.py && copy Lea.bat.bak-codex-* Lea.bat"
|
||||
# Puis kill + relancer LeaInteractive
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. Critères GO/NOGO commit + freeze
|
||||
|
||||
### Critères GO commit du lot stabilisation
|
||||
|
||||
1. ✅ Sections 4 (healthcheck Linux + Windows) : OK avant restart profil démo
|
||||
2. ✅ Section 3 (restart) : services Active running, journal propre
|
||||
3. ✅ Section 4 post-restart : OK encore
|
||||
4. ✅ Section 5 (smoke offline) : `88 passed, 1 xfailed`
|
||||
5. ✅ Section 6 (smoke live) : 7/7 critères GO ou ecarts explicitement acceptes par Codex/Dom
|
||||
6. ✅ Aucune régression sur la branche backup actuelle (vérifier `git log --oneline -20`)
|
||||
7. ✅ Codex a synthétisé/groupé les commits proprement (1 commit par mission, messages clairs)
|
||||
|
||||
### Critères NOGO commit
|
||||
|
||||
1. ❌ Un seul critère NOGO smoke live → ne pas commit, investiguer
|
||||
2. ❌ Healthcheck en WARN persistant non liste dans les warnings toleres → ne pas commit
|
||||
3. ❌ Worktree contient des fichiers modifiés non identifiés (ex. modif EasyOCR pré-existante signalée) → identifier d'abord, commit ensuite
|
||||
|
||||
### Critères GO freeze branche `demo-2026-06-01`
|
||||
|
||||
Après commit OK :
|
||||
1. Créer branche dédiée : `git checkout -b demo-2026-06-01` **`[CODEX ONLY]`**
|
||||
2. Vérifier que tous les fichiers livrés y sont
|
||||
3. Protection branche : `git config branch.demo-2026-06-01.pushRemote refusable` ou équivalent (à arbitrer Codex/Dom)
|
||||
4. Tag de freeze : `git tag demo-freeze-2026-05-31` (la veille de démo)
|
||||
5. Documenter dans `docs/coordination/registre/2026-05-31_freeze-demo.md` les flags actifs + hashes + tests passés
|
||||
|
||||
---
|
||||
|
||||
## 9. Risques résiduels
|
||||
|
||||
### R1 — `RPA_GROUNDING_MODEL` ambigu
|
||||
|
||||
**Sévérité** : Élevée si quelqu'un set la var globalement.
|
||||
|
||||
**Description** : `vlm_config.py:get_grounding_profile()` (D5-v2) défaut `qwen3.5:9b` ET `resolve_engine.py:959, 985, 1013` lit la même var et attend `qwen2.5vl:7b` (bbox_2d). Set global → cassure silencieuse d'un des deux.
|
||||
|
||||
**Mitigation** :
|
||||
- Ne PAS set globalement (rappel section 2)
|
||||
- D5-v3b (post-démo) : renommer en `RPA_BBOX_GROUNDING_MODEL` côté legacy
|
||||
- Test garde-fou : `test_no_helper_migration_done` vérifie qu'aucun caller n'utilise `generate_grounding()` (D5-v2 reste API préparatoire)
|
||||
|
||||
### R2 — Windows executor `num_ctx=8192` hardcoded
|
||||
|
||||
**Sévérité** : Moyenne pour la démo (chemin Windows pas trigger en démo Linux+VLM serveur).
|
||||
|
||||
**Description** : `agent_v0/agent_v1/core/executor.py` contient des appels VLM Windows avec `num_ctx=8192` hardcoded. Reporté D5-v3c. Nécessite redéploiement Windows.
|
||||
|
||||
**Mitigation pour démo** :
|
||||
- Le replay live serveur-driven utilise les chemins serveur (resolve_engine) qui ont `num_ctx=4096` depuis D5-v3a
|
||||
- Les chemins executor.py VLM côté Windows sont fallbacks rarement empruntés
|
||||
- Si trigger pendant la démo : la fuite VRAM revient localement Windows mais ne casse pas le replay
|
||||
|
||||
### R3 — Worktree large et sale
|
||||
|
||||
**Sévérité** : Moyenne pour discipline commit.
|
||||
|
||||
**Description** : `git status` montre plusieurs fichiers modifiés non encore commités, dont :
|
||||
- Patches C1+C1b+C1c+C1d+C2b+C2d-bis+D5-v2+D5-v3a (attribués)
|
||||
- Modification EasyOCR dans `resolve_engine.py` pré-existante (non attribuée D5-v3a, signalée par Codex)
|
||||
- Possible reste de la Phase 1 Quick wins Codex
|
||||
|
||||
**Mitigation** :
|
||||
- Codex groupera les commits proprement
|
||||
- Claude n'a pas mélangé son patch D5-v3a avec la modif EasyOCR (séparation respectée dans le résumé)
|
||||
- Avant commit final, vérifier `git diff` ligne par ligne pour ne pas inclure de modif inconnue
|
||||
|
||||
### R4 — Smoke live valide post-correctifs
|
||||
|
||||
**Sévérité** : Faible a moyenne.
|
||||
|
||||
**Description** : Incertitude levee le 2026-05-25 17:47:59 par `replay_sess_1c0bfb42` : `16/16`, 0 failed, 0 retries, 0 pause Lea. Le run valide explicitement les gardes memoire sur transition fenetre et bouton generique. Reste a surveiller sur plusieurs traces avant freeze.
|
||||
|
||||
**Mitigation** :
|
||||
- Rejouer un smoke court apres toute modification du builder, resolver ou Windows agent.
|
||||
- Ne pas generaliser ce succes a toutes les apps : il valide le chemin Bloc-notes/demo.
|
||||
|
||||
### R5 — Coordination bruyante / synthèse à maintenir
|
||||
|
||||
**Sévérité** : Faible (organisationnel).
|
||||
|
||||
**Description** : Beaucoup de messages inbox aujourd'hui (≥ 30 entre Claude/Codex). Risque de perdre le fil au prochain reboot session.
|
||||
|
||||
**Mitigation** :
|
||||
- Structure `active/` + `syntheses/` + `registre/` mise en place par Codex (cf. section 19:20 INFO)
|
||||
- Continuer à capitaliser dans ces dossiers avant archivage des inbox
|
||||
|
||||
### R6 — Risque effet bord modif EasyOCR pré-existante
|
||||
|
||||
**Sévérité** : Faible, risque leve.
|
||||
|
||||
**Description** : `git diff resolve_engine.py` contient une modification EasyOCR signalée par Codex (probablement reste Phase 1 12:15). Gemini a confirme que cette modification respecte `RPA_EASYOCR_GPU=0` via `easyocr_gpu_enabled(default=False)` et evite une allocation VRAM cachee.
|
||||
|
||||
**Mitigation** :
|
||||
- Conserver dans le lot stabilisation, documente dans `docs/coordination/registre/2026-05-25_R6-easyocr-leve.md`.
|
||||
- Verifier au commit que la modif reste separee conceptuellement de D5-v3a.
|
||||
|
||||
---
|
||||
|
||||
## Arbitrage Codex/Dom demandé
|
||||
|
||||
Avant exécution de ce runbook par Codex, arbitrages à trancher :
|
||||
|
||||
1. **Section 1 — drop-in systemd vs Environment direct dans la unit** : préfères-tu créer des `.conf` séparés (proposé) ou modifier directement les units `.service` ?
|
||||
2. **Section 6 — commande exacte smoke live Bloc-notes** : à compléter par toi (commande non documentée dans le runbook car de ta compétence)
|
||||
3. **Section 8 — protection branche `demo-2026-06-01`** : pre-push hook git, branche read-only sur Gitea, ou simplement convention équipe ?
|
||||
4. **Risque R6 EasyOCR** : tu veux que je fasse l'investigation lecture seule maintenant (sans patcher) pour identifier la modif et son intention ?
|
||||
5. **Profil démo Niveau VLM** : confirmation explicite — on garde `qwen2.5vl:7b-rpa` (`num_ctx=4096` via D5-v3a) comme modèle grounding pour la démo, pas qwen3.5 ?
|
||||
6. **Cas `agent_demo_user` session** : la fixture C2 est `sess_20260520T102916_066851`, mais la démo réelle utilise probablement une session différente (Bloc-notes ou Easily). Quelle fixture est la référence smoke ?
|
||||
|
||||
---
|
||||
|
||||
## Fin du runbook
|
||||
|
||||
Auteur : Claude
|
||||
Statut : draft pour arbitrage Codex/Dom. Aucune commande exécutée. Aucun patch posé. Aucun service redémarré.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Arbitrage Dom — démo interactive Léa
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 11:55 Europe/Paris
|
||||
- `Statut`: **source de vérité active**
|
||||
- `Complète`: `docs/coordination/active/2026-05-26_arbitrage-dom-demo-reelle-poc.md`
|
||||
|
||||
## Décision Dom
|
||||
|
||||
Dom précise que, pour cette démo, le client veut voir aussi de l'interaction avec Léa.
|
||||
|
||||
Le schéma de la précédente démo doit donc être modifié : il ne suffit pas de rejouer un ancien parcours filmé ou un workflow linéaire. La démonstration doit montrer une boucle plus proche de l'usage POC :
|
||||
|
||||
1. Léa observe/lit des données affichées à l'écran.
|
||||
2. Léa explicite ce qu'elle a compris ou demande confirmation.
|
||||
3. Léa reporte ces données dans une autre interface ou un autre environnement.
|
||||
4. L'humain garde le contrôle sur les étapes sensibles.
|
||||
|
||||
Environnements visés :
|
||||
|
||||
- VM ;
|
||||
- NoMachine ;
|
||||
- Citrix ;
|
||||
- maquette Easily / aiva-vision.
|
||||
|
||||
## Ligne produit
|
||||
|
||||
Le but n'est pas de faire une vitrine artificielle. Le client a déjà vu un scénario réel filmé ; il veut maintenant voir Léa agir en vrai.
|
||||
|
||||
La démo doit donc montrer :
|
||||
|
||||
- compréhension du contexte affiché ;
|
||||
- lecture de champs visibles à l'écran ;
|
||||
- report de valeurs dans une autre interface ;
|
||||
- interaction naturelle avec Léa ;
|
||||
- confirmation humaine au bon moment ;
|
||||
- robustesse observable plutôt qu'effet spectaculaire.
|
||||
|
||||
## Impact scénario
|
||||
|
||||
Le scénario métier minimal doit être révisé :
|
||||
|
||||
- conserver un parcours court ;
|
||||
- éviter un grand workflow fragile ;
|
||||
- intégrer une phase explicite de dialogue avec Léa ;
|
||||
- intégrer au moins une lecture d'information écran ;
|
||||
- intégrer au moins une retranscription/report contrôlé dans une autre zone ou interface ;
|
||||
- conserver la vraie chaîne capture/trace/build/replay si un workflow est enregistré ;
|
||||
- ne pas basculer vers un mode VWB cosmétique.
|
||||
|
||||
## Hypothèse technique
|
||||
|
||||
Dom estime que ce changement ne pose pas de difficulté majeure avec les progrès récents :
|
||||
|
||||
- Léa est jugée plus sûre que le VWB pour cette interaction ;
|
||||
- le socle Notepad a validé les gardes de fenêtre/dialogue ;
|
||||
- le profil démo stabilise les coûts ;
|
||||
- les briques lecture/grounding/replay sont utilisables à condition de rester court et contrôlé.
|
||||
|
||||
## Critère de réussite
|
||||
|
||||
La réussite n'est pas seulement "le workflow finit".
|
||||
|
||||
La réussite est :
|
||||
|
||||
- Léa lit une donnée visible ;
|
||||
- Léa la restitue correctement ;
|
||||
- Léa la reporte dans la bonne cible ;
|
||||
- Léa demande confirmation ou pause si ambiguïté ;
|
||||
- les logs/traces permettent de comprendre ce qui s'est passé.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,50 @@
|
||||
# Arbitrage Dom — démo réelle, socle POC
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 11:40 Europe/Paris
|
||||
- `Statut`: **source de vérité active**
|
||||
|
||||
## Décision Dom
|
||||
|
||||
Dom précise :
|
||||
|
||||
> Un vrai scénario vers ce client a déjà été fait, il était filmé. Cette fois-ci le client veut voir en vrai. On va faire court mais bien avec des interactions. L'objectif est la démo, mais pas seulement : ensuite on enchaîne sur des POC. Donc pas de trucage, pas de bidouillage, on fait du solide, démo ou pas démo.
|
||||
|
||||
## Conséquences
|
||||
|
||||
- Le scénario peut être **court**, mais il doit être **réellement exécuté**.
|
||||
- Pas de succès simulé, pas de replay cosmétique, pas de coordonnées hardcodées pour faire illusion.
|
||||
- Pas de contournement silencieux des garde-fous de vérification.
|
||||
- Pas de données réelles : la maquette est fictive, mais le comportement de Léa doit rester authentique.
|
||||
- Si le scénario échoue, on documente l'échec et on corrige ; on ne maquille pas le résultat.
|
||||
|
||||
## Ligne technique
|
||||
|
||||
La démo doit s'appuyer sur la chaîne réelle :
|
||||
|
||||
1. capture par Dom sur la maquette Easily ;
|
||||
2. inspection de la trace brute ;
|
||||
3. build replay avec profil démo explicite ;
|
||||
4. validation offline de la queue d'actions ;
|
||||
5. replay live seulement avec GO Dom ;
|
||||
6. logs et métriques conservés localement pour analyse POC.
|
||||
|
||||
Le profil démo reste autorisé uniquement comme profil produit assumé :
|
||||
|
||||
- `RPA_SKIP_INTENTION_ENRICHMENT=true`
|
||||
- `RPA_SKIP_BUILD_VISION=true`
|
||||
- `RPA_EASYOCR_GPU=0`
|
||||
- `AGENT_CHAT_ENABLE_OWL=0`
|
||||
- `AGENT_CHAT_ENABLE_UI_DETECTION=0`
|
||||
|
||||
Ces flags ne doivent pas masquer un échec de grounding ou d'exécution. Ils servent à supprimer des coûts non nécessaires à la démonstration et à stabiliser la machine.
|
||||
|
||||
## Critères de solidité
|
||||
|
||||
- Reproductibilité : le même scénario peut être relancé sous supervision.
|
||||
- Observabilité : trace, screenshots, logs et décisions de replay inspectables.
|
||||
- Sobriété : 6 à 10 interactions métier valent mieux qu'un grand parcours fragile.
|
||||
- Authenticité : Léa clique, saisit, confirme ou demande de l'aide pour de vraies raisons.
|
||||
- Préparation POC : les choix faits aujourd'hui doivent rester défendables après la démo.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,78 @@
|
||||
# Arbitrage scroll — reference VWB
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 Europe/Paris
|
||||
- `Statut`: arbitrage actif
|
||||
|
||||
## Point Dom
|
||||
|
||||
Dom rappelle que, sur la demo VWB precedente, les scrolls n'avaient pas pose de probleme.
|
||||
|
||||
Ce rappel est juste et doit corriger notre prudence excessive : le scroll ne doit pas faire sortir `Synthese Urgences` du perimetre cible par principe.
|
||||
|
||||
## Verification code
|
||||
|
||||
Le chemin VWB contenait deja un contrat explicite pour les zones longues :
|
||||
|
||||
- `visual_workflow_builder/backend/api_v3/dag_execute.py` pre-expanse `extract_text_scroll` en 6 sous-steps atomiques ;
|
||||
- `agent_v0/server_v1/replay_engine.py` possede le meme principe cote replay.
|
||||
|
||||
Sequence contractuelle :
|
||||
|
||||
1. `extract_text` sur la zone visible haute ;
|
||||
2. `key_combo ctrl+end` ;
|
||||
3. `wait scroll_pause_ms` ;
|
||||
4. `extract_text` sur la zone visible basse ;
|
||||
5. `_concat_text_vars` ;
|
||||
6. `key_combo ctrl+home`.
|
||||
|
||||
Donc le sujet n'est pas "le scroll est fragile", mais :
|
||||
|
||||
- verifier que le workflow demo utilise bien `extract_text_scroll` sur les onglets longs ;
|
||||
- verifier que l'expansion est active sur le chemin execute ;
|
||||
- valider le resultat par marqueurs metier.
|
||||
|
||||
## Correction d'arbitrage
|
||||
|
||||
Perimetre cible demo :
|
||||
|
||||
1. `Motif d'admission`
|
||||
2. `Examens cliniques`
|
||||
3. `Imagerie`
|
||||
4. `Notes medicales`
|
||||
5. `Synthese Urgences` avec lecture haut + bas
|
||||
|
||||
`Synthese Urgences` reste dans la cible live.
|
||||
|
||||
La bascule a 4 onglets ne doit intervenir que si une repetition concrete montre un echec non recupere :
|
||||
|
||||
- action `extract_text_scroll` non appelee ;
|
||||
- scroll fait mais marqueurs bas absents apres retry ;
|
||||
- mauvais onglet/patient ;
|
||||
- OCR vide sans arret humain.
|
||||
|
||||
Le simple fait que `Synthese Urgences` necessite un scroll n'est plus un critere de degrade.
|
||||
|
||||
## Marqueurs obligatoires
|
||||
|
||||
Pour `Synthese Urgences`, la capture haute seule est insuffisante.
|
||||
|
||||
GO si le texte final concatene contient au moins les marqueurs bas attendus :
|
||||
|
||||
- `CCMU`
|
||||
- `GEMSA`
|
||||
- `J12.1`
|
||||
- `Consultation externe`
|
||||
|
||||
Si ces marqueurs ne sont pas trouves, Léa doit annoncer qu'elle n'a pas toute la page et demander une reprise/validation humaine.
|
||||
|
||||
## Note sur l'ancien incident
|
||||
|
||||
L'ancien blocage documente sur `Notes medicales` / `Synthese Urgences` n'etait pas un echec de scroll :
|
||||
|
||||
- cause primaire : timeout client 5s pendant que le serveur executait `extract_text`, puis perte silencieuse des actions suivantes ;
|
||||
- cause aggravante : grounding OCR de la barre d'onglets, plusieurs onglets detectes comme une seule ligne.
|
||||
|
||||
Ces causes doivent rester surveillees, mais elles ne justifient pas de traiter le scroll comme impossible.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,47 @@
|
||||
# Arbitrage sortie de transposition — OnlyOffice
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 20:56 Europe/Paris
|
||||
- `Statut`: **source active**
|
||||
- `Répond à`: scénario v2 collecte/transposition
|
||||
|
||||
## Décision
|
||||
|
||||
La sortie de transposition visible recommandée pour J-6 est un tableur ouvert dans **OnlyOffice**.
|
||||
|
||||
LibreOffice n'est pas installé côté Linux, mais OnlyOffice est disponible :
|
||||
|
||||
```bash
|
||||
/snap/bin/onlyoffice-desktopeditors
|
||||
```
|
||||
|
||||
## Ligne démo
|
||||
|
||||
Léa doit montrer la boucle :
|
||||
|
||||
1. collecte des informations dans Easily ;
|
||||
2. structuration des données ;
|
||||
3. génération d'un fichier tableur local (`.xlsx` ou `.csv`) ;
|
||||
4. ouverture visible dans OnlyOffice ;
|
||||
5. arrêt pour validation humaine.
|
||||
|
||||
## Format recommandé
|
||||
|
||||
Colonnes minimales :
|
||||
|
||||
- `IPP`
|
||||
- `Nom`
|
||||
- `Prénom`
|
||||
- `Motif`
|
||||
- `Statut`
|
||||
- `Informations collectées`
|
||||
- `Proposition Aiva-urgence`
|
||||
- `Commentaire humain`
|
||||
|
||||
## Critère de réussite
|
||||
|
||||
Le client doit voir un artefact lisible dans un autre outil que l'interface source.
|
||||
|
||||
La génération fichier seule ne suffit pas : le fichier doit être ouvert ou présenté visiblement.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,55 @@
|
||||
# Audit rapide ancien workflow `Urgence_aiva_demo`
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 12:00 Europe/Paris
|
||||
- `Statut`: **constat actif**
|
||||
- `Workflow`: `wf_a38aeebea5e6_1778162737` / `Urgence_aiva_demo`
|
||||
|
||||
## Constat
|
||||
|
||||
Le workflow existe dans le VWB et contient déjà plusieurs briques utiles :
|
||||
|
||||
- `extract_table`
|
||||
- `pause_for_human`
|
||||
- `click_anchor`
|
||||
- `extract_text`
|
||||
- `extract_text_scroll`
|
||||
- `t2a_decision`
|
||||
- `type_text`
|
||||
|
||||
Il est donc précieux comme référence technique.
|
||||
|
||||
## Problème
|
||||
|
||||
Il ne doit pas être repris tel quel comme source de vérité de la démo interactive 2026-06-01.
|
||||
|
||||
Raisons :
|
||||
|
||||
- le scénario correspond à l'ancienne démo linéaire ;
|
||||
- l'ordre des étapes est fragile ;
|
||||
- `t2a_decision` consomme des variables (`t_motif_admission`, `t_examen_clinique`, `t_imagerie`, `t_synthese_urgences`) qui sont extraites plus tard dans le workflow ;
|
||||
- certains labels/ancres sont incohérents ou issus de recalages historiques ;
|
||||
- les étapes 18/20 avaient déjà des limitations documentées sur les fixtures ;
|
||||
- ce workflow ne porte pas explicitement la nouvelle boucle Dom : lecture écran -> restitution Léa -> report contrôlé -> arrêt sûr.
|
||||
|
||||
## Décision Codex
|
||||
|
||||
Ne pas exécuter `wf_a38aeebea5e6_1778162737` tel quel en démo.
|
||||
|
||||
Deux usages autorisés :
|
||||
|
||||
1. référence pour identifier les briques disponibles ;
|
||||
2. matériau pour construire une variante propre.
|
||||
|
||||
## Recommandation
|
||||
|
||||
Créer une variante courte dédiée, ou recapturer proprement avec Dom :
|
||||
|
||||
- nom cible : `wf_easily_interactif_lea_2026-06-01`
|
||||
- 6 à 10 étapes visibles ;
|
||||
- extraction texte avant analyse ;
|
||||
- pause/confirmation avant report ;
|
||||
- report contrôlé dans `#dpi-input` / `#aiva-justification` ;
|
||||
- arrêt sûr si lecture ou cible ambiguë.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,102 @@
|
||||
# Benchmark OCR local — captures Easily
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 22:05 Europe/Paris
|
||||
- `Statut`: resultats mesures locaux
|
||||
- `Sources`: `output/playwright/easily_dryrun_2026-05-26/`
|
||||
- `Objectif`: arbitrer le patch OCR minimal J-6
|
||||
|
||||
## Synthese
|
||||
|
||||
Sur les captures dry-run Easily, **Tesseract est le meilleur moteur pour les IPP/chiffres** : 11/11 IPP exacts sur `landing_wide.png` en ~0,47s.
|
||||
|
||||
EasyOCR brut reste solide pour le texte continu et les onglets : tous les marqueurs metier critiques sont retrouves, sauf IPP secondaires.
|
||||
|
||||
Le preprocessing OpenCV teste degrade certains marqueurs (`J12.1`, `Aucun`, `11 dossiers`) et multiplie la latence par environ 2-3. Il ne doit pas etre active par defaut sans ciblage.
|
||||
|
||||
docTR CPU est bon sur bandeau patient et synthese basse, mais rate un IPP (`25012257` lu `2501225/`) sur la colonne IPP. Sur ce jeu de captures, il n'est pas superieur a Tesseract pour les chiffres.
|
||||
|
||||
## Resultats par moteur
|
||||
|
||||
### Marqueurs metier plein ecran
|
||||
|
||||
| Capture | EasyOCR brut | EasyOCR preproc | Tesseract |
|
||||
|---|---:|---:|---:|
|
||||
| `landing_wide.png` | 5/5 | 4/5 (`11 dossiers` manque) | 5/5 |
|
||||
| `dossier_motif.png` | 4/4 | 3/4 (`J12.1` manque) | 4/4 |
|
||||
| `dossier_examens.png` | 4/4 | 4/4 | 4/4 |
|
||||
| `dossier_imagerie.png` | 2/2 | 1/2 (`Aucun` manque) | 2/2 |
|
||||
| `dossier_notes.png` | 3/3 | 3/3 | 3/3 |
|
||||
| `dossier_synthese.png` | 1/1 | 1/1 | 1/1 |
|
||||
| `dossier_synthese_bottom.png` | 5/5 | 5/5 | 5/5 |
|
||||
|
||||
### IPP exacts sur `landing_wide.png`
|
||||
|
||||
IPP attendus :
|
||||
|
||||
```text
|
||||
25003284, 25003362, 25003364, 25003451, 25003475, 25005866,
|
||||
25010621, 25012257, 25048485, 25056615, 25151530
|
||||
```
|
||||
|
||||
| Moteur | Exact | Latence | Notes |
|
||||
|---|---:|---:|---|
|
||||
| EasyOCR brut | 8/11 | ~2,61s | confusions `25003362`, `25003364`, `25012257` |
|
||||
| EasyOCR preproc | 9/11 | ~4,55s | corrige `25003362`, mais garde des confusions |
|
||||
| Tesseract plein ecran | **11/11** | **~0,47s** | meilleur resultat |
|
||||
| docTR CPU crop colonne IPP | 10/11 | ~0,65s apres init | `25012257` lu `2501225/` |
|
||||
|
||||
### docTR CPU crops critiques
|
||||
|
||||
| Crop | Resultat | Latence apres init |
|
||||
|---|---|---:|
|
||||
| colonne IPP | 10/11 exacts, erreur sur `25012257` | ~0,65s |
|
||||
| bandeau dossier | `25003284`, `MOREL`, `Catherine` OK | ~0,60s |
|
||||
| synthese basse | `CCMU`, `GEMSA`, `J12.1`, `Consultation externe`, `UC CONSULT` OK | ~0,98s |
|
||||
|
||||
Init docTR mesuree :
|
||||
|
||||
- import : ~1,54s ;
|
||||
- predictor init : ~0,90s.
|
||||
|
||||
## Arbitrage technique provisoire
|
||||
|
||||
Pour J-6 :
|
||||
|
||||
1. **Ne pas activer preprocessing OpenCV global par defaut** : gain non prouve, regressions marqueurs.
|
||||
2. **Garder EasyOCR brut** pour texte continu et onglets.
|
||||
3. **Ajouter Tesseract comme extraction specialisee IPP/chiffres** sur tableau/liste, via ROI si possible.
|
||||
4. **Utiliser docTR seulement si besoin de bboxes/zonage structure**, pas comme remplacement general.
|
||||
5. **PaddleOCR non teste** dans cette passe : reporte sauf besoin post-demo.
|
||||
6. **VLM non retenu pour OCR texte pur**.
|
||||
|
||||
## Patch minimal recommande
|
||||
|
||||
Patch candidat :
|
||||
|
||||
- `core/llm/ocr_extractor.py`
|
||||
- ajouter une fonction `extract_digits_tesseract_from_image(image_path, region=None, pattern=None)`;
|
||||
- utiliser Tesseract uniquement pour les champs chiffres/IPP ;
|
||||
- ne pas modifier le comportement existant de `extract_text_from_image`.
|
||||
|
||||
Patch optionnel :
|
||||
|
||||
- `core/llm/ocr_extractor.py`
|
||||
- ajouter `extract_text_doctr_from_image(image_path, region=None)` pour test futur sur zones structurees ;
|
||||
- pas branche par defaut dans le workflow demo sans nouvelle mesure.
|
||||
|
||||
Fail-safe :
|
||||
|
||||
- si EasyOCR et Tesseract divergent sur un IPP critique, Léa ne cite pas l'IPP comme certain et demande confirmation.
|
||||
|
||||
## Impact scenario demo
|
||||
|
||||
Maintenir :
|
||||
|
||||
- pas d'enumeration des IPP secondaires par EasyOCR ;
|
||||
- description du tableau + choix humain ;
|
||||
- dossier cible `MOREL Catherine / 25003284` OK ;
|
||||
- 5 onglets cible, incluant `Synthese Urgences` avec `extract_text_scroll` haut + bas ;
|
||||
- 4 onglets seulement en degrade si la repetition montre un echec concret non recupere des marqueurs bas (`CCMU`, `GEMSA`, `J12.1`, `Consultation externe`).
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,92 @@
|
||||
# Cadrage produit — Aiva-vision, Léa, plugins métier
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 14:13 Europe/Paris
|
||||
- `Statut`: **source de vérité active**
|
||||
- `Source`: clarification Dom
|
||||
|
||||
## Vocabulaire produit
|
||||
|
||||
### Aiva-vision
|
||||
|
||||
Aiva-vision est le socle commun de la plateforme.
|
||||
|
||||
Son rôle :
|
||||
|
||||
- apprendre des interfaces existantes ;
|
||||
- comprendre ce qui est affiché à l'écran ;
|
||||
- interagir avec des applications métiers ;
|
||||
- orchestrer des actions contrôlées ;
|
||||
- fournir un socle réutilisable au-delà d'un domaine particulier.
|
||||
|
||||
Aiva-vision est pensé comme un produit universel : santé aujourd'hui, aéronautique ou autres secteurs demain.
|
||||
|
||||
### Léa
|
||||
|
||||
Léa est l'agent d'interaction d'Aiva-vision.
|
||||
|
||||
Son rôle :
|
||||
|
||||
- dialoguer avec l'utilisateur ;
|
||||
- observer/lire l'écran ;
|
||||
- demander confirmation ;
|
||||
- exécuter ou guider les actions ;
|
||||
- apprendre quand elle ne sait pas faire ;
|
||||
- s'arrêter plutôt que risquer une action incertaine.
|
||||
|
||||
Léa matérialise l'interaction humain-machine du produit.
|
||||
|
||||
### Plugins métier
|
||||
|
||||
Les plugins métier se greffent sur Aiva-vision.
|
||||
|
||||
Ils apportent :
|
||||
|
||||
- les règles métier ;
|
||||
- les workflows propres au domaine ;
|
||||
- les modèles ou fonctions spécialisées ;
|
||||
- les critères de décision ;
|
||||
- les restitutions adaptées aux utilisateurs métier.
|
||||
|
||||
## Exemple démo : Aiva-urgence
|
||||
|
||||
Dans la démo du 2026-06-01, le plugin métier est **Aiva-urgence**.
|
||||
|
||||
Aiva-urgence travaille avec Léa pour traiter des dossiers patients sur une maquette Easily.
|
||||
|
||||
Objectif métier :
|
||||
|
||||
- lire les informations du dossier patient ;
|
||||
- qualifier ou requalifier le passage ;
|
||||
- décider entre :
|
||||
- Forfait Urgences ;
|
||||
- hospitalisation / requalification UHCD-MCO ;
|
||||
- reporter ou justifier le résultat dans l'interface cible ;
|
||||
- demander confirmation humaine sur les étapes sensibles.
|
||||
|
||||
## Positionnement de la démo
|
||||
|
||||
La démo ne présente pas seulement un automatisme RPA.
|
||||
|
||||
Elle doit montrer :
|
||||
|
||||
1. Aiva-vision comme plateforme d'apprentissage et d'interaction avec interfaces existantes.
|
||||
2. Léa comme agent prudent, supervisable et capable d'apprendre.
|
||||
3. Aiva-urgence comme plugin métier santé, spécialisé dans le traitement/codage de dossiers urgences.
|
||||
4. Une boucle réelle : lecture écran -> compréhension métier -> confirmation -> report contrôlé.
|
||||
|
||||
## Message client
|
||||
|
||||
Message court recommandé :
|
||||
|
||||
> Aiva-vision est notre plateforme générique d'interaction avec les interfaces métier. Léa en est l'agent : elle observe, apprend, agit et demande de l'aide quand c'est nécessaire. Pour cette démonstration, nous avons branché le plugin métier Aiva-urgence, qui aide à qualifier les dossiers patients entre forfait urgences et requalification en hospitalisation.
|
||||
|
||||
## Conséquences scénario
|
||||
|
||||
- Ne pas présenter Aiva-urgence comme tout le produit.
|
||||
- Ne pas réduire Léa à un simple replay de clics.
|
||||
- Ne pas vendre une autonomie totale immédiate.
|
||||
- Présenter l'apprentissage supervisé comme une propriété normale du produit.
|
||||
- Montrer que le même socle pourra accueillir d'autres plugins métier.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,99 @@
|
||||
# Dry-run Easily v2 — captures, OCR, scroll, OnlyOffice
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 21:05 Europe/Paris
|
||||
- `Statut`: resultat dry-run local
|
||||
- `Scenario`: `2026-05-26_scenario-operatoire-demo-lea-v2-collecte-transposition.md`
|
||||
- `Dossier cible`: `MOREL Catherine / IPP 25003284`
|
||||
|
||||
## Environnement
|
||||
|
||||
- Maquette : `http://127.0.0.1:8765/index.html`
|
||||
- Dossier : `http://127.0.0.1:8765/dossier.html?id=25003284`
|
||||
- Sortie tableur : OnlyOffice via `/snap/bin/onlyoffice-desktopeditors`
|
||||
- LibreOffice : absent, ne pas utiliser dans les consignes demo
|
||||
|
||||
## Artefacts produits
|
||||
|
||||
Repertoire :
|
||||
|
||||
```bash
|
||||
output/playwright/easily_dryrun_2026-05-26/
|
||||
```
|
||||
|
||||
Captures :
|
||||
|
||||
- `landing.png`
|
||||
- `landing_wide.png`
|
||||
- `dossier_motif.png`
|
||||
- `dossier_examens.png`
|
||||
- `dossier_imagerie.png`
|
||||
- `dossier_notes.png`
|
||||
- `dossier_synthese.png`
|
||||
- `dossier_synthese_bottom.png`
|
||||
|
||||
Sorties :
|
||||
|
||||
- `aiva_urgence_collecte_morel_25003284.xlsx`
|
||||
- `aiva_urgence_collecte_morel_25003284.csv`
|
||||
|
||||
OnlyOffice a ete lance avec le `.xlsx`. Fenetre detectee :
|
||||
|
||||
```text
|
||||
aiva_urgence_collecte_morel_25003284.xlsx — ONLYOFFICE
|
||||
```
|
||||
|
||||
## Resultat OCR
|
||||
|
||||
Controle EasyOCR sur captures Playwright :
|
||||
|
||||
| Capture | Chars OCR | Chaines trouvees | Manques importants |
|
||||
|---|---:|---|---|
|
||||
| `landing.png` | 1531 | `Liste des passages`, `25003284`, `MOREL`, `Asthme` | exactitude imparfaite sur IPP secondaires |
|
||||
| `landing_wide.png` | 1531 | `25003284`, `MOREL`, `11 dossiers` dans le pied de page | `25003362`, `25003364`, `25012257` mal lus |
|
||||
| `dossier_motif.png` | 1047 | `25003284`, `MOREL`, `Observations`, `J12.1` | valeur `39` non retrouvee sur cette capture |
|
||||
| `dossier_examens.png` | 875 | `Examens`, `febrile`, `Sibilants`, `Verrouille` | aucun bloquant |
|
||||
| `dossier_imagerie.png` | 544 | `Aucun`, `imagerie` | aucun bloquant |
|
||||
| `dossier_notes.png` | 1325 | `Infection`, `VRS`, `augmentin`, `RESULTATS` | aucun bloquant |
|
||||
| `dossier_synthese.png` | 939 | `Synthese` | `CCMU`, `GEMSA`, `Consultation externe`, `J12.1` absents |
|
||||
| `dossier_synthese_bottom.png` | 931 | `CCMU`, `GEMSA`, `Consultation externe`, `UC CONSULT`, `J12.1` | aucun bloquant apres scroll |
|
||||
|
||||
## Enseignements
|
||||
|
||||
1. Le dossier cible est suffisamment lisible pour une demo courte supervisee.
|
||||
2. Lister tous les IPP un par un par OCR seul n'est pas assez fiable : certains IPP secondaires sont deformes.
|
||||
3. La phrase demo doit donc eviter "je vais enumerer exactement les 11 IPP". Elle peut dire : "je vois 11 dossiers, avec des colonnes IPP, patient, motif, medecin, statut ; souhaitez-vous tous les traiter ou en choisir un ?"
|
||||
4. La synthese urgences exige une extraction scroll : capture haute seule insuffisante, capture bas obligatoire.
|
||||
5. Le tableur OnlyOffice est valide comme cible visible J-6.
|
||||
|
||||
## GO/NOGO provisoire
|
||||
|
||||
GO pour repetition si :
|
||||
|
||||
- `25003284`, `MOREL`, `Catherine` lus dans le bandeau dossier ;
|
||||
- au moins 4 onglets sur 5 produisent un OCR non vide ;
|
||||
- `Notes medicales` contient `VRS` ou `augmentin` ;
|
||||
- `Synthese Urgences` top+bottom contient `CCMU`, `GEMSA`, `J12.1`, `Consultation externe` ;
|
||||
- le fichier `.xlsx` est genere et ouvert dans OnlyOffice.
|
||||
|
||||
NOGO si :
|
||||
|
||||
- mauvais patient ouvert ;
|
||||
- OCR vide sur un onglet sans arret humain ;
|
||||
- synthese basse non capturee ;
|
||||
- sortie tableur generee mais non ouverte visiblement ;
|
||||
- Léa annonce des IPP secondaires inexacts comme s'ils etaient certains.
|
||||
|
||||
## Consequence demo
|
||||
|
||||
Scenario recommande maintenu :
|
||||
|
||||
1. Léa decrit la table et le nombre de dossiers.
|
||||
2. Léa demande tous les dossiers ou un dossier.
|
||||
3. Dom choisit `MOREL Catherine / 25003284`.
|
||||
4. Léa collecte les onglets avec scroll obligatoire sur `Synthese Urgences`.
|
||||
5. Léa genere le tableur.
|
||||
6. Léa ouvre le tableur dans OnlyOffice.
|
||||
7. Léa s'arrete pour validation humaine.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,53 @@
|
||||
# Etat preparation — repetition humaine 2026-05-27
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 Europe/Paris
|
||||
- `Statut`: pret pour repetition humaine
|
||||
|
||||
## Etat fonctionnel
|
||||
|
||||
- Maquette Easily locale accessible : `http://127.0.0.1:8765/`
|
||||
- Streaming server Léa : `http://127.0.0.1:5005/health` OK
|
||||
- Agent chat : `http://127.0.0.1:5004/api/status` OK
|
||||
- OnlyOffice disponible : `/snap/bin/onlyoffice-desktopeditors`
|
||||
- Tesseract disponible : `/usr/bin/tesseract`
|
||||
- Langues Tesseract : `eng`, `fra`, `osd`
|
||||
|
||||
## Preparations faites
|
||||
|
||||
- Runbook humain challenge cree :
|
||||
- `docs/coordination/active/2026-05-26_runbook-repetition-humain-challenge-demo-v2.md`
|
||||
- Principe scroll securise acte :
|
||||
- `docs/coordination/active/2026-05-26_principe-apprentissage-scroll-securise.md`
|
||||
- Patch OCR Tesseract IPP/chiffres implemente :
|
||||
- `docs/coordination/active/2026-05-26_patch-ocr-tesseract-ipp.md`
|
||||
- Workflow `Demo_urgence_3_db` branche sur `engine="tesseract"` pour `extract_table`.
|
||||
|
||||
## Verification technique
|
||||
|
||||
Tests executes :
|
||||
|
||||
```bash
|
||||
pytest -q tests/unit/test_ocr_extractor_tesseract.py tests/integration/test_t2a_extract.py
|
||||
python3 -m compileall -q core/llm/ocr_extractor.py core/llm/__init__.py agent_v0/server_v1/replay_engine.py tests/unit/test_ocr_extractor_tesseract.py tests/integration/test_t2a_extract.py
|
||||
```
|
||||
|
||||
Resultat : OK, 40 tests passes.
|
||||
|
||||
Capture `landing_wide.png` :
|
||||
|
||||
- extraction IPP Tesseract : 11/11 exacts.
|
||||
|
||||
## Attention demain
|
||||
|
||||
Dom joue l'humain challenge :
|
||||
|
||||
- il peut interrompre ;
|
||||
- il peut refuser ;
|
||||
- il peut demander une preuve ;
|
||||
- il peut demander une reprise ;
|
||||
- il peut verifier que Léa ne conclut pas sans validation.
|
||||
|
||||
Critere principal : qualite et arret propre avant fluidite.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,72 @@
|
||||
# Mission P0 OCR écran - suivi coordination
|
||||
|
||||
Date: 2026-05-26 21:14 Europe/Paris
|
||||
Owner: Qwen / agent spécialisé OCR écran
|
||||
Statut: envoyé, en attente rapport
|
||||
Mode: read-only strict
|
||||
|
||||
## Pourquoi
|
||||
|
||||
Le dry-run Easily v2 a confirmé que l'OCR actuel lit correctement le dossier cible `MOREL Catherine / 25003284`, mais il n'est pas encore assez robuste pour une démonstration produit où Léa doit lire des écrans DPI avec précision:
|
||||
- confusion possible sur certains IPP secondaires,
|
||||
- besoin de scroll pour récupérer la synthèse basse,
|
||||
- nécessité de seuils GO/NOGO explicites avant le 2026-06-01.
|
||||
|
||||
## Mission envoyée
|
||||
|
||||
Qwen:
|
||||
|
||||
`docs/coordination/inbox_qwen/2026-05-26_2114_codex-to-qwen_MISSION-P0-ocr-ecran-readonly.md`
|
||||
|
||||
Claude informé:
|
||||
|
||||
`docs/coordination/inbox_claude/2026-05-26_2114_codex-to-claude_INFO-mission-P0-ocr-confiee-qwen.md`
|
||||
|
||||
## Livrable attendu
|
||||
|
||||
`docs/coordination/inbox_codex/2026-05-26_HHMM_qwen-to-codex_RAPPORT-P0-ocr-ecran.md`
|
||||
|
||||
Le rapport doit couvrir:
|
||||
- audit pipeline OCR/scroll existant,
|
||||
- options testables immédiatement ou nécessitant installation,
|
||||
- plan J-6,
|
||||
- seuils GO/NOGO DPI,
|
||||
- références fichiers/lignes,
|
||||
- patches proposés pour une passe suivante uniquement.
|
||||
|
||||
## Addendum Dom - interface apprise
|
||||
|
||||
Dom a ajouté une contrainte produit structurante:
|
||||
|
||||
Après avoir vu une interface plusieurs fois, Léa ne doit plus faire une OCR plein écran naïve. Elle doit exploiter une carte d'interface apprise:
|
||||
- zones d'intérêt,
|
||||
- ancres stables,
|
||||
- ROI par champ,
|
||||
- scroll attendu,
|
||||
- champs critiques,
|
||||
- seuils de drift.
|
||||
|
||||
Addendum envoyé à Qwen:
|
||||
|
||||
`docs/coordination/inbox_qwen/2026-05-26_2115_codex-to-qwen_ADDENDUM-P0-ocr-interface-apprise.md`
|
||||
|
||||
Le rapport Qwen doit donc distinguer:
|
||||
- stratégie cold start,
|
||||
- stratégie interface apprise,
|
||||
- trajectoire immédiate demo 2026-06-01,
|
||||
- trajectoire socle produit Aiva-vision.
|
||||
|
||||
## Décision actuelle
|
||||
|
||||
Tant que le rapport Qwen n'est pas reçu, Codex ne modifie pas le moteur OCR partagé. Le scénario de démo reste cadré fail-safe: Léa doit s'arrêter et demander confirmation quand la confiance de lecture est insuffisante.
|
||||
|
||||
## Addendum Dom — apprentissage interface
|
||||
|
||||
Le rapport Qwen doit intégrer le principe produit suivant : Léa apprend l'interface. Après plusieurs vues validées, typiquement une dizaine, elle doit pouvoir se concentrer directement sur les zones utiles au protocole métier au lieu de refaire une OCR plein écran systématique.
|
||||
|
||||
Attendu dans le rapport :
|
||||
|
||||
- stratégie `cold start` ;
|
||||
- stratégie `interface apprise` avec ROI/ancres/champs critiques ;
|
||||
- détection de drift ;
|
||||
- bascule fail-safe vers confirmation humaine.
|
||||
121
docs/coordination/active/2026-05-26_mission-p0-ocr-ecran-lea.md
Normal file
121
docs/coordination/active/2026-05-26_mission-p0-ocr-ecran-lea.md
Normal file
@@ -0,0 +1,121 @@
|
||||
# Mission P0 — OCR ecran Léa
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 21:25 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Priorite`: P0 demo 2026-06-01
|
||||
- `Produit`: Aiva-vision / Léa
|
||||
|
||||
## Pourquoi
|
||||
|
||||
Dom demande le meilleur niveau possible sur l'OCR ecran. Le sujet est critique pour Aiva-vision : Léa doit lire des interfaces metier reelles, pas seulement des documents propres.
|
||||
|
||||
Le dry-run Easily v2 montre :
|
||||
|
||||
- dossier cible `MOREL Catherine / IPP 25003284` lisible ;
|
||||
- onglets principaux exploitables ;
|
||||
- erreurs OCR sur certains IPP secondaires ;
|
||||
- `Synthese Urgences` incomplete sans scroll ;
|
||||
- sortie OnlyOffice valide.
|
||||
|
||||
Reference :
|
||||
|
||||
- `docs/coordination/active/2026-05-26_dryrun-easily-v2-captures-ocr-onlyoffice.md`
|
||||
|
||||
## Objectif
|
||||
|
||||
Construire une strategie OCR ecran robuste pour la demo et les POC :
|
||||
|
||||
1. lire correctement des tableaux ecran ;
|
||||
2. detecter les erreurs au lieu de continuer silencieusement ;
|
||||
3. gerer les zones longues/scroll ;
|
||||
4. combiner OCR, segmentation, ROI, validation et fallback ;
|
||||
5. produire des seuils GO/NOGO mesurables.
|
||||
|
||||
## Principe produit Dom — interface apprise
|
||||
|
||||
L'OCR ecran ne doit pas rester une lecture plein ecran naive a chaque passage.
|
||||
|
||||
Mode attendu :
|
||||
|
||||
- **cold start** : Léa decouvre l'interface, lit large, identifie les zones, demande confirmation et enregistre les reperes ;
|
||||
- **apprentissage** : apres plusieurs passages valides, Léa consolide une carte d'interface : onglets, colonnes, champs critiques, zones longues, ancres stables, comportement de scroll ;
|
||||
- **interface connue** : apres environ 10 vues validees, Léa se concentre directement sur les zones utiles pour le protocole metier, par exemple IPP/patient/statut, notes, diagnostic, CCMU/GEMSA, decision medicale ;
|
||||
- **drift** : si les ancres ou zones attendues ne correspondent plus, Léa repasse en mode prudent et demande confirmation.
|
||||
|
||||
Donc la mission OCR doit produire deux strategies :
|
||||
|
||||
1. lecture robuste en premiere rencontre ;
|
||||
2. lecture ciblee par ROI/ancres quand l'interface est apprise.
|
||||
|
||||
## Contraintes
|
||||
|
||||
- Pas de bidouille demo.
|
||||
- Pas de decision silencieuse si OCR douteux.
|
||||
- Pas de dependance LibreOffice : sortie visible OnlyOffice.
|
||||
- Ne pas destabiliser le runtime J-6.
|
||||
- Les installations nouvelles sont possibles si Dom les valide, mais elles doivent etre justifiees.
|
||||
|
||||
## Axes de travail
|
||||
|
||||
### A. Benchmark OCR ecran
|
||||
|
||||
Tester ou auditer :
|
||||
|
||||
- EasyOCR actuel (`core/llm/ocr_extractor.py`) ;
|
||||
- preprocessing image : upscale, grayscale, contraste, sharpen, crop ROI ;
|
||||
- OCR tableau avec bboxes ;
|
||||
- OCR par zones plutot que plein ecran ;
|
||||
- capture plus haute resolution ;
|
||||
- fallback DOM/UIA quand disponible ;
|
||||
- docTR/Tesseract/PaddleOCR si presents ou installables proprement ;
|
||||
- VLM uniquement comme second avis, pas comme source unique si trop lent/incertain.
|
||||
- carte d'interface apprise : ROI nommees, ancres stables, validation de drift, lecture ciblee.
|
||||
|
||||
### B. Scroll et completude
|
||||
|
||||
Valider :
|
||||
|
||||
- top + bottom obligatoires sur onglet long ;
|
||||
- detection de fin de page ;
|
||||
- concatenation sans doublons dangereux ;
|
||||
- chaines obligatoires par onglet ;
|
||||
- arret humain si champ critique absent.
|
||||
|
||||
### C. Seuils GO/NOGO
|
||||
|
||||
Definir des seuils pratiques :
|
||||
|
||||
- patient cible : IPP + nom + prenom ;
|
||||
- tableau liste : nombre de dossiers + structure colonnes, sans enumeration forcee si OCR douteux ;
|
||||
- dossier : onglets visibles ;
|
||||
- notes : `VRS`, `augmentin` ou equivalent metier ;
|
||||
- synthese : `CCMU`, `GEMSA`, `J12.1`, `Consultation externe` ;
|
||||
- transposition : fichier ouvert visiblement dans OnlyOffice.
|
||||
|
||||
## Delegations
|
||||
|
||||
- Qwen : audit/benchmark OCR ecran et recommandations techniques.
|
||||
- Agent OCR specialise `Anscombe` : audit read-only du pipeline repo et plan d'amelioration sans patch immediat.
|
||||
- Codex : integration, arbitrage, tests locaux, transformation en plan executable.
|
||||
|
||||
## Inventaire local initial
|
||||
|
||||
Disponibles localement :
|
||||
|
||||
- EasyOCR `1.7.2`
|
||||
- OpenCV `4.10.0`
|
||||
- Pillow `12.1.0`
|
||||
- pytesseract `0.3.13`
|
||||
- binaire Tesseract : `/usr/bin/tesseract`
|
||||
- docTR `1.0.1`
|
||||
- PaddleOCR `3.4.0`
|
||||
|
||||
Absents :
|
||||
|
||||
- Surya OCR
|
||||
- keras-ocr
|
||||
|
||||
Conclusion : on peut benchmarker immediatement EasyOCR, Tesseract, docTR et PaddleOCR sans demander d'installation prealable.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,80 @@
|
||||
# Patch OCR — Tesseract specialise IPP/chiffres
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 Europe/Paris
|
||||
- `Statut`: implemente et verifie localement
|
||||
|
||||
## Objectif
|
||||
|
||||
Securiser la lecture des IPP/chiffres pour la demo Aiva-urgence sans modifier le comportement OCR general.
|
||||
|
||||
## Changements
|
||||
|
||||
- `core/llm/ocr_extractor.py`
|
||||
- ajout `extract_digits_tesseract_from_image(...)` ;
|
||||
- ajout du parametre `engine` sur `extract_table_from_image(...)` ;
|
||||
- `engine="easyocr"` reste le defaut ;
|
||||
- `engine="tesseract"`, `"digits"` ou `"ipp"` active Tesseract specialise chiffres.
|
||||
- `core/llm/__init__.py`
|
||||
- export de `extract_digits_tesseract_from_image`.
|
||||
- `agent_v0/server_v1/replay_engine.py`
|
||||
- prise en compte du parametre action `engine` sur `extract_table`.
|
||||
- correction du normaliseur replay : `extract_table` accepte maintenant `variable_name` et transmet `engine`.
|
||||
- `tests/unit/test_ocr_extractor_tesseract.py`
|
||||
- tests unitaires du filtrage numerique et de la delegation `extract_table(engine="tesseract")`.
|
||||
- `tests/integration/test_t2a_extract.py`
|
||||
- test du passage `variable_name` + `engine="tesseract"` dans `_edge_to_normalized_actions`.
|
||||
|
||||
## Verification
|
||||
|
||||
Tests :
|
||||
|
||||
```bash
|
||||
pytest -q tests/unit/test_ocr_extractor_tesseract.py tests/integration/test_t2a_extract.py
|
||||
python3 -m compileall -q core/llm/ocr_extractor.py core/llm/__init__.py agent_v0/server_v1/replay_engine.py tests/unit/test_ocr_extractor_tesseract.py tests/integration/test_t2a_extract.py
|
||||
```
|
||||
|
||||
Resultat : OK, 40 tests passes.
|
||||
|
||||
Verification sur capture reelle :
|
||||
|
||||
```bash
|
||||
python3 -c "from core.llm.ocr_extractor import extract_digits_tesseract_from_image; print(extract_digits_tesseract_from_image('output/playwright/easily_dryrun_2026-05-26/landing_wide.png', pattern=r'^25\\d{6}$'))"
|
||||
```
|
||||
|
||||
Resultat :
|
||||
|
||||
```text
|
||||
25003284, 25003362, 25003364, 25003451, 25003475, 25005866, 25010621, 25012257, 25048485, 25056615, 25151530
|
||||
```
|
||||
|
||||
Donc 11/11 IPP exacts sur `landing_wide.png`.
|
||||
|
||||
## Usage workflow demo
|
||||
|
||||
Le workflow VWB actif `Demo_urgence_3_db` (`wf_483910cdd851_1778750587`) a ete mis a jour :
|
||||
|
||||
- step `step_79c40f5a8342_1778750587`
|
||||
- `action_type`: `extract_table`
|
||||
- ajout `parameters.engine = "tesseract"`
|
||||
|
||||
Sauvegarde BDD avant modification :
|
||||
|
||||
- `visual_workflow_builder/backend/instance/workflows.db.backup_2026-05-26_ocr_tesseract_demo3`
|
||||
|
||||
Contrat attendu pour la liste patients :
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "extract_table",
|
||||
"parameters": {
|
||||
"output_var": "patients",
|
||||
"pattern": "^25\\d{6}$",
|
||||
"engine": "tesseract"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Si EasyOCR et Tesseract divergent sur un champ critique, Léa ne tranche pas seule : elle demande confirmation humaine.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,61 @@
|
||||
# Principe produit — apprentissage du scroll securise
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 Europe/Paris
|
||||
- `Statut`: arbitrage produit actif
|
||||
|
||||
## Decision Dom
|
||||
|
||||
Qualite en premier.
|
||||
|
||||
Quand Léa observe un humain scroller pendant l'apprentissage, elle ne doit pas seulement enregistrer "scroll". Elle doit apprendre la meilleure facon securisee de parcourir cette zone dans ce contexte.
|
||||
|
||||
## Principe
|
||||
|
||||
Le scroll est une competence apprise, pas un raccourci fixe.
|
||||
|
||||
Léa doit apprendre :
|
||||
|
||||
- quelle zone est scrollable : page principale, tableau, panneau interne, iframe/Citrix/NoMachine ;
|
||||
- quel geste humain a fonctionne : molette, `PageDown`, `End`, `Ctrl+End`, barre de defilement, drag ;
|
||||
- quel focus etait necessaire avant le scroll ;
|
||||
- quels marqueurs prouvent que la page a bouge ;
|
||||
- quels marqueurs prouvent que le bas ou la section cible est atteint ;
|
||||
- comment revenir au point de depart si l'action suivante le demande.
|
||||
|
||||
## Rejeu securise
|
||||
|
||||
Au replay, Léa doit privilegier la strategie la plus fiable observee pour cette interface.
|
||||
|
||||
Contrat minimal :
|
||||
|
||||
1. verifier le bon ecran et le bon dossier avant de scroller ;
|
||||
2. identifier ou confirmer la zone scrollable ;
|
||||
3. faire un scroll controle ;
|
||||
4. verifier que l'ecran a bien change ;
|
||||
5. verifier que les marqueurs attendus sont apparus ;
|
||||
6. ne jamais exploiter une extraction incomplete comme certaine ;
|
||||
7. s'arreter et demander a l'humain si les preuves ne sont pas suffisantes.
|
||||
|
||||
## Implication demo Aiva-urgence
|
||||
|
||||
Pour `Synthese Urgences`, on garde le contrat VWB `extract_text_scroll` haut + bas comme base J-6.
|
||||
|
||||
Mais le discours produit doit etre plus large :
|
||||
|
||||
> Quand Léa apprend une interface, elle observe comment l'utilisateur navigue dans les zones longues. Ensuite elle rejoue le geste le plus fiable pour cette zone, verifie que le contenu a bouge et controle les marqueurs attendus. Si elle ne retrouve pas les preuves, elle s'arrete et demande confirmation.
|
||||
|
||||
Marqueurs de validation sur la maquette :
|
||||
|
||||
- `CCMU`
|
||||
- `GEMSA`
|
||||
- `J12.1`
|
||||
- `Consultation externe`
|
||||
|
||||
## Regle qualite
|
||||
|
||||
Un scroll reussi n'est pas un geste envoye.
|
||||
|
||||
Un scroll reussi est un geste envoye + un changement visuel constate + les donnees attendues relues.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,63 @@
|
||||
# Principe Dom — apprentissage et arrêt sûr
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 11:59 Europe/Paris
|
||||
- `Statut`: **source de vérité active**
|
||||
- `Complète`:
|
||||
- `docs/coordination/active/2026-05-26_arbitrage-dom-demo-reelle-poc.md`
|
||||
- `docs/coordination/active/2026-05-26_arbitrage-dom-demo-interaction-lea.md`
|
||||
|
||||
## Décision Dom
|
||||
|
||||
Le client est informé que le système est en POC et qu'il doit subir un apprentissage avant d'être autonome.
|
||||
|
||||
Dans le monde hospitalier, le comportement attendu n'est pas de tenter une action incertaine. Il est préférable que la machine s'arrête et dise :
|
||||
|
||||
- "je ne sais pas" ;
|
||||
- "montre-moi" ;
|
||||
- "confirme-moi cette information" ;
|
||||
- "je préfère m'arrêter plutôt que de risquer une mauvaise action".
|
||||
|
||||
## Conséquence produit
|
||||
|
||||
Un arrêt contrôlé n'est pas un échec de démo si :
|
||||
|
||||
- il intervient sur une ambiguïté réelle ;
|
||||
- il est compréhensible par le client ;
|
||||
- Léa explique ce qui manque ;
|
||||
- l'humain peut confirmer ou montrer ;
|
||||
- la suite peut reprendre proprement.
|
||||
|
||||
## Ligne démo
|
||||
|
||||
La démo doit valoriser :
|
||||
|
||||
- autonomie graduée ;
|
||||
- apprentissage supervisé ;
|
||||
- prudence clinique ;
|
||||
- traçabilité ;
|
||||
- refus des actions dangereuses ou ambiguës.
|
||||
|
||||
## Critère de réussite
|
||||
|
||||
La réussite n'est pas uniquement "Léa fait tout sans s'arrêter".
|
||||
|
||||
La réussite est :
|
||||
|
||||
1. Léa exécute les actions sûres ;
|
||||
2. Léa lit et reporte correctement les données non ambiguës ;
|
||||
3. Léa demande confirmation quand une action peut être risquée ;
|
||||
4. Léa s'arrête proprement quand l'écran ou la cible ne correspond pas ;
|
||||
5. l'humain peut reprendre la main ou montrer l'action attendue.
|
||||
|
||||
## Critère NOGO
|
||||
|
||||
NOGO si Léa :
|
||||
|
||||
- agit malgré une ambiguïté forte ;
|
||||
- saisit une donnée dans le mauvais champ ;
|
||||
- clique dans une mauvaise fenêtre ;
|
||||
- invente une donnée non affichée ;
|
||||
- masque son incertitude au lieu de demander confirmation.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,30 @@
|
||||
# Repartition taches demo v2 — 2026-05-26 21:10
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
- `Objet`: repartir le travail entre Codex, Claude, Qwen
|
||||
|
||||
## Decision
|
||||
|
||||
On travaille en parallele :
|
||||
|
||||
- **Codex** : integration, dry-run local, captures, OCR, artefact tableur, synthese finale.
|
||||
- **Claude** : script operatoire demo v2, points d'arret humain, NOGO, fail-safe.
|
||||
- **Qwen** : audit technique dry-run, seuils GO/NOGO OCR/scroll/grounding, sortie OnlyOffice.
|
||||
|
||||
## Messages emis
|
||||
|
||||
- `docs/coordination/inbox_claude/2026-05-26_2110_codex-to-claude_TACHE-demo-v2-protocole-failsafe-onlyoffice.md`
|
||||
- `docs/coordination/inbox_qwen/2026-05-26_2110_codex-to-qwen_TACHE-audit-technique-dryrun-onlyoffice.md`
|
||||
|
||||
## Arbitrage sortie
|
||||
|
||||
La cible de transposition visible est OnlyOffice :
|
||||
|
||||
```bash
|
||||
/snap/bin/onlyoffice-desktopeditors
|
||||
```
|
||||
|
||||
LibreOffice n'est pas une hypothese valide sur ce poste Linux.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,140 @@
|
||||
# Runbook repetition humaine — demo Aiva-vision / Aiva-urgence v2
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 Europe/Paris
|
||||
- `Statut`: actif pour repetition du 2026-05-27
|
||||
- `Humain challenge`: Dom
|
||||
|
||||
## Objectif
|
||||
|
||||
La repetition du 2026-05-27 ne doit pas etre une repetition confortable.
|
||||
|
||||
Dom joue le role de l'humain reel qui challenge Léa :
|
||||
|
||||
- il peut demander "pourquoi tu lis ca ?" ;
|
||||
- il peut interrompre ;
|
||||
- il peut demander de choisir un dossier particulier ;
|
||||
- il peut demander ou sont les preuves ;
|
||||
- il peut refuser une proposition ;
|
||||
- il peut demander une sortie OnlyOffice ;
|
||||
- il peut verifier que Léa ne saute pas une zone longue.
|
||||
|
||||
La qualite prime sur la fluidite. Un arret propre est un succes produit si Léa explique ce qui manque.
|
||||
|
||||
## Scenario nominal
|
||||
|
||||
1. Ouvrir la maquette Easily, liste des passages aux urgences.
|
||||
2. Léa decrit le tableau sans enumerer tous les IPP secondaires :
|
||||
- 11 dossiers ;
|
||||
- colonnes principales ;
|
||||
- proposition : traiter tous les dossiers ou un dossier precis.
|
||||
3. Dom choisit `MOREL Catherine / IPP 25003284`.
|
||||
4. Léa ouvre le dossier et verifie le bandeau :
|
||||
- `25003284`
|
||||
- `MOREL`
|
||||
- `Catherine`
|
||||
5. Léa collecte les 5 onglets :
|
||||
- `Motif d'admission`
|
||||
- `Examens cliniques`
|
||||
- `Imagerie`
|
||||
- `Notes medicales`
|
||||
- `Synthese Urgences` avec lecture haut + bas
|
||||
6. Léa produit une synthese prudente Aiva-urgence.
|
||||
7. Léa demande ou consigner :
|
||||
- OnlyOffice tableur ;
|
||||
- Word/document ;
|
||||
- base de donnees ;
|
||||
- autre environnement.
|
||||
8. Dom choisit OnlyOffice.
|
||||
9. Léa genere et ouvre le `.xlsx`.
|
||||
10. Léa demande validation humaine finale avant toute conclusion metier.
|
||||
|
||||
## Challenges humains attendus
|
||||
|
||||
Dom peut volontairement challenger Léa sur ces points.
|
||||
|
||||
### Selection dossier
|
||||
|
||||
- "Traite seulement MOREL Catherine."
|
||||
- "Comment sais-tu que c'est le bon dossier ?"
|
||||
- "Ne cite pas tous les IPP, dis-moi seulement ce que tu vois globalement."
|
||||
|
||||
Attendu Léa :
|
||||
|
||||
- citer les preuves du bandeau ;
|
||||
- ne pas inventer les IPP secondaires ;
|
||||
- demander confirmation si divergence IPP/nom.
|
||||
|
||||
### Scroll et zones longues
|
||||
|
||||
- "Tu es sure d'avoir lu toute la synthese ?"
|
||||
- "Je t'ai montre comment scroller, refais-le proprement."
|
||||
- "Quels marqueurs prouvent que tu es en bas ?"
|
||||
|
||||
Attendu Léa :
|
||||
|
||||
- expliquer lecture haut + bas ;
|
||||
- verifier changement visuel ;
|
||||
- citer les marqueurs `CCMU`, `GEMSA`, `J12.1`, `Consultation externe` ;
|
||||
- s'arreter si un marqueur manque.
|
||||
|
||||
### Sortie bureautique
|
||||
|
||||
- "Mets-moi ca dans OnlyOffice."
|
||||
- "Je veux voir le fichier ouvert."
|
||||
- "Ne valide rien automatiquement."
|
||||
|
||||
Attendu Léa :
|
||||
|
||||
- generer un `.xlsx` lisible ;
|
||||
- ouvrir OnlyOffice ;
|
||||
- attendre validation humaine.
|
||||
|
||||
### Refus / correction humaine
|
||||
|
||||
- "Non, ce n'est pas ca."
|
||||
- "Reprends depuis l'onglet Notes."
|
||||
- "Tu n'as pas assez de preuves."
|
||||
|
||||
Attendu Léa :
|
||||
|
||||
- accepter la correction ;
|
||||
- relancer la lecture ciblee ;
|
||||
- ne pas argumenter contre l'humain ;
|
||||
- journaliser la correction comme apprentissage.
|
||||
|
||||
## Critères GO/NOGO
|
||||
|
||||
GO :
|
||||
|
||||
- bon dossier prouve par `25003284`, `MOREL`, `Catherine` ;
|
||||
- tableau de liste decrit sans enumeration fragile ;
|
||||
- 5 onglets tentes ;
|
||||
- `Synthese Urgences` validee par marqueurs bas ;
|
||||
- fichier OnlyOffice ouvert ;
|
||||
- validation finale demandee a Dom ;
|
||||
- aucune invention clinique ou administrative.
|
||||
|
||||
NOGO :
|
||||
|
||||
- mauvais dossier ;
|
||||
- Léa saute `Synthese Urgences` sans le dire ;
|
||||
- Léa considere un scroll reussi sans preuve de mouvement et de marqueurs ;
|
||||
- OCR vide exploite comme information ;
|
||||
- divergence IPP non signalee ;
|
||||
- conclusion automatique sans validation humaine.
|
||||
|
||||
## Discours produit a tenir
|
||||
|
||||
Phrase cle :
|
||||
|
||||
> Aiva-vision apprend l'interface comme un collaborateur. Quand Léa observe un humain scroller, elle apprend la zone, le geste et les preuves de completude. Au replay, elle ne se contente pas d'envoyer un scroll : elle verifie que l'ecran a bouge et que les donnees attendues sont relues. Si ce n'est pas le cas, elle s'arrete.
|
||||
|
||||
## Priorite technique avant repetition
|
||||
|
||||
1. Ajouter extraction Tesseract specialisee chiffres/IPP.
|
||||
2. Conserver EasyOCR pour texte continu.
|
||||
3. Garder `extract_text_scroll` comme contrat de lecture longue.
|
||||
4. Rejouer les 5 onglets sur les captures existantes puis sur l'interface.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,134 @@
|
||||
# Scénario interactif Léa v0 — lecture écran et report contrôlé
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 11:59 Europe/Paris
|
||||
- `Statut`: **base de travail active**
|
||||
- `Cible`: démo Easily 2026-06-01 + socle POC
|
||||
- `Références`:
|
||||
- `docs/coordination/active/2026-05-26_arbitrage-dom-demo-reelle-poc.md`
|
||||
- `docs/coordination/active/2026-05-26_arbitrage-dom-demo-interaction-lea.md`
|
||||
- `docs/coordination/active/2026-05-26_principe-dom-apprentissage-fail-safe.md`
|
||||
|
||||
## Objectif
|
||||
|
||||
Montrer Léa en interaction réelle, pas seulement un replay linéaire :
|
||||
|
||||
1. Léa lit une information affichée dans le DPI.
|
||||
2. Léa explique ce qu'elle a compris ou demande confirmation.
|
||||
3. Léa reporte l'information dans une autre interface de la maquette.
|
||||
4. Léa s'arrête si l'information ou la cible est ambiguë.
|
||||
|
||||
## Périmètre v0
|
||||
|
||||
Maquette :
|
||||
|
||||
- `http://127.0.0.1:8765/index.html` côté Linux ;
|
||||
- `http://192.168.1.40:8765/index.html` côté Windows/Léa.
|
||||
|
||||
Patient :
|
||||
|
||||
- `MOREL Catherine`
|
||||
- IPP `25003284`
|
||||
- données fictives de maquette.
|
||||
|
||||
Interface source :
|
||||
|
||||
- dossier patient ;
|
||||
- onglet `Synthèse Urgences`.
|
||||
|
||||
Interface cible :
|
||||
|
||||
- page `codage.html?id=25003284` ;
|
||||
- zone `#dpi-input` ;
|
||||
- zone `#aiva-justification`.
|
||||
|
||||
## Séquence courte proposée
|
||||
|
||||
1. **Interaction initiale**
|
||||
- Dom demande à Léa : "Aide-moi à coder le dossier MOREL, en mode étape par étape."
|
||||
- Léa doit annoncer qu'elle va ouvrir le dossier, lire la synthèse, puis demander confirmation avant report.
|
||||
|
||||
2. **Ouverture dossier**
|
||||
- Léa ouvre la liste patients.
|
||||
- Léa clique `25003284` / `MOREL Catherine`.
|
||||
|
||||
3. **Lecture écran**
|
||||
- Léa ouvre `Synthèse Urgences`.
|
||||
- Action serveur attendue : `extract_text` ou `extract_text_scroll` vers une variable type `dpi_synthese`.
|
||||
- Preuve attendue : log `extract_text -> variable`, texte non vide, screenshot associé.
|
||||
|
||||
4. **Compréhension / confirmation**
|
||||
- Action attendue : `t2a_decision` sur `{{dpi_synthese}}` ou analyse `/api/analyse` après report DPI.
|
||||
- Léa présente une synthèse courte :
|
||||
- patient / IPP ;
|
||||
- diagnostic ou éléments clés ;
|
||||
- proposition Forfait Urgences vs UHCD ;
|
||||
- incertitude éventuelle.
|
||||
- Action attendue : `pause_for_human` ou confirmation copilot.
|
||||
- Message attendu : "Je propose de reporter ces éléments. Confirmez-vous ?"
|
||||
|
||||
5. **Report contrôlé**
|
||||
- Léa clique `Coder >`.
|
||||
- Léa clique la zone `Coller ou saisir le dossier patient` (`#dpi-input`).
|
||||
- Léa reporte le texte lu ou un résumé contrôlé.
|
||||
- Le déclenchement `paste`/blur lance l'analyse réelle `/api/analyse`.
|
||||
|
||||
6. **Justification**
|
||||
- Léa clique `#aiva-justification`.
|
||||
- Léa saisit une justification courte, traçable, issue de ce qui a été lu.
|
||||
- Exemple de forme : "Synthèse lue sur le DPI : sortie rapide, décision Forfait Urgences à confirmer par l'humain."
|
||||
|
||||
7. **Validation humaine**
|
||||
- Léa s'arrête et demande vérification.
|
||||
- Dom confirme ou corrige.
|
||||
- Si ambiguïté : Léa demande "montrez-moi" au lieu de continuer.
|
||||
|
||||
## Comportements attendus
|
||||
|
||||
Succès produit :
|
||||
|
||||
- Léa lit une donnée affichée.
|
||||
- Léa ne l'invente pas.
|
||||
- Léa explique ce qu'elle va reporter.
|
||||
- Léa reporte dans la bonne zone.
|
||||
- Léa demande confirmation avant l'étape sensible.
|
||||
|
||||
Succès technique :
|
||||
|
||||
- `extract_text` non vide ;
|
||||
- clics dans la bonne fenêtre ;
|
||||
- `#dpi-input` et `#aiva-justification` correctement ciblés ;
|
||||
- `/api/analyse` appelé ou fallback local documenté ;
|
||||
- trace et screenshots exploitables.
|
||||
|
||||
Arrêt sûr acceptable :
|
||||
|
||||
- OCR vide ou ambigu ;
|
||||
- mauvais onglet ;
|
||||
- cible de saisie non trouvée ;
|
||||
- écran différent de celui attendu ;
|
||||
- résultat T2A incohérent ou absent.
|
||||
|
||||
NOGO :
|
||||
|
||||
- report dans le mauvais champ ;
|
||||
- action dans la mauvaise fenêtre ;
|
||||
- donnée inventée ;
|
||||
- clic malgré incertitude forte ;
|
||||
- absence de trace expliquant la lecture/report.
|
||||
|
||||
## Notes techniques
|
||||
|
||||
- La brique `extract_text` existe côté serveur et stocke une variable runtime depuis le dernier screenshot/heartbeat.
|
||||
- La brique `t2a_decision` existe et utilise `qwen2.5:7b` texte, pas `qwen2.5vl`.
|
||||
- Le mode copilot du chat permet une approbation étape par étape.
|
||||
- Le message "Je n'y arrive pas, montrez-moi comment faire" existe côté UI Léa pour les pauses supervisées.
|
||||
- La page `codage.html` supprime le bouton `Analyser` au runtime ; l'analyse se déclenche par `paste`, `blur` ou `Ctrl+Entrée`.
|
||||
|
||||
## À valider avant capture
|
||||
|
||||
- Choisir si le report porte sur le DPI complet lu, un extrait Synthèse Urgences, ou une justification courte.
|
||||
- Confirmer si on veut montrer le mode copilot dans le chat dès le lancement.
|
||||
- Confirmer la cible visuelle exacte côté Windows : `http://192.168.1.40:8765/index.html`.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,285 @@
|
||||
# Scénario opératoire démo Léa v1
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 15:43 Europe/Paris
|
||||
- `Statut`: **base opératoire v1**
|
||||
- `Produit`: Aiva-vision
|
||||
- `Agent`: Léa
|
||||
- `Plugin métier`: Aiva-urgence
|
||||
- `Cible démo`: 2026-06-01
|
||||
|
||||
## Intention
|
||||
|
||||
Montrer que Léa est le collaborateur numérique d'Aiva-vision :
|
||||
|
||||
- elle observe une interface métier existante ;
|
||||
- elle lit des données affichées ;
|
||||
- elle explique ce qu'elle comprend ;
|
||||
- elle demande confirmation avant une action sensible ;
|
||||
- elle reporte l'information dans une autre zone/interface ;
|
||||
- elle s'arrête proprement si elle ne sait pas.
|
||||
|
||||
Ce scénario est court, mais il doit rester réel et défendable pour les POC.
|
||||
|
||||
## Préconditions
|
||||
|
||||
- Maquette Easily active :
|
||||
- Linux : `http://127.0.0.1:8765/index.html`
|
||||
- Windows/Léa : `http://192.168.1.40:8765/index.html`
|
||||
- Services actifs :
|
||||
- `rpa-streaming.service`
|
||||
- `rpa-agent-chat.service`
|
||||
- `rpa-mockup-easily.service`
|
||||
- Profil démo actif :
|
||||
- `RPA_SKIP_INTENTION_ENRICHMENT=true`
|
||||
- `RPA_SKIP_BUILD_VISION=true`
|
||||
- `RPA_EASYOCR_GPU=0`
|
||||
- `AGENT_CHAT_ENABLE_OWL=0`
|
||||
- `AGENT_CHAT_ENABLE_UI_DETECTION=0`
|
||||
- Patient maquette :
|
||||
- `MOREL Catherine`
|
||||
- IPP `25003284`
|
||||
- données fictives.
|
||||
|
||||
## Phrase de lancement
|
||||
|
||||
Phrase Dom proposée dans le chat Léa :
|
||||
|
||||
> Léa, aide-moi à coder le dossier MOREL avec Aiva-urgence. Travaille en mode étape par étape : lis d'abord la synthèse affichée, explique-moi ce que tu as compris, demande confirmation, puis reporte les éléments dans l'interface de codage.
|
||||
|
||||
Variante plus courte :
|
||||
|
||||
> Léa, lance Aiva-urgence sur le dossier MOREL en mode supervisé.
|
||||
|
||||
## Séquence v1
|
||||
|
||||
### 1. Cadrage oral Léa
|
||||
|
||||
Comportement attendu :
|
||||
|
||||
- Léa annonce qu'elle va travailler avec le plugin Aiva-urgence.
|
||||
- Léa précise qu'elle demandera confirmation avant report.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- message visible dans le chat Léa ;
|
||||
- pas d'action automatique avant confirmation si l'intention est ambiguë.
|
||||
|
||||
### 2. Ouverture liste patients
|
||||
|
||||
Action :
|
||||
|
||||
- ouvrir ou vérifier la page liste patients.
|
||||
|
||||
Cible :
|
||||
|
||||
- `index.html`
|
||||
- ligne `MOREL Catherine` / IPP `25003284`.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- écran liste patients visible ;
|
||||
- trace `window_focus_change` ou heartbeat cohérent.
|
||||
|
||||
NOGO :
|
||||
|
||||
- mauvaise application au premier plan ;
|
||||
- page non chargée ;
|
||||
- patient absent.
|
||||
|
||||
### 3. Sélection du dossier
|
||||
|
||||
Action Léa :
|
||||
|
||||
- cliquer sur `25003284` ou la ligne `MOREL Catherine`.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- dossier patient ouvert ;
|
||||
- bandeau patient visible ;
|
||||
- URL ou titre contient `dossier.html?id=25003284`.
|
||||
|
||||
NOGO :
|
||||
|
||||
- mauvais patient ;
|
||||
- clic sur une autre ligne ;
|
||||
- changement de fenêtre imprévu.
|
||||
|
||||
### 4. Lecture de la synthèse
|
||||
|
||||
Action Léa :
|
||||
|
||||
- ouvrir l'onglet `Synthèse Urgences`.
|
||||
- lire le contenu affiché via action serveur `extract_text` ou `extract_text_scroll`.
|
||||
|
||||
Variable attendue :
|
||||
|
||||
- `t_synthese_urgences` ou équivalent.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- log serveur `extract_text -> variable ...` avec longueur non nulle ;
|
||||
- screenshot/heartbeat correspondant à l'onglet Synthèse ;
|
||||
- texte extrait contenant des éléments patient/décision/diagnostic.
|
||||
|
||||
NOGO :
|
||||
|
||||
- OCR vide ;
|
||||
- onglet incorrect ;
|
||||
- texte extrait incohérent avec l'écran ;
|
||||
- Léa invente une donnée non lue.
|
||||
|
||||
### 5. Restitution et confirmation
|
||||
|
||||
Action Léa :
|
||||
|
||||
- résumer en une phrase ce qu'elle a compris.
|
||||
- demander confirmation avant report.
|
||||
|
||||
Message attendu, forme acceptable :
|
||||
|
||||
> J'ai lu la synthèse du dossier MOREL. Je vois un passage court aux urgences avec une sortie, et je propose de reporter ces éléments dans Aiva-urgence pour analyse. Confirmez-vous ?
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- `pause_for_human`, confirmation copilot ou demande explicite visible ;
|
||||
- Dom peut répondre oui/non/corriger.
|
||||
|
||||
Succès produit :
|
||||
|
||||
- la pause est un comportement normal de sécurité.
|
||||
|
||||
NOGO :
|
||||
|
||||
- Léa continue sans confirmation ;
|
||||
- Léa affirme une décision métier non étayée ;
|
||||
- Léa masque une incertitude.
|
||||
|
||||
### 6. Passage à l'interface de codage
|
||||
|
||||
Action Léa :
|
||||
|
||||
- cliquer `Coder >`.
|
||||
|
||||
Cible :
|
||||
|
||||
- `codage.html?id=25003284`.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- page Aiva-urgence/aiva-vision visible ;
|
||||
- zone `Coller ou saisir le dossier patient` visible.
|
||||
|
||||
NOGO :
|
||||
|
||||
- page codage non ouverte ;
|
||||
- perte du contexte IPP ;
|
||||
- mauvaise fenêtre.
|
||||
|
||||
### 7. Report du contenu lu
|
||||
|
||||
Action Léa :
|
||||
|
||||
- cliquer dans `#dpi-input`.
|
||||
- coller/reporter le texte lu ou un extrait contrôlé validé par Dom.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- action `type_text` ou collage contrôlé ;
|
||||
- contenu visible dans la zone DPI ;
|
||||
- déclenchement réel de l'analyse par `paste`, `blur` ou `Ctrl+Entrée`.
|
||||
|
||||
NOGO :
|
||||
|
||||
- texte saisi dans le mauvais champ ;
|
||||
- donnée inventée ;
|
||||
- report partiel non assumé ;
|
||||
- analyse lancée avant confirmation si Dom ne l'a pas validée.
|
||||
|
||||
### 8. Justification contrôlée
|
||||
|
||||
Action Léa :
|
||||
|
||||
- cliquer dans `#aiva-justification`.
|
||||
- saisir une justification courte et traçable.
|
||||
|
||||
Texte de forme acceptable :
|
||||
|
||||
> Synthèse lue dans le DPI. Passage court avec sortie ; proposition Aiva-urgence à vérifier par l'humain avant validation.
|
||||
|
||||
Preuve attendue :
|
||||
|
||||
- justification visible ;
|
||||
- pas d'écrasement par le retour LLM si l'humain/Léa a déjà saisi.
|
||||
|
||||
NOGO :
|
||||
|
||||
- justification dans le mauvais champ ;
|
||||
- justification trop affirmative si l'analyse est incertaine ;
|
||||
- écrasement silencieux d'une saisie humaine.
|
||||
|
||||
### 9. Arrêt sûr final
|
||||
|
||||
Action Léa :
|
||||
|
||||
- s'arrêter et demander validation finale.
|
||||
|
||||
Message attendu :
|
||||
|
||||
> J'ai reporté les éléments dans Aiva-urgence. Pouvez-vous vérifier avant validation ?
|
||||
|
||||
Succès produit :
|
||||
|
||||
- Léa n'a pas besoin de finaliser seule ;
|
||||
- elle sait s'arrêter au bon moment.
|
||||
|
||||
## Critères GO
|
||||
|
||||
GO si :
|
||||
|
||||
- Léa ouvre le bon dossier patient ;
|
||||
- une lecture écran produit un texte exploitable ;
|
||||
- Léa restitue sans inventer ;
|
||||
- une confirmation humaine intervient avant report ;
|
||||
- le report arrive dans la bonne zone ;
|
||||
- la justification est visible et cohérente ;
|
||||
- les logs permettent de suivre lecture -> confirmation -> report.
|
||||
|
||||
## Critères NOGO
|
||||
|
||||
NOGO si :
|
||||
|
||||
- mauvaise fenêtre ou mauvais patient ;
|
||||
- saisie dans le mauvais champ ;
|
||||
- donnée inventée ou non affichée ;
|
||||
- action sensible sans confirmation ;
|
||||
- OCR vide mais Léa continue quand même ;
|
||||
- perte du contexte IPP ;
|
||||
- erreur non expliquée au client.
|
||||
|
||||
## Comportements acceptables en démo
|
||||
|
||||
Acceptable :
|
||||
|
||||
- Léa demande confirmation ;
|
||||
- Léa dit qu'elle ne sait pas ;
|
||||
- Léa demande "montrez-moi" ;
|
||||
- Léa s'arrête si l'écran ne correspond pas ;
|
||||
- Léa demande à Dom de reprendre la main.
|
||||
|
||||
Non acceptable :
|
||||
|
||||
- Léa agit malgré un doute ;
|
||||
- Léa simule une lecture ;
|
||||
- Léa hardcode une valeur ;
|
||||
- Léa masque une erreur.
|
||||
|
||||
## Notes d'exécution
|
||||
|
||||
- Ne pas rejouer l'ancien `Urgence_aiva_demo` tel quel.
|
||||
- Utiliser l'ancien workflow comme référence de briques uniquement.
|
||||
- Cible workflow propre : `wf_easily_interactif_lea_2026-06-01`.
|
||||
- Premier passage recommandé : capture ou exécution supervisée courte, pas smoke live long.
|
||||
- Live replay uniquement avec GO explicite Dom.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,309 @@
|
||||
# Scénario opératoire démo Léa v2 — collecte et transposition
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 16:22 Europe/Paris
|
||||
- `Statut`: **base opératoire v2**
|
||||
- `Remplace fonctionnellement`: `2026-05-26_scenario-operatoire-demo-lea-v1.md`
|
||||
- `Produit`: Aiva-vision
|
||||
- `Agent`: Léa
|
||||
- `Plugin métier`: Aiva-urgence
|
||||
- `Cible démo`: 2026-06-01
|
||||
|
||||
## Intention produit
|
||||
|
||||
Montrer Léa comme collaborateur numérique capable de :
|
||||
|
||||
1. lire précisément une interface métier existante ;
|
||||
2. comprendre la structure de l'écran ;
|
||||
3. naviguer dans un dossier multi-onglets ;
|
||||
4. collecter des informations complètes, y compris avec scroll/ascenseurs ;
|
||||
5. proposer un choix d'exploitation ;
|
||||
6. transposer les informations dans un autre outil ou environnement.
|
||||
|
||||
Le message produit : Aiva-vision apprend les interfaces ; Léa les parcourt et collecte ; Aiva-urgence apporte le raisonnement métier urgences.
|
||||
|
||||
## Ce que le client doit voir
|
||||
|
||||
Le client doit voir en vrai :
|
||||
|
||||
- Léa décrit le tableau des passages aux urgences.
|
||||
- Léa identifie qu'il y a plusieurs dossiers patients.
|
||||
- Léa propose : traiter tous les dossiers ou un dossier précis.
|
||||
- Léa ouvre un dossier.
|
||||
- Léa parcourt les onglets du dossier.
|
||||
- Léa lit/collecte les informations affichées.
|
||||
- Léa sait gérer les zones longues avec ascenseur.
|
||||
- Léa s'arrête et demande où consigner les informations.
|
||||
- Léa reporte vers une cible choisie : Excel, Word, base de données, ou autre plateforme/environnement.
|
||||
|
||||
## Démo courte recommandée
|
||||
|
||||
Pour rester solide en J-6, ne pas traiter tous les dossiers en live.
|
||||
|
||||
Démo recommandée :
|
||||
|
||||
1. Léa lit le tableau des dossiers.
|
||||
2. Léa propose "tous les dossiers" ou "un dossier".
|
||||
3. Dom choisit un dossier : `MOREL Catherine / 25003284`.
|
||||
4. Léa collecte les informations du dossier dans plusieurs onglets.
|
||||
5. Léa demande où les consigner.
|
||||
6. Dom choisit une sortie simple.
|
||||
7. Léa reporte les informations collectées dans cette sortie.
|
||||
|
||||
Le discours peut préciser que le traitement multi-dossiers est la même boucle répétée, mais que la démo live reste courte pour garder la supervision clinique.
|
||||
|
||||
## Phrase de lancement
|
||||
|
||||
Phrase Dom proposée :
|
||||
|
||||
> Léa, observe la liste des passages aux urgences avec Aiva-urgence. Décris-moi les dossiers disponibles, puis demande-moi si je veux tous les traiter ou en choisir un. Ensuite, collecte les informations du dossier choisi et propose-moi où les consigner.
|
||||
|
||||
Variante courte :
|
||||
|
||||
> Léa, avec Aiva-urgence, lis cette liste de dossiers et aide-moi à collecter puis reporter les informations du dossier MOREL.
|
||||
|
||||
## Séquence v2
|
||||
|
||||
### 1. Lecture de la liste des dossiers
|
||||
|
||||
Écran source :
|
||||
|
||||
- liste des passages aux urgences ;
|
||||
- tableau avec colonnes `IPP`, `Nom`, `Prénom`, `Né(e) le`, `Arrivée`, `Motif`, `Médecin`, `Statut`.
|
||||
|
||||
Action attendue :
|
||||
|
||||
- Léa lit la structure du tableau ;
|
||||
- Léa identifie les lignes disponibles ;
|
||||
- Léa restitue un résumé court.
|
||||
|
||||
Message attendu :
|
||||
|
||||
> Je vois une liste de passages aux urgences avec 11 dossiers. Chaque ligne contient l'IPP, le patient, le motif, le médecin et le statut. Voulez-vous que je traite tous les dossiers ou un dossier en particulier ?
|
||||
|
||||
Preuves attendues :
|
||||
|
||||
- action OCR/table ou extraction texte ;
|
||||
- trace indiquant la lecture de l'écran ;
|
||||
- mention correcte d'au moins 2-3 colonnes ;
|
||||
- proposition de choix à l'utilisateur.
|
||||
|
||||
NOGO :
|
||||
|
||||
- Léa invente un nombre de dossiers ;
|
||||
- Léa ne voit pas le tableau ;
|
||||
- Léa lance un traitement sans demander le périmètre.
|
||||
|
||||
### 2. Choix supervisé du périmètre
|
||||
|
||||
Action Dom :
|
||||
|
||||
- choisir un dossier pour la démo courte, par exemple `MOREL Catherine / 25003284`.
|
||||
|
||||
Action attendue Léa :
|
||||
|
||||
- confirmer le choix ;
|
||||
- annoncer qu'elle ouvre le dossier et collecte les onglets.
|
||||
|
||||
Message attendu :
|
||||
|
||||
> D'accord, je traite le dossier MOREL Catherine, IPP 25003284. Je vais parcourir les onglets et collecter les informations utiles.
|
||||
|
||||
### 3. Ouverture du dossier
|
||||
|
||||
Action Léa :
|
||||
|
||||
- cliquer sur `25003284` ou la ligne `MOREL Catherine`.
|
||||
|
||||
Preuves attendues :
|
||||
|
||||
- bandeau dossier visible ;
|
||||
- `IPP : 25003284`;
|
||||
- patient `MOREL Catherine`;
|
||||
- onglets visibles.
|
||||
|
||||
NOGO :
|
||||
|
||||
- mauvais patient ;
|
||||
- mauvais dossier ;
|
||||
- mauvaise fenêtre.
|
||||
|
||||
### 4. Collecte multi-onglets
|
||||
|
||||
Onglets à parcourir :
|
||||
|
||||
- `Motif d'admission`;
|
||||
- `Examens cliniques`;
|
||||
- `Imagerie`;
|
||||
- `Notes médicales`;
|
||||
- `Synthèse Urgences`.
|
||||
|
||||
Action attendue :
|
||||
|
||||
- Léa ouvre chaque onglet ;
|
||||
- Léa collecte le texte affiché ;
|
||||
- si l'onglet est long, Léa utilise scroll/extraction longue ;
|
||||
- Léa garde les informations structurées par onglet.
|
||||
|
||||
Variables cibles possibles :
|
||||
|
||||
- `t_motif_admission`;
|
||||
- `t_examen_clinique`;
|
||||
- `t_imagerie`;
|
||||
- `t_notes_medicales`;
|
||||
- `t_synthese_urgences`.
|
||||
|
||||
Preuves attendues :
|
||||
|
||||
- logs `extract_text` ou `extract_text_scroll`;
|
||||
- longueurs de texte non nulles ;
|
||||
- captures/heartbeats cohérents avec chaque onglet ;
|
||||
- aucune donnée inventée.
|
||||
|
||||
NOGO :
|
||||
|
||||
- OCR vide mais continuation silencieuse ;
|
||||
- onglet sauté sans le dire ;
|
||||
- scroll non fait alors que le contenu est manifestement long ;
|
||||
- données d'un onglet rangées sous le mauvais libellé.
|
||||
|
||||
### 5. Synthèse métier Aiva-urgence
|
||||
|
||||
Action attendue :
|
||||
|
||||
- Aiva-urgence analyse les informations collectées ;
|
||||
- Léa restitue une synthèse métier courte ;
|
||||
- Léa ne présente pas une décision comme définitive sans confirmation humaine.
|
||||
|
||||
Message attendu :
|
||||
|
||||
> J'ai collecté les informations du dossier. Je peux maintenant les consigner dans un document, un tableur ou une base, puis lancer l'aide Aiva-urgence pour qualifier le passage. Où voulez-vous que je reporte ces informations ?
|
||||
|
||||
### 6. Choix de sortie
|
||||
|
||||
Sorties possibles à démontrer :
|
||||
|
||||
- Excel / tableur ;
|
||||
- Word / document ;
|
||||
- base de données ;
|
||||
- autre environnement ou plateforme, par exemple Linux via NoMachine ;
|
||||
- Citrix/VM dans les POC ultérieurs.
|
||||
|
||||
Pour la démo courte, choisir une sortie unique et fiable.
|
||||
|
||||
Options recommandées J-6 :
|
||||
|
||||
1. **Excel/tableur** : visible, compréhensible client, bon pour montrer transposition structurée.
|
||||
2. **Word/document** : bon pour montrer synthèse narrative.
|
||||
3. **Base locale** : solide techniquement mais moins visible client.
|
||||
|
||||
Recommandation Codex :
|
||||
|
||||
- démo live : Excel ou document visible ;
|
||||
- preuve POC : log/DB local en complément.
|
||||
|
||||
### 7. Report contrôlé
|
||||
|
||||
Action Léa :
|
||||
|
||||
- ouvrir ou cibler la sortie choisie ;
|
||||
- reporter les champs collectés ;
|
||||
- demander confirmation avant validation finale.
|
||||
|
||||
Exemple Excel/tableur :
|
||||
|
||||
- IPP ;
|
||||
- Nom/prénom ;
|
||||
- Motif ;
|
||||
- Statut ;
|
||||
- éléments médicaux clés ;
|
||||
- proposition Aiva-urgence ;
|
||||
- commentaire humain.
|
||||
|
||||
Preuves attendues :
|
||||
|
||||
- les valeurs reportées correspondent au dossier lu ;
|
||||
- report dans les bons champs/cellules ;
|
||||
- action traçable ;
|
||||
- arrêt final pour validation humaine.
|
||||
|
||||
NOGO :
|
||||
|
||||
- report dans mauvais outil ;
|
||||
- champ décalé ;
|
||||
- mélange entre deux patients ;
|
||||
- données inventées ;
|
||||
- validation finale automatique sans accord.
|
||||
|
||||
## Ce qui est acceptable en démo
|
||||
|
||||
Acceptable :
|
||||
|
||||
- Léa demande "tous les dossiers ou un en particulier ?";
|
||||
- Léa demande où consigner les données ;
|
||||
- Léa demande de montrer un champ inconnu ;
|
||||
- Léa s'arrête si un onglet ou un bouton téléchargement est ambigu ;
|
||||
- Léa dit que l'apprentissage sera nécessaire pour automatiser toute une série.
|
||||
|
||||
Non acceptable :
|
||||
|
||||
- Léa fait semblant d'avoir lu ;
|
||||
- Léa hardcode `MOREL Catherine` sans lecture ;
|
||||
- Léa saute les onglets longs ;
|
||||
- Léa mélange collecte et analyse sans traçabilité ;
|
||||
- Léa reporte sans confirmation.
|
||||
|
||||
## Boutons téléchargements / pièces jointes
|
||||
|
||||
Si un onglet contient un bouton de téléchargement ou une pièce jointe :
|
||||
|
||||
- Léa doit signaler l'existence du bouton ;
|
||||
- ne pas télécharger sans confirmation ;
|
||||
- demander si le document doit être ouvert, lu ou attaché au dossier de sortie.
|
||||
|
||||
Message attendu :
|
||||
|
||||
> Je vois un bouton de téléchargement. Voulez-vous que je l'ouvre pour collecter son contenu, ou je le note simplement comme pièce disponible ?
|
||||
|
||||
## Critères GO
|
||||
|
||||
GO si :
|
||||
|
||||
- Léa décrit correctement le tableau initial ;
|
||||
- Léa propose le choix tous/un dossier ;
|
||||
- Léa ouvre le bon dossier ;
|
||||
- Léa collecte au moins 2 onglets en live, idéalement 3 à 5 selon stabilité ;
|
||||
- Léa demande où reporter ;
|
||||
- Léa reporte correctement dans une sortie visible ;
|
||||
- Léa s'arrête pour validation.
|
||||
|
||||
## Critères NOGO
|
||||
|
||||
NOGO si :
|
||||
|
||||
- mauvais patient ;
|
||||
- mauvaise fenêtre ;
|
||||
- valeurs inventées ;
|
||||
- onglets longs ignorés sans avertissement ;
|
||||
- report dans mauvais champ ;
|
||||
- aucune trace de lecture écran ;
|
||||
- Léa continue malgré incertitude forte.
|
||||
|
||||
## Positionnement face à l'ancienne démo VWB
|
||||
|
||||
Ancienne démo VWB :
|
||||
|
||||
- collecte assurée par module OCR ;
|
||||
- analyse par module d'analyse ;
|
||||
- report dans une cible.
|
||||
|
||||
Nouvelle démo Aiva-vision/Léa :
|
||||
|
||||
- même principe fonctionnel ;
|
||||
- mais centré sur Léa comme agent interactif ;
|
||||
- plus supervisable ;
|
||||
- plus fail-safe ;
|
||||
- plus proche d'un collaborateur entrant dans l'entreprise ;
|
||||
- extensible à d'autres plugins métier.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,122 @@
|
||||
# Synthese retours Claude/Qwen — demo v2 OCR
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-05-26 21:40 Europe/Paris
|
||||
- `Statut`: arbitrage actif
|
||||
|
||||
## Messages lus
|
||||
|
||||
- `docs/coordination/inbox_codex/2026-05-26_2101_qwen-to-codex_AUDIT-technique-dryrun-onlyoffice.md`
|
||||
- `docs/coordination/inbox_codex/2026-05-26_2113_qwen-to-codex_SEUILS-fallbacks-apres-dryrun.md`
|
||||
- `docs/coordination/inbox_codex/2026-05-26_2117_qwen-to-codex_RAPPORT-P0-ocr-ecran.md`
|
||||
- `docs/coordination/inbox_codex/2026-05-26_2130_claude-to-codex_DEMO-v2-script-failsafe-onlyoffice.md`
|
||||
- `docs/coordination/inbox_codex/2026-05-26_2145_claude-to-codex_ADDENDUM-demo-v2-dryrun-integration.md`
|
||||
|
||||
## Convergence
|
||||
|
||||
Claude et Qwen convergent sur :
|
||||
|
||||
- demo courte sur `MOREL Catherine / IPP 25003284` ;
|
||||
- pas d'enumeration exacte des IPP secondaires, car OCR insuffisant sur certains chiffres ;
|
||||
- sortie visible OnlyOffice en `.xlsx` ;
|
||||
- arrets humains assumés comme comportement produit ;
|
||||
- fail-safe si OCR vide, mauvais dossier, scroll incomplet ou transposition non ouverte.
|
||||
|
||||
## Arbitrages Codex
|
||||
|
||||
### 1. Tableau liste
|
||||
|
||||
Léa doit dire :
|
||||
|
||||
> Je vois 11 dossiers avec les colonnes IPP, patient, motif, medecin et statut. Voulez-vous que je traite tous les dossiers ou un dossier en particulier ?
|
||||
|
||||
Elle ne doit pas enumerer tous les IPP secondaires en live.
|
||||
|
||||
### 2. Perimetre onglets
|
||||
|
||||
Claude recommande 3 onglets pour prudence. Le dry-run Codex + seuils Qwen montrent que les 5 onglets sont exploitables si `Synthese Urgences` a un scroll bas obligatoire.
|
||||
|
||||
Addendum Claude 21:45 : recommandation ajustee a **4 onglets** pour la demo live (`Motif`, `Examens`, `Imagerie`, `Notes medicales`) afin de montrer une collecte clinique plus riche sans dependre du scroll. Claude reserve `Synthese Urgences` au discours POC sauf si Dom veut valoriser CIM-10/CCMU/GEMSA.
|
||||
|
||||
Correction Dom/Codex apres rappel VWB : sur la demo precedente, le scroll n'etait pas un point faible. Le contrat VWB `extract_text_scroll` lisait haut + bas (`ctrl+end`, OCR bas, concat, retour haut). Donc on ne retire plus `Synthese Urgences` par prudence abstraite sur le scroll.
|
||||
|
||||
Arbitrage Codex maintenu : **preparer le workflow 5 onglets**, avec degrade possible :
|
||||
|
||||
1. `Motif d'admission`
|
||||
2. `Examens cliniques`
|
||||
3. `Imagerie`
|
||||
4. `Notes medicales`
|
||||
5. `Synthese Urgences` top + bottom
|
||||
|
||||
Si repetition generale instable, on bascule en mode court, mais le scenario produit cible reste 5 onglets car le client veut voir la capacite a collecter largement, y compris une zone longue avec scroll.
|
||||
|
||||
Plan de conduite :
|
||||
|
||||
- repetition technique : tester 5 onglets ;
|
||||
- si `Synthese Urgences` top+bottom est stable, live 5 onglets ;
|
||||
- si `extract_text_scroll` est appele mais que les marqueurs bas restent absents apres retry, live 4 onglets et discours explicite sur l'arret fail-safe ;
|
||||
- 3 onglets reste le mode secours minimal.
|
||||
|
||||
### 3. OCR J-6
|
||||
|
||||
Mise a jour Qwen 21:32 : la recommandation P0 evolue vers une approche hybride par type de zone.
|
||||
|
||||
Actions P0 recommandees par Qwen :
|
||||
|
||||
- benchmark EasyOCR actuel vs Tesseract/docTR/PaddleOCR sur captures existantes ;
|
||||
- utiliser **docTR CPU** comme moteur de zonage principal pour les zones critiques structurees :
|
||||
- bandeau patient ;
|
||||
- zone IPP du tableau ;
|
||||
- champs `CCMU`, `GEMSA`, orientation/decision ;
|
||||
- conserver **EasyOCR** pour le texte continu :
|
||||
- notes medicales ;
|
||||
- observations ;
|
||||
- OCR large cold start ;
|
||||
- ajouter preprocessing OpenCV optionnel dans `core/llm/ocr_extractor.py` si le benchmark prouve un gain ;
|
||||
- ajouter validation post-OCR par chaines obligatoires, au minimum log-only/fail-safe ;
|
||||
- garder **Tesseract** comme fallback conditionnel sur les chiffres/IPP douteux ;
|
||||
- reserver **PaddleOCR** pour post-demo ou cas difficiles ;
|
||||
- ne pas utiliser VLM comme OCR texte pur en demo.
|
||||
|
||||
### 4. Interface apprise
|
||||
|
||||
Le rapport Qwen integre le principe Dom :
|
||||
|
||||
- cold start : lecture large + confirmation ;
|
||||
- interface apprise : ROI/ancres/champs critiques ;
|
||||
- drift : retour prudent + demande humaine.
|
||||
|
||||
Decision : on n'implemente pas toute la carte d'interface avant le 2026-06-01, mais le discours produit doit la nommer clairement comme mecanisme de POC/apprentissage.
|
||||
|
||||
## GO/NOGO demo consolide
|
||||
|
||||
GO si :
|
||||
|
||||
- `25003284`, `MOREL`, `Catherine` lus dans le bandeau ;
|
||||
- 5 onglets captures, ou degrade explicite si un onglet non critique echoue ;
|
||||
- `Notes medicales` contient `VRS` ou `augmentin` ;
|
||||
- `Synthese Urgences` bottom contient `CCMU`, `GEMSA`, `J12.1`, `Consultation externe` ;
|
||||
- `.xlsx` genere et ouvert visiblement dans OnlyOffice.
|
||||
|
||||
NOGO si :
|
||||
|
||||
- mauvais patient ;
|
||||
- OCR vide sans arret humain ;
|
||||
- synthese basse non tentee ;
|
||||
- tableur non ouvert visiblement ;
|
||||
- Léa invente ou annonce comme certains des IPP secondaires mal lus ;
|
||||
- validation finale automatique sans humain.
|
||||
|
||||
## Prochaine action Codex
|
||||
|
||||
Faire un benchmark OCR local sur les captures dry-run avec :
|
||||
|
||||
- EasyOCR brut ;
|
||||
- EasyOCR avec preprocessing OpenCV ;
|
||||
- docTR CPU sur crops critiques ;
|
||||
- Tesseract ;
|
||||
- PaddleOCR uniquement si temps et latence acceptables.
|
||||
|
||||
Puis arbitrer le patch minimal J-6.
|
||||
|
||||
Auteur : Codex
|
||||
@@ -0,0 +1,26 @@
|
||||
# NOTE Codex — defauts replay demo: actions longues et message cible
|
||||
|
||||
Date: 2026-05-27 10:09
|
||||
|
||||
Contexte live:
|
||||
- Replay `replay_free_c8815c3c`.
|
||||
- Apres validation de Dom, progression jusqu'a `29/72`.
|
||||
- Pause affichee dans Lea: `Je ne vois pas 'un élément' à l'écran`.
|
||||
|
||||
Constats:
|
||||
- Action longue observee avant la pause: `step_9f51bb3608f5_1779110608042`, type `wait`, duree `30000ms`.
|
||||
- La pause ne dit pas ce que Lea cherche parce que le `target_spec` de l'action en echec ne contient que `anchor_image_base64`, `anchor_id`, `anchor_bbox`, `original_size`.
|
||||
- L'ancre `anchor_a518f6d5e727_1778849657` existe pourtant en base VWB avec:
|
||||
- `description`: `Word document icon with text.`
|
||||
- `target_text`: `- W - ICE rapport urgenc.`
|
||||
- cible reelle: document Word `rapport_urgence.docx`.
|
||||
|
||||
Defauts produit a corriger:
|
||||
1. Performance / UX: auditer les `wait` fixes longs (`30000ms`) et remplacer quand possible par attente conditionnelle visuelle ou evenementielle.
|
||||
2. Message pause: enrichir `pause_message` quand `target_description` vaut `un élément`, en recuperant au minimum `anchor_id`, `description`, `target_text`, bbox et type d'action.
|
||||
3. Build replay: propager `visual_anchors.description`, `target_text` et/ou `ocr_description` dans `target_spec` pour que l'agent et le serveur n'aient pas seulement une image d'ancre.
|
||||
4. Reprise supervisee: ajouter une option explicite `resume(skip_failed_action=true)` ou equivalente. Aujourd'hui `/resume` reinjecte toujours l'action echouee, ce qui complique les corrections manuelles quand l'humain a deja remis l'ecran dans le bon etat.
|
||||
|
||||
Point live:
|
||||
- Ne pas cliquer aveuglement sur `Continuer`.
|
||||
- Correction probable: ouvrir `C:\Users\dom\Desktop\rapport_urgence.docx` pendant le mode apprentissage puis signaler `Ctrl+Shift+L`, pour que la correction soit capturee.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Incident — reprise brute hors cibles replay Léa
|
||||
|
||||
Date : 2026-05-27 10:42 CEST
|
||||
|
||||
## Résumé
|
||||
|
||||
Pendant la répétition live, une reprise courte a été lancée via `/replay/raw` (`replay_free_2cc9e73e`) pour continuer la partie Linux après ouverture correcte de la VM NoMachine. Cette reprise ne respectait pas le chemin normal du replay Léa : les clics reposaient sur des bboxes historiques et non sur un état visuel certifié.
|
||||
|
||||
Dom a signalé à juste titre que la souris n'a pas cliqué dans les bonnes cibles et que, pour la démo Léa, nous étions hors trajectoire.
|
||||
|
||||
## État sécurisé
|
||||
|
||||
- `replay_free_c8815c3c` : annulé.
|
||||
- `replay_free_2cc9e73e` : annulé.
|
||||
- Gardien clipboard VM : arrêté.
|
||||
- NoMachine Windows affiche bien la VM Ubuntu via `192.168.1.40:4001`.
|
||||
- Aucun autre clic automatique ne doit être lancé avant décision Dom.
|
||||
|
||||
## Défauts produit exposés
|
||||
|
||||
1. Des clics avec `validator_v2.failure_category="no_visual_change"` ont été reportés `success=true`.
|
||||
2. Les retries ont fait monter `completed_actions` au-dessus de `total_actions`.
|
||||
3. Le replay a pu rester `running` malgré un état de queue incohérent.
|
||||
4. Le message Léa/UI ne distingue pas assez nettement une fin annulée d'une fin fonctionnelle.
|
||||
|
||||
## Délégations ouvertes
|
||||
|
||||
- Claude : `docs/coordination/inbox_claude/2026-05-27_1040_codex-to-claude_MISSION-P0-replay-visual-guard-false-success.md`
|
||||
- Qwen : `docs/coordination/inbox_qwen/2026-05-27_1041_codex-to-qwen_MISSION-P0-runbook-reprise-vwb-nomachine.md`
|
||||
|
||||
## Règle immédiate
|
||||
|
||||
Ne plus utiliser de reprise brute par bboxes historiques en contexte démo Léa. Repartir uniquement d'un état initial contrôlé ou d'un sous-workflow dont l'écran de départ est validé visuellement.
|
||||
@@ -0,0 +1,34 @@
|
||||
# Suivi actif - Reuse coeur Lea micro-apprentissage
|
||||
|
||||
Date: 2026-05-27 19:33
|
||||
Pilote: Codex
|
||||
Participants: Qwen, Claude
|
||||
|
||||
## Objectif
|
||||
|
||||
Construire la prochaine etape du coeur Lea sans reinventer les briques existantes:
|
||||
|
||||
- apprentissage de gestes simples,
|
||||
- nettoyage des sessions,
|
||||
- validation humaine,
|
||||
- generalisation,
|
||||
- replay verifie,
|
||||
- memoire durable,
|
||||
- communication humaine claire.
|
||||
|
||||
## Missions envoyees
|
||||
|
||||
- Qwen: `docs/coordination/inbox_qwen/2026-05-27_1933_codex-to-qwen_AVIS-inventaire-reuse-lea-core.md`
|
||||
- Claude: `docs/coordination/inbox_claude/2026-05-27_1933_codex-to-claude_AVIS-vision-strategie-reuse-lea-core.md`
|
||||
|
||||
## Reponses attendues
|
||||
|
||||
- `docs/coordination/inbox_codex/2026-05-27_HHMM_qwen-to-codex_AVIS-reuse-lea-core.md`
|
||||
- `docs/coordination/inbox_codex/2026-05-27_HHMM_claude-to-codex_VISION-strategie-reuse-lea-core.md`
|
||||
|
||||
## Contraintes
|
||||
|
||||
- Reutiliser les outils existants avant de coder.
|
||||
- Ne pas transformer Lea en boite a clic.
|
||||
- Les actions doivent etre verifiees par changement d'etat pertinent, pas seulement par execution.
|
||||
- Si l'ecran ne permet pas l'action attendue, Lea doit expliquer ce qu'elle cherche en termes humains.
|
||||
@@ -0,0 +1,54 @@
|
||||
# Plan actif - 2026-05-28 matin - Micro-apprentissage Lea P0
|
||||
|
||||
Date de preparation: 2026-05-27 21:35
|
||||
Objectif: produire une premiere competence courte verifiee exploitable.
|
||||
|
||||
## Cible
|
||||
|
||||
Competence P0:
|
||||
|
||||
`open_windows_search` / `ouvrir_recherche_windows`
|
||||
|
||||
Source:
|
||||
|
||||
- `data/training/live_sessions/streaming_sessions/sess_20260527T185155_98ad9a.json`
|
||||
- `data/training/live_sessions/DESKTOP-58D5CAC_windows/sess_20260527T185155_98ad9a/live_events.jsonl`
|
||||
|
||||
## Livrables attendus demain
|
||||
|
||||
1. Segment propre P0 documente.
|
||||
2. `data/competences/observed/open_windows_search.yaml`.
|
||||
3. Validateur leger de schema competence.
|
||||
4. Warning `message_contract.py` branche sur au moins un chemin de pause.
|
||||
5. Tests verts sur le perimetre modifie.
|
||||
6. Decision Dom: replay supervise ou non.
|
||||
|
||||
## Ordre d'execution
|
||||
|
||||
1. Lire handoff:
|
||||
- `docs/handoffs/2026-05-27_handoff_codex_micro_apprentissage_lea_p0_reprise_2026-05-28.md`
|
||||
2. Inspecter session P0:
|
||||
- verifier indices evenements,
|
||||
- isoler `key_combo ["win", "s"]`,
|
||||
- trouver postcondition `Rechercher/SearchHost.exe`,
|
||||
- reperer parasites apres succes.
|
||||
3. Ecrire YAML observe/candidate.
|
||||
4. Ajouter validateur.
|
||||
5. Brancher warning message.
|
||||
6. Tester.
|
||||
7. Ne lancer aucun replay live sans GO Dom.
|
||||
|
||||
## Decisions ouvertes
|
||||
|
||||
- YAML initial en `observed` ou `candidate` ?
|
||||
- Validateur strict maison ou JSON schema/Pydantic ?
|
||||
- Premier site runtime pour warning: `_coerce_pause_message` ou `_pause_action_message` ?
|
||||
- Rejoue supervise demain matin ou seulement verification offline ?
|
||||
|
||||
## Non-objectifs
|
||||
|
||||
- Pas de VWB.
|
||||
- Pas de nouvelle chaine Graph/FAISS.
|
||||
- Pas de stabilisation AUTO.
|
||||
- Pas de recapture Win+S.
|
||||
- Pas de refactor large `api_stream.py`.
|
||||
@@ -0,0 +1,62 @@
|
||||
# Strategie nettoyage worktree - 2026-06-01
|
||||
|
||||
Statut : strategie de reprise, pas encore executee.
|
||||
|
||||
## Objectif
|
||||
|
||||
Remettre le worktree au propre sans perdre de travail, sans embarquer d'artefacts parasites, et sans casser le POC.
|
||||
|
||||
## Etat initial
|
||||
|
||||
- Repo : `/home/dom/ai/rpa_vision_v3`
|
||||
- Branche : `backup/post-demo-2026-05-19`
|
||||
- `git status --porcelain=v1 | wc -l` : 781 entrees
|
||||
- Worktree contient des changements Dom, Codex, Claude, Qwen, docs, tests, artefacts locaux et fichiers generes.
|
||||
|
||||
## Regles de securite
|
||||
|
||||
- Interdit : `git reset --hard`
|
||||
- Interdit : `git clean -fd`
|
||||
- Interdit : `git checkout -- <path>` sans accord explicite
|
||||
- Interdit : commit global `git add .`
|
||||
- Interdit : suppression de fichiers non identifies
|
||||
- Interdit : toucher au `.docx` DSI modifie par Dom
|
||||
|
||||
## Roles
|
||||
|
||||
- Qwen : audit lecture seule + classification + plan de commits/exclusions.
|
||||
- Claude : plan d'execution chirurgical, puis execution seulement apres GO.
|
||||
- Codex : validation finale, tests, staging/commit si Dom donne GO.
|
||||
- Dom : arbitrage uniquement sur fichiers douteux ou risques produit.
|
||||
|
||||
## Classification cible
|
||||
|
||||
1. Code P0 revocation/security
|
||||
2. Code P1 persist
|
||||
3. Code P1 shadow / agent-chat / bouton Windows
|
||||
4. Code P1 semantique
|
||||
5. Code R6 worker queue
|
||||
6. Tests associes
|
||||
7. Docs POC/handoffs/coordination utiles
|
||||
8. Artefacts locaux/generes a ignorer
|
||||
9. Binaires/DB a exclure sauf justification
|
||||
10. Fichiers utilisateur a ne pas toucher
|
||||
|
||||
## Sequence de nettoyage
|
||||
|
||||
1. Audit lecture seule.
|
||||
2. Classement par lots.
|
||||
3. Validation du plan par Qwen/Codex.
|
||||
4. Tests minimum du lot.
|
||||
5. Staging explicite par fichiers, jamais global.
|
||||
6. Commit logique.
|
||||
7. Recontrole `git status`.
|
||||
8. Lot suivant.
|
||||
|
||||
## Definition of done
|
||||
|
||||
- Aucun fichier utile perdu.
|
||||
- Aucun artefact local inutile committe.
|
||||
- Commits petits et reversibles.
|
||||
- Tests cibles passes ou limites documentees.
|
||||
- Worktree final compréhensible : soit propre, soit avec une liste courte de restes justifies.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Cadrage produit - socle multi-vertical
|
||||
|
||||
**Date** : 2026-06-02
|
||||
**Statut** : decision Dom, applicable aux agents et aux prochains lots.
|
||||
|
||||
## Decision
|
||||
|
||||
Les premiers POC visent le milieu de la sante, mais la sante est une **verticale metier**, pas l'identite du produit.
|
||||
|
||||
Le socle RPA Vision / Lea doit rester multi-vertical. Les prochains POC/MVP peuvent viser notamment :
|
||||
|
||||
- aeronautique ;
|
||||
- administration publique ;
|
||||
- mairie ;
|
||||
- conseil regional ;
|
||||
- autres metiers a processus bureautiques et applicatifs complexes.
|
||||
|
||||
## Implications
|
||||
|
||||
- Le code coeur ne doit pas hardcoder un vocabulaire sante quand une formulation neutre suffit.
|
||||
- Les contraintes sante/HDS/DPI/patient restent valables dans les docs et configs du POC sante, mais ne doivent pas contaminer les modules generiques.
|
||||
- Les noms de variables, defaults, messages UI et docs transverses doivent privilegier une terminologie neutre : utilisateur, poste, dossier, application, session, trace technique, competence.
|
||||
- Les verticales metier doivent etre portees par des profils/configurations/adapters, pas par des forks du coeur produit.
|
||||
- Les docs DSI Wallerstein et DGX clinique restent specifiques au POC sante actuel.
|
||||
|
||||
## Regle pour les agents
|
||||
|
||||
Quand un choix est ambigu :
|
||||
|
||||
- garder le socle generique ;
|
||||
- isoler la verticale dans une couche de configuration ou de documentation POC ;
|
||||
- signaler tout hardcode metier non necessaire.
|
||||
Reference in New Issue
Block a user