docs(coordination): add dgx spark multi-poste poc focus

docs/coordination/inbox_claude/2026-06-01_1012_codex-to-claude_ADDENDUM-DGX-SPARK-multi-postes-apprentissage.md

@@ -0,0 +1,53 @@
+# Codex -> Claude - ADDENDUM DGX Spark POC multi-postes apprentissage
+
+Claude,
+
+Addendum Dom du 2026-06-01 matin:
+
+Le point essentiel du POC DGX Spark n'est pas seulement de transferer Lea sur le Spark. La fonctionnalite centrale a demontrer est:
+
+> Lea doit etre capable d'apprendre par demonstration depuis plusieurs postes equipes, puis de consolider/exploiter ces apprentissages cote serveur.
+
+Contexte existant trouve dans le repo:
+- dashboard Fleet dans `web_dashboard/templates/index.html`;
+- bouton "Enregistrer un agent";
+- tableau agents actifs/revoques;
+- telechargement ZIP installeur preconfigure;
+- proxy dashboard `web_dashboard/app.py` vers `/api/v1/agents/*`;
+- registre serveur `agent_v0/server_v1/agent_registry.py` table `enrolled_agents`;
+- endpoints streaming `POST /api/v1/agents/enroll`, `POST /api/v1/agents/uninstall`, `GET /api/v1/agents/fleet`;
+- config ZIP generee avec `RPA_SERVER_URL`, `RPA_API_TOKEN`, `RPA_MACHINE_ID`, `RPA_USER_LABEL`;
+- le replay/streaming propage deja largement `machine_id`.
+
+Reserve importante a verifier:
+- le dashboard parle d'un token a configurer par agent, mais le code actuel indique encore un token API global serveur:
+  - `api_stream.py` commente "Token Bearer global obligatoire";
+  - `/agents/enroll` retourne `"api_token": API_TOKEN`;
+  - `web_dashboard/app.py` injecte `RPA_API_TOKEN` global dans les ZIP;
+  - le modal dashboard dit explicitement "Ce token est le token API global du serveur".
+- Si Dom fait reference a une implementation plus recente de jetons propres, il faut la localiser. Sinon, pour le POC multi-postes, c'est un ecart fonctionnel/securite a traiter.
+
+Mission Claude ajustee:
+
+1. Recentrer le plan POC sur "multi-postes -> apprentissage -> consolidation Spark".
+   - parcours operateur no-CLI: creer agent, telecharger ZIP, installer sur poste, voir poste connecte, enregistrer une demonstration, voir apprentissage remonter, superviser, promouvoir si eligible;
+   - points UX dashboard manquants pour que Dom n'ait pas a bricoler.
+
+2. Decrire le flux produit attendu:
+   - une identite poste/collaborateur;
+   - sessions observees par machine;
+   - competences/verdicts avec contexte machine;
+   - consolidation centrale;
+   - reutilisation ou transposition sur un autre poste si compatible.
+
+3. Identifier les decisions Dom:
+   - est-ce acceptable pour POC d'avoir un token global temporaire si reseau ferme?
+   - faut-il obligatoirement un token par poste avant envoi sur site?
+   - combien de postes minimum pour valider le POC: 2, 3, plus?
+   - quelles donnees apprentissage doivent rester par poste vs globales?
+
+4. Livrer dans `docs/coordination/inbox_codex/` un ACK/PLAN mis a jour.
+
+Priorite:
+- avant 10:30: signaler clairement "existant", "gap", "prochain patch recommande";
+- pas de code avant arbitrage si cela touche auth/provisionnement.

docs/coordination/inbox_qwen/2026-06-01_1012_codex-to-qwen_ADDENDUM-DGX-SPARK-multi-postes-token-qa.md

@@ -0,0 +1,74 @@
+# Codex -> Qwen - ADDENDUM DGX Spark POC multi-postes / token QA
+
+Qwen,
+
+Addendum Dom du 2026-06-01 matin:
+
+Pour le POC Spark, le point fonctionnel essentiel est la capacite de Lea a apprendre depuis plusieurs postes equipes. Le Spark doit donc etre valide comme serveur central d'apprentissage multi-postes, pas seulement comme machine d'execution locale.
+
+Contexte repo verifie rapidement:
+- `web_dashboard/templates/index.html`
+  - onglet Fleet;
+  - "Enregistrer un agent";
+  - liste actifs/revoques;
+  - lien de telechargement d'un ZIP Lea preconfigure;
+  - modal token.
+- `web_dashboard/app.py`
+  - `GET/POST /api/fleet/<endpoint>` proxy vers `http://localhost:5005/api/v1/agents`;
+  - `GET /api/fleet/download/<machine_id>` construit un ZIP avec config personnalisee;
+  - config contient `RPA_SERVER_URL`, `RPA_API_TOKEN`, `RPA_MACHINE_ID`, `RPA_USER_LABEL`.
+- `agent_v0/server_v1/agent_registry.py`
+  - table SQLite `enrolled_agents`;
+  - `machine_id` unique;
+  - statuts `active` / `uninstalled`;
+  - `last_seen_at`.
+- `agent_v0/server_v1/api_stream.py`
+  - endpoints `/api/v1/agents/enroll`, `/uninstall`, `/fleet`;
+  - replay/streaming deja largement parametre par `machine_id`.
+
+Reserve critique a auditer:
+- malgre l'UX "token par agent", le code actuel semble utiliser un token global:
+  - `/agents/enroll` retourne `api_token: API_TOKEN`;
+  - commentaire: "Token Bearer global obligatoire";
+  - `web_dashboard/app.py` injecte `os.environ['RPA_API_TOKEN']` dans chaque ZIP;
+  - modal dashboard: "Ce token est le token API global du serveur".
+- La revocation d'un agent marque `status=uninstalled`, mais ne semble pas invalider un secret propre au poste puisqu'il n'y en a pas cote code lu.
+- Risques POC: fuite token globale, usurpation `machine_id`, revoke non effectif, confusion entre identite machine et auth.
+
+Mission Qwen ajustee:
+
+1. Auditer techniquement le chemin multi-postes:
+   - enrollment;
+   - generated ZIP;
+   - auth;
+   - heartbeat/last_seen;
+   - stockage sessions par machine;
+   - replay cible par `machine_id`;
+   - apprentissage/consolidation.
+
+2. Classer les gaps Critical/Major/Minor:
+   - per-machine token absent ou present ailleurs;
+   - revocation effective ou non;
+   - machine_id spoofable;
+   - tests manquants;
+   - compat POC reseau ferme vs site reel.
+
+3. Proposer le patch minimal si necessaire:
+   - soit "token par poste" reel avec hash stocke en DB + retour une seule fois + validation bearer liee au `machine_id`;
+   - soit garde POC temporaire clairement limitee si Dom valide reseau ferme;
+   - dashboard no-CLI obligatoire.
+
+4. Ajouter a la matrice POC:
+   - creer 2 agents dans dashboard;
+   - telecharger 2 ZIPs distincts;
+   - connecter 2 postes;
+   - enregistrer une demonstration sur poste A;
+   - verifier apparition session/workflow avec `machine_id`;
+   - supervision/verdict;
+   - replay cible poste A puis verification non-confusion avec poste B;
+   - revocation poste A et verification comportement attendu.
+
+Livrable attendu:
+- fichier ACK/REVUE dans `docs/coordination/inbox_codex/`;
+- pas de code sans coordination;
+- priorite a clarifier l'ecart token global vs "jetons propres" mentionne par Dom.