# 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 :
```python
_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 :
  ```bash
  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)
```