rpa_vision_v3/docs/QW_SMOKE_TESTS_2026-05-06.md

QW Suite Mai — Smoke tests pour validation manuelle

Date d'exécution prévue : 2026-05-06 (matin) Branche : feature/qw-suite-mai Durée estimée : ~1h20 si tout passe, +30 min de debug par test KO

Coche au fur et à mesure. Si un test KO, applique le "Si KO" puis re-tente. Tout test critique en KO bloquant → kill-switch (procédure §10).

---

§0. Préflight (5 min)

• 0.1 Vérifier branche : git -C /home/dom/ai/rpa_vision_v3 branch --show-current Attendu : feature/qw-suite-mai

• 0.2 Vérifier les commits récents : git -C /home/dom/ai/rpa_vision_v3 log --oneline -15 Attendu : voir tous les commits du sprint (spec, plan, QW1×4, QW2×2, QW4×3, docs, fixes A/B/C éventuels)

• 0.3 Lancer la baseline rapide :

  cd /home/dom/ai/rpa_vision_v3
  .venv/bin/pytest tests/unit/test_monitor_router.py \
                   tests/unit/test_loop_detector.py \
                   tests/unit/test_safety_checks_provider.py \
                   tests/integration/test_grounding_offset.py \
                   tests/integration/test_loop_detector_replay.py \
                   tests/integration/test_replay_resume_acknowledgments.py \
                   -q
  

  Attendu : 27 passed (en ~5s). Si KO : ne pas continuer, regarder l'erreur et m'appeler.

• 0.4 Vérifier les services systemd :

  ./svc.sh status
  

  Attendu : streaming, vwb-backend, vwb-frontend, dashboard au minimum running. Si KO : ./svc.sh start puis re-vérifier.

• 0.5 Ouvrir un terminal dédié pour journalctl (sera utilisé tout le long) :

  journalctl -u rpa-streaming -f
  

  Le laisser ouvert dans un coin de l'écran.

---

§1. Test QW1 mono-écran (10 min) — RÉGRESSION

But : prouver que le sprint n'a pas cassé un workflow Easily Assure existant.

• 1.1 Ouvrir VWB : https://vwb.labs.laurinebazin.design (ou http://localhost:3002 en local)

• 1.2 Sélectionner un workflow validé le 30/04 sur Easily Assure (UHCD ou Forfait, le plus simple).

• 1.3 Cliquer "→ Windows" pour lancer le replay sur Agent V1.

• 1.4 Pendant l'exécution, dans le terminal journalctl, chercher la ligne :

  [BUS] lea:monitor_routed source=focus|composite_fallback ...
  

  Attendu : au moins 1 occurrence par action visuelle. Sur poste mono-écran, source=composite_fallback ou source=focus (les deux sont OK).

• 1.5 Le replay doit terminer identique à avant (mêmes clics aux mêmes endroits).

Verdict : ☐ OK ☐ KO Si KO : noter l'écart visuel, kill-switch QW2/QW4 (§10) puis re-tester. Si encore KO → rollback (§11).

---

§2. Test QW1 multi-écrans (15 min, optionnel) — VALEUR AJOUTÉE

But : prouver que le ciblage par écran fonctionne. Skip si tu n'as qu'un seul écran sur le poste de démo.

• 2.1 Brancher un 2ème écran sur le poste Windows (Agent V1).

• 2.2 Vérifier qu'Agent V1 voit les 2 écrans :

  ssh dom@192.168.1.11
  C:\rpa_vision\.venv\Scripts\python.exe -c "from screeninfo import get_monitors; print([(m.x, m.y, m.width, m.height) for m in get_monitors()])"
  

  Attendu : 2 tuples affichés.

• 2.3 Lancer le même workflow Easily Assure (§1.2).

• 2.4 Dans journalctl, observer :

  • Heartbeats Windows enrichis (cf. fix A) : la session reçoit monitor_index en continu.
  • [BUS] lea:monitor_routed source=focus idx=0 ou idx=1 selon où Easily est ouvert.

• 2.5 Déplacer la fenêtre Easily Assure sur le 2ème écran avant un nouveau replay → relancer → vérifier que le clic atterrit sur le 2ème écran (pas sur le composite).

Verdict : ☐ OK ☐ KO ☐ Skipped (pas de 2ème écran)

---

§3. Test QW2 LoopDetector — boucle artificielle (10 min)

But : prouver que Léa s'arrête seule quand elle tourne en rond.

• 3.1 Dupliquer un workflow simple (1-2 actions) dans VWB.

