rpa_vision_v3/docs/coordination/RUNBOOK-DGX-POST-REBOOT-CHECK.md

RUNBOOK DGX - Check post-deploiement et post-reboot POC

• Date: 2026-06-17
• Responsable coordination: Codex
• Scope: POC DGX uniquement
• Cible labo actuelle: DGX 192.168.1.45
• Cible clinique preparee: Ethernet 192.168.1.178/24, gateway 192.168.1.243, DNS 192.168.1.9 puis 192.168.1.8, IPv6 inactive, profil inactif tant que Dom/Codex ne donnent pas le GO.

Objectif

Valider qu'apres deploiement puis redemarrage du DGX, toute la chaine POC reste fonctionnelle sans dependance localhost cote utilisateur:

• dashboard;
• VWB;
• import workflow;
• anchors visibles;
• agent-chat / "Discuter avec Lea";
• streaming/fleet;
• worker/replay;
• installateur Lea autonome;
• configuration reseau DGX sans bascule clinique accidentelle.

Regle de conduite

• Dom execute uniquement les gestes UI de la section "Check Dom".
• Les agents techniques collectent les preuves systeme et reseau.
• Toute divergence est notee avec: etape, symptome, impact, rollback propose.
• Pas de changement reseau clinique actif pendant le check labo: le Wi-Fi reste le lien de test.

0. Prerequis avant reboot

Point	Attendu	Statut
Branche DGX	poc-dgx	A confirmer par Claude
Commit DGX	9605cc9d9 ou commit ulterieur explicitement valide	A confirmer par Claude
Commits POC presents	667575c3a, 9605cc9d9	A confirmer par Claude/Qwen
Deploy propre	pas de fichier parasite embarque dans le runtime POC	A confirmer
Donnees runtime	backup backend/instance/workflows.db avant reset/deploy, restore apres deploy, hash/size verifies	A confirmer par Claude
Donnees non trackees	data/workflows (symlink) + donnees VWB sous visual_workflow_builder/backend/data/ non supprimes	A confirmer
VWB build	bundle reconstruit depuis poc-dgx	A confirmer
Installateur Lea	version 1.0.1, Python embedded obligatoire	A confirmer
Profil Ethernet clinique	prepare si besoin, autoconnect off, non active	A confirmer par Qwen
Enrolement VM Lea	VM/poste pointe vers DGX labo 192.168.1.45 pour le test, pas vers l'URL cloud	A confirmer

NO-GO reboot si le deploiement n'est pas fige, si le DGX ne pointe pas sur le bon commit, ou si workflows.db/anchors/workflows ne sont pas verifies apres deploy.

1. Baseline avant reboot

Un agent technique releve l'etat avant redemarrage:

Famille	Controle	Attendu
Services principaux	dashboard, VWB backend, streaming, agent-chat, worker/fleet actifs	actifs
Ports utilisateur	5001, 5004, 5005 disponibles depuis le LAN autorise	OK
Ports internes	5002, 8000, 11434 selon architecture DGX	OK ou documente
Dashboard	acces par http://192.168.1.45:5001	login ou 401 attendu, pas page blanche
Streaming	health :5005	200/healthy
Auth streaming	route protegee sans token	401 attendu
Agent chat	status/health :5004	200/online
VWB	frontend charge depuis IP DGX	OK
Bundle VWB	aucune URL active localhost/127.0.0.1	OK
VM Windows Lea	Lea pointe vers DGX 192.168.1.45 pour 5004/5005	OK

Si un point est deja rouge avant reboot, on corrige avant de redemarrer. Le reboot ne doit pas servir a masquer une panne.

2. Reboot DGX

1. Claude annonce le debut du reboot dans la coordination.
2. Codex garde la coordination ouverte.
3. Attendre le retour reseau du DGX sur le Wi-Fi labo.
4. Ne pas activer le profil Ethernet clinique pendant ce cycle.
5. Claude poste l'heure de retour et le premier etat des services.

NO-GO immediat si le DGX ne revient pas sur le reseau labo ou si le dashboard reste inaccessible plus de 10 minutes apres retour reseau.

3. Check technique post-reboot

3.1 Services

Noms constates/attendus a verifier sur le DGX. Ne pas supposer qu'un service existe: si une unite est absente, le noter et verifier si sa fonction est couverte par un autre service.

• rpa-streaming
• rpa-agent-chat
• rpa-vision-v3-dashboard
• rpa-vision-v3-vwb-frontend
• rpa-vision-v3-vwb-backend
• rpa-vision-v3-worker
• rpa-vision-v3-stream-worker si installe, sinon documenter l'absence
• rpa-vision-v3-api
• rpa-grounding ou service grounder equivalent si present; sinon documenter le fallback
• rpa-vision-v3-healthcheck.timer si actif dans le deploiement final; sinon ne pas bloquer mais documenter

Attendu:

• services POC critiques actifs apres reboot;
• services POC critiques enabled si necessaires au demarrage automatique;
• pas de boucle restart;
• logs recents sans traceback bloquant;
• healthcheck timer actif ou decision documentee si non utilise;
• VWB frontend servi par le vrai frontend POC (frontend_v4), pas l'ancien frontend/.
• Ne jamais utiliser git clean -xfd sur DGX pendant la sequence POC: cela detruirait les donnees runtime non trackees.

