# 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.