rpa_vision_v3/docs/handoffs/2026-05-17_handoff_session_nomachine.md

Handoff session 2026-05-17 — instabilité NoMachine + état général démo J-4

Auteur : Claude (session 09:30 → ~11:00 CEST) Suite de : 2026-05-16_handoff_ydotool_clipboard.md (handoff hier soir) Objectif : démo vidéo "demo 95" Paris jeudi 21 mai 2026 (J-4)

---

1. Diagnostic principal du jour : NoMachine freeze côté Windows

Symptôme : Léa déplace la souris (mouse_move OK, visible côté VM via NoMachine viewer) mais les clics ne s'enregistrent pas dans la VM. Le serveur signale vlm_and_template_all_failed au step suivant car l'état visuel attendu (launcher GNOME ouvert, DBeaver visible, etc.) n'est jamais atteint.

Cause root identifiée par Dom : NoMachine viewer Windows freeze progressivement. Au démarrage frais ça marche, après quelques minutes les inputs synthétiques (mouse click, keystrokes) sont mangés silencieusement. Pattern intermittent.

Mitigation immédiate démo :

• Redémarrer NoMachine côté Windows avant chaque take
• Garder NoMachine en plein écran (la fenêtre ne doit pas déborder de l'écran, sinon le grounding Léa crop sur une zone hors-écran et tout casse — vu rect aberrant (2553, 46) 1705×977 dans les logs)

Investigation post-démo nécessaire :

• Version NoMachine actuelle : 9.5.7. Vérifier si update fixe le freeze
• Logs NoMachine côté Windows (mémoire, codec, déconnexions)
• Tester alternatives : RDP natif Windows, TigerVNC, Sunshine/Moonlight

---

2. Bug secondaire : RPA_VLM_MODEL=gemma4:e4b dans le code Léa

Localisation : C:\rpa_vision\agent_v1\core\executor.py lignes ~1569, 1700, 2248 :

_vlm_model_popup = os.environ.get("RPA_VLM_MODEL", "gemma4:e4b")

Le tag gemma4:e4b n'existe pas dans Ollama → [POPUP-VLM] HTTP 404 à chaque appel popup → la cascade de récupération en cas de visual_resolve fail est cassée → Léa demande directement l'aide humaine au lieu de tenter le fallback popup-detect.

Fix simple : exporter RPA_VLM_MODEL=qwen2.5vl:7b (ou autre modèle existant) dans l'env Windows de Léa, OU patcher le code Léa pour avoir un default valide.

---

3. État infra (en fin de session)

Côté Linux hôte

• Serveur rpa-streaming : restart à 10:48:58 (PID 319324) après reset state interne (workflow paused_need_help bloquant)
• VLM model configuré : qwen2.5vl:7b (via .env.local → override sur vlm_config.py)
• Note : qwen2.5vl runtime Ollama = 13 GB → débordement CPU à 100%. Pour linux_db simple, le VLM Ollama n'est appelé qu'en fallback (~1.6s avec réponse vide), pas critique. Le grounding principal est InfiGUI-G1-3B Transformers (3.9 GB VRAM, permanent depuis 7 jours).

Côté VM Ubuntu 26.04 (192.168.122.132)

• /home/dom/demo_95 : SQLite, table renommée requalifications_t2a → requalification_urgence ✓
• État table : 3 rows propres (DURAND, MARTIN, PETIT), AUTOINCREMENT à 3 → prochain INSERT = id 4
• ydotoold : daemon actif depuis hier (socket /tmp/.ydotool_socket perm 0666)
• Gardien clipboard prepare_clipboard_linuxdb.sh : potentiellement à relancer après reboot VM
• xhost +local: : perdu au reboot, à refaire

Côté Windows (Léa)

• Léa redémarrée plusieurs fois aujourd'hui (10:00, 10:32)
• Léa peut crasher silencieusement (déjà constaté ce matin). Risque pour la démo : prévoir un quick-restart Léa pré-démo et surveiller pendant le take.

---

4. Avancées concrètes vs hier

Élément	Hier (handoff 2026-05-16)	Aujourd'hui
Table demo_95	requalifications_t2a	requalification_urgence (renommée)
Payload INSERT	INSERT INTO requalifications_t2a ...	INSERT INTO requalification_urgence ...
Step 8 workflow linux_db	paste_and_execute server-side	identique ✓
Step 8 workflow Demo_urgence_3_db (ord 40)	INSERT INTO requalifications_t2a	INSERT INTO requalification_urgence (mis à jour)
Scripts shell	paste_and_execute_linuxdb.sh avec bugs (verif stricte +1 byte, sudo TTY required)	fixés : tolérance ±1 byte newline, skip sudo si daemon présent
Server-side action paste_and_execute	intégrée en code (replay_engine + api_stream)	intégrée + testée avec succès hier

---

5. Backups du jour (workflows.db)

workflows.db.backup_2026-05-17_093654_avant_rename_table       (avant ALTER TABLE)
workflows.db.backup_2026-05-17_102048_avant_rerecord_linuxdb   (jamais utilisé — le re-record n'a pas été fait)

---

6. Suite de session après reboots serveur + Windows

Routine de redémarrage à respecter

1. Linux hôte : systemctl --user start rpa-streaming (vérif journalctl --user-unit=rpa-streaming -f pour VLM model log)
2. VM Ubuntu :
   • Si reboot VM : sudo ydotoold --socket-path=/tmp/.ydotool_socket --socket-perm=0666 & (depuis terminal NoMachine, pas SSH)
   • Si reboot VM : xhost +local: (depuis terminal NoMachine, pas SSH)
   • Si reboot VM : ~/ai/rpa_vision_v3/scripts/prepare_clipboard_linuxdb.sh (relance gardien clipboard)
3. Windows : Léa démarre via raccourci ou C:\rpa_vision\.venv\Scripts\pythonw.exe run_agent_v1.py
4. NoMachine Windows : ouvrir connexion vers VM, mettre en plein écran, NE PAS bouger pendant les replays

Vérification avant démo

• DBeaver doit être déjà ouvert dans la VM avec la base demo_95 connectée et la console SQL prête (la conn navigue dans requalification_urgence)
• Le workflow linux_db part du principe que NoMachine vient juste d'être ouvert mais que DBeaver n'est PAS encore ouvert (les steps ouvrent le launcher GNOME, cliquent DBeaver, etc.)

Pour le take vidéo (J-4)

• Faire 1 warmup run avant le take (cold start VLM ~1m30 sur le 1er resolve)
• Reset la table après le warmup :

  sshpass -p loli ssh dom@192.168.122.132 \
    'python3 -c "import sqlite3; c=sqlite3.connect(\"/home/dom/demo_95\"); c.execute(\"DELETE FROM requalification_urgence WHERE id > 3\"); c.execute(\"UPDATE sqlite_sequence SET seq = 3 WHERE name = '\''requalification_urgence'\''\"); c.commit()"'
  

---

7. Dette technique (à traiter post-démo)

1. NoMachine freeze sous Windows — sujet #1 pour la fiabilité long terme
2. RPA_VLM_MODEL=gemma4:e4b hardcoded dans Léa (executor.py lignes 1569, 1700, 2248) → patch + SCP
3. qwen2.5vl:7b runtime 13 GB sur RTX 5070 12 GB — déborde CPU. Choix VLM stable manquant. Pistes : Holo1.5-7B, MiniCPM-V 2.6, ou désactiver carrément le VLM auxiliaire pour les workflows à anchor templates fiables
4. Léa peut crasher silencieusement sur Windows — investiguer logs Windows pour identifier (mémoire ? exception ?)
5. Couplage hôte ↔ VM dur : password loli en clair dans les scripts. À remplacer par clé SSH + sudoers NOPASSWD post-démo

---

8. Files clés à connaître

• /home/dom/ai/rpa_vision_v3/scripts/prepare_clipboard_linuxdb.sh (gardien clipboard, lance daemon ydotoold si absent — désormais en mode skip-sudo)
• /home/dom/ai/rpa_vision_v3/scripts/paste_and_execute_linuxdb.sh (Ctrl+V + Ctrl+Enter via ydotool, invocable depuis serveur ou à la main)
• /home/dom/ai/rpa_vision_v3/scripts/payload_insert_morel.sql (1635 bytes, table requalification_urgence)
• /home/dom/ai/rpa_vision_v3/core/detection/vlm_config.py (DEFAULT_VLM_MODEL = "gemma4:latest" mais env var de .env.local met qwen2.5vl:7b)
• /home/dom/ai/rpa_vision_v3/agent_v0/server_v1/replay_engine.py (_handle_paste_and_execute_action au handler)
• /home/dom/ai/rpa_vision_v3/agent_v0/server_v1/api_stream.py (elif type_ == "paste_and_execute" dans le dispatcher)

9. Workflow linux_db actuel (en DB)

wf_0786343fb2b7_1778879244 — 9 steps :

0  double_click_anchor   LINUX_demo (icône NoMachine sur bureau Windows)
1  click_anchor          (bouton Activités GNOME en bas-gauche Ubuntu via NoMachine)
2  click_anchor          (icône DBeaver dans le launcher GNOME ouvert)
3  wait_for_anchor       attente
4  click_anchor          (dans DBeaver)
5  click_anchor          (dans DBeaver)
6  click_anchor          (dans DBeaver — focus zone éditeur SQL)
7  keyboard_shortcut     Alt+F11 (plein écran DBeaver)
8  paste_and_execute     server-side (lance scripts/paste_and_execute_linuxdb.sh)