Proposition : Remplacer le polling par callbacks + logging complet

Status : IMPLEMENTEE

Diagnostic

Pourquoi ca timeout

1. ToolsClient.pollJob() fait du polling toutes les 500ms vers ai-orchestrator — des centaines de requetes HTTP inutiles
2. ai-orchestrator supporte deja les callbacks (callback_url) — ulias-org ne les utilise PAS
3. Le routing Interpreter a un timeout de 90s, mais le cold start Ollama + queue peut prendre plus
4. Les logs sont quasi inexistants pendant les appels LLM — zero visibilite

Ce qui manque

• Aucun log avant/apres un appel LLM (modele, tokens, duree)
• Aucun log du job ID ai-orchestrator
• Aucun event frontend pendant l'attente LLM
• Le polling silencieux mange le timeout sans rien signaler

Changements

1. ToolsClient — Callbacks au lieu du polling

Fichier : packages/server/src/tools/client.ts

Remplacer pollJob() (polling 500ms) par un systeme callback :

- Map<jobId, {resolve, reject, timer}> pour les jobs en attente
- Quand on cree un job : passer callback_url=http://192.168.1.12:5515/internal/job-callback/{jobId}
- Attendre une Promise qui se resolve quand le callback arrive
- Timeout failsafe : si le callback n'arrive pas apres X secondes, reject

Le callback fonctionne deja — ai-orchestrator envoie des webhooks vers http://192.168.1.12:5510/callback/... (claude-memory). Meme pattern pour ulias-org sur port 5515.

2. Index.ts — Endpoint callback

Fichier : packages/server/src/index.ts

Ajouter un endpoint HTTP interne :

.post('/internal/job-callback/:jobId', async ({ params, body }) => {
  // Resolve la Promise en attente pour ce jobId
  // body = {job_id, status, output_result, error_message, processing_time_ms, gpu_id, ...}
})

3. Logging structure complet

ToolsClient.callLLM() — avant/apres chaque appel :

[LLM] → ${model} tools=${N} ctx=${num_ctx} priority=${priority} timeout=${timeout}ms
[LLM] Job ${jobId} created (queue_pos=${pos})
[LLM] Job ${jobId} completed in ${duration}ms (${tokens} tokens, GPU${gpuId})
[LLM] Job ${jobId} TIMEOUT after ${timeout}ms
[LLM] Job ${jobId} FAILED: ${error}

AgentRunner — chaque iteration :

[Agent:${name}] iter=${i}/${max} → LLM call (${messages.length} msgs, ${model})
[Agent:${name}] iter=${i} ← ${toolCalls} tools / ${content.length} chars (${duration}ms)
[Agent:${name}] Tool ${toolName}(${argsPreview}) → ${resultLength} chars (${duration}ms)

Interpreter — routing :

[Interpreter] Routing via ${model} (timeout=${timeout}ms)
[Interpreter] Job ${jobId} → routed to ${agent} (${duration}ms)

4. Events frontend pendant l'attente LLM

Nouveaux events envoyes au frontend via le WebSocket existant :

{type: 'llm_started', data: {model, iteration, messageCount}}
{type: 'llm_completed', data: {model, duration, toolCalls, tokens}}

Le frontend affichera dans le streaming indicator : "LLM qwen3:8b en cours (iter 1/10)..." au lieu de rien.

5. Timeouts revises

Fichiers modifies

Ordre d'execution

1. Ajouter le systeme callback dans ToolsClient + endpoint dans index.ts
2. Ajouter tous les logs structures
3. Ajouter les events frontend (llm_started, llm_completed)
4. Augmenter les timeouts
5. Commit + push → pipeline
6. Tester via connectors-api (JAMAIS en direct)