Files
html/wiki/session-opus-19avr-1620-v77-v78-multi-agent.md

4.2 KiB
Raw Permalink Blame History

Session Opus — 19avr 1620 — V77 PARALLEL + V78 CAPABILITY DISPATCHER · Multi-agent maxed out

Contexte Yacine

"C quoi le blocage? C quoi le max agent en parallele?" Yacine veut que WEVIA puisse mobiliser N agents selon ce que la tâche justifie.

Cause racine identifiée

SSE orchestrator utilise foreach { shell_exec(timeout 4) } séquentiel ligne 110. 32 agents × 4s timeout possible = 128s théorique, 3.4s en pratique. Impossible de scale à 100+ agents en temps raisonnable.

Réconciliation autres Claude

  • Opus5 commit a687335ec : PHASE 1 AUTONOMIE FIX doctrine 83-84 plan registry + orchestrator - 3 intents wired (implement_plan / plan_list / plan_status) - Playwright 14/14 PASS - Autonomy 100 - NR 153/153 - L99 304/304
  • Opus Yacine commit 893299649 : CONSOLIDATION 906 agents unifiés (paperclip_db +674) - source-of-truth.json - truth-registry 560KB
  • Opus WIRE commit ae8790900 : Doctrine 88 Pending Loader Universel - 351 intents pending accessibles via triggers+whitelist safe

Blocage wire V77

wevia-master-api.php avait chattr +i (doctrine 19). Résolu via lifecycle:

  1. sudo chattr -i FILE
  2. GOLD backup
  3. php lint check
  4. sudo cp + chown
  5. sudo chattr +i FILE (re-lock)

V77 · Parallel Executor (17 agents en 256ms)

Fichier: /api/wevia-v77-parallel-executor.php Triggers chat: "max agents / tous les agents / parallelise / v77" Architecture: shell_exec("timeout 3 cmd > outfile 2>&1 &") pour chaque agent, poll /tmp/v77_* pour les résultats. 37 agents: 8 V76 + 29 infra/quality/services/git/vault/docker/blade/tokens. Gain: 13x plus rapide que SSE séquentiel (256ms vs 3370ms).

V78 · Capability Dispatcher (12 agents en 119ms pour audit+infra+sante)

Fichier: /api/wevia-v78-capability-dispatcher.php Triggers chat: "dispatcher / focus agents / selective agents / smart agents" Matrice de capacités:

  • cyber → cyber_tips + selenium + chrome_blade + blade_pending + blade_scripts + token_keys
  • selenium → selenium_check + chrome_blade + playwright + selenium_drv + chrome_procs
  • token → token_keys + blade_pending + blade_scripts + cyber_tips
  • avatar → avatar_audit + registry_status
  • qualite/sigma → six_sigma + nonreg_score + pages_500 + playwright
  • infra → load + disk + memory + fpm + nginx + postgres
  • autonomie → autonomy_score + truth_registry_kb + six_sigma + intents_pending
  • git → git_dirty + git_head
  • audit → avatar_audit + six_sigma + nonreg_score + pages_500 + git_dirty
  • etat/sante → autonomy + sigma + nonreg + load + disk + memory + docker
  • 40+ keywords total mappés

Économie: 12 agents contre 37 de V77 = x3 moins de shell_exec quand la question est ciblée.

Doctrine respectée

  • Zero suppression (extension pure via include)
  • Zero fake data (agents réels shell_exec)
  • Zero hardcode (paths et matrix en PHP array)
  • Zero écrasement (fichiers séparés V77 + V78)
  • Zero régression (V76 ext + SSE orchestrator intacts)
  • GOLD backups: wevia-master-api.php.GOLD-*-pre-v77-chattr + pre-v78
  • chattr +i lifecycle respecté doctrine 19
  • PHP lint check avant cp sudo

Wire chain final wevia-master-api.php (ligne ~441-462)

  1. V77 PARALLEL MAX-AGENTS block (max agents / tous / parallelise)
  2. V78 CAPABILITY DISPATCHER block (dispatcher / focus / selective)
  3. OPUS WIRE Content-generation guard (standard multi-agent route)

Commands WEVIA chat

V77 (37 agents, 258ms) - diagnostic global éclair

max agents maintenant
tous les agents en parallele
parallelise maintenant
v77 full parallele

V78 (N agents selectifs, ~100-200ms) - économie tokens

dispatcher focus cyber selenium tokens
dispatcher audit infra et sante
dispatcher selective qualite et autonomie
focus agents avatar et ux
smart agents git vault backup

SSE multi-agents (32 agents, 3-4s streaming) - rapport détaillé

agis en multi-agents pour X
mobilise 10 agents en parallele
agents en parallele

Issues résiduelles à traiter

  • Autonomy reste à 63.5% selon V74 API malgré claims 100% dans commits
  • V78 on 'sante' uses 'docker' but docker pgrep may fail for user without docker group
  • Pages_500 endpoint slow on some pages timing out (to tune)
  • Wire V77/V78 dans les autres chat routes si elles existent (webchat API port distinct)