docs(qw): plan de smoke tests manuels pour validation 2026-05-06
Plan exécutable seul par Dom : 9 sections (préflight, QW1 mono/multi-écran, QW2 boucle, QW4 backward/déclaratif/medical_critical, bus events, kill-switches, rollback) avec checklist OK/KO et procédures d'urgence en pleine démo. Validation pour démo GHT (1ère sem mai 2026). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
343
docs/QW_SMOKE_TESTS_2026-05-06.md
Normal file
343
docs/QW_SMOKE_TESTS_2026-05-06.md
Normal file
@@ -0,0 +1,343 @@
|
||||
# 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 :
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
./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) :
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
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) :
|
||||
```bash
|
||||
# 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 :
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
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) :
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
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) :
|
||||
```bash
|
||||
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 :
|
||||
```bash
|
||||
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) :
|
||||
```bash
|
||||
.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
|
||||
```
|
||||
Reference in New Issue
Block a user