Audit critique ulias-org + Plan de fix

Date : 14/02/2026 Status : EN ATTENTE VALIDATION

Constat utilisateur

1. La derniere conversation reste en "pending" apres execution
2. L'objectif "envoie un mail avec les projets GitLab" ne fonctionne pas : il retourne la liste des outils AI au lieu de faire la tache, et pas de mail recu
3. Aucun feedback visuel pendant l'execution : "on ne voit pas ce que tu es en train de faire"
4. Le routing doit etre generique : on peut envoyer un mail via Mailjet mais aussi Gmail API, le systeme doit choisir intelligemment

Problemes identifies (par ordre de criticite)

P1 - CRITIQUE : Objectif orphelin en "pending" (backend)

Fichier : director/index.ts Lignes : 117-126, 196-208

Le bug : Quand un objectif declenche un briefing :

1. handleMessage() cree l'objectif #1 en DB (status: pending) → ligne 199
2. Briefing demarre, les questions sont posees
3. L'utilisateur repond "go" → handleBriefingMessage() ligne 126 appelle handleMessage(enrichedPrompt, onEvent, { skipBriefing: true })
4. Ce 2eme appel cree un objectif #2 en DB → nouvelle ligne 199
5. L'objectif #2 s'execute et se termine (completed)
6. L'objectif #1 reste pending pour toujours → orphelin

Fix : Stocker le objectiveDbId original dans le briefing session. Quand handleBriefingMessage confirme, passer cet ID via opts.reuseObjectiveId pour que handleMessage le reutilise au lieu d'en creer un nouveau.

Fichiers modifies : director/index.ts (opts, createObjective conditionnel, stockage dans briefing)

P2 - CRITIQUE : Multi-step ne passe pas le bon contexte (backend)

Fichier : director/index.ts Lignes : 452-461

Le bug : Dans handleMultiStep, le previous_result de la sous-tache 1 est passe a la sous-tache 2 comme texte brut tronque a 4000 chars. Problemes :

• Si la sous-tache 1 retourne un gros JSON (ex: 10 projets GitLab), il est tronque de maniere incoherente
• L'agent suivant recoit du texte coupe sans instruction claire sur quoi en faire
• Le task.description (ligne 467) dit juste "Part 1/2 of: ..." sans expliciter que le previous_result contient les donnees a utiliser

Fix :

• Enrichir le task.description avec des instructions explicites : "Utilise les donnees ci-dessous (previous_result) pour accomplir ta tache."
• Passer aussi le message original complet pour que l'agent comprenne l'objectif final
• Garder la compaction mais la rendre plus intelligente (garder la structure, pas juste couper)

Fichiers modifies : director/index.ts (handleMultiStep description enrichie)

P3 - CRITIQUE : Events de progression invisibles (frontend)

Fichier : ulias-org-web/src/components/chat/EventCard.tsx Lignes : 269, 332, 338

Le bug : Les events thinking, tool_call, tool_result sont rendus avec :

• opacity-60 sur le conteneur → quasi-invisible (ligne 269)
• opacity-70 text-xs sur le texte → minuscule et transparent (ligne 332)
• opacity-60 sur les arguments d'outils (ligne 338)

L'utilisateur ne voit strictement rien pendant que l'agent travaille, puis la reponse finale apparait d'un coup.

Fix :

• Retirer opacity-60 du conteneur des events progress
• Changer opacity-70 text-xs en opacity-90 text-sm (meme taille que le reste)
• Retirer opacity-60 des arguments d'outils
• Les events progress restent visuellement distincts via la couleur de la bordure gauche (deja en place)

Fichiers modifies : EventCard.tsx (3 lignes de CSS)

P4 - HAUTE : Indicateur de streaming statique (frontend)

Fichier : ulias-org-web/src/components/chat/ChatMessages.tsx Lignes : 234-238

Le bug : Pendant l'execution, le seul feedback est un texte statique "Reflexion en cours..." qui ne change jamais. L'utilisateur ne sait pas :