• 3.2 Modifier la 1ère action click pour qu'elle cible un target_text impossible (ex: target_text="ZZZZZ_INEXISTANT_999").

• 3.3 Lancer le replay.

• 3.4 Dans journalctl, attendre l'apparition de :

  LoopDetector: replay XXX mis en pause — signal=retry_threshold ...
  [BUS] lea:loop_detected ...
  

  Délai attendu : ~30-60s (3 retries × ~10s par retry visuel).

• 3.5 Côté VWB : la bulle PauseDialog doit apparaître avec pause_reason=loop_detected.

• 3.6 Cliquer "Annuler" pour arrêter le replay propre.

Verdict : ☐ OK ☐ KO Si KO : vérifier RPA_LOOP_DETECTOR_ENABLED=1 (défaut). Si toujours KO → log dans journalctl doit donner la raison.

---

§4. Test QW4 backward — workflow legacy (5 min)

But : prouver qu'un pause_for_human existant continue à marcher exactement comme avant.

• 4.1 Sélectionner un workflow ayant déjà une action pause_for_human (sans safety_level ni safety_checks).

• 4.2 Lancer le replay.

• 4.3 Quand la pause apparaît : la bulle doit être identique à avant (juste le message, boutons Continuer/Annuler, PAS de checklist).

• 4.4 Dans journalctl, vérifier qu'aucun appel à Ollama medgemma:4b n'est lancé (pas de ligne avec ce modèle).

• 4.5 Cliquer Continuer → le replay doit reprendre sans erreur.

Verdict : ☐ OK ☐ KO Si KO : régression. Kill-switch QW4 (§10) + re-test.

---

§5. Test QW4 safety_checks déclaratifs (15 min)

But : prouver que la checklist s'affiche et bloque le Continue tant que les required ne sont pas cochés.

• 5.1 Dans VWB, créer ou modifier un workflow pour insérer une action pause_for_human avec :

  • message : "Validation patient"
  • safety_level : standard (PAS medical_critical, on isole le déclaratif)
  • safety_checks : 2 entrées
    • {id: "check_ipp", label: "IPP correct ?", required: true}
    • {id: "check_diag", label: "Diagnostic confirmé ?", required: true}

• 5.2 Sauvegarder, lancer le replay.

• 5.3 Quand la pause apparaît :

  • ☐ Bulle "Pause supervisée" affichée
  • ☐ 2 cases à cocher visibles avec badges [obligatoire]
  • ☐ Bouton "Continuer" désactivé (grisé)
  • ☐ Aucun badge [Léa] (pas de medical_critical → pas de LLM)

• 5.4 Cocher 1 seule case → Continuer reste désactivé.

• 5.5 Cocher la 2ème case → Continuer s'active.

• 5.6 Cliquer Continuer → replay reprend.

• 5.7 Test de sécurité : forcer un POST /api/v3/replay/resume sans cocher (via curl) :

  # Récupérer le replay_id en cours via VWB ou journalctl
  curl -X POST http://localhost:5002/api/v3/replay/resume \
       -H "Content-Type: application/json" \
       -d '{"replay_id":"<replay_id>","acknowledged_check_ids":[]}'
  

  Attendu : 400 {"detail": {"error": "required_checks_missing", "missing": ["check_ipp","check_diag"]}}

Verdict : ☐ OK ☐ KO

---

§6. Test QW4 medical_critical avec LLM (15 min)

But : prouver que Léa appelle medgemma:4b en moins de 5s et ajoute des checks contextuels.

• 6.1 Vérifier que medgemma:4b est dispo dans Ollama :

  ollama list | grep medgemma
  

  Attendu : medgemma:4b listé. Si absent : ollama pull medgemma:4b (3.3 GB).

• 6.2 Reprendre le workflow §5.1 et changer safety_level: medical_critical.

• 6.3 Lancer le replay.

• 6.4 Quand la pause apparaît :

  • ☐ Bulle affichée
  • ☐ 2 checks déclaratifs (badges [obligatoire])
  • ☐ 0 à 3 checks supplémentaires avec badge [Léa] bleu (tooltip = evidence)
  • ☐ Délai d'apparition < 5s (sinon le timeout a sauvé)

• 6.5 Dans journalctl, vérifier la ligne :

  [BUS] lea:safety_checks_generated count=N sources=['declarative', 'declarative', 'llm_contextual', ...]
  

• 6.6 Si Ollama timeout ou crash, vérifier la ligne :

  [BUS] lea:safety_checks_llm_failed reason=... detail=...
  

  Et la pause s'affiche tout de même avec les 2 checks déclaratifs (fallback safe).

Verdict : ☐ OK ☐ KO

---

§7. Test bus events lea:* (5 min)

But : agréger les events vus pour audit démo.

• 7.1 Lancer un replay complet de A à Z (workflow §1 ou §6).

• 7.2 À la fin, extraire tous les events [BUS] du journal :

  journalctl -u rpa-streaming --since "10 minutes ago" | grep "\[BUS\]" | tail -30
  

• 7.3 Vérifier la présence d'au moins :

  • lea:monitor_routed (au moins 1 par action visuelle)
  • lea:safety_checks_generated (si test §6 fait, au moins 1)
  • lea:loop_detected (si test §3 fait)

Verdict : ☐ OK ☐ KO

---

§8. Test kill-switches (10 min) — RÉFLEXE DÉMO

But : savoir désactiver QW2/QW4 en pleine démo si ça part en vrille.

• 8.1 Désactiver QW2 + QW4 :

  sudo systemctl edit rpa-streaming
  # Ajouter sous [Service] :
  Environment=RPA_LOOP_DETECTOR_ENABLED=0
  Environment=RPA_SAFETY_CHECKS_LLM_ENABLED=0
  # Sauver, sortir
  sudo systemctl restart rpa-streaming
  

• 8.2 Re-lancer un replay quelconque.

• 8.3 Dans journalctl : vérifier qu'aucun event lea:loop_detected ni lea:safety_checks_generated n'apparaît.

• 8.4 Réactiver (avant la démo réelle) :

  sudo systemctl edit rpa-streaming
  # Supprimer les 2 lignes Environment=...
  sudo systemctl restart rpa-streaming
  

• 8.5 Re-vérifier qu'un replay normal réémet les bus events.

Verdict : ☐ OK ☐ KO

---

§9. Test rollback complet (procédure) — RÉFLEXE D'URGENCE

À NE PAS exécuter sauf vraie urgence, juste connaître la commande :

cd /home/dom/ai/rpa_vision_v3
git checkout backup/pre-qw-suite-mai-2026-05-05
./svc.sh restart

Pour revenir au sprint après rollback :

git checkout feature/qw-suite-mai
./svc.sh restart

• 9.1 Lire la procédure, savoir où elle est documentée (docs/QW_SUITE_MAI.md).

---

§10. Si problème en pleine démo

Ordre des réflexes :

1. Kill-switch QW2 d'abord (LoopDetector = couche passive, désactiver est sans risque) :

   sudo systemctl set-environment RPA_LOOP_DETECTOR_ENABLED=0
   sudo systemctl restart rpa-streaming
   

   (set-environment est plus rapide que systemctl edit mais ne survit pas au reboot — OK pour démo)

2. Kill-switch QW4 ensuite si toujours problème :

   sudo systemctl set-environment RPA_SAFETY_CHECKS_LLM_ENABLED=0
   sudo systemctl restart rpa-streaming
   

3. Rollback complet si toujours KO (cf. §9).

---

§11. Récap final

À cocher après tous les tests pour acter "prêt démo" :

• §1 mono-écran OK (régression zéro)
• §2 multi-écrans OK ou skip assumé
• §3 LoopDetector OK
• §4 backward QW4 OK
• §5 safety_checks déclaratifs OK
• §6 medical_critical + LLM OK
• §7 bus events visibles dans journalctl
• §8 kill-switches testés et fonctionnels
• §9 procédure rollback connue

Si tout coché → démo GHT GO 🟢 Si §1 ou §3 ou §5 KO → démo NO-GO sans fix 🔴 Si §2 ou §6 KO → démo OK avec kill-switch QW correspondant 🟡

---

Annexes

• Spec : docs/superpowers/specs/2026-05-05-qw-suite-mai-design.md
• Plan d'exécution : docs/superpowers/plans/2026-05-05-qw-suite-mai.md
• Synthèse livraison : docs/QW_SUITE_MAI.md
• Backup distant : backup/pre-qw-suite-mai-2026-05-05 (Gitea)
• Tests automatisés (référence 116 passed) :

  .venv/bin/pytest tests/unit/test_monitor_router.py \
                   tests/unit/test_loop_detector.py \
                   tests/unit/test_safety_checks_provider.py \
                   tests/integration/test_grounding_offset.py \
                   tests/integration/test_loop_detector_replay.py \
                   tests/integration/test_replay_resume_acknowledgments.py \
                   tests/test_pipeline_e2e.py \
                   tests/test_phase0_integration.py \
                   tests/integration/test_stream_processor.py \
                   -q