chore(dgx): snapshot consolidation WIP pour transfert poc DGX
Regroupe le WIP non committé requis pour le clone/runtime DGX (Option A) : - api_stream.py : préflight replay + smoke santé modèles + handler 403 WP-B - de-hardcode VLM : vlm_config, gpu/*, vram_orchestrator, ollama_manager - stream_processor, semantic_matcher, agent_chat (app/planner/intent) - workflows.db (acquis ; le transfert artifacts le mettra à jour + rewrite chemins) - docs : plans DGX, benchmarks VLM/grounders, recherche SOTA, coordination 8 juin Snapshot destiné à la branche poc-dgx poussée sur Gitea pour cloner le DGX. Scan anti-secret : clean. graphify (repo embarqué) exclu. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
@@ -0,0 +1,66 @@
|
||||
# Fiches actions reprise 2026-06-03 — VLM/DGX/Lea
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-03 10:10 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Refs`:
|
||||
- `docs/handoffs/2026-06-02_handoff_codex_fin_session_reprise_2026-06-03.md`
|
||||
- `docs/handoffs/2026-06-02_handoff_qwen_fin_session_reprise_2026-06-03.md`
|
||||
- `docs/coordination/inbox_codex/2026-06-02_1919_claude-to-codex_INFO-qwen25vl-rpa-transfere-DGX-grounding-OK.md`
|
||||
- `docs/coordination/inbox_codex/2026-06-02_1925_claude-to-codex_ACK-GO-dehardcode-VLM-plan-TDD.md`
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
1. P1.x de-hardcodage VLM : enlever les hardcodes `gemma4:*`, `qwen2.5vl:7b` dangereux et le port mort `11435`.
|
||||
2. Quality gate P1.x : Qwen verifie le patch sans dependance DGX reelle.
|
||||
3. Synchronisation docs coordination : commit docs seulement si Dom valide, sans toucher au `.docx` DSI ni a `workflows.db`.
|
||||
4. Cadrage P1.y DGX inference bake-off : comparer Ollama baseline vs vLLM/SGLang, hors hot path Lea.
|
||||
5. Test Lea humain E2E : seulement apres stabilisation VLM/DGX.
|
||||
|
||||
## Contraintes communes
|
||||
|
||||
- Ne pas modifier/revert `docs/POC/PREREQUIS_DSI_DGX_SPARK_2026-06-01.docx`.
|
||||
- Ne pas modifier/revert `visual_workflow_builder/backend/instance/workflows.db`.
|
||||
- Ne pas creer d'alias Ollama sur DGX.
|
||||
- Ne pas hardcoder `qwen2.5vl:7b-rpa`, `qwen3-vl:8b`, `gemma4:e4b` ou `gemma4:latest` dans les call-sites runtime.
|
||||
- Tests P1.x mockes HTTP uniquement, sans service DGX obligatoire.
|
||||
- Ne pas brancher un nouveau runtime d'inference dans Lea avant benchmark et GO.
|
||||
|
||||
## Repartition
|
||||
|
||||
| Acteur | Fiche | Role |
|
||||
|---|---|---|
|
||||
| Claude | `docs/coordination/inbox_claude/2026-06-03_1010_codex-to-claude_FICHE-ACTION-P1X-dehardcode-VLM-DGX.md` | Execution TDD du de-hardcodage VLM et retour patch/tests |
|
||||
| Qwen | `docs/coordination/inbox_qwen/2026-06-03_1010_codex-to-qwen_FICHE-QG-P1X-dehardcode-et-bakeoff-DGX.md` | Quality gate P1.x, puis cadrage QG du bake-off |
|
||||
| Gemini | `docs/coordination/inbox_gemini/2026-06-03_1010_codex-to-gemini_STANDBY-bakeoff-DGX-vlm.md` | Veille/revue optionnelle si Dom reactive Gemini |
|
||||
| Codex | cette fiche | Orchestration, verification locale, cadrage adapter OpenAI-compatible LeaBench |
|
||||
|
||||
## Fiche Codex
|
||||
|
||||
### Actions immediates
|
||||
|
||||
1. Lire toute livraison Claude posterieure au GO P1.x avant de toucher au code.
|
||||
2. Verifier le patch P1.x localement si livraison recue.
|
||||
3. Lancer les tests cibles mentionnes par Claude + un `rg` de controle sur hardcodes VLM.
|
||||
4. Si GO Qwen et tests verts, proposer un commit code separe du commit docs coordination.
|
||||
5. Creer ensuite la fiche active `P1.y DGX inference bake-off` avec adapter `openai_compat` pour LeaBench.
|
||||
|
||||
### Commandes utiles
|
||||
|
||||
```bash
|
||||
rg -n "gemma4:|qwen2\\.5vl:7b|11435" agent_v0 core tests
|
||||
RPA_AUTH_DISABLED=true .venv/bin/python -m pytest tests/unit tests/integration -q
|
||||
```
|
||||
|
||||
Adapter les tests au scope exact touche. Ne pas lancer de replay live ni de service runtime sans GO Dom.
|
||||
|
||||
## Definition de sortie
|
||||
|
||||
- P1.x est ferme seulement si :
|
||||
- hardcodes runtime dangereux retires ou justifies ;
|
||||
- endpoints ne pointent plus vers `11435` ;
|
||||
- chemin grounding bbox preserve ;
|
||||
- tests mockes passent ;
|
||||
- Qwen rend GO ou GO partiel non bloquant.
|
||||
- P1.y est ouvert seulement comme benchmark isole, pas comme migration runtime.
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# Reprise post-coupure — orchestration 2026-06-04
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-04 09:52 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Contexte`: session precedente coupee, reprise par lecture locale
|
||||
|
||||
## Etat verifie localement
|
||||
|
||||
- Branche: `backup/post-demo-2026-05-19`
|
||||
- HEAD: `4dc7d840d feat(p1x): de-hardcode VLM models/endpoints to vlm_config (DGX-ready)`
|
||||
- P1.x serveur: patch livre par Claude, commit present localement.
|
||||
- Tests cibles P1.x lances localement:
|
||||
|
||||
```bash
|
||||
RPA_AUTH_DISABLED=true .venv/bin/python -m pytest \
|
||||
tests/unit/test_task_planner.py tests/unit/test_replay_critic.py \
|
||||
tests/unit/test_domain_personality.py tests/unit/test_workflow_ir.py \
|
||||
tests/unit/test_resolve_engine_observer_vlm.py tests/unit/test_resolve_engine_bbox_num_ctx.py \
|
||||
tests/unit/test_resolve_engine_dialog_button_guard.py tests/unit/test_resolve_engine_start_button_guard.py \
|
||||
tests/unit/test_dialog_resolver.py tests/unit/test_vlm_grounding_profile.py \
|
||||
tests/unit/test_v4_resolve_order.py tests/unit/test_chat_interface.py tests/unit/test_v4_wiring.py \
|
||||
tests/unit/test_safety_checks_provider.py tests/unit/test_ui_detector.py \
|
||||
tests/unit/test_extraction_engine.py -q
|
||||
```
|
||||
|
||||
Resultat local: `305 passed`, 2 warnings Python non bloquants.
|
||||
|
||||
## Reserve importante
|
||||
|
||||
Le verdict Qwen `2026-06-03_1730_qwen-to-codex_VERDICT-QG-P1X-GO-resolu.md`
|
||||
dit que le `rg` global est silencieux. Ce n'est pas vrai dans le checkout local.
|
||||
|
||||
Le grep local trouve encore des occurrences dans:
|
||||
|
||||
- client gele: `agent_v0/agent_v1/core/executor.py` et copie deploy Windows;
|
||||
- chemins V4 / reasoning: `core/execution/observe_reason_act.py`, `core/execution/input_handler.py`, `core/cognition/vram_orchestrator.py`;
|
||||
- config/infra: `core/config.py`, `core/gpu/*`;
|
||||
- commentaires/tests.
|
||||
|
||||
Conclusion Codex provisoire: P1.x serveur est sain, mais le statut "globalement nettoye"
|
||||
est trop fort tant que les occurrences restantes ne sont pas classees par wiring runtime.
|
||||
|
||||
## Contraintes maintenues
|
||||
|
||||
- Ne pas modifier/revert `docs/POC/PREREQUIS_DSI_DGX_SPARK_2026-06-01.docx`.
|
||||
- Ne pas modifier/revert `visual_workflow_builder/backend/instance/workflows.db`.
|
||||
- Ne pas patcher le client Lea gele sans GO Dom explicite.
|
||||
- Ne pas brancher de nouveau runtime inference dans Lea avant benchmark et GO.
|
||||
|
||||
## Actions lancees
|
||||
|
||||
- Claude: mission de cartographie/cadrage dette VLM hors P1.x serveur.
|
||||
- Qwen: revue corrective du verdict P1.x et classification des occurrences restantes.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# Parallelisation P1.z / P1.y — 2026-06-04
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-04 14:27 Europe/Paris
|
||||
- `Statut`: actif
|
||||
|
||||
## Decision
|
||||
|
||||
Dom valide que les deux etapes avancent en parallele.
|
||||
|
||||
## Repartition
|
||||
|
||||
- Claude: execution TDD P1.z V4/reasoning DGX-safe.
|
||||
- Qwen: quality gate P1.z + cadrage quality gate P1.y bake-off DGX.
|
||||
- Codex: orchestration, lecture des retours, verification locale avant suite.
|
||||
|
||||
## Bornes
|
||||
|
||||
- P1.z peut toucher `core/execution/*`, `core/cognition/vram_orchestrator.py`,
|
||||
et eventuellement un helper config central.
|
||||
- P1.y reste benchmark isole: aucun branchement Lea runtime.
|
||||
- Client Lea gele hors scope.
|
||||
- `.docx` DSI et `workflows.db` intouchables.
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
# Distribution P1.y-alpha / P1.w — 2026-06-04
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-04 16:35 Europe/Paris
|
||||
- `Statut`: actif
|
||||
|
||||
## Etat
|
||||
|
||||
- P1.x serveur: GO.
|
||||
- P1.z V4/reasoning: GO, commit `806cc04b8`.
|
||||
- P1.y bake-off: cadre Qwen recu, addendum memoire provider-neutral recu.
|
||||
|
||||
## Repartition
|
||||
|
||||
- Claude: P1.y-alpha, adapter OpenAI-compatible LeaBench isole.
|
||||
- Qwen: QG P1.y-alpha + cadrage P1.w fallback `DEFAULT_VLM_MODEL`.
|
||||
- Codex: orchestration, verification locale, pas de modification runtime sans GO.
|
||||
|
||||
## Bornes
|
||||
|
||||
- P1.y-alpha ne lance pas vLLM/SGLang et ne touche pas Lea runtime.
|
||||
- P1.w est seulement cadre pour l'instant.
|
||||
- `.docx` DSI et `workflows.db` restent intouchables.
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# Info modeles DGX — gemma4:31b disponible
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-05 10:35 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Source`: Dom, conversation directe
|
||||
|
||||
## Information Dom
|
||||
|
||||
Dom indique que `gemma4:31b` est charge.
|
||||
|
||||
Dom autorise aussi Codex/agents a telecharger des modeles utiles si besoin, sans redemander
|
||||
un accord a chaque modele. A garder scope: uniquement pour benchmark/validation utile au POC.
|
||||
|
||||
## Impact
|
||||
|
||||
- P1.w fallback VLM: ne pas conclure automatiquement que `gemma4:31b` doit devenir le default.
|
||||
- P1.y bake-off: `gemma4:31b` peut entrer dans les candidats qualite/latence si disponible
|
||||
sur le runtime teste.
|
||||
- Toute selection de default runtime reste soumise a mesures: latence, precision, memoire,
|
||||
stabilite, zero clic dangereux.
|
||||
|
||||
## Garde-fous
|
||||
|
||||
- Pas d'alias Ollama.
|
||||
- Pas de migration hot path Lea sans benchmark et GO Dom.
|
||||
- Ne pas faire exploser le stockage modele sans raison explicite.
|
||||
- Noter tout modele telecharge dans la coordination.
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Distribution P1.w fallback VLM — 2026-06-05
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-05 10:50 Europe/Paris
|
||||
- `Statut`: actif
|
||||
|
||||
## Etat
|
||||
|
||||
- P1.x serveur: GO.
|
||||
- P1.z V4/reasoning: GO.
|
||||
- P1.y-alpha adapter OpenAI-compatible LeaBench: GO.
|
||||
- P1.w: cadrage Qwen recu, execution lancee.
|
||||
|
||||
## Information Dom
|
||||
|
||||
Dom confirme que les modeles cites/observes ce matin sont bien presents cote DGX/tunnel.
|
||||
La liste observee via `/api/tags` incluait notamment:
|
||||
|
||||
- `qwen2.5vl:7b-rpa`
|
||||
- `qwen2.5vl:7b`
|
||||
- `gemma4:31b-cloud`
|
||||
- autres modeles locaux plus petits.
|
||||
|
||||
Dom a aussi indique que des telechargements de modeles utiles sont autorises si necessaire.
|
||||
|
||||
## Repartition
|
||||
|
||||
- Claude: executer P1.w en TDD, correction minimale du fallback VLM central.
|
||||
- Qwen: quality gate P1.w et verification du choix de fallback.
|
||||
- Codex: verification locale, relance QG, pas de migration runtime non demandee.
|
||||
|
||||
## Point de vigilance
|
||||
|
||||
Qwen a propose `DEFAULT_VLM_MODEL = "qwen3-vl:8b"`, mais Codex n'a pas vu ce modele
|
||||
dans le `/api/tags` local lors du smoke. Claude doit verifier la disponibilite effective
|
||||
avant de choisir le fallback. Ne pas hardcoder un modele absent.
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# DGX Ollama tags verifies — 2026-06-05
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-05 11:05 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Source`: smoke local `http://127.0.0.1:11434/api/tags`
|
||||
|
||||
## Etat confirme
|
||||
|
||||
Dom indique que `ollama` pointe maintenant sur le DGX.
|
||||
|
||||
Codex a verifie le endpoint local `127.0.0.1:11434` et observe notamment:
|
||||
|
||||
- `gemma4:31b`
|
||||
- `t2a-gemma3-27b:latest`
|
||||
- `t2a-gemma3-27b-q4:latest`
|
||||
- `qwen2.5vl:7b-rpa`
|
||||
- `qwen3-vl:8b`
|
||||
|
||||
## Impact
|
||||
|
||||
- Le cadrage P1.w Qwen proposant `qwen3-vl:8b` comme fallback DGX-safe est maintenant
|
||||
coherent avec le endpoint actif.
|
||||
- `gemma4:31b` est bien present comme modele local, pas seulement `gemma4:31b-cloud`.
|
||||
- Ne pas transformer `gemma4:31b` en default sans benchmark: candidat P1.y qualite/latence.
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
# Resultat LeaBench statique — qwen2.5vl-rpa vs qwen3-vl
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-05 15:10 Europe/Paris
|
||||
- `Statut`: actif
|
||||
- `Contexte`: test sans controle desktop, benchmark statique uniquement
|
||||
|
||||
## Commandes lancees
|
||||
|
||||
Validation cas:
|
||||
|
||||
```bash
|
||||
.venv/bin/python tools/lea_bench.py \
|
||||
--cases benchmarks/computer_use/cases/leabench_extended_2026-05-24.jsonl \
|
||||
--repo-root . --json
|
||||
```
|
||||
|
||||
Resultat: `16` cas valides.
|
||||
|
||||
Benchmark qwen2.5vl:
|
||||
|
||||
```bash
|
||||
.venv/bin/python tools/lea_bench_ollama.py \
|
||||
--cases benchmarks/computer_use/cases/leabench_extended_2026-05-24.jsonl \
|
||||
--repo-root . \
|
||||
--model qwen2.5vl:7b-rpa \
|
||||
--output benchmarks/computer_use/predictions/qwen25vl_rpa_2026-06-05.jsonl
|
||||
```
|
||||
|
||||
Score:
|
||||
|
||||
- total: 16
|
||||
- answered: 16
|
||||
- correct: 9
|
||||
- dangerous: 6
|
||||
- accuracy: 0.5625
|
||||
|
||||
Benchmark qwen3-vl:
|
||||
|
||||
```bash
|
||||
.venv/bin/python tools/lea_bench_ollama.py \
|
||||
--cases benchmarks/computer_use/cases/leabench_extended_2026-05-24.jsonl \
|
||||
--repo-root . \
|
||||
--model qwen3-vl:8b \
|
||||
--timeout 90 \
|
||||
--output benchmarks/computer_use/predictions/qwen3vl_8b_2026-06-05.jsonl
|
||||
```
|
||||
|
||||
Interrompu apres environ 7 minutes: 10 predictions produites.
|
||||
|
||||
Score partiel:
|
||||
|
||||
- total: 16
|
||||
- answered: 10
|
||||
- missing: 6
|
||||
- correct: 5
|
||||
- dangerous: 0
|
||||
- answered_accuracy: 0.5
|
||||
|
||||
## Lecture
|
||||
|
||||
- `qwen2.5vl:7b-rpa`: trop dangereux pour conduire un test Lea live autonome;
|
||||
plusieurs clics hors region et clics dans mauvais etat.
|
||||
- `qwen3-vl:8b`: plus conservateur, zero clic dangereux sur le partiel, mais trop lent
|
||||
et abstient sur des cibles visibles.
|
||||
|
||||
## Decision provisoire
|
||||
|
||||
Ne pas lancer de test Lea humain autonome base sur ces sorties.
|
||||
|
||||
Prochaine etape recommandee:
|
||||
|
||||
1. analyser les predictions dangereuses de `qwen2.5vl:7b-rpa`;
|
||||
2. tester un prompt/parametrage plus strict ou un mode validation qui interdit les clics
|
||||
si confiance/region faible;
|
||||
3. garder `qwen3-vl:8b` comme juge de refus/validation possible, pas comme acteur direct
|
||||
tant que latence et abstention ne sont pas maitrisees.
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
# Diagnostic live 2026-06-05 — trace non revendiquée, pont Léa réparé, test long à relancer
|
||||
|
||||
- `Auteur`: Codex
|
||||
- `Date`: 2026-06-05 17:18 Europe/Paris
|
||||
- `Statut`: actif
|
||||
|
||||
## Contexte
|
||||
|
||||
Dom a signalé que le test Win+R évoqué par Codex était trop léger par rapport
|
||||
à la capacité attendue. Correction importante apportée ensuite par Dom : il
|
||||
n'a pas volontairement lancé d'enregistrement d'apprentissage pour cette trace.
|
||||
|
||||
## Constat factuel
|
||||
|
||||
Une trace locale existe sur Windows, mais elle n'est pas revendiquée comme
|
||||
enregistrement volontaire par Dom :
|
||||
|
||||
- session brute : `data/training/live_sessions/DESKTOP-58D5CAC_windows/sess_20260605T170738_8dbfd4/live_events.jsonl`
|
||||
- nom logué côté agent : `mon test win r`
|
||||
- événements : 19
|
||||
- actions : 6
|
||||
- extraction dry-run : 1 candidate `key_win_r_wait_explorer_exe`, `validator_status=would_pass`
|
||||
- clics de fin de session rejetés par segmentation
|
||||
|
||||
Cette trace est donc `non probante` et ne doit pas être utilisée comme preuve
|
||||
de test utilisateur. Elle prouve uniquement qu'une capture locale a pu être
|
||||
démarrée et finalisée techniquement.
|
||||
|
||||
## Blocage trouvé
|
||||
|
||||
La trace montre que le chemin `smart_tray` a lancé la capture locale, mais pas
|
||||
la session conversationnelle Léa-first côté `agent-chat`, car le venv Windows
|
||||
ne contenait pas `httpx`.
|
||||
|
||||
Log Windows :
|
||||
|
||||
```text
|
||||
2026-06-05 17:07:38 [agent_v1.ui.smart_tray] ERROR:
|
||||
Orchestrateur Léa injoignable : httpx non disponible — installer httpx>=0.27 sur le poste Windows.
|
||||
```
|
||||
|
||||
## Correction appliquée
|
||||
|
||||
Installation côté Windows :
|
||||
|
||||
```text
|
||||
httpx==0.28.1
|
||||
httpcore==1.0.9
|
||||
anyio==4.13.0
|
||||
```
|
||||
|
||||
Vérification :
|
||||
|
||||
- `import httpx` OK dans `C:\rpa_vision\.venv`
|
||||
- healthcheck Windows OK : `LeaInteractive` running, 1 arbre agent, capture server OK
|
||||
- préflight pont Windows -> agent-chat OK : session `learn_8182c363762e` créée en `waiting_user_stop`,
|
||||
puis annulée proprement
|
||||
|
||||
## Decision
|
||||
|
||||
La session `sess_20260605T170738_8dbfd4` doit être classée `trace non
|
||||
revendiquée / non probante`, pas `smoke test utilisateur` et pas `preuve
|
||||
workflow long`.
|
||||
|
||||
Prochaine preuve utile :
|
||||
|
||||
1. lancer explicitement un apprentissage Windows supervisé sur un scénario long mais sûr ;
|
||||
2. vérifier création simultanée :
|
||||
- session brute `live_events.jsonl` ;
|
||||
- session orchestrateur `agent_chat/state/learn_*.json` ;
|
||||
3. extraire en dry-run et vérifier plusieurs candidates/segments, pas seulement Win+R.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Recadrage — réutilisation des acquis Notepad / popups
|
||||
|
||||
- `Date`: 2026-06-05 18:09 Europe/Paris
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Décision
|
||||
|
||||
Ne plus présenter `Bloc-notes -> Fichier > Enregistrer / Enregistrer sous` ni la
|
||||
gestion des popups comme des apprentissages à refaire. Ce sont des acquis déjà
|
||||
présents. Le travail porte sur leur réutilisation fiable.
|
||||
|
||||
## Diagnostic
|
||||
|
||||
Le problème identifié n'était pas l'absence d'apprentissage, mais un pont cassé :
|
||||
|
||||
- le matcher ne scannait pas assez les workflows existants et n'indexait pas
|
||||
assez le texte des nodes/actions ;
|
||||
- le streaming server ne chargeait pas récursivement les workflows dans les
|
||||
sous-dossiers machine ;
|
||||
- donc une commande pouvait ne pas retrouver l'acquis, ou le retrouver côté chat
|
||||
puis être refusée côté replay.
|
||||
|
||||
## Correctifs posés
|
||||
|
||||
- `core/workflow/semantic_matcher.py` : scan récursif, extraction texte enrichie,
|
||||
synonymes, scoring tokens d'action.
|
||||
- `agent_v0/server_v1/api_stream.py` : chargement récursif et reload aligné.
|
||||
- `agent_v0/server_v1/stream_processor.py` : chargement récursif.
|
||||
|
||||
## Vérifications
|
||||
|
||||
- Tests ciblés : 93 passed.
|
||||
- Compilation Python : OK.
|
||||
- Services redémarrés : `rpa-streaming`, `rpa-agent-chat`.
|
||||
- Chat : 130 workflows.
|
||||
- Streaming : 146 fichiers scannés, 130 workflows en mémoire.
|
||||
- Recherche live `sauvegarde le fichier notepad` : retourne des workflows appris.
|
||||
- Le workflow `Bloc-notes, Explorateur et Python (5)` est connu du streaming.
|
||||
- Conversion hors exécution : actions replay non vides.
|
||||
|
||||
## Prochaine étape
|
||||
|
||||
Valider un test réel supervisé, sans réapprentissage :
|
||||
|
||||
1. commande naturelle ;
|
||||
2. sélection workflow existant ;
|
||||
3. acceptation streaming ;
|
||||
4. exécution supervisée ;
|
||||
5. gestion popup/dialogue ;
|
||||
6. preuves archivées.
|
||||
|
||||
## Délégation
|
||||
|
||||
- Claude : pont technique mémoire -> replay.
|
||||
- Qwen : quality gate réutilisation acquis / refus des tests trop légers.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,51 @@
|
||||
# Lancement parallèle — préflight replay et GPU/technos
|
||||
|
||||
- `Date`: 2026-06-05 20:37 Europe/Paris
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Décision
|
||||
|
||||
Dom demande de ne pas repousser. Les jobs 1 et 3 sont lancés en parallèle.
|
||||
|
||||
## Job 1 — Préflight replay non destructif
|
||||
|
||||
Objectif : prouver le pont `mémoire existante -> replay` sans risque live.
|
||||
|
||||
Claude reçoit GO pour implémenter :
|
||||
|
||||
`POST /api/v1/traces/stream/replay/preflight`
|
||||
|
||||
Le endpoint doit être strictement non destructif :
|
||||
|
||||
- pas de queue ;
|
||||
- pas de replay state ;
|
||||
- pas de replay lock ;
|
||||
- pas de clic ;
|
||||
- sortie actionnable pour QG.
|
||||
|
||||
Qwen reçoit le QG associé.
|
||||
|
||||
## Job 3 — GPU/technos
|
||||
|
||||
Objectif : vitesse, précision, qualité.
|
||||
|
||||
Constat initial Claude :
|
||||
|
||||
- Ollama/VLM/LLM tournent sur DGX via tunnel ;
|
||||
- RTX locale disponible ;
|
||||
- OCR/YOLO/SoM restent CPU ;
|
||||
- UI-TARS/InfiGUI, OmniParser/Florence2, `qwen3.5:9b`, ONNX doivent être clarifiés.
|
||||
|
||||
Travail lancé :
|
||||
|
||||
- baseline CPU/GPU ;
|
||||
- patch paramétrable, pas hardcodé ;
|
||||
- audit techno par techno avec bench avant rebranchement.
|
||||
|
||||
## Fichiers envoyés
|
||||
|
||||
- `docs/coordination/inbox_claude/2026-06-05_2037_codex-to-claude_GO-PREFLIGHT-REPLAY-et-GPU-TECHNOS.md`
|
||||
- `docs/coordination/inbox_qwen/2026-06-05_2037_codex-to-qwen_QG-PREFLIGHT-et-GPU-TECHNOS.md`
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,51 @@
|
||||
# Reprise loop coordination — 2026-06-08
|
||||
|
||||
- `Date`: 2026-06-08 09:48 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Decision
|
||||
|
||||
Le loop de coordination est remis en place par fichiers :
|
||||
|
||||
1. etat courant dans `docs/coordination/active/` ;
|
||||
2. relance courte dans `inbox_claude/` ;
|
||||
3. relance QG courte dans `inbox_qwen/` ;
|
||||
4. reponses attendues dans `inbox_codex/`.
|
||||
|
||||
## Etat repris
|
||||
|
||||
- Preflight replay non destructif : GO final Qwen.
|
||||
- Endpoint actif : `POST /api/v1/traces/stream/replay/preflight`.
|
||||
- Workflows connus cote chat/streaming : memoire existante reconnectee.
|
||||
- LeaBench live autonome : NO-GO, 6 clics dangereux observes sur `qwen2.5vl:7b-rpa`.
|
||||
- Test long Notepad : GO uniquement supervise, Dom devant Windows requis.
|
||||
- P1.g GPU cascade : patch Claude propose en worktree, non merge.
|
||||
- `qwen3.5:9b` : absent DGX, decision Dom attendue pull vs nettoyage.
|
||||
|
||||
## Messages remis dans le flux
|
||||
|
||||
- Claude :
|
||||
- `docs/coordination/inbox_claude/2026-06-08_0948_codex-to-claude_REPRISE-LOOP-P1G-GPU-ET-PREFLIGHT.md`
|
||||
- Qwen :
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_0948_codex-to-qwen_REPRISE-QG-P1G-GPU-ET-PREFLIGHT.md`
|
||||
|
||||
## Contrat de loop
|
||||
|
||||
- Claude repond dans `docs/coordination/inbox_codex/` avec ACK/NACK et etat du patch P1.g.
|
||||
- Qwen repond dans `docs/coordination/inbox_codex/` avec verdict QG P1.g et hygiene.
|
||||
- Codex lit les deux retours, arbitre, teste et recopie les decisions durables dans
|
||||
`active/`, `syntheses/` ou `registre/`.
|
||||
- Aucun replay live autonome sans Dom devant Windows et validation explicite.
|
||||
- Aucun merge du patch device sans decision Dom + QG.
|
||||
|
||||
## Prochaine action Codex
|
||||
|
||||
1. Attendre les retours Claude/Qwen dans `inbox_codex/`.
|
||||
2. Si Qwen confirme GO merge P1.g et Dom confirme, preparer merge supervise depuis
|
||||
`.claude/worktrees/agent-a4f390f410e00ad7c`.
|
||||
3. Si merge effectue, lancer bench GPU reel `auto` vs `cpu`, puis restart uniquement apres
|
||||
resultats.
|
||||
4. Si Dom veut avancer cote utilisateur, preparer test Notepad supervise, pas autonome.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,118 @@
|
||||
# Plan journee — Lea live, DGX, dashboard agents
|
||||
|
||||
- `Date`: 2026-06-08 11:02 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
- `Role Codex`: chef de projet / integration / arbitrage
|
||||
|
||||
## Reformulation Dom
|
||||
|
||||
Dom a fixe deux objectifs minimum pour aujourd'hui :
|
||||
|
||||
1. lancer des tests Lea grandeur nature ;
|
||||
2. commencer le transfert progressif du programme vers le DGX.
|
||||
|
||||
Suite a suivre aujourd'hui et cette semaine :
|
||||
|
||||
- dashboard fonctionnel ;
|
||||
- creation d'agents fonctionnelle ;
|
||||
- securite de creation/enrolement/revocation agent fonctionnelle ;
|
||||
- capture propre des actions/workflows depuis plusieurs machines ;
|
||||
- replay fonctionnel ;
|
||||
- apprentissage/modele correctement cable entre capture, workflow, matching, preflight, replay.
|
||||
|
||||
## Decisions de cadrage
|
||||
|
||||
- Pas de replay live autonome : tests grandeur nature = supervises, Dom devant Windows.
|
||||
- Preflight replay non destructif reste le sas obligatoire avant toute execution.
|
||||
- `gemma4:26b` est candidat acteur/juge grounding supervise sur DGX, pas active en default runtime.
|
||||
- `gemma4:12b` est candidat OCR/VQA leger, pas grounder Windows.
|
||||
- `qwen2.5vl:7b-rpa` reste dans la cascade temps reel tant que le runtime complet n'est pas qualifie.
|
||||
- UI-TARS DGX est casse actuellement : import Ollama sans `mmproj`, pas de capacite `vision`.
|
||||
- P1.g GPU device reste en attente GO Dom avant merge.
|
||||
|
||||
## Objectif fin de semaine
|
||||
|
||||
Demonstration defendable :
|
||||
|
||||
1. plusieurs machines peuvent s'enroler proprement ;
|
||||
2. elles capturent actions + screenshots + events sans melange d'identite machine ;
|
||||
3. les workflows appris sont stockes, indexes et matchables ;
|
||||
4. le replay sait retrouver le workflow, preflight non destructif, puis executer sous supervision ;
|
||||
5. les decisions IA/modeles sont tracees et remplacables par configuration ;
|
||||
6. dashboard permet de creer/voir/gerer les agents avec garde-fous de securite.
|
||||
|
||||
## Plan d'action du 2026-06-08
|
||||
|
||||
### P0 — coordination et capacites agents
|
||||
|
||||
- Claude doit fournir l'inventaire de ses agents/subagents disponibles, roles, outils, plugins/skills, et manques.
|
||||
- Qwen doit fournir l'inventaire equivalent cote QG/revue.
|
||||
- Codex active ses propres sous-agents pour audits paralleles :
|
||||
- protocole tests Lea live ;
|
||||
- transfert DGX ;
|
||||
- dashboard/creation agents/securite.
|
||||
- Chaque agent doit proposer les plugins/skills manquants avant de bloquer.
|
||||
|
||||
### P1 — tests Lea grandeur nature
|
||||
|
||||
But : une preuve supervisee, pas autonome.
|
||||
|
||||
Pipeline attendu :
|
||||
|
||||
1. verifier Windows agent + `httpx` + connexion agent-chat ;
|
||||
2. lancer apprentissage explicitement par Dom ;
|
||||
3. capturer scenario long mais safe ;
|
||||
4. verifier session brute `live_events.jsonl` + session orchestrateur `agent_chat/state/learn_*.json` ;
|
||||
5. extraire/convertir en workflow ;
|
||||
6. matcher par commande naturelle ;
|
||||
7. appeler `POST /api/v1/traces/stream/replay/preflight` ;
|
||||
8. lancer replay supervise si preflight OK ;
|
||||
9. archiver preuves et verdict.
|
||||
|
||||
Critere GO journee : au moins un scenario long safe capture -> workflow connu -> preflight OK -> replay supervise demarre sans action dangereuse.
|
||||
|
||||
### P2 — transfert DGX
|
||||
|
||||
But : commencer sans casser le poste local.
|
||||
|
||||
Phases :
|
||||
|
||||
1. inventaire services/ports/env/modeles/data ;
|
||||
2. verifier DGX Ollama 0.30.6 + tags + VRAM + acces systemd ;
|
||||
3. identifier chemins a synchroniser et chemins a exclure ;
|
||||
4. creer plan de deploiement non destructif ;
|
||||
5. verifier imports modele : Gemma4 OK, UI-TARS KO sans `mmproj` ;
|
||||
6. definir rollback et stop conditions.
|
||||
|
||||
Critere GO journee : checklist DGX + premiere synchro ou dry-run documente + liste des branchements manquants.
|
||||
|
||||
### P3 — dashboard agents + securite
|
||||
|
||||
But : transformer le dashboard en outil operable multi-machine.
|
||||
|
||||
Questions bloqueuses :
|
||||
|
||||
- creation agent : qui peut creer ?
|
||||
- jeton d'enrolement : generation, expiration, usage unique ?
|
||||
- identite machine : stable, non forgeable ?
|
||||
- revocation : immediate ?
|
||||
- affichage dashboard : etat agent, derniere capture, workflows, erreurs ?
|
||||
- separation multi-machine : pas de melange de sessions/workflows.
|
||||
|
||||
Critere GO semaine : creation/enrolement/revocation agent testables et visibles dans le dashboard.
|
||||
|
||||
## Delegations envoyees
|
||||
|
||||
- Claude :
|
||||
- `docs/coordination/inbox_claude/2026-06-08_1102_codex-to-claude_MISSION-JOURNEE-lea-live-dgx-dashboard-agents.md`
|
||||
- Qwen :
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1102_codex-to-qwen_QG-JOURNEE-lea-live-dgx-dashboard-agents.md`
|
||||
|
||||
## Attendus de retour
|
||||
|
||||
- Reponses Claude/Qwen dans `docs/coordination/inbox_codex/`.
|
||||
- Une synthese Codex apres retours agents.
|
||||
- Aucun changement runtime non reversible sans GO Dom.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,69 @@
|
||||
# P0 UI-TARS — reparation obligatoire, pas abandon
|
||||
|
||||
- `Date`: 2026-06-08 11:16 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
- `Decision Dom`: UI-TARS est un point essentiel du projet ; Claude doit tester et reparer.
|
||||
|
||||
## Constat repris
|
||||
|
||||
Claude a prouve que l'import Ollama actuel `0000/ui-tars-1.5-7b-q8_0:7b` est aveugle :
|
||||
|
||||
- pas de capacite `vision` ;
|
||||
- `projector_info = {}` ;
|
||||
- requetes image en HTTP 500/400 ;
|
||||
- modele utilise dans `core/execution/input_handler.py` niveau 2 grounding ;
|
||||
- present aussi dans `core/detection/vlm_config.py` fallback.
|
||||
|
||||
Qwen confirme que l'echec est silencieux (`logger.debug`) et que le niveau 2 est casse.
|
||||
|
||||
## Arbitrage Codex
|
||||
|
||||
UI-TARS ne doit pas etre abandonne.
|
||||
|
||||
Court terme :
|
||||
|
||||
- eviter un fallback silencieux en 500 ;
|
||||
- rendre l'echec visible (`warning`) ;
|
||||
- ne pas laisser croire que UI-TARS fonctionne si `capabilities` ne contient pas `vision`.
|
||||
|
||||
Moyen terme immediat :
|
||||
|
||||
- reparer l'import UI-TARS avec le `mmproj` correspondant ;
|
||||
- verifier `capabilities` contient `vision` et `projector_info` non vide ;
|
||||
- relancer le bench LeaBench 16 cas ;
|
||||
- comparer a `gemma4:26b`, `gemma4:31b`, `qwen2.5vl:7b-rpa`.
|
||||
|
||||
## Contrat de reparation
|
||||
|
||||
Claude pilote la reparation technique :
|
||||
|
||||
1. identifier source fiable du GGUF UI-TARS + `mmproj` compatible ;
|
||||
2. creer un Modelfile DGX propre ;
|
||||
3. importer sous un tag distinct, ne pas ecraser sans preuve ;
|
||||
4. sanity image `/api/chat` ;
|
||||
5. verifier `/api/show` ;
|
||||
6. bench UI-TARS natif `start_box` 0-1000 ;
|
||||
7. rapporter latence, accuracy, dangereux, cas Save As.
|
||||
|
||||
Qwen fait le QG :
|
||||
|
||||
1. verifier que le tag repare est vraiment multimodal ;
|
||||
2. verifier qu'aucun echec silencieux ne reste ;
|
||||
3. verifier que l'activation runtime reste conditionnee a bench + GO Dom ;
|
||||
4. verifier que le fallback temporaire ne supprime pas durablement UI-TARS du projet.
|
||||
|
||||
## Non-decisions
|
||||
|
||||
- Pas de suppression durable de UI-TARS comme techno projet.
|
||||
- Pas de promotion Gemma4 en remplacement definitif de UI-TARS.
|
||||
- Pas d'activation runtime UI-TARS tant que le bench repare n'est pas vert.
|
||||
|
||||
## Messages envoyes
|
||||
|
||||
- Claude :
|
||||
- `docs/coordination/inbox_claude/2026-06-08_1116_codex-to-claude_GO-P0-REPARATION-UITARS-MMProj.md`
|
||||
- Qwen :
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1116_codex-to-qwen_QG-P0-REPARATION-UITARS-MMProj.md`
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,104 @@
|
||||
# Audit anti-bordelisation — architecture runtime reelle
|
||||
|
||||
- `Date`: 2026-06-08 11:41 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
- `Motif`: Dom signale un risque systemique : trop de code essentiel non branche, navigation trop locale.
|
||||
|
||||
## Diagnostic de depart
|
||||
|
||||
Le cas UI-TARS montre une dette d'architecture :
|
||||
|
||||
- une brique essentielle existe ;
|
||||
- elle est appelee dans un chemin secondaire ;
|
||||
- elle n'est pas dans le chemin critique replay Lea ;
|
||||
- son echec est silencieux ;
|
||||
- les tests passent quand meme car les chemins testes ne l'exercent pas.
|
||||
|
||||
Ce schema peut exister ailleurs : dashboard, creation agents, apprentissage, replay, modeles,
|
||||
securite, transfert DGX.
|
||||
|
||||
## Objectif de l'audit
|
||||
|
||||
Produire une carte de verite runtime :
|
||||
|
||||
| Domaine | Contrat produit | Code present | Code reellement appele | Tests | Risque |
|
||||
|---|---|---|---|---|---|
|
||||
|
||||
La question centrale n'est plus "est-ce que le code existe ?", mais :
|
||||
|
||||
- est-il dans le chemin runtime reel ?
|
||||
- echoue-t-il silencieusement ?
|
||||
- est-il protege par test ?
|
||||
- est-il visible dans dashboard/logs/health ?
|
||||
- est-il compatible multi-machine/DGX ?
|
||||
|
||||
## Lots d'audit
|
||||
|
||||
### Lot 1 — Runtime Lea / replay / apprentissage
|
||||
|
||||
- capture Windows ;
|
||||
- agent-chat learn ;
|
||||
- live sessions ;
|
||||
- extraction competences/workflows ;
|
||||
- matcher ;
|
||||
- preflight ;
|
||||
- replay supervise ;
|
||||
- replay autonome interdit.
|
||||
|
||||
### Lot 2 — Grounding/modeles
|
||||
|
||||
- `resolve_engine` vrai chemin demo ;
|
||||
- `input_handler`/VWB chemin secondaire ;
|
||||
- UI-TARS, InfiGUI, OmniParser, Gemma, qwen ;
|
||||
- fallbacks ;
|
||||
- health modeles ;
|
||||
- tests LeaBench et runtime.
|
||||
|
||||
### Lot 3 — Dashboard agents securite
|
||||
|
||||
- creation agent ;
|
||||
- enrolement ;
|
||||
- token par poste vs token global ;
|
||||
- revocation ;
|
||||
- usurpation machine_id ;
|
||||
- auth dashboard/VWB/agent-chat ;
|
||||
- endpoints debug/secrets.
|
||||
|
||||
### Lot 4 — Multi-machine / data
|
||||
|
||||
- separation sessions/workflows par machine ;
|
||||
- choix machine explicite ;
|
||||
- chemins data ;
|
||||
- replay sur mauvais poste ;
|
||||
- preuves d'audit.
|
||||
|
||||
### Lot 5 — DGX migration
|
||||
|
||||
- services/ports ;
|
||||
- systemd/user/path ;
|
||||
- env/secrets ;
|
||||
- modeles Ollama ;
|
||||
- data a copier vs regenerer ;
|
||||
- stop conditions.
|
||||
|
||||
## Mandat Qwen
|
||||
|
||||
Qwen recoit un lot transverse de contre-audit. Il doit challenger Claude et Codex, pas seulement ACK.
|
||||
|
||||
Message :
|
||||
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1141_codex-to-qwen_MANDAT-AUDIT-ANTI-BORDELISATION.md`
|
||||
|
||||
## Regle
|
||||
|
||||
Toute brique critique doit avoir :
|
||||
|
||||
1. chemin runtime identifie ;
|
||||
2. healthcheck ou log visible ;
|
||||
3. test ciblant le chemin reel ;
|
||||
4. fallback explicite ;
|
||||
5. statut dashboard ou preuve d'audit ;
|
||||
6. owner et deadline.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,114 @@
|
||||
# Constats initiaux audit global — P0 anti-bordelisation
|
||||
|
||||
- `Date`: 2026-06-08 11:45 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Constat general
|
||||
|
||||
Le projet n'a pas seulement des bugs isoles. Il presente plusieurs risques de coherence :
|
||||
|
||||
- code essentiel present mais pas dans le chemin runtime reel ;
|
||||
- fallbacks silencieux ;
|
||||
- securite agent encore trop globale ;
|
||||
- dashboard/VWB/agent-chat pas alignes sur un modele de securite unique ;
|
||||
- migration DGX non stabilisee entre chemins `/home/dom` et `/opt/rpa_vision_v3` ;
|
||||
- tests existants qui valident des chemins secondaires ou partiels.
|
||||
|
||||
## P0 identifies
|
||||
|
||||
### 1. UI-TARS / grounding
|
||||
|
||||
Etat :
|
||||
|
||||
- ancien tag `0000/ui-tars-1.5-7b-q8_0:7b` aveugle sans `mmproj` ;
|
||||
- reimport `uitars-1.5-7b-vision` reussi, mais bench mauvais : 0,375 accuracy, 9 dangereux ;
|
||||
- cause racine : UI-TARS etait dans `input_handler`, pas dans le chemin critique replay Lea
|
||||
`resolve_engine`.
|
||||
|
||||
Action :
|
||||
|
||||
- gate `capabilities: vision` + warning, pas d'echec silencieux ;
|
||||
- ne pas abandonner UI-TARS, mais ne pas l'activer en runtime sante ;
|
||||
- continuer evaluation moteurs propres vLLM/Transformers/InfiGUI/Holo/Qwen3-VL ;
|
||||
- tout grounder retenu doit etre branche dans le vrai chemin `resolve_engine`, pas seulement VWB.
|
||||
|
||||
### 2. Tests Lea grandeur nature
|
||||
|
||||
Etat :
|
||||
|
||||
- preflight non destructif GO ;
|
||||
- test long Notepad GO seulement supervise ;
|
||||
- replay autonome NO-GO ;
|
||||
- protocole live existe : capture explicite, `live_events.jsonl`, `learn_*.json`, dry-run,
|
||||
preflight, replay supervise.
|
||||
|
||||
Action :
|
||||
|
||||
- executer uniquement avec Dom devant Windows ;
|
||||
- archiver preuves dans la session ;
|
||||
- stop si workflow inconnu, `n_actions=0`, popup non detectee, machine/focus incertains.
|
||||
|
||||
### 3. Dashboard agents / securite
|
||||
|
||||
Etat :
|
||||
|
||||
- token global agent retourne a l'enrolement ;
|
||||
- revocation contournee possible par usurpation `machine_id` ;
|
||||
- token logge au startup streaming ;
|
||||
- endpoints debug/env exposent trop ;
|
||||
- VWB et agent-chat ont des surfaces non authentifiees ;
|
||||
- VWB peut choisir une machine Windows active si `machine_id` manque.
|
||||
|
||||
Action P0 :
|
||||
|
||||
- token par poste hashe en DB ;
|
||||
- revocation effective liee au token, pas seulement au `machine_id` declare ;
|
||||
- suppression/neutralisation debug secrets ;
|
||||
- interdiction execution sans `machine_id` explicite ;
|
||||
- tests enroll/revoke/usurpation/double-enroll.
|
||||
|
||||
### 4. DGX migration
|
||||
|
||||
Etat :
|
||||
|
||||
- branche active sale ;
|
||||
- `data` environ 28G ;
|
||||
- systemd actuel hardcode `/home/dom`, user `dom`, `.env.local` ;
|
||||
- scripts prod visent `/opt/rpa_vision_v3`, user `rpa`, env `/etc/rpa_vision_v3/...` ;
|
||||
- `svc.sh` attend des noms d'unites differents de `deploy/systemd`.
|
||||
|
||||
Action P0 :
|
||||
|
||||
- choisir chemin cible unique ;
|
||||
- dry-run de copie, pas transfert aveugle ;
|
||||
- secrets rotatifs ;
|
||||
- verifier Ollama 0.30.6 + modeles ;
|
||||
- exclure venv/node_modules/logs/caches ;
|
||||
- health checks ports `8000/5001/5002/5004/5005/5006/5099/3002/11434`.
|
||||
|
||||
### 5. Qwen
|
||||
|
||||
Qwen a recu un mandat transverse :
|
||||
|
||||
- trouver les autres "UI-TARS bis" ;
|
||||
- carte runtime reelle ;
|
||||
- bloquants fin de semaine ;
|
||||
- plan de tests des chemins reels ;
|
||||
- utiliser ses subagents.
|
||||
|
||||
Fichier :
|
||||
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1141_codex-to-qwen_MANDAT-AUDIT-ANTI-BORDELISATION.md`
|
||||
|
||||
## Regle immediate
|
||||
|
||||
Aucun nouveau patch fonctionnel ne doit etre accepte sans repondre :
|
||||
|
||||
1. est-ce le chemin runtime reel ?
|
||||
2. quel test l'exerce ?
|
||||
3. que se passe-t-il si la brique echoue ?
|
||||
4. est-ce visible dans logs/health/dashboard ?
|
||||
5. comment on rollback ?
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,98 @@
|
||||
# Chantier DGX — installation propre et complete
|
||||
|
||||
- `Date`: 2026-06-08 11:56 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
- `Priorite`: P0/P1 semaine
|
||||
|
||||
## Decision
|
||||
|
||||
Le transfert DGX n'est pas un simple `rsync`.
|
||||
|
||||
Il devient un chantier dedie : **installation propre et complete du programme sur le DGX**,
|
||||
avec services, env, modeles, donnees, securite, dashboard, agents et healthchecks.
|
||||
|
||||
## Owners
|
||||
|
||||
- **Codex** : chef de projet / architecture cible / arbitrage chemins, services, ordre d'activation.
|
||||
- **Claude** : lead implementation DGX install. Produit le plan executable, scripts/diffs proposes,
|
||||
dry-run, puis implementation sous GO.
|
||||
- **Qwen** : QG migration. Valide systemd, env, secrets, stop conditions, tests et absence de regression.
|
||||
- **Dom** : GO sur decisions irreversibles : chemin cible, user systemd, rotation secrets, activation modeles.
|
||||
|
||||
## Ce qui est deja pris en compte
|
||||
|
||||
Source de verite actuelle :
|
||||
|
||||
- ports/services : `services.conf` ;
|
||||
- audit DGX Codex subagent : services, donnees, systemd, secrets, stop conditions ;
|
||||
- Qwen audit : incoherences `/home/dom` vs `/opt/rpa_vision_v3`, `.env.local` vs `/etc/...`,
|
||||
`User=dom`, noms d'unites, `vram_orchestrator`, chemins absolus ;
|
||||
- Claude : DGX SSH + sudo OK, Ollama 0.30.6, Gemma4 12b/26b/31b, UI-TARS reimporte/bench.
|
||||
|
||||
## Decisions a trancher avant installation complete
|
||||
|
||||
1. Chemin cible DGX :
|
||||
- option A : `/opt/rpa_vision_v3` avec user `rpa` ;
|
||||
- option B : `/home/dom/ai/rpa_vision_v3` pour compat court terme.
|
||||
2. Env cible :
|
||||
- prod : `/etc/rpa_vision_v3/rpa_vision_v3.env` ;
|
||||
- ne pas copier `.env.local` tel quel.
|
||||
3. Services :
|
||||
- aligner `deploy/systemd/*.service` avec `services.conf` ;
|
||||
- supprimer mismatch `rpa-dashboard.service` vs `rpa-vision-v3-dashboard.service`.
|
||||
4. Secrets :
|
||||
- rotation obligatoire des tokens deja exposes/logges ;
|
||||
- pas de secret dans repo, ZIP agent, logs ou debug endpoints.
|
||||
5. Donnees :
|
||||
- copier workflows/DB necessaires ;
|
||||
- ne pas copier caches, venv, node_modules, logs bruts inutiles ;
|
||||
- traiter `data/training/live_sessions` comme sensible.
|
||||
6. Modeles :
|
||||
- default runtime conserve `qwen2.5vl:7b-rpa` ;
|
||||
- `gemma4:26b` seulement profil supervise apres GO ;
|
||||
- UI-TARS repare mais bench dangereux en Ollama, pas actif sante ;
|
||||
- futur grounder a brancher dans `resolve_engine`.
|
||||
|
||||
## Livrables demandes
|
||||
|
||||
Claude doit produire :
|
||||
|
||||
1. `PLAN-INSTALL-DGX-PROPRE-COMPLETE.md` ;
|
||||
2. checklist preflight DGX ;
|
||||
3. proposition de chemin/user/env cible ;
|
||||
4. dry-run copy/sync avec inclusions/exclusions ;
|
||||
5. plan systemd cible ;
|
||||
6. plan secrets/rotation ;
|
||||
7. healthcheck post-install ;
|
||||
8. rollback.
|
||||
|
||||
Qwen doit produire :
|
||||
|
||||
1. `QG-INSTALL-DGX-PROPRE.md` ;
|
||||
2. stop conditions ;
|
||||
3. tests d'acceptance ;
|
||||
4. revue des scripts/diffs Claude avant execution.
|
||||
|
||||
## Criteres GO installation DGX
|
||||
|
||||
- `ollama --version` DGX = 0.30.6 ou plus ;
|
||||
- tags requis presents : `qwen2.5vl:7b-rpa`, `gemma4:12b`, `gemma4:26b`, `gemma4:31b` ;
|
||||
- UI-TARS non active tant que bench sante KO ;
|
||||
- services verifies : API `8000`, dashboard `5001`, VWB backend `5002`, agent-chat `5004`,
|
||||
streaming `5005`, session-cleaner `5006`, worker `5099`, VWB frontend `3002` ;
|
||||
- env lu depuis emplacement cible, sans fallback dev ;
|
||||
- secrets forts et rotatifs ;
|
||||
- dashboard accessible uniquement selon politique auth ;
|
||||
- agents multi-machine enroles avec securite minimale ;
|
||||
- preflight replay OK ;
|
||||
- test Lea supervise OK.
|
||||
|
||||
## Messages envoyes
|
||||
|
||||
- Claude :
|
||||
- `docs/coordination/inbox_claude/2026-06-08_1156_codex-to-claude_MISSION-INSTALL-DGX-PROPRE-COMPLETE.md`
|
||||
- Qwen :
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1156_codex-to-qwen_QG-INSTALL-DGX-PROPRE-COMPLETE.md`
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,65 @@
|
||||
# Parallelisation stricte — agents et workstreams
|
||||
|
||||
- `Date`: 2026-06-08 11:59 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Decision
|
||||
|
||||
On passe en execution parallele controlee. Les lots sont independants tant qu'ils ne changent pas
|
||||
le runtime sans GO.
|
||||
|
||||
Regle : chaque lane produit un livrable court, QG separe, puis integration Codex.
|
||||
|
||||
## Lanes paralleles
|
||||
|
||||
| Lane | Sujet | Owner execution | QG | Peut avancer sans GO runtime ? | Livrable |
|
||||
|---|---|---|---|---|---|
|
||||
| A | Securite agents multi-machine | Claude + agent Codex secu | Qwen | Oui, plan/diff/tests | PATCH/PLAN tokens par machine |
|
||||
| B | Installation DGX propre | Claude | Qwen | Oui, plan/dry-run | PLAN-INSTALL-DGX |
|
||||
| C | Tests Lea grandeur nature | Claude | Qwen | Oui, protocole ; execution avec Dom | PLAN-LEA-LIVE |
|
||||
| D | Dashboard agents/secu | Claude | Qwen | Oui, audit/diff propose | AUDIT-DASHBOARD-AGENTS-SECU |
|
||||
| E | Grounding/modeles vrais chemins | Claude | Qwen | Oui, bench/audit ; activation sous GO | SOTA + cablage resolve_engine |
|
||||
| F | Code mort / UI-TARS bis | Qwen lead audit | Codex | Oui, audit | Carte runtime + suppressions proposees |
|
||||
| G | P1.g GPU device | Claude | Qwen | Non merge sans GO Dom | Bench auto/cpu apres GO |
|
||||
|
||||
## Travail deja lance
|
||||
|
||||
- Claude a pris le lead DGX install et annonce 3 agents :
|
||||
- `PLAN-INSTALL-DGX-PROPRE-COMPLETE`
|
||||
- `PLAN-LEA-LIVE-GRANDEUR-NATURE`
|
||||
- `AUDIT-DASHBOARD-AGENTS-SECU`
|
||||
- Qwen a livre :
|
||||
- carte runtime anti-bordelisation ;
|
||||
- P0 bloquants fin de semaine ;
|
||||
- plan tests chemins reels ;
|
||||
- QG gate vision.
|
||||
- Codex a lance un sous-agent securite agents :
|
||||
- token par machine ;
|
||||
- enroll/revoke ;
|
||||
- auth agent-chat/VWB ;
|
||||
- machine_id explicite.
|
||||
|
||||
## Relance Qwen
|
||||
|
||||
Qwen doit parallelliser ses QG :
|
||||
|
||||
- QG securite agents ;
|
||||
- QG install DGX ;
|
||||
- QG Lea live ;
|
||||
- QG dashboard agents ;
|
||||
- QG grounding vrais chemins.
|
||||
|
||||
Message :
|
||||
|
||||
- `docs/coordination/inbox_qwen/2026-06-08_1159_codex-to-qwen_PARALLELISATION-QG-LANES.md`
|
||||
|
||||
## Stop conditions
|
||||
|
||||
- Pas de patch runtime majeur sans QG.
|
||||
- Pas de replay live autonome.
|
||||
- Pas d'installation DGX destructive sans GO Dom.
|
||||
- Pas d'activation modele sans bench.
|
||||
- Pas de service expose sans auth minimale.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,91 @@
|
||||
# Point etat — parallelisation 2026-06-08 15:01
|
||||
|
||||
- `Date`: 2026-06-08 15:01 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Etat global
|
||||
|
||||
La parallelisation est effective.
|
||||
|
||||
- Claude produit les plans et diffs techniques.
|
||||
- Qwen produit les QG par lane.
|
||||
- Codex centralise, arbitre et maintient les stop conditions.
|
||||
- Dom garde les GO irreversibles.
|
||||
|
||||
## Lanes
|
||||
|
||||
| Lane | Sujet | Etat | Verdict |
|
||||
|---|---|---|---|
|
||||
| A | Securite agents multi-machine | Audit + QG livres | NO-GO en l'etat |
|
||||
| B | Installation DGX propre | Plan Claude + QG Qwen livres | GO provisoire, choix chemin requis |
|
||||
| C | Test Lea grandeur nature | Protocole livre + QG valide | GO provisoire, Dom devant Windows requis |
|
||||
| D | Dashboard agents/secu | Audit + QG livres | NO-GO tant que securite P0 non corrigee |
|
||||
| E | Grounding/modeles vrais chemins | Gate vision committe, bench vLLM livre | Qwen3-VL-4B via vLLM candidat |
|
||||
| F | Code mort / UI-TARS bis | Carte Qwen livree | nettoyage requis |
|
||||
| G | P1.g GPU device | GO provisionnel precedent | en attente GO Dom + bench |
|
||||
|
||||
## Points acquis
|
||||
|
||||
### UI-TARS / grounders
|
||||
|
||||
- Ancien UI-TARS Ollama etait aveugle sans `mmproj`.
|
||||
- Reimport vision reussi, mais bench mauvais : 0,375 accuracy, 9 dangereux / 16.
|
||||
- UI-TARS n'est pas active en runtime sante.
|
||||
- Gate vision commit `d00fe7b00` valide Qwen : plus de 500 silencieux dans `input_handler`.
|
||||
- Bench vLLM DGX : `Qwen3-VL-4B-Instruct` gagne pour le grounding candidat :
|
||||
- 0,875 accuracy ;
|
||||
- 1 dangereux / 16 ;
|
||||
- cible demo 2/2 ;
|
||||
- latence ~1,1 s ;
|
||||
- a cabler dans `resolve_engine`, pas `intelligent_executor`.
|
||||
- Aucun grounder standalone n'est considere sur : cascade de validation obligatoire.
|
||||
|
||||
### DGX
|
||||
|
||||
- Plan installation propre livre par Claude.
|
||||
- QG Qwen donne GO provisoire.
|
||||
- Bloqueur Dom : choisir chemin cible :
|
||||
- court terme : `/home/aivanov/ai/rpa_vision_v3` user `aivanov` ;
|
||||
- propre : `/opt/rpa_vision_v3` user `rpa`.
|
||||
- Donnees : ne pas copier les 28G de `data/training/live_sessions`; copier allow-list.
|
||||
- Services : 4 unites manquantes identifiees, systemd actuel hardcode `/home/dom`.
|
||||
- Secrets : rotation obligatoire.
|
||||
|
||||
### Lea live
|
||||
|
||||
- Protocole grandeur nature livre.
|
||||
- GO provisoire pour scenario Notepad/Explorateur/Easily safe.
|
||||
- Execution seulement si Dom devant Windows.
|
||||
- Preflight non destructif obligatoire.
|
||||
- Replay autonome reste NO-GO.
|
||||
|
||||
### Dashboard / agents / securite
|
||||
|
||||
- Fleet/enrolement existe et est wired.
|
||||
- Modele de securite actuel = token global.
|
||||
- Revocation contournable par usurpation `machine_id`.
|
||||
- Agent-chat et VWB backend restent trop ouverts.
|
||||
- Qwen valide les workpacks :
|
||||
- WP-A dashboard fail-closed secrets ;
|
||||
- WP-B bloquer reenrolement poste revoque ;
|
||||
- WP-D stale last_seen ;
|
||||
- WP-E ne plus mettre token en clair dans ZIP ;
|
||||
- WP-C token par poste, plus gros morceau.
|
||||
|
||||
## Decisions Dom requises
|
||||
|
||||
1. DGX : Option A court terme (`/home/aivanov/...`) ou Option B propre (`/opt/...` + user `rpa`) ?
|
||||
2. Autoriser Claude a lancer WP-A puis WP-B securite agents ?
|
||||
3. Fenetre pour test Lea grandeur nature : Dom devant Windows ?
|
||||
4. P1.g GPU : toujours en attente de GO explicite avant merge/bench.
|
||||
|
||||
## Stop conditions actives
|
||||
|
||||
- Pas d'installation DGX destructive sans GO Dom.
|
||||
- Pas de multi-machine defendable tant que securite agents P0 non corrigee.
|
||||
- Pas de replay autonome.
|
||||
- Pas d'activation modele sans bench + QG + GO Dom.
|
||||
- Pas de service expose sans auth minimale.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,51 @@
|
||||
# Decisions Dom — GO operationnels 2026-06-08 15:15
|
||||
|
||||
- `Date`: 2026-06-08 15:15 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Source`: reponse Dom "option A pour le 1 ok pour le 2 et 4 et pour le 3 quand tu veux"
|
||||
- `Statut`: actif, source de verite jusqu'a contre-ordre Dom
|
||||
|
||||
## Decisions confirmees
|
||||
|
||||
1. **DGX / installation propre**
|
||||
- Decision: **Option A**.
|
||||
- Cible court terme: `/home/aivanov/ai/rpa_vision_v3`.
|
||||
- User: `aivanov`.
|
||||
- Objectif: demarrer transfert/bootstrap DGX aujourd'hui sans contaminer les donnees ni les secrets.
|
||||
- Option B (`/opt/rpa_vision_v3`, user systeme `rpa`) reste cible propre post-POC, pas le chemin d'aujourd'hui.
|
||||
|
||||
2. **Securite agents / dashboard**
|
||||
- Decision: **GO pour WP-A et WP-B**.
|
||||
- WP-A: dashboard fail-closed si secret Basic manquant en prod.
|
||||
- WP-B: bloquer le re-enrolement sous nouveau `machine_id` en contexte demo/locked.
|
||||
- Multi-machine reste **NO-GO** tant que les P0 securite ne sont pas corriges et valides QG.
|
||||
|
||||
3. **Test Lea grandeur nature**
|
||||
- Decision: **fenetre ouverte quand Codex/Claude jugent le preflight vert**.
|
||||
- Condition non negociable: Dom devant le poste Windows cible.
|
||||
- Scope: capture Shadow supervisee, Notepad/Explorateur/Easily lecture seule, pas de replay autonome.
|
||||
|
||||
4. **P1.g GPU device**
|
||||
- Decision: **GO merge/bench**.
|
||||
- Objectif: brancher la selection GPU/CPU proprement, verifier tests, bench, rollback env.
|
||||
- Activation runtime large seulement apres QG + preuves.
|
||||
|
||||
## Priorites d'execution
|
||||
|
||||
| Priorite | Sujet | Owner execution | Owner QG | Gate |
|
||||
|---|---|---|---|---|
|
||||
| P0 | WP-A/WP-B securite | Claude | Qwen | Tests + QG GO |
|
||||
| P0 | DGX Option A bootstrap | Claude | Qwen | Pas de secrets, pas de rsync massif, pas de service expose |
|
||||
| P0 | Preflight Lea live | Claude + Codex | Qwen | G1-G6 verts + Dom present |
|
||||
| P1 | P1.g GPU merge/bench | Claude | Qwen | Tests + bench + rollback |
|
||||
|
||||
## Stop conditions maintenues
|
||||
|
||||
- Pas de replay autonome.
|
||||
- Pas d'installation destructive ni suppression sur DGX.
|
||||
- Pas de copie de `data/training/live_sessions`.
|
||||
- Pas de secret ecrit en clair dans un rapport, un log ou un ZIP.
|
||||
- Pas d'activation modele/grounder sans bench + QG + GO Dom explicite.
|
||||
- Pas de multi-machine defendable tant que le token global et les endpoints non proteges restent en P0.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,70 @@
|
||||
# Additif — transfert des donnees entrainees vers DGX
|
||||
|
||||
- `Date`: 2026-06-08 15:43 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Source`: clarification Dom "les donnees entrainees seront bien transferees ?"
|
||||
- `Statut`: actif
|
||||
|
||||
## Decision
|
||||
|
||||
Oui, les **donnees entrainees utiles au runtime** seront transferees vers le DGX.
|
||||
|
||||
La regle "sans data" signifiait : **pas de `data/` brut dans Git, pas de rsync massif, pas de secrets, pas de captures sensibles non triees**.
|
||||
|
||||
Elle ne signifie pas que le DGX repart sans acquis.
|
||||
|
||||
## Paquet a transferer hors Git
|
||||
|
||||
Transfert par archive/manifeste controle, avec checksum, apres revue QG :
|
||||
|
||||
- `visual_workflow_builder/backend/instance/workflows.db` — workflows demo/runtime.
|
||||
- `data/training/workflows/` — workflows entraines.
|
||||
- `data/training/faiss_index/` — index de recherche/matching.
|
||||
- `data/training/embeddings/` — embeddings entraines.
|
||||
- `data/training/screen_states/` — etats ecran appris.
|
||||
- `data/embeddings/` — embeddings runtime/prototypes.
|
||||
- `data/visual_embeddings/` — signatures visuelles.
|
||||
- `data/competences/` — competences observees/candidates.
|
||||
- `data/correction_packs/` — corrections apprises.
|
||||
- `data/templates/templates.json` — templates operationnels.
|
||||
- `data/workflows_ir/` — representations IR de workflows si presentes.
|
||||
- `data/learning/target_memory.db` et `data/learning/element_signatures.db` — memoires cibles/signatures, si elles ne contiennent pas de donnees sensibles en clair.
|
||||
|
||||
## Quarantaine / transfert selectif
|
||||
|
||||
Ces repertoires ne doivent pas partir automatiquement :
|
||||
|
||||
- `data/training/live_sessions/` — 28 Go de captures reelles, potentiellement sensibles.
|
||||
- `data/training/sessions/`.
|
||||
- `data/training/uploads/`.
|
||||
- `data/runner_captures/`, `data/screenshots/`, `data/sessions/`, `data/streaming_sessions/`.
|
||||
- logs, audits, erreurs contenant captures ou payloads applicatifs.
|
||||
|
||||
Si une partie de ces donnees est necessaire pour re-entrainement ou benchmark, elle doit etre transferee en **lot selectif anonymise**, avec manifeste, pas dans le paquet runtime initial.
|
||||
|
||||
## Interdits
|
||||
|
||||
- Pas de commit Git contenant `data/`.
|
||||
- Pas de `.env`, `.env.local`, token, mot de passe, cle Fernet/API dans l'archive.
|
||||
- Pas de DB fleet/dev brute si elle contient identites machines/tokens : initialiser le registry DGX proprement ou scrubber table par table.
|
||||
- Pas de transfert massif non inspecte de `data/training/live_sessions`.
|
||||
|
||||
## Validation attendue
|
||||
|
||||
Claude doit produire :
|
||||
|
||||
- manifeste exact des chemins retenus ;
|
||||
- taille de chaque entree ;
|
||||
- commande d'archive non destructive ;
|
||||
- commande de verification anti-secret/anti-capture ;
|
||||
- emplacement cible DGX ;
|
||||
- checksum de l'archive.
|
||||
|
||||
Qwen doit verifier :
|
||||
|
||||
- rien de sensible dans l'archive runtime ;
|
||||
- tous les acquis necessaires au replay/matching sont presents ;
|
||||
- restauration testable sur DGX ;
|
||||
- chemins/configs coherents apres extraction.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,42 @@
|
||||
# ACK Codex — lecture Qwen/Claude et actions ouvertes
|
||||
|
||||
- `Date`: 2026-06-08 16:06 CEST
|
||||
- `Auteur`: Codex
|
||||
- `Statut`: actif
|
||||
|
||||
## Messages lus
|
||||
|
||||
- `2026-06-08_1546_claude-to-codex_ACK-additif-trained-artifacts-en-production.md`
|
||||
- `2026-06-08_1548_qwen-to-codex-claude_QG-WPA-WPB-GO.md`
|
||||
- `2026-06-08_MANIFESTE-TRANSFERT-TRAINED-ARTIFACTS-DGX.md`
|
||||
- `2026-06-08_1550_qwen-to-codex-claude_QG-MANIFESTE-TRAINED-ARTIFACTS.md`
|
||||
|
||||
## Etat confirme
|
||||
|
||||
| Sujet | Etat | Decision |
|
||||
|---|---|---|
|
||||
| WP-A dashboard fail-closed | Livre + QG | **GO sans reserve** |
|
||||
| WP-B verrou reenrolement | Livre + QG | **GO sans reserve** |
|
||||
| P1.g GPU | Livre + QG precedent | **GO**, bench reel reste a faire |
|
||||
| DGX preflight Option A | Preflight + QG | **GO preflight**, transfert code en attente consolidation/push |
|
||||
| Trained artifacts | Manifeste + QG | **GO avec reserves** |
|
||||
|
||||
## Actions ouvertes
|
||||
|
||||
1. **Trained artifacts V2**
|
||||
- Ajouter `visual_workflow_builder/backend/data/anchors/`.
|
||||
- Retirer `data/training/screen_states/` du paquet initial.
|
||||
- Ajouter un script de rewrite chemins `/home/dom/ai/rpa_vision_v3/` -> `/home/aivanov/ai/rpa_vision_v3/` pour `visual_anchors.image_path`.
|
||||
- Methode: tar + checksum, pas rsync direct.
|
||||
|
||||
2. **Consolidation code avant DGX**
|
||||
- Commit/push branche `poc/dgx-2026-06-08` requis avant clone DGX.
|
||||
- Ne pas pousser `data/`, `.env*`, secrets.
|
||||
- Inclure le handler HTTP 403 `fleet_enroll_locked` dans le commit de consolidation `api_stream`.
|
||||
|
||||
3. **Transfert effectif**
|
||||
- Aucun transfert de donnees execute a ce stade.
|
||||
- Aucun clone DGX execute a ce stade.
|
||||
- Attendre validation du manifeste V2 + decision push/branche.
|
||||
|
||||
— Codex
|
||||
@@ -0,0 +1,89 @@
|
||||
# Revue visuelle — captures _full.png des workflows métier (risque contenu patient)
|
||||
# Dossier : /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/
|
||||
# Généré 2026-06-08. À revoir AVANT envoi clinique DGX.
|
||||
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_ab3b0bdcbfbf_1776784888_full.png
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b8ae007cfb07_1776784723_full.png
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_be5bf2b0088b_1776773876_full.png
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_c47602cedc05_1776773318_full.png
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_f4ee64c796b1_1776784765_full.png
|
||||
Demo PMSI | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_fdfc0baf59e6_1776774010_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_79c26617976d_1778493882_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_8d4b9cf0207c_1778575835_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_8e72328ac1f1_1778575896_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_90aab00906b5_1778493250_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b8bf39376b8a_1778497633_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_c07eeb32f46e_1778497407_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_de15b10a848b_1778498168_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e31b93822caa_1778497559_full.png
|
||||
Demo_urgence_2 | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e757dbf3f22f_1778497837_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_79c26617976d_1778493882_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_90aab00906b5_1778493250_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_ad076a293244_1778679925_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b8bf39376b8a_1778497633_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_c07eeb32f46e_1778497407_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d026587f81cf_1778674974_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e31b93822caa_1778497559_full.png
|
||||
Demo_urgence_2_interop | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e757dbf3f22f_1778497837_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_19a316a9234e_1778887700_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_2002e2d7ba0d_1779089272_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_221d38ad0e90_1778851432_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_79c26617976d_1778493882_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_90aab00906b5_1778493250_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_a518f6d5e727_1778849657_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b8bf39376b8a_1778497633_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b972ad4bd7c8_1778849735_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_bfbffbb47be7_1778872136_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_c07eeb32f46e_1778497407_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_cd15bb4f8e52_1778851357_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_cf3a4b7702af_1778886433_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d98bc4caa74d_1778887632_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e31b93822caa_1778497559_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_e757dbf3f22f_1778497837_full.png
|
||||
Demo_urgence_3_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_f2b354c7facc_1778851494_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_03c42f2ed139_1769203089_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_0c2836b2e973_1769197682_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_51c04e0e1db5_1769203445_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_64ba9e3f9c7c_1769200373_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b0688d5625ce_1769203327_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_b73d32ff6a3a_1770801636_full.png
|
||||
Onlyoffice | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_faaab112603a_1769200099_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_01b083af68a4_1777577411_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_0438bd2d9bdd_1778161174_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_1e7a355e4a6a_1777567028_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_29b89a0891b5_1777578702_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_4852d99cae10_1778156445_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_4b7a49bddfbc_1778161000_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_588c9c1c673c_1778161204_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_6a4db9f10eb0_1777578174_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_76a0ff320080_1777589181_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_90a77dd7e94d_1777567721_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_930fa9de55fb_1778147052_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_94792774d3e9_1777566772_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_9ae251da05f0_1778156720_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_a2d52564f86a_1777578074_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_c3929b00816a_1778161050_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_cdfe229d3976_1778156566_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d2edf48ceeb2_1778161762_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d6c574420481_1777578052_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d7b26c54198f_1778147971_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_eed66b340a98_1778161242_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_f9bbb873c964_1777565422_full.png
|
||||
Urgence | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_ff3bfdf7f6d4_1777577699_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_0efb3b8f61bb_1778434669_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_1958d72f71c4_1778164548_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_1a8811a99aa8_1778435686_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_30ef2bca7362_1778434976_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_3c8a9303a3a2_1778422742_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_76a0ff320080_1777589181_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_7ed58bbe1194_1778434871_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_807d29c6ab5b_1778422860_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d7b26c54198f_1778147971_full.png
|
||||
Urgence_aiva_demo | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_efe9d72f07e3_1778425168_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_19a316a9234e_1778887700_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_221d38ad0e90_1778851432_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_bfbffbb47be7_1778872136_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_cd15bb4f8e52_1778851357_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_cf3a4b7702af_1778886433_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_d98bc4caa74d_1778887632_full.png
|
||||
linux_db | /home/dom/ai/rpa_vision_v3/visual_workflow_builder/backend/data/anchors/anchor_f2b354c7facc_1778851494_full.png
|
||||
Reference in New Issue
Block a user