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.