3.2 Reseau et ports

Port	Usage	Attendu labo
5001	dashboard / VWB integre	accessible via 192.168.1.45
5004	agent-chat / ChatWindow Lea	accessible depuis VM Windows autorisee
5005	streaming/fleet/replay	accessible depuis VM Windows autorisee
5002	VWB backend si separe	conforme au deploiement DGX
8000	upload/API core si actif	conforme au deploiement DGX
11434	Ollama local DGX	local/interne sauf decision contraire

Attendu:

• aucun appel navigateur produit vers localhost ou 127.0.0.1;
• 5004/5005 repondent depuis la VM Windows;
• le dashboard charge toutes ses ressources depuis l'IP DGX;
• la carte Ethernet clinique reste inactive ou non connectee pendant le check labo.

3.3 Endpoints et fonctions serveur

Controle	Attendu
Dashboard 5001	page login/auth visible, pas 500
Streaming 5005/health	healthy
Streaming route protegee sans token	401
Fleet machines	VM Lea visible ou reenrolement documente
Enrolement VM Lea	config.txt/runtime pointe vers DGX, pas vers URL cloud
Replay next	repond correctement pour machine enrollee
Agent chat 5004	online et session chat possible
VWB catalog/workflows	liste chargee
Anchors API	upload/thumbnail/original accessibles depuis IP DGX
Worker	pas de backlog bloquant, pas de crash loop
Modele/grounding	service disponible ou fallback documente

4. Check Dom UI post-reboot

Dom ne fait que ces gestes:

Etape	Geste Dom	GO	NO-GO
T1 Dashboard	Ouvrir l'URL DGX fournie	page login/dashboard visible	page blanche, site inaccessible, erreur 500
T2 Chat Lea	Dans la VM, ouvrir "Discuter avec Lea", envoyer "Bonjour"	reponse en quelques secondes	pas connectee, erreur serveur, fermeture fenetre
T3 Bulles action	Demander une action simple	bulles/progression visibles	aucune progression visible pendant une action lancee
T4 Import VWB	Importer un workflow JSON Lea	succes, workflow visible	erreur, rien ne se passe
T5 Anchors	Ouvrir une etape avec ancre	image d'ancre/crop visible	image absente, plein ecran au lieu de crop
T6 Replay supervise	Lancer un replay safe/supervise	execution ou demande de confirmation	clic hors cible, blocage, absence de reaction
T7 Reconnexion apres reboot	Fermer/rouvrir Lea sur VM	reconnecte DGX sans reconfig manuelle	demande Python/outils externes ou config manuelle non prevue

5. Criteres GO/NO-GO

GO livraison labo si:

• DGX revient apres reboot;
• services critiques actifs;
• dashboard accessible via IP DGX;
• VWB charge sans localhost;
• chat Lea fonctionne depuis VM;
• import workflow OK;
• anchors visibles;
• replay supervise OK ou comportement d'arret/confirmation conforme;
• installateur Lea autonome confirme;
• profil Ethernet clinique non active par erreur.

NO-GO livraison si un des points suivants echoue:

• DGX ne revient pas proprement apres reboot;
• dashboard/VWB inaccessible;
• 5004 ou 5005 indisponible depuis la VM;
• "Discuter avec Lea" ne fonctionne pas;
• installateur demande Python ou un outil externe;
• VWB appelle encore localhost cote navigateur;
• import/anchors/replay cassent;
• configuration Ethernet clinique activee accidentellement pendant les tests labo.

6. Preuves a archiver

Claude fournit:

• commit DGX courant;
• preuve backup/restore workflows.db si reset/deploy effectue;
• confirmation que data/workflows et les vrais chemins visual_workflow_builder/backend/data/anchors, visual_workflow_builder/backend/data/anchor_images, visual_workflow_builder/backend/instance/workflows.db sont presents apres deploy/reboot;
• liste services actifs/enabled;
• ports et endpoints avec resultats;
• resultat grep bundle no-localhost;
• resultat test VM Lea chat;
• resultat import/anchors/replay;
• chemin de l'artefact installateur Lea 1.0.1;
• incidents et rollback si besoin.

Qwen fournit:

• controle croise commits/fichiers parasites;
• matrice GO/NO-GO post-reboot;
• verification profil Ethernet clinique inactif;
• etat VM Windows 11 ARM DGX ou decision fallback VMware clinique.

Codex consolide:

• verdict final pret/pas pret;
• liste des anomalies restantes;
• decision de passage au check site ou retour correction.

7. Rollback minimal

Si VWB regresse:

• revenir au dernier commit POC valide connu;
• redeployer le bundle precedent;
• redemarrer uniquement dashboard/VWB backend;
• refaire T1, T4, T5.

Si agent-chat regresse:

• verifier service rpa-agent-chat;
• verifier env 5004/feedback bus;
• redemarrer agent-chat puis streaming si necessaire;
• refaire T2/T3.

Si streaming/fleet regresse:

• verifier service rpa-streaming;
• verifier token/auth;
• verifier reenrolement VM;
• refaire T2/T6.

Si reseau clinique s'active par erreur:

• revenir au profil Wi-Fi labo;
• desactiver le profil Ethernet clinique;
• confirmer retour dashboard 192.168.1.45;
• ne reprendre les tests qu'apres stabilisation.