• Quel agent travaille
• Quelle iteration en cours (1/5, 2/5...)
• Quel outil est appele
• Ou en est le multi-step (etape 1/2, 2/2...)

Fix : Rendre l'indicateur de streaming dynamique en trackant le dernier event recu. Afficher un message contextuel :

• thinking → "Reflexion en cours... (iteration X/Y)"
• tool_call → "Appel outil: nomDeLoutil..."
• subtask_started → "Etape X/Y : description..."
• routing → "Routage vers agent..."
• Defaut → "En cours..."

Fichiers modifies : ChatMessages.tsx (signal lastEvent + affichage dynamique)

P5 - HAUTE : Routing pas generique — doit etre instance-aware (backend)

Fichiers : agents/interpreter.ts, director/index.ts

Le probleme fondamental : Le routing est hardcode. Exemples :

• "envoie un mail" → hardcode vers connector → sendEmail (Mailjet). Mais Gmail aussi peut envoyer des mails.
• "regarde une video" → aucun routing. Mais ca pourrait etre Jellyfin OU YouTube (si connecteur ajoute).
• "stocke ce fichier" → pas clair. Nextcloud ? User Storage ? Google Drive ?

Le systeme ne sait pas quelles instances le user a et ce qu'elles peuvent faire.

Le fix architectural :

1. Le routing prompt doit etre dynamique : buildRoutingPrompt() recoit les instances du user et genere un prompt qui liste les capacites reelles.

Aujourd'hui dans interpreter.ts:
  buildRoutingPrompt()  ← statique, hardcode

Apres fix:
  buildRoutingPrompt(userInstances)  ← dynamique, base sur les instances

2. L'interpreter recoit le UserContext : route(message) → route(message, userCtx) pour acceder aux instances.

3. Le prompt genere une section "CAPABILITIES" dynamique :

AVAILABLE CAPABILITIES (based on user's connected instances):
- Email: Mailjet (transactionnel, no-reply@gouroubleu84.com), Gmail (personnel, OAuth)
- Storage: Nextcloud, User Storage (interne), Google Drive
- Media: Jellyfin (local, films/series)
- Git: GitLab-33800 (local CI/CD)
- AI: AI Orchestrator (Ollama, GPU local)
- DB: Supabase
- Notifications: ntfy (push)
- Logs: Loki/Grafana

When multiple instances can fulfill a request, choose the most appropriate:
- Email formal/transactionnel → Mailjet
- Email personnel → Gmail
- Video locale → Jellyfin
- If ambiguous, prefer the most specific instance for the task.

4. Pas de hardcodage dans le routing prompt : Les sections COMMUNICATION ROUTING, SPECIALIST ROUTING etc. sont generees a partir des tags des instances (mail, storage, media, etc.) et des outils disponibles des agents.

Impact :

• Quand un user ajoute un connecteur YouTube, le routing le detecte automatiquement
• Quand un user n'a PAS Gmail connecte, le routing ne le propose pas
• Multi-user safe : chaque user a ses propres capabilities

Fichiers modifies :

• interpreter.ts : route() recoit userCtx, buildRoutingPrompt() dynamique
• director/index.ts : passe userCtx a interpreter.route()

Plan d'execution

Projets impactes : ulias-org (backend), ulias-org-web (frontend) Commits : 1 par projet Deploy : CI/CD automatique apres push

Test de validation

Apres deploy, tester via WebSocket :

1. "Fais l'etat des lieux des outils AI" → doit voir les events en temps reel + resultat
2. "Envoie un mail a gouroubleu@gmail.com avec les 10 derniers projets GitLab" → multi-step: projets recuperes puis mail envoye avec les BONS projets (routing detecte Mailjet + Gmail, choisit)
3. Creer un projet (briefing) → repondre aux questions → "go" → l'objectif original passe a completed, pas d'orphelin
4. Verifier routing dynamique : GET /api/capabilities doit montrer les capabilities detectees depuis les instances du user

Fichiers modifies (resume)