docs: track design docs, plans, audits, coordination infrastructure, handoffs
- 21 docs/*.md: audits, design notes, deployment plans, checklists, memos - Coordination: ROLES, runbooks (DGX reboot, Lea live), patches, registre, syntheses, systemd, QG template - Handoffs: 6 Codex handoff documents + README + template
This commit is contained in:
Dom
233
docs/coordination/RUNBOOK-DGX-POST-REBOOT-CHECK.md
Normal file
233
docs/coordination/RUNBOOK-DGX-POST-REBOOT-CHECK.md
Normal file
@@ -0,0 +1,233 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user