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>

.ideai/tickets/14/carnet.md

@@ -0,0 +1,20 @@
+---
+issueRef: "#14"
+version: 7
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1783456579694
+---
+## Production #14 — livrée dans develop (validation e2e live restante)
+
+Périmètre figé avec l'utilisateur : adapter HTTP OpenAI-compatible **purement additif** (zéro régression Claude/Codex), parité **tool-calling + MCP** complète, canal HTTP natif robuste.
+
+### Cycle
+- Cadrage Architect : slug mémoire `ticket14-local-lan-openai-adapter-scoping` (asymétrie CLI-vs-serveur HTTP, port ToolInvoker in-process, reprise sans id provider).
+- Backend (DevBackend) : variante `StructuredAdapter::OpenAiCompatible`, VO `HttpChatConfig`, `openai_compat.rs`, port `ToolInvoker` déléguant à la même OrchestratorService que le MCP. GO QA (domain 467 / application 530 / infrastructure 523 / app-tauri 247, 0 échec). Défaut réel corrigé : timeout post-contact mappé Io.
+- Frontend (DevFrontend) : types DTO miroir, wizard/settings (endpoint/model/apiKeyEnv=nom de var/timeouts, validation miroir backend), profil de référence Ollama éditable, erreur endpoint rendue via bannière role="alert". GO QA (tsc 0 + vitest 59 fichiers / 566 tests, 0 échec). Défaut réel corrigé : erreur endpoint invisible dans le DOM.
+
+### Git
+- Backend `aab4bca`, frontend `d89380c`, merge `--no-ff` `3c6cd04` → develop. Branche feature supprimée. **Local uniquement, rien poussé.**
+
+### Reste à faire (hors code)
+- Validation e2e **live contre un vrai endpoint Ollama/LAN** : lancement cellule, conversation headless, reprise, délégation inter-agents, vivacité/timeout, endpoint indisponible/modèle absent (critère d'acceptation n°7). Non exercée en tests automatisés — c'est la raison du statut QA plutôt que closed.

.ideai/tickets/14/issue.md

@@ -0,0 +1,75 @@
+---
+id: "0c1f1991-b6db-47b7-bbef-2478bc7874ab"
+number: 14
+title: "Integration de profils IA locaux/LAN comme profils IdeA canoniques"
+status: "qa"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1783184495846
+updatedAt: 1783456579694
+version: 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.