Plan de Test — Ulias-Org v0.8.0
Date : 13/02/2026
Status : IMPLEMENTEE
Objectif : Tester le projet ulias-org de bout en bout pour identifier ce qui fonctionne et ce qui ne fonctionne pas.
Constat initial (pre-test)
| Element |
Etat |
Commentaire |
| /health |
OK |
v0.8.0, uptime 10h+, 1 session active |
| /api/status |
OK |
31 agents, 8 teams, scheduler running |
| /api/teams |
OK |
8 teams retournees |
| /api/agents |
OK |
31 agents avec models et tools |
| /api/capabilities |
OK |
Reponse complete |
| /api/objectives |
PROBLEME |
50 objectives TOUTES en "pending" — aucune executee |
| /api/decisions |
OK (vide) |
Aucune decision en attente |
| /api/suggestions |
OK (vide) |
Normal (profil CEO vide) |
| /api/profile |
OK (vide) |
Profil pas encore configure |
| ulias-org-web |
403 |
Restriction IP nginx (a tester depuis navigateur local) |
| Scheduler |
CREE mais N'EXECUTE PAS |
health_check (5min) + disk_usage (1h) creent des objectives jamais traites |
Probleme critique identifie : Le scheduler cree des objectives via director.handleMessage() mais elles restent toutes en pending. Soit le routing LLM echoue silencieusement, soit la mise a jour DB in_progress echoue, soit le ReAct loop ne demarre jamais.
Phase 1 : Diagnostic du flow principal (PRIORITAIRE)
Verifier pourquoi les 50 objectives sont bloquees en "pending".
| Test |
Methode |
Attendu |
| 1.1 Logs container ulias-org |
docker logs ulias-org --tail 200 via SSH |
Chercher erreurs Scheduler/Director |
| 1.2 Test LLM routing |
Appel direct ai-orchestrator avec qwen3:8b |
Verifier que le modele repond |
| 1.3 Test interpreter.route() |
Envoyer un message simple via WS |
Observer le routing decision |
| 1.4 Test connectors-api reachable |
curl depuis le container ulias-org |
Verifier connectivite reseau |
| 1.5 Test Supabase DB write |
Creer/update un objectif manuellement |
Verifier que les updates passent |
Phase 2 : Endpoints REST (verification fonctionnelle)
| Test |
Endpoint |
Auth |
Attendu |
| 2.1 Health |
GET /health |
Non |
{status: "healthy", version: "0.8.0"} |
| 2.2 Status |
GET /api/status |
Non |
Agents count, teams, scheduler |
| 2.3 Teams |
GET /api/teams |
Non |
8 teams avec agents |
| 2.4 Agents list |
GET /api/agents |
Non |
31 agents avec tools et models |
| 2.5 Capabilities |
GET /api/capabilities |
Non |
Reponse structuree complete |
| 2.6 Objectives |
GET /api/objectives |
X-API-Key |
Liste objectives user |
| 2.7 Objective detail |
GET /api/objectives/:id |
X-API-Key |
Objective + tasks |
| 2.8 Active objectives |
GET /api/objectives/active |
X-API-Key |
Seulement in_progress |
| 2.9 Decisions |
GET /api/decisions |
X-API-Key |
Liste (probablement vide) |
| 2.10 Profile GET |
GET /api/profile |
X-API-Key |
Profil CEO |
| 2.11 Profile PUT |
PUT /api/profile |
X-API-Key |
Mettre a jour preferences |
| 2.12 Suggestions |
GET /api/suggestions |
Non |
Suggestions contextuelles |
| 2.13 Scheduler jobs |
GET /api/scheduler/jobs |
Non |
3 jobs avec running status |
| 2.14 Feedback GET |
GET /api/feedback/:agent |
X-API-Key |
Stats feedback agent |
| 2.15 Feedback POST |
POST /api/feedback |
X-API-Key |
Creer un feedback |
| 2.16 Prompt GET |
GET /api/agents/:name |
X-API-Key |
Prompt agent (avec override) |
| 2.17 Prompt PATCH |
PATCH /api/agents/:name/prompt |
X-API-Key |
Override prompt |
| 2.18 Prompt DELETE |
DELETE /api/agents/:name/prompt |
X-API-Key |
Reset prompt |
Phase 3 : WebSocket & Flow principal
| Test |
Methode |
Attendu |
| 3.1 Connexion WS |
wscat -c wss://ulias-org.../ws/webui |
Connexion etablie |
| 3.2 Auth WS |
Envoyer {type:"auth", apiKey:"ck_live_..."} |
Reponse auth_success |
| 3.3 Message simple |
{type:"message", content:"Quel est le status des containers?"} |
Routing → monitor → exec → reponse |
| 3.4 Evenements temps reel |
Observer les events pendant 3.3 |
objective_created, routing, thinking, tool_call, tool_result, objective_completed |
| 3.5 Lifecycle objectif |
Verifier en DB apres 3.3 |
Objectif passe par pending → in_progress → completed |
| 3.6 Message recherche |
"Lis le fichier /etc/hostname sur prod-portainer" |
Routing → explorer → readFile → reponse |
| 3.7 Message code |
"Lis le fichier package.json de ulias-org" |
Routing → explorer/coder → readFile |
Phase 4 : Test par agent (1 par team)
| Agent |
Team |
Commande test |
Outil attendu |
Verification |
| 4.1 monitor |
ops |
"Verifie les containers Docker sur prod-portainer" |
exec (docker ps) |
Liste containers |
| 4.2 explorer |
research |
"Lis le fichier /etc/os-release sur prod-portainer" |
readFile |
Contenu fichier |
| 4.3 analyst |
research |
"Montre les derniers logs de ulias-org dans Loki" |
queryLogs |
Logs recents |
| 4.4 infra |
ops |
"Verifie l'espace disque sur prod-portainer" |
exec (df -h) |
Usage disque |
| 4.5 coder |
engineering |
"Lis le package.json du projet ulias-org sur gitlab-SSH" |
readFile |
Contenu JSON |
| 4.6 auditor |
security |
"Verifie les ports ouverts sur prod-portainer" |
exec (ss -tlnp) |
Liste ports |
Phase 5 : Scheduler
| Test |
Methode |
Attendu |
| 5.1 Jobs actifs |
GET /api/scheduler/jobs |
2 enabled (health_check, disk_usage) |
| 5.2 Execution reelle |
Attendre 5min (health_check) puis verifier logs |
Le job cree un objectif ET l'execute |
| 5.3 Objectif traite |
Verifier que le nouvel objectif passe completed |
Pas rester en pending |
| 5.4 Notification echec |
Simuler un echec (si possible) |
Notification ntfy envoyee |
Phase 6 : Pipelines
| Test |
Pipeline |
Methode |
Attendu |
| 6.1 verification_chain |
WS: "Ecris un script hello.sh, fais-le reviewer et tester" |
coder → reviewer → tester |
| 6.2 Briefing trigger |
WS: "Cree un nouveau site web" |
Detection briefing, questions Q&A |
| 6.3 Briefing annulation |
Repondre "annuler" pendant briefing |
Briefing annule proprement |
Note : Les pipelines create_* sont des operations destructives (creent des repos GitLab). A tester avec prudence.
Phase 7 : Features avancees
| Test |
Feature |
Methode |
Attendu |
| 7.1 Traduction |
Agent repond en anglais |
Director.translateOutput() |
Reponse traduite en FR |
| 7.2 Response cache |
Meme question 2x |
2eme appel plus rapide |
Cache hit |
| 7.3 Circuit breaker |
Outil defaillant |
Apres 3 echecs → pause 60s |
Pas de cascade |
| 7.4 Decision approval |
Agent deployer fait gitPush |
Decision request envoyee |
CEO doit approuver |
| 7.5 Lessons |
Apres objectif complete |
Lesson extraite + embedding |
Stocke en DB |
| 7.6 CEO profile |
Interactions repetees |
Profil mis a jour |
Patterns detectes |
| 7.7 Suggestions |
Avec profil rempli |
GET /api/suggestions |
Suggestions contextuelles |
| 7.8 File upload |
POST /api/upload avec base64 |
Fichier dans Supabase Storage |
URL retournee |
Phase 8 : Web UI (ulias-org-web)
| Test |
Page |
Verification |
| 8.1 Login |
/login |
Connexion API key → redirect dashboard |
| 8.2 Dashboard |
/ |
Stats, agents, derniere activite |
| 8.3 Chat |
(main page) |
Envoyer message, voir evenements live |
| 8.4 Monitor |
/monitor |
Affichage health containers |
| 8.5 History |
/history |
Liste objectives (filtrage par status) |
| 8.6 Decisions |
/decisions |
Queue decisions (vide probablement) |
| 8.7 Teams |
/teams |
8 teams avec agents |
| 8.8 Prompts |
/prompts |
Editer prompt agent, sauvegarder, reset |
| 8.9 Settings |
/settings |
Preferences CEO |
| 8.10 Help |
/help |
Capabilities, tools, pipelines |
Note : L'UI web retourne 403 depuis PVE (restriction IP nginx). A tester depuis un navigateur sur le reseau autorise.
Ordre d'execution propose
- Phase 1 (diagnostic) — Comprendre POURQUOI les 50 objectives sont bloquees
- Phase 2 (REST) — Valider tous les endpoints rapidement
- Phase 3 (WebSocket) — Tester le flow principal end-to-end
- Phase 4 (agents) — Verifier que chaque type d'agent fonctionne
- Phase 5 (scheduler) — Verifier l'execution automatique
- Phase 6 (pipelines) — Tester les workflows multi-etapes
- Phase 7 (avancees) — Cache, circuit breaker, decisions, lessons
- Phase 8 (web) — UI (a faire depuis navigateur)
Criteres de succes
- [ ] Flow principal fonctionne : message → routing → agent → tools → result
- [ ] Objectifs passent par le cycle complet (pending → in_progress → completed)
- [ ] Le scheduler execute REELLEMENT les jobs (pas juste creer en DB)
- [ ] Au moins 1 agent par team execute un tool avec succes
- [ ] La traduction FR fonctionne
- [ ] Les events WebSocket arrivent en temps reel
- [ ] La DB persiste correctement (objectives, tasks, messages)