Blomios
2fa226e413
`.ideai/tickets/` et `.ideai/sprints/` sont le registre durable du projet (les tickets sont déjà référencés par les messages de commit : #14, #21..#25, #28), au même titre que `.ideai/memory/`. Ils entrent donc dans le dépôt. À l'inverse, `.ideai/background-tasks/` (snapshots de rendez-vous headless) et `.ideai/proposals/` (amendements de contexte en attente d'arbitrage) restent de l'état d'exécution transitoire, de la même classe que `live-state.json` et `.ideai/requests/` : ils doivent être ignorés (patch `.gitignore` à venir). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
33 lines
2.9 KiB
Markdown
33 lines
2.9 KiB
Markdown
---
|
|
id: "9d8ec8cf-312a-4f90-8199-e37b183ba11e"
|
|
number: 28
|
|
title: "First-run wizard : bouton « Save and continue » figé (busy bloqué par l'auto-détection)"
|
|
status: "closed"
|
|
priority: "high"
|
|
sprint: null
|
|
links: []
|
|
agentRefs: []
|
|
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
updatedBy: {"kind":"user"}
|
|
createdAt: 1783458330440
|
|
updatedAt: 1783491458775
|
|
version: 3
|
|
---
|
|
## Symptôme (confirmé live, build 0.3.0 @2026-07-07 22:46, = develop 3c6cd04)
|
|
Au premier lancement, le wizard affiche les profils de référence (Claude/Codex/Ollama), l'utilisateur remplit le profil Ollama et coche la case, mais **« Save and continue » ET « Detect installed CLIs » restent grisés** → impossible de finir le first-run. Confirmé par l'utilisateur : les deux boutons sont grisés.
|
|
|
|
## Diagnostic (source + JS embarqué vérifiés)
|
|
- Le JS embarqué contient exactement `disabled: n.busy` sur le bouton (`FirstRunWizard.tsx:103`) — **aucune** condition de validation. Donc bouton grisé ⇔ `busy` reste `true`.
|
|
- `useFirstRun.reload()` : `setBusy(true)` → affiche les lignes (d'où formulaire visible/éditable) → `await detectProfiles(refs)` (auto-détection à l'ouverture) → `finally { setBusy(false) }`. Le `finally` ne s'exécute que **si la détection se termine**. Si la promesse `detectProfiles` ne se résout jamais, `busy` reste figé → les deux boutons restent grisés.
|
|
|
|
## Causes racines suspectées (2 défauts #14 qui se combinent)
|
|
1. **Profil Ollama sans commande de détection** : `detect: None` → `detection_spec` retombe sur `"{command} --version"` = `openai-compatible --version` (`runtime/mod.rs:64`), binaire inexistant → ligne « ✗ not found », et surtout probe inutile.
|
|
2. **`block_on` sur runtime tokio imbriqué** dans le chemin de détection : `DetectProfiles::execute` (`usecases.rs:79`) appelle `runtime.detect()` synchrone → `futures_block_on` construit un runtime current-thread et `block_on` (`runtime/mod.rs:231`) **à l'intérieur** de la commande async Tauri `detect_profiles` (`commands.rs:752`). Pattern qui peut paniquer (« Cannot start a runtime from within a runtime ») / rester pendu → la promesse ne se résout jamais. Se déclenche probablement sur une machine **sans Claude/Codex installés**.
|
|
|
|
## Attendu du fix
|
|
- `busy` doit **toujours** revenir à `false` même si la détection panique/pend (le `finally` ne doit pas dépendre du résultat de la détection ; détection best-effort, non bloquante, éventuellement bornée par timeout).
|
|
- Donner une commande/stratégie de détection correcte au profil OpenAI-compatible (ou ne pas le sonder comme un CLI — c'est un endpoint HTTP, pas un binaire).
|
|
- Corriger le `block_on` imbriqué dans le runtime de détection (ne pas bloquer dans un contexte async Tauri).
|
|
|
|
## Validation QA
|
|
Reproduire sur une machine **sans** Claude/Codex installés + Ollama lancé ; vérifier que le wizard reste utilisable (boutons cliquables) et que le profil Ollama se persiste et démarre. |