blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3fff3402ec556d6e664c5415e4d8a0e5c7db48f3
IdeA/.ideai/tickets/28/issue.md
Blomios 2fa226e413 chore(tickets): versionne le store de tickets et de sprints du projet 
`.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>
2026-07-08 08:38:33 +02:00

2.9 KiB
Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
id number title status priority sprint links agentRefs createdBy updatedBy createdAt updatedAt version
9d8ec8cf-312a-4f90-8199-e37b183ba11e 28 First-run wizard : bouton « Save and continue » figé (busy bloqué par l'auto-détection) closed high null
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
kind
user
1783458330440 1783491458775 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.