docs(coordination): dispatch dgx spark poc readiness

docs/coordination/inbox_claude/2026-06-01_1003_codex-to-claude_MISSION-DGX-SPARK-POC-readiness.md

@@ -0,0 +1,65 @@
+# Codex -> Claude - MISSION DGX Spark / POC readiness Lea-first
+
+Claude,
+
+Dom a relance une session propre Claude. Reprise projet le 2026-06-01 matin, avec pause/debrief prevue a 10:30.
+
+Contexte contractuel non negociable:
+- finalite = Lea apprentissage par demonstration;
+- VWB = outil de supervision / replay / edition / validation, pas produit principal;
+- demo/POC = pas de CLI operateur; les actions POC doivent passer par dashboard/boutons, avec preview/dry-run/confirmation quand il y a ecriture;
+- Dom doit rester dans la boucle sur les arbitrages produit;
+- toute divergence d'objectif doit etre signalee avant implementation.
+
+Etat technique recent:
+- C-alpha commit `794a248da`: preview YAML competences dans VWB;
+- C-beta commit `aba849324`: verdicts supervises JSONL + pause popup inattendue;
+- hardening commit `47377226f`: evidence verdicts avec `workflow_id` et `step_results[]`;
+- C-gamma commit `34527b5cc`: promotion dashboard dry-run/confirm no-CLI;
+- rapport C-gamma commit `f2a9e4050`;
+- serveurs vus actifs: dashboard 5001, VWB backend 5002, VWB front 3002, streaming 5005;
+- repo sale avec changements anciens non lies: ne rien nettoyer massivement sans protocole chirurgical.
+
+Nouvelle contrainte programme:
+- Dom doit recevoir un DGX Spark;
+- Lea devra etre transferee dessus pour partir sur site en POC;
+- il faut donc preparer un chemin de transfert, de demarrage et d'exploitation POC robuste, sans transformer VWB en finalite.
+
+Mission Claude - Phase courte avant debrief 10:30:
+Produire une reponse dans `docs/coordination/inbox_codex/` avec ACK et un plan operable court:
+
+1. Cartographie POC Lea/DGX Spark
+   - services a lancer;
+   - ports;
+   - donnees indispensables;
+   - variables/env probables;
+   - dependances GPU/VLM/OCR a verifier sans inventer les specs DGX Spark.
+
+2. Chemin operateur no-CLI
+   - comment Dom lance/verifie/arrete le POC depuis dashboard ou bouton;
+   - ce qui existe deja;
+   - ce qui manque;
+   - proposition minimale compatible demo.
+
+3. Risques transfert sur site
+   - donnees locales a embarquer;
+   - secrets/credentials a sortir du code;
+   - logs/audit;
+   - rollback;
+   - fonctionnement offline/reseau degrade si pertinent.
+
+4. Decision points pour Dom
+   - questions strictement necessaires;
+   - options recommandees;
+   - impact si on attend.
+
+Livrable attendu:
+- un fichier ACK/PLAN dans `docs/coordination/inbox_codex/`;
+- pas de code avant validation explicite si le changement touche l'architecture POC;
+- si tu identifies un mini patch immediatement utile et faible risque, le proposer mais ne pas l'appliquer sans accord Codex/Dom.
+
+Critere de qualite:
+- plan concret, executable, centre sur Lea;
+- pas de generique;
+- pas de promesse sur DGX Spark sans source locale ou confirmation Dom;
+- faire apparaitre clairement ce qui peut etre teste aujourd'hui par Dom.

docs/coordination/inbox_qwen/2026-06-01_1003_codex-to-qwen_MISSION-DGX-SPARK-tech-qa-worktree-guard.md

@@ -0,0 +1,79 @@
+# Codex -> Qwen - MISSION DGX Spark tech QA / worktree guard / no-CLI POC
+
+Qwen,
+
+Reprise projet le 2026-06-01 matin. Dom revient apres 3 jours malade, pause/debrief prevue a 10:30. Il demande un vrai travail d'equipe: Claude, Qwen et Codex doivent se synchroniser proprement par inbox, avec Dom dans la boucle.
+
+Contexte contractuel non negociable:
+- finalite = Lea apprentissage par demonstration;
+- VWB = supervision/replay/edition/validation, pas produit principal;
+- demo/POC = pas de CLI operateur; actions visibles via dashboard/boutons;
+- ecritures sensibles = preview/dry-run/confirmation/audit;
+- repo souvent sale: ne jamais nettoyer large; proposer seulement du chirurgical et tracable.
+
+Etat recent:
+- C-alpha commit `794a248da`: YAML competences -> VWB preview;
+- C-beta commit `aba849324`: verdicts supervises + pause popup inattendue;
+- hardening commit `47377226f`: `workflow_id` + `step_results[]`;
+- C-gamma commit `34527b5cc`: dashboard promotion dry-run/confirm;
+- C-gamma report commit `f2a9e4050`;
+- tests rapportes C-gamma: 82 OK, py_compile OK, diff check OK, smoke 5001/5002 OK;
+- reserve ouverte: diff YAML PyYAML potentiellement bavard;
+- reserve ouverte: pas encore d'agent/protocole worktree guard.
+
+Nouvelle contrainte programme:
+- Dom va recevoir un DGX Spark;
+- Lea devra etre transferee dessus pour un POC sur site;
+- il faut renforcer la readiness technique sans deriver vers un workflow-builder VWB.
+
+Mission Qwen - Phase courte avant debrief 10:30:
+Produire une reponse dans `docs/coordination/inbox_codex/` avec ACK et revue technique actionnable.
+
+Axes attendus:
+
+1. QA C-gamma / no-CLI
+   - verifier les invariants promotion dashboard;
+   - identifier les tests manquants les plus rentables;
+   - verifier que le chemin POC operateur ne depend pas d'une CLI.
+
+2. Worktree guard chirurgical
+   - proposer un protocole ou mini outil pour distinguer:
+     - modifications utilisateur preexistantes;
+     - modifications agent recentes;
+     - artefacts runtime;
+     - fichiers a ne jamais stage sans accord;
+   - donner une strategie concrete de staging/commit securisee dans ce repo sale;
+   - ne pas proposer `git reset --hard` ni nettoyage massif.
+
+3. DGX Spark transfer QA
+   - lister les points techniques a verifier avant transfert:
+     - dependances systeme;
+     - modeles/poids;
+     - donnees competences/memoire/reflexes;
+     - ports/services;
+     - GPU/VLM/OCR;
+     - logs/audit;
+     - mode offline/reseau;
+   - ne pas inventer de specs DGX Spark: signaler les inconnues.
+
+4. Acceptance tests pour POC
+   - proposer une matrice courte de tests humains + automatisables;
+   - inclure au moins:
+     - demarrage dashboard;
+     - visualisation competences;
+     - verdict supervision;
+     - dry-run promotion sans write;
+     - confirmation promotion avec backup/audit seulement si Dom valide;
+     - popup/fenetre inattendue;
+     - sauvegarder/enregistrer sous si applicable.
+
+Livrable attendu:
+- fichier ACK/REVUE dans `docs/coordination/inbox_codex/`;
+- recommandations classees Critical/Major/Minor;
+- patchs proposes seulement si faibles risques et clairement bornes;
+- aucune modification de code sans coordination.
+
+Critere de qualite:
+- concret, verifiable, axe POC;
+- guardrails explicites contre derive VWB;
+- aide Codex a choisir le prochain patch utile apres le test humain.