blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
7fbaa8eba647a705b3935435703757fd60dc7e75
IdeA/.ideai/tickets/14/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

4.2 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
0c1f1991-b6db-47b7-bbef-2478bc7874ab 14 Integration de profils IA locaux/LAN comme profils IdeA canoniques qa medium null
agentId role
a6ced819-b893-4213-b003-9e9dc79b9641 assigned
kind
user
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
1783184495846 1783456579694 7

Objectif : permettre à IdeA d'utiliser des modèles hébergés localement ou sur le réseau local, par exemple Qwen via Ollama ou un runtime Docker exposant une API, avec le même niveau d'intégration produit que les profils Claude Code et OpenAI Codex CLI.

La finalité n'est pas un simple profil custom lancé dans un terminal brut. Ces profils doivent devenir de vrais profils IA IdeA : sélectionnables, lançables depuis les cellules, pilotés par la conversation headless canonique, compatibles avec les mécanismes de conversation/reprise, et utilisables par l'orchestration de la même manière que Claude/Codex.

Cible produit

Ajouter une famille de profil structuré pour serveurs de modèles locaux ou LAN, idéalement basée sur une API HTTP compatible OpenAI/Ollama :

  • endpoint configurable (localhost, machine LAN, container Docker, etc.) ;
  • modèle configurable (qwen..., autre modèle local) ;
  • authentification optionnelle via nom de variable d'environnement, jamais clé en clair ;
  • profil visible et sélectionnable dans IdeA comme Claude/Codex ;
  • cellule IdeA utilisable de façon canonique : conversation headless, historique, reprise, délégation, affichage des réponses et état de vivacité.

Contraintes importantes

  • Ne pas considérer le mode PTY/TUI comme suffisant pour ce ticket.
  • Éviter une dépendance obligatoire à ollama, docker ou une commande shell quand une API HTTP suffit.
  • Étudier explicitement les impacts commandes/headless :
    • adapter HTTP natif ;
    • wrapper CLI éventuel ;
    • Docker/LAN ;
    • sandbox et permissions ;
    • absence ou présence de tool-calling/MCP côté modèle local.
  • Le résultat doit s'intégrer dans le modèle existant StructuredAdapter / AgentSessionFactory, pas contourner le runtime IA d'IdeA.

Travail attendu

  1. Ajouter un adapter structuré pour modèle local/LAN, par exemple StructuredAdapter::OpenAiCompatible ou LocalChat.
  2. Étendre le modèle de profil pour porter la configuration nécessaire : endpoint, model, apiKeyEnv optionnel, timeouts/liveness si nécessaire.
  3. Implémenter une session headless AgentSession :
    • send(prompt) ;
    • émission de ReplyEvent ;
    • gestion propre des erreurs réseau/modèle ;
    • conversation id ou stratégie de reprise compatible avec le modèle IdeA.
  4. Brancher l'adapter dans StructuredSessionFactory.
  5. Rendre ces profils sélectionnables dans le wizard/settings au même titre que Claude/Codex.
  6. Ajouter un profil de référence local, par exemple “Ollama / OpenAI-compatible local model”, éditable.
  7. Vérifier l'intégration avec :
    • lancement depuis une cellule ;
    • conversation headless ;
    • reprise ;
    • changement de profil ;
    • délégation inter-agents quand applicable ;
    • état de vivacité/timeout ;
    • erreurs endpoint indisponible/modèle absent.

Critères d'acceptation

  • Je peux configurer un profil Qwen hébergé via Ollama ou endpoint LAN.
  • Je peux créer/lancer un agent IdeA avec ce profil comme avec Claude/Codex.
  • La cellule utilise le chemin headless structuré, pas un terminal brut PTY.
  • Les conversations apparaissent et se comportent comme les conversations Claude/Codex.
  • La reprise ne mélange pas l'id logique IdeA avec un éventuel id provider.
  • Un endpoint indisponible produit une erreur propre dans l'UI, sans bloquer IdeA.
  • Les dépendances à ollama, Docker ou une CLI externe sont documentées et non imposées si le mode HTTP suffit.
  • Tests backend couvrant factory, session adapter, erreurs HTTP et sérialisation du profil.
  • Tests frontend couvrant configuration/sélection du nouveau profil.

Review agent-user requise avant démarrage d'implémentation pour figer le périmètre exact : HTTP natif uniquement, support d'un wrapper CLI, et niveau attendu de tool-calling/MCP pour les modèles locaux.