backup: snapshot post-démo GHT 2026-05-19

Backup état complet après enregistrement vidéo démo de bout en bout.
À utiliser comme point de référence pour la consolidation post-démo.

Changements majeurs de la session 18-19 mai :
- AIVA-URGENCE : page autonome avec preset URL + auto-focus chain
- Workflow Demo_urgence_3_db : merge linux_db + steps AIVA + pause humaine NoMachine
- Bypass LLM (static_result / static_text) dans replay_engine
  pour démos déterministes sans appel Ollama
- Fix api_stream:3013 — replay_paused au premier polling /next
- dag_execute : lift duration_ms vers top-level pour wait runtime
- NPM bypass auth /aiva-urgence/ via location ^~ (proxy_host/10.conf hors git)
- scripts/cancel-replays.sh — workaround Stop VWB qui ne purge pas la queue

Anchors visuels (468) forcés dans le commit pour garantir restorabilité.
DB workflows actuelle + ~12 .bak DB de la journée incluses.

Sujets identifiés pour consolidation post-démo (TODO) :
1. Bug VWB recapture anchor ne régénère pas le PNG
2. Léa client accumule état mémoire (restart périodique requis)
3. Stop VWB ne purge pas la queue serveur (lien manquant vers /replay/cancel)
4. Bug coord client mss tronqué 2560x60 → mapping Y cassé
5. delay_before/delay_after ignorés au runtime (fix partiel duration_ms)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

deploy/systemd/ollama-vram-policy.conf

@@ -0,0 +1,30 @@
+# Drop-in pour /etc/systemd/system/ollama.service.d/vram-policy.conf
+#
+# Politique VRAM RPA Vision V3 — RTX 5070 12 GB partagée avec InfiGUI.
+#
+# Le service `rpa-grounding` charge InfiGUI-G1-3B en permanence (~2.4 GB).
+# Pour éviter qu'Ollama charge plusieurs VLM en parallèle (qwen2.5vl:3b ET 7b)
+# et déborde, on limite à 1 modèle chargé à la fois.
+#
+# OLLAMA_MAX_LOADED_MODELS=1 : un seul modèle en VRAM Ollama. Si on demande
+#   un autre modèle, l'ancien est déchargé automatiquement avant le nouveau.
+#   En pratique, comme Dom fait RECORD ou REPLAY mais pas les deux en même
+#   temps, le swap a lieu lors du changement de mode et coûte ~5s une seule fois.
+#
+# OLLAMA_KEEP_ALIVE=5m : un modèle inutilisé pendant 5 min est déchargé.
+#   Bon compromis entre réactivité (warm start dans la session) et libération
+#   VRAM (un mode oublié ne traîne pas).
+#
+# OLLAMA_NUM_PARALLEL=1 : une seule requête Ollama en parallèle. Évite la
+#   contention GPU avec InfiGUI quand le pipeline appelle les deux backends
+#   en cascade.
+#
+# Installation :
+#   sudo mkdir -p /etc/systemd/system/ollama.service.d/
+#   sudo cp deploy/systemd/ollama-vram-policy.conf /etc/systemd/system/ollama.service.d/vram-policy.conf
+#   sudo systemctl daemon-reload && sudo systemctl restart ollama
+
+[Service]
+Environment="OLLAMA_MAX_LOADED_MODELS=1"
+Environment="OLLAMA_KEEP_ALIVE=5m"
+Environment="OLLAMA_NUM_PARALLEL=1"

deploy/systemd/rpa-grounding.service

@@ -0,0 +1,60 @@
+[Unit]
+Description=RPA Vision V3 - Service grounding persistant (InfiGUI-G1-3B)
+# Dépend du GPU NVIDIA prêt et du réseau pour le téléchargement HuggingFace au premier run.
+After=network-online.target nvidia-persistenced.service
+Wants=network-online.target
+
+[Service]
+Type=simple
+
+# ---- Runtime ----
+User=dom
+Group=dom
+WorkingDirectory=/home/dom/ai/rpa_vision_v3
+EnvironmentFile=-/home/dom/ai/rpa_vision_v3/.env.local
+Environment="PYTHONUNBUFFERED=1"
+Environment="PYTHONDONTWRITEBYTECODE=1"
+Environment="ENVIRONMENT=production"
+Environment="RPA_SERVICE_NAME=rpa-grounding"
+# Socket + répertoire d'images partagé avec les autres services RPA
+# via RuntimeDirectory=rpa (cf. plus bas). PrivateTmp=true reste activé :
+# /tmp serait isolé par service systemd, donc on n'utilise plus /tmp pour
+# les transferts client/serveur — tout passe par /run/rpa/.
+Environment="RPA_GROUNDING_SOCKET=/run/rpa/grounding.sock"
+Environment="RPA_GROUNDING_IMG_DIR=/run/rpa"
+# Forcer la visibilité GPU (cf. note sur héritage CUDA dans ui_tars_grounder.py)
+Environment="CUDA_VISIBLE_DEVICES=0"
+Environment="NVIDIA_VISIBLE_DEVICES=all"
+
+ExecStart=/home/dom/ai/rpa_vision_v3/.venv/bin/python3 -m core.grounding.infigui_server
+
+# ---- Socket partagé ----
+# /run/rpa/ est créé par systemd au démarrage et nettoyé à l'arrêt.
+# Les autres services (api, worker, dashboard, vwb) doivent lire ce répertoire :
+# ils ne le créent pas, ils s'attendent à ce qu'il existe et que le socket soit dedans.
+RuntimeDirectory=rpa
+RuntimeDirectoryMode=0755
+
+# ---- Resilience ----
+# Le chargement initial du modèle prend 10–15s. Restart=on-failure couvre les
+# crashs CUDA ; le client a un fallback subprocess pour la fenêtre de redémarrage.
+Restart=on-failure
+RestartSec=5
+# Le modèle est gros (~2.4GB VRAM, ~6GB RAM). Laisser largement le temps de charger.
+TimeoutStartSec=120
+TimeoutStopSec=30
+
+# ---- Hardening ----
+# PrivateTmp=true : OK car les transferts d'images se font via /run/rpa/
+# (RuntimeDirectory) et non plus via /tmp. Tous les services consommateurs
+# doivent déclarer RuntimeDirectory=rpa pour voir le même répertoire.
+PrivateTmp=true
+NoNewPrivileges=true
+
+# Logs -> journald
+StandardOutput=journal
+StandardError=journal
+SyslogIdentifier=rpa-grounding
+
+[Install]
+WantedBy=multi-user.target

deploy/systemd/rpa-mockup-easily.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=Maquette Easily Assure (démo GHT Sud 95) - serveur statique HTTP
+Description=Maquette Easily Assure (démo GHT Sud 95) - Flask + /api/analyse
 After=network-online.target
 Wants=network-online.target
 
@@ -8,7 +8,9 @@ Type=simple
 User=dom
 Group=dom
 WorkingDirectory=/home/dom/ai/rpa_vision_v3/docs/clients/ght_sud_95/mockup_easily_assure
-ExecStart=/usr/bin/python3 -m http.server 8765 --bind 0.0.0.0
+Environment=PYTHONUNBUFFERED=1
+Environment=PYTHONPATH=/home/dom/ai/rpa_vision_v3
+ExecStart=/home/dom/ai/rpa_vision_v3/.venv/bin/python server.py
 
 Restart=on-failure
 RestartSec=3
@@ -18,7 +20,6 @@ NoNewPrivileges=true
 PrivateTmp=true
 ProtectSystem=strict
 ProtectHome=read-only
-ReadOnlyPaths=/home/dom/ai/rpa_vision_v3/docs/clients/ght_sud_95/mockup_easily_assure
 
 StandardOutput=journal
 StandardError=